Edit: to be clear binary size == memory to load it into, plus there is heap memory used as well as a filetype and lexer and parser is created, but really all that needs actual benchmarking.

To be clear, not ;-). See above.

And of course the UI is cluttered by all filetypes ATM, and there have been reports of the filetype menus being too big for small screens, which is unfixable since menus can't be scrolled onto the screen. It has been suggested to fold those menus alphabetically, see my link to wikipedia above to see that would be better.

I agree about the file type menu size problem (Geany seems to support too many "Programming languages" ;-) but this cannot be an argument for stopping support for new languages. Personally, I'd split the menu into alphabetic groups - I don't see any better option there.

Some of the paranoia was triggered by the request to include the uctags peg parser for TOML and kotlin, TOML compiles into 5000 lines of C but kotlin compiles into over 20000 lines, but I guess again we need benchmarks how big they are compiled.

For me the "paranoia" was not about "20000 lines of code" but about "unreviewable, autogenerated, impossible to debug, impossible to say what performance characteristics it has 20000 lines of code". Not about binary size at all on my side.

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