<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src, branch master</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>implemented but disabled block-wise backwards search algorithm</title>
<updated>2026-05-31T19:19:24+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-05-31T19:19:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=aa7b0bb1445feeefafdcf47fd639b10500b45c03'/>
<id>aa7b0bb1445feeefafdcf47fd639b10500b45c03</id>
<content type='text'>
* 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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 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
</pre>
</div>
</content>
</entry>
<entry>
<title>allow CTRL+C interrupting forward and background searches</title>
<updated>2026-05-10T21:47:26+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-05-10T21:47:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=c011363117c18d9332c42d4e5ec7f6ba3f932ec3'/>
<id>c011363117c18d9332c42d4e5ec7f6ba3f932ec3</id>
<content type='text'>
* 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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 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.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixup: prevent warnings due to missing parameter names</title>
<updated>2026-05-10T11:11:03+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-05-10T11:11:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=db314a6b421a0bc4a8d58605e9bd18f7aa2067cd'/>
<id>db314a6b421a0bc4a8d58605e9bd18f7aa2067cd</id>
<content type='text'>
This would be a C23 extension.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This would be a C23 extension.
</pre>
</div>
</content>
</entry>
<entry>
<title>support "default colors"</title>
<updated>2026-05-09T22:15:52+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-05-09T22:15:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=58a0f8def5742248bf235c7c9cd9d3efcb334751'/>
<id>58a0f8def5742248bf235c7c9cd9d3efcb334751</id>
<content type='text'>
* 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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 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.
</pre>
</div>
</content>
</entry>
<entry>
<title>Curses: support arbitrary RGB colors</title>
<updated>2026-04-26T00:00:18+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-26T00:00:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=282fa65c0d547c89eac6cd4c7e91496a280bece7'/>
<id>282fa65c0d547c89eac6cd4c7e91496a280bece7</id>
<content type='text'>
* Instead of supporting only 16 predefined RGB placeholder
  values in Scintilla messages and styles, you can now use
  arbitrary RGB values and colors are allocated via the terminal
  on the fly.
  You no longer need to call 3EJ to change the default color
  palette.
* The placeholder RGB values are still available.
  Since you will usually want exact RGB values when using
  anything outside of the range of 16 default colors
  and the RGB placeholders will not always exactly correspond
  to their RGB value, you can now call `0,3EJ` to ignore
  the default palette and allocate all colors dynamically.
* Allows for more than 16 colors on the screen simultaneously.
  Also simplifies the solarized.tes color scheme.
  Since both Scinterm and SciTECO try not to touch the 16
  default colors, you also no longer have to deal with
  restoring the palette after program termination
  (which was never reliable anyway).
* Color schemes with non-default colors (solarized.tes)
  may now be broken on TERM=linux-16color (Linux VT)
  since Scinterm will get only 8 colors, but solarized.tes
  needs 16.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Instead of supporting only 16 predefined RGB placeholder
  values in Scintilla messages and styles, you can now use
  arbitrary RGB values and colors are allocated via the terminal
  on the fly.
  You no longer need to call 3EJ to change the default color
  palette.
* The placeholder RGB values are still available.
  Since you will usually want exact RGB values when using
  anything outside of the range of 16 default colors
  and the RGB placeholders will not always exactly correspond
  to their RGB value, you can now call `0,3EJ` to ignore
  the default palette and allocate all colors dynamically.
* Allows for more than 16 colors on the screen simultaneously.
  Also simplifies the solarized.tes color scheme.
  Since both Scinterm and SciTECO try not to touch the 16
  default colors, you also no longer have to deal with
  restoring the palette after program termination
  (which was never reliable anyway).
* Color schemes with non-default colors (solarized.tes)
  may now be broken on TERM=linux-16color (Linux VT)
  since Scinterm will get only 8 colors, but solarized.tes
  needs 16.
