This commit prevents specially crafted modelines from making the
editor execute arbitrary Kakoune commands.
By using a tabulation character as a separator, commands can be
injected in the value of the options listed in the modeline. For
example:
# kak: tabstop=2;set-option buffer pwned yes
Fixes#3735.
This commit addresses an off-by-one error that selected `modelines`+1
lines when looking for modelines in a buffer.
Note that setting `modelines` to 0 will still select one line.
Fixes#3733.
This fixes serveral shortcomings of the current implementation:
- valid recipt definitions eg
foo bar="quz":
where previously interrupted by justfile/double_string
and therefore they where not highlighted correctly
- global variable assignments where not captured at all
Add support for the following gopls commands:
- format
- imports
- definition
- references
Thanks krobelus@ and lenormf@ for their review and suggestions.
- some wording changes in included documentation
- find supports multiple starting paths, we don't need to launch it 3 times
- Change the regex that trims the file extension to only trim the last extension
Some additional things I noticed:
- find should use -L to see through symlinks like the autoload processing does.
- find should check the user's autoload directory first, so users can override
Kakoune's built-in documentation.
This makes the somewhat-dubious assumption that every plugin will have uniquely-
named documentation files, instead of automatically putting every plugin's docs
into a namespace. However, plugins already have to deal with flat namespaces for
commands, options, filetypes, etc. so one more shouldn't hurt.
Fixes#2466.
This adds two things I forgot in
9a7d8df4 (Avoid accidentally using environment variables in sh scopes)
Mea culpa, the problem was that I was skipping matches with "filetype"
because that's usually just a hook parameter as in "WinSetOption filetype=.."
rg --pcre2 '\b(?!filetype=)\w+=' rc/
So I missed these two cases where a shell variable is actually called "filetype".
The one in git.kak was not a problem because show_git_cmd_output is only
ever called with sane inputs. However, file.kak does use the filetype
environment variable for many mime types, for example:
filetype=somefiletype\''; echo -debug injection; nop '\' kak /dev/null
Will run the echo since /dev/null has mime type "inode/chardevice"
It's unclear what the `send-text` alias does at first glance,
so prefixing it with "repl-" both fixes that and helps make it
discoverable via the command prompt's fuzzy matcher.
The `repl` alias also seems too generic a name, the "-new" suffix
should hopefully give a hint that it creates a new window.
This commit addresses the following issues:
* highlight trailing space characters with the `meta` face, instead of
`PrimarySelection`
* make the regex more readable by using a capture group in stead of
`\K`
* specifically match space characters, not other horizontal whitespace
characters
* match two or more space characters
Reference[1]:
> When you do want to insert a <br /> break tag using Markdown, you
> end a line with two or more spaces, then type return.
[1] https://daringfireball.net/projects/markdown/syntax#p
Note that the original reproducer doesn't seem to work anymore,
probably because of changes made to how lists are highlighted.
Fixes#911
Similar to Jinja, getting `eex` highlighting in *.ex files
will require users to setup a filetype hook similar to the
following:
hook global WinSetOption filetype=elixir %{
require-module eex
add-highlighter window/eex ref eex
}
This is done both to fix a circular dependency between the `elixir`
and `eex` modules, and avoid polluting `elixir` files with false
positives from `eex` highlighting given `eex` is framework specific
This fixed a weird bug where if you were typing in the top level scope of a
program (no indentation before statements), the `end`s wouldn't be inserted
for you.
The syntax highlighting has been broken down into 3 main categories:
string: string, array of words
variable: symbol, array of symbols
meta: regexp, shell execution
In case a user connects to the same Kakoune session from multiple tmux
windows/sessions, this makes the splits appear next to the calling client,
instead the client where the Kakoune session was started.
As it was before, when you had this (| = cursor):
``` json
{
"foo": {|
}
```
and hit <ret>, this would happen:
``` json
{
"foo": {
|
}
```
when it should have been this:
``` json
{
"foo": {
|
}
```
When a closing brace or bracket is typed, it should automatically match
indentation with it's opener. Because of an unescaped ']' literal the regexp
didn't work.
/// foo
///%( )
/// foo
/// %( )
With `c<ret>bar<esc>`,
/// foo
bar
/// foo
///
/// bar
Based on c-family block comment handling, this patch also add rust
block comment indentation.
This affects `o` behavior on empty comment but it allows a way more
efficient way to clear comments.
This patch centralises the loading of windowing environments, in order
to ensure that by default only a single module is loaded, rather than
the current code which can load multiple potentially incompatible
modules; and in order to provide the user with more control over the
loading of windowing modules.
The patch introduces a new str-list option `windowing_modules` which
defines an ordered list of windowing modules to attempt to load. Modules
are loaded in the order specified in the list until a module loads
without error, at which point the process finishes.
When loaded each windowing module tests the environment to determine
whether it should load (e.g. the tmux module tests to see if it's being
run within a tmux session), and if it determines that it should then it
completes its loading without error. If it doesn't detect an appropriate
environment then it returns an error, and the module loading logic tries
the next module.
The user can override the default `windowing_modules` list to specify
their preferred modules (i.e. they can put kitty ahead of tmux if that's
their preference, or they can leave out the x11 modules alltogether). In
addition, if the `windowing_modules` option is an empty list this
bypasses the environment detection logic completely, and allows the
modules to be loaded manually - this allows a user to replace the
windowing module loading logic with their own manual set up.
* 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.
