Lapce Editor 0.3 | Hacker News Reader

Lapce Editor 0.3

github.com

222 pointsphilonoist98 comments

I wonder whether it's achievable to have a plugin system similar to how web extensions work where you could write a plugin and have it work across different editors. I see how getting people to move to this editor might depend on people moving over once a sufficient amount of their current editor's features are supported, some of which might be contributed by extensions.

So an interface like LSP but for plugins… very interesting idea!

Text manipulation operations are fairly simple to define and can probably be abstracted away into some generic API. Then writing generic text manipulation plugins should be very doable.

The complexity comes with project management, multiple files, build actions, etc. But you could define language specific sub-interfaces and the plugins would implement them. So a C++ plugin would understand CMake files for example.

The complexity comes with interaction in general. Writing plugins on their own is simple. And defining a good API for most common use cases is also not hard today, as we have enough experience now. But the hard part will be defining an independent Interface which will work everywhere on a satisfying level.

I mean that's basically the biggest selling-point of plugin-systems today. Not that you can write your own functions to do something, but how well you can integrate it into the interface and deliver your own interface to enhance the app. And another part would be safe interaction with other plugins, and necessary package-managment.

>So a C++ plugin would understand CMake files for example.

No one understands CMake files

There seems to be some trend, to outsource plugins into their separate processes, so you can write them in your preferred language. So APIs are already being established here and there. All we probably need is someone carving out a standard from them, with room for editor-specific enhancement, and then convince the projects to support this.

Maybe the neovim-people could get together with other projects, start some group, project, whatever to discuss this further? Of maybe something like this already exists?

Perhaps using WASM via something like https://extism.org/. That would also open it up to building plugins in multiple languages.

Tangential to this I've wondered if it's possible or advisable to have a utility to port VS Code plugins to a plugin that's compatible with the JetBrains IDEs.

> Perhaps using WASM via something like https://extism.org/. That would also open it up to building plugins in multiple languages.

https://github.com/lapce/lapce already says,

> Plugins can be written in programming languages that can compile to the WASI format (C, Rust, AssemblyScript)

so it sounds like they did that?

Maybe we could invent a standard technology for defining interfaces between software pieces. We could call it Interface Definition Language (IDL for short). And then we could have something that brokers requests to those objects to facilitate intercommunication. We could call that an ORB! Finally a good idea!

oh man, we can then build it into the OS and give it a recognizeable name like Component Object Model!

Could we define a common specification for how those brokers should interact with other objects, and call it CORBA?

Yes, why not! But I guess that's too complex, we'd need a simple object access protocol!

OMG, why are we talking about ancient uncool technology?

Jokes aside, there are so many cool standards for doing stuff it's a shame we seem to reinvent the wheel over and over again.

I have an even simpler idea. We can have some kind of protocol header that specifies the size and shape of the structures and functions that can be called using a binary-level interface. Then we can just provide the implementation as machine code where the header maps each callable function to its respective code block. To "return" values, the callables can just push their results onto a "stack" at a known location and return control to the caller.

The bonus is this should be really fast and it doesn't even require any codec or message copying.

Awesome, this looks like an editor I've wanted to have for a while. I'll definitely be trying it out.

Basically it seems to take the good parts from a few other editors and combines them:

It's like VSCode, but without the bloat of electron or Microsoft's telemetry.

It's like sublime text, but it's open source and has first class LSP support.

It's like Neovim, but it doesn't require downloading and configuring a bunch of mystery meat plugins just to get what have been table stakes editor features for decades.

> It's like VSCode, but without the bloat of electron or Microsoft's telemetry.

But isn't the bloat of electron which enables the greatest benefit of VS Code? By which I mean the plugins with their wide range of abilities and UI-integrations.

> It's like sublime text, but it's open source and has first class LSP support.

Sublime has LSP since a while now.

> But isn't the bloat of electron which enables the greatest benefit of VS Code? By which I mean the plugins with their wide range of abilities and UI-integrations.

Maybe for some users. I'm sparing with extensions because I find them hard to vet; I checked and I'm only using clangd and prettier right now. But I don't think Electron is required in order to have rich extensions - just see Vim/Neovim, Emacs, or any IDE.

> Sublime has LSP since a while now.

My bad then. I thought sublime's LSP support came from a third party package.

> But I don't think Electron is required in order to have rich extensions - just see Vim/Neovim, Emacs, or any IDE.

