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.

What I meant is git has nothing to do with it, almost every file is saved so the compiler can complain about the errors, or some other tool can complain, thats not something to commit to git ;-)

The thing the buffer (not file) save provides is letting the process of making the changes without either autosave writing an unknown partial changed state to the file or the whole lot being lost on crash (and remember its not just power failures, which are rare thankfully, there are regular opportunities for me to accuse users of "crashing" Geany by logging out or shutting down without closing it, a bad habit they got into with VS).

Anyway as I said I'm disappointed that a better solution is not gonna happen, but since I don't have time, and nobody else is willing to do it, then I'm neither for nor against PTF.

Not using a language ourselves doesn't mean we cannot support it. Nobody knows all the languages there are in Geany

You don't??? ;-)

Geany devs can create any filetype, but supporting it well is different. There have been some atrocious highlighting mappings when the person who made them didn't understand the language, similarly there have been some poor categorisation of symbols (usually to C categories, not all languages are C you know ;-), and then there are all the functions hidden away that decide things based on the filetype. Of course Geany devs can create a filetype for any language, but my point is we should have someone who knows the language to provide an input to it rather than treat them all as C.

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.

I already said "So possibly we could simplify the importing of Lexilla by not limiting it.", you are pushing on an open door (or maybe it says 'pull') :-)

And as I said, now I just need the actual evidence for "Now, its just uctags and mappings and the UI and the rest." and I will stop caring about how many filetypes we add.

Then I miss the point totally. What's the point of splitting libgeany.so into tons of smaller sos?

(Note to self, stop thinking onto the page before finishing idea, and to be clear this is nothing to do with size specifically)

My suggestion was that each filetype has a dll, sure the biggest part of them is the lexer and the parser, but also all the various functions hidden around Geany that depend on filetype can either be in config file, or in the dll.

That means everything for a filetype is in one code file plus lexer and parser and a config file, so things don't get missed and checking filetypes is easier. In fact more per filetype features could be supported without adding support overhead, as a simple example a per filetype "autocomplete trigger" function would mean autocomplete would no longer be limited to C/C++ '.' or '->'.

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.

Agreed, and as I said above a quick scan of the Wikipedia alphabetical list of programming languages shows a better spread that way. And the top level doesn't have to be 26 one letter menus, it could be ranges "a-c" "d-i" etc so the range is longer for letters that have few if any Geany filetypes in them.

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.

But reviewing and debugging should be happening in uctags, not in the import to Geany? If its reviewed and benchmarked there (size and speed) then many client projects will benefit.

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