Making your own plugins for ecode?

[emeraldtip]

I'm guessing that right now there's no way to create and integrate your own plugins (other than writing them into source and then compiling ecode?), cause an improved plugin system is listed as a planned feature.

• Would the improved plugin system also give users the ability to write their own plugins?

If so:

• How would user-written plugins interface with ecode? (apparently "ecode implements an internal protocol that allow plugins to communicate with each other" (and with the editor itself aswell?) "The LSP protocol is going to be used as a base to implement the plugin communication" (does the editor still use some internal protocol or is the internal protocol the LSP protocol? (also doesn't LSP stand for language server protocol so LSP protocol would be language server protocol protocol?) But how would communications through LSP and ecode work?)
• Any plans for an integrated "plugin store", where plugins could be downloaded without exiting the application (this would also include a website or something like that, where users could upload community-made plugins)?

[SpartanJ]

I'm guessing that right now there's no way to create and integrate your own plugins (other than writing them into source and then compiling ecode?), cause an improved plugin system is listed as a planned feature.

That's correct. But, it's intentional, I don't believe the vscode model works the way I would want it to. Basically if there's no control over the quality of the plugins you could end up with a barely working Frankenstein. I think that the best way to avoid that is allowing anyone to contribute to the code base but having some control over the quality of the plugins. But it's something I'm willing to discuss.

Would the improved plugin system also give users the ability to write their own plugins?

Yes, but I don't think I will work on a non-native / compiled code plugin system any time soon.

How would user-written plugins interface with ecode?

The same way any plugin currently interacts with the editor. There's a big interface that allows you to implement things on top of the editors. For reference, this is the interface. Then there's a base implementation of a plugin here. Plugins are not that hard to implement but it's not that easy, the idea of plugins is that they need to work mostly asynchronously, so that adds some complexity. But there are not real limitations of implementing them synchronously (I can't do much about it given the interface design). So that's one of the things I would like to "control" if anyone wants to contribute.

does the editor still use some internal protocol or is the internal protocol the LSP protocol?

It does implement a rudimentary system of message passing between plugins to be able to do some communication between plugins and also to some sub-systems in the editor. But they usually end up being not so generic. This is all done to avoid complexity and the re-implementation of similar functionalities (for example, the global search sub-system is being used to display the results of a global symbol search, that it's done by the LSP client). But, most of the plugins will not need anything like that. Communication between plugins is something that I don't think it exists in other more customizable editors, since plugins depending on other plugins creates a problem hard to maintain.

Any plans for an integrated "plugin store", where plugins could be downloaded without exiting the application (this would also include a website or something like that, where users could upload community-made plugins)?

In order to be able to offer something like that, plugins would need to be non-native / compiled code. So first it would require to expose the API to other language, probably something like Lua or may be using WASI (which I think if would be more feasible). But that is a huge effort, I cannot do it alone. I think I like the lapce approach

As of now my priority is implementing debugger support via DAP. I'm using ecode as my main editor many hours a day but I still need to run some other editor or gdb to debug, which is inconvenient. I want to be able to do all my work with ecode. But I still haven't find the right moment to start that. Then probably I'll add a small Git plugin to do some basic stuffs (actually the only thing I need right need is a git-blame integration).

After that my whole needs from an editor will be covered and I would be able to start to think in adding features that could be great for other users. What I need is collaborators and people getting involved with the development, but I find it really hard to sell the editor given the amount of options that are in the market. So I'm not sure how what to do in that regard. Meanwhile I continue developing because I actually need the editor to improve for my needs. And for some reason I never found any editor that feels "right" for me. Next release should be here soon but it's an stabilization release, almost no new features, I've working in improving the performance of the code base (around +80% better rendering performance, faster syntax highlighting, faster initialization times and reduced memory footprint, but it was not really necessary, I just enjoy working on improving performance).

[emeraldtip]

I would be interested in collaborating to ecode, but there are 2 factors that stop me from doing that right now:

1. The code I write is complete ass
2. I have almost 0 experience with cpp

Getting even better performance from an already performant text editor was something I wasn't expecting (I mean this thing is snappy even on my 10 year old dual-core i3 laptop with an HDD for a drive). (Maybe it's because most of the IDEs I've been using so far have been electron based)

[SpartanJ]

I absolutely understand the issue. Also the code-base at this point is huge and complex, because it's not only the editor but the whole GUI and framework are custom. So I would probably need to attract some people to use the GUI first (and it's something I'm not promoting, but I still continue working very actively on improving it, but I have very limited time). The other huge problem is that people is not interested in doing C++ during his free time, they usually try to experiment with some new fancy and cool languages (Rust, Zig, Nim, Odin, etc), and I totally get it. So the only real alternative is providing a bridge so the people can use any of those languages to develop plugins, that would be possible using WASM / WASI modules.

The code I write is complete ass

There are some stuff that are not complex to develop, but take time, for example, a Git Blame plugin should be quite trivial.

Getting even better performance from an already performant text editor was something I wasn't expecting (I mean this thing is snappy even on my 10 year old dual-core i3 laptop with an HDD for a drive). (Maybe it's because most of the IDEs I've been using so far have been electron based)

Yeah, it was probably not needed, but my argument is that if I want to keep adding features and keep the editor as snappy as it is now, I need to get some room for the new stuff. Also, there are or at least were some occasions where you could find some hiccups (I'm pretty sure there are still several, but nothing really important).

[emeraldtip]

If I have time I'll try to get some basic gui thing working with eepp and if that works I'll see what I can do