<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src/interface-curses/interface.c, branch v2.5.2</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<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>GTK: SIGTERM/SIGHUP always terminates the program and dumps recovery files</title>
<updated>2026-04-12T21:00:40+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-12T19:47:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=0a8770ac7d382df8976b2448fccc6cfe434cd4d1'/>
<id>0a8770ac7d382df8976b2448fccc6cfe434cd4d1</id>
<content type='text'>
* SIGTERM used to insert the ^KCLOSE key macro.
  However with the default ^KCLOSE macro, which inserts `EX`,
  this may fail to terminate the editor if buffers are modified.
  If the process is consequently killed by a non-ignorable signal,
  we may still loose data.
* SIGTERM is used to gracefully shut down, so we now always terminate.
  Since we have recovery files, they are now dumped before terminating.
  This makes sure that recovery files are more up-to-date during
  unexpected but gracefull terminations.
* The same functionality is planned on Curses, but requires more fundamental
  changes (TODO).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* SIGTERM used to insert the ^KCLOSE key macro.
  However with the default ^KCLOSE macro, which inserts `EX`,
  this may fail to terminate the editor if buffers are modified.
  If the process is consequently killed by a non-ignorable signal,
  we may still loose data.
* SIGTERM is used to gracefully shut down, so we now always terminate.
  Since we have recovery files, they are now dumped before terminating.
  This makes sure that recovery files are more up-to-date during
  unexpected but gracefull terminations.
* The same functionality is planned on Curses, but requires more fundamental
  changes (TODO).
</pre>
</div>
</content>
</entry>
<entry>
<title>Curses: handle window resizes when blocking in `^T` and don't return function keys</title>
<updated>2026-04-04T12:04:48+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-04T11:48:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=0f39109d6bb4ed14b51164791621620cc6b5d461'/>
<id>0f39109d6bb4ed14b51164791621620cc6b5d461</id>
<content type='text'>
* There was a logic error in teco_interface_getch() that caused Curses function key
  codes to be returned directly. These codes however are useless to macro authors and
  can be confused with codepoints. You cannot report function keys in the same "namespace"
  along with Unicode codepoints.
  They are now filtered out.
* Also make sure that Backspace and Return are reported as 8 and 10 respectively
  in all Curses variants.
  All control codes reported by Curses are passed down unmodified - in contrast to
  the command-line input handling. I.e. 13 is not normalized to 10.
* PDCursesMod/WinGUI may return bogus key presses, that also have to be filtered out
  as we already did in the main input handling.
  A function teco_interface_check_key() has been introduced.
* NOTE: teco_interface_blocking_getch() already makes sure that recovery files are dumped
  even when blocking in `^T`.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* There was a logic error in teco_interface_getch() that caused Curses function key
  codes to be returned directly. These codes however are useless to macro authors and
  can be confused with codepoints. You cannot report function keys in the same "namespace"
  along with Unicode codepoints.
  They are now filtered out.
* Also make sure that Backspace and Return are reported as 8 and 10 respectively
  in all Curses variants.
  All control codes reported by Curses are passed down unmodified - in contrast to
  the command-line input handling. I.e. 13 is not normalized to 10.
* PDCursesMod/WinGUI may return bogus key presses, that also have to be filtered out
  as we already did in the main input handling.
  A function teco_interface_check_key() has been introduced.
* NOTE: teco_interface_blocking_getch() already makes sure that recovery files are dumped
  even when blocking in `^T`.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixup color pair support: updated Scinterm again</title>
<updated>2026-02-02T17:11:44+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-02-02T17:11:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ba2cf86f1889a334772aba56186a14150a96b2f3'/>
<id>ba2cf86f1889a334772aba56186a14150a96b2f3</id>
<content type='text'>
This is for some minor cleanup.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is for some minor cleanup.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixup: high-color-pair support was still broken in Scinterm</title>
<updated>2026-01-30T13:36:20+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-01-30T13:22:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e624826447d83f1b79e5442d3695a7528cf578cf'/>
<id>e624826447d83f1b79e5442d3695a7528cf578cf</id>
<content type='text'>
* Also updated A_XXX attributes to WA_XXX, where the "new" wattr_set() APIs
  are used. This doesn't make a difference on ncurses and PDCurses, but the
  X/Open standard demands it.
