- May 26, 2014 at 7:56 am #18491
I am a PHP developer and I write scripts for VQMod. They all have mixed content: XML + PHP mostly (JS can be added as well). I love, when text is highlighted, but XML and PHP doesn’t mix well. See for yourself:
Problem’s very simple: EmEditor thinks, that -> is a closing tag for previously opened < tag, however it’s not. The same happens in most similar cases (e.g.:, simple string like this “<“ will “open” the highlighted text):
Could you add a feature to add a list of EXCLUDED symbols or symbol combinations for each highlighted option? I mean add a “Exclude tags” field on Highlight (1) tab near “Begin tag” and “End tag” ones. For example, in fore-mentioned cases I’d add ->, “>” and “<“ combinations, since they always interfere.May 26, 2014 at 4:41 pm #18494
The issue is quite broader. I work with Perl. And that language has some rather queer exceptions. One example: @my_array is … you guessed, an array! $#my array is the highest index currently occupied. But EmEditor considers everything beyond the ‘#’ as comment. And there are many more exceptions.
Try and open one of the syntax highlighting files. Open Tools->Properties for the current configuration->Highlight(1). Click the ‘Export’ button and same the ‘esy’ file. Its syntax seem simple enough. Especially note the line
There seem to be a possibility to specify some syntax highlighting by regular expressions. I once asked Yutaka for some usage examples. He doesn’t seem to consider this request as worthy of his attention. May be you can convince him otherwise…?May 27, 2014 at 2:22 am #18496
I work with Perl. And that language has some rather queer exceptions. One example: @my_array is … you guessed, an array! $#my array is the highest index currently occupied. But EmEditor considers everything beyond the ‘#’ as comment. And there are many more exceptions.
Perl is not a very good example. It is mathematically proven that it cannot be statically parsed (that is, without running the script itself), not to mention doing this with only regexps, having no customizable lexer and parser.
Of course, it does not mean that there is no place for improvements — some common and non-contradictory expressions still can be detected and highlighted, but with Perl’s versatility it’s quite a troublesome task. As a Perl developer, I would be extremely glad to see improvements in this area too…May 27, 2014 at 2:29 am #18497
I think most cases can be covered with exclusions list. For Perl you could add $#, for example, to avoid parsing this as a comment. Of course it’s impossible to cover all cases, but that’s OK.
So… Any word from developers?May 27, 2014 at 3:06 am #18498
That’s not a completely bad idea at all 🙂 Monkeyman! Thanks!
It could simply take care of some keywords used as variable or methods names: e.g.,
formatis a keyword but
$formatis a perfectly legal variable name.
warnis a keyword, but
$object->warnis an object’s method call, etc.
Well, Yutaka, how about it (and about RegEx usage examples?)
You must be logged in to reply to this topic.