[HN Gopher] Lapce Editor, Release v0.2.0
___________________________________________________________________
Lapce Editor, Release v0.2.0
Author : manaskarekar
Score : 77 points
Date : 2022-09-04 15:39 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| stephc_int13 wrote:
| 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 wrote:
| hello, lapce contributor here. This is definitely not an
| expected behavior. Would you mind opening an issue about it?
| kikki wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > I thought you were a contributor to Lapce
|
| Not yet :)
|
| I keep an eye on https://www.areweguiyet.com/
| yewenjie wrote:
| Can I please have something as extensible as Emacs with real
| multi-threading and modern architecture? I wonder, is that too
| much to ask?
| d_tr wrote:
| Out of curiosity, do you have some preferred language in mind
| for the extensible part? Guile? Something else?
| phillipcheese wrote:
| 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
| vitiral wrote:
| Well, to meet that requirement you must first have self editing
| code. That pretty much leaves you just FORTH or lisp AFAIK
| cercatrova wrote:
| 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
| manaskarekar wrote:
| > 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
| iza wrote:
| 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 wrote:
| 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.
| Yakei wrote:
| > 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)
| bern4444 wrote:
| 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).
| bogwog wrote:
| > 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.
| funklute wrote:
| > 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.
| kbd wrote:
| > how would you have avoided excessive startup times?
|
| I don't think it's a problem? kitty terminal is programmed
| half in Python and is fast.
| bogwog wrote:
| 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.
| funklute wrote:
| > 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.
|
| That's a very good point!
| keb_ wrote:
| > 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.
| frou_dh wrote:
| 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.
| funklute wrote:
| I wasn't disputing that though. However, because of the
| batteries included, it has significantly more overhead than
| lua.
| frou_dh wrote:
| 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.
| funklute wrote:
| 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).
| haolez wrote:
| 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.
| rstat1 wrote:
| 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.
| bogwog wrote:
| > 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.
|
| Famous last words
| IndigoIncognito wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2022-09-04 23:01 UTC)