18 ms·

Lapce – Fast open-source code editor

538 points by maximilianroos 5y ago

nisanth074 5y ago
Amazing project! Great initial set of features.
asicsp 5y ago
Past discussions: https://news.ycombinator.com/item?id=29549173 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 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)
math-dev 5y ago
Good to see it has VIM bindings. But without an Emacs like Lisp Machine, no can do ;)
deleted 5y ago
[deleted]
rhim 5y ago
Are they using the linkin park logo?
- boobsbr 5y ago
  Coincidence, maybe?
- frenchman99 5y ago
  From a quick Google search, the linkin park logo looks quite different
- rhim 5y ago
  Looks very similar to me: https://tse2.mm.bing.net/th?id=OIP.kyjN_mk3b6e6SNFV0mC7JgHaFj&pid=Api https://tse2.mm.bing.net/th?id=OIP.kyjN_mk3b6e6SNFV0mC7JgHaF...
- dzhou121 5y ago
  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.
- approxim8ion 5y ago
  Looks closer to the NewPipe logo to me.
once_inc 5y ago
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.
ncmncm 5y ago
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."
- omniscient_oce 5y ago
  At least they went with "lighting-fast" instead of "blazing-fast"
  - chrismorgan 5y ago
    “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.
    - randomsearch 5y ago
      Vite is a tool that deserves this moniker
      - ncmncm 5y ago
        What would one use Vite in place of?
        randomsearch 5y ago
        webpack
    - ncmncm 5y ago
      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.
  - 5y ago
woile 5y ago
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.
- OtomotO 5y ago
  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.
  - kybernetikos 5y ago
    I think the file browser is like the high order digits in a number.
- lilyball 5y ago
  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.
- jcelerier 5y ago
  > 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
- abainbridge 5y ago
  > if you resize it you move the whole text What's wrong with moving the whole text?
- thejosh 5y ago
  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.
Deukhoofd 5y ago
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.
oblio 5y ago
Super minor nitpick, or question: isn't the standard Web Assembly abbreviation WASM?
- Deukhoofd 5y ago
  WASM and WASI are two different things. WASI is the WebAssembly System Interface. https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-overview.md https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
- emteycz 5y ago
  WASI is an interface similar to libc - it's a compilation target in place of OS (whereas Wasm is the binary format itself).
- dzhou121 5y ago
  WASM is targeting web. WASI(https://wasi.dev/ https://wasi.dev/) is the system interface.
sbt567 5y ago
the future looks promising! Can't wait to try this out when it finally reach stability
thescribbblr 5y ago
.msi installer marked as Unsafe.
- _ehqz 5y ago
  I installed it anyways. Seems fine so far.
  - thescribbblr 5y ago
    I am unable to
    - _ehqz 5y ago
      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?
darkwater 5y ago
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.
- still_grokking 5y ago
  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).
  - follower 5y ago
    > 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.
d3nj4l 5y ago
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.
- cyber_kinetist 5y ago
  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).
  - d3nj4l 5y ago
    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.
    - cyber_kinetist 5y ago
      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.
syrusakbary 5y ago
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/ https://wasmer.io/ [2] https://makepad.dev/ https://makepad.dev/
- dzhou121 5y ago
  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.
thejosh 5y ago
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).
pratio 5y ago
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
rckt 5y ago
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.
chimen 5y ago
- ihateolives 5y ago
  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.
- pkolaczk 5y ago
  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).
  - chimen 5y ago
    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.
    - Yoric 5y ago
      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.
      - chimen 5y ago
    - bennyp101 5y ago
      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.
dzhou121 5y ago
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.
- GekkePrutser 5y ago
  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.
  - dzhou121 5y ago
    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.
    - GekkePrutser 5y ago
      Interesting, I'll definitely give it a try. Thanks for building it.
  - mekster 5y ago
    I thought atom was ditched. Competitors would be VSC, Sublime and JetBrains.
- ihateolives 5y ago
  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.
matthew-hale 5y ago
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.
nitred 5y ago
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.
tommica 5y ago
Cool project, hopefully it turns out well! I really liked the speed of it.
skocznymroczny 5y ago
It's native UI as in not a web browser, but it draws the UI manually instead of using WinAPI etc.?
colonwqbang 5y ago
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
- JadedBlueEyes 5y ago
  No - it'd an acronym for Light And Powerful Code Editor
marcus_cemes 5y ago
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.
tunnuz 5y ago
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.)
johnisgood 5y ago
> 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/ https://www.gnu.org/software/tramp/
- dzhou121 5y ago
  It's similar to VSCode's remote development https://code.visualstudio.com/docs/remote/remote-overview https://code.visualstudio.com/docs/remote/remote-overview Or trying to be.
  - NateEag 5y ago
    So, yes - similar to TRAMP in Emacs: https://www.gnu.org/software/tramp/ https://www.gnu.org/software/tramp/
    - lanstin 5y ago
      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.
