fzf as --initial-command crashes Ghostty

[keen-dot-dev]

Coming from urxvt, I wanted to create similar keybinding for Ghostty in my i3 configuration to run Ghostty with ThePrimeagen's tmux-sessionizer, which uses fzf program.

The command for urxvt is i3-sensible-terminal -e ~/scripts/tmux-sessionizer.sh or urxvt -e ~/scripts/tmux-sessionizer.sh and both of them work perfectly.

Ghostty also supports -e option, which looks like what I need. Unfortunately, if initial command has to run fzf - it fails (see the video below).

ghostty_fzf.mp4

To simplify the issue, this command fails:
ghostty --initial-command="ls ~ | fzf"
The result is the same as shown on the video with additional message below:

panic: runtime error: index out of range [0] with length 0

                                                          goroutine 7 [running]:
        github.com/junegunn/fzf/src.(*Terminal).markOtherLine(...)
                                                                       github.com/junegunn/fzf/src/terminal.go:176
                                          github.com/junegunn/fzf/src.(*Terminal).printHighlighted(0xc00017c008, {0xc00012a500, {0x0, 0x0, 0x0, 0x0}}, {0x5fc50?, 0xc0?, 0x967f084b?}, {0x101?, ...}, ...)
                                                                github.com/junegunn/fzf/src/terminal.go:2476 +0x176d
                                            github.com/junegunn/fzf/src.(*Terminal).parsePrompt.func1()
                                github.com/junegunn/fzf/src/terminal.go:1097 +0x87
          github.com/junegunn/fzf/src.(*Terminal).printPrompt(0xc00017c008)
        github.com/junegunn/fzf/src/terminal.go:1809 +0x23
                                                          github.com/junegunn/fzf/src.(*Terminal).Loop.func8.2(0xc00011a7e0)
                                                        github.com/junegunn/fzf/src/terminal.go:3752 +0x352
                                   github.com/junegunn/fzf/src/util.(*EventBox).Wait(0xc00011a7e0, 0xc00005ffa0)
                                                github.com/junegunn/fzf/src/util/eventbox.go:34 +0x62
                             github.com/junegunn/fzf/src.(*Terminal).Loop.func8()
                github.com/junegunn/fzf/src/terminal.go:3718 +0xfa
                                                                  created by github.com/junegunn/fzf/src.(*Terminal).Loop in goroutine 23
                                                                       github.com/junegunn/fzf/src/terminal.go:3696 +0x5f9

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Ghostty failed to launch the requested command:

/bin/sh -c ls ~ | fzf

Runtime: 12 ms
Exit Code: 2

Press any key to close the window.

Add --wait-after-command option to see more info. Specified initial command by itself runs well.

[jcollie]

Ghostty isn't technically crashing here. It's fzf crashing because it doesn't like something about the environment that it's being created in. So the task here is to figure out what's different between the environment that urxvt creates and the environment that Ghostty creates.

[jcollie]

Ah, yes, you are experiencing problems similar to what fastfetch users experience when fastfetch is run as part of their shell init script. Ghostty starts your command while the user interface is still initializing. Part of that initialization process of the UI may involve resizing the window a number of times as, but the window starts out relatively small. fastfetch and apparently fzf don't like this so sleeping for a second while the UI finishes all of it's resizes "fixes" this problem. I don't know if we have a solution for this but we're aware that it exists.

[keen-dot-dev]

I see, thank you.

I understand that solution may not be that simple.
However, I'd like to know: should I expect any changes in this regard, or this is not considered an issue?

Perhaps, it's possible to make a new option to control if user wants to execute initial command only after ghostty has fully initialized window? It would definitely be faster and more reliable than solution with custom delay.

[handdara]

Just adding here that I had the same issue, and am also using a delay to patch the problem for now.
On my machine I got said delay down to .015 seconds, less than that and occasionally it would crash.
At around .0078 seconds it crashed roughly half the time.

[rhodes-b]

I see, thank you.

I understand that solution may not be that simple. However, I'd like to know: should I expect any changes in this regard, or this is not considered an issue?

Perhaps, it's possible to make a new option to control if user wants to execute initial command only after ghostty has fully initialized window? It would definitely be faster and more reliable than solution with custom delay.

I dont think its generally considered an issue its a edge case very early in initialization, normally a sleep of 0.1 fixes it.
GTK especially is slow to startup the first time so waiting extra time to do stuff would be another startup hit which is bad.

Like Jcollie said what happens is before there is a window ghostty just picks some initial size since it has to start with something (I think this is a smaller number). Then app runtime starts window and starts reporting sizes in which ghostty will internally update its size to properly tell apps that are running. Afaik GTK doesnt give any info on when its all the way initialized so you know its "done resizing". Ghostty also cant force GTK to some initial size it wants

ghostty/src/Surface.zig

Lines 619 to 621 in 603639a

	// Note: it is important to do this after the renderer is setup above.
	// This allows the apprt to fully initialize the surface before we
	// start messing with the window.

(take a look at the comment here it lets GTK initialize then starts changing sizes)

[keen-dot-dev]

I see, thank you.

I understand that solution may not be that simple. However, I'd like to know: should I expect any changes in this regard, or this is not considered an issue?

Perhaps, it's possible to make a new option to control if user wants to execute initial command only after ghostty has fully initialized window? It would definitely be faster and more reliable than solution with custom delay.

I dont think its generally considered an issue its a edge case very early in initialization, normally a sleep of 0.1 fixes it.
GTK especially is slow to startup the first time so waiting extra time to do stuff would be another startup hit which is bad.

Like Jcollie said what happens is before there is a window ghostty just picks some initial size since it has to start with something (I think this is a smaller number). Then app runtime starts window and starts reporting sizes in which ghostty will internally update its size to properly tell apps that are running. Afaik GTK doesnt give any info on when its all the way initialized so you know its "done resizing". Ghostty also cant force GTK to some initial size it wants

ghostty/src/Surface.zig

Lines 619 to 621 in 603639a

	// Note: it is important to do this after the renderer is setup above.
	// This allows the apprt to fully initialize the surface before we
	// start messing with the window.

(take a look at the comment here it lets GTK initialize then starts changing sizes)

Thank you for this clarification! I wasn't familiar with ghostty source code enough to find the root cause of the problem myself.

While I still feel a bit uncomfortable with the "sleep of 0.1" solution - I guess the issue should be closed as it is not in fact an issue.

Thanks to all participants, I hope this discussion may be helpful to anyone facing similar issues.