* Allow color pairs up to 32767 instead of only up to 32766.
* We now always require Curses wide-character APIs due to Scinterm,
  which has to use mvwin_wch(). We were practically depending on wide-character
  support anyway, so this shouldn't really restrict portability.
* teco_curses_add_wc() has been simplified, now that we can rely on
  wide-char APIs. Perhaps it should be removed altogether?
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Also updated A_XXX attributes to WA_XXX, where the "new" wattr_set() APIs
  are used. This doesn't make a difference on ncurses and PDCurses, but the
  X/Open standard demands it.
* Allow color pairs up to 32767 instead of only up to 32766.
* We now always require Curses wide-character APIs due to Scinterm,
  which has to use mvwin_wch(). We were practically depending on wide-character
  support anyway, so this shouldn't really restrict portability.
* teco_curses_add_wc() has been simplified, now that we can rely on
  wide-char APIs. Perhaps it should be removed altogether?
</pre>
</div>
</content>
</entry>
<entry>
<title>Curses: support up to 32767 color pairs</title>
<updated>2026-01-26T18:50:03+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-01-26T18:50:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=7fa9feae452ea05a083b17d3f0cdf69bf5d37822'/>
<id>7fa9feae452ea05a083b17d3f0cdf69bf5d37822</id>
<content type='text'>
* Instead of ORing COLOR_PAIR() into attributes, always pass separate `pair` arguments.
  Since they are `short` this allows for up to 32767 color pairs.
  Previously, we could only count on 256 color pairs (or 128 for SciTECO and Scinterm each).
* Analoguous changes have been made to Scinterm.
  See also https://github.com/orbitalquark/scinterm/pull/37
  Since it only correctly checks for overflows at the end of the color pair space, we allocate the second
  half of that space to Scinterm.
  It is now very unlikely to overflow the color pair space, though.
* This wasn't critical of course since even the 128 pairs would be unlikely to exhaust as long
  as we support only 16 ANSI colors.
  Scinterm however supports arbitrary RGB colors and we might want to do so soon as well.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Instead of ORing COLOR_PAIR() into attributes, always pass separate `pair` arguments.
  Since they are `short` this allows for up to 32767 color pairs.
  Previously, we could only count on 256 color pairs (or 128 for SciTECO and Scinterm each).
* Analoguous changes have been made to Scinterm.
  See also https://github.com/orbitalquark/scinterm/pull/37
  Since it only correctly checks for overflows at the end of the color pair space, we allocate the second
  half of that space to Scinterm.
  It is now very unlikely to overflow the color pair space, though.
* This wasn't critical of course since even the 128 pairs would be unlikely to exhaust as long
  as we support only 16 ANSI colors.
  Scinterm however supports arbitrary RGB colors and we might want to do so soon as well.
</pre>
</div>
</content>
</entry>
<entry>
<title>GTK: fixed --detach and support stdout/stderr redirections</title>
<updated>2026-01-24T15:37:27+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-01-24T15:29:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=7ff541040edc3b3f8a25bb69e04ecb57cba12954'/>
<id>7ff541040edc3b3f8a25bb69e04ecb57cba12954</id>
<content type='text'>
* We fork after command line arguments have been parsed, which
  is after gtk_get_option_group() has been called.
  This means that GTK was already initialized and it wasn't safe
  to continue after forking.
* As a workaround, we now re-exec with the original argv array,
  so GTK can be properly reinitialized.
  Since we did not remove `--detach` from argv (and that would be
  nontrivial), it would fork again endlessly,
  so we use an environment variable
  $__SCITECO_DETACHED to guard against recursive forks.
