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.
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.
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.
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.
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.
> "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.
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.
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.
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)?
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.
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.
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!
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).
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)
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.
> 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).
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?
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).
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.
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'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.
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.
> 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.
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!
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
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."
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 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 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 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.
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.
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.
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.
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).
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.
“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.
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.
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.
> 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.
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.
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.
> 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.
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.
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
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.
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]).
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.
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.
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).
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:
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 ^^
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:
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.)
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]
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).
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. :)
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
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.
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.
Sublime success shows people do need those 0.01 seconds saved (well, actually it is often not just 0.01 seconds, but a lot more - VS Code is sometimes laggy and that's really annoying).
Sublime got completely destroyed in a single year by...an electron app (VSCODE). Chew on that. While at it I'm going to let you know why: features, open platform, plugins, ecosystem and integration. I've been a Sublime user and now I don't even have it installed any more. They share the same fate with TextMate.
That seems like a big statement, I still use ST - albeit not for everyday work (I shifted to JetBrains tools), but if I want to knock up a quick script then I will > subl file.ext to quickly knock something up.
If I have big files to open, or I want to do some text manipulation, then ST is what I reach for.
"Completely destroyed" is a bit much, maybe shifted to a different use-case for some people, but for a quick editor that offers a pretty damn good environment to work in I think it still has its place.
On the other hand, VSCode won largely by being much faster than most of the competition.
Anyway, the author wanted to write a desktop app in Rust. What's the issue with that? A few years ago, we'd have the same but "written in JS", "written in Ruby", "written in Python", ... I agree that it's more important for the author than for the end-users, of course.
ok, i’m glad you’ve found an editor that better suits your needs. remember, this is a preference, not a competition. personally, i much prefer the responsiveness & lower memory footprint of sublime, and couldn’t tolerate trading those off for features in atom/code.
What do you mean it's not a competition? They are fighting for your AppStore, for the same spot, for your attention. Sublime has pricing, Microsoft has...other interests. I would have loved for Sublime to win here but it lost. Sure there are still users of it but let's not debate here. All youtube videos and pictures I see lately from programmers are using VsCode. In fact, I haven't seen a single Sublime open in a video tutorial for over 2-3 years now. It's not even funny. Speed is important but not when we talk about a second (I'm generous here).
Powerful as an adject has lost it's meaning. Every new tool is either powerful or minimalistic. Or both. Or post-modern. There are no regular tools or software anymore.
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"…
> 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
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. :-)
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.