The -i flag on Mac OS means:
჻ man file | grep -i -- -i
-i If the file is a regular file, do not classify its contents.
The --mime-type option is (mostly) portable:
- Linux uses --mime-type
- macOS uses --mime-type
- FreeBSD uses --mime-type
- NetBSD uses --mime-type
- OpenBSD uses --mime-type and does not use the same implementation as everybody else
- Solaris does not support MIME types at all
There might legitimately be "|" characters in the message, so
we want to stop at the first one, the one that delimits the message location
from the message text.
Don't ask Kakoune to quote values we know can never contain shell-sensitive
characters, and flatten the kakquote() function to a single line for ease
of copy/pasting.
Fixes#2302, #3336.
Addresses parts of #3155.
Changes include:
- New `lint-selections` command that only lints the current selections,
and allows a custom lint command.
- New `lint-buffer` command that always lints the whole buffer with
the linter specified in the lintcmd option.
- `lint` alias for `lint-buffer`, for backwards compatibility.
- Errors and warnings are now shown in the Error and Information faces,
not hard-coded red and yellow.
- Error and warning flags now use "!" and "?" symbols respectively,
instead of a unicode block, so they can still be distinguished
in a monochrome colour-scheme or by colour-blind users.
- An error flag on a given line always takes precedence over a warning.
- All messages for the same line are collected into a multi-line message.
- We no longer escape tildes in messages, since that change was added
in commit ae339dc (2016) when we started using `%~~` to quote messages.
We stopped using `%~~` in commit 1a2eecd (2018).
- Anything the linter writes to stderr is logged to the *debug* buffer,
not lost.
- If the linter writes to stderr, an error is shown to the user instead
of the usual error/warning count.
- The `lint_errors` hidden option is replaced by `lint_messages`,
because it contains warnings as well as errors.
- `lint-next-error` renamed to `lint-next-message`,
and `lint-previous-error` renamed to `lint-previous-message`
for the same reason.
- New `lint-next-error` and `lint-previous-error` aliases,
for backwards compatibility.
- `lint-next-message` and `lint-previous-message` show the message
they jump to.
- Where `lint_errors` was a range-specs option, `lint_messages` is a
line-specs option to keep things simpler. This means lint-next-message
and lint-previous-message no longer jump to a specific column.
The first line returned by `aspell` isn't always an identification
string, it can also be an error.
This commit prevents the first line from being ignored in any case,
and allows errors to be reported consistently.
Related to #3330
This commit adds a `documentation` face to the builtin themes, used
to highlight common documentation syntaxes:
/**
* JavaDoc
*/
/*!
* QtDoc
*/
/// Inline documentation
## Inline documentation
The face is only an alias to the `comment` one for now.
Closes#1944
Adds support for highlighting git-status(1) output in short format
(--short) and with branch name (--branch), including file renames and
commits ahead/behind information.
Using `{\}` in an Awk script results in the following error being printed:
```
awk: cmd. line:18: warning: escape sequence `\}' treated as plain `}'
```
Previously, the keywords were a mess. They contained the shell’s
reserved words and some arbitrarily selected builtins. I generated
the word list using bash because it contains all POSIX builtins and
is common for scripting.
In variable assignments some characters that are allowed to be in
variables used to not be highlighted, e.g. hyphens. With this commit
all characters except whitespace are considered to be part of the
variable.
This commit implements a standalone shared highlighter group that
highlights Jinja statements and expressions.
The traditional way of highlighting file contents is to hook on the
file extension, and assign a custom filetype/highlighter group to
the current buffer. However, since Jinja templates can be based on
any text file format in existence, we do not have a specific file
extension to hook, and consequently, no custom "jinja" filetype.
The user is expected to add the `jinja` highlighter whenever required:
```
require-module jinja
add-highlighter window/ ref jinja
```
Alternatively, file extensions that are known to occasionally pair
with Jinja can be hooked from the user configuration:
```
hook global WinCreate .+\.html %[
try %[
execute-keys -draft \%s \{%|\{\{ <ret>
require-module jinja
add-highlighter window/ ref jinja
]
]
```
The above hook auto-detects statements/expressions (respectively
{%…%} and {{…}} expansions), but will cause false positives
(in terms of highlighting), and therefore isn't part of `jinja.kak`
by default.
