When using `eval` a new scope named 'local' gets pushed for the
whole evaluation, this makes it possible to temporarily set
an option/hook/alias...
Local scopes nest so nested evals do work as expected.
Remove the now trivial with-option command
A couple of semi-opinionated choices were made in this implementation:
1. The guide is hidden in the first column.
2. The indent guides are highlighted using a new `WhitespaceIndent` face.
3. Nothing is done to continue the guide through empty lines. I believe this to be the correct approach,
at least as long as it is kept as a part of the show-whitespaces highlighter. However some people's
oppinion may differ, and if so, that could be implemented.
4. The guides default to on, like the other show-whitespace options. Default character is "│".
5. Spaces between the indent guides are currently highlighted as other spaces.
Other reasonable options would be no replacement, -tabpad, or a similar -indentpad.
6. Guides are disabled by passing `-indent ""`.
7. Indent guides are separate from tab highlighting.
Additionally, we could consider adding a separate face for the "current" indent level as many editors do,
but this is a bit harder in kakoune because of multiple selections.
Closes#2323
prompt has fuzzy filtering which is more discoverable than the menu
mode's regex filtering (because that one needs / to trigger it).
There are no important differences left, so replace the menu builtin
with a prompt-based command.
prompt does not support markup in the completion menu, so drop that
feature for now.
Read output from the script as it comes and update the candidate
list progressively.
Disable updating of the list when a completion has been explicitely
selected.
Previously, `:doc mapping` hid everything from the beginning of the "expansions"
link up to the "keys" link in the next section (the next occurring comma). Now
the end of the "Mapping commands" section and the beginning of the "Mapping
keys" section are properly visible inside Kakoune.
Make it possible to move the current session to a daemon one after
the fact, which is useful to ensure the session state survives client
disconnecting, for example when working from ssh.
The current exponential behaviour does not seem that useful, it seems
more predictible that pressing `+` twice would end up with 3 copies
of the original selections instead of 4.
Fixes#4533
This switch makes show-matching fallback to the character preceeding
the cursor if the character under the cursor is not a matching
character, which should make show-matching more useful in insert mode.
Sometimes we get people asking why <c-c> can't be mapped. It should be
mentioned in the `:help mapping` documentation, along with any other
unmappable keys.
Change the initial <c-h>/<c-k> bindings to the recently freed-up
<a-u></a-U>.
Pros:
- easier to remember
- the redo binding is logical.
- works on legacy terminals, unlike <c-h>
Cons:
- It's less convenient to toggle between selection undo and redo
keys. I think this is okay since this scenario does not happen that
often in practice.
%exp{...} just expands its content the same way double quoted strings
do, but using a named expansion type makes it possible to use the
more quoting mechanism to avoid quoting hell.
Whenever a new history node is committed after some undo steps, instead
of creating a new branch in the undo graph, we first append the inverse
modifications starting from the end of the undo list up to the current
position before adding the new node.
For example let's assume that the undo history is A-B-C, that a single undo
has been done (bringing us to state B) and that a new change D is committed.
Instead of creating a new branch starting at B, we add the inverse of C
(noted ^C) at the end, and D afterwards. This results in the undo history
A-B-C-^C-D. Since C-^C collapses to a null change, this is equivalent to
A-B-D but without having lost the C branch of the history.
If a new change is committed while no undo has been done, the new history
node is simply appended to the list, as was the case previously.
This results in a simplification of the user interaction, as two bindings
are now sufficient to walk the entire undo history, as opposed to needing
extra bindings to switch branches whenever they occur.
The <a-u> and <a-U> bindings are now free.
It also simplifies the implementation, as the graph traversal and
branching code are not needed anymore. The parent and child of a node are
now respectively the previous and the next elements in the list, so there
is no need to store their ID as part of the node.
Only the committing of an undo group is slightly more complex, as inverse
history nodes need to be added depending on the current position in the
undo list.
The following article was the initial motivation for this change:
https://github.com/zaboople/klonk/blob/master/TheGURQ.md
Some plugins (*cough* kak-lsp) and help texts tend to have immensely long content
in a single line. This generates info boxes that span the entire terminal width.
This is made especially worse on widescreen monitors or at small text size.
This grants user control over how wide these boxes are.
I deliberately avoid pushing this change to `kak-lsp` because it's not the only
plugin that this could help--see the `hook` help text for an example of this
problem in vanilla Kakoune. I would also suggest that since this is a rendering
concern, it be handled by the terminal rendering logic.
Originally the page said:
> No other escaping takes place in balanced strings.
...but in the course of a general readability rewrite (56287da) this was
changed to:
> Characters may be escaped in the same manner as those for quoted strings.
...which is not actually true; probably this change made it in because there
were a lot of good changes in those commits and we didn't read them all closely
enough.
Now the documentation is correct again, and I've added some examples covering
the problems people occasionally ask about (see #2760).
From the issue:
> It often happens to me that I carefully craft a selection with multiple
> cursors, ready to make changes elegantly, only to completely mess it
> up by pressing a wrong key (by merging the cursors for example). Being
> able to undo the last selection change (even if only until the previous
> buffer change) would make this much less painful.
Fix this by recording selection changes and allowing simple linear
undo/redo of selection changes.
The preliminary key bindings are <c-h> and <c-k>.
Here are some other vacant normal mode keys I considered
X Y
<backspace> <minus>
# ^ =
<plus> '
unfortunately none of them is super convenient to type. Maybe we
can kick out some other normal mode command?
---
This feature has some overlap with the jump list (<c-o>/<c-i>) and
with undo (u) but each of the three features have their moment.
Currently there's no special integration with either peer feature;
the three histories are completely independent. In future we might
want to synchronize them so we can implement Sublime Text's "Soft
undo" feature.
Note that it is possible to restore selections that predate a buffer
modification. Depending on the buffer modification, the selections
might look different of course. (When trying to apply an old buffer's
selection to the new buffer, Kakoune computes a diff of the buffers
and updates the selection accordingly. This works quite well for
many practical examples.)
This makes us record the full history of all selections for each
client. This seems wasteful, we could set a limit. I don't expect
excessive memory usage in practice (we also keep the full history of
buffer changes) but I could be wrong.
Closes#898
This wording was valid for an old version of that patch that foolishly
add a switch to "map" to allow recording history. Happily we found
a better solution. Now commands inside user mappings never add to
prompt history (unless you use "set-register"), so be clear about that.
So far they have only been talked about in source code
(HistoryRegister), not in documentation.
Let's give them an official name so users can find them better;
"prompt history register" seems better than "history register" since
the former gives more context. OTOH, in future other registers (like @)
could grow into history registers, so I'm not sure.
State that the history registers are only changed by _interactive_
prompts; that's not quite true yet for user modes but I'll push a
separate fix for that.
