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
Fixup ctags-complete command to search for partial matches for the
current selection in all tags files listed in ctagsfiles option. Format
the results to fit the Kakoune completions type.
Add ctags-enable-autocomplete and ctags-disable-autocomplete commands to
add and remove an InsertIdle hook to select the previous word and call
ctags-complete.
Use the ctags_min_chars option to limit the noise of returning many
completions for very short selections.
Indentation can be different depending on the first word of list forms. The
indent hook uses `e` from inside the parent to select the first word for
testing whether it is a special word; however, in the case of a one-character
symbol, this selects to the end of the *next* word.
This rejects such selections.
Change regular expression in git blame, removing braces. New expression is supported on various awk engines used in some distributions as default ones. As trade-off, the new expression accepts more input character sequences.
adding init to git.kak
removing git init EOF line
git ls-files on on git.kak
no candidates for git-init, removed function
removed candidates for git-init
1. Add commands to navigate between man page links.
2. Add command to jump to a man page by following a man page link.
3. Add key map for <ret> to jump command.
4. Add key maps for a suggested user mode.
1. If there is no man page found (error 16), then echo stderr text.
2. For other kinds of errors, fail with stderr text so that command can propagate through a try/catch.
Also add test for tab preservation during c-family autoindentation, and correct alignment of '}' with opening of block in cases of wrap between '(' and ')' in c-family languages
Konsole doesn't work well with non-default Kakoune themes, so I've put it last in the list, but in case when no other terminal is available it's good to have it in the list for launching non-kakoune things, like tig
1. Enable the command to correctly show the prefix of a function name [prefix::basename],
where prefix is the value gotten from a class, struct, or namespace field of the tag line.
2. Use a readtag filter expression to replace a use of grep.
1. Fix#2250. Enable ctags to handle absolute file paths.
Only prepend tagroot to tag location if it is a relative file path.
2. Include signature field in the default ctags command.
The regex for displaying signature info includes a mandatory pattern
for 'signature' field, but the field is not a default option for the ctags command.
If the tags file is generated by the as-is ctags command, pattern matching will fail,
and the whole ctags line for the selected function will be displayed instead.
It allows plugins to create generic terminal using the user's preferred windowing system
For example, it can be used to run fzf, gdb or simply a shell.
* 'new' commands are refactored to simply use the 'terminal' one
* style and docstrings has been unified
* all windowing systems go through "sh -c" for consistency purposes, even if unnecessary
* ModeChange hooks that remove indent now belong to *-trim-indent groups, instead of just -indent
* *-filter-around-selections hooks and commands have been renamed to trim-indent for clarity
This highlighting and static completion for types and macros that were
previously missing. No functions are included, but some macros are
highlighted as such, even if they're function-like macros.
Removing the handlebars highlighters when a client toggles away from hbs window unintentionally causes
other clients attached to hbs windows to no longer highlight correctly. The only other option is to
copy the entire html highlighter and all of it's rules, but that seems like a maitenance headache.
So instead, just leave the hbs rules injected into the html rules once the user opens any handlebars file.
It's not ideal, but I'd say it's the least bad option.
This commit also introduces a regression in that I decided that the best way to
avoid overly long and confusing names was to rename the current shell-*
switches to script-*, and have the shell command completion be
shell-completion.
renamed script-{completion,candidates} to shell-script-*
Updated docs with new switch names
Added -shell-completion switch to x11-repl and kitty-repl
Algol-like indenting doesn't work for Lisp as we tend to open (and
close) many forms on one line. This generally puts the cursor
where it should be, though it is probably confused by strings
with brackets and things.
- Removes -recurse from handlebars comments. Handlebars parsers (janl/mustache.js, ember-cli/ember-cli-htmlbars), do not treat comments as recursive, so don't highlight them as so.
- Creates shared/hbs-file highligher group. This represents a handlebars file, which is html that happens to contain some handlebars tags.
- Augments the shared/html highlighter when needed. Because handlebars lives inside of html, we need to add the highlighter inside of it. Since there's no way to scope modifications of a shared highlighter to a window, here I'm modifying/unmodifying the shared/html highlighter whenever the user attaches/detaches a filetype of "hbs" to/from the window.
- Matches namespaced helpers as well. In htmlbars, helpers (components) can have '/'s in them, so make sure to continue highlighting through those. Also removes unused capturing groups.
- Allows for de-indenting when closing a block expression
- Brings in html highlighter hooks
- Improves indent matching on close of yielded blocks. Previous version just flat out didn't work.
Use regions to avoid highlighting the commit message as a diff.
The new method will fail if one line of the commit message matches
'^diff --git' but that is fairly unlikely.
Fixes#2371
Values like `0xffffffffffffffffull` were highlighted only till first `u` leaving `ll` without highlighting. This change addresses this issue. It also adds uppercase `ULL` highlighting in values.
Previously, one of the syntaxes for italic was (greatly summarized) something
like this:
[^_]_[^_]+_[^_]
That is to say, the regex matched the blanks on both sides of the italic span,
as well as the actual span content. That means that if you had consecutive
italic words:
_some_ _italic_ _words_
...only the odd-numbered words would be highlighted: the space after "_some_"
was counted as part of that span, so it wasn't available as part of "_italic_"
and therefore "_italic_" wouldn't be highlighted. Likewise, if the first word
in a buffer was italic, it wouldn't be highlighted because the first underscore
was not preceded by a non-underscore character!
Now we use lookahead/lookbehind assertions, which don't count as part of the
matched span, so consecutive spans don't interfere with one another.
Fixes#2111.
Previously, a code block was anything between triple-backtics, including inline
blocks:
some text ```
not a codeblock, but highlighted as one
``` other text
and even if the closing backticks had the wrong indent:
```
this is a code block containing a triple backtick
```
this is still a code block, but Kakoune thinks otherwise
```
Now we use the -match-capture flag to ensure the start and end fences have
exactly the same indent.
Previously, the generic code-block region was defined first, which meant that
it took priority over all the language-specific highlighters. Now we define
the generic code-block highlighting *after* the others, which fixes#2304.
Previously, code-spans were defined as ordinary inline markup, but in Markdown
ordinary formatting doesn't work inside code-spans. Therefore, they are now
regions unto themselves, defined according to section 6.3 of the CommonMark
spec <https://spec.commonmark.org/0.28/#code-spans>, which addresses a comment
on #2111.
Since the gocode completions contain white space, they cannot be used without quotations.
Also, since I'm in there, the buffer should be quoted for heathens who use white space in their paths.
These templates are simple shell scripts, similar to PKGBUILDs.
They reside in srcpkgs, so we can use this to identify if
`template` really is a Void Linux package template.
When opening buffers from a directory that's not under versioning
(or even from a different repository), `git` commands will not work.
This commit temporarily changes the current working directory to that
of the current buffer to make sure the context is right.
Some syntax checkers (such as `cppcheck`) like to pass
extra-information using a regular diagnostic line - but with null
coordinates (0:0).
This commit makes the `:lint` command ignore such messages, to prevent
`set-option` from failing when assigning coordinates to `lint_flags`, and to avoid unecessary information in the `*lint-output*` buffer.
According to the Rust language reference[1], a raw string starts with an 'r',
zero or more '#' characters, and a '"', and doesn't close until a '"' is
immediately followed by the matching number of '#' characters.
[1]: https://doc.rust-lang.org/reference/tokens.html#raw-string-literals
* Make clang.kak compatible with POSIX `[`.
* Make lint.kak dump range/line-specs correctly. It still doesn't read them
correctly -- that'll be easier after the upcoming $kak_ changes for lists.
Unfortunately Strings that start with a quoted quote (like '''str')
are still incorrectly highlighted, a deeper refactoring of the regions
highlighter will be necessary.
Now that we have a nice standard way to express lists of strings,
registers can be fully exposed. An new $kak_main_reg_... env var
was added to provide the previous behaviour which is relied on by
doc.kak.
Automatic reparsing of %sh{...}, while convenient in many cases,
can be surprising as well, and can lead to security problems:
'echo %sh{ printf "foo\necho bar" }' runs 'echo foo', then 'echo bar'.
we make this danger explicit, and we fix the 'nop %sh{...}' pattern.
To reparse %sh{...} strings, they can be passed to evaluate-commands,
which has been fixed to work in every cases where %sh{...} reparsing
was used..
Note: `GNU/screen` has a different interpretation of what constitutes
a "vertical split", hence the inverted command descriptions, compared
to the tmux/iterm etc.
Closes#1626
A Rust data structure that is generic over a type conventionally uses a single
capital letter for the type variable, like `Vec<T>` or `HashMap<K, V>`. A Rust
data structure that is generic over a reference-lifetime conventionally uses an
apostrophe followed by a single lower-case letter for the lifetime variable,
like `Something<'a>`.
Previously, Kakoune would highlight "'a>" as the lifetime parameter; with this
change Kakoune highlights "'a" and leaves the closing ">" alone.
The :format command is often called from a BufWritePre hook to format the
current buffer, however the :format command itself calls `:write` to store the
buffer in a temporary location, potentially causing an infinite recursion.
If we disable hooks while running :format, there's no danger of that occurring.
Changes:
- Highlight float literals with float type suffixes (nf64 and nf32)
- Make module items use the module color
- Highlight macro variables $variable
- Highlight lifetimes
- Highlight u128 and i128
- Highlight character literals (e.g. 'a')
- Highlight dyn keyword (will in the future be used for trait objects)
Previously, due to a typo, Kakoune would highlight backtick spans from the first backtick to the last backtick in a paragraph, no matter how many backticks were in between. Now spans correctly stop at the first backtick after the opening backtick.
even though tmux 2.7 is installed.
The problem is that
```
expr "$(tmux -V)" : 'tmux \([0-9]*\|master\)'
```
fails on FreeBSD. It works fine with GNU expr.
Replace the expression with cut(1) and a simple parameter expansion
which should hopefully work fine on any POSIX system.
Signed-off-by: Tobias Kortkamp <git@tobik.me>
set-face now takes a scope argument, and faces can be overridden on
a buffer or window basis.
colorscheme apply on global scope, which should be good enough for
now.
Fixes#1411
Instead of starting the default shell and sending it text (hoping
it will support POSIX like shell syntax), just use the `env` utility
to set the correct environment and exec kakoune.
- Added <?php and ?> tags, and highlight everything outside as html
- Highlight documentation comments and @fields
- Added basic string interpolation highlighting
Letting any character to be escaped is error prone as it looks like
\l could mean [:lower:] (as it used to with boost) when it only means
literal l.
Fix the haskell.kak file as well.
Fixes#1945
Previously, two underscore characters in a document would mark the entire
space between them as italic, no matter how far apart. Now we only accept a
single consecutive newline within an inline-formatted span, so hard-wrapped
documents will still format nicely but stray characters won't mess up your
entire document.
Note that the highlighter for backtick-enclosed spans was modified,
even though it's redundant with the code-block highlighting introduced
in 5bc62c694.
As well as the traditional `[text](url)` syntax, Markdown allows the text to
be followed by a tag in square brackets. If the text is followed by nothing
at all, then the tag for that link is the text itself. The actual URL
is supplied later in the document, like a footnote at the bottom of the page:
Some text with [a link][tag] and [another link].
[tag]: http://www.example.com/link1
[another link]: http://www.example.com/link2
This adds the "link" face to the URL in such footnote lines.
Makes all the suggestions on the completion menu have the same format:
{type}{suggestedWord}{extra description}
the type column is aligned to 6 characters wide (and aligned to the right),
to allow the suggestion to be easily visually detectable and, as a bonus,
the type too.
For example, a bit of menu would look like this:
fn stdout() -> Stdout
trait BufRead: Read
struct BufReader<R>
Type is one of the following:
- fn
- enum
- mod
- trait
- struct
It also trims the module extra bits to only 30 characters long (it can be a lot longer than that)
When AWK processes the racer response, it adds a trailing ':' that
kakoune completion expects to lead to a row having an 'a|b|c' shape,
but it's empty instead. Removing the extra ':' allows the racer
complation to actually work.
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.
With the introduction of -match-capture for the lua region highlighter,
the string closing regex had spurious captures that were not going to
match.
Fixes#1850
This commit avoids false positives when highlighting literals such as
`$window`, which is a regular variable but still highlighted as a
special value.
Special highlighting of variables that start with a dollar sign `$`
was also removed, as not all variables start with a dollar sign,
and we don't have a reliable way yet to detect variables.
unsetting static_words whenever any buffer filetype is set to non ocaml
is wrong, it breaks static_words for every filetype whose filetype hook
run before the ocaml ones.
Block comments in Lua were broken, apparently due to the opening
sequence being interpreted as a line comment. Changing the order in the
highlighter seems to fix this issue.
Fixes#1735
We need \K to not interfer with languages own interpretation of ` like multiline strings in javascript
We need \b in e.g. java\b otherwise it blocks javascript
I couldn't get the bare ``` to not block the other highlighters when introducing \K any other way than negative lookahead of all possible highlighers
Commit 870d2d22d7 introduced a regression
in the highlighting of qualified Haskell variables, such as `Foo.bar`.
After that commit `Fo` was highlighted as a constructor (note, not
`Foo`, just `Fo` without the trailing `o`). This restores the original
behavior.
- Ensure ranger opens with the currently focused client tty if multiple screen clients are connected to the same session.
- Ensure args are passed to ranger correctly.
- Ensure command-line args are passed to ranger correctly. (Only strict long format works e.g. `ranger --cmd="echo foo"`)
- Change the current directory because `screen -X` uses screen's cwd not kakoune's.
- Use heredoc to make escaping and quoting easier to debug and slightly less unpredictable.
- Use ranger's `--choosefiles` option instead of mapping keys and having to do multiple levels of escaping and quoting of args esp. command-line args which were unusable in `screen -X eval`.
- Remove screen region when user quits ranger.
- The proper way to do this would be to switch focus to the target client's region but GNU Screen offers no obvious way to do that.
- Remove screen region after client is closed.
- Assumed: Kak server runs in screen.
- Hack: kak sets `/proc/self/fd/0 -> /dev/null`. Get the client process tty because Screen needs to know the controlling terminal. Else Screen will use the last known tty and will open new windows on a different terminal if one is connected.
As well as ordinary `//` line-comments, Rust regards `///` comments
as documentation applying to the following item, and `//!` comments as
documentation applying to the enclosing item, so we should copy those
to new lines, too.
* move most of the kakoune implementation outside of the shell scope
to avoid unnecessary escaping
* let kakoune do the option expansions to avoid injection of special
characters
* split block commenting options into two and do the < to <lt>
conversion directly
* show error messages directly in the buffer rather than in *debug*
Fixes#1600 and #875
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.
boost regex tolerates non-escaped special characters, and escaped
non-special characters. Standardize on stricter syntax, where
special characters must be escaped, and non-special characters must
not.
this uses 'export' to set $TMPDIR instead; fish provides an 'export'
function for bash-compatibility, so this should work for both shells.
note that prior to this change, opening new panes with fish did not
work, as fish does not support `FOO=1 bar` syntax.
- the file was edited with a different editor/program or
- kak didn't restore a backup or
- if old backups weren't purged or
- if autorestore wasn't loaded (e.g. `kak -n`) after backups were generated.
Sometimes the implementation of `man` will display errors, e.g.
```
<standard input>:4808: warning [p 54, 13.2i]: can't break line
```
Those errors are harmless but are still reported on the debug buffer,
so we hide them by redirecting the standard error stream to /dev/null.
When using the `man` filetype to make use of the text highlighters
of the `man.kak` script, the documentation pages inherit from the
window resizing hooks that won't work on `doc` buffers.
Fixes#1591
Highlighting perl regex patterns with regular expressions (with
highlighters) caused several misses that made most of the file
unreadable. This commit makes `perl.kak` not try to highlight
those patterns in the code, and also addresses issues with string
highlighting.
Import keywords are put in keyword face instead of meta face.
This leaves room for pragmas and macros to be in the meta face.
Operator keywords are put in keyword face too.
Finally, expression keywords are put in face attribute.
Previously, if you opened a new line after an underlined heading (what
the CommonMark spec calls a "Setext heading") or inserted a newline into
a line that started with `**strong emphasis**` the Markdown autoindent
hook would assume the leading symbols were list bullets and paste them
at the beginning of the new line.
However, the CommonMark specification says that list bullets must be
followed by at least one horizontal whitespace character, so Setext
heading underlines and strong emphasis are not valid list bullets and
should not be matched by the autoindent pattern.
This commit changes the regex that selects the pastable prefix of the
previous line so that it must match either:
- One or more `>` characters with optional whitespace between them
(a blockquote prefix), optionally followed by a list bullet; or
- An optional blockquote prefix and a list bullet
Since we don't strictly need either the blockquote prefix nor the list
bullet, we could concievably just make both optional... but for lines
without either, the regex would find a zero-length match, and for the
purposes of copy/paste Kakoune treats that as a one-character match.
Therefore, the regex is written to fail if neither pattern is found.
When used just after grepping, grep-next-match ended up jumping to
the second match, as `0g` is the same as `g`.
The fix itself is pretty ugly, a better one might be to distinguish
the `0` count from no count given, so that `0g` could fail with
"no such line" or similar.
