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.
This is especially useful to use the indent guides without the other
parameters, but in general it can be a useful option.
It could be worth considering cleaning up these options to default off instead, but
the default also seems useful, so i consider this ok, as it might be the more advanced
usecase.
The previous tradeoff of having a very small Thread struct is not
necessary anymore as we do not memcpy Threads on swap_next since
d708b77186.
This requires offsets to be used instead of indices for jump/split
ops.
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.
Technically we seem to be compiling with `-std=c++2a` which (if I
understand correctly) is "all the features we have from 23 and up.
But 20 is the earliest version that compiles for me (with clang). 14 and 17 didn't work.
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.
