> Current codebase has a lot of if branches checking for specific languages, > approaching an implementation of this design would likely mean that those > hard-coded checks would want to move to plugin-based approach; that is to be > recognized as some work.
The key thing is the comment above that the design must allow progressive implementation, the current capability is the fallback, and is not intended to be removed for a long time. The intention is to design a mechanism so that no more language specific branches need get added to Geany core. But unless the process of including plugin capability in place of the built-ins can proceed in small chunks it probably isn't going to happen at all, simply due to resource availability. > we could look at how language-specific plugins have been designed&implemented > in other notable editors. Certainly, if anyone wants to chime in with their knowledge (or investigations) of existing editors that will be useful and may be adaptable to Geany. > and I can foresee a situation where Geany gets "stuck" because of plugins Plugins are part of the Geany process and address space, so if they crash or hang so does Geany, thats an unfortunate fact of life. It is very unlikely that will change so plugin devs just have to be careful. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/geany/geany/issues/1458#issuecomment-292705428
