<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/tests, 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>testsuite: added test case for help command (`?`)</title>
<updated>2026-08-10T21:55:40+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-08-10T21:49:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=d00ff9b4d72eff882eac4529d9e3c4cd9423cc4c'/>
<id>d00ff9b4d72eff882eac4529d9e3c4cd9423cc4c</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>don't crash on `0S...$`, but always throw an error</title>
<updated>2026-08-07T19:23:59+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-08-07T18:47:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=8a8edaa2daf37f7c12e21b9199755b5de8e489f5'/>
<id>8a8edaa2daf37f7c12e21b9199755b5de8e489f5</id>
<content type='text'>
* 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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 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
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed dot after an unsuccessful interactive search</title>
<updated>2026-08-04T22:05:44+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-08-04T21:58:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=df87077309d06207b234b1231128c205ec11a155'/>
<id>df87077309d06207b234b1231128c205ec11a155</id>
<content type='text'>
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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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.
</pre>
</div>
</content>
</entry>
<entry>
<title>`A` without arguments is now equivalent to `0A`</title>
<updated>2026-07-26T11:47:17+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-07-26T11:47:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=cca906658aee1dcaa38787880c54fe304f9f2e94'/>
<id>cca906658aee1dcaa38787880c54fe304f9f2e94</id>
<content type='text'>
* 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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 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.
</pre>
</div>
</content>
</entry>
<entry>
<title>conditionals can be terminated with F" now in addition to a single-quote (')</title>
<updated>2026-07-26T10:28:34+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-07-26T00:36:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=68364bd3637b6944fa1f63a00dae5caf375afab9'/>
<id>68364bd3637b6944fa1f63a00dae5caf375afab9</id>
<content type='text'>
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 '\''.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 '\''.
</pre>
</div>
</content>
</entry>
<entry>
<title>implemented E*q to store the last command line</title>
<updated>2026-07-26T10:28:34+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-07-25T23:20:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=a07512149088ec8bb47d16ed8fbbfdefd4745626'/>
<id>a07512149088ec8bb47d16ed8fbbfdefd4745626</id>
<content type='text'>
`*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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
`*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.
</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>fixed lexer initialization if $SCITECOPATH happens to contain glob characters</title>
<updated>2026-07-24T14:15:46+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-07-24T14:15:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=378b9da1476cdcac14332b89f6286a450c4a7757'/>
<id>378b9da1476cdcac14332b89f6286a450c4a7757</id>
<content type='text'>
* Always use ^ENq instead of ^EQq in the first argument of `EN`.
* Added a "Globbing" test case - globbing was undertested anyway.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Always use ^ENq instead of ^EQq in the first argument of `EN`.
* Added a "Globbing" test case - globbing was undertested anyway.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed case-insensitive searches with non-ANSI (Unicode) patterns</title>
<updated>2026-07-24T13:20:20+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-07-24T13:20:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=1ce474195699345584aaa5a8999d3158d7d8ed87'/>
<id>1ce474195699345584aaa5a8999d3158d7d8ed87</id>
<content type='text'>
* 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&lt;5&gt;`.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 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&lt;5&gt;`.
</pre>
</div>
</content>
</entry>
<entry>
<title>implemented the ^~ pattern match construct: the rest of the pattern will be an Advanced Regular Expression</title>
<updated>2026-06-28T22:32:13+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-06-28T22:15:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=3522966d9584ec16e2f469acd0fe8727857a9d25'/>
<id>3522966d9584ec16e2f469acd0fe8727857a9d25</id>
<content type='text'>
* 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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 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.
</pre>
</div>
</content>
</entry>
</feed>
