I'm a fan. I was looking for something a bit more like a vscode experience with kakoune/helix style keybindings, but everything seemed to be either 100% terminal or vim-style. I was quite interested in https://lapce.dev/ also written in rust, but as I say, vim-style rather than kakoune/helix style.
Have you looked at Neovide? It's very similar to this, a cross-platform Rust based GUI front end for neovim. Neovide is really quite nice; it's beautifully rendered.
My primary use case for Neovide (vs neovim running in Wezterm/kitty/Alacritty) is simply so I can Alt/Cmd-TAB to it quickly as I usually run with many terminal windows open and it's somewhat of a chore to locate the one with nvim in it, whereas with Neovide I have a separate app with an icon in the dock/sysmenu to switch to.
>My primary use case for Neovide (vs neovim running in Wezterm/kitty/Alacritty) is simply so I can Alt/Cmd-TAB to it quickly as I usually run with many terminal windows open and it's somewhat of a chore to locate the one with nvim in it, whereas with Neovide I have a separate app with an icon in the dock/sysmenu to switch to.
In Sway I have long (across three different terminal emulators) had a setup where I launch specially named terminals on session start, e.g. term-editor, term-local, term-remote, and then use the custom titles (I guess it's an appid actually) in my Sway config to make keybinds to focus those specific windows. I also focus my other always-used programs via their default appid (wayland) or class (xwayland), terminals just have the issue you mentioned of dealing with multiple, so had to use something more specific.
That last one makes the editor terminal always launch on workspace 1 which makes it a bit easier to get things where I'm used to having them after a restart.
The bind looks for emacs before my special term as I was using emacs (with evil) for a bit and had the bind set up to focus that. I left it in because this way if I just have one or the other open at some point, the bind works as expected without me having to change the config back and forth. Though with both open my focus ends up on the terminal.
Most terminal emulators should support a similar argument for launching with a custom id/title/whatever, and even if you're not using i3 or Sway, I think there are other programs such as wmctrl which can do something similar.
Surely you can just fix the cmd-tab behavior? I've always imagined the defaults were tuned for non-techies, because they don't exactly do well with many windows.
App detection, which breaks simple things like alt tab and more complicated things keyboard rebindings via external tools (and all the other cooperation with utilities based on app detection), then poor keybinding support of terminals with whole modifiers missing
I’ve been splitting time recently between Zed, VSCode, and Neovim. Zed has come along way, its native vim integration is top notch. It ties in its core editor features and enables them via vim commands rather than offering a true “vim experience”, which is exactly what I’m looking for but certainly won’t be for everyone.
> Most modal editors are terminal apps, I'd like to change that and implement a good modal GUI editor.
That’s lovely, I’m doing the same. I’m using glfw and C++14 to build a vim-ish IDE. I never learned to love vim/nvim plugins, and make only basic use of macros and substitutions so that’s pretty much the feature-set. It’s very fun to build your own UI library.
There's plenty of things that Emacs does right, but evil-mode is far from ideal. Many plugins don't support it OOB and need special workarounds. Many others expect native Emacs keybindings and you need to manually add ones for evil-mode specifically. Nowadays I don't experience many issues with it, but this is mostly because my setup is largely static, and it took me several years of tweaking the configuration to get it in a state that's usable and intuitive for me. It's unreasonable to expect everyone else to have the same patience, so an editor with a _native_ modal UI can certainly improve the user experience.
In general, the benefit of a UI would be that you can draw things you can't draw when constrained to a grid of characters, and you can have interactivity you couldn't otherwise have. It would be more like VS Code or Zed but with the Helix editing model underneath.
(Worth noting one of the maintainers said only a couple months ago: "this is really far away right now as helix needs large architectural changes before writing a GUI is even feasible/a good idea."[1])
Another benefit that hasn't been mentioned yet is menu bars (e.g. File, Edit, View, Help, etc...)
Having a visible menu bar helps with feature discoverability.
While it's true that terminal-based editors can have menu bars (e.g. nano), they're more limited overall than what you'll find with native OS menu bars.
Editing root-owned files by opening an editor as root is generally considered to be an anti-pattern. There is sudoedit as an option, but that also works with VSCode (and has the same limitations roughly.) The better option is probably just not editing root-owned files directly except in an emergency; there's usually better approaches to deploying system-wide changes.
That's probably not going to happen as part of the core editor (there's a long discussion about this somewhere on the bug tracker) but should be easy to add using the now work-in-progress plugin system. Scroll down to the Examples section.
Funny how the maintainers preferred to build a plugin system instead of just the tree explorer, I suspect Helix will lose its biggest feature: no plugins and easy configuration :(
I used to use tree explorers all the time, but once I discovered fuzzy-search file explorers, I never used a tree explorer again. It’s been too long for me to remember why I liked tree explorers before or why I stopped using them, so I’m curious, what are the benefits of a tree explorer over a fuzzy-search file explorer?
I’m not questioning the usefulness or validity of tree explorers. I’m just trying to see things from a different perspective.
Tree-based finders allow you to explore a project.
Fuzzy finders only work when you already know what files exist.
Without a tree-based finder, you have no way to know which files exist in an unfamiliar project. Imagine being asked to change something in a project (e.g. add some extra space between two things on screen) without knowing what files existed. If you only rely on searching for names/terms that come to mind, you're probably going to miss the best way to accomplish the task at hand.
Tbh, I like having both, I find a fuzzy search is faster at finding what I want but a file tree is really helpful for building a mental model of directory relationships in a complex project.
Being made with gpui means it's mac-only right? Seems worth mentioning for anyone not familiar with the library and an odd choice if the goal is parity with Helix.
I had heard of that but went off the fact that MacOS is still a requirement in the repo readme.
Just had a peek in the build.rs and do see the windows target, which is great, Rust could definitely use some more cross-platform UI tooling
Readit News
https://neovide.dev
My primary use case for Neovide (vs neovim running in Wezterm/kitty/Alacritty) is simply so I can Alt/Cmd-TAB to it quickly as I usually run with many terminal windows open and it's somewhat of a chore to locate the one with nvim in it, whereas with Neovide I have a separate app with an icon in the dock/sysmenu to switch to.
In Sway I have long (across three different terminal emulators) had a setup where I launch specially named terminals on session start, e.g. term-editor, term-local, term-remote, and then use the custom titles (I guess it's an appid actually) in my Sway config to make keybinds to focus those specific windows. I also focus my other always-used programs via their default appid (wayland) or class (xwayland), terminals just have the issue you mentioned of dealing with multiple, so had to use something more specific.
Relevant config lines:
```
exec --no-startup-id "sh -c 'sleep 10; exec foot --app-id=term-editor'"
bindsym ctrl+$mod+e [class="Emacs"] focus ; [app_id="term-editor"] focus
assign [app_id="term-editor"] 1
```
That last one makes the editor terminal always launch on workspace 1 which makes it a bit easier to get things where I'm used to having them after a restart.
The bind looks for emacs before my special term as I was using emacs (with evil) for a bit and had the bind set up to focus that. I left it in because this way if I just have one or the other open at some point, the bind works as expected without me having to change the config back and forth. Though with both open my focus ends up on the terminal.
Most terminal emulators should support a similar argument for launching with a custom id/title/whatever, and even if you're not using i3 or Sway, I think there are other programs such as wmctrl which can do something similar.
I use them every day :)
There is a discussion of Helix-style bindings on their github, and some proofs of concept, but nothing polished yet AFAIK.
Works great even though it's labeled as an alpha.
https://zed.dev
That’s lovely, I’m doing the same. I’m using glfw and C++14 to build a vim-ish IDE. I never learned to love vim/nvim plugins, and make only basic use of macros and substitutions so that’s pretty much the feature-set. It’s very fun to build your own UI library.
There's plenty of things that Emacs does right, but evil-mode is far from ideal. Many plugins don't support it OOB and need special workarounds. Many others expect native Emacs keybindings and you need to manually add ones for evil-mode specifically. Nowadays I don't experience many issues with it, but this is mostly because my setup is largely static, and it took me several years of tweaking the configuration to get it in a state that's usable and intuitive for me. It's unreasonable to expect everyone else to have the same patience, so an editor with a _native_ modal UI can certainly improve the user experience.
(Worth noting one of the maintainers said only a couple months ago: "this is really far away right now as helix needs large architectural changes before writing a GUI is even feasible/a good idea."[1])
[1]: https://github.com/helix-editor/helix/issues/39#issuecomment...
Having a visible menu bar helps with feature discoverability.
While it's true that terminal-based editors can have menu bars (e.g. nano), they're more limited overall than what you'll find with native OS menu bars.
But good terminal editors are rare to be used within SSH sessions. (Vs code can do but editing root owned files aren't easy)
I don't want to git push/pull on every minor edit that I might revert the next minute.
This also involves, directory listing that is only root accessible.
https://github.com/helix-editor/helix/pull/8675
I’m not questioning the usefulness or validity of tree explorers. I’m just trying to see things from a different perspective.
Fuzzy finders only work when you already know what files exist.
Without a tree-based finder, you have no way to know which files exist in an unfamiliar project. Imagine being asked to change something in a project (e.g. add some extra space between two things on screen) without knowing what files existed. If you only rely on searching for names/terms that come to mind, you're probably going to miss the best way to accomplish the task at hand.
Can build Zed from the main branch.