Live data from Hacker News

Helix-gpui: A simple GUI for the Helix editor

github.com

31–40 of 77 posts

Re: Helix-gpui: A simple GUI for the Helix editor

#32

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

The best graphical, modal text editor is Emacs.

it also has many terminals to choose from and dirvish which sits on top of dired is the best file editor I've used.

Re: Helix-gpui: A simple GUI for the Helix editor

#33
post #31

If you're in an environment to use GUI, there are plenty other more featureful alternatives. But good terminal editors are rare to be used within SSH sessions. (Vs code can do but editing root owned files aren't easy)

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.

Re: Helix-gpui: A simple GUI for the Helix editor

#34

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.

There are Kakoune-style bindings for vs code: https://marketplace.visualstudio.com/items?itemName=gregoire...

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.

Re: Helix-gpui: A simple GUI for the Helix editor

#35
post #13

Earlier quoted context omitted.

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 wr…

Ah, I see. Would this come at a performance cost? (My only experience with GUI editors is VSCode, which feels sluggish compared to Helix.)

Arguably native drawing should be faster than going through terminal subsystem, all other things being equal.

Re: Helix-gpui: A simple GUI for the Helix editor

#36
post #20

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

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

Re: Helix-gpui: A simple GUI for the Helix editor

#37
post #16

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.

What's the thing that bothers you most in a terminal app like helix compared to a regular GUI?

no shadows, no blur, no animations ...

Re: Helix-gpui: A simple GUI for the Helix editor

#38

All we want is a tree explorer :'(

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.

Re: Helix-gpui: A simple GUI for the Helix editor

#39

All we want is a tree explorer :'(

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 f…

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.
Post reply on HN