<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco, 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>updated TODO</title>
<updated>2026-05-31T20:02:18+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-05-31T20:02:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=d03667b609c91a18fe975686b8519a2599138dc3'/>
<id>d03667b609c91a18fe975686b8519a2599138dc3</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<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>FreeBSD port: added patches for a v2.5.2_1 release that should fix building on arm64 and riscv</title>
<updated>2026-05-19T20:52:25+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-05-19T20:52:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=957f24cf63261424288a8794f61cfdf5e5606fad'/>
<id>957f24cf63261424288a8794f61cfdf5e5606fad</id>
<content type='text'>
* 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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 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.
</pre>
</div>
</content>
</entry>
<entry>
<title>check for sbrk() even on UNIX</title>
<updated>2026-05-19T20:07:05+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-05-19T17:21:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=62177d06bd9d31242e67995d4e33a755a3447ca2'/>
<id>62177d06bd9d31242e67995d4e33a755a3447ca2</id>
<content type='text'>
* 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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 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.
</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>updated Scintilla to v5.6.2</title>
<updated>2026-05-09T21:08:15+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-05-09T21:08:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=26bcf1e04d5fcadc2fa968d7b5ce0e458d0aaa92'/>
<id>26bcf1e04d5fcadc2fa968d7b5ce0e458d0aaa92</id>
<content type='text'>
* 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.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* 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.
</pre>
</div>
</content>
</entry>
<entry>
<title>opener.check-recovery: don't pollute Q-register `_`</title>
<updated>2026-04-27T16:48:54+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-27T16:48:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=14b7d1fc5621c3251115ccf577beaabf8ab0eccc'/>
<id>14b7d1fc5621c3251115ccf577beaabf8ab0eccc</id>
<content type='text'>
This has been broken since v2.5.2.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This has been broken since v2.5.2.
</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>
</feed>
