SlickEdit Community

SlickEdit Product Discussion => SlickEdit® => Features and/or Improvements => Topic started by: TKasparek on May 23, 2016, 06:01:01 pm

Title: Edit project templates, specify project for ctrl+., build output, color coding by regex
Post by: TKasparek on May 23, 2016, 06:01:01 pm
Wish list:
Title: Re: Edit project templates, specify project for ctrl+., build output, color coding by regex
Post by: Clark on May 23, 2016, 06:15:57 pm
  • Color coding by regex. Ability to specify an extension and color code the file by specifying a regex for how to color parts of the file.

This is on our todo list (won't make v21 though). I don't think we will be able to make this support a multi-line regex though. Should be really handy anyway.
Title: Re: Edit project templates, specify project for ctrl+., build output, color coding by regex
Post by: jporkkahtc on May 24, 2016, 05:13:09 pm
Clark, how does the language color coding work?


I can define a custom language and add tons of keywords and slick is able to color those very fast (for arm64, I've got about 1300 keywords).
Does it build a giant regex, or something more efficient?
Certainly, for things like arm assembly, being able to define the keywords with regex could make creating/editing the language easier, but I'd wonder how fast that is for coloring large files.




I use "QuickHighlight.e" to let me highlight words on the fly, but it gets pretty slow with large files. (It does a search and _SetTextColor)
I've thought about rewriting this to define a custom language - adding and removing keywords on the fly - seems like the performance would be a lot better.
It wouldn't let me define a different color for each "word" though. Also, changing the defined keywords in a language appears to be slow though.


The language coloring seems smart enough to only color what is on screen - while quickHighlight scans the entire file.


In any case, having built in QuickHighlight like functionality would be great - presumably it would be optimized to handle *huge* log files, regex patterns, etc.




TKasparek: Quickhighlight.e (available in the macros forum) just does a search for the words it highlights, so it could be extended to search for regex's as well.
Title: Re: Edit project templates, specify project for ctrl+., build output, color coding by regex
Post by: Clark on May 24, 2016, 05:37:33 pm
regex keywords should actually have descent performance and won't change performance of non regex keywords. A regex match will be slower of course but we will support both types of matching.

In v21, it will be faster to add/remove keywords on the fly because you won't have to write a file and then load it. Instead, you create XML in memory and load that.

I wouldn't expect having 1000 or so keywords to have any performance issues but if have say 10,000 or more, then things will likely slow down.

SlickEdit does not color code the entire file. Only the displayed page is color coded every time it's displayed.
Title: Re: Edit project templates, specify project for ctrl+., build output, color coding by regex
Post by: jporkkahtc on May 26, 2016, 08:25:28 pm
WRT TKasparek && Better parsing/separation of build output
All the tools are there in Slick for pretty powerful and flexible error parsing, but they are poorly integrated and of course requires you to be somewhat of an RegEx expert. The couple of times I've needed to, I've found it to be really hard to debug problems with the error parsing expressions.
It would be helpful if the build output window would tell you which error RE matched each individual error, and allow some sort of interaction --- from BuildOutput, activate the ErrorRE dialog. Also provide some simple way to update BuildOutput after you have changed the error parser. Live preview of the BuildOutput while you edit the error RE's would be ideal :-).


The "Error Regular Expressions" window is *almost* a much better RegEx tool than "RegEx Evaluator".

To make the Error tool window into a fantastic RE tool:
    Each of the items in the "Expressions" list is a saved expression.
    Keep the checkboxes to enable/disable.
    Add a text box for "Test cases".
    When there is a match in the TestCase, indicate which of the items in "Expressions" is the match.


Integrate with the rest of Slick: Everywhere where Slick accepts a RegEx, allow the user to access the list of saved expressions.

Extend the dialog to support replace expressions as well - requires each expression to be a pair + diff view showing the match preview + replace preview.