PolytreeDE/alacritty
1
0
Fork 0
mirror of https://github.com/alacritty/alacritty.git synced 2024-11-11 13:51:01 -05:00
Code Releases Activity
alacritty/extra/completions/_alacritty

129 lines
4.6 KiB
Text
Raw Normal View History

Add shell completions and manpage * Add manpage Adds a basic manpage that was autogenerated with `help2man` and then slightly adjusted with information from the README.md and better formatting. * Add zsh completions Add completions for the zsh shell. These should be complete and even allow completion of the command inside `--command` and `-e`. * Add bash completions The bash completions are almost on the same level as the zsh completions. The only little thing the bash completions do not do is complete inside of `--command` and `-e`, instead bash just stops completion after these options. * Update readme with manpage and completions Added the install instructions for the manpage and completions to the README.md. Also tweaked the current readme a slight bit because the build section was structured in a slightly confusing way.
2018-03-07 16:34:05 -05:00
#compdef alacritty
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
autoload -U is-at-least
Add shell completions and manpage * Add manpage Adds a basic manpage that was autogenerated with `help2man` and then slightly adjusted with information from the README.md and better formatting. * Add zsh completions Add completions for the zsh shell. These should be complete and even allow completion of the command inside `--command` and `-e`. * Add bash completions The bash completions are almost on the same level as the zsh completions. The only little thing the bash completions do not do is complete inside of `--command` and `-e`, instead bash just stops completion after these options. * Update readme with manpage and completions Added the install instructions for the manpage and completions to the README.md. Also tweaked the current readme a slight bit because the build section was structured in a slightly confusing way.
2018-03-07 16:34:05 -05:00
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
_alacritty() {
typeset -A opt_args
typeset -a _arguments_options
local ret=1
Add multi-window support Previously Alacritty would always initialize only a single terminal emulator window feeding into the winit event loop, however some platforms like macOS expect all windows to be spawned by the same process and this "daemon-mode" can also come with the advantage of increased memory efficiency. The event loop has been restructured to handle all window-specific events only by the event processing context with the associated window id. This makes it possible to add new terminal windows at any time using the WindowContext::new function call. Some preliminary tests have shown that for empty terminals, this reduces the cost of additional terminal emulators from ~100M to ~6M. However at this point the robustness of the daemon against issues with individual terminals has not been refined, making the reliability of this system questionable. New windows can be created either by using the new `CreateNewWindow` action, or with the `alacritty msg create-window` subcommand. The subcommand sends a message to an IPC socket which Alacritty listens on, its location can be found in the `ALACRITTY_SOCKET` environment variable. Fixes #607.
2021-10-23 03:16:47 -04:00
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
if is-at-least 5.2; then
_arguments_options=(-s -S -C)
else
_arguments_options=(-s -C)
fi
Add multi-window support Previously Alacritty would always initialize only a single terminal emulator window feeding into the winit event loop, however some platforms like macOS expect all windows to be spawned by the same process and this "daemon-mode" can also come with the advantage of increased memory efficiency. The event loop has been restructured to handle all window-specific events only by the event processing context with the associated window id. This makes it possible to add new terminal windows at any time using the WindowContext::new function call. Some preliminary tests have shown that for empty terminals, this reduces the cost of additional terminal emulators from ~100M to ~6M. However at this point the robustness of the daemon against issues with individual terminals has not been refined, making the reliability of this system questionable. New windows can be created either by using the new `CreateNewWindow` action, or with the `alacritty msg create-window` subcommand. The subcommand sends a message to an IPC socket which Alacritty listens on, its location can be found in the `ALACRITTY_SOCKET` environment variable. Fixes #607.
2021-10-23 03:16:47 -04:00
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
local context curcontext="$curcontext" state line
_arguments "${_arguments_options[@]}" \
Migrate from structopt to clap 3
2022-01-04 13:25:26 -05:00
'--embed=[Defines the X11 window ID (as a decimal integer) to embed Alacritty within]:EMBED: ' \
'--config-file=[Specify alternative configuration file \[default: $XDG_CONFIG_HOME/alacritty/alacritty.yml\]]:CONFIG_FILE: ' \
'--socket=[Path for IPC socket creation]:SOCKET: ' \
'*-o+[Override configuration file options \[example: cursor.style=Beam\]]:OPTION: ' \
'*--option=[Override configuration file options \[example: cursor.style=Beam\]]:OPTION: ' \
'--working-directory=[Start the shell in the specified working directory]:WORKING_DIRECTORY: ' \
'*-e+[Command and args to execute (must be last argument)]:COMMAND: ' \
'*--command=[Command and args to execute (must be last argument)]:COMMAND: ' \
'-t+[Defines the window title \[default: Alacritty\]]:TITLE: ' \
'--title=[Defines the window title \[default: Alacritty\]]:TITLE: ' \
'--class=[Defines window class/app_id on X11/Wayland \[default: Alacritty\]]:instance> | <instance>,<general: ' \
'-h[Print help information]' \
'--help[Print help information]' \
'-V[Print version information]' \
'--version[Print version information]' \
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
'--print-events[Print all events to stdout]' \
'--ref-test[Generates ref test]' \
'(-v)*-q[Reduces the level of verbosity (the min level is -qq)]' \
'(-q)*-v[Increases the level of verbosity (the max level is -vvv)]' \
Add parameters to `msg create-window` subcommand Alacritty's `msg create-window` subcommand would previously inherit all the CLI parameters from the original executable. However not only could this lead to unexpected behavior, it also prevents multi-window users from making use of parameters like `-e`, `--working-directory`, or `--hold`. This is solved by adding a JSON-based message format to the IPC socket messages which instructs the Alacritty server on which CLI parameters should be used to create the new window. Fixes #5562. Fixes #5561. Fixes #5560.
2021-11-22 13:34:09 -05:00
'--hold[Remain open after child process exit]' \
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
":: :_alacritty_commands" \
"*::: :->alacritty" \
&& ret=0
case $state in
(alacritty)
words=($line[1] "${words[@]}")
(( CURRENT += 1 ))
curcontext="${curcontext%:*:*}:alacritty-command-$line[1]:"
case $line[1] in
(msg)
_arguments "${_arguments_options[@]}" \
Migrate from structopt to clap 3
2022-01-04 13:25:26 -05:00
'-s+[IPC socket connection path override]:SOCKET: ' \
'--socket=[IPC socket connection path override]:SOCKET: ' \
'-h[Print help information]' \
'--help[Print help information]' \
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
":: :_alacritty__msg_commands" \
"*::: :->msg" \
&& ret=0
Migrate from structopt to clap 3
2022-01-04 13:25:26 -05:00
case $state in
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
(msg)
words=($line[1] "${words[@]}")
(( CURRENT += 1 ))
curcontext="${curcontext%:*:*}:alacritty-msg-command-$line[1]:"
case $line[1] in
(create-window)
_arguments "${_arguments_options[@]}" \
Migrate from structopt to clap 3
2022-01-04 13:25:26 -05:00
'--working-directory=[Start the shell in the specified working directory]:WORKING_DIRECTORY: ' \
'*-e+[Command and args to execute (must be last argument)]:COMMAND: ' \
'*--command=[Command and args to execute (must be last argument)]:COMMAND: ' \
'-t+[Defines the window title \[default: Alacritty\]]:TITLE: ' \
'--title=[Defines the window title \[default: Alacritty\]]:TITLE: ' \
'--class=[Defines window class/app_id on X11/Wayland \[default: Alacritty\]]:instance> | <instance>,<general: ' \
'--version[Print version information]' \
Add parameters to `msg create-window` subcommand Alacritty's `msg create-window` subcommand would previously inherit all the CLI parameters from the original executable. However not only could this lead to unexpected behavior, it also prevents multi-window users from making use of parameters like `-e`, `--working-directory`, or `--hold`. This is solved by adding a JSON-based message format to the IPC socket messages which instructs the Alacritty server on which CLI parameters should be used to create the new window. Fixes #5562. Fixes #5561. Fixes #5560.
2021-11-22 13:34:09 -05:00
'--hold[Remain open after child process exit]' \
Migrate from structopt to clap 3
2022-01-04 13:25:26 -05:00
'-h[Print help information]' \
'--help[Print help information]' \
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
&& ret=0
;;
(help)
_arguments "${_arguments_options[@]}" \
Migrate from structopt to clap 3
2022-01-04 13:25:26 -05:00
'--version[Print version information]' \
'-h[Print help information]' \
'--help[Print help information]' \
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
&& ret=0
;;
esac
;;
esac
;;
(help)
_arguments "${_arguments_options[@]}" \
&& ret=0
;;
esac
;;
esac
Add multi-window support Previously Alacritty would always initialize only a single terminal emulator window feeding into the winit event loop, however some platforms like macOS expect all windows to be spawned by the same process and this "daemon-mode" can also come with the advantage of increased memory efficiency. The event loop has been restructured to handle all window-specific events only by the event processing context with the associated window id. This makes it possible to add new terminal windows at any time using the WindowContext::new function call. Some preliminary tests have shown that for empty terminals, this reduces the cost of additional terminal emulators from ~100M to ~6M. However at this point the robustness of the daemon against issues with individual terminals has not been refined, making the reliability of this system questionable. New windows can be created either by using the new `CreateNewWindow` action, or with the `alacritty msg create-window` subcommand. The subcommand sends a message to an IPC socket which Alacritty listens on, its location can be found in the `ALACRITTY_SOCKET` environment variable. Fixes #607.
2021-10-23 03:16:47 -04:00
}
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
(( $+functions[_alacritty_commands] )) ||
_alacritty_commands() {
local commands; commands=(
Migrate from structopt to clap 3
2022-01-04 13:25:26 -05:00
'msg:Send a message to the Alacritty socket' \
'help:Print this message or the help of the given subcommand(s)' \
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
)
_describe -t commands 'alacritty commands' commands "$@"
}
(( $+functions[_alacritty__msg__create-window_commands] )) ||
_alacritty__msg__create-window_commands() {
Migrate from structopt to clap 3
2022-01-04 13:25:26 -05:00
local commands; commands=()
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
_describe -t commands 'alacritty msg create-window commands' commands "$@"
}
(( $+functions[_alacritty__help_commands] )) ||
_alacritty__help_commands() {
Migrate from structopt to clap 3
2022-01-04 13:25:26 -05:00
local commands; commands=()
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
_describe -t commands 'alacritty help commands' commands "$@"
}
(( $+functions[_alacritty__msg__help_commands] )) ||
_alacritty__msg__help_commands() {
Migrate from structopt to clap 3
2022-01-04 13:25:26 -05:00
local commands; commands=()
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
_describe -t commands 'alacritty msg help commands' commands "$@"
}
(( $+functions[_alacritty__msg_commands] )) ||
_alacritty__msg_commands() {
local commands; commands=(
Migrate from structopt to clap 3
2022-01-04 13:25:26 -05:00
'create-window:Create a new window in the same Alacritty process' \
'help:Print this message or the help of the given subcommand(s)' \
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
)
_describe -t commands 'alacritty msg commands' commands "$@"
Add multi-window support Previously Alacritty would always initialize only a single terminal emulator window feeding into the winit event loop, however some platforms like macOS expect all windows to be spawned by the same process and this "daemon-mode" can also come with the advantage of increased memory efficiency. The event loop has been restructured to handle all window-specific events only by the event processing context with the associated window id. This makes it possible to add new terminal windows at any time using the WindowContext::new function call. Some preliminary tests have shown that for empty terminals, this reduces the cost of additional terminal emulators from ~100M to ~6M. However at this point the robustness of the daemon against issues with individual terminals has not been refined, making the reliability of this system questionable. New windows can be created either by using the new `CreateNewWindow` action, or with the `alacritty msg create-window` subcommand. The subcommand sends a message to an IPC socket which Alacritty listens on, its location can be found in the `ALACRITTY_SOCKET` environment variable. Fixes #607.
2021-10-23 03:16:47 -04:00
}
Switch to clap-generated completions The current completions required a lot of domain-specific knowledge about each individual shell and their completion functionality. Much of which is sparsely documented. While clap does not generate perfect completions, since parameters like `-e` are missing completions, it does a reasonable job while requiring no work on writing these completions. Since access to `cli.rs` isn't possible from the `build.rs`, these completions aren't always generated on build. Instead a test verifies that there has been no changes to these completions and provides a simple code sample for re-generating them. This should provide a simple solution with minimal overhead.
2021-11-19 18:34:40 -05:00
_alacritty "$@"
Copy permalink