xenia/kakoune
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
main
kakoune/rc/windowing/kitty.kak

85 lines
2.7 KiB
Plaintext
Raw Permalink Normal View History

Implement smarter detection of windowing environments. This patch centralises the loading of windowing environments, in order to ensure that by default only a single module is loaded, rather than the current code which can load multiple potentially incompatible modules; and in order to provide the user with more control over the loading of windowing modules. The patch introduces a new str-list option `windowing_modules` which defines an ordered list of windowing modules to attempt to load. Modules are loaded in the order specified in the list until a module loads without error, at which point the process finishes. When loaded each windowing module tests the environment to determine whether it should load (e.g. the tmux module tests to see if it's being run within a tmux session), and if it determines that it should then it completes its loading without error. If it doesn't detect an appropriate environment then it returns an error, and the module loading logic tries the next module. The user can override the default `windowing_modules` list to specify their preferred modules (i.e. they can put kitty ahead of tmux if that's their preference, or they can leave out the x11 modules alltogether). In addition, if the `windowing_modules` option is an empty list this bypasses the environment detection logic completely, and allows the modules to be loaded manually - this allows a user to replace the windowing module loading logic with their own manual set up.
2020-07-05 04:02:59 +02:00
# https://sw.kovidgoyal.net/kitty/index.html
# ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾
Add kitty.kak to support kitty integration
2018-06-19 11:39:45 +02:00
Added modules to extra files
2019-03-13 22:00:59 +01:00
provide-module kitty %{
Implement smarter detection of windowing environments. This patch centralises the loading of windowing environments, in order to ensure that by default only a single module is loaded, rather than the current code which can load multiple potentially incompatible modules; and in order to provide the user with more control over the loading of windowing modules. The patch introduces a new str-list option `windowing_modules` which defines an ordered list of windowing modules to attempt to load. Modules are loaded in the order specified in the list until a module loads without error, at which point the process finishes. When loaded each windowing module tests the environment to determine whether it should load (e.g. the tmux module tests to see if it's being run within a tmux session), and if it determines that it should then it completes its loading without error. If it doesn't detect an appropriate environment then it returns an error, and the module loading logic tries the next module. The user can override the default `windowing_modules` list to specify their preferred modules (i.e. they can put kitty ahead of tmux if that's their preference, or they can leave out the x11 modules alltogether). In addition, if the `windowing_modules` option is an empty list this bypasses the environment detection logic completely, and allows the modules to be loaded manually - this allows a user to replace the windowing module loading logic with their own manual set up.
2020-07-05 04:02:59 +02:00
# ensure that we're running on kitty
evaluate-commands %sh{
Fix syntax errors.
2020-07-06 13:55:54 +02:00
[ -z "${kak_opt_windowing_modules}" ] || [ "$TERM" = "xterm-kitty" ] || echo 'fail Kitty not detected'
Implement smarter detection of windowing environments. This patch centralises the loading of windowing environments, in order to ensure that by default only a single module is loaded, rather than the current code which can load multiple potentially incompatible modules; and in order to provide the user with more control over the loading of windowing modules. The patch introduces a new str-list option `windowing_modules` which defines an ordered list of windowing modules to attempt to load. Modules are loaded in the order specified in the list until a module loads without error, at which point the process finishes. When loaded each windowing module tests the environment to determine whether it should load (e.g. the tmux module tests to see if it's being run within a tmux session), and if it determines that it should then it completes its loading without error. If it doesn't detect an appropriate environment then it returns an error, and the module loading logic tries the next module. The user can override the default `windowing_modules` list to specify their preferred modules (i.e. they can put kitty ahead of tmux if that's their preference, or they can leave out the x11 modules alltogether). In addition, if the `windowing_modules` option is an empty list this bypasses the environment detection logic completely, and allows the modules to be loaded manually - this allows a user to replace the windowing module loading logic with their own manual set up.
2020-07-05 04:02:59 +02:00
}
use kitty launch command, make commands consistent `new-window` is a legacy command (see https://github.com/kovidgoyal/kitty/issues/2708). `KITTY_WINDOW_ID` should be set for any kitty window anyways.
2021-03-04 20:22:59 +01:00
declare-option -docstring %{window type that kitty creates on new and repl calls (window|os-window)} str kitty_window_type window
Added modules to extra files
2019-03-13 22:00:59 +01:00
rc windowing: allow to configure windowing system and window placement in new/terminal commands Today I can control "terminal" and "new" by changing the terminal alias but I always need to choose a concrete implementation, like "tmux-terminal-horizontal", even when there is otherwise no need to mention tmux in my config. Allow to configure windowing system and window placement independently by introducing dedicated options. This allows to create mappings that work in any windowing system like map global user c %{:with-option windowing_placement window new<ret>} map global user '"' %{:with-option windowing_placement vertical new<ret>} map global user '%' %{:with-option windowing_placement horizontal new<ret>} For windowing systems that don't support all placements, you can wrap the above in try/catch to fall back on the "window" variant which is defined for all windowing systems. When using multiple (nested) windowing systems, you might want to add mappings like map global user t %{:with-option windowing_module tmux new<ret>} map global user T %{:with-option windowing_module wayland new<ret>} --- This changes the default "terminal" alias for some modules. In particular, instead of delegating to iterm-terminal-vertical screen-terminal-vertical tmux-terminal-horizontal wezterm-terminal-vertical it will now by default delegate to the respective "-window" variant. We could maintain backwards compatiblity here by setting the "windowing_placement" option accordingly, but the new behavior seems more logical? Also, this removes the "terminal-tab" alias which was only defined by the kitty module. We could try to keep the alias approach and implement a "with-alias" command, however that approach can only capture both dimensions (windowing system and placement) if we add tons of commands like "terminal-horizontal" (with implied windowing system) and "tmux-terminal" (with implied placement). Side thought: we could also get rid of the "focus" alias and instead define define-command focus %{ "%opt{windowing_module}-focus" } Closes #3943, #4425
2023-11-01 11:21:19 +01:00
define-command kitty-terminal-window -params 1.. -docstring '
kitty-terminal-window <program> [<arguments>]: create a new terminal as a kitty window
Rework 'terminal' commands * Arguments of the kakoune command are now preserved in the shell call * Escaping logic is moved from 'new' to 'terminal'
2018-12-21 18:14:28 +01:00
The program passed as argument will be executed in the new terminal' \
Expose a 'terminal' command for the various windowing systems It allows plugins to create generic terminal using the user's preferred windowing system For example, it can be used to run fzf, gdb or simply a shell. * 'new' commands are refactored to simply use the 'terminal' one * style and docstrings has been unified * all windowing systems go through "sh -c" for consistency purposes, even if unnecessary
2018-12-02 13:59:45 +01:00
%{
nop %sh{
use kitty launch command, make commands consistent `new-window` is a legacy command (see https://github.com/kovidgoyal/kitty/issues/2708). `KITTY_WINDOW_ID` should be set for any kitty window anyways.
2021-03-04 20:22:59 +01:00
match=""
Match on kitty window id when available This ensures new window are created in the same os window as the current client instead of the default one. Closes #4009
2021-02-28 22:47:09 +01:00
if [ -n "$kak_client_env_KITTY_WINDOW_ID" ]; then
Match against kitty window id directly when using kitty @ launch When launch matches using `id` kitty tries to match against tab id before matching windows. When there are multiple tabs it's likely to match a tab before matching a window. Use `window_id` directly to avoid any possiblity of matching tabs. This is only needed for `kitty @ launch` for other commands there is no specific `window_id` field.
2023-05-07 12:04:55 +02:00
match="--match=window_id:$kak_client_env_KITTY_WINDOW_ID"
Match on kitty window id when available This ensures new window are created in the same os window as the current client instead of the default one. Closes #4009
2021-02-28 22:47:09 +01:00
fi
use kitty launch command, make commands consistent `new-window` is a legacy command (see https://github.com/kovidgoyal/kitty/issues/2708). `KITTY_WINDOW_ID` should be set for any kitty window anyways.
2021-03-04 20:22:59 +01:00
listen=""
if [ -n "$kak_client_env_KITTY_LISTEN_ON" ]; then
listen="--to=$kak_client_env_KITTY_LISTEN_ON"
Respect KITTY_LISTEN_ON when launching terminal
2021-01-21 10:58:48 +01:00
fi
use kitty launch command, make commands consistent `new-window` is a legacy command (see https://github.com/kovidgoyal/kitty/issues/2708). `KITTY_WINDOW_ID` should be set for any kitty window anyways.
2021-03-04 20:22:59 +01:00
kitty @ $listen launch --no-response --type="$kak_opt_kitty_window_type" --cwd="$PWD" $match "$@"
Expose a 'terminal' command for the various windowing systems It allows plugins to create generic terminal using the user's preferred windowing system For example, it can be used to run fzf, gdb or simply a shell. * 'new' commands are refactored to simply use the 'terminal' one * style and docstrings has been unified * all windowing systems go through "sh -c" for consistency purposes, even if unnecessary
2018-12-02 13:59:45 +01:00
}
}
rc windowing: allow to configure windowing system and window placement in new/terminal commands Today I can control "terminal" and "new" by changing the terminal alias but I always need to choose a concrete implementation, like "tmux-terminal-horizontal", even when there is otherwise no need to mention tmux in my config. Allow to configure windowing system and window placement independently by introducing dedicated options. This allows to create mappings that work in any windowing system like map global user c %{:with-option windowing_placement window new<ret>} map global user '"' %{:with-option windowing_placement vertical new<ret>} map global user '%' %{:with-option windowing_placement horizontal new<ret>} For windowing systems that don't support all placements, you can wrap the above in try/catch to fall back on the "window" variant which is defined for all windowing systems. When using multiple (nested) windowing systems, you might want to add mappings like map global user t %{:with-option windowing_module tmux new<ret>} map global user T %{:with-option windowing_module wayland new<ret>} --- This changes the default "terminal" alias for some modules. In particular, instead of delegating to iterm-terminal-vertical screen-terminal-vertical tmux-terminal-horizontal wezterm-terminal-vertical it will now by default delegate to the respective "-window" variant. We could maintain backwards compatiblity here by setting the "windowing_placement" option accordingly, but the new behavior seems more logical? Also, this removes the "terminal-tab" alias which was only defined by the kitty module. We could try to keep the alias approach and implement a "with-alias" command, however that approach can only capture both dimensions (windowing system and placement) if we add tons of commands like "terminal-horizontal" (with implied windowing system) and "tmux-terminal" (with implied placement). Side thought: we could also get rid of the "focus" alias and instead define define-command focus %{ "%opt{windowing_module}-focus" } Closes #3943, #4425
2023-11-01 11:21:19 +01:00
complete-command kitty-terminal-window shell
Expose a 'terminal' command for the various windowing systems It allows plugins to create generic terminal using the user's preferred windowing system For example, it can be used to run fzf, gdb or simply a shell. * 'new' commands are refactored to simply use the 'terminal' one * style and docstrings has been unified * all windowing systems go through "sh -c" for consistency purposes, even if unnecessary
2018-12-02 13:59:45 +01:00
Add a complete-command command to configure command completion This makes it possible to change command completion in hooks and paves the way to more flexibility in how custom commands can be completed
2022-02-22 10:14:47 +01:00
define-command kitty-terminal-tab -params 1.. -docstring '
Rework 'terminal' commands * Arguments of the kakoune command are now preserved in the shell call * Escaping logic is moved from 'new' to 'terminal'
2018-12-21 18:14:28 +01:00
kitty-terminal-tab <program> [<arguments>]: create a new terminal as kitty tab
The program passed as argument will be executed in the new terminal' \
Expose a 'terminal' command for the various windowing systems It allows plugins to create generic terminal using the user's preferred windowing system For example, it can be used to run fzf, gdb or simply a shell. * 'new' commands are refactored to simply use the 'terminal' one * style and docstrings has been unified * all windowing systems go through "sh -c" for consistency purposes, even if unnecessary
2018-12-02 13:59:45 +01:00
%{
nop %sh{
use kitty launch command, make commands consistent `new-window` is a legacy command (see https://github.com/kovidgoyal/kitty/issues/2708). `KITTY_WINDOW_ID` should be set for any kitty window anyways.
2021-03-04 20:22:59 +01:00
match=""
Match on kitty window id when available This ensures new window are created in the same os window as the current client instead of the default one. Closes #4009
2021-02-28 22:47:09 +01:00
if [ -n "$kak_client_env_KITTY_WINDOW_ID" ]; then
Match against kitty window id directly when using kitty @ launch When launch matches using `id` kitty tries to match against tab id before matching windows. When there are multiple tabs it's likely to match a tab before matching a window. Use `window_id` directly to avoid any possiblity of matching tabs. This is only needed for `kitty @ launch` for other commands there is no specific `window_id` field.
2023-05-07 12:04:55 +02:00
match="--match=window_id:$kak_client_env_KITTY_WINDOW_ID"
Match on kitty window id when available This ensures new window are created in the same os window as the current client instead of the default one. Closes #4009
2021-02-28 22:47:09 +01:00
fi
use kitty launch command, make commands consistent `new-window` is a legacy command (see https://github.com/kovidgoyal/kitty/issues/2708). `KITTY_WINDOW_ID` should be set for any kitty window anyways.
2021-03-04 20:22:59 +01:00
listen=""
if [ -n "$kak_client_env_KITTY_LISTEN_ON" ]; then
listen="--to=$kak_client_env_KITTY_LISTEN_ON"
Support KITTY_LISTEN_ON on kitty-terminal-tab and kitty-focus
2021-01-22 01:19:35 +01:00
fi
use kitty launch command, make commands consistent `new-window` is a legacy command (see https://github.com/kovidgoyal/kitty/issues/2708). `KITTY_WINDOW_ID` should be set for any kitty window anyways.
2021-03-04 20:22:59 +01:00
kitty @ $listen launch --no-response --type=tab --cwd="$PWD" $match "$@"
Expose a 'terminal' command for the various windowing systems It allows plugins to create generic terminal using the user's preferred windowing system For example, it can be used to run fzf, gdb or simply a shell. * 'new' commands are refactored to simply use the 'terminal' one * style and docstrings has been unified * all windowing systems go through "sh -c" for consistency purposes, even if unnecessary
2018-12-02 13:59:45 +01:00
}
}
Add a complete-command command to configure command completion This makes it possible to change command completion in hooks and paves the way to more flexibility in how custom commands can be completed
2022-02-22 10:14:47 +01:00
complete-command kitty-terminal-tab shell
Expose a 'terminal' command for the various windowing systems It allows plugins to create generic terminal using the user's preferred windowing system For example, it can be used to run fzf, gdb or simply a shell. * 'new' commands are refactored to simply use the 'terminal' one * style and docstrings has been unified * all windowing systems go through "sh -c" for consistency purposes, even if unnecessary
2018-12-02 13:59:45 +01:00
Add a complete-command command to configure command completion This makes it possible to change command completion in hooks and paves the way to more flexibility in how custom commands can be completed
2022-02-22 10:14:47 +01:00
define-command kitty-focus -params ..1 -docstring '
Expose a 'terminal' command for the various windowing systems It allows plugins to create generic terminal using the user's preferred windowing system For example, it can be used to run fzf, gdb or simply a shell. * 'new' commands are refactored to simply use the 'terminal' one * style and docstrings has been unified * all windowing systems go through "sh -c" for consistency purposes, even if unnecessary
2018-12-02 13:59:45 +01:00
kitty-focus [<client>]: focus the given client
If no client is passed then the current one is used' \
%{
evaluate-commands %sh{
Add kitty.kak to support kitty integration
2018-06-19 11:39:45 +02:00
if [ $# -eq 1 ]; then
Expose a 'terminal' command for the various windowing systems It allows plugins to create generic terminal using the user's preferred windowing system For example, it can be used to run fzf, gdb or simply a shell. * 'new' commands are refactored to simply use the 'terminal' one * style and docstrings has been unified * all windowing systems go through "sh -c" for consistency purposes, even if unnecessary
2018-12-02 13:59:45 +01:00
printf "evaluate-commands -client '%s' focus" "$1"
Add kitty.kak to support kitty integration
2018-06-19 11:39:45 +02:00
else
use kitty launch command, make commands consistent `new-window` is a legacy command (see https://github.com/kovidgoyal/kitty/issues/2708). `KITTY_WINDOW_ID` should be set for any kitty window anyways.
2021-03-04 20:22:59 +01:00
match=""
if [ -n "$kak_client_env_KITTY_WINDOW_ID" ]; then
match="--match=id:$kak_client_env_KITTY_WINDOW_ID"
Support KITTY_LISTEN_ON on kitty-terminal-tab and kitty-focus
2021-01-22 01:19:35 +01:00
fi
use kitty launch command, make commands consistent `new-window` is a legacy command (see https://github.com/kovidgoyal/kitty/issues/2708). `KITTY_WINDOW_ID` should be set for any kitty window anyways.
2021-03-04 20:22:59 +01:00
listen=""
if [ -n "$kak_client_env_KITTY_LISTEN_ON" ]; then
listen="--to=$kak_client_env_KITTY_LISTEN_ON"
fi
kitty @ $listen focus-window --no-response $match
Add kitty.kak to support kitty integration
2018-06-19 11:39:45 +02:00
fi
Expose a 'terminal' command for the various windowing systems It allows plugins to create generic terminal using the user's preferred windowing system For example, it can be used to run fzf, gdb or simply a shell. * 'new' commands are refactored to simply use the 'terminal' one * style and docstrings has been unified * all windowing systems go through "sh -c" for consistency purposes, even if unnecessary
2018-12-02 13:59:45 +01:00
}
}
rc windowing: use menu behavior for focus We can complete every possible client argument.
2022-07-19 15:56:05 +02:00
complete-command -menu kitty-focus client
Expose a 'terminal' command for the various windowing systems It allows plugins to create generic terminal using the user's preferred windowing system For example, it can be used to run fzf, gdb or simply a shell. * 'new' commands are refactored to simply use the 'terminal' one * style and docstrings has been unified * all windowing systems go through "sh -c" for consistency purposes, even if unnecessary
2018-12-02 13:59:45 +01:00
Added modules to extra files
2019-03-13 22:00:59 +01:00
alias global focus kitty-focus
rc windowing: allow to configure windowing system and window placement in new/terminal commands Today I can control "terminal" and "new" by changing the terminal alias but I always need to choose a concrete implementation, like "tmux-terminal-horizontal", even when there is otherwise no need to mention tmux in my config. Allow to configure windowing system and window placement independently by introducing dedicated options. This allows to create mappings that work in any windowing system like map global user c %{:with-option windowing_placement window new<ret>} map global user '"' %{:with-option windowing_placement vertical new<ret>} map global user '%' %{:with-option windowing_placement horizontal new<ret>} For windowing systems that don't support all placements, you can wrap the above in try/catch to fall back on the "window" variant which is defined for all windowing systems. When using multiple (nested) windowing systems, you might want to add mappings like map global user t %{:with-option windowing_module tmux new<ret>} map global user T %{:with-option windowing_module wayland new<ret>} --- This changes the default "terminal" alias for some modules. In particular, instead of delegating to iterm-terminal-vertical screen-terminal-vertical tmux-terminal-horizontal wezterm-terminal-vertical it will now by default delegate to the respective "-window" variant. We could maintain backwards compatiblity here by setting the "windowing_placement" option accordingly, but the new behavior seems more logical? Also, this removes the "terminal-tab" alias which was only defined by the kitty module. We could try to keep the alias approach and implement a "with-alias" command, however that approach can only capture both dimensions (windowing system and placement) if we add tons of commands like "terminal-horizontal" (with implied windowing system) and "tmux-terminal" (with implied placement). Side thought: we could also get rid of the "focus" alias and instead define define-command focus %{ "%opt{windowing_module}-focus" } Closes #3943, #4425
2023-11-01 11:21:19 +01:00
# deprecated
define-command -hidden kitty-terminal -params 1.. %{
kitty-terminal-window %arg{@}
}
Added modules to extra files
2019-03-13 22:00:59 +01:00
}
Reference in New Issue Copy Permalink