Don't worry, just sit quietly in a dark room and the feeling will soon pass 😜
I feel I need to lock myself in the cellar for one year to achieve this :-)
The "persistent temp files" (PTF) is rather disappointing to me having been saved by nice vscode when there was a power cut. What vscode provides is intermittent saves of all modified buffers (and not over the top of the original files like autosave does), and the ability to restore buffers to the same modified state they were. This would cover the limited PTF feature as well. Safety and a new feature, what more could you want?
Sure, would be nice to have but it's a big project that would mean rewriting the majority of session handling in Geany and I'm not sure if anyone is ever going to do that. So I'd go for what we can have now easily - autosave pretty much simulates the file restore by overwriting original files (IMO doesn't matter much for properly VCS'd files) and the "persistent temp files" feature handles unnamed documents.
Multiple carets, no right answers about clashes of keycodes on different platforms and desktops yet.
IMO we have the right answer - configurable click-bindings which for symbol goto and rectangular selection default to the same value as before and for multiple cursor just something reasonable that can be changed when it conflicts with something else.
Wrap search on not found, there is a preference to automatically wrap search, so AFAICT https://github.com/geany/geany/issues/1192 (ignoring the hijacks) is done.
When you look at it, it's about something different - it's about the case when you see the popup dialog. In that dialog, the Cancel button is default that gets selected when pressing enter - and it would make more sense if Find was the default button. I can imagine that people want to be informed about the fact that they reached the end of the document and see this popup but be able to quickly wrap by only pressing Enter.
Only one query for dart since 2014 doesn't seem much support for adding yet another built in language. Just because you added it to Lexilla isn't an argument to build a wasted language to Geany 😜 .
See #371 (which has 5 thumbs up), #3313, and pull requests #379, #3372.
In Scintilla, issues sorted by thumbs up reaction are https://github.com/ScintillaOrg/lexilla/issues?q=is%3Aissue+is%3Aopen+sort%3...
In Notepad++ it's the most requested language: https://github.com/notepad-plus-plus/notepad-plus-plus/issues/651
Dart seems to be number 17 language based on the PR number metric: https://madnight.github.io/githut/#/pull_requests/2024/1
So I simply think that Geany should support it.
Same goes for zig.
Zig is indeed probably a different case, this is the first time I heard about it but it appears like quite a nice language and there seem to be relatively big projects using Zig on github and I don't see a reason why it shouldn't be supported by Geany.
What would be better than keeping adding built in stuff would be a @techee minor 100000000 or so line change that allows lexillas and ctags parsers and the language configuration to be in plugins so the cost of low traction languages isn't imposed on everybody (or dlls with different API if appropriate, eg IIUC Lexilla allows for that) ... now thats something for you to get your teeth into 😁
This is exactly the opposite of what this meta-issue tries to solve - real user's problems. I haven't seen a single user asking: "Please, modify Geany so I have to download language support from all around github and compile it myself" ;-). I think this is a fundamentally wrong approach.
What would be much better instead is to have all the lexilla configuration (that we currently hard-code) defined dynamically in configuration files and possibly link all the lexers present in Scintilla even if we don't use them right now. This would allow users to add support for their languages just by modifying the config files and referencing the linked lexers by IDs. The benefits would be: 1. Editing config files is much easier, especially for beginning programmers and people using something else than C (there's a kind of chicken and egg problem where we know C but don't know the language whose support is being added and the person wanting the support of the language he knows doesn't know C). We could get more contributions this way and do less work ourselves. 2. Given our frequency of releases, users could be advised to update the config files in a certain way if there are some problems or to grab some config files from the Geany repository when there's a support of a new language. 3. New/updated lexers would be properly upstreamed to lexilla (because we'd only support those) instead of some forks at random places at github and filetype config files would be sent to Geany.