On Thu, 29 Jun 2023 at 07:58, Andreas Schöller via Devel devel@lists.geany.org wrote:
Hello Geany developers,
i know i’m late to the party and its gotten quite on this list. Is there any development going on ?
It mostly uses github for development discussion now.
In 2016 there was a long discussion about the Symbols-View and possible changes to the TagManager - it seems there have been no changes since september 2016 ?
Best for you to look at the github history, there have been a number of changes in symbols and so on, but the overall architecture has not changed.
I’m asking because i'd like to add some language support for the Nim language. Its a small community - i’d estimate less than one tenth of the Smalltalk-community. Looking at how things should be done, i learned a Scintilla-Lexer must be done, that might or might not get included upstream depending on the size of the community.
Perhaps you should have checked, Lexilla already has a Nim lexer. It hasn't had a substantive change in 4 years, so either its really good, or nobody is maintaining it. But you can add a language to Geany that only has a lexer, IIRC there are several. Of course that doesn't solve symbols.
Then for Geany a parser is required that provides the CTags/Exuberant-Tags or the non-compatible Geany-Tags for Geany. Fair enough - Nim is a not easy to parse language and actually i’m using the default support, which uses the Python-parser. The only thing lacking is a proper symbol-view. As pragmatic as i tackle things, i guess that requires a compiler/dev-setup for everything Geany plus Scintilla and may be Exuberant-Tags - and i’m on a Mac - so this is not an option.
Its possible to build Geany on Mac, see the geany/geany_OSX repo, but yeah the process is Linux centric, thats where the contributors are.
During your long discussion about restructuring or opening up the CTag-mechanism to Plugins, i learned that this involves many performance issues around huge loads of AST generated tags for intelligent IDE-support etc. pp. Thats all not needed on my side - since i’m coming form VS-Code and help me god - i don’t need any more smart-stuff popping up around me, forcing me to dig into mile-long JSON-cfg-files to turn it off somehow. And the super-smart background memory-hogs that eat up all resources bringing the entire system to a halt - i’m done with that, too.
Many IDEs (like Vscode) these days are moving to Language Server Processes to provide parsing and semantic information. Since there is a standard for that interface LSPs can be supplied by language projects so they usually use compiler gubbins and so stay up to date. There has been discussion about adding the capability for Geany to talk to LSPs, and there was an initial attempt, but that showed the the size of the changes, so nobody has offered to do it.
Writing a cmd-line tool that populates the symbol-view with struct-infos, procedures and Enums to get a sorted overview would take me an afternoon using the compiler-tools that are already part of my setup. I can also provide CTag-compatible tags - but right now i need to smuggle them into a geany-project and they only provide completion-support - they don’t show up in the symbol-view.
I am not sure what you mean by "smuggle", you can have tag files loaded automatically or Tools->Load Tags File if you don't want it automatic. Since the tags files are normally used for language libraries, having them all show in the symbols pane would flood the user symbols into invisibility and uselessness. Project plugins like Project Organiser generate and load additional tags for a project, but again it needs the uctags parser to do so.
I’d wish for a option in a language-format-cfg, that allows me to name a cmd-line-tool that provides the tags for the symbol-view.
This is the definition of an LSP, but "somebody" has to add the capability to Geany, as noted above. The LSP could of course be used with other editor/IDEs until its added to geany, and could use the actual Nim parser internals, a good Nim community project??
Cheers Lex
In any format that Geany likes best - including the undocumented binary TagManager-format. Without stressing the rest of the Tag-Management-System in the background. It does not need to rebuild the tag-list on-every-keystroke and it must not try to read/incorporate other files that might belong to a project - it shall just care for the one file in the current Viewport. I think there is already a command to refresh the symbol-outline manually ? Would that be possible and might that help other smaller communities to get around the Scintilla/C-Parser/Excuberant-Tags-thingy-challenge ?
Any comments are welcome, thx for making Geany, greets Andreas
Devel mailing list -- devel@lists.geany.org To unsubscribe send an email to devel-leave@lists.geany.org