<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src/glob.c, branch lsp</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>get rid of teco_qreg_vtable_t::undo_set_integer()</title>
<updated>2026-07-25T00:37:17+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-07-25T00:37:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=a53fa85dabdfc2c47ec0c9e6626ddda2379a8e38'/>
<id>a53fa85dabdfc2c47ec0c9e6626ddda2379a8e38</id>
<content type='text'>
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).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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).
</pre>
</div>
</content>
</entry>
<entry>
<title>revised and improved the Unicode glyph-to-byte conversion heuristics</title>
<updated>2026-07-24T23:55:28+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-07-24T23:55:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=685507922b0b75da5935076395a5b1ec1ef58356'/>
<id>685507922b0b75da5935076395a5b1ec1ef58356</id>
<content type='text'>
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 `&lt;.+1:J;&gt;`
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 `&lt;.+1:J;&gt;`
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>teco_globber_t is ported from GRegex to terex</title>
<updated>2026-06-28T00:35:17+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-06-28T00:35:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=0dfb113b47d958093e6ae086c9695e5be83b24b8'/>
<id>0dfb113b47d958093e6ae086c9695e5be83b24b8</id>
<content type='text'>
It's now a private struct, so we can include the regex_t wihout
having to draw in the terex headers everywhere.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It's now a private struct, so we can include the regex_t wihout
having to draw in the terex headers everywhere.
</pre>
</div>
</content>
</entry>
<entry>
<title>updated copyright to 2026</title>
<updated>2026-01-01T06:59:49+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-01-01T06:59:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=c2feb2a6f71fc9adb20226fb3c2260c236e974e0'/>
<id>c2feb2a6f71fc9adb20226fb3c2260c236e974e0</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>teco_string_t is now passed by value like a scalar if the callee isn't expected to modify it</title>
<updated>2025-12-28T19:57:31+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-12-28T15:23:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ea0a23645f03a42252ab1ce8df45ae4076ebae75'/>
<id>ea0a23645f03a42252ab1ce8df45ae4076ebae75</id>
<content type='text'>
* When passing a struct that should not be modified, I usually use a const pointer.
* Strings however are small 2-word objects and they are often now already passed via separate
  `gchar*` and gsize parameters. So it is consistent to pass teco_string_t by value as well.
  A teco_string_t will usually fit into registers just like a pointer.
* It's now obvious which function just _uses_ and which function _modifies_ a string.
  There is also no chance to pass a NULL pointer to those functions.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* When passing a struct that should not be modified, I usually use a const pointer.
* Strings however are small 2-word objects and they are often now already passed via separate
  `gchar*` and gsize parameters. So it is consistent to pass teco_string_t by value as well.
  A teco_string_t will usually fit into registers just like a pointer.
* It's now obvious which function just _uses_ and which function _modifies_ a string.
  There is also no chance to pass a NULL pointer to those functions.
