Ghry
Helix-gpui: A simple GUI for the Helix editor
51–60 of 77 posts
Re: Helix-gpui: A simple GUI for the Helix editor
#52Earlier quoted context omitted.
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.
What would be the better approach to handle bunch of files in /etc/ without making the process reluctant? 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.
Generally, I think most people agree that directly editing live configuration files on systems is not the ideal way to manage systems. As for what to do instead, it strongly depends. On test or development systems, I suspect most people wouldn't bat an eye to just running Vim as root, but there are some other options:
- Use configuration management systems to provision configuration changes: Ansible, SaltStack, Chef, etc. (And yeah, when testing on development or test set ups/VMs, you might first try stuff with vim directly. But if you are pretty sure you know what you want, you can also just do it in the configuration management system, test it, and provision it.) -- This may seem overkill for local configuration but it's pretty handy.
- If possible, make use of features of your tools to require less root access. For example, in Nix there are various ways to move the Nix configuration for the system out of /etc/nixos and into a user directory, or some hybrid of the two. Maybe some services can be made rootless: either running as "user" services, or even under a rootless container.
- Make use of permissions or ACLs to give write access to a non-root user or group. Then you don't need to be root to edit or provision the files.
Re: Helix-gpui: A simple GUI for the Helix editor
#53What has your experience using GPUI been like?
Also wondering how stable it is (how often are they breaking source compatibility?)
Since it is not released on crates.io
Re: Helix-gpui: A simple GUI for the Helix editor
#54I'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?
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
Re: Helix-gpui: A simple GUI for the Helix editor
#55I'm a happy Helix user and I'm curious what the benefit is of this over terminal-based Helix?
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.
What's the limit over native?
Re: Helix-gpui: A simple GUI for the Helix editor
#56I'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.
I've heard that Zed's vim mode is very good, although I'm not a vim user so I can't confirm. https://zed.dev
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.
Re: Helix-gpui: A simple GUI for the Helix editor
#57Earlier quoted context omitted.
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…
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 min…
For discovering files in an unknown codebase I use the grep feature in Helix (or just ripgrep CLI). Way faster than going through a tree in most cases.
Re: Helix-gpui: A simple GUI for the Helix editor
#58Earlier quoted context omitted.
What's the thing that bothers you most in a terminal app like helix compared to a regular GUI?
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
What is app detection?
Regarding poor key binding support, I think that's not really a problem in modern applications. Quoting https://gpanders.com/blog/state-of-the-terminal/ :
> Sending key presses as escape sequences requires that terminal applications are able to recognize and parse those sequences, so it is not something that “just works” out of the box. However, the kitty keyboard protocol has been widely adopted by both modern terminal emulators and terminal applications. Terminals which support the kitty keyboard protocol (to some degree) include Wezterm, Alacritty, kitty, foot, Ghostty, and iTerm2. Applications which support the kitty keyboard protocol (to some degree) include Vim, Neovim, Helix, kakoune, and nushell. This means that when using one of these applications in one of these terminals, all of the key encoding problems discussed above (as well as some others which were not discussed…) are solved.
At least I indeed saw no such issue using helix in wezterm for example.
Re: Helix-gpui: A simple GUI for the Helix editor
#59Earlier quoted context omitted.
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
What is app detection? Regarding poor key binding support, I think that's not really a problem in modern applications. Quoting https://gpanders.com/blog/state-of-the-terminal/ : > Sending key presses as escape sequences requires that terminal applications are able to recognize and parse those sequences, so it is not something that “just works” out of the box. However, the kitty keyboard protocol has been widely adopt…
App detection is being able to tell which app you're using, e.g., knowing that you're using Helix and not just WezTerm
Poor key binding support is still a problem despite the optimistic quote (and might last for one more generation given the snail speed of progress). For example, the kitty protocol isn't "comprehensive" despite its dev's claims: it doesn't support left vs right modifiers and also some non-standard modifiers that are used to circumvent this limitation (only hyper)
> At least I indeed saw no such issue using helix in wezterm for example.
I think helix still doesn't support even the full kitty protocol, e.g., the Windows key.
And I do see these issues since I'm using richer keybindings to make input more ergonomic.
Re: Helix-gpui: A simple GUI for the Helix editor
#60Why is this flagged?