I don't know about IDEs, but I wouldn't put vim & Emacs on the same level as VS Code in terms of interfaces. They go much further than your average text-editor and also grow over time, but at the end they are still text-based interfaces with some fluff. Though, It of course depends strongly on your requirements. For most developers, text with fluff is more than enough.

I mean, aren't there whole web browsers and email clients written inside of Emacs? Isn't there a whole "Emacs is an operating system" joke?

But in any case, I try to avoid bespoke custom editor setups unless there's a situation that really warrants it.

Only one web browser, I think. The w3m package exists, but that's just a communication layer between Emacs and w3m.

> I mean, aren't there whole web browsers and email clients written inside of Emacs?

Depends on your definition of "whole". Those modes work by removing features from the webstack, or by borrowing from external GUIs. Emacs browser w3m for example, is AFAIK unable to handle JavaScript. Electron-apps on the other side offer you whole webstack, including all available components, widgets, libs, frameworks, or whatever. So it's very easy to take some webapp or component and integrate into your workflows. Apps like Emacs are unable of doing this, and thus constantly on a game of fetching up on popular features and services.

I see the limitations of vim an advantage not a disadvantage. Because everything is a buffer and the layout is just windows, the usual keys just work.

It's one of the things I have about "real" IDEs with a vim mode. The one in vscode is pretty good, it's pretty rare I break it when just editing code (mostly '.' not doing what I expect). But everything else doesn't fit the vim model. I have the file manager or something open in the left and I can't reach it with ctrl+h, because it's own weird UI thing not just a split (like it would be in vim).

This is exactly what has always kept me bouncing off of these things.

As a vim user I can reach a sort of uncanny valley where the core editing loop feels "right," but I end up having to fight against all that muscle memory when it comes to using features outside of it.

I had the opposite experience.

Every plugin in nvim required to learn some new different bs shortcut to have basic features. Plus, I ran into plenty of crashes and weird error in some plugins - and performance wasn't always great.

The editing is fine, you can get used to buffer editing - it's everything else which is not polished and feels like a pile of half implemented features.

I don't really keep up with the state of the art of vim, so I don't know what the community has shifted to doing in plugins, but in vim you have to go out of your way to override the base keys in your plugin buffer. I guess that might be more popular now, I don't know.

But the principle I'm talking about applies without any plugins at all. If just do :terminal it'll make a split, you can now switch between whatever you were doing and that terminal the same way you would switch between a regular split.

None of the proper IDEs do that. I can't just look at what's on my screen and do "move focus to the thing below where I am". You need to memorize shortcuts for each bloody tab rather than them being context aware, and I hate it.

> I don't think Electron is required in order to have rich extensions - just see Vim/Neovim, Emacs, or any IDE

At the cost of difficulty. Recently I wrote a VSCode extension myself with zero prior knowledge (shameless plug: https://github.com/CrendKing/universal-format-on-type/), in probably one day. All I needed to study is their extension API that I cared about. No need for learning a whole new language or DSL. Also easy to debug since there is no compilation and little environment setup.

There is a good reason even though everyone acknowledge about Electron's performance cost, everyone is still using it.

I haven't made a vscode extension, but I don't agree that neovim extensions are created with any great difficulty. The lua API is easy to use and well documented. There is a huge ecosystem of neovim extensions precisely because it is so easy to get started.

VS code is reasonably fast, sane defaults and language support, that's why it's popular.

Plugins are overrated and I try not to use them as much as I can.

> It's like VSCode, but without the bloat of electron or Microsoft's telemetry.

Just did a quick comparison on Windows 11 and vscode with hello world uses 400MB but lapce used 900MB :)

I've tried it on Linux, load it with a Rust project, and it only consumes around 100MB. Dunno what happens on Windows though

Definetly a project I'm keeping my eyes on.

The "killer feature" will be the plugin/extension support. Vscode got where its now mostly because of how extendable it is imo.

> Vscode got where its now mostly because of how extendable it is imo.

Every IDE or "code" editor has had some sort of extensions since decades. _Not_ being extensible is a reason to not being successful.

What made VS Code was the LSP and that you can use JS (that "everybody" already knows) to write extensions. The need of Lapce to use a language with manual memory management (to compile to (non GC) WASM) is a problem for general adoption.

It's great but unfortunately the lack of line wrapping[1] has actively prevented me using it.

