kakoune/rc/extra/x11-repl.kak

# termcmd should already be set in x11.kak
def -docstring %{x11-repl [<arguments>]: create a new window for repl interaction
All optional parameters are forwarded to the new window} \
    -params .. \
    -command-completion \
    x11-repl %{ %sh{
        if [ -z "${kak_opt_termcmd}" ]; then
           echo "echo -color Error 'termcmd option is not set'"
           exit
        fi
        if [ $# -eq 0 ]; then cmd="bash"; else cmd="$@"; fi
        setsid ${kak_opt_termcmd} ${cmd} -t kak_repl_window < /dev/null > /dev/null 2>&1 &
}}

def x11-send-text -docstring "send the selected text to the repl window" %{
    nop %sh{
        printf %s\\n "${kak_selection}" | xsel -i
        wid=$(xdotool getactivewindow)
        xdotool search --name kak_repl_window windowactivate
        xdotool key --clearmodifiers "Shift+Insert"
        xdotool windowactivate $wid
    }
}

alias global repl x11-repl
alias global send-text x11-send-text
split x11 repl functionality to x11-repl.kak 2016-01-26 14:05:35 +01:00			`# termcmd should already be set in x11.kak`
Fix, complete and add docstring documentation to builtin commands Level out the builtin commands loaded at startup in terms of format and expressiveness. The following convention was followed: * commands that take more than one argument have to be described along with their parameters prior to the actual documentation, otherwise the docstring consists in a capitalized sentence e.g. `command <arg1>: do something` * optional arguments are enclosed in square brackets, to comply with the format used for hardcoded commands e.g. `cd [<directory>]` * describe the effects of the command in the documentation string and omit implementation details unless they are relevant. Usually command names include the name of the tool they use, so they don't need to be redundantly mentioned e.g. `tmux-new-pane <arguments>: open a new pane` * document the format the parameters to the commands, or list them if they are to be chosen among a list of static values (c.f. `spell.kak`) 2016-10-11 09:03:41 +02:00			`def -docstring %{x11-repl [<arguments>]: create a new window for repl interaction`
			`All optional parameters are forwarded to the new window} \`
			`-params .. \`
split x11 repl functionality to x11-repl.kak 2016-01-26 14:05:35 +01:00			`-command-completion \`
			`x11-repl %{ %sh{`
			`if [ -z "${kak_opt_termcmd}" ]; then`
Pass a generic pattern to `printf` calls, use `echo` when possible 2016-04-23 07:47:01 +02:00			`echo "echo -color Error 'termcmd option is not set'"`
split x11 repl functionality to x11-repl.kak 2016-01-26 14:05:35 +01:00			`exit`
			`fi`
Fix, complete and add docstring documentation to builtin commands Level out the builtin commands loaded at startup in terms of format and expressiveness. The following convention was followed: * commands that take more than one argument have to be described along with their parameters prior to the actual documentation, otherwise the docstring consists in a capitalized sentence e.g. `command <arg1>: do something` * optional arguments are enclosed in square brackets, to comply with the format used for hardcoded commands e.g. `cd [<directory>]` * describe the effects of the command in the documentation string and omit implementation details unless they are relevant. Usually command names include the name of the tool they use, so they don't need to be redundantly mentioned e.g. `tmux-new-pane <arguments>: open a new pane` * document the format the parameters to the commands, or list them if they are to be chosen among a list of static values (c.f. `spell.kak`) 2016-10-11 09:03:41 +02:00			`if [ $# -eq 0 ]; then cmd="bash"; else cmd="$@"; fi`
split x11 repl functionality to x11-repl.kak 2016-01-26 14:05:35 +01:00			`setsid ${kak_opt_termcmd} ${cmd} -t kak_repl_window < /dev/null > /dev/null 2>&1 &`
			`}}`

Fix, complete and add docstring documentation to builtin commands Level out the builtin commands loaded at startup in terms of format and expressiveness. The following convention was followed: * commands that take more than one argument have to be described along with their parameters prior to the actual documentation, otherwise the docstring consists in a capitalized sentence e.g. `command <arg1>: do something` * optional arguments are enclosed in square brackets, to comply with the format used for hardcoded commands e.g. `cd [<directory>]` * describe the effects of the command in the documentation string and omit implementation details unless they are relevant. Usually command names include the name of the tool they use, so they don't need to be redundantly mentioned e.g. `tmux-new-pane <arguments>: open a new pane` * document the format the parameters to the commands, or list them if they are to be chosen among a list of static values (c.f. `spell.kak`) 2016-10-11 09:03:41 +02:00			`def x11-send-text -docstring "send the selected text to the repl window" %{`
Avoid interpretting eventual output in send-text implementations 2016-01-28 20:30:49 +01:00			`nop %sh{`
Pass a generic pattern to `printf` calls, use `echo` when possible 2016-04-23 07:47:01 +02:00			`printf %s\\n "${kak_selection}" \| xsel -i`
split x11 repl functionality to x11-repl.kak 2016-01-26 14:05:35 +01:00			`wid=$(xdotool getactivewindow)`
			`xdotool search --name kak_repl_window windowactivate`
			`xdotool key --clearmodifiers "Shift+Insert"`
			`xdotool windowactivate $wid`
			`}`
			`}`

			`alias global repl x11-repl`
			`alias global send-text x11-send-text`