[HN Gopher] Helix-gpui: A simple GUI for the Helix editor
___________________________________________________________________
Helix-gpui: A simple GUI for the Helix editor
Author : todsacerdoti
Score : 97 points
Date : 2024-05-27 16:32 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| wkat4242 wrote:
| What's a "modal editor"? I don't really understand what's so
| unique about this.
| cbolton wrote:
| When you're not in insert mode, you have the whole alphabet of
| keyboard keys to act on the text without
| Ctrl/Alt/Shift/whatever combinations. So you can get a lot done
| with very few key presses, using shortcuts that make sense
| (e.g. "t." to select all text "to the next dot", and all that
| without straining your hands as you'd do when you use
| Ctrl/Alt/Shift modifiers. That last point is how I got into
| modal editors: Emacs keybindings were aggravating my RSI
| symptoms. It went away when I started using vim (and now
| helix).
| bern4444 wrote:
| Modal editors like vim and helix have modes[0] that allow for
| different operations.
|
| Vim has
|
| - normal mode which allows you to enter commands to manipulate
| text rather than just type characters in the file
|
| - insert mode which allows you to enter text into a file
|
| - replace mode which allows you to replace text
|
| and a few others.
|
| Most editors like vscode, sublime etc only have a single mode
| that they are always in IE insert mode. Modal editors have
| additional modes that allow for additional capabilities.
|
| [0]https://www.freecodecamp.org/news/vim-editor-modes-
| explained...
| lifty wrote:
| a modal editor is an editor with different editing modes, like
| Vim or Helix. Notepad for example is not a modal editor, and
| neither is VSCode by default.
| paranoidxprod wrote:
| Just an editor with modes. Ie in vim you have have the default
| normal mode (move with hjkl) to move around the code without
| having to move your hands over to the arrows, insert mode to
| enter text, visual mode to select text, etc.
| senkora wrote:
| It typically means "something like vi", where there are "modes"
| like insert, normal, command, replace, visual, etc. that
| completely change the keybindings and are switched between by
| pressing certain keys in certain modes.
| talldayo wrote:
| Modal editing is an older concept, where by-default you can't
| hop in and start typing like normal. Most modal editors
| (including Helix) start you in a Normal mode, which is mostly
| used for reading and searching documents. Then you press a
| button (usually i or a) and get put into an Insert mode, where
| you can edit the text and type to your heart's content.
| Pressing escape will drop you back into Normal mode when you're
| done, where you can save the document and exit the editor.
|
| It's a different workflow, but kinda nice when you want that
| IDE-style experience in a simpler interface like a TUI.
| Lyngbakr wrote:
| I'm a happy Helix user and I'm curious what the benefit is of
| this over terminal-based Helix?
| dcre wrote:
| 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])
|
| [1]: https://github.com/helix-
| editor/helix/issues/39#issuecomment...
| Lyngbakr wrote:
| Ah, I see. Would this come at a performance cost? (My only
| experience with GUI editors is VSCode, which feels sluggish
| compared to Helix.)
| dcre wrote:
| Not necessarily. Zed is designed to be very fast. Worth
| looking into. https://zed.dev/
|
| Both VS Code and Zed have pretty comprehensive (and in the
| case of VS Code, widely used) Vim modes, so it would really
| be quite a lot like that.
| lsllc wrote:
| +1 for Zed [running in vim mode]. It has best-in-class
| tree-sitter and LSP support (not unsurprising since Max
| Brunsfeld of tree-sitter fame is one of the founders).
| zokier wrote:
| Arguably native drawing _should_ be faster than going
| through terminal subsystem, all other things being equal.
| leecommamichael wrote:
| > 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.
| turboponyy wrote:
| The best graphical, modal text editor is Emacs.
| beyondCritics wrote:
| Emacs is far from being modal though ...
| karthink wrote:
| Emacs' keymap system is fully modal by design. This state
| machine is why it's possible to fully implement evil-mode
| (and many other modal editing UIs, like boon, lispy etc)
| quite easily on top.
| turboponyy wrote:
| Emacs is whatever you want it to be, and it has wonderful
| modal editing packages such as evil-mode[1] - which
| surpasses the editing system from vi that it is based on -
| and Meow[2]
|
| 1. https://github.com/emacs-evil/evil
|
| 2. https://github.com/meow-edit/meow
| jhchabran wrote:
| Having used evil-mode as my main driver for years, I can
| confirm that it truly works as expected. Requires some
| setup though. I used
| https://github.com/doomemacs/doomemacs to do the heavy
| lifting though.
| imiric wrote:
| *with evil-mode.
|
| 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.
| wudangmonk wrote:
| it also has many terminals to choose from and dirvish which
| sits on top of dired is the best file editor I've used.
| davefol wrote:
| What has your experience using GPUI been like?
| kybernetikos wrote:
| 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.
| cbolton wrote:
| What's the thing that bothers you most in a terminal app like
| helix compared to a regular GUI?
| feel-ix-343 wrote:
| no shadows, no blur, no animations ...
| lsllc wrote:
| 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 it,
| whereas with Neovide I have a separate app with an icon in the
| dock/sysmenu to switch to.
| opan wrote:
| >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.
| yjftsjthsd-h wrote:
| Meta: 4 spaces indentation to format code.
|
| Question: exec --no-startup-id "sh -c
| 'sleep 10; exec foot --app-id=term-editor'"
|
| What's the sleep for?
| ilyagr wrote:
| 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.
| SkyArrow wrote:
| I've been using this fork which has Helix bindings: https://m
| arketplace.visualstudio.com/items?itemName=silverqu...
|
| Works great even though it's labeled as an alpha.
| k33st wrote:
| Helix is gorgeous and really efficient, but still lacks some
| crucial function like auto-reloading. To palliate that, advanced
| users could try this IDE that does solve all these problems,
| Helix and Tmux as an IDE in the shell:
| https://github.com/webdev23/shelix
| dcre wrote:
| For anyone interested, here is the issue about auto-reloading.
|
| https://github.com/helix-editor/helix/issues/1125
|
| Another example of a missing feature in high demand is the
| ability to pipe info about the current file (path, line number,
| etc) to a command, e.g., for a custom git blame command.
| Fortunately there is a PR for that and helix is easy to build
| from source.
|
| https://github.com/helix-editor/helix/pull/6979
| worldsavior wrote:
| Not sure why would you use a GUI over the terminal, since it
| looks like a replica of Helix only using GUI components instead
| of terminal rendering.
| ldelossa wrote:
| All we want is a tree explorer :'(
| matrixhelix wrote:
| 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 :(
| jiripospisil wrote:
| 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.
|
| https://github.com/helix-editor/helix/pull/8675
| innocentoldguy wrote:
| 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.
| Charlie_e wrote:
| 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.
| mekster wrote:
| 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)
| jchw wrote:
| 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.
| Charlie_e wrote:
| 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.
___________________________________________________________________
(page generated 2024-05-27 23:00 UTC)