This seems to have gone very quiet for a while so given that the discussion has weaved over many topics it seems worth summarising before its all forgotten.

Persistent temp files: to me would have been nice if it was subsumed by the "backup modified buffers" suggestion but as that is unlikely to happen "soon" no objections to it.
LSP is in Geany, only the plugin geany/geany-plugins#1331 waiting input, should probably be merged.
Zoom, awaiting Scintilla upgrade, but no objections AFAICT
Multi cursor support, set keyboard shortcuts on Linux with my desktop Cinnamon compatible defaults ;-P, no other problems delaying it AFAIK.
Toml #3934 needs to be merged, further improvements can be subsequent
Consistent Notebook wheel tab change behaviour, needs #3469 merge, no other objections AFAIK
Change the default button on the search wrap dialog, no objections but nothing done yet, since the dialog can be avoided by selecting "always wrap" its not high importance IMO.
Dart, either merge #3968 which is a custom filetype, or wait for Scintilla update that includes Dart lexer and make built-in filetype
Zig, waiting for updated Scintilla

The questions about having more and more filetypes, overhead, menu, filetype organisation, and Geany organisation are woven through the issue posts.

Overhead, actual data changed my view:
- for me Lexilla is no longer a problem (in fact it could even be possible to include all Lexilla) after the size number I was using was corrected by @nyamatongwe
- for me Ctags size so far is no problem, @techee raised issues about size and speed of the PEG parsers for Toml and Kotlin but data indicates that the compiled size is not excessive IMO, @rdipardo has indicated that the Kotlin parser is ok for their usage, and I am less concerned about speed now the built-in parser can be disabled from the filetype file if a user finds it too slow
Menu: this is the only remaining problem with adding more filetypes AFAICT, everything goes in the "Programming" submenu which is already too large, seems general agreement that the menu should be arranged by name in alphabetic ranges. The ranges can be chosen to make each sub-menu about the same size. Question should this change happen before more filetypes are added to avoid making the menu even bigger?
Filetype organisation: there appears to have been many misunderstandings about the proposal of filetype DLLs and discussion, it is not to be implemented as part of this, but the more filetypes are added the more is subject to any re-organisation and thats why it was raised here. Will raise a new issue.
Geany organisation: it was suggested that a method of recording contributors who know the filetype and who volunteer to advise and suggest for its support. That way when something is raised by filetype users, Geany devs have someone to ping for their expertise. I think this may have been overinterpreted, just a file such as filetype_support.md in the top level was all that was intended, but probably badly communicated. Will raise new issue.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.