Plugin system

[Red M]

Hi,

Is there any interest in someone offering a plugin system where by extensions (like the Lua extension) could be loaded into SciTE via a dynamically linked library?

I have recently pulled together a themes system based on someone's work and improved it by integrating LuaRocks into SciTE (called scite_luarocks) but this is janky and feels rather awful because of cross platform support for binary rocks requiring a compiler and very few rocks are pure Lua (or they are pure Lua and are missing functionality)

So I'd like to to integrate Python but not require having to manage my own patchset on top of the mainline repository to do so. So instead I'm starting at step 1 which would be allowing the SciTE Extension interface to load statically compiled libraries by defining them in SciTE config. The syntax would look something like this:

ext.load.$extension_name=$relative_path_to_scite_userhome

Open to suggestions on such a plugin system and I'm not afraid to put in the work and offer my patch to be merged. Also, is there a GitHub repository or if not where is the repository?

[Neil Hodgson]

Red M:

> Is there any interest in someone offering a plugin system where by extensions (like the Lua extension) could be loaded into SciTE via a dynamically linked library?

Sounds reasonable.

> I'm starting at step 1 which would be allowing the SciTE Extension interface to load statically compiled libraries by defining them in SciTE config. The syntax would look something like this:
>
> ext.load.$extension_name=$relative_path_to_scite_userhome

The interfaces in Extender.h may not be sufficiently defined to work between separately compiled executables like a DLL/so and the SciTE application. They haven't been made ABI-safe by declaring calling conventions. There are returns of C++ types (like std::string) that may be defined differently by different standard libraries or even between release and debug builds.

> Open to suggestions on such a plugin system and I'm not afraid to put in the work and offer my patch to be merged. Also, is there a GitHub repository or if not where is the repository?

Its on SourceForge:
https://sourceforge.net/p/scintilla/scite/ci/default/tree/

Neil

[seasoned_geek]

Personally I've never liked any plug-in systems for editors or IDEs. For RedDiamond I put the banning of using the code to create an editor/IDE with plug-ins from it right in the license.

Here's why. 

I'm old. Maybe I've finally hit that cranky old man stage of life? I've just lived long enough to watch this happen time and time and time again.

Take a look at ELPA and MELPA for Emacs.I think ELPA is even split into GNU and non-GNU. Somewhere between 70-90% of those will break the current version of Emacs if you manage to get them to install. At least 40% won't even install because they are for some older version of Emacs and quickly became abandonware. Of those that install, roughly 50% conflict with one or more plug-ins. The global variable space isn't policed, well cared for, or sacred. If you have an 8-12 hour edit session with that editor, many of the plug-ins will just "stop working" for no reason and issue no error. Restart the editor and they seem to behave again.

This isn't an Emacs specific problem. Atom, Sublime Text, even Visual Studio Code/VSCodium have this exact same problem despite their youth. Code::Blocks, CodeLite, QtCreator, the list goes on and on.

Notable exception. Geany seems to keep tight reign on this. Limited number of plug-ins that don't seem to trash each other.