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.
