This makes it possible to remove the pending clears whenever an
info/status line is explicitely added, removing a class of race
conditions introduced by the previous implementation.
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).
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
--
2.45.2
I configured :make to use a special makecmd for files called test.cpp.
hook global BufCreate .*/test.cpp %{
set-option buffer makecmd "g++ %val{buffile} && ./a.out"
}
Commit c93cb5c4d (Add a `fifo` helper command and refactor `make`
and `grep` to use it, 2024-06-07) made :make evaluate makecmd in the
toolsclient context instead of the calling context, so my buffer-local
override no longer applies. I'm not sure if this is something we want
to guarantee but it doesn't seem unreasonable, and we can fix it a
no cost I think.
Additionally, it changed
eval "${kak_opt_makecmd}" "$@";
to
$kak_opt_makecmd "$@"
meaning that the "&&" in my makecmd will no longer be evaluated.
Instead it will be passed as argument to g++, effectively
g++ %val{buffile} '&&' ./a.out
which I don't think is a reasonable expectation (unless we change
makecmd to be str-list options). Essentially, the above only applies
word splitting to makecmd; it seems simpler and less surprising to
treat them as raw shell commands.
Expand makecmd in the calling client again, and insert it verbatim
into the shell script.
grep hasn't needed it so far but keep it consistent.
previously, clicking on the status line if it is on the top of the
window results on a coord.line = 1 << 16, or there abouts. This is
because the expression
(key & 0xFFFF0000) >> 16
results in an `shr` instruction which does not propagate the sign
bit. Mouse event coordinates can be negative if the status line is
on top and the status line is clicked. The new line
(int32_t) (key & 0xFFFF0000) >> 16
properly propagates the sign bit, leading to the correct signed
numeric line coordinate.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
adds scroll amount in the upper 16-bits of `Key.modifiers`, reclaiming
the space in `Key.key` for coordinates. Previously, while mouse events
included their coordinates, scrolling did not. Scroll events are now
emitted as <scroll:amount:line.column>.
Now the scrolloff can be specified in the configuration file and
if either one of the column or line offset given is too large to
fit in the buffer, half of the window dimension is taken in it's
place. `v<` and `v>` account custom scroll offset as well.
I had this issue with device tree binding files in zephyr, that follow the vendor,device.yml
convention. The linux kernel presumably uses it as well.
While allowing escaping helps, we might consider using a separate option. The most obvious
approach might be to move the current behavior to -buffers, and have -buffer be
verbatim. However, I'm not entirely sure about the impact of that breakage,
so for now, at least the ability to escape it.
Make last insert and macro recording closer together, paving the
way towards moving last insert to a register.
Use a FunctionRef for insert completer key insertion support.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
This fixes an issue with the following hooks:
hook global InsertCompletionShow .* %{ map window insert <tab> <c-n> }
hook global InsertCompletionHide .* %{ unmap window insert <tab> <c-n> }
When repeating a last insert using <tab> to select a completion, it
inserts a <tab> instead of selecting, then the insert completion tries
to erase the inserted text with backspaces but fails to totally do that
as it erases the tab character first.
It seems g++-10 running on rosetta on macos ventura triggers
generates some code that crashes in __cxa_throw, this seems
similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98805
We already have plenty of testing with gcc 10 so we can bump
macos gcc to workaround this.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.
The previous implementation was relying on the left hand side of the
assignement's side effects to be sequenced before the right hand side
evaluation (so --split_pos was expected to have taken place)
This is actually counter to C++17 which guarantees evaluation of the
right hand side of the assignement first. For some reason this is
not the case with GCC on linux.
I dedicate any and all copyright interest in this software to the
public domain. I make this dedication for the benefit of the public at
large and to the detriment of my heirs and successors. I intend this
dedication to be an overt act of relinquishment in perpetuity of all
present and future rights to this software under copyright law.