7 ms·

Lapce Editor, Release v0.2.0

102 points by manaskarekar 4y ago

cercatrova 4y ago
How 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 https://github.com/helix-editor/helix
- manaskarekar 4y ago
  > 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 https://kakoune.org/why-kakoune/why-kakoune.html
  - Xevi 4y ago
    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".
    - manaskarekar 4y ago
      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.
- iza 4y ago
  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.
bogwog 4y ago
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.
- funklute 4y ago
  > 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.
  - frou_dh 4y ago
    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.
yewenjie 4y ago
Can I please have something as extensible as Emacs with real multi-threading and modern architecture? I wonder, is that too much to ask?
- vitiral 4y ago
  Well, to meet that requirement you must first have self editing code. That pretty much leaves you just FORTH or lisp AFAIK
  - hollerith 4y ago
    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.
- phillipcheese 4y ago
  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
- d_tr 4y ago
  Out of curiosity, do you have some preferred language in mind for the extensible part? Guile? Something else?
  - yewenjie 4y ago
    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?
stephc_int13 4y ago
I tried it on Windows 11. - Startup is fast. - Memory usage is a bit high (133MB with no files open) - CPU and GPU usage on idle is weird (25% and 40%) doing nothing, the window is not even displayed... That's unfortunate, that is a pass for now...
- Yakei 4y ago
  hello, lapce contributor here. This is definitely not an expected behavior. Would you mind opening an issue about it?
kikki 4y ago
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.
- manaskarekar 4y ago
  I haven’t used druid, but I’m on the hunt for a good option too. What were your impressions with iced leaving aside the early stage changes?
  - kikki 4y ago
    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).
    - manaskarekar 4y ago
      > I thought you were a contributor to Lapce Not yet :) I keep an eye on https://www.areweguiyet.com/ https://www.areweguiyet.com/
IndigoIncognito 4y ago
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 It only supports 3 languages :(
- Yakei 4y ago
  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 :)
dzhou121 4y ago
Lapce dev here. Thanks for posting this. 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.
- manaskarekar 4y ago
  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.
- rozgo 4y ago
  Would it be possible to integrate something like bevy_engine as a plugin? For live or low-coding experience and tools.

102 points by manaskarekar 4y ago

How 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 https://github.com/helix-editor/helix

manaskarekar 4y ago
> 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 https://kakoune.org/why-kakoune/why-kakoune.html
- Xevi 4y ago
  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".
  - manaskarekar 4y ago
    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.
iza 4y ago
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.

bogwog 4y ago

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.

funklute 4y ago
> 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.
- frou_dh 4y ago
  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.

yewenjie 4y ago

Can I please have something as extensible as Emacs with real multi-threading and modern architecture? I wonder, is that too much to ask?

vitiral 4y ago
Well, to meet that requirement you must first have self editing code. That pretty much leaves you just FORTH or lisp AFAIK
- hollerith 4y ago
  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.
phillipcheese 4y ago
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
d_tr 4y ago
Out of curiosity, do you have some preferred language in mind for the extensible part? Guile? Something else?
- yewenjie 4y ago
  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?

stephc_int13 4y ago

I tried it on Windows 11. - Startup is fast. - Memory usage is a bit high (133MB with no files open) - CPU and GPU usage on idle is weird (25% and 40%) doing nothing, the window is not even displayed... That's unfortunate, that is a pass for now...

Yakei 4y ago
hello, lapce contributor here. This is definitely not an expected behavior. Would you mind opening an issue about it?

kikki 4y ago

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.

manaskarekar 4y ago
I haven’t used druid, but I’m on the hunt for a good option too. What were your impressions with iced leaving aside the early stage changes?
- kikki 4y ago
  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).
  - manaskarekar 4y ago
    > I thought you were a contributor to Lapce Not yet :) I keep an eye on https://www.areweguiyet.com/ https://www.areweguiyet.com/

IndigoIncognito 4y ago

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 It only supports 3 languages :(

Yakei 4y ago
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 :)

dzhou121 4y ago

Lapce dev here. Thanks for posting this. 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.

manaskarekar 4y ago
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.
rozgo 4y ago
Would it be possible to integrate something like bevy_engine as a plugin? For live or low-coding experience and tools.