Edit project templates, specify project for ctrl+., build output, color coding by regex

[TKasparek]

Wish list:

• Ability to edit project files for project templates within the gui. Right now I edit a project files to the relative paths and files I want using wildcards then copy the files section out of a project vpj to the usrprjtemplates.vpt. Works good but is clunky.
• Ability to specify a default for Tag by Workspace/Tag by Project. I always use Tag by Project and I always need to change this.
• Ability to specify which Tag file to use for Go to Definition. (Ctrl+.) I have 20+ variations of the same project in a workspace. Finding the correct one for the active project so I don't muck up another change can be a lot of scrolling to find the same directory.
• Better parsing/separation of build output. When you have a complicated build system that calls many pre and post build functions it can be very difficult to see the information needed. I would like to be able to specify what messages are info/warning/errors using regex as a minimum. There is basic support for this but I can't make heads or tails of it, and I can't see any way to specify info vs. error. It would be nice to classify parts of the build output as certain build step outputs. Like if a regex is matched, it's an info message from X build process. Then allow filtering by message type and/or build process.
• Faster color coding with full symbol.
• 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.

[Clark]

• 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.

[jporkkahtc]

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.

[Clark]

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.

[jporkkahtc]

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.