</pre>
</div>
</content>
</entry>
<entry>
<title>do not execute `^A` in parse-only mode</title>
<updated>2026-04-19T22:27:45+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-19T22:24:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=38130f053e84535e37630e1388b858c46c580f9f'/>
<id>38130f053e84535e37630e1388b858c46c580f9f</id>
<content type='text'>
This was especially dangerous since the introduction of
a message level parameter, which could still be popped from
the expression stack in parse-only mode or during lexing.
This effectively broke n^A interactively in GTK.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This was especially dangerous since the introduction of
a message level parameter, which could still be popped from
the expression stack in parse-only mode or during lexing.
This effectively broke n^A interactively in GTK.
</pre>
</div>
</content>
</entry>
<entry>
<title>teco_view_load_from_channel() now temporarily releases the line character index on the correct view</title>
<updated>2026-04-19T09:43:02+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-19T09:38:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=2b8d3f93fdb92df3e67fabff779a2ac1d91358b7'/>
<id>2b8d3f93fdb92df3e67fabff779a2ac1d91358b7</id>
<content type='text'>
* Had been broken since introduction in v2.3.0.
* This slowed down EQq&lt;filename&gt;$ on large files.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Had been broken since introduction in v2.3.0.
* This slowed down EQq&lt;filename&gt;$ on large files.
</pre>
</div>
</content>
</entry>
<entry>
<title>UNIX: do not automatically restart syscalls on SIGINT</title>
<updated>2026-04-18T22:02:16+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-18T22:02:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=d4c864e92f89003e73883fe0b259e6c2e3bfb4f3'/>
<id>d4c864e92f89003e73883fe0b259e6c2e3bfb4f3</id>
<content type='text'>
* signal() sets SA_RESTART by default.
* Some syscalls can theoretically block indefinitely.
  Even opening a special file could result in an indefinitely
  blocking operation, that should be interruptible.
  You must still poll teco_interrupted in these read() loops of course.
* Also makes sure that clipboard operations are interruptible
  even if $SCITECO_CLIPBOARD_GET blocks.
  Although I couldn't provoke problems in practice,
  I did observe hangs with xclip on Wayland on Linux,
  that could only be resolved by manually killing xclip.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* signal() sets SA_RESTART by default.
* Some syscalls can theoretically block indefinitely.
  Even opening a special file could result in an indefinitely
  blocking operation, that should be interruptible.
  You must still poll teco_interrupted in these read() loops of course.
* Also makes sure that clipboard operations are interruptible
  even if $SCITECO_CLIPBOARD_GET blocks.
  Although I couldn't provoke problems in practice,
  I did observe hangs with xclip on Wayland on Linux,
  that could only be resolved by manually killing xclip.
</pre>
</div>
</content>
</entry>
<entry>
<title>Curses: fixed rendering bright/light colors on 8-color terminals</title>
<updated>2026-04-16T23:18:20+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-16T23:18:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=869de7c6270c50481499c201aa16aa5bc3a56739'/>
<id>869de7c6270c50481499c201aa16aa5bc3a56739</id>
<content type='text'>
* Scinterm was simply rendering them as black, thus effectively
  breaking the Linux and FreeBSD vts with terminal.tes.
* I was considering to render light black as white on 8-color terminals,
  so it's always readable.
  However, if you add in A_BOLD there is a good chance that the
  color will end up grey - at least it does in the virtual terminals (consoles).
* There is no need to use bright colors in the Scintilla view defaults.
  E.g. 0xFFFFF is "light white".
  However on 8-color terminals this will be rendered like white anyway.
  The new defaults are closer to what terminal.tes does.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Scinterm was simply rendering them as black, thus effectively
  breaking the Linux and FreeBSD vts with terminal.tes.
* I was considering to render light black as white on 8-color terminals,
  so it's always readable.
  However, if you add in A_BOLD there is a good chance that the
  color will end up grey - at least it does in the virtual terminals (consoles).
* There is no need to use bright colors in the Scintilla view defaults.
  E.g. 0xFFFFF is "light white".
  However on 8-color terminals this will be rendered like white anyway.
  The new defaults are closer to what terminal.tes does.
</pre>
</div>
</content>
</entry>
<entry>
<title>`^A` now accepts an optional integer to specify the message severity</title>
<updated>2026-04-14T21:19:45+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-13T23:16:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=34af154e92383161666751ca69a288c98f5cca60'/>
<id>34af154e92383161666751ca69a288c98f5cca60</id>
<content type='text'>
* I.e. you can now log warnings and errors from SciTECO code as well.
* We do not need a version of ^A accepting code points, since this is
  supported by ^T already.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* I.e. you can now log warnings and errors from SciTECO code as well.
* We do not need a version of ^A accepting code points, since this is
  supported by ^T already.
</pre>
</div>
</content>
</entry>
</feed>