xyproto 5y ago
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.
- filmor 5y ago
  A panic is a different kind of crash than a segfault, it can not be used to get your credit card information.
  - sitkack 5y ago
    And there is a stack trace. Worlds apart.
    - eatonphil 5y ago
      Well stack traces are just a gdb session away, no changes to code/binary needed. No?
byteski 5y ago
byteski 5y ago
its actually super cool for a personal project. devs need a vscode-like editor without electron and m$ stuff and built-in vim support
biorach 5y ago
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
- JadedBlueEyes 5y ago
  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.
ho_schi 5y ago
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?
- GolDDranks 5y ago
  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 https://github.com/linebender/druid#Goals
  - ho_schi 5y ago
    Thank you. I was misguided by the dependency upon Gtk! For Gtk there is anyway gtk-rs[1] available. [1] https://gtk-rs.org/ https://gtk-rs.org/
- mekster 5y ago
  Will people stop complaining about Electron once their machine has 8 or more GB of ram?
  - ColonelPhantom 5y ago
    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.
  - ho_schi 5y ago
    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/ 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 ^^
mythz 5y ago
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 https://github.com/rxi/lite
tony-allan 5y ago
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.
- qwerty456127 5y ago
  > Amazingly fast on ARM Macbook Pro Isn't everything amazingly fast on it?
gigatexal 5y ago
Supporting modal editing like vim is a huge plus for me. As far as personal projects go this is amazing. Kudos.
- marcofiset 5y ago
  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.
  - gigatexal 5y ago
    I know, but given the willingness to throw a bone to the vim community is nice.
Rob_Polding 5y ago
Awesome work, I'll be watching the project. A more efficient code editor is sorely needed, well done.
still_grokking 5y ago
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/ https://onivim.io/
- lsbehe 5y ago
  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
- follower 5y ago
  > 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-1001226988 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 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.
Gentil 5y ago
I thought this is a brilliant output for a personal project. https://lite-xl.com/ 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.
- toastercat 5y ago
  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.
- lqdev 5y ago
  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
  - follower 5y ago
    > 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 https://twitter.com/ekuber if you've not already done so.
eek2121 5y ago
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. :)
deleted 5y ago
[deleted]
rhabarba 5y ago
> 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.
- follower 5y ago
  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.
  - rhabarba 5y ago
    Good to know, thank you.
teeceetime2 5y ago
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
ha1zum 5y ago
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.
romaintailhurat 5y ago
I was waiting for the "written in Rust", was not disappointed. :) Great project by the way.
id02009 5y ago
Very happy to see new editors coming up, and extra happy for Linux support. Nice!
ghusto 5y ago
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).
cdaringe 5y ago
WASI for plugins is a great choice. Are other editors out there doing this?

Amazing project! Great initial set of features.

Past discussions: https://news.ycombinator.com/item?id=29549173 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 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)

math-dev 5y ago

Good to see it has VIM bindings. But without an Emacs like Lisp Machine, no can do ;)

deleted 5y ago

[deleted]

rhim 5y ago

Are they using the linkin park logo?

boobsbr 5y ago
Coincidence, maybe?
frenchman99 5y ago
From a quick Google search, the linkin park logo looks quite different
rhim 5y ago
Looks very similar to me: https://tse2.mm.bing.net/th?id=OIP.kyjN_mk3b6e6SNFV0mC7JgHaFj&pid=Api https://tse2.mm.bing.net/th?id=OIP.kyjN_mk3b6e6SNFV0mC7JgHaF...
dzhou121 5y ago
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.
approxim8ion 5y ago
Looks closer to the NewPipe logo to me.

once_inc 5y ago

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.

ncmncm 5y ago

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

omniscient_oce 5y ago
At least they went with "lighting-fast" instead of "blazing-fast"
- chrismorgan 5y ago
  “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.
  - randomsearch 5y ago
    Vite is a tool that deserves this moniker
    - ncmncm 5y ago
      What would one use Vite in place of?
      - randomsearch 5y ago
        webpack
  - ncmncm 5y ago
    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.
- 5y ago

woile 5y ago

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.

OtomotO 5y ago
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.
- kybernetikos 5y ago
  I think the file browser is like the high order digits in a number.
lilyball 5y ago
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.
jcelerier 5y ago
> 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
abainbridge 5y ago
> if you resize it you move the whole text What's wrong with moving the whole text?
thejosh 5y ago
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.

Deukhoofd 5y ago

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.

oblio 5y ago

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

