design must allow progressive implementation [...] 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.

Couldn't agree more, so I'd say let's staple this approach as the way to go.

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.

I will check around and report back if I find anything comparable/useful.

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.

Yeah, this is a too fundamental aspect of Geany and I would not even think of changing it in any way (IMO it is the basis of being "Lite" and fast too). However, the moment a corpus of new plugins emerges (external or official) we might want to define testsuites to catch rogue plugin behavior situations and not necessarily at UI-level as I was hinting in #1462.

The reason I am mentioning this is - from my tiny experience with #1457 - that the moment I coded a synchronous call to an external command I knew a "sin" was being done, in the sense that potentially Geany would become stuck when the external process becomes rogue. And as you said, no safeguard would be in place for this even with the plugins system.

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