Automatic reparsing of %sh{...}, while convenient in many cases,
can be surprising as well, and can lead to security problems:
'echo %sh{ printf "foo\necho bar" }' runs 'echo foo', then 'echo bar'.
we make this danger explicit, and we fix the 'nop %sh{...}' pattern.
To reparse %sh{...} strings, they can be passed to evaluate-commands,
which has been fixed to work in every cases where %sh{...} reparsing
was used..
- Ensure ranger opens with the currently focused client tty if multiple screen clients are connected to the same session.
- Ensure args are passed to ranger correctly.
- Ensure command-line args are passed to ranger correctly. (Only strict long format works e.g. `ranger --cmd="echo foo"`)
- Change the current directory because `screen -X` uses screen's cwd not kakoune's.
- Use heredoc to make escaping and quoting easier to debug and slightly less unpredictable.
- Use ranger's `--choosefiles` option instead of mapping keys and having to do multiple levels of escaping and quoting of args esp. command-line args which were unusable in `screen -X eval`.
- Remove screen region when user quits ranger.
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`)