* Also, do not close stdin/stdout/stderr if has been redirected
  to a file, so you can now e.g. call `gsciteco -d &gt;some-file`.
* This was broken since v2.5.0.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* We fork after command line arguments have been parsed, which
  is after gtk_get_option_group() has been called.
  This means that GTK was already initialized and it wasn't safe
  to continue after forking.
* As a workaround, we now re-exec with the original argv array,
  so GTK can be properly reinitialized.
  Since we did not remove `--detach` from argv (and that would be
  nontrivial), it would fork again endlessly,
  so we use an environment variable
  $__SCITECO_DETACHED to guard against recursive forks.
* Also, do not close stdin/stdout/stderr if has been redirected
  to a file, so you can now e.g. call `gsciteco -d &gt;some-file`.
* This was broken since v2.5.0.
</pre>
</div>
</content>
</entry>
<entry>
<title>Curses: fixed colors on emulators with less than 256 color pairs</title>
<updated>2026-01-21T18:12:08+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-01-18T21:06:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=a3116cb6c3caee368bb1ccbfbe43a4fab823bfa1'/>
<id>a3116cb6c3caee368bb1ccbfbe43a4fab823bfa1</id>
<content type='text'>
* For instance on TERM=rxvt.
  Generally 8-color emulators will usually support only 65 color pairs.
* On emulators that support more than 256 pairs, we must still limit them
  to 256 (or 128 for Scinterm and SciTECO) since we still use a single
  attribute for colors and misc. attributes (see COLOR_PAIR()).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* For instance on TERM=rxvt.
  Generally 8-color emulators will usually support only 65 color pairs.
* On emulators that support more than 256 pairs, we must still limit them
  to 256 (or 128 for Scinterm and SciTECO) since we still use a single
  attribute for colors and misc. attributes (see COLOR_PAIR()).
</pre>
</div>
</content>
</entry>
<entry>
<title>Curses: fixed flickering of the hardware cursor</title>
<updated>2026-01-15T00:06:38+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-01-15T00:06:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=7fece4c0a8a685d5ada4dfb89ce5fd7efa9f38fa'/>
<id>7fece4c0a8a685d5ada4dfb89ce5fd7efa9f38fa</id>
<content type='text'>
* Disabling the cursor with every key press caused a cursor status change when
  using CARETSTYLE_CURSES, which resulted in flickering, especially when using the
  cursor keys or typing quickly.
* Instead we now disable the cursor only if CARETSTYLE_CURSES is NOT used on the
  command line.
* It would be good to use curs_set(2) for `^T` - in some emulators it causes
  e.g. a blinking cursor - but it wouldn't be visible in simpleterm.
  This is probably just because it doesn't guarantee any contrast.
* This was broken in v2.5.1.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Disabling the cursor with every key press caused a cursor status change when
  using CARETSTYLE_CURSES, which resulted in flickering, especially when using the
  cursor keys or typing quickly.
* Instead we now disable the cursor only if CARETSTYLE_CURSES is NOT used on the
  command line.
* It would be good to use curs_set(2) for `^T` - in some emulators it causes
  e.g. a blinking cursor - but it wouldn't be visible in simpleterm.
  This is probably just because it doesn't guarantee any contrast.
* This was broken in v2.5.1.
</pre>
</div>
</content>
</entry>
<entry>
<title>Curses: the hardware cursor is enabled by default now on the command line</title>
<updated>2026-01-10T15:15:07+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-01-10T14:58:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=37d8808d4009df862da9976c765d5958ce5d2a63'/>
<id>37d8808d4009df862da9976c765d5958ce5d2a63</id>
<content type='text'>
If you dislike this, you can always revert to the old style by adding the
following to your profile:

  0,2048ED 2#16@ES/SETCARETSTYLE//$ 2048,0ED
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If you dislike this, you can always revert to the old style by adding the
following to your profile:

  0,2048ED 2#16@ES/SETCARETSTYLE//$ 2048,0ED
</pre>
</div>
</content>
</entry>
</feed>
