There does not seem to be any reasonable use cases of not collapsing
jumps when the input is not comming from the user. Always collapse
them.
It could make sense to move jump collapsing out of context_wrap as
in general any action not comming directly from the user should
collapse them, at the moment a comment or mapping will not collapse
jumps, which is unfortunate.
The use of `%{...%reg{...}}` was not being expanded correctly, as
the enclosing %{...} prevents the internal %expand{...} from being
considered.
The introduction of an additional command allows us to bypass
quoting hell as the expansion of %reg{5} could contain arbitrary
text.
That means we can now have highlighters active at global, buffer, and
window scope. The add-highlighter and remove-highlighter syntax changed
to take the parent path (scope/group/...) as a mandatory argument,
superseeding the previous -group switch.
- Use the classic unix file:line:(col:)? pattern for matching.
- The option `make_error_pattern` can be used to further restrict errors
to be matched (to include / exclude warnings, etc.
The current pattern used by the commands `make-next` and `make-prev`
are not suitable for all usages.
For example the go compiler will not suffix errors with `error: ` and is
not usable with these functions. This change allows the user to define
a custom error pattern, instead of having to work around the error (for
example using sed to insert the `error: ` suffix).
What do you think of this? I have not followed the current convention
of having options without separators (like `makecmd`). Also this does
not feel to be the right solution because the pattern has to be set at
global level.
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`)
