Conversation
I dedicate any and all copyright interest in this software to the public domain. I make this dedication for the benefit of the public at large and to the detriment of my heirs and successors. I intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law.
| # Bug: Ghostty (up to at least nightly build 2026-07-16) ignores our `set wait after command | ||
| # of cfg to false` instruction and requires a keypress to close a terminal. |
There was a problem hiding this comment.
ghostty-org/ghostty#13167. No issue has been created yet.
|
For what it's worth, I use Kakoune with Ghostty on Linux via the Wayland windowing module. Because there is no equivalent functionality like AppleScript integration for Linux, and there is no CLI options for opening new splits (only new windows), my integration is very simple. And I don't hate it. Just: So, I can open new windows, but not new tabs, splits, and so on. To make this pull request more compatible with Ghostty on Linux as it works today, maybe there is an opportunity to guard in the |
| ghostty-terminal-impl <direction> <program> [<arguments>] | ||
| direction is tab|window|up|down|left|right' ghostty-terminal-impl %{ | ||
| nop %sh{ | ||
| direction="$1" |
There was a problem hiding this comment.
A suggestion for Linux compatibility.
If uname is Darwin we can use $1 as the direction, but if uname is Linux then we can just eagerly set the direction to window since no other shell integration would work at this time.
| elif [ "$direction" = 'window' ]; then | ||
| osascript \ | ||
| -e "tell application \"Ghostty\"" \ | ||
| -e " set cfg to new surface configuration" \ | ||
| -e " set command of cfg to \"${cmd}\"" \ | ||
| -e " set wait after command of cfg to false" \ | ||
| -e " set newwin to new window with configuration cfg" \ | ||
| -e " activate window newwin" \ | ||
| -e "end tell" >/dev/null |
There was a problem hiding this comment.
For Linux compatibility, we should be able to basically slot in the existing wayland-terminal-window here, which is already working for me on Linux.
I just pulled up the version of the Wayland windowing module I'm currently using in case the reference is useful:
define-command wayland-terminal-window -params 1.. -docstring '
wayland-terminal-window <program> [<arguments>]: create a new terminal as a Wayland window
The program passed as argument will be executed in the new terminal' \
%{
evaluate-commands -save-regs 'a' %{
set-register a %arg{@}
evaluate-commands %sh{
if [ -z "${kak_opt_termcmd}" ]; then
echo "fail 'termcmd option is not set'"
exit
fi
termcmd=$kak_opt_termcmd
args=$kak_quoted_reg_a
unset kak_opt_termcmd kak_quoted_reg_a
setsid ${termcmd} "$args" < /dev/null > /dev/null 2>&1 &
}
}
}
complete-command wayland-terminal-window shell
It would need to be changed if it's going to be inside this elif, but yeah. Just want you to know that this is working for me already.
| [ -z "${kak_opt_windowing_modules}" ] || [ "$TERM" = "xterm-ghostty" ] || echo 'fail Ghostty not detected' | ||
| [ -x "$(which osascript)" ] || echo 'fail Ghostty detected; could not find osascript (macOS only)' | ||
| } | ||
| define-command -params 2.. -docstring ' |
There was a problem hiding this comment.
alexherbo2 says that
eval -client kak_client_in_given_ghostty_terminal ghostty-terminal-vertical kak -c %val{session}(where kak_client_in_given_ghostty_terminal should be substituted with a client name) should do the right thing, i.e. open a terminal to the right of the specified client, but it does not. This is probably impossible in Ghostty 1.3.1 for the same reason I gave for ghostty-focus below, but we should make this work in nightly.
I think we should also include in this module a comment listing commands and their expected outcome to use for regression testing.
There was a problem hiding this comment.
I've made this command work, but I now have a question: when opening a new window/tab/split should that client be focused automatically or should focus remain on the client you opened it from?
There was a problem hiding this comment.
I think we shouldn’t do anything special.
@benjaminwil I don't have a linux machine to test with but please let me know if you have something more concrete I should include in this PR. The docs say that |
…on}` ghostty-terminal-impl was operating on the Ghostty focused terminal, not the terminal containing the current client.
|
Hey @lrworth, I'll leave it to you and the I have tested that this is working as expected. 👍 I would personally rather use this |
Ghostty as of 1.3.0 supports AppleScript on macOS. This can be used to implement
ghostty-terminal-%opt{windowing_placement}, to create splits, tabs, and windows. Milestone for the unreleased 1.4.0 includes ghostty-org/ghostty#11592 which can be used to support theghostty-focuscommand. I have tested this on the nightly build.I've been using this for a few days now and it seems to work how it should.
I haven't considered Linux at all for this PR, except that the
ghosttymodule should fail gracefully on that platform. I haven't tested on Linux. A Linux Ghostty integration would look quite different, assuming it is possible at all.