@techee :
mean rewriting the majority of session handling in Geany
yeah, but might make it waaaaaay simpler, anyway, ATM if you aren't gonna do it probably won't happen :disappointed:
As I said I'm disappointed, not against PTF, but it does make one more thing to remove when it is done right.
Oh, and "proper" VCS-ing does not mean committing intermediate changes for backups, unlike Geany's git a "proper" VCS is buildable at every commit and preferably even runnable, that way `git blame` will work. So saving backups is back in Geany's court.
IMO we have the right answer
We should be able to distinguish platforms, so can set win and mac, but there is still conflict between Linux desktops, and common ones like Gnome and Cinnamon not just obscure ones. But the UI can be merged and the default argument can continue (so long as _my_ default is used ;-).
When you look at it, it's about something different
Well the preference means the user never sees the popup, but anyway changing the popup default button S/B fine.
Dart seems to be number 17 language
Thats a good reason if we had someone who knew about the language, or has your gopher been stabbed by a dart? :wink:
What we should have is a language champion for each language supported by Geany. @b4n for C. @techee for Go. @elextr for C++. Who else? This is not for coding, but for advice on language issues, sensible mappings for Lexilla, LSP etc.
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
:egg:zactly.
But thats a problem everywhere, for vscode they need typescript, for emacs they need lisp, for others they need C or C++. Thats where all the regexen lexers come from, they don't need code, just some arcane weird version of regex plus the proprietary extensions because pure regex isn't enough. But as you say, at least its only editing a text file not rebuilding the source. But then the speed issue exists. And parsers are not supportable purely in configuration, but maybe you could invent a JIT PEG compiler?
I don't see a reason why it shouldn't be supported by Geany.
Because __every__ user has to pay the price of all the languages they do not use.
Maybe you want to support some more "nice" languages https://en.wikipedia.org/wiki/List_of_programming_languages? :grin:
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 are you talking about? Where did I say anything like that? You seem to have have fundamentally misunderstood the suggestion and projected your worst nightmare onto it.
It is the job of software engineers of a general tool to convert user requests into sensible implementations that make the application suitable for a range of use-cases. No user says "I want a Lexilla highlighter and a ctags parser and highlightingmappings and ..." thats our job, the user just says "I want Zag[^1]".
All I am suggesting is that the Lexilla highlighter and the ctags parser and the mappings be provided in a dll instead of built in like now. They won't be "from all around github" but from the Geany project.
lexilla configuration (that we currently hard-code) defined dynamically in configuration files
Totally agree, I just said "in the dll" so this change doesn't have to be done as well although it could be. It is something that should be done separately in any case. But no user will ask for it :smiling_imp:
But if it is done the config can also say `lexerparser=geanyzag.so` to load the lexer and parser. As I keep saying it is not good software design to compile everything in, making all users, even those on Raspberry Pi, pay for lexers and parsers that are not used by them.
[^1]: fictitious example language