Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lapce Editor, Release v0.2.0

github.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: Lapce Editor, Release v0.2.0

#31

Post by Yakei »

bogwog wrote: post #4

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 limi…

> 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)

Re: Lapce Editor, Release v0.2.0

#32

Post by Yakei »

stephc_int13 wrote: post #19

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...

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

Re: Lapce Editor, Release v0.2.0

#33

Post by manaskarekar »

dzhou121 wrote: post #29

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…

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.

Re: Lapce Editor, Release v0.2.0

#34

Post by manaskarekar »

kikki wrote: post #28
manaskarekar wrote: post #27

Earlier quoted context omitted.

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?

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).

> I thought you were a contributor to Lapce

Not yet :)

I keep an eye on https://www.areweguiyet.com/

Re: Lapce Editor, Release v0.2.0

#35

Post by rozgo »

dzhou121 wrote: post #29

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…

Would it be possible to integrate something like bevy_engine as a plugin? For live or low-coding experience and tools.

Re: Lapce Editor, Release v0.2.0

#36

Post by Xevi »

manaskarekar wrote: post #3
cercatrova wrote: post #2

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

> 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 beli…

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".

Re: Lapce Editor, Release v0.2.0

#37

Post by manaskarekar »

Xevi wrote: post #36
manaskarekar wrote: post #3

Earlier quoted context omitted.

> 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 beli…

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.

Re: Lapce Editor, Release v0.2.0

#38

Post by yewenjie »

d_tr wrote: post #24
yewenjie wrote: post #16

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

Out of curiosity, do you have some preferred language in mind for the extensible part? Guile? Something else?

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?

Re: Lapce Editor, Release v0.2.0

#39

Post by hollerith »

vitiral wrote: post #21
yewenjie wrote: post #16

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

Well, to meet that requirement you must first have self editing code. That pretty much leaves you just FORTH or lisp AFAIK

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.

Re: Lapce Editor, Release v0.2.0

#40

Post by bern4444 »

bogwog wrote: post #26
bern4444 wrote: post #22

Earlier quoted context omitted.

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. Pyt…

> 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 ba…

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
Post reply on HN