On macOS, backspace reportedly no longer works after <c-z> and fg.
The value of m_original_termios.c_cc[VERASE] seems to be wrong
in a static lambda that captures a singleton "this".
Not sure what's the problem. I thought that it is guaranteed that
"static auto convert = [this]() { ... }" is initialized lazily,
hence it should capture the correct address. Maybe the address
changes somehow or it's UB / a compiler bug.
This reverts commit ad36585b7aCloses#5155
On FreeBSD and NetBSD, sysctl() can return -1 when the path is too long,
leaving the buffer unitialised.
On macOS, both _NSGetExecutablePath() and realpath() can fail with
pathological paths or if memory is exhausted.
On Haiku, the kak_assert(status == B_OK) check will be compiled out in
non-debug builds.
Detect all of these cases and error out, reshaping get_kak_binary_path()
to avoid multiple repetitions of the same fatal error message.
On Linux, Hurd, Cygwin, DragonFly BSD and Solaris/Illumos, Kakoune obtains
a path to its binary by reading the appropriate /proc symlink target.
readlink() can fail or it can fill the entire buffer, silently truncating
the path if the buffer is too small.
kak_assert() is compiled out in non-debug builds so we ignore a readlink()
failure, corrupt the stack by writing to buffer[-1] then return a string
from the uninitialised buffer.
If readlink() succeeds and the binary path is sizeof(buffer) long, we write
a \0 terminator beyond its end. If it is longer, we also truncate the path.
Throw a fatal error on startup in all these unlikely failure cases.
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
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
MacOS uses an old GNU make that does not support the != syntax.
That syntax is not Posix (yet, it is accepted for next standard) but
we really need a way to call the shell from a Makefile. Hopefully we
can remove this soon (not holding my breath though)
Fixes#5117
In a noninteractive shell, asynchronous commands ignore SIGINT and
SIGQUIT. We typically use such shells to feed fifo buffers which we
do want to cancel them on Control-C. Make it so.
Same for SIGQUIT; that one is not typically used but I expect that
along the Kakoune server it kills any child processes that (haven't
been daemonized).
Note that for unknown reasons, Bash already doesn't ignore SIGINT in
async processes that use "eval".
Note that Dash has a bug that prevents this from working;
proposed fix is at
https://lore.kernel.org/dash/20240329153905.154792-2-aclopte@gmail.com/
(While at it balance out some parens, to help the m command)
Overloading SIGTERM like that causes issues; specifically if the
editor is invoked (without exec) from a wrapper script.
By sending SIGTERM to whole process group, we kill our parent process
(the wrapper script) which then sends SIGTERM to Kakoune. By this
time Kakoune has already reset the SIGTERM handler to the default
action and terminates.
We can use a different fix for the problem that some shells don't
cancel "make", see the next patch.
This reverts commit ec44d98347.
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
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