One thing I would like to highlight about the WASI based plugin system is that, on this release we’ve finalised our API design. We call it "Plugin Server Protocol", which includes everything that LSP has and extends it with more stuff that a code editor needs. We hope that "Plugin Server Protocol" can evolve into something great that future code editors can use. It will be win-win-win for editor authors, plugin writers, and users. New editors don't need to start from zero for plugins. Plugin writers write once to support all editors that are compatible with this API. Users have more plugins to choose from.
Thank you for an awesome editor. I've been using it on and off since the first release. It is remarkably fast and you seem to have hit the right spots as far bootstrapping it goes!
I agree with your plug-in philosophy and I'm excited to see where the project goes. It is a very promising editor.
This is a project I'm really excited for. It seems like it has a chance of potentially replacing Sublime Text for me some day, which is something I've been trying to do for a while with zero success.
I worry about the plugin system though. It is using WASI for plugins, so people can use any programming language they want. That seems like it could lead to a horribly fragmented ecosystem. It also means plugins are limited to accessing only the system resources exposed by the WASI runtime, which may make sense for security in, say, a web browser, but for an extensible editor it just feels like an unnecessary obstacle.
IMO, any application for editing/powerusers with a plugin system should be using Python exclusively. Not only is Python available everywhere (and often preinstalled), but it has the richest ecosystem out there that supports the most varied domains. And in the rare cases where a plugin does need to do some number crunching that's too slow in Python, it can be implemented with CFFI using C or any language that can expose a compatible C interface.
Also, the typical systems programming stuff you'd likely need to do in a code editor/IDE plugin are extremely easy to do in Python using nothing more than the standard library. Imagine trying to maintain a set of plugins all using different programming languages and build systems and package managers. That's a maintenance nightmare.
> IMO, any application for editing/powerusers with a plugin system should be using Python exclusively.
While I agree that python is often a good (or even the best) choice, I think the neovim team made a solid argument for lua (easier than C, faster than python).
Would you have chosen python for neovim, and if so, how would you have avoided excessive startup times? (keeping in mind that a terminal-based editor gets started many times throughout the day, as opposed to a GUI editor which you might only start once at the beginning of the day)
EDIT: btw, I wholeheartedly agree about the plugin system. Even with neovim, it's pretty confusing that many plugins are now available in original vimscript versions, or new lua versions. I tend to go with the lua versions, simply because I don't want the mental overhead of understanding two different plugin languages, in cases where I decide to fork and alter the plugin code.
I actually have a mild distaste for Lua after spending about a month and a half using LiteXL (https://lite-xl.com/), which is an editor written entirely in Lua. The thing is a spaghetti mess, with a lot of plugins relying in internal implementation details of core features, and some of them even making changes to the core and other plugins. (but to be fair, that's mostly an issue with the design of LiteXL and not Lua)
The thing I don't like about Lua is that it doesn't really offer much. It's a programming language with practically zero features. Projects end up doing things, like inventing their own class system just to do OOP, and that becomes a problem for interop between projects. Performance is good, but there are other options with good performance. Although I will admit that coroutines are a killer feature of Lua that I wish more languages had.
For the use-case of neovim, idk. I stopped using vim as a main editor many years ago, but I do know what you mean about the concern with startup times. However, I don't think anyone can say Python's startup times are too slow without actual data to back that up. On my machine (with Python 3.10), a simple hello world runs instantly. I'm too lazy to do a proper measurement, but it's nowhere near what I would consider slow.
And idk what neovims plugin ecosystem looks like, but if Python's startup times were a real issue, I don't think I would mind having a persistent daemon to reduce the problem, especially if it means better plugins.
> The thing I don't like about Lua is that it doesn't really offer much. It's a programming language with practically zero features. Projects end up doing things, like inventing their own class system just to do OOP, and that becomes a problem for interop between projects.
I personally see Lua's minimalism as one of its strengths and one of the reasons it's great for plugin systems. OOP is doable if you need it, but really unnecessary anyway.
> And idk what neovims plugin ecosystem looks like, but if Python's startup times were a real issue, I don't think I would mind having a persistent daemon to reduce the problem, especially if it means better plugins.
Python has a huge standard library full of useful general-purpose stuff. The motto "Batteries Included" might sound a bit boring at this point, but it's as true as ever.
I don't think the breadth of the standard library necessarily affects startup time. You only pay the cost for a module when someone imports it, surely.
Yes, true - I didn't word that very well. I believe lua is faster than python mostly due to the simplicity of the language implementation itself, but as another comment pointed out, it might not actually be that big a difference (and I don't have any hard numbers at hand).
Python is and has been a go to language for writing vim plugins. We've seen its limitations in the vim community. The same is true for Javascript and Typescript (which I personally love).
NeoVim picked Lua and every Lua based plugin I've seen has been extremely impressive in its speed.
I don't love Lua - I don't know it so well and find it a little difficult to read and write - but I can't argue with the results. Python is not the right decision nor is JS.
Only other language I could see is rust given its speed, safety, and interoperability with C but Rust also has a lot of ceremony which is great but not as conducive to the plugin author community (a lot of additional overhead).
> Python is and has been a go to language for writing vim plugins. We've seen its limitations in the vim community. The same is true for Javascript and Typescript (which I personally love).
Can you link to any example plugins that are written in either python or js/ts and are considered slow? I'm not doubting you, I'm just not a big vim user, so I'm not familiar with many plugins.
> NeoVim picked Lua and every Lua based plugin I've seen has been extremely impressive in its speed.
I'm sure you're impressed by the perceived speed, but I don't believe you have any real (i.e. data-backed) basis for comparison there. If you do, I'd love to see it.
But to counter your anecdotal evidence with another, Sublime Text only supports Python for its plugin system, and the performance of every plugin I have ever used has been extremely fast. Besides network stuff, I've never even noticed plugin operations, since they all seem to finish instantly.
I believe you complete me was a python plugin. CoC for vim is a LSP client written in typescript which was slow to startup and felt a lot slower than neovim’s native LSP
Slow startups are potentially a language issue (which can be mitigated/eliminated in various ways, especially for a text editor), but I hope you realize that comparing the performance of two completely different implementations doesn't say anything about the language choice.
If the neovim native LSP were a direct translation of the typescript implementation, then that would be useful to compare. However, I doubt that's what happened here since doing that would be a waste of effort. If anything, it's more likely neovim's LSP was designed with knowledge of some of CoC's performance issues in mind (since it pre-dates it).
As for youcompleteme, I don't have too much experience with it. I used it years ago and don't remember any performance problems, although that's anecdotal. Regardless, a completion plugin like that typically relies on a cache built from e.g. clang's compilation database feature, meaning that (after the cache is built) the plugin just needs to access that data structure in response to queries. The design of the cache and implementation of the interface between the client and the server are what will likely determine the bottlenecks, not the raw ops/sec of the Python interpreter.
Nice thing about using WASM for plugins is that you wanted to (for some unknown reason) write a plugin for this editor in Python you could because it can be compiled to WASM.
>>Imagine trying to maintain a set of plugins all using different programming languages and build systems and package managers. That's a maintenance nightmare.
I would imagine once you got all this setup the first time, it wouldn't be that much of a "maintenance nightmare". Literally just running scripts.
> I worry about the plugin system though. It is using WASI for plugins, so people can use any programming language they want. That seems like it could lead to a horribly fragmented ecosystem. It also means plugins are limited to accessing only the system resources exposed by the WASI runtime, which may make sense for security in, say, a web browser, but for an extensible editor it just feels like an unnecessary obstacle.
Contributor here, mainly on the plugin system.
The main reason for using wasi is to have a single runtime to run any plugins on any os. As you mentioned, plugin makers can write their plugins on their favourite languages ( although as of right now no library or wrapper has been done for other languages ), and the end user doesn't have to care. As for the sandboxing part, the only real sandboxing done as of right now is allowing the plugin to only access its own folder.
One of the main features of this release is the new plugin system, which we call PSP. It's designed as a superset of LSP, and extended to the scope of an editor. As PSP is the mandatory way to interact with Lapce for plugins, you could run any kind of binary instead of WASI and it would still work (in fact, there have been talks about allowing user to run binaries as an alternative for WASI based plugins)
There might be another advantage here for WASI: you could write a compiler for, say, VimScript and it would translate to this editor's APIs. Sounds like an interesting project to me.
Lapce is graphical and seems to be aiming for a vscode-like experience, while Helix is a terminal-based editor. They're not really competing in the same space imo.
> Helix's editing model is strongly inspired from vim and kakoune, and a notable difference from vim (and the most striking similarity to kakoune) is that Helix follows the selection → action model. This means that the whatever you are going to act on (a word, a paragraph, a line, etc) is selected first and the action itself (delete, change, yank, etc) comes second. A cursor is simply a single width selection.
I don't have any experience with vim or other alternatives, but after reading that article or seems like kakoune is way better in practice. I wonder why Lapce didn't go with "object -> verb".
I think many would agree that object-verb is the better way, but the vim way is old and more established. I would imagine the sheer number of users would be far more for vim’s model.
That said, it’s a mode that could be introduced in the future as kak-mode I suppose.
How have you been finding Druid? I think it's a difficult start for a lot of people because how often it's changing (and how Xilem may fundamentally change it again in the future). I had a similar issue with iced. Rust GUI is in a weird state right now with no strong options unless you go WebRender or something like Tauri.
Oh - my bad - I thought you were a contributor to Lapce (which apparently uses Druid). Iced looks nice too, but it's missing a lot of core features that I think are pretty crucial (e.g. Multi-windows).
its a tall order to make something like emacs, it may not be a "modern architecture" but when im developing programs for emacs its a far, far better development experience than developing programs in general. lisp repl development is really unparalleled for pleasant development. i wish lisps were more popular, i'd love a job working with a lisp. writing go all day is rotting my brain
Just no. It is easier to write a Lisp program that manipulates or processes a Lisp program than it is for example to write a Rust program that manipulates a Rust program, but that has not bearing on Emacs because Emacs never does that.
Source: have been programming in Emacs Lisp for 30 years.
Not much of a preference there but I have weak feeling that Lisps are the best choice for customisation. Like, what other language has something like defadvice?
This is what i've been searching for, for ages
- Lightweight
- Has necessary features
- Has a nice UI
- Actively maintained
- Small learning curve
- Not much config required
Lapce does not support only three languages. It uses LSP, which means any language with an LSP server should work out of the box. Some work has been done regarding that on this release ( mainly making sure we respect the specification more), leading to making the Julia LSP works. Other LSP already tried and working are : C/CPP, Rust, Go, Python, and if I recall correctly JavaScript too.
The only matter to take care of is to write a plugin to start the LSP server, which can be done in around 30 lines of Rust :)
One thing I would like to highlight about the WASI based plugin system is that, on this release we’ve finalised our API design. We call it "Plugin Server Protocol", which includes everything that LSP has and extends it with more stuff that a code editor needs. We hope that "Plugin Server Protocol" can evolve into something great that future code editors can use. It will be win-win-win for editor authors, plugin writers, and users. New editors don't need to start from zero for plugins. Plugin writers write once to support all editors that are compatible with this API. Users have more plugins to choose from.