Lapce – Fast open-source code editor | Hacker News Reader

Lapce – Fast open-source code editor

lapce.dev

538 pointsmaximilianroos224 comments

Author here. Thanks for all the feedback.

I'm aware that Lapce lacks lots of basic stuff. It's a personal project so the initial set of features and key bindings are tight to my personal preferences.

I'm currently working on the missing pieces, like multi cursor support(in master but not released yet), mouse support, sane default key bindings(probably I'll stick to an existing editor), basic UX etc.

Feel free to submit a feature request or bug report in Github Issues or leave your feedback here.

Valiant effort and impressive personal project!

> I'm currently working on the missing pieces, like multi cursor support(in master but not released yet), mouse support, sane default key bindings(probably I'll stick to an existing editor), basic UX etc.

Website claims "Native GUI" but this is not native GUI. I'd rather have basic UX before multi cursor or anything else nice to have but totally optional things. On Windows open dialog is broken, you can't select drives, you have to enter the drive letter manually, but in input field delete key is not working. That's as far as I got trying it out.

Maybe the author should use a library like native-dialog (https://crates.io/crates/native-dialog) for these rather than making a file picker from scratch in Druid (the current Rust UI framework).

It is refreshing to see a new code editor, even with minimal set of features that feels fresh and fast. Thanks for putting it out there. Please please please keep that responsive experience and don't trade it off for a full set of features that will make this tool lose its charm and become just the same as the rest of the powerful tools.

Thanks for your kind words.

It will, it's in the DNA. L comes before P.

Awesome.

> " L comes before P."

LAPCE == Lightning-fast and Powerful Code Editor

I.e. Lightning-fast comes before Powerful.

ty (much kinder res than "rtfa" which I clearly didn't)

slainte!

Extremely impressive for a personal project! Great job, if it were mine, I'd be exceptionally proud of it.

I think the heat you're getting here is from the very slick website that makes Lapce look more finished than it is. It might be a good idea to adjust the text to manage people's expectations.

Great job!

I think you're right on the heat front. It's probably causing a form of dissonance with some people.

First thing I tried was ctrl+shift+f to grep through a project, which didn't work. I see the functionality is there, though. Both Intellij and vscode uses this shortcut, so harmonizing with them would be nice. Also the code completions are not clickable with a mouse, and using the "down" key also doesn't do anything.

Anyway, development-wise these are minor issues in a project of this size. Nice work!

> Also the code completions are not clickable with a mouse, and using the "down" key also doesn't do anything.

Yeah, unfortunately it seems like there's a (possibly recently introduced?) bug that appears to break arrow-key/list interactions.

I was able to get code completion & command palettes to work by supplying a custom keymap I posted here: https://github.com/lapce/lapce/issues/133#issuecomment-10715...

My impression is that the non-modal keymap isn't as regularly updated given the developer's preference for modal interaction. I'm happy enough I can at least still edit the keymap to workaround the issue. :D

Off Topic: https://www.lapce.dev has a certificate issue. Also, the editor does not seem to run on Windows 7 ("createpseudoconsole could not be located" in KERNEL32.dll)

> Windows 7

is EOL and should be treated as such.

True. But it shouldn't be. It's like tearing down a perfectly good neighborhood to make way for a hotel that doesn't really benefit the town.

In my opinion, that's a main reason developers should favor open source tools, they never truly 'go away'. The code is out there, so keeping it going then comes down to whether someone cares enough to maintain it. Not saying that path is all roses...

It's same. Surrounding environments will change and just because the source of a previous version is there doesn't mean you can stably run it years on.

> Also, the editor does not seem to run on Windows 7 ("createpseudoconsole could not be located" in KERNEL32.dll)

Windows 7 EOL was 2 years ago though. (I know it's the last version of Windows that isn't an add-bloated spyware but still)

https://www.microsoft.com/en-US/windows/windows-7-end-of-lif...

Note that Windows 10 has some really nice OS API additions that may make devs consider ditching Windows 7 support (such as the createpseudoconsole function you’ve mentioned: https://docs.microsoft.com/en-us/windows/console/createpseud...)

Pseudoconsole/ConPTY is a big deal and this would need a complex fallback for Windows 7 and 8. Probably not worthwhile.

Are there any plans to release the app as a Flatpak, they are a great way to package your application cross-distro with a central way of updating (such as Flathub).

meta comment. Often people working on a big system like this aren't the same people who would know about flatpak or flathub and nor do they have to be the same people to implement that packaging. I find if I include a link to said recommendations that it increases the likelihood that someone will takeup the recommendation. Esp if the link espouses why it is great.

https://docs.flatpak.org/en/latest/introduction.html#reasons...

https://flathub.org/home

> Flathub only hosts stable application releases, and not development snapshots.

from https://github.com/flathub/flathub/wiki/App-Submission

> If there’s an app that you'd like to be distributed on Flathub, the best first course of action is to approach the app’s developers and ask them to submit it. Remember that for some projects or communities, this may be the first that they have heard of the Flatpak technology or interacted with somebody who advocates it.

Also from the above link.

No relation to this project. Just wanted to chime in to say that KDE's Kate editor pulled its Flatpak because the sandboxing makes much of the system integration (terminal, git, language servers) hard or impossible.

A Flatpak may have to ship with an independent copy of a lot of basic developer tools, and even then I don't know whether I want two different versions of git access the same local repository with a chance of incompatible repository formats.

I'm having the same issue with the Visual Studio Code (Flatpak). I want to use the compilers, interpreters and tools from the host, not whatever it's provided by the Flatpak or the runtimes from flathub/gnome, if it's provided at all.

Yeah, I've run into this issue with Flatpak & Kate. (I think it was specifically the Flathub Kate Flatpak that was pulled?)

FWIW I was recently able to get a "passable" but not ideal Rust/LSP/Rust-Analyzer/Cargo setup mostly functional via use of the kate build plugin and e.g `flatpak-spawn --host cargo build`...

...and... `flatpak-spawn --host cargo run | sed --unbuffered 's/\x1b\[[0-9;]*m//g'`.

Excuse the cough. :D (It was necessary to remove the ANSI colour codes produced by some logging library the project used.)

(My preference would be to use AppImage but unfortunately recent Kate AppImage versions have a hang-on exit bug.)

I haven't had a chance to test this yet but this is fantastic to see.

Anything like this that progresses the cross-platform remote model that we now have with VSC, particularly if the endpoint is fast and memory-efficient, is really important, because of the variety of dev environments.

What I would _really_ like, of course, is an iPad editor that could do the same.

If you could make an iPad editor that has VSC-style remoting, that is genuinely a killer app right now for a lot of people.

That would be "just enough" editor for me so I could travel for a few days and still do a couple of hours of work here and there, without the laptop commitment.

I am not big on iOS subscription apps and I'm budget-constrained, but I'd pay $50 per year (probably more, and I figure I wouldn't be alone), without hesitation, for a fast remoting iOS editor that had 80% of the functionality of VSCode Remote and had a viable built in browser to avoid the process switch.

The code-server project definitely works for this, but something a bit more native would be amazing.

https://github.com/coder/code-server

Why don't you install VS Code as PWA from https://vscode.dev/ ?

From the iPad perspective this is not actually that different to running code-server.

(code-server is basically the open source parts of this from what I understand, and the back-end impact is really no different at all, except needing to open a port for the web interface.)

I'm not sure whether vscode.dev will be able to connect to my own remotes yet; need to test that!

The main problem is as far as I am aware the same; the browser-side connection can drop quite easily because of the limits of iOS (you can't switch away without losing it).

That is obviously not something even a native version of Lapce would be able to totally avoid, but an iOS native app might have a few more strategies for maintaining background remote connections for a little while (SSH apps do for example).

vscode.dev is still for local development, not remote. It uses browser filesystem APIs to access your local filesystem. Whereas code-server runs on the remote and exposes a web server for you to connect to which serves up the filesystem on the remote.

You can connect to remote git repository

Yeah. But is that just for editing/committing? Can it remote into a server via SSH, run extensions there? I'm guessing not.

Not sure if it includes everything you've mentioned - but for iPad I found GoCoEdit to be about as "killer app" as it could get for an ipad code editor. I mean it blew me away. Not the developer, not associated with the dev or company - I just truly think its a wonderful editor.

Yes -- I've been using GoCoEdit for a long time! I love it. It's a really heroic effort.

But Visual Studio Code's remote thing really is on another level -- you can do things like run the git session remotely but with the GUI-side tools, do find and replace on the remote side; all the extensions (PHP syntax stuff etc.) install and run on the remote side as well as they do locally etc.; it's almost completely seamless.

Are in-browser editors ruled out?

EDIT: aha, just saw this, downthread:

> "The main problem is as far as I am aware the same; the browser-side connection can drop quite easily because of the limits of iOS (you can't switch away without losing it)."

In-browser editors are OK, if you can test your work without disrupting the connection, yeah. So sometimes if e.g. the website you're building is in another browser tab that has been enough.

The other way round -- an in-editor browser -- could be the better way to work. GoCoEdit does this (and it really is rather good!) as does Panic's Code Editor (formerly Coda for iOS), which is good, but not as good. And you arguably get a terminal more easily this way too, particularly where SSH keys are involved.

For me, the most important feature is VIM bindings. I used to suffer from severe RSI and VIM was a big part of what helped my wrists recover.

Seriously.

I don't know how people text edit without the vim keybindings. I'll never go back!

In emacs there are a few alternative modal editing modes I've been wanting to try.

https://github.com/Kungsgeten/ryo-modal

https://github.com/jyp/boon

https://github.com/emacsorphanage/god-mode

Only if I rebind keys from the very unintuitive default vim binding. It's like it's trying to twist your brain.

You an me both. I used emacs until I developed persistent tendonitis down the outside of my left hand.

Switched to vim, and the tendonitis resolved itself in about two months. That was back around 1990.

I love that you're using Treesitter. I haven't followed the editor space much, but afaik, this is one of the first to implement it. The demos I'd seen were very impressive - definitely going to give it a shot!

Every editor supports it now

What do you specifically mean by every?

How are you rendering fonts? FreeType to render the glyph texture map and then quads for each character? Or SDF?

render the glyph texture map and then quads for each character

I believe an open source editor should be built from source and I couldn't find links to sources or how to build from source on the website. The getting started documentation points to the download section. It would be cool if one of the downloads would be marked as source (for any OS).

There is a GitHub link on the top of the website. Build instructions are in the readme. https://github.com/lapce/lapce

I don't see it on the phone.

> It's a personal project so the initial set of features and key bindings are tight to my personal preferences.

As it should be. Well done.

I am kind of curious. Which came first? The editor or Rust?

I was wondering if you were learning Rust and decided that you needed a project to reinforce your learning? Or you were designing and editor and decided you should do it in Rust?

I always wanted a "perfect" editor https://github.com/lapce/lapce/blob/master/docs/why-lapce.md

And my recent professional work was writing Rust, and I felt Rust would be really suitable for my editor.

This looks awesome!! The code editor space may seem saturated, but it's not! I've been looking for an alternative to VS Code for some time.

Some things I'm really excited for: - Remote development as a first-class citizen! I use code-server a ton now, but getting away from browser jank would be nice. - In the future I wonder if something besides SSH would work for the connection. SSH doesn't handle bad connections or closing a laptop and moving very well. I use wireguard to connect to my code-server instance right now and it's pretty close to feeling like I develop locally. - Lighter and faster. Why does my laptop always have to be burning... - A more FOSS ecosystem. VS Code is "open source" but not really in practice. Some important extensions (from Microsoft) have non-foss licenses and the standard distribution is built with non-foss tidbits. There are projects like Codium that rectify these issues to some degree.

MOSH is not likely to be a supported protocol it seems, that would probably have been a good fit for your needs: https://github.com/microsoft/vscode-remote-release/issues/33...

I think Microsoft replaced SSH in vscode remote, part of the motivation being that the default SSH port (22?) is often blocked on corporate networks. I believe they use websockets instead, and I wonder if that might help with the problems associated with putting your computer to sleep and resuming your work (and connection)?

What prompted you to develop it? The market for this is quite crowded with Atom and VS Code. Where you that dissatisfied with them? Just wondering.

I like that this is native though. VS Code is one of the rare good electron apps but native is still nicer IMO. Will give it a try.

It's mainly speed.

I don't know if it's fixed now. Previously when I was using VSCode, sometimes the "go to definition" hangs and it will freeze the whole editor, which was unacceptable. So in Lapce, nothing blocks the main thread other than your key press.

Interesting, I'll definitely give it a try. Thanks for building it.

I thought atom was ditched. Competitors would be VSC, Sublime and JetBrains.

Do you use Lapce to edit Lapce's source code?

Yes, for more than one year now.

The speed on this is phenomenal and I'm really looking forward to you filling out a few more of the missing pieces. Really impressive achievement.

I wonder if you've considered kakoune style modal editing rather than vim? If you've not come across it, it might be worth looking at, as I think it's a better paradigm and one that I expect will go nicely with the multiple cursors you're working on.

Nowadays when I see "written in Rust" in the title, it reads like special pleading: "It's maybe not as good as what you use, but we are really proud to have got it working at all."

At least they went with "lighting-fast" instead of "blazing-fast"

“Lightning fast” is no less meaningless in practice than “blazing fast”. Both get used extensively by projects in such languages as JavaScript and Rust, on projects of similar scope that nonetheless have at least an order or two of magnitude’s performance difference.

Vite is a tool that deserves this moniker

What would one use Vite in place of?

webpack

If the title claims "lightning fast" or "blazing fast", I expect to see quantitative comparisons to alternatives. Which operations are faster than in other programs?

alacritty is a Rust program that is promoted as uniquely fast, but is substantially slower than (e.g.) kitty.

I myself only use software that is "made with <3"

I cringe quite hard when I see projects with either of these now-cliche catchphrases. It's crazy how many people use them.

I, too, only use software that is "made with binary".

I still prefer it to the "performant and beautiful" Electron made famous. almost all of the applications that said that were neither performant or beautiful, unless you found web pages and their quirks more beautiful than native GUIs.

I think that's a perfectly valid appeal to altruism in a tech-savvy audience. It makes sense to take a hit on your individual needs and wants as a user in the short term, if it helps with keeping the tech ecosystem which we collectively inhabit healthy in the long term.

Free market forces based on individual self-interest have proven to be really bad at doing that, so altruism is needed to fill the gap.

...by that logic, I prefer software written in Rust to software written in C++ or Java Script even if it's worse from a user perspective, as long as it's tolerably worse rather than just unusable.

I'd prefer it written in Zig compared to Rust, C++, JavaScript, or Cobol ;)

What is zig?

Just a Google away: https://ziglang.org/

Really? I take it to mean "fast and won't randomly segfault".

That should really apply to any systems language other than C for a text editor. As long as you have bounds checking and a test suite you're golden.

> As long as you have bounds checking and a test suite you're golden.

And other hilarious jokes you can tell yourself

I wouldn't recommend such a simple approach for something like a compiler, but for a text editor I don't think it's unreasonable. How many allocations can it actually need within any given subsystem which you can test individually?

I can't remember the last time any C tool segfaulted on me

Which one is that?

Sublime text is written in C, and before VSCode it was arguably the most popular editor on the planet.

Aaand "written in Rust" got removed from the title.

I take it as a declaration about the author: that he knows Rust now and can be hired to write Rust.

I think 'safe'

What makes you think rust is more safe? The platform itself it’s flawed, so any language running on the platform is also flawed.

Load a rust program into mem, change mem, run rust program. You’ve just lost safety.

The same reason "native MacOS app" is a selling point, it's all Electron's fault (only half kidding here).

For the tech savvy crowd, we care about stuff like this because we don't need another electron app hogging memory on our systems. Personally for me "written in rust" translates to "I care about performance" and "I care about my app not hogging your system memory"

I moreso see this as "Written by someone who's quite concerned about runtime performance and efficiency".

Ripgrep has completely upended my expectations (in a good way) for what modern machines are capable of. I'm all for OCD perfectionism if it means the performance I dreamed of in the 90's in finally realized.

> we are really proud to have got it working at all

On the contrary, the rust crate ecosystem and tooling means a lone developer can compose specialised libraries to produce a working artefact that scratches her own itch. Such productivity is the opposite of getting something working at all.

Trying to build an OSS cpp project or even worse, use an OSS Cpp library in your own project is more along the lines of "getting something working at all". Every third-party and some enterprise-internal Cpp libraries require one answers the following questions:

- how do I build the damn thing?

- how do I run the tests?

- how do I use the library? Vendor into the repo? apt install?

- what APIs does the system/library provide?

- where can I find the documentation and examples?

- how do I set up code completion?

- how do I know am using the library interface correctly?

- how do I know I didn't violate any invariants/safety guarantees?

Compare with the list of dependencies across the Cargo workspace members.

https://github.com/lapce/lapce/blob/master/lapce-core/Cargo....

https://github.com/lapce/lapce/blob/master/lapce-ui/Cargo.to...

https://github.com/lapce/lapce/blob/master/lapce-rpc/Cargo.t...

The cost of adding a new rust dependency when measured by the number of questions you need to answer beforehand is nearly constant. This means a layman can be more productive in rust.

Correct use, documentation, and other concerns are imporant for all libraries, whether got via cargo or otherwise, so this amounts to special pleading again.

More importantly, though: how hard is it to use a library coded in C++ from your Rust program? You have to make and maintain some sort of shim layer. Even a C library needs some such effort. For any given need, you are much less likely to find an existing and suitable Rust library already written, released, and maintained than one in some other, more widely used, language.

> Correct use, documentation, and other concerns are important for all libraries, whether got via cargo or otherwise

This is true.

However the Cargo/Rust ecosystem has one standard answer, read the associated crate docs, e.g.:

https://docs.rs/libloading

Coincidentally, the above linked crate `libloading` also shows how to access functionality in a shared library that exposes a C ABI compatible interface whatever the implementation language.

I don't understand this sentiment. Rust is the only language ecosystem where I find that anything works at all. Whenever I have to build something not built in rust, I'm praying. With rust made tooling, I just never have problems.

I don't know of any essential tool coded in Rust. Literally every single thing I rely on is coded in other some other language, and works. There is exactly one in Haskell: pandoc. No Java or C# (although I guess some people feel they need Minecraft or Kerbal Space Program). No Lisp, except Emacs. No Erlang, Clojure, Scala, OCaml, Dart, or Ada. Does TeX still count as Pascal?

The only case I know of where I would need a Rust program is to check a blake3 hash. That won't last.

> No Java

I am not sure what "essential tool" means if pandoc included in it. For me Intellij, Eclipse, Dbeaver are more essential (+ few other Specific tools based on Eclipse).

C# - I am not sure, MS Office?

I acknowledge that some people depend on Java and even C# programs.

Ripgrep is my essential codebase search tool. It's incredibly fast, very clear, and it just works how I expect. I use it a lot if I'm refactoring a larger codebase, particularly because it works well for more dynamic languages (where a compiler won't help) and for comments and documentation (where I want the naming to remain consistent).

I've heard good things about Bat and Exa - I personally have never felt a huge need for them, but other people claim that they're pretty essential to them.

Have you tried go at all?

Just tried it, on Linux. Pro:

- a single binary you can drop in ~/bin

- native Linux version

- really, really fast

- git branches in the top bar by default

Cons (beside being super new and lacking ecosystem):

- Use a custom window border, which is also pretty ugly IMO

- cannot use arrow keys in the command palette (or any file dialog). I guess it's a bug?

- default key bindings are... weird? ctrl+f doesn't prompt a find box for example

- cannot make syntax highlight work even on common formats like MarkDown, JSON or YAML

So, it feels very immature but for sure it is a great starting point, if I get good syntax highlight and code completion with a LSP (although it should already work) I might see me switching from VS Code to it, at least partially.

It's funny how people can disagree on pros / cons. For me it's:

> - a single binary you can drop in ~/bin

Well, a binary larger than quite some operating systems. (And not even talking about the security issues with such an approach).

> - native Linux version

Well, it's as "native" as an Electron app as it'll execute native machine code at some point. ;-) Besides that it feels as "native" as an Electron app… The UX is much more important than the actual technology used, imho!

> - really, really fast

I didn't measure anything but at least it feels as fast as my "dumb desktop editor", which is Kate. Only that Kate is usable right now, and has in fact quite some features.

The good parts:

- Lapces packaging issue is solvable.

- Rust is a fast language so I think Lapce won't become too slow as development progresses.

But the no-native UX is an issue. It likely won't ever feel more "native" than any random Electron app; love it or hate it.

But at least I'm looking forward to something like Slint GUI (which hopefully will feel native to my KDE Desktop once it'll be ready).

> Only that Kate is usable right now, and has in fact quite some features.

There's dozen of us! :)

As a matter of interest, have you managed to get a satisfactory Rust/LSP/Rust-Analyzer/Cargo setup running with your Kate install?

(Also, Kate as an AppImage seems to be ~150-185MB as a data point for comparisons. (`libKF5TextEditor.so.5` is ~3.5MB.))

The whole "native UI" aspect is a reasonable discussion point but given I seem to be running GTK/Flatpak-based distros I despair of ever having something "native" that I also think is good. :D (Elementary OS at least got me close enough to finally mostly move away from Mac.)

I do think native file dialog boxes are generally a nice addition as a halfway point.

> As a matter of interest, have you managed to get a satisfactory Rust/LSP/Rust-Analyzer/Cargo setup running with your Kate install?

Never tried. Like I said, Kate is my "dumb desktop editor". For coding I'm currently using VSC (and have still an IntelliJ install around, in case of).

The AppImage size of Kate is just crazy! Didn't know. That's also not really acceptable. The package version is only 7 MB uncompressed… (And all the libs are shared as I'm using KDE anyway).

Regarding the UX: Maybe I'm just lazy but I'm not keen on learning and remembering different details in how applications work. The "feel" in the 'look & feel' of an app is the most important thing. But as people here mentioned Lapce does not even handle clicks in an "usual" way. A native file dialog is just the tip of the things that should feel "native", imho.

I was super excited and took it for a spin, but this is not usable (macOS 12, arm). Not "rough around the edges", but "pre-alpha unusable". The command pallet didn't respond to arrow keys. I couldn't figure out how to search for an extension. There's no menu bar items, and it follows very few macOS platform conventions (eg, Cmd+T opens a new tab with its own workspace, but Cmd+W doesn't close it.) For some reason, the text is super blurry, especially on the file tree and other UI elements. The UI is obviously non-native and sticks out way more than VS Code's electron based UI.

I think it's a great project with a lot of potential, but I'll give it at least a year or two before general usability.

The UI is actually native, it's just that the native Rust UI tookit it's using (druid) is still work-in-progress and doesn't have some things we expect from a full UI framework (most notably, good text rendering).

Sure, if by native you mean “not using the web”, but my understanding is that Druid, much like flutter, uses a canvas like renderer underneath and doesn’t use platform widgets. The fact that lapce’s ui - like its file picker - looks nothing like a Mac app is flat out obvious and makes me less inclined to bother.

Almost all UI frameworks and APIs given from operating systems (WinForms, UIKit, GTK, …) uses a canvas renderer underneath. Except for the different styling, technology wise there isn’t really that much difference from other cross-platform UI frameworks such as Druid or Flutter. (For example, everyone seems to agree that Sublime Text is a “native” text editor, even if most of the rendering is actually done via a proprietary homebrew UI framework internal to Sublime HQ.)

Maybe you were emphasizing more on the theming/design principles than the technology behind it. In that area I just think Druid needs more work to allow using native dialogs for certain specific elements (file dialog, right click menu, etc.), which is what Qt already does.

Everything uses a canvas tender underneath, but native - at least to me - is using the platform’s implementation and widgets. Otherwise, even the web is native.

> The command pallet didn't respond to arrow keys.

Yeah, this seems to be an unfortunate bug. FWIW I linked to a workaround that enabled me to try the app's functionality more here: https://news.ycombinator.com/item?id=30718638

> I couldn't figure out how to search for an extension.

AFAICT there is only one extension/plugin currently (for Rust Analyzer) which is installable via the "puzzle piece" icon on the left side of the editor window.

In general it seems like non-modal people currently need to setup keybindings to get a usable editor.

It looks really promising. I wonder why code editors have the file explorer on the left side by default, if you resize it you move the whole text (unless you write in a right-to-left language). A colleague made me aware of this a while ago and I cannot stop wondering. I moved it to the right ever since.

Hm, it depends how you use it, I would say.

I totally agree that in a ltr context left side screams "focus point".

On the other hand, the project drawers/file explorer is mostly toggled off while I work, so it doesn't take any screen real estate.

And when I need it, it makes sense to be on the left side.

I prefer to explore via some search mechanism though.

Project drawers are only needed for special cases, like getting a feel for the overall structure of a project.

I think the file browser is like the high order digits in a number.

Probably so that way your code doesn't start at the left edge of the screen. This means your head stays more centered instead of constantly turned to the left.

> if you resize it you move the whole text

the main reason I change the sidebar's width is to recenter my text depending on my position in front of my screen aha... guess it's a case of the 1172s

> if you resize it you move the whole text

What's wrong with moving the whole text?

I think that Visual Studio has it on the right hand side by default, but that's the only editor I can think of that does it.

It does not have it by default on the right, but you can move it yourself.

Visual Studio Code does not. But Visual Studio does.

Nowadays, Visual Studio on the old days had it on the left by default.

Actually I don't remember any longer when they changed, maybe VS 2010 WPF rewrite.

IIRC they brought it into line with the old SQL Server Management Studio (SSMS), which always had the explorer on the right.

Why is moving the entire text a problem? It needs to be redrawn, but that's not expensive - it's like moving an entire window.

If for some reason you needed to resize the left side very often, or it would even resize automatically, I would understand the concern.

It's not about computation, I like the text to stay still. When I was aware of this it started bothering me, so I've changed it to the right ever since. Of course this is a very small and picky detail.

Judging by the downvotes people are really annoyed by this :D I'd never know!

For the same reason almost all relevant ui-elements are left-aligned across operation systems and apps: because we are tuned to process things left-to-right and the mouse is more often on the left side than it is on the right, and it feels less intuitive to move it to the right end of the screen.

- window-operation buttons on macos (close, maximize ...)

- application-menus in gnome, macos etc (file, edit, view ...)

- heavy-used buttons in browser (page back, refresh ...)

Except for the scroll bar. I vaguely remember from many years ago (maybe it was on Windows or some Linux desktop at the time) that you could put it there. NextStep seems to have used it like that by default, judging from screenshots.

Afaik Steve Jobs was left handed.

So everything build for him (as NextStep and macOS) has every GUI element on "the wrong side"… ;-)

This is a valid point. File explorer is not something that is used very frequently so moving it to the right makes sense.

> I moved it to the right ever since.

What text editor are you using?

I'm using vs code which is quite flexible

1. Select file to edit.

2. Edit text.

Flows from left to right.

> I wonder why code editors have the file explorer on the left side by default, if you resize it you move the whole text (unless you write in a right-to-left language).

Honestly, this behavior makes using a vertical monitor almost impossible. Wish VSCode let me configure it like Rider/IntelliJ so the sidebar is just a popover-style drawer rather than a push-style drawer.

Why do you want the text to start at the left edge of your display?

That's worse for your neck than keep it more center aligned.

It's needed. When I'm in vim I always open an extra terminal to the left so the text is more centred

Past discussions:

https://news.ycombinator.com/item?id=29549173 "Lapce – Fast and Powerful Code Editor written in Rust" (333 points | 3 months ago | 145 comments)

https://news.ycombinator.com/item?id=30526693 "Show HN: Lapce – open-source code editor inspired by Xi-editor" (7 points | 15 days ago | 2 comments)

I thought this is a brilliant output for a personal project.

https://lite-xl.com/ is another one which is written in Lua. Brilliant and super fast. It is much more polished than Lapce but still rough around the edges with features though.

Another one is Micro which is cool too.

Either way I am loving the fact that new OSS text editors coming out.

Lite (and almost everything by rxi) is very impressive. Lite-XL is a great continuation of the Lite project. Looking forward to see how it evolves.

Former contributor and user of Lite XL here.

It's an awesome little editor. I quit using it though because it seemed like the future direction of the project wasn't very clear, and from a practical standpoint VS Code simply has a better developer experience, but I had great fun hacking around it nevertheless.

One of my favorite things about rxi/lite and Lite XL is just how easy it is to write plugins. Simply create a new .lua file in the plugins directory and monkey-patch whatever you need. And while it might seem like monkey-patching isn't the most clean solution, that's not exactly true — the source code of the editor doesn't need to be cluttered with explicit hooks, and plugins interoperate with each other very well, because one plugin doesn't know about the others' existence. From its standpoint it just modifies the vanilla editor.

This extensibility allowed me to write some really cool stuff, the one plugin I'm especially proud of is lint+ [1], which leverages the immediate mode nature of the UI to draw pretty lint messages atop the text editor (and it even renders Rust's friendly compiler errors with little rails on the left! see issue #3 [2]).

Can recommend.

  [1]: https://github.com/liquidev/lintplus
  [2]: https://github.com/liquidev/lintplus/issues/3

> it even renders Rust's friendly compiler errors with little rails on the left! see issue #3 [2]

Nice!

You might like to show your work on that to https://twitter.com/ekuber if you've not already done so.

I'm actually using Lite-XL as essentially my main editor. I even wrote (at least the initial part of) a more usable terminal emulator plugin [1] based on libtmt (I think the community is working on replacing it with something even better).

I'm using the mentioned lint+ plugin, but for example also the LSP plugin, which is extremely useful, and a lot of others as well.

I love how fluid the entire editor feels (mostly, sometimes there's a small delay e.g. when I close the last tab in a language which terminates the language server synchronously). It's also extremely nice in terms of scaling support (super fine-grained and high quality at any scale).

> You can connect to a remote machine seamlessly, with a "local" experience, benefiting from a identical environment with your production server, or utilizing the full performance of the remote machine.

What does this mean? Is it like Emacs' TRAMP[1]?

[1] https://www.gnu.org/software/tramp/

It's similar to VSCode's remote development https://code.visualstudio.com/docs/remote/remote-overview

Or trying to be.

So, yes - similar to TRAMP in Emacs:

https://www.gnu.org/software/tramp/

Which is very nice, tho not new. Thought I use it less often than I did when I first learned about it. I just have emacs under tmux scattered around the boxes I am working with.

No Electron? That is already one good thing ;)

Why does Rust folks seem to encapsulate and separate their stuff more and more? Own build-tools and infrastructure are one thing. Am I right that Druid is not an very own Toolkit but a layer like WxWidgets?

No, Druid does not delegate to system widgets as far as I know. In that sense, it's slightly wrong that it's called "native", as it's not native UI, but it's compiled "native code" (= not Electron or a wrapper to some other framework that's written in some other language).

Here are the goals of Druid; be sure to read about the non-goals too: https://github.com/linebender/druid#Goals

Thank you. I was misguided by the dependency upon Gtk! For Gtk there is anyway gtk-rs[1] available.

[1] https://gtk-rs.org/

Will people stop complaining about Electron once their machine has 8 or more GB of ram?

My machine has 8 GB of RAM and I complain about Electron, because it's still sluggish, looks out of place and with how prevalent it is, running 3 instances is not rare (eg Slack+Discord+VSCode), which together eat up easily multiple gigabytes of RAM, and then there's also still my regular web browser.

Actually not. The problem is, good stuff need enduring hard work. There is no justification of wasting resources, draining the battery and providing bad integration into the environment. It is like Flash:

https://josephg.com/blog/electron-is-flash-for-the-desktop/

Why companies use Electron? It saves them money! And the users pay for CPU, RAM and suffer from bad usability. But that doesn't show up on your bill from Microsoft, Zoom, Spotify or Slack. And when your stuck with one software migration to better is hard. Steve Jobs killed Flash for just on reason, battery drain ^^

Gave it a quick shot on Windows, but it looks like the text rendering has artefacts all over the place? I'm seeing lots of very blurry text.

It's fantastic It's quite new so I understand the lack of support for syntax highlighting but

- it's fast

- has a built in terminal

- single binary

-rudimentary git support.

- It detected my virtualenv and opened the terminal accordingly.

Kudos to the developers, If you don't like it, it doesn't've to be your daily driver, won't be mine but this is amazing work

The file explorer appears to lack autocompletion. This feels like a project very close to being usable, but held back by minor issues with the UX.

I like the single lapce.exe and loads reasonably fast.

But this is in a pre pre-alpha stage, so many bugs it's far too early for public feedback. It loads reasonably fast except chrome stats in top left then jerks towards the center. The start page says to bring up the command palette which I was unable to navigate via keyboard.

The open file dialog takes an eternity to load the first time, the path is in a text box that's not editable. Focusing a text file gives an Insert cursor which is in text mode, there's a noticable slow delay before writing the first character, text selection is non existent so lacks basic text editing features.

There is a built-in terminal however there's only a single tab.

The only thing that gives it potential is that the folder/file browsing is super quick even with a node_modules folder so it might be built on efficient rendering that can be improved.

Even for such a basic editor it's 38mb download. For a far smaller + more complete editor checkout Lite:

https://github.com/rxi/lite

This is one of the cases where not having null pointers in Rust really doesn't seem to help:

  % touch test
  
  % lapce test
  thread 'main' panicked at 'Error in Surface::configure: parent device is lost', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.12.0/src/backend/direct.rs:214:9
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

  % RUST_BACKTRACE=full lapce test
  thread 'main' panicked at 'Error in Surface::configure: parent device is lost', /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-0.12.0/src/backend/direct.rs:214:9
  stack backtrace:
   0:     0x56474aaac84c - <unknown>
   1:     0x56474aad958c - <unknown>
   2:     0x56474aaa38f8 - <unknown>
   3:     0x56474aaaeea7 - <unknown>
   4:     0x56474aaaeb6f - <unknown>
   5:     0x56474aaaf60a - <unknown>
   6:     0x56474aaaf2f7 - <unknown>
   7:     0x56474aaaccf4 - <unknown>
   8:     0x56474aaaeff9 - <unknown>
   9:     0x5647494db8e3 - <unknown>
  10:     0x56474a7d8499 - <unknown>
  11:     0x56474a7d8f62 - <unknown>
  12:     0x56474a6b7345 - <unknown>
  13:     0x56474984e455 - <unknown>
  14:     0x564749657184 - <unknown>
  15:     0x56474953e4a5 - <unknown>
  16:     0x5647494ee8b6 - <unknown>
  17:     0x5647494dc243 - <unknown>
  18:     0x5647494dc2b9 - <unknown>
  19:     0x56474aaabf31 - <unknown>
  20:     0x5647494dc282 - <unknown>
  21:     0x7f084a6d3310 - __libc_start_call_main
  22:     0x7f084a6d33c1 - __libc_start_main@GLIBC_2.2.5
  23:     0x5647494dc165 - <unknown>
  24:                0x0 - <unknown>

Arch Linux, lapce 0.0.10, Rust 1.61.0-nightly, Sway/Wayland.

A panic is a different kind of crash than a segfault, it can not be used to get your credit card information.

Sure, but that is not a worry I have when I launch Neovim.

And there is a stack trace. Worlds apart.

Well stack traces are just a gdb session away, no changes to code/binary needed. No?

But most crashes can be turned into an exploit.

I was just responding to the stack traces bit, no argument about the exploit potential.

Not all crashes in C or C++ can give you a meaningful stack trace. Lots of time there is heap corruption, or stack corruption.

Safe Rust has the same properties as a managed language, one is going to spend an order of magnitude less time hunting for bugs.

Gotcha, thanks for clarifying!

I should have elaborated in my original comment. Next time!

Panics are usually at or close to the root of the bug. Segfaults can be anywhere later in the program

Probably an error in the WGPU rendering code. Rendering APIs have all sorts of implicit constraints and edge cases you need to be aware of (because of the complexity of using a specialized computation device that doesn't work like a CPU), and Rust's memory safety won't help you with most of it (since these are more of domain-specific logic errors rather than memory safety errors). Though Rust might help in designing a better API because it can use other features such as sum types, result types, and traits to model states and errors in a less error-prone way.

(At least the WGPU experience seems better than OpenGL, when you don't even get an assert or a stack trace, just an invisible error that you can only fetch by using glGetError() and is going to be hell of a shitty time trying to debug it and then sometimes you get to the conclusion that it might actually be a driver bug...)

Great work already! I do have one nitpick, however. Instead of handling click events, it seems to be using a more direct mouse input and acting on the mouse button being pressed. In webpages, this is the difference between onmousedown and onclick events.

This is extremely frustrating, perhaps it was done to give the illusion of speed, or it's a side-effect of the immaturity of the GUI framework? If you click and hold on the tab close button on your browser, and then move your mouse away and depress the button, you have the possibility to abort the action.

Another side effect of this seems to be that the GUI does not respond to presses from a touchscreen (on laptops), which does not behave like a mouse input, but still fires click events that most applications happily accept.

Honest question, is there a reason why one wouldn't be able to install Lapce via cargo, e.g., `cargo install lapce`? (I don't know much about distributing Rust applications so be patient with me if it's a dumb question.)

Is the name meant to be read as "lapse"?

1. a brief or temporary failure of concentration, memory, or judgement.

synonyms: failure, failing, slip, error, mistake, blunder, fault, omission, oversight, negligence, dereliction, slip-up, fail

No - it'd an acronym for Light And Powerful Code Editor

This is awesome! They seem to be using Wasmer [1] under the hood for their WebAssembly/WASI plugin system.

I would love to know if the IDE frontend could be compiled to Wasm (using WebGL/WebGPU under the hood) so it could run in the browsers, similarly to Makepad [2]

[1] https://wasmer.io/

[2] https://makepad.dev/

Potentially, the UI bits Lapce uses such as Druid, Winit, Wgpu all have the potential to compile into WASM. But it's not a priority.

Great job so far, and I hope this project expands and does well.

Hopefully this will remind some people how responsive applications should be. Not the _running away through treacle with all your memory under its arm_ that modern tools have become (hello VSCode).

Tried it for a bit. A great start.

The good: - Half the memory usage on my machine compared to other graphical editors. - It is extremely fast, though as all the missing features get added, we'll see if it stays that way.

Some basic QoL improvements needed - Needs syntax highlighting for more languages (Ruby/JS in my case) - Needs to use the system dialogs on Windows and macOS. Had a difficult time using other drive mount types. The built-in dialog would not open them at first.

I will be keeping an eye on this one. The only one that beats it speed-wise and memory wise is vim. :)

Good to see it has VIM bindings.

But without an Emacs like Lisp Machine, no can do ;)

Are they using the linkin park logo?

Coincidence, maybe?

From a quick Google search, the linkin park logo looks quite different

It is a bit similar.

When I thought about Lapce's logo, I took the initials of "Lightning" and "Powerful", so put L and P together to form a logo.

I guess Linkin Park is L and P too.

Looks closer to the NewPipe logo to me.

Doesn't seem to work on macos. It opens up, but has visual noise while I move the cursor. And I couldn't open a folder, because the dialog was unresponsive.

Since it's in an early stage, would be neat if there's list of features that this project wants build and which ones of them are already done. It would help to manage users' expectation when they try this out and perhaps even invite people who have been-there-done-that to help you achieve the remaining goals.

Looks like there is some hardware incompatibility - the whole window, except for a small bit in the top left corner where I can see the "Open Folder" icon, is black.

``` $ lapce MESA-INTEL: warning: Haswell Vulkan support is incomplete $ uname -r 5.13.0-35-generic x86_64 x86_64 ``` Ubuntu 21.10

That error is your drivers saying they have incomplete Vulcan support. It could work if you update to a recent version of Ubuntu or use the extended hardware support release.

Looks really promising, it starts crazy fast (sublime speeds), but no syntax highlighting and opening a project was buggy. Can't also full screen without making the entire thing full screen (clicking + on a Mac brings the whole thing full screen).

I'd be more inclined to give it a try if there were videos demonstrating it being used. Either on the project's website or YouTube. Otherwise, this looks like a great idea + project

> Vim like modal editing

Can I disable it? Because honestly, I don't want to tell my text editor to let me enter text every time I open a file.

Yes, it can be disabled. (via opening screen and/or preferences.)

I'm not a fan of modal editing either so I appreciate that while the Lapce developer is a fan they at least support non-modal as an option--unlike many other recent Rust-based text editor projects.

Good to know, thank you.

Amazingly fast on ARM Macbook Pro. Love the idea of remote editing.

Keep up the good work and post again when it's a bit more mature.

> Amazingly fast on ARM Macbook Pro

Isn't everything amazingly fast on it?

Supporting modal editing like vim is a huge plus for me. As far as personal projects go this is amazing. Kudos.

It's very barebones though, basic movement + get in and out of insert mode using i/I or a/A.

Basic commands like y, d, c + motion are not supported yet.

I know, but given the willingness to throw a bone to the vim community is nice.

Awesome work, I'll be watching the project. A more efficient code editor is sorely needed, well done.

It's native UI as in not a web browser, but it draws the UI manually instead of using WinAPI etc.?

Super minor nitpick, or question: isn't the standard Web Assembly abbreviation WASM?

WASI is an interface similar to libc - it's a compilation target in place of OS (whereas Wasm is the binary format itself).

WASM is targeting web.

WASI(https://wasi.dev/) is the system interface.

WASM and WASI are two different things. WASI is the WebAssembly System Interface.

https://github.com/bytecodealliance/wasmtime/blob/main/docs/...

I was waiting for the "written in Rust", was not disappointed. :)

Great project by the way.

Very happy to see new editors coming up, and extra happy for Linux support. Nice!

WASI for plugins is a great choice. Are other editors out there doing this?

Cool project, hopefully it turns out well! I really liked the speed of it.

its actually super cool for a personal project. devs need a vscode-like editor without electron and m$ stuff and built-in vim support

Amazing project! Great initial set of features.

the future looks promising! Can't wait to try this out when it finally reach stability

I tried to change the font by backspacing whatever the default was in the font family box in settings, but once I deleted the last character, the program crashed and would not open again.

Running with a trace gets:

    thread 'main' panicked at 'assertion failed: `(left == right)`
      left: `23`,
     right: `0`', /home/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/font-kit-0.10.1/src/loaders/freetype.rs:817:13
    stack backtrace:
       0: rust_begin_unwind
                 at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/std/src/panicking.rs:498:5
       1: core::panicking::panic_fmt
                 at /rustc/9d1b2106e23b1abd32fce1f17267604a5102f57a/library/core/src/panicking.rs:116:14
       2: core::panicking::assert_failed_inner
       3: core::panicking::assert_failed
       4: font_kit::loaders::freetype::Font::rasterize_glyph
       5: piet_wgpu::pipeline::Cache::get_glyph_pos
       6: piet_wgpu::text::WgpuText::get_glyph_pos
       7: piet_wgpu::text::WgpuTextLayout::rebuild
       8: <piet_wgpu::text::WgpuTextLayoutBuilder as piet::text::TextLayoutBuilder>::build
       9: lapce_core::config::Config::editor_text_width
      10: <lapce_core::terminal::LapceTerminal as druid::widget::widget::Widget<lapce_core::data::LapceTabData>>::layout
      11: druid::core::WidgetPod<T,W>::layout
      12: <lapce_core::scroll::LapcePadding<T,W> as druid::widget::widget::Widget<T>>::layout
      13: druid::core::WidgetPod<T,W>::layout
      14: <lapce_core::terminal::LapceTerminalView as druid::widget::widget::Widget<lapce_core::data::LapceTabData>>::layout
      15: druid::core::WidgetPod<T,W>::layout
      16: <lapce_core::split::LapceSplitNew as druid::widget::widget::Widget<lapce_core::data::LapceTabData>>::layout
      17: druid::core::WidgetPod<T,W>::layout
      18: <lapce_core::terminal::TerminalPanel as druid::widget::widget::Widget<lapce_core::data::LapceTabData>>::layout
      19: druid::core::WidgetPod<T,W>::layout
      20: <lapce_core::tab::LapceTabNew as druid::widget::widget::Widget<lapce_core::data::LapceTabData>>::layout
      21: <druid::widget::lens_wrap::LensWrap<T,U,L,W> as druid::widget::widget::Widget<T>>::layout
      22: druid::core::WidgetPod<T,W>::layout
      23: <lapce_core::window::LapceWindowNew as druid::widget::widget::Widget<lapce_core::data::LapceWindowData>>::layout
      24: <druid::widget::lens_wrap::LensWrap<T,U,L,W> as druid::widget::widget::Widget<T>>::layout
      25: druid::core::WidgetPod<T,W>::layout
      26: druid::window::Window<T>::layout
      27: druid::window::Window<T>::do_paint
      28: druid::win_handler::AppState<T>::paint_winit_window
      29: druid::app::AppLauncher<T>::launch::{{closure}}
      30: winit::platform_impl::platform::x11::EventLoop<T>::run_return::single_iteration
      31: winit::platform_impl::platform::x11::EventLoop<T>::run
      32: winit::platform_impl::platform::EventLoop<T>::run
      33: winit::event_loop::EventLoop<T>::run
      34: lapce_core::app::lanuch
    note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

Agree with other comments here that it's a bit too unusable at the moment, and unfortunately I wasn't even 30 seconds into my demo before this happened, so I can't really comment on the rest of the application.

.msi installer marked as Unsafe.

I installed it anyways. Seems fine so far.

I am unable to

Hmm. Don't know what to tell ya. Did you go into the extra options and tell it to bypass the warning?

As for whoever is downvoting my previous comment. Seriously?

Just tossing an opinion out there. In the last 10 years my editor progression has been notepad++ -> sublime -> atom -> vscode -> pycharm. Virtually every pixel on Pycharm is dedicated to at least try to let me write better python code and ease development friction. Lapce may eventually be vscode++ but I'm no longer in the market for general purpose editors.

Complaining about bugs in an alpha software makes no sens so I won't.

But one thing makes me uncomfortable regardless of its early state: It's gigantic!

It's a 55 MB executable. You could fit at least one hundred full blow almost self contained (CLI) text-editors with the feature-set of Lapce in that size…

What is going on there? Does it bundle an operating system, or even a whole EMACS distribution in that binary?

Besides that it feels like VSCode. Not regarding speed, Lapce feels faster for sure. But with its custom GUI there is actually no gain regarding UX compared to any "desktop-webpage-container" (a.k.a. Electron app), imho. "Native" applications that don't feel native just "aren't native" — regardless the technology used.

The other but related issue is (even it's not really on Lapce) that those Rust GUI toolkits are imho light-years away from being production ready. So not only that Lapce feels "not native" (which is bad on its own, as it's than the UX of "just another webpage") but additionally it will likely take years just for the used GUI toolkit to catch up with the state of the art.

Of course I wish the authors luck with their project! But it looks to me like it'll be a quite long journey up to the finish line. So they will also need some staying power. Especially as there seems to be some competition¹ in the space of "VSCode alikes"…

¹ https://onivim.io/

The gigantic executable size is a rust issue I'm very dissatisfied with.

There are a few factors that contribute more or less to this. In no particular order:

- many dependencies badly handle additional, potentially unwanted features (many aren't optional at all and take runtime checked branches)

- lto is disabled by default on release builds

- release builds still bundle a lot of debug info (should only affects binary, not memory size)

- backtracing on panic pulls in a big backtracing library, formating code and string literals

Enabling lto shaved off 10mb of my build just now

> It's a 55 MB executable. You could fit at least one hundred full blow almost self contained (CLI) text-editors with the feature-set of Lapce in that size…

Sure, why not, I've got time to waste on endless bikeshedding... :D

IMO 55MB isn't "gigantic"--a 450MB binary could rightly be called "gigantic": https://github.com/lapce/lapce/issues/24#issuecomment-100122... (But, ya know, ya don't get this here debugging info for free.)

FWIW the Linux binary I downloaded can be immediately shrunk from 57413256 bytes to 44604432 bytes (~43MB) by running `strip` on it.

I imagine further size reductions can be found by following the, by now, "standard", list of steps at https://github.com/johnthagen/min-sized-rust but for a pre-pre-alpha personal project I imagine doing so is not a high priority.

Also FWIW comparing a "self contained (CLI)" to a self-contained GUI editor seems pretty apples to oranges as comparisons go...

I will accept though a 3x multiplier on the "bloated" `emacs25-nox` (~15MB) and a 50x on the svelte `vim.tiny` (~11MB) I found installed locally. (Apparently `emacs25-x` on another machine weighs in at ~17MB so I guess that's the eventual target. :D )

My primary interest in Lapce is for editing Rust code with LSP/Rust-Analyzer support (the latter being where there's actually issues with regard to constrained development environments), I recently almost got there with the KDE Kate editor but a Rust built editor with WASM/WASI as a target for plugins seems more attractive to me going forward.

I understand that a code editor is necessarily a little bit bloated.

But my comment was more about the binary size.

I'm very much not a fan of this static compiled apps even I understand that from the developers standpoint they're nice. But properly packaging such a thing is usually more involved as I would be if is would be modular from the get go.

AppImages are a bit better as they're an "overlayed" bundle but still the usual problems remain.

How big would it be if it would use the dynamic libs provided by an distribution actually? I guess not bigger than Kate. :-)

Reply on news.ycombinator.com