The previous implementation used to replace the contents of the buffer with
whatever the `formatcmd` was returning, regardless of the exit code of the
command, which led to the buffer being wiped out on error.
This commit does the formatting in a temporary file, and only replaces the
current buffer with the contents of the -formatted- temporary file if the
`formatcmd` returned successfully.
Fixes#1357
These are less useful with more static words, and they are
woefully incomplete: no support -docstring for map, set
uses the variable face, but there is no corresponding
highlighter for decl or %opt{..}.
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
- 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.
The option is now used as a fallback when detection by extension fails. Some
scripts like `base/mail.kak` and `base/html.kak` still rely heavily on it.
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.
The default commenting character is now '#', considering the superior
amount of files that use it for comments compared to the previous
C-style comment characters.
The logic now also prioritize the opening commenting characters if they
contain a colon, to be able to use selection commenting on markdown
files.
This commit properly produces backslash characters within double quote
strings instead of hoping the shell will not recognize the escape
sequence that they form with the following character. Use the proper
POSIX function declaration form.
The uncommenting logic now also ignores trailing newline characters,
which shortens the amount of operations needed to uncomment a selection.
Initialising the `comment_line_chars` and `comment_selection_chars` variables
in language support scripts created a hard dependency of those scripts
to `commenting.kak`, which would create errors when this script was not
loaded, e.g. when running tests.
Initializing the `formatcmd` variable in the default language support
scripts created a dependency to the `formatter.kak` script, which we do
not want. Examples of such cases are when users haven't loaded the
`formatter.kak` script, or when Kakoune runs its test suite and
selectively loads some language scripts for testing purposes.
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`)
