[CrashNBurn]

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?

[Yutaka Emura]

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,

[CrashNBurn]

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

[CrashNBurn]

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.

[Author]

Posts