[1]: https://github.com/lapce/lapce/issues/945

The ticket seems to be describing virtual wrapping. Interesting that this is a strict requirement for you. I’ve personally never used this feature in any editor. I disable it when I can.

Personally, I just find such “long” lines too difficult to navigate.

For personal projects, where I'm in control of column size, this works nicely. Not so much for "work" projects.

> Personally, I just find such “long” lines too difficult to navigate.

This is where line wrapping helps me. It wraps the lines to my preferred column size preventing the horizontal scroll.

The troff style of writing is sentence per line. It makes diffs of prose a lot nicer, but pretty much requires "folding" lines.

That is absolutely right. I downloaded it to try it but luckily I saw this comment and I deleted the install file. I think if someone makes a text editor, they should have the courtesy to say "note: there is no line wrapping in this editor". It's actually a basic expectation that most people have with regard to editors.

Technically, like the person said in the thread "What prevents you from doing it yourself?"

I feel like not having line wrapping is like not having a save function. Yeah technically it's open source but it's a little irritating not to have "NO WRAPPING" in big letters.

This is version 0.3. Calm down.

Related. Others?

Lapce Editor, Release v0.2.0 - https://news.ycombinator.com/item?id=32714191 - Sept 2022 (40 comments)

Lapce – Fast open-source code editor - https://news.ycombinator.com/item?id=30708505 - March 2022 (224 comments)

Show HN: Lapce – open-source code editor inspired by Xi-editor - https://news.ycombinator.com/item?id=30526693 - March 2022 (2 comments)

Lapce – Fast and Powerful Code Editor written in Rust - https://news.ycombinator.com/item?id=29549173 - Dec 2021 (145 comments)

I’ve really liked Lapce for the past 3/4 months I’ve used it, but there’s been a persistent issue that keeps me going back to Lite XL. Pasting huge blocks of text, think 80,000 characters long, breaks it to the point of not being able to open the same file again in the editor. Lite XL doesn’t care and it’s wicked fast with edge cases like that. If Lapce could manage that better, it would be my go to.

> Rewrote in FloemUI

Just had a look at this. It's one of the few that doesn't use jsx-like macros, an major anti-feature in my opinion. The jsx stuff looks fancy, but it completely breaks Rust Analyzer. You might not care about code completion, but good luck resolving the complex type+lifetime issues (that UIs in Rust often have) without hover type.

Kudos for showing scope discipline, that's one I will be keeping an eye on.

> The jsx stuff looks fancy, but it completely breaks Rust Analyzer

That's not inherent of macros, but how the parser of the macro body is written. Ideally, the jsx code would be transformed to correct Rust code even on broken input, then Rust Analyzer would map the tokens from the expansion to the tokens from the source code to have context for IDE features (rename, autocompletion, go to definition, etc).

I wrote some stuff [1]. It's a bit all over the place since I'm very bad at writing. Here's also a thread with Rust Analyzer's developers [2]

[1]: https://blog.emi0x7d1.dev/improving-autocompletion-in-your-r... [2]: https://www.reddit.com/r/rust/comments/16x2kzi/improving_aut...

