Helix editor panics when started from xplr

[Omnikar]

• OS: MacOS 11.2.1
• Terminal: iTerm2 3.4.12
• xplr version: 0.17.2
• Helix version: source build from commit 368064e3

When I try to start Helix from xplr, either via :e or even by typing hx into the shell opened by :!, it panics with the following panic message from crossterm:

thread 'main' panicked at 'reader source not set'

The panic message also gives that it occurred at src/event/read.rs:38:30 in crossterm.

[sayanarijit]

Thanks for reporting.

Reference line: https://github.com/crossterm-rs/crossterm/blob/9bc5cd3527a2d26caa6e2ccdc499beb4764fca95/src/event/read.rs#L38

[sayanarijit]

The problem seems to be in macOS. But works fine on Linux (tested on the latest Manjaro).

[sayanarijit]

The deepest I could investigate was upto this function where helix tries to create a file descriptor pointing to the standard input or /dev/tty and apparently panics.

So I tried to run the following code from inside xplr terminal, hoping for it to panic:

use libc;
use std::fs;
use std::os::unix::io::{IntoRawFd, RawFd};

fn main() {
    unsafe { libc::isatty(libc::STDIN_FILENO) };
    fs::OpenOptions::new().read(true).write(true).open("/dev/tty").unwrap().into_raw_fd();
}

But it ran successfully.

[sayanarijit]

Got some helpful references from the crossterm discord channel:

• Always read user input from /dev/tty crossterm-rs/crossterm#396
• Changed STDIN to /dev/tty crossterm-rs/crossterm#407
• /dev/tty does not work on macOS with kqueue crossterm-rs/crossterm#500

[Omnikar]

Oh, it looks like crossterm-rs/crossterm#500 is the same issue as what prevented Helix's "pipe into a buffer on startup" feature from working on MacOS.

[sayanarijit]

Seems like it's fixed in the latest version of helix editor.

Hence, closing this issue.

[Omnikar]

Seems like it's fixed in the latest version of helix editor.

I updated to the latest versions of Helix and xplr, but I'm still getting the same exact error.

[sayanarijit]

Can you confirm the correct binary is run in the xplr shell? Spawn the shell using :! and check version "$EDITOR --version"

[Omnikar]

Can you confirm the correct binary is run in the xplr shell? Spawn the shell using :! and check version "$EDITOR --version"

It's Helix 22.05, the latest version.

[tait-adam]

Was there any solution to this in the end?

• MacOS 11.7
• Kitty terminal 0.26.2
• xplr 0.19.3
• hx 22.08.1

Having the same problem

[sayanarijit]

Ah, so it's macOS specific. I currently don't have access to a macOS, but it sounds like the issue is related to one of the crossterm issues linked above. Need help to confirm this by a macOS user.

[taupiqueur]

I’ve been able to start Helix from xplr on macOS using @yyogo’s patch.

helix-editor/helix#2111

[tait-adam]

I’ve been able to start Helix from xplr on macOS using @yyogo’s patch.

helix-editor/helix#2111

Works perfectly. Thanks

[sayanarijit]

Hope it gets fixed in crossterm/helix soon. Closing this.