| Age | Commit message (Collapse) | Author |
|---|
|
If the current buffer is locked, it means we are in the middle of
creating the client or already changing the buffer, error out in this
case instead of getting into an inconsistent state.
Fixes #5338
|
|
FifoWatcher::read_fifo() deletes the fifo watcher in
m_buffer.values().erase(fifo_watcher_id); // will delete this
which calls: HashMap::unordered_remove()
constexpr_swap(m_items[index], m_items.back());
destructor called here --> m_items.pop_back();
m_index.remove(hash, index);
So hash map invariants (of buffer.values()) are broken, when calling
~FifoWatcher which fires BufCloseFifo hooks. Things blow up if those
hooks access buffer.values() such as by accessing cached highlighters
to redraw the buffer. A shell call with a long sleep in the client
context seems to trigger this.
Fix this by destroying removed map items only at the end of
HashMap::remove(), when invariants are restored. Alternatively, we
could introduce a fifo_trash container; I haven't explored that.
|
|
Move the whole responsibility of making the cursor visible to the
window, removing cursor_pos from the display setup and resolving
the cursor location by finding it in the display buffer afterwards.
This simplifies hightlighters' do_compute_display_setup as they do
not need to compute the cursor location. Highlighting may run on
more lines than necessary after this change but this should be a
minor performance hit.
|
|
Without doing this, replace with multiple selection at buffer end
breaks as the first selection will replace the end-of-line with a
non-eol character, then a new eol will automatically be added which
will put remaining selections past the end of the buffer.
Fixes #5316
|
|
The hook is manually triggred at the end of registration, by
disabling it we avoid the hook being potentially called multiple
times due to interaction with other hooks.
Fixes #5324
|
|
We use linewise paste if any of the pasted register elements has a trailing
newline. As shown in the previous patch, this leads to awkward situations
where insertion positions from <a-P> are not monotonically increasing.
This complicated behavior is questionable. The root cause is that linewise
paste may insert some strings that don't have a trailing newline. This leads
to weird cases of GIGO, especially when using <a-P> when the last element
is missing a trailing newline.
Simplify the implementation by not activating linewise paste in that case.
Instead of special-casing the last element, try to simplify the behavior
further by using line-wise paste only if *all* elements are properly
terminated. I can't think of a real-world case where the existing behavior
would be desired.
A regression test shows a change in behavior. Might be less weird now.
The added test case is a copy except it uses "P" instead of "p" (the extra
newline is because "d" deletes the last newline in the buffer which gets
added back implicitly).
(I think the list of register elements is never empty, so this should never
cause a trivial linewise paste. Even if so, that would be fine because
inserting nothing is a nop either way.)
Fixes #5312
|
|
sel1 == sel2 was using BasicSelection::operator==, ignoring captures,
which led to selection history deciding that selection did not change
in some cases where only the captures had been updated and for the
new selection not to be properly applied, leading to missing capture.
|
|
Commit 8c49c8ee4 (Highlight all atoms for the line regardless of
has_buffer_range, 2024-11-04) intentionally changes the behavior
to also highlight outside the buffer, painting over number-lines.
Let's use a final face as suggested to restore the test's previous
behavior, fixing the failure.
|
|
This changes the behaviour with say line numbers and other line
flags, but can be opted out by using final faces
Fixes #5253
|
|
|
|
Instead of outputing the matching output, either ignore the output
(if not extra argument is given) or match it.
Usage is: ui_out -until-grep <pattern> [<expected>]
|
|
Add cursor coordinate parameters, and fix encoding to match the
new one.
|
|
|
|
A common pattern is for info/echo messages to be generated by idle
hooks but the clearing of previous info/echo was done immediately on
normal mode events. This led to flickering of the info box especially
when a hook was repeatidly generating the same info (like moving
a cursor in the same word where the hook reacts to the word under
the cursor).
|
|
We do not typically go into lengthy explanation of the code in the
support scripts. This would have a performance impact (as comments
are not trimmed in advance) and feels out of place.
|
|
The current python filetype module treats a single empty comment line
(typically created by hitting enter twice while in a block comment) as
the end of a block comment, deleting the empty comment and ending
comment prefix copying. This runs contrary to PEP8, which explicitly
allows for paragraphs in block comments, with an empty comment as the
paragraph separator.
This change implements support for using a single empty comment as a
paragraph separator, with two consecutive empty comments being treated
as the end of the block comment; both empty comment lines are deleted
and comment prefix copying is ended.
|
|
ASan shows that we resolve a face spec owned by a freed stack variable.
=================================================================
==2263300==ERROR: AddressSanitizer: stack-use-after-return on address 0x7a9316c33918 at pc 0x633ea421d8ea bp 0x7ffca001e980 sp 0x7ffca001e970
READ of size 8 at 0x7a9316c33918 thread T0
...
#6 0x633ea421d8e9 in Kakoune::FaceRegistry::resolve_spec(Kakoune::FaceSpec const&) const src/face_registry.cc:128
...
Address 0x7a9316c33918 is located in stack of thread T0 at offset 2328 in frame
#0 0x633ea427a095 in operator() src/commands.cc:2267
This frame has 26 object(s):
[32, 36) '<unknown>'
...
[544, 560) 'disable_hooks' (line 2269)
...
[928, 2432) 'local_scope' (line 2271) <== Memory access at offset 2328 is inside this variable
|
|
|
|
tabs <-> space conversion functions did not create a ScopedEdition
leading to uncommited modifications. Fixing this did fix the
interactive error, but that error still existed in non interactive
context so redo now considers there there is no redo child if there
are uncommited modifiations (which is correct as this means we are
currently creating a new leaf in the undo tree)
Fixes #5124
|
|
Only record non-synthetized insertions, removing the need to
re-record on replay and fixing the last replay getting dropped by
macro execution.
Fixes #5122
|
|
|
|
<c-n>/<c-p> handling in insert was always dropping the last key in
the last_insert() vector (in order to replace it with the actual
completion text inserted), this was not valid for synthetized keys
that are not added to that vector in the first place.
Take the opportunity to merge insert completion handling code between
<c-n>/<c-p> and direct menu selection.
Fixes #5120
|
|
The wrap highlighter was pulling all lines until the cursor, regardless
of whether the cursor was going to be made visible, this could lead to
a display buffer containing much more lines than the actual viewport
which eventually could lead to menu being anchored out of view that
was leading to past-the-end buffer accesses.
Fix the wrap higlighter not to pull lines up to the cursor when it
is not tasked with making the cursor visible, and always trim the
eventual extra lines after highlighting.
Fixes #5118
|
|
After extracting the whole buffer content, a line can end up with
only non-range highlgihters pending which makes its range become
0.0,0.0, after running highlighting on the extracted range it gets
re-inserted but taking the min of existing range and inserted range
wrongly returns 0.0. Avoid this by detecting that the 0.0,0.0 range
does not actually mean anything when we have no ranged atoms.
Fixes #5001
|
|
Fixes #5076
|
|
This test doesn't care about testing things like "if I send the next
key before we have finished reacting to the previous ones, nothing
bad ever happens".
Hence we can until exhaustion after each input. This should fix
bespoke flakiness. The handling of "c<esc>" should be atomic.
This reasoning probably applies to most tests; waiting for all events
seems like the safest and easiest approach overall (compared to sleep
or sleep-until). The downside is that the tests need changes when
UI code changes but it rarely does, and if it does we can automate
the updates.
Closes #5073
|
|
|
|
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.
|
|
Regressed in a2c41593a (Fix partial regex text being pushed in history,
2023-11-02).
|
|
This should fix a bug in lint.kak though I didn't check.
|
|
|
|
ensure cursor is visible after user input except if the command
implementation opted-out. Hooks and timers should not enforce
visible cursor.
PageUp/PageDown and `<c-f>` / `<c-b>` commands still move the cursor
as this seemed a desired behaviour.
|
|
Thanks @krobelus
|
|
This is currently broken on various corner cases and breaks the
"master branch should be good for day to day work" implicit rule,
ongoing work to stabilize this feature will take place on the
no-cursor-move-on-scroll branch until its deemed ready.
This reverts commit 1e38045d702ec6eb2425016d9b02636270ab1b1e.
Closes #4963
|
|
Kakoune now does not touch cursors when scrolling. It checks
if either the buffer or selections has been modified since
last redraw.
Fixes #4124
Fixes #2844
|
|
Do not rely on timing but wait for Kakoune to redraw which is what
we actually need: Mouse clicks rely on the current display buffer
to resolve the buffer location, so we need to wait for a redraw
to happen with `ui_out`
|
|
Commits e49c0fb04 (unmap: fail if the mapping is currently executing,
2023-05-14) 42be0057a (map: fail if key is currently executing,
2023-06-24) fixed potential use-after-free issues. By doing so,
it broke configurations that in practice have not triggered any
crashes [1] [2].
For example with,
set -remove global autocomplete insert
hook global InsertCompletionShow .* %{
map window insert <esc> <c-o>
}
hook global InsertCompletionHide .* %{
unmap window insert <esc> <c-o>
}
The execution of the <esc> mapping triggers InsertCompletionHide fails
at unmapping. This seems legit and I don't see an obvious alternative
way to write it (InsertIdle would not be correct though it would work
in practice).
Fix the regression by allowing map and unmap again while keeping the
mappings alive until they have finished executing.
Applying map/unmap immediately seems like the most obvious semantics.
Alternatively, we could apply them in between key presses.
[1]: <https://github.com/kak-lsp/kak-lsp/issues/689>
[2]: <https://github.com/alexherbo2/auto-pairs.kak/issues/60>
|
|
If during execution of a mapping, that same mapping is replaced,
there is undefined behavior because we destroy a mapping that we are
still iterating over.
I have been using this mapping inside my kakrc to re-source the kakrc.
map global user s %{:source "%val{config}/kakrc"<ret>} -docstring 'source "%val{config}/kakrc"'
Now <space>s happens to not trigger undefined behavior because the
mapping stays the same.
However it triggers an assertion added by Commit e49c0fb04 (unmap:
fail if the mapping is currently executing, 2023-05-14), specifically
the destructor of ScopedSetBool that guards mapping execution.
Fix these by banning map of a key that is executing, just like we
did for unmap.
Alternative solution: we could allow mapping (and even unmapping)
keys at any time and keep them alive by moving them into a trash can,
like we do for clients and others.
|
|
When a line only contains non-range atoms we can end-up accessing
past the end atom.
Add a test that shows the issue when run with valgrind, it is
unfortunately quite hard to trigger a crash because the invalidly
accessed byte usually leads to the correct code path being taken
(when != DisplayAtom::Range) so we have only 1 in 255 chance of
triggerring a crash.
Fixes #4927
|
|
In some cases such as with folding we can end-up with regions
not having any atoms to highlight which can trigger a crash as
we assume display buffers not to be empty
Fixes #4926
|
|
When unmapping a key sequence that is currently executing, we continue
executing freed memory which can have weird effects. Let's instead
throw an error if that happens. In future we can support unmap in
this scenario.
Closes #4896
|
|
|
|
Fixes #4887
[ja: add test]
|
|
|
|
The previous code was assuming it was fine to push_next without
growing, which used to be the case with the previous implementation
because we always have poped the current thread that we try to push.
However now that we use a ring-buffer, m_next_begin == m_next_end can
either mean full, or empty. We solve this by assuming it means empty
and never allowing the buffer to become full, which means we need
to grow after pushing to next if we get full.
Fixes #4859
|
|
Fixes #4844
|
|
|
|
|
|
The macOS CI manges to trigger this race. When it happens the
"c" inserted by the last command is not seen by the test runner.
Let's fix this by adding yet another sleep.
|
|
AKA macOS.
|