Deukhoofd 5y ago
WASM and WASI are two different things. WASI is the WebAssembly System Interface. https://github.com/bytecodealliance/wasmtime/blob/main/docs/WASI-overview.md https://github.com/bytecodealliance/wasmtime/blob/main/docs/...
emteycz 5y ago
WASI is an interface similar to libc - it's a compilation target in place of OS (whereas Wasm is the binary format itself).
dzhou121 5y ago
WASM is targeting web. WASI(https://wasi.dev/ https://wasi.dev/) is the system interface.

sbt567 5y ago

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

thescribbblr 5y ago

.msi installer marked as Unsafe.

_ehqz 5y ago
I installed it anyways. Seems fine so far.
- thescribbblr 5y ago
  I am unable to
  - _ehqz 5y ago
    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?

darkwater 5y ago

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.

still_grokking 5y ago
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).
- follower 5y ago
  > 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.

d3nj4l 5y ago

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.

cyber_kinetist 5y ago
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).
- d3nj4l 5y ago
  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.
  - cyber_kinetist 5y ago
    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.

syrusakbary 5y ago

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/ https://wasmer.io/ [2] https://makepad.dev/ https://makepad.dev/

dzhou121 5y ago
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.

thejosh 5y ago

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

pratio 5y ago

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

rckt 5y ago

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.

chimen 5y ago

ihateolives 5y ago
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.
pkolaczk 5y ago
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).
- chimen 5y ago
  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.
  - Yoric 5y ago
    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.
    - chimen 5y ago
  - bennyp101 5y ago
    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.

dzhou121 5y ago

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.

GekkePrutser 5y ago
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.
- dzhou121 5y ago
  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.
  - GekkePrutser 5y ago
    Interesting, I'll definitely give it a try. Thanks for building it.
- mekster 5y ago
  I thought atom was ditched. Competitors would be VSC, Sublime and JetBrains.
ihateolives 5y ago
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.

matthew-hale 5y ago

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.

nitred 5y ago

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.

tommica 5y ago

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

skocznymroczny 5y ago

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

colonwqbang 5y ago

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

JadedBlueEyes 5y ago
No - it'd an acronym for Light And Powerful Code Editor

marcus_cemes 5y ago

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.

tunnuz 5y ago

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

johnisgood 5y ago

> 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/ https://www.gnu.org/software/tramp/

dzhou121 5y ago
It's similar to VSCode's remote development https://code.visualstudio.com/docs/remote/remote-overview https://code.visualstudio.com/docs/remote/remote-overview Or trying to be.
- NateEag 5y ago
  So, yes - similar to TRAMP in Emacs: https://www.gnu.org/software/tramp/ https://www.gnu.org/software/tramp/
  - lanstin 5y ago
    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.

xyproto 5y ago

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.

filmor 5y ago
A panic is a different kind of crash than a segfault, it can not be used to get your credit card information.
- sitkack 5y ago
  And there is a stack trace. Worlds apart.
  - eatonphil 5y ago
    Well stack traces are just a gdb session away, no changes to code/binary needed. No?

byteski 5y ago

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

biorach 5y ago

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

JadedBlueEyes 5y ago
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.

ho_schi 5y ago

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?

GolDDranks 5y ago
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 https://github.com/linebender/druid#Goals
- ho_schi 5y ago
  Thank you. I was misguided by the dependency upon Gtk! For Gtk there is anyway gtk-rs[1] available. [1] https://gtk-rs.org/ https://gtk-rs.org/
mekster 5y ago
Will people stop complaining about Electron once their machine has 8 or more GB of ram?
- ColonelPhantom 5y ago
  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.
- ho_schi 5y ago
  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/ 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 ^^

mythz 5y ago

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 https://github.com/rxi/lite

tony-allan 5y ago

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.

qwerty456127 5y ago
> Amazingly fast on ARM Macbook Pro Isn't everything amazingly fast on it?

gigatexal 5y ago

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

marcofiset 5y ago
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.
- gigatexal 5y ago
  I know, but given the willingness to throw a bone to the vim community is nice.

Rob_Polding 5y ago

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

still_grokking 5y ago

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/ https://onivim.io/

lsbehe 5y ago
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
follower 5y ago
> 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-1001226988 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 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.

Gentil 5y ago

I thought this is a brilliant output for a personal project. https://lite-xl.com/ 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.

toastercat 5y ago
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.
lqdev 5y ago
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
- follower 5y ago
  > 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 https://twitter.com/ekuber if you've not already done so.

eek2121 5y ago

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

deleted 5y ago

[deleted]

rhabarba 5y ago

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

follower 5y ago
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.
- rhabarba 5y ago
  Good to know, thank you.

teeceetime2 5y ago

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

ha1zum 5y ago

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.

romaintailhurat 5y ago

I was waiting for the "written in Rust", was not disappointed. :) Great project by the way.

id02009 5y ago

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

ghusto 5y ago

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

cdaringe 5y ago

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