* Add r7rs functions, keywords, etc.
* Add highlighting for decimal, hex, octal, binary constants
* Add missing word characters
* Resolve several issues with word boundaries
Similarly to the <semicolon> key, make it easier to write
`:execute-keys` commands by replacing <percent> with `%`.
Highlighters can keep escaping the sign when regular expressions are
not quoted, but built-in scripts that use `%` as an editing primitive
have been modified to use the named key, for clarity.
This commit renames `lint-enable` into `lint-show-diagnostics`,
makes it hidden, and calls it automatically after diagnostics have
been recovered by `:lint-cleaned-selections`.
The `lint-disable` command becomes `lint-hide-diagnostics`.
The concept of "enabling" diagnostics was inherited from the Clang
support script, but in that case it's not clear why calling `:lint`
should do the work but not render it (similarly to `:spell`).
The `lint-show` command was also renamed into a more descriptive
`lint-show-current-line`.
Ranges specified with a +<length> were inconsistent, with +0 meaning
an empty range, while +1 meant a two character long range (first character
+ the following one). Change that to mean a single character.
Fixes#3479
This commit removes declarations and mentions to the built-in `bold`
and `italic` faces.
While they could be a user-friendly way of customising how tokens
are emphasised in Markdown documents (similarly to the
`$LESS_TERMCAP_*` environment variables for `man` pagers), most other
markup languages do not have the concept of "strong" and "emphasis"
but refer directly to the font style/weight.
The faces were also not even set by default to highlight as their
names implied, so having markup language support scripts directly
use the +b and +i face attributes is more consistent.
Highlight every character between brackets, including more
brackets. This allows alternative constructs in INI files such as:
```
[section]
[[subsection]]
```
This commit also only applies the appropriate face on the section
name itself, not the entire line (including hypothetical surrounding
whitespace characters).
This adds support for the Eex templating that is used in the Phoenix
web framework. Eex files include HTML and Elixir code, and Elixir files
can include Eex in string literals marked with the `~L` prefix.
Additionally this unbreaks `"""` string literals, which did not work because
`"` was matched before `"""`
Calling `:lint-buffer` when `lintcmd` is empty results in a temporary
directory being created, but never removed when the underlying linting
code errors out.
In Ruby, identifiers can end with a `!` or `?` too, which means that `class!` or `end?`are not actually keywords, but regular identifiers. This fixes that by not using `\b` but `[^0-9A-Za-z_!?]` instead in some places.
Incrementally setting the lint variables triggers multiple refreshes,
including the text jumping as the guttter column is removed and re-
added. This causes the info message to disappear when linting is done
on NormalIdle.
Looks like hyphens and periods are sometimes printed as part of
git-log(1)’s graphing feature; for example, in this repository:
git log --graph 55e7f857
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.
This commit removes attempts to auto-detect the version of the local
Tmux binary.
The Tmux package that ships with OpenBSD doesn't have a version
number[1], and therefore doesn't provide any way to check if it's
compatible with the REPL module, making the feature disabled by
default in that distribution.
Fixes#3237.
[1] https://github.com/tmux/tmux/issues/1141#issuecomment-340244302
The `pick` command in a rebase commit is virtually a no-op, but other
commands actually do things. This commit visually communicates
that fact.
Fixes#3208.
If `-` is not first or last in a character classes, it matches a range based on
the character code. This applies to special characters as well as to
alphanumeric characters.
- Highlight `=` and `|` as keywords (like `->` and `:`)
- Highlight custom operators (I guess they aren't really custom as of Elm 0.19
but there are still a bunch "built in").
This commit adds a `spell_lang` option that will be used by the
`spell` command when no language is passed to it directly.
Setting a buffer/window local option allows using `:spell` seamlessly
across several buffers, written in different languages.
-verbatim will disable argument parsing in evaluate-commands, making
it possible to forward a single command to a different context without
triggering a reparsing of the arguments.
Fixes -try-client support in grep.kak
Closes#3153
Highlighting arbitrary words in Swift comments should be done from the
user configuration, plus hardcoding the `red` color doesn't play well
with all colorschemes.
This commit allows using the <semicolon> expansion in commands, instead
of `\;`.
It makes commands look more elegant, and prevents new-comers from
falling into the trap of using <a-;> without escaping the semicolon.
this will only highlight elm 0.19 (latest) properly
very close to how https://ellie-app.com/ highlights
- anything that starts with an upper case letter is a type
- anything that starts with a lower case letter is a function
- function declaration is just a function at the start of a line
note: the default color scheme looks too colorful
For clojure.kak and haskell.kak, set extra_word_chars on the buffer
and not the window, so that the buffer's word db is updated correctly
for word completion.
Document this.
Also, minor refactor of clojure.kak.
Closes#3108
When trimming indent, the last line, if only containing
whitespaces does not need to match the indent, so that
this indentation style works:
-docstring %{
indented string
}
Check if buffile is a full path by checking for the beginning
'/' character in editorconfig-load command. This avoids a parsing
error from feeding a *scratch*/*debug*/*grep*/etc. buffer name to the
editorcofig command. Don't clear editorconfig hooks until after checking
for a valid bufffile path. This way, opening the *debug* buffer will
not clear the hooks from a previously parsed .editorconfig file. If
trim_trailing_whitespace is true, print the hook directly from awk. This
removes the need to save a editorcofig_trim_trailing_whitespace option.
Note: Setting the max_line_length requires a window to be created.
Therefore, a global hook to load .editorconfig settings should be:
hook global WinCreate .* %{editorconfig-load}
* Adapt the char literal highlighter from c-family.kak
* Fix line comment adjacent to char literal not being highlighted
* Fix single quote terminating a double quote string
* Fix keywords in comments being highlighted
* Highlight Nim's escape sequences for strings
* Highlight common comment tags
* Add on/off to the highlighted boolean values
* Remove redundant regex highlighter for comments
* Fix autoindent indenting lines more than it should
Before:
```nim
type
MyType = tuple
myint: int # This line needs to be indented manually
```
After:
```nim
type
MyType = tuple
myint: int # Lines after 'tuple' are now indented automatically
```
Make sure decorators are on their own line, and don't stop highlighting at
the first dot when they are imported, e.g.
```
import enum
@enum.unique
class A(enum.Enum):
…
```
Ideally highlighting shouldn't stop at the first parenthesis either
(e.g. `@foo(['1'])`), but the current code somewhat highlights the contents
of the parens already, which is good enough in most cases.
This attempts to support a simple formatting and intentation style for
plain sh syntax (and other sh-compatible code which doesn't stray too
far from portable sh).
The complexity of sh syntax means that we have to be opinionated -
attempting to be more flexible would require extensive context
awareness, and would require something more akin to a proper
autoformatting tool or a language server.
The formatting style used here makes use of vertical whitespace as the
primary delimiter, so that code ends up looking like this:
if [ $foo = "bar" ]; then
thing1
else
thing2
fi
for i in foo bar baz; do
thing1
thing2
done
case "$foo" in
bar) thing1;;
baz)
thing1
thing2
;;
esac
Since the formatting style used is very opinionated the 'sh_auto_indent'
option can be used to disable auto-indentation, with the default set to
'no'.
Due to ambiguity in the POSIX standard, GNU and BSD versions of the `wc`
utility use slightly different whitespace conventions when formatting
their output [1]. When limiting the output to just counting the number
of bytes (as is done by Kakoune when calculating the length of words
for spell check highlighting), the BSD version of `wc -c` has some
additional leading whitespace:
gnu$ printf %s "test" | wc -c
4
bsd$ printf %s "test" | wc -c
4
This leading whitespace needs to be removed before defining the "region"
to highlight, or `set-option` will not be able to parse the given
`spell_regions` and will complain that there are "not enough elements
in tuple." In other words, the region `1.21+8|Error` on Linux ends up
looking like `1.21+ 8|Error` on macOS, which is invalid.
Removing the whitespace could be accomplished in a number of ways, but
using arithmetic expansion [2] is POSIX compliant and does not require
shelling out to another process.
[1]: https://unix.stackexchange.com/questions/205906/extra-space-with-counted-line-number
[2]: https://mywiki.wooledge.org/ArithmeticExpression
