Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #9157
    CrashNBurn
    Member

    I have found something with the Syntax Highlighting that seems like a bug, but is likely intended behaviour?

    If I enable this rule and make it so it is one of the first rules in the .esy file — so that my own defined functions will be highlighted:

    [A-Za-z0-9_#[]@-]+(
    [x] Regular Expression

    E.G. TestFunc(

    Then it overrides all of my keywords if they also have a round bracket.
    E.G. if( .. Instead of: if(

    Yet, if I enable “Regular Expression” for all of the keywords, then it works like it should – Both rules are applied — except with that many keywords as regular expressions the scrolling staggers and jumps very badly.
    E.G. TestFunc( … and if(

    As well, I have a secondary Highlight to make the “(” just be default text colour.
    So I get: TestFunc(

    Shouldn’t all the syntax rules be applied regardless whether or not one is a regex and the other rule(s) are not?

    #9160
    Yutaka Emura
    Keymaster

    There is a limitation in regards to how strictly implement these conditions. More strictly implement the highlight, slower EmEditor becomes. We have to choose a balance between features and speed. Currently, this is the specification, unfortunately. I might consider more strict implementation in future major versions.

    Thank you,

    #9161
    CrashNBurn
    Member

    I know some of the issues could be resolved if there was a way to indicate what part of a Rule should be highlighted, aside from the “In Tag” or RightSide.

    For example,
    Highlight Match: \%([a-z0-9#_@$?]+)\%
    Higlight Partial: 1

    Or if Not using Regex::
    Highlight Match: \%SomeTextHere\%
    Highlight Partial: SomeTextHere

    It’s also a possibility, if a regex doesn’t use “+” or “.” when the Highlight rules are read, EmEditor could parse the rules into multiple non-regex single rules.

    Possible Regex (multiple lines for readability):

    A_Loop(Field
    |File(Attrib|Dir|Ext|(Full|Long)Path|Short(Name|Path)|Size(|KB|MB)|Time(Accessed|Created|Modified))
    |ReadLine
    |Reg(Key|Name|SubKey|TimeModified|Type)
    )

    Example Keywords

    A_LoopField
    A_LoopFileAttrib
    A_LoopFileDir
    A_LoopFileExt
    A_LoopFileFullPath
    A_LoopFileLongPath
    A_LoopFileShortName
    A_LoopFileShortPath
    A_LoopFileSize
    A_LoopFileSizeKB
    A_LoopFileSizeMB
    A_LoopFileTimeAccessed
    A_LoopFileTimeCreated
    A_LoopFileTimeModified
    A_LoopReadLine
    A_LoopRegKey
    A_LoopRegName
    A_LoopRegSubKey
    A_LoopRegTimeModified
    A_LoopRegType

    Possibly not many would find benefit to that particular code. Although I believe a general recursive function would be able to parse out a regex that doesn’t utilize “.” or “+” into non-regex single rules.

    Also looking through the .esy file, they tend to be grouped into types, similiar Highlight colors and options. If one could NAME that group of words/rules, and then provide an exception Rule to only be applied if none of the rules match.

    Example, from above, if I named those keywords, “BuiltInVars”, and also added something like the following:
    A_LoopField
    \%A_LoopField\%

    After all the internal variables are listed and grouped together, I could provide a rule like above:
    Default: \%([a-z0-9#_@$?]+)\%

    Which only is applied if none of the Group has matched already.

    Anyways, just throwing out some ideas. EmEditor rocks, I just find a few quirks/issues here and there :-)

    #9667
    CrashNBurn
    Member

    With V11 Beta out now, is there any chance of updating the Highlighter rules to either:

    1_) Allow to choose what piece of a regex to Highlight. OR

    2A) Allow a Rule to Block any further matches for the string &
    2B) Allow a Rule to ALLOW further matches for the string
    —> Regardless if one is a regex and one is a simple string.

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.