</pre>
</div>
</content>
</entry>
<entry>
<title>TECO_DEFINE_STATE() no longer constructs callback names for mandatory callbacks, but tries to use static assertions</title>
<updated>2025-12-26T17:10:42+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-12-26T17:10:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=c2114fa0af73b42bc1ef302f7511ef87690cc0b1'/>
<id>c2114fa0af73b42bc1ef302f7511ef87690cc0b1</id>
<content type='text'>
* Requiring state callbacks by generating their names (e.g. NAME##_input) has several disadvantages:
  * The callback is not explicitly referenced when the state is defined.
    So an unintroduced reader will see some static function, which is nowhere referenced and still
    doesn't cause "unused" warnings.
  * You cannot choose the name of function that implements the callback freely.
  * In "substates" you need to generate a callback function if you want to provide a default.
    You also need to provide dummy wrapper functions whenever you want to reuse some existing
    function as the implementation.
* Instead, we are now using static assertions to check whether certain callbacks have been
  implemented.
  Unfortunately, this does not work on all compilers. In particular GCC won't consider
  references to state objects fully constant (even though they are) and does not allow
  them in _Static_assert (G_STATIC_ASSERT). This could only be made to work in newer GCC
  with -std=c2x or -std=gnu23 in combination with constexpr.
  It does work on Clang, though.
  So I introduced TECO_ASSERT_SAFE() which also passes if the expression is *not* constant.
  These static assertions are not crucial - they do not check anything that can differ between
  systems. So we can always rely on the checks performed by FreeBSD CI for instance.
  Also, you will of course quickly notice missing callbacks at runtime - with and without
  additional runtime assertions.
* All mandatory callbacks must still be explicitly initialized in the TECO_DEFINE_STATE calls.
* After getting rid of generated callback implementations, the TECO_DEFINE_STATE macros
  can finally be qualified with `static`.
* The TECO_DECLARE_STATE() macro has been removed. It no longer abstracts anything
  and cannot be used to declare static teco_state_t anyway.
  Also TECO_DEFINE_UNDO_CALL() also doesn't have a DECLARE counterpart.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Requiring state callbacks by generating their names (e.g. NAME##_input) has several disadvantages:
  * The callback is not explicitly referenced when the state is defined.
    So an unintroduced reader will see some static function, which is nowhere referenced and still
    doesn't cause "unused" warnings.
  * You cannot choose the name of function that implements the callback freely.
  * In "substates" you need to generate a callback function if you want to provide a default.
    You also need to provide dummy wrapper functions whenever you want to reuse some existing
    function as the implementation.
* Instead, we are now using static assertions to check whether certain callbacks have been
  implemented.
  Unfortunately, this does not work on all compilers. In particular GCC won't consider
  references to state objects fully constant (even though they are) and does not allow
  them in _Static_assert (G_STATIC_ASSERT). This could only be made to work in newer GCC
  with -std=c2x or -std=gnu23 in combination with constexpr.
  It does work on Clang, though.
  So I introduced TECO_ASSERT_SAFE() which also passes if the expression is *not* constant.
  These static assertions are not crucial - they do not check anything that can differ between
  systems. So we can always rely on the checks performed by FreeBSD CI for instance.
  Also, you will of course quickly notice missing callbacks at runtime - with and without
  additional runtime assertions.
* All mandatory callbacks must still be explicitly initialized in the TECO_DEFINE_STATE calls.
* After getting rid of generated callback implementations, the TECO_DEFINE_STATE macros
  can finally be qualified with `static`.
* The TECO_DECLARE_STATE() macro has been removed. It no longer abstracts anything
  and cannot be used to declare static teco_state_t anyway.
  Also TECO_DEFINE_UNDO_CALL() also doesn't have a DECLARE counterpart.
</pre>
</div>
</content>
</entry>
<entry>
<title>properly document some functions in expressions.c and simplified code</title>
<updated>2025-07-26T13:48:56+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-26T13:30:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=0ea082b74414696a7800455a437656fca2886f6d'/>
<id>0ea082b74414696a7800455a437656fca2886f6d</id>
<content type='text'>
* Practically all calls to teco_expressions_args() must be preceded by teco_expressions_eval().
* In code paths where we know that teco_expressions_args() &gt; 0, it is safe
  to call teco_expressions_pop_num(0) instead of teco_expressions_pop_num_calc().
  This is both easier and faster.
* teco_expressions_pop_num_calc() is for simple applications where you just want to get
  a command argument with default (implied) values.
  Since it includes teco_expressions_eval(), we can avoid superfluous calls.
* -EC...$ turned out to be broken and is fixed now.
  A test case has been added.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Practically all calls to teco_expressions_args() must be preceded by teco_expressions_eval().
* In code paths where we know that teco_expressions_args() &gt; 0, it is safe
  to call teco_expressions_pop_num(0) instead of teco_expressions_pop_num_calc().
  This is both easier and faster.
* teco_expressions_pop_num_calc() is for simple applications where you just want to get
  a command argument with default (implied) values.
  Since it includes teco_expressions_eval(), we can avoid superfluous calls.
* -EC...$ turned out to be broken and is fixed now.
  A test case has been added.
</pre>
</div>
</content>
</entry>
<entry>
<title>revised command topics</title>
<updated>2025-07-18T13:37:13+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-18T13:37:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=2c236869333dd20b77109fe7e9bb4ace30c0f774'/>
<id>2c236869333dd20b77109fe7e9bb4ace30c0f774</id>
<content type='text'>
* Added some keywords.
* Consistently added command variants with all modifiers.
  In principle including modifiers in the topics is unnecessary -
  you can always strip the modifiers and look up the raw command.
  However, looking up a command with modifiers can speed up the process
  (compare looking up ?S&lt;TAB&gt; vs ?::S&lt;TAB&gt;
* The `@` modifier is listed only for commands without string arguments.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Added some keywords.
* Consistently added command variants with all modifiers.
  In principle including modifiers in the topics is unnecessary -
  you can always strip the modifiers and look up the raw command.
  However, looking up a command with modifiers can speed up the process
  (compare looking up ?S&lt;TAB&gt; vs ?::S&lt;TAB&gt;
* The `@` modifier is listed only for commands without string arguments.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed ^S/^Y for &lt;Gq&gt; and &lt;EN&gt;</title>
<updated>2025-06-27T14:13:15+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-06-27T14:13:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=39249ed57170f09e7dd2fc76c62b51d90a2a4d76'/>
<id>39249ed57170f09e7dd2fc76c62b51d90a2a4d76</id>
<content type='text'>
* We must call teco_interface_bytes2glyphs() only ever with byte offsets
  that already exist in the buffer.
* regression, introduced in aaa1d51a4c85fcc627e88ef7cf5292d9c5f5f840
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* We must call teco_interface_bytes2glyphs() only ever with byte offsets
  that already exist in the buffer.
* regression, introduced in aaa1d51a4c85fcc627e88ef7cf5292d9c5f5f840
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed an asterisk in the &lt;EN&gt; manpage entry</title>
<updated>2025-06-27T14:10:14+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-06-27T14:10:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=06b4da0de1388eb8403d3ad88915c117ab84877f'/>
<id>06b4da0de1388eb8403d3ad88915c117ab84877f</id>
<content type='text'>
* We have to avoid `/*` within comments, so one of the two characters will
  have to use a named glyph.
  \[**] is actually a special symbol, which wasn't noticed until supporting Unicode.
  There is no named glyph for the plain asterisk.
  Thus we now use \[sl] to escape the `/` character.
  `/\c*` might have also worked.
* grosciteco now supports the `sl` glyph.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* We have to avoid `/*` within comments, so one of the two characters will
  have to use a named glyph.
  \[**] is actually a special symbol, which wasn't noticed until supporting Unicode.
  There is no named glyph for the plain asterisk.
  Thus we now use \[sl] to escape the `/` character.
  `/\c*` might have also worked.
* grosciteco now supports the `sl` glyph.
</pre>
</div>
</content>
</entry>
</feed>
