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 :-)