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.

I didn't mean to use it for back up - I meant it as a possibility to get back to the previous version when the autosave feature saves something you don't want to have saved under some special occasions like the power cut you mentioned.

But the UI can be merged and the default argument can continue (so long as my default is used ;-).

That's the way to go :-)

Thats a good reason if we had someone who knew about the language, or has your gopher been stabbed by a dart? 😉

Not using a language ourselves doesn't mean we cannot support it. Nobody knows all the languages there are in Geany - but we have access to the documentation of the languages, we know C/C++ (somewhat in my case), we know Geany internals and if we want to develop a multi-language editor which Geany is, it's more up to us to add support for new languages than someone who has no idea about C and Geany.

Or look at it another way, let's say we want an editor that supports 95% of most used languages. Then by doing nothing this goal starts regressing as new languages are introduced and gain some traction. So I think from time to time is inevitable to add some new language if we want Geany to be an up-to-date multi-language editor.

Because every user has to pay the price of all the languages they do not use.

Hmm, what price is it? If it's about the binary size, the Dart lexer has about 24KB which I think doesn't matter. And to sum up the binary size discussions above, our lexilla has 1.3MB, full Scintilla's lexilla has 3.6MB so even including all language support would add just about 2.3MB (to our 4MB libgeany.so so the total size would be about 6.3MB). I'm all for minimal binary sizes and against bloated software but I think this is totally acceptable.

Some notes about the binaries to avoid confusion: @elextr the sizes you report are binaries with debugging symbols in them - to remove debugging symbols, run strip my_binary.so/a/o. To debug exceptions, templates and other stuff, C++ debugging symbols take up more space than C which is why you see the unstripped ctags binaries much smaller than for Scintilla. Second, as Neil said, code pages are loaded lazily only when needed so the code that isn't executed just sits on the disk. And the same applies also for the huge binaries with debugging symbols where the debugging symbols just sit on the disk until you start debugging the application.

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.

Then I miss the point totally. What's the point of splitting libgeany.so into tons of smaller sos? The only thing I can imagine that could potentially be slow is dynamic linking when the application starts but it matters only for libraries with huge API surfaces (and Scintilla's API pretty much consists of a single function to which you only pass different arguments).

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.

Again, code pages are loaded lazily so not the whole binary is loaded in ram. But even the whole code had to be loaded, it's just 6.3MB with all the lexers. (And I really care about Raspberry Pi performance and test on it - Geany should run fast there but this is just marginal amount of code and doesn't really matter.)

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