| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
* This has been broken for some time, but it didn't crash in v2.5.2.
* Even when it did not crash, the search just failed.
In TECO-11 (judging by TECOC), we must throw an error, though.
Video TECO on the other hand always succeeds in such cases.
* Added test case
|
|
I am unsure why it now suddenly causes problems.
pkg2appimage appears to download the appimagetool.
|
|
wine64 nowadays appears to require a 32-bit Wine as well, so replace
it with wine64.bin.
The quasi-msys2 python3 could theoretically also be launched with
wine64.bin, but I prefer to run it with the FreeBSD-native python3.
|
|
quasi-msys2 apparently overwrites python3 with a win32 version.
This no longer works without installing a 32-bit Wine version.
Instead, I now force it to run with the native FreeBSD python3.
|
|
It was missing a few files.
Should also fix CI runs.
|
|
--disable-malloc-replacement
sys/user.h draws in some header from openbsm, so we install it
as well into the freebsd14-sciteco container.
Should fix CI builds.
|
|
If you had a partial success during interactive searching, dot would be
left at that position since the failure handling only reset via SCI_GOTOPOS.
This is now fixed by restoring the initial dot in glyphs as well.
All existing occurrences of "dot" have been renamed to "pos" for consistency.
(Nowadays, "dot" should be reserved for glyph positions since this is what
`.` returns. Especially if both kinds of positions are used in the same code.)
A test case has been added.
This has been broken since 685507922b0b75da5935076395a5b1ec1ef58356.
|
|
* Atomics are much cheaper than mutexes for such rarely contented
fields, but they are still much slower than plain arithmetics.
* For realloc(), we'd expect relatively small changes between calls
which means that the chunk's usable size probably won't change.
Therefore it makes sense to check whether we'd get a zero addition
to teco_memory_usage.
* We will now have at most one atomic add in realloc() instead of
always 2 atomic operations.
|
|
|
|
|
|
It can also be useful for spawning $SCITECO_CLIPBOARD_SET/GET processes (currently via popen())
and for launching language servers.
|
|
Otherwise, valgrind won't be able to detect malloc()/free() misuse.
In other words, CI-driven Valgrind checks have always been broken.
|
|
But I doubt that get_string() could in practice fail on the plain
environment variable Q-Regs. So this was never triggered.
|
|
* These files are created regularily and shouldn't be mangled with unless you're
recovering from a crash.
So it makes sense to hide them by default, just like the hidden .teco-* savepoint
files.
* Recovery file name creation and checks are now centralized in file-utils.h.
|
|
* It was equivalent to `1A` which is almost never what you want.
I doubt that any existing macros would be broken by this.
But neither do I replace all `0A` in the existing code base (yet).
* `A` without arguments is a completely different "append" command in TECO-11,
but it doesn't make sense in SciTECO and I don't see what else `A` could
be repurposed for.
It cannot be made an insertion command since it depends on the stack state
which we don't track in parse-only mode.
* Added test case.
|
|
This is useful when writing small macros directly on the
command-line as in `sciteco --eval`. If you use double quoted shell
strings, too many characters have to be escaped.
If you use single-quotes, though, embedding the conditional end (')
is annoying -- it would have to be written as '\''.
|
|
`*q` can only be used at the very beginning of the command line.
We cannot support it everywhere as Video TECO did since we do
not follow the operators in parse-only mode.
`E*q` is a replacement, so you can store the previous command line at
any later point.
This also adds a test case.
|
|
|
|
It was never required as a separate callback/method,
but was kept merely for consistency.
Since we now call teco_current_doc_set_dot() in
teco_qreg_dot_set_integer(), we'd have to split it up into
an "undo" method as well. I decided to get rid of the
superfluous Q-Reg method instead.
It's quite likely we could get rid of the remaining
undo_set_string(), undo_exchange_string() and undo_edit()
callbacks as well (TODO).
|
|
Previously almost all glyph-to-byte offset conversions consulted
Scintilla's line index and counted characters on the resulting line.
For instance a simple expression like `.+1J` would scan the same line
twice completely, which would be very slow on pathologically long lines.
Even insertions did that due to having to update the ^Y ranges.
If you repeat such an operation over all characters as in `<.+1:J;>`
you would have complexity O(n^2) for n = line length.
Only commands with an explicit relative nature like `C` and `A` would
use teco_view_glyph2bytes_relative() which scans beginning at dot
as long as the relative movement is less than 1024 glyphs.
Wit the new heuristics almost all glyph-to-byte and byte-to-glyph
conversions can make use of that optimization.
This requires that dot must at all times be known in glyphs as well -
the byte position is managed by Scintilla (SCI_GETCURRENTPOS).
We therefore introduced teco_current_doc_set_dot() and
teco_current_doc_get_dot() to update dot in the current buffer or
Q-Register -- it cannot be stored along with the view since
Q-Registers share a single view.
A number of auxiliary functions have been introduced for
converting relative to a known (glyphs,bytes) offset pair
and for converting absolute and relative positions with regard
to the current doc and SCI_GETCURRENTPOS position.
Of course this is error-prone since the glyph and dot positions
are interdependant - they must always be kept in sync.
With these new optimizations even pathologically long lines can
(usually) be managed even in UTF-8 documents.
It does not address slow-downs in Scintilla's line layout, yet.
grosciteco.tes for instance runs twice as fast now.
|
|
* Always use ^ENq instead of ^EQq in the first argument of `EN`.
* Added a "Globbing" test case - globbing was undertested anyway.
|
|
* Since case-insensitivity is the default, you couldn't effectively
search for non-ANSI characters, although character classes were not affected.
* This was a terex bug, i.e. wasn't broken in v2.5.2.
* Test cases have been added.
The test case for searching for ^E (5) has been simplified using `^E<5>`.
|
|
Inlining the macro calls no longer results in a 25% speedup.
|
|
Building documentation is slow, so this speeds up
development-test cycles.
|
|
|
|
* It's already used on home:rhaberkorn:sciteco:UNSTABLE (OBS).
We cannot introduce it in STABLE though until the next stable release
which will contain the gtk-broadway-run.sh script.
* The FreeBSD packaging is actually not tested yet.
The package version had been dumped to 2.6.0 since it definitely
won't work with v2.5.2 tarballs.
The v2.5.2_1 patches have consequently also been removed.
You can still find them in the bugzilla ticket (not merged into ports yet).
|
|
* terex disables assertions by default unless you add `-DREG_DEBUG`.
Since we heavily modified the original by Henry Spencer it makes sense
to enable assertions.
* dlmalloc will still be built without assertions even if --enable-debug
is given since that has a significant speed impact and I consider
dlmalloc to be rock solid. It would need `-DDEBUG=1` to enable assertions
(among other things).
We only disable additional checks in dlmalloc if --disable-debug.
|
|
The latter sometimes fails and causes a lot of fallout on OBS servers.
gtk-broadway-run.sh uses the GTK Broadway backend instead and will
only work with GTK applications.
It is currently tested for the Debian and RPM packages and might
later be integrated into the FreeBSD package as well.
|
|
* GSpawn ends up calling posix_spawnp() which passes down a small
4kb stack to the child process until it exec()s.
This stack could be overflowed easily on code paths where the
path is not already absolute and when many shared libraries
are involved.
* The crashes could therefore only be observed on Gtk builds and
in UNIX shell emulation mode (0,128ED). Sample test case:
gsciteco -e '0,128ED @EC"ls"'
Theoretically a relative $SHELL variable could have also triggered
it.
* I assume that the bug will be fixed in libc at least by the time of
FreeBSD 16.
* As a workaround we resolve relative program paths before passing
them to g_spawn_async_with_pipes().
|
|
dlmalloc had one bogus unused variable warning, so we also added `-Wno-unused-but-set-variable`.
We don't want to change upstream sources unless absolutely necessary.
|
|
* The previous checks for interruptions only helped in a few corner cases
like for very high search-repeat counts or during backwards searches across
the entire buffer.
* But even with terex' more predictable runtime properties
a single regex execution can hang quite a long time.
E.g. `S^EM^X$` on a huge buffer or even more so with backreferences as in
`S^~(.*)\1$`.
* We now use the new tere_set_is_interrupted_cb() to register
teco_interface_is_interrupted(). Types should be compatible as long
as gboolean resolves to int.
* It's no longer necessary to manually check for teco_interface_is_interrupted()
since tere_exec() now returns REG_EINTR in case the callback returned TRUE
in which case it's handled by teco_error_regex_set().
|
|
It for some strange reason had to be escaped for AREs
even though a single freestanding `)` cannot mean anything.
|
|
This for the first time mentions all of the bundled core libraries
in the end user documentation.
|
|
an Advanced Regular Expression
* Allows searching by regular expressions.
We will never support all ARE constructs in TECO patterns, so this is useful to have available.
* Can only be typed upcaret.
This leaves ^E~q available as an escape-regexp string building construct.
* Once we replace the pattern2regexp converter with a custom terex lexer,
we might want to restrict ^~ to the beginning of the pattern.
Currently, however it can be anywhere, so you can mix TECO patterns with regular expressions.
|
|
The calculation of the block start was faulty and could cause underflows
resulting in unpredictable behavior.
|
|
regular expression
|
|
This was using g_regex_escape_string() which always translates a null byte
to `\0`, which is ambiguous if followed by other digits, so a null byte followed
by a digit would result in a wrong regular expression.
Actually the same could happen outside of character classes, ie. `@S/^@1/` was also broken.
Also it does not escape `-`, so the result cannot be used in character classes.
This is fixed now in a new custom implementation teco_regex_escape().
Once moving to a custom terex lexer, we won't need any of this of course
unless we want to provide a regex escaping string building construct.
We are now completely free of GRegex.
|
|
It's now a private struct, so we can include the regex_t wihout
having to draw in the terex headers everywhere.
|
|
* terex is based on Henry Spencer's regular expression engine for Tcl.
It is a hybrid NFA/DFA design which has better worst-time runtimes than
the backtracking PCRE. Memory usage is also limited and can no longer
increase catastrophically.
* It should no longer be possible to crash SciTECO with pathological
searches.
* Since it reliably supports partial matches (REG_EXPECT) we can
now enable the new backwards-search algorithm by default.
This used to be broken because of a glib bug, which I already
fixed. It would however take a long time until this ends up
on the majority of glib installations.
* Regexp executions can still be quite slow if you are looking
for a pattern at the end of a huge file, which can hang the editor,
but this can now at least theoretically be solved by adding
hooks into terex to poll for interruptions.
* We can now also get rid of a TECO-pattern to regexp translation
step by directly generating terex tokens (TODO).
* Performance-wise terex appears to be slower than PCRE for simple
forward searches even when linking everything with optimzations (FIXME).
* Having a stand-alone regular expression engine is also a huge
step in getting rid of glib.
See also: https://git.fmsbw.de/terex/about/
|
|
|
|
A partial match __should__ always be at the end of the subject string
(i.e. block), so we don't have to check for it.
Also, partial matches will be rare, so we can discriminate against
the branch that handles them.
|
|
|
|
* The block-wise search algorithm allows for efficient backwards searches
on large files.
* On the downside the results are not entirely symmetric to forward searches.
It therefore makes sense to still support the old correct but possibly slow
algorithm.
Since the old algorithm is just a special case of the new one (with a single
block stretching the entire search range), you can configure the block size
using `8EJ`.
* Unfortunately, the new block-wise algorithm won't work due to a bug in GRegex
(only in the glib wrapper code).
It is therefore disabled for the time being by default and will probably
only be enabled once we switch to a new regexp engine.
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/5199
|
|
on arm64 and riscv
* I don't want to release a new upstream version since master isn't stable, yet.
I also don't want to branch out a stable v2.5 branch.
So we just add the necessary patch files.
* Also fixes the `_` register pollution when opening new files.
* Should fix Poudriere arm64 builds that are currently causing fallout.
|
|
* Turns out that not all UNIXes support sbrk().
FreeBSD arm64 and riscv ports don't implement sbrk().
It's also apparently not in POSIX - so other systems might also
be affected.
This needs to be passed on to dlmalloc.
* We now use DLMALLOC_CPPFLAGS instead of conditionals to pass
on flags to dlmalloc.
* Should be backported to the FreeBSD v2.5.2 package
to fix Poudriere fallout.
|
|
* You can provoke hangs in forward searches when opening large files:
`100000S^X$`
This cannot be sped up, but must be interruptible.
* With backwards searches it is even easier to provoke.
Go to the end of a large file and perform any backwards search,
even `-S$`.
Since we must always search from the beginning of the document,
you will always produce all matches over the entire document.
There might be ways to speed up backwards searches, but they must
be interruptible anyway.
* Perhaps we can extend back the search range in chunks of 1-4kb
until we produce at least `-count` matches.
|
|
This would be a C23 extension.
|
|
* The terminal's default foreground and background colors
are now used by default (`sciteco --no-profile`), so SciTECO
integrates naturally into all terminal color schemes, even
dark-on-bright ones.
* The default Scintilla colors use only 0x000000 (COLOR_BLACK) and 0xC0C0C0 (COLOR_WHITE)
now.
* You can use `7EJ` to configure the default colors in color
schemes or your profile.
All existing color schemes had to disable default colors
(`-1,-1,7EJ`) since they wouldn't look well otherwise.
* You may add `-1,7EJ` to ~/.teco_ini when using a terminal emulator
with a washed-out palettized COLOR_BLACK.
We cannot detect the terminal's default colors automatically.
* Scinterm updated to v6.0.
We require a not-yet-upstreamed patch:
https://github.com/orbitalquark/scinterm/pull/40
* In fact, we might decide not to support default colors at all in Scinterm,
so this feature should be considered experimental.
|
|
* This is mainly to support Scinterm 6.0, which does not appear to
work with older Scintilla versions (obviously a bug).
* SCI_SETTABDRAWMODE(SCTD_CONTROLCHAR) has been merged upstream
* SC_LINE_END_TYPE_NONE will not be merged and may have to be
permanently maintained.
|
|
This has been broken since v2.5.2.
|
