Lapce Editor, Release v0.2.0
github.com
Lapce Editor, Release v0.2.0
1–10 of 41 posts
Re: Lapce Editor, Release v0.2.0
#2How does Lapce compare to Helix, also written in Rust, is modal like Vim, has a built in LSP with sane defaults, etc?
Re: Lapce Editor, Release v0.2.0
#3How does Lapce compare to Helix, also written in Rust, is modal like Vim, has a built in LSP with sane defaults, etc? https://github.com/helix-editor/helix
> 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 believe Lapce follows the original vim model.
For further reading about the object-verb model: https://kakoune.org/why-kakoune/why-kakoune.html
Re: Lapce Editor, Release v0.2.0
#4This 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.
Re: Lapce Editor, Release v0.2.0
#5This 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 limi…
> 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.
Re: Lapce Editor, Release v0.2.0
#6This 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 limi…
> 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 st…
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.
Re: Lapce Editor, Release v0.2.0
#7Earlier quoted context omitted.
> 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 st…
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 wasn't disputing that though. However, because of the batteries included, it has significantly more overhead than lua.
Re: Lapce Editor, Release v0.2.0
#8Earlier quoted context omitted.
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 wasn't disputing that though. However, because of the batteries included, it has significantly more overhead than lua.
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.
Re: Lapce Editor, Release v0.2.0
#9How does Lapce compare to Helix, also written in Rust, is modal like Vim, has a built in LSP with sane defaults, etc? https://github.com/helix-editor/helix
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.
Re: Lapce Editor, Release v0.2.0
#10This 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 limi…
> 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 st…
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.