Helix crashes when launched from zk application

[adrianmroz-allegro]

Summary

When zk tries to run helix, helix crashes with error status 101.

I wanted to add helix as default editor for zk. For fresh install I set editor in zk config but

Reproduction Steps

I tried this:

1. Fresh install of zk
2. Set editor = "hx" in config per config documentation
3. Invoke any action in zk that should cause launch of helix, for example zk new

I expected this to happen:
Helix to launch

Instead, this happened:
Helix crashes with:
zk: error: failed to launch editor: hx /Users/<snip>/5e19.md: exit status 101

Here is the code of zk that launches editor. It works for me with nano and vim

Log attached that corresponds with launching running zk new.

Helix log

~/.cache/helix/helix.log

2022-04-14T21:22:22.528 helix_view::editor [ERROR] Failed to initialize the LSP for `source.md` { LSP not defined }

Platform

macOS

Terminal Emulator

iTerm

Helix Version

helix 22.03 (d4e45fd)

[barszcz]

@adrianmroz-allegro I'm having this exact same problem and decided to investigate.

The relevant bit of the error message when running zk new with my editor set to hx proved to be thread 'main' panicked at 'reader source not set', /Users/brew/Library/Caches/Homebrew/cargo_cache/registry/src/github.com-1ecc6299db9ec823/crossterm-0.25.0/src/event/read.rs:38:30 . Long story short, the root cause of this seems to be crossterm-rs/crossterm#500. Until that's fixed upstream in crossterm, I don't think we'll be able to pipe input to zk with hx set up as the editor on macOS.

However, as you point out, hx isn't currently working for this at all on macOS, even when we're not piping from stdin. That's because zk is setting stdin to /dev/tty as a theoretically editor-agnostic workaround for this issue when using vim. One would think this would be safe, but on macOS, doing this blows up Helix because of the crossterm issue.

To confirm this, I recompiled zk without the stdin redirect and voila, zk new and friends worked fine, as long as I didn't try to pipe its input. Until this gets fixed in crossterm, I think the workaround belongs in zk and not in Helix: just check if stdin is piped and add the stdin redirect iff it is. I believe this will fix all non-piped usages of zk for macOS Helix users, without causing a regression for Vim users. I'm working on this now and plan on submitting a PR to zk.

One last thing I want to note here, and I can open a separate issue for this if need be: when I do something like echo blah | hx I get the informative error message Piping into helix-term is currently not supported on macOS. But in the case of this issue, where we're piping to another program that tries to open Helix, we get the panic instead, which is much more cryptic. Is it possible to have smarter detection for this case?

[yyogo]

Updating that I've run into this in zsh as well, and that I just opened crossterm-rs/crossterm#711 and verified that it fixes this issue (and also fixes piping to Helix on macOS)

[taupiqueur]

You can edit Helix’s /Cargo.toml to test @yyogo’s patch.

[patch.crates-io]
crossterm = { git = "https://github.com/yyogo/crossterm.git", branch = "use-select-in-unix" }

[alxzh]

Helix crashes for me when set as default editor in fish shell.