While working with a grammar of my own I tried a sample code that resulted in just shy of 18,000 graph nodes and noticed that the Microsoft's graph viewer locks up the UI while trying to paint so many. So, given that 18K nodes isn't useful anyway, nor is even 1,000, I'm going to add a maxNodeRender setting in the configuration. The default will start at 500. The tree view portion will still render so you can simply click the subset of the tree you wish to graph as normal and get something more usable that also doesn't spike your CPU and lock up the UI for 10 seconds. I should have a release with this soon.
I would like to create a vsix installer to make installation of Grun.Net and usage within Visual Studio as simple as possible. Unfortunately, this is outside my area of expertise so I shall hope for assistance from the community.
The current method for extracting the parser rules can sometimes result in them being in the wrong order and thus getting mismatched to the graph node names. This will be fixed in the next release later today.
Grun.Net does not seem to work with a net472 assembly built against Antlr4.Runtime.Standard v4.8. At assembly.GetTypes(), line 83, Scanner.c "Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information" Note: Antlr4cs is several versions behind the current Antlr code base, now 4.8. Version 4.6.6 in the Antlr4 code tree was last updated a year ago, but forked from 4.6, which was released in 2016! 4.7 was released in 2017. 4.8 was released a few months ago. The Antlr4cs code hasn't been updated by Harwell for over a year, and unclear if he is maintaining that codebase now. Other than that and a few minor problems (lexer error messages are not displayed, selection of input or tokens not reflected in selection in tree), the code works well.
Add the ability for the user to fully customize the colors used in heuristic syntax highlighting as well as the graph window. This should help make the tool as friendly to color blind users as well as those who just don't like the default colors.
It occurs to me that while locking the assembly for the console app isn't a big deal, it certainly is for the GrunWin tool, which presumably a developer will have open and running while they are making changes to their grammar, recompiling and re-testing. Given this, the assembly loading logic needs to use an AppDomain so that it can be dumped and reloaded on demand.
Add click support so that the user may click on any parser error and select the text in the code editor window that corresponds to the error that was clicked on.
Add click support so that the user may click on any parser tree node and select the text in the code editor window that corresponds to the node that was clicked on.
With a large enough sample of code the constant rebuilding of the parse tree graph can slow the editor down. While this sin't unexpected under the current design, it is something that should be fixed before a full release. It will simply take some basic threading magic.
GrunWin should be modified to detect changes to the loaded grammar assembly and then reload the assembly in response. This will make grammar testing more seamless and easy for the user.
When a source code line would be forced to wrap in the console, the syntax highlighting breaks badly. The syntax highlight code in the console needs to be modified to detect line wrapping.
Add support to drag and drop assemblies and source code files to GrunWin. If an assembly is dropped onto the form, it should find all ANTLR grammars within the assembly and then load the grammar if there is only one. If there are multiple grammars, the the user should be prompted which grammar to load. Any non-assembly file should be inspected to see if it appears to be valid ascii source. If so, then the contents should be loaded into the code editor window.
Add click support so that the user may click on any token line and select the text in the code editor window that corresponds to the token that was clicked on.
I inadvertently broke line number displays in a build without noticing it. I will have this fixed shortly with a fixed build released for both versions.
The editor should support intuitive selection of token colors and add syntax highlighting to any grammar by default. The default colors may or may not make some folks happy. To address this, the editor should support dynamic loading of any IEditorGuide instances in the target assembly or any other assemblies in the same folder or in a "Guides" folder within the GrunWin directory itself. GrunWin will attempt to find an IEditorGuide that matches the current grammar and use it in place of the default intuitive highlighting behavior.
I need to refactor the project design to abstract all dependencies on the Antlr4 runtime assemblies. This will allow it to have different providers for different runtime versions all supported in the same tool.