Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Helix-gpui: A simple GUI for the Helix editor

github.com

Post reply on HN
Print view View original

41–50 of 77 posts

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

#41

Post by SkyArrow »

ilyagr wrote: post #34
kybernetikos wrote: post #12

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.

I've been using this fork which has Helix bindings: https://marketplace.visualstudio.com/items?itemName=silverqu...

Works great even though it's labeled as an alpha.

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

#42

Post by yjftsjthsd-h »

opan wrote: post #36
lsllc wrote: post #20

Earlier quoted context omitted.

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

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?

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

#44

Post by Charlie_e »

Flex247A wrote: post #43
Charlie_e wrote: post #40

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.

GPUI works on Windows too now. Can build Zed from the main branch.

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

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

#45

Post by spartanatreyu »

Lyngbakr wrote: post #9

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

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

#46

Post by spartanatreyu »

innocentoldguy wrote: post #38
ldelossa wrote: post #22

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…

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.

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

#48

Post by mekster »

jchw wrote: post #33
mekster wrote: 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.

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.

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

#49

Post by Hasnep »

kybernetikos wrote: post #12

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.

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

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

#50

Post by p9fus »

Lyngbakr wrote: post #14
dcre wrote: 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.)

if anything GUI's should be significantly faster (well, I say significantly, but a well optimized GUI app and a well optimized Terminal + TUI app would probably have near imperceptible latency today anyways)
Post reply on HN