The problem is that you also sometimes need to inspect output tokens that occur between (or that don't logically map to tokens between) the input tokens. I ran into this with Leptos. It's just a bad idea. Floem shows that you can have something that looks awfully similar to HTML, without the unnecessary complexity (and compile times) of JSX macros.

I've been using this the last year for navigating larger code bases where my usual terminal editor falls a bit short because this looks clean and minimal but has all the IDE navigation features like file system trees and LSP functionality. It's a cool project, and it might be getting to the point where it can be used as the main code editor for a project.

Still not sure what the "killer feature" here is. Is there even one? Or is it just "something like vs code but in Rust and faster and slicker"?

I'd give it a try, but I am very happy using Helix, which is pretty novel in its own right.

I'd say it's either "VS Code, but with better performance / resource usage" or "Sublime Text, but open source"

Not everything has to have a killer feature. It's an oper-source project, not a for-profit startup

this is the one

> You can write a plugin for Lapce with any programing language that compiles to WASI

though faster and slicker than Electron would also be nice. A helix-like as opposed to vim-like mode as well

> A helix-like as opposed to vim-like mode as well

Discussed here: https://github.com/lapce/lapce/issues/281

The killer feature for me is not being an Electron app.

Neither is kate.

Nor vim nor emacs for that matter.

Yup. I use Emacs since 2002 and am pretty happy with it. Never used an Electron-based app and probably never will.

> Or is it just "something like vs code but in Rust and faster and slicker"?

By that logic wasn't the "killer feature" of VSCode just "something like Atom but in Typescript and faster and slicker"?

Code folding is still not supported. It's a dealbreaker for me https://github.com/lapce/lapce/issues/749

I could definitely give this a shot, looks clean as hell. Does it support Ruby?

There’s a language server for Ruby maintained by Shopify so I expect it should support Ruby okay if you have that installed.

I first thought “Another editor, we don’t need that…” but this one actually gets everything even more right than neovim! Plugins on WASM, written entirely in Rust, renders via wgpu, built in Remote Development. Only thing missing is an official built-in package manager, to avoid the mistake neovim did. A non-barebones VSCode like out-of-the-box configuration would be the cherry on top.

I've been keeping an eye on this one. This holds the most promise of replacing vscode for me. Right now, Kate is more mature and stable at the moment. But I think once it gets further along it'll definitely kick the pants off of the other options.

I've tried Lite XL and CudeText and they are both hard to set up and fall far short of Kate and Lapce in terms of UI.

I'm curious, why not Sublime Text? It is better, faster, and more mature than Lapce, LiteXL, Kate, CudaText, and VSCode (although VSCode might have more extensions).

Is it just because it's not free? I bought it, and it has been my most used piece of software by far.

I've heard about Sublime Text but never considered getting it.

The first code editor I ever got any real use out of was vscode. Which until recently was perfect (some feature regressions and issues with crashing.) At this point the last thing I want to do is depend on a proprietary editor.

Would it be feasible to implement a TUI/ncurses mode over the same editor backend and feature set? Think something like the FreePascal TUI IDE, or the Oberon TUI that made HN a couple days ago: https://news.ycombinator.com/item?id=38240333

Looks better than last time I checked. I like the idea and it's getting there.

The preview image shows intellisense covering up 80% of the code with irrelevant suggestions and a compiler error verbosely complaining about code in progress. That much distraction should have a very small visual indicator at the point of focus, just enough to hint the action required to expand if it is actually relevant.

Tried it. Not bad actually, can't see the type annotations from the Rust lsp though. I see one warning so I imagine annotations are at least partially supported.

Also I can't jump to my jumped-from point when pressing "go to definition" via Ctrl+T when using vim bindings.

> #2190: Rewrite with Floem UI

Oh, does it means that it's moving back to wgpu after its earlier switch to OpenGL? Does it means that the problems that were encountered earlier with wgpu has been resolved?

https://github.com/lapce/lapce says,

> Lapce (IPA: /læps/) is written in pure Rust with a UI in Floem. It is designed with Rope Science from the Xi-Editor which makes for lightning-fast computation, and leverages Wgpu for rendering.

So I think it's reasonable to conclude that they did move back.

It feels extremely fast if you compare with vscode, also it looks like it is already usable for some projects, need more time to see if there's some deal breaker for an early adoption.

Looks promising, but not usable for me atm, formatting doesn't seem to work and i also don't find any support for eslint.

weird font rendering on non-retina windows makes this unusable for me.

Promising project, but keyboard internationalization is a mess. It's unusable for those using non-English keyboard layouts.

https://github.com/lapce/lapce/issues/2244

https://github.com/lapce/lapce/issues/1094

https://github.com/lapce/lapce/issues/1689

https://github.com/lapce/lapce/issues/2731

It's at 0.3, cut them some slack.

This is kind of a problem in that it reduces the number of potential early users, testers and ultimately contributors. Sure it is still early in its development process, but it is important work to do in order to gain traction.

As a non-native English speaker who speaks 4 languages, I have almost never found myself using any other language than English in a code editor or IDE. And I never seen anyone who did, except for very occasional editing of localisation data files.

I have seen used (mainly in comments): Japanese, French, German, Dutch, Chinese (don't know if it was TC or SC; if those are even different unicode ranges or whether they are differentiated by font), and, if I remember correctly, Afrikaans. It's also kinda funny and a little off-putting to see English keywords side-by-side with, like, Dutch variable names.

An alternative way of looking at this: a text editor's main job is to turn keys pressed into characters to be inserted in the document and commands to be executed.

So what? It isn’t claiming to be ready, for its main job or otherwise.

I do not see any indication of its "not-readiness" anywhere in the README https://github.com/lapce/lapce or their website: https://lapce.dev/

So while it isn't claiming to be ready, their content does not tell otherwise. Yes, the version is 0.3, but Neovim is at 0.9.

Says pre alpha right at the very top of the website.

Oh, you're right, it's there right above the title "Lightning-fast and Powerful Code Editor". I swear they added that after my post ;)

> Yes, the version is 0.3, but Neovim is at 0.9.

I would argue that that's a fault on neovim's side; I'm sure there's a reason, but I would call it 1.x software.

Oh, that's to be version-comparable to Emacs, which is at version 29. Vim being at 9 is just way too optimistic!

duck and run

Indeed, navigating keyboard internationalization is a rabbit hole within a time-sink. Luckily, in most cases, you can just plop in a library, and it works, but it's probably not that simple here. All the wtf edge cases, plus the quirks of different operating systems and hardware manufacturers—it's the stuff of nightmares.

Keyboard handling is so fundamental that a text editor must deal with it, perfectly, from the beginning. The cited issues aren't merely a severe and high impact bug cluster, but also an inexcusable design defect that disqualifies the whole project; I suppose someone decided to use Rust despite the lack of sufficiently mature input handling libraries.

> Keyboard handling is so fundamental that a text editor must deal with it, perfectly, from the beginning.

That would be nice but in reality it's such a tricky and subtle problem that nobody does it perfectly. All the operating systems and browsers are buggy in different ways, nevermind anything with smaller budgets. The deeper you get into proper text handling, the more you will realize that nobody has solved it.

Perfection is unlikely, but serious developers should aim to be less buggy than the competition and/or limited by operating system and hardware shortcomings.

Handling dead keys and displaying national characters is solved problem and has been since MS-DOS times. It's really not that "tricky and subtle problem" in 2023. Unless one is inventing keyboard handling from scratch again.

That's a very strong opinion about a project that is at 0.3 and is attending to many simultaneous problems, including building their own UI solution.

It's certainly an issue, especially for non-English users, but it doesn't "disqualify the whole project"; it just means that's not what they're prioritising at this time.

Prioritising glamorous and interesting aspects like plugins and "their own UI solution" over boring correctness is not the way to deliver a good text editor.

I'm not going to criticize them but being able to type with my keyboard is pretty high in my list of requirements for a text editor :D

I'm sure contributions are welcome to solve the problem

Please, contribute to discussion at least.

I want an "I'm adult" switch, which will stop bombing me with popups until I press Tab (for completion) or F1 (for help).

It's unusable, because it distracts on almost every keypress with popups, type hints, and additional characters inserted. Sometimes, these popups even block the CODE I working on. It similar to browsing without an ad-blocker.

I want a helpful and predictable editor, not a kaleidoscope. I don't want to think "hey, what happened?" after a key press.

I can't speak for this particular editor, but Visual Studio once shipped with a mode for C# I think it was, that was like a neon light show. It was unbearable. Also SSMS it has full-on intellisense or nothing at all, and having it on; it just gets in the way. It's like MS only know "my way or the highway".

I realise this is tangential to the subject but I think it bears repeating: respect the user.

Does it try to help you type "if" once you press 'i' ? I find it really weird that (some) code editors do that. Also adding )}] after I type ({ or [, and even worse a second " or ' after I type one " or '. I realise there are ways of turning this sort of thing off (usually), but I miss the days when such things never ever happened.

Edit: I just looked at the project's main website and the auto help provided half way through typing "self" which they are obviously very proud of looks like my worst nightmare. A few weekends back I did some "unplugged" C programming just with Notepad++ rather than Visual Studio and honestly I felt it was a key step to overcoming the migraine issues I've been having lately.

I like autopairs (as those are called) but I really hate it when I type the terminator and the editor inserts another terminator. That's why I gave up on VS Codium after giving it a second try.

Syntax highlighting? Aaaaaand... it's gone!

Does this mean you are rejecting it because it has syntax highlighting? It has theme support so you can absolutely turn that off if you’d like.

No, that would be crazy. Ofc I want syntax highlighting. There's a bug in the newest version which removes syntax highlighting. I thought it's more common, so I understand that probably most are not understanding my comment. https://github.com/lapce/lapce/issues/2747

Reply on news.ycombinator.com