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..
Sometimes the implementation of `man` will display errors, e.g.
```
<standard input>:4808: warning [p 54, 13.2i]: can't break line
```
Those errors are harmless but are still reported on the debug buffer,
so we hide them by redirecting the standard error stream to /dev/null.
When using the `man` filetype to make use of the text highlighters
of the `man.kak` script, the documentation pages inherit from the
window resizing hooks that won't work on `doc` buffers.
Fixes#1591
The Debian implementation of `man-db` does not strip ANSI sequences out
of the file, even though the documentation says it would do so. The
commit that originally closed this issue wasn't related to the problem
experienced, this one hopefully addresses it.
This commit also addresses an issue with the `-i` flag in BSD `sed`
which expects an argument (the GNU implementation doesn't).
Fixes#1098
This commit uses options and flags that will work on both the BSD and
the `man-db` implementations, however those changes remain unportable as
the POSIX standard only defines a single `-k` flag for the utility,
which we don't need.
The call to the `col` utility has also been replaced by a call to `sed`,
as the former is only shipped on systems that have the `nroff` formatter
installed.
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`)
