<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src/view.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>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>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>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>fixup: renamed "backups" to "recovery files"</title>
<updated>2025-12-19T22:25:48+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-12-19T22:25:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=2592ef74ab2eba57c32fe21993ce01e9698b106f'/>
<id>2592ef74ab2eba57c32fe21993ce01e9698b106f</id>
<content type='text'>
* Other editors call "backup files" previous copies of saved files.
  This role would be served by savepoint files in SciTECO.
* Likewise filename~ would point to such a backup file.
  It therefore makes sense that savepoint files also end in tildes (.teco-n-filename~).
* Security copies of modified buffers would be called "auto-saves" (Emacs) or
  "swap files" (Vim).
  Both of these terms is IMHO misleading, so SciTECO now uses the
  term "recovery file".
* "Recovery files" are now named #filename# just like in Emacs.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Other editors call "backup files" previous copies of saved files.
  This role would be served by savepoint files in SciTECO.
* Likewise filename~ would point to such a backup file.
  It therefore makes sense that savepoint files also end in tildes (.teco-n-filename~).
* Security copies of modified buffers would be called "auto-saves" (Emacs) or
  "swap files" (Vim).
  Both of these terms is IMHO misleading, so SciTECO now uses the
  term "recovery file".
* "Recovery files" are now named #filename# just like in Emacs.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixup: must not use teco_view_save_to_file() when creating backup/recovery files</title>
<updated>2025-12-18T01:10:46+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-12-18T01:10:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=714875f3c0c22ed01a8e777755b281c97f2b52b8'/>
<id>714875f3c0c22ed01a8e777755b281c97f2b52b8</id>
<content type='text'>
* It emits undo tokens which would bring internal datastructures - especially the undo stack -
  out of sync.
* We now document that teco_view_save_to_channel() will always be without undo token emission.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* It emits undo tokens which would bring internal datastructures - especially the undo stack -
  out of sync.
* We now document that teco_view_save_to_channel() will always be without undo token emission.
</pre>
</div>
</content>
</entry>
<entry>
<title>avoid FILENAME_MAX for allocating on the stack</title>
<updated>2025-12-14T20:49:58+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-12-14T20:49:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ad0780c7163c9673f89dc584d2a6096f317bec2b'/>
<id>ad0780c7163c9673f89dc584d2a6096f317bec2b</id>
<content type='text'>
* FILENAME_MAX is a standard C macro, but it may be arbitrarily long on some platforms
  (like the popular GNU/Hurd). See:
  https://www.gnu.org/software/libc/manual/html_node/Limits-for-Files.html#index-FILENAME_005fMAX
* This means there is no portable macro for the maximum path length.
  You could perhaps define PATH_MAX to MAX_PATH on Windows.
* Instead, we use g_strdup_printf() to calculate the save point name.
  We avoid another g_build_filename() by prepending the directory in the printf().
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* FILENAME_MAX is a standard C macro, but it may be arbitrarily long on some platforms
  (like the popular GNU/Hurd). See:
  https://www.gnu.org/software/libc/manual/html_node/Limits-for-Files.html#index-FILENAME_005fMAX
* This means there is no portable macro for the maximum path length.
  You could perhaps define PATH_MAX to MAX_PATH on Windows.
* Instead, we use g_strdup_printf() to calculate the save point name.
  We avoid another g_build_filename() by prepending the directory in the printf().
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed rub out of file writes to non-existing symlinks</title>
<updated>2025-12-09T00:12:57+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-12-09T00:12:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=a886813f86f88b4b1cc874a81229b7b59d0d463a'/>
<id>a886813f86f88b4b1cc874a81229b7b59d0d463a</id>
<content type='text'>
* teco_file_get_absolute_path() does not currently guarantee to resolve
  non-existent parts of the path.
  When opening a symbolic link to a non-existing file, it would only
  be created when writing out the file.
  The undo token to remove it, however would remove the original
  unresolved path.
  When rubbing out the EW, the symlink would get removed instead
  of the newly written file.
* We now resolve/canonicalize the path again immediately after
  opening the new file, which should ensure that it resolves.
* As an alternative, we might have also tried to reliably canonicalize
  non-existent symlinks. This however is tricky and there would have
  to be a break condition to guard against cyclic symlinke.
  In the end there is no guarantee to be able to resolve a path
  exactly like the OS does.
  Therefore, teco_file_get_absolute_path() was not touched,
  not even on UNIX.
* A test case was not added since it would rely on creating real symlinks.
  It wouldn't work on MSYS when `ln -s` falls back to hardlinks.
  Perhaps other non-UNIX platforms would have similar restrictions.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* teco_file_get_absolute_path() does not currently guarantee to resolve
  non-existent parts of the path.
  When opening a symbolic link to a non-existing file, it would only
  be created when writing out the file.
  The undo token to remove it, however would remove the original
  unresolved path.
  When rubbing out the EW, the symlink would get removed instead
  of the newly written file.
* We now resolve/canonicalize the path again immediately after
  opening the new file, which should ensure that it resolves.
* As an alternative, we might have also tried to reliably canonicalize
  non-existent symlinks. This however is tricky and there would have
  to be a break condition to guard against cyclic symlinke.
  In the end there is no guarantee to be able to resolve a path
  exactly like the OS does.
  Therefore, teco_file_get_absolute_path() was not touched,
  not even on UNIX.
* A test case was not added since it would rely on creating real symlinks.
  It wouldn't work on MSYS when `ln -s` falls back to hardlinks.
  Perhaps other non-UNIX platforms would have similar restrictions.
</pre>
</div>
</content>
</entry>
<entry>
<title>render tabs as "TAB" in the command-line and in SciTECO macros</title>
<updated>2025-11-02T22:21:21+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-11-02T22:21:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=1391e9c6ea1f9bef965f96e70f4e27141abcb5cd'/>
<id>1391e9c6ea1f9bef965f96e70f4e27141abcb5cd</id>
<content type='text'>
* This requires the new SCI_SETTABDRAWMODE(SCTD_CONTROLCHAR).
* It makes no sense to let TAB indent in TECO code as it can be
  the insert-with-tab command (^I).
  On the other hand large `I`-blocks could include TABs which are
  actually meant as indentations.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This requires the new SCI_SETTABDRAWMODE(SCTD_CONTROLCHAR).
* It makes no sense to let TAB indent in TECO code as it can be
  the insert-with-tab command (^I).
  On the other hand large `I`-blocks could include TABs which are
  actually meant as indentations.
</pre>
</div>
</content>
</entry>
<entry>
<title>avoid g_prefix_error_literal(), which requires glib 2.70</title>
<updated>2025-08-27T15:07:49+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-08-27T15:07:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=61c1980e25cc5ce48d7c3902db1e39f6b92473f9'/>
<id>61c1980e25cc5ce48d7c3902db1e39f6b92473f9</id>
<content type='text'>
This broke builds e.g. on Ubuntu 20.04.
Regression was introduced in 51bd183f064d0c0ea5e0184d9f6b6b62e5c01e50.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This broke builds e.g. on Ubuntu 20.04.
Regression was introduced in 51bd183f064d0c0ea5e0184d9f6b6b62e5c01e50.
</pre>
</div>
</content>
</entry>
<entry>
<title>added --quiet, --stdin and --stdout for easier integration into UNIX pipelines</title>
<updated>2025-08-03T13:09:33+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-08-03T12:41:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=51bd183f064d0c0ea5e0184d9f6b6b62e5c01e50'/>
<id>51bd183f064d0c0ea5e0184d9f6b6b62e5c01e50</id>
<content type='text'>
* In principle --stdin and --stdout could have been done in pure TECO code using the
  &lt;^T&gt; command.
  Having built-in command-line arguments however has several advantages:
  * Significantly faster than reading byte-wise with ^T.
  * Performs EOL normalization unless specifying --8bit of course.
  * Significantly shortens command-lines.
    `sciteco -qio` and `sciteco -qi` can be real replacements for sed and awk.
* You can even place SciTECO into the middle of a pipeline while editing
  interactively:
  foo | sciteco -qio --no-profile | bar
  Unfortunately, this will not currently work when munging the profile
  as command-line parameters are also transmitted via the unnamed buffer.
  This should be changed to use special Q-registers (FIXME).
* --quiet can help to improve the test suite (TODO).
  Should probably be the default in TE_CHECK().
* --stdin and --stdout allow to simplify many SciTECO scripts, avoiding
  temporary files, especially for womenpage generation (TODO).
* For processing potentially infinite streams, you will still have to
  read using ^T.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* In principle --stdin and --stdout could have been done in pure TECO code using the
  &lt;^T&gt; command.
  Having built-in command-line arguments however has several advantages:
  * Significantly faster than reading byte-wise with ^T.
  * Performs EOL normalization unless specifying --8bit of course.
  * Significantly shortens command-lines.
    `sciteco -qio` and `sciteco -qi` can be real replacements for sed and awk.
* You can even place SciTECO into the middle of a pipeline while editing
  interactively:
  foo | sciteco -qio --no-profile | bar
  Unfortunately, this will not currently work when munging the profile
  as command-line parameters are also transmitted via the unnamed buffer.
  This should be changed to use special Q-registers (FIXME).
* --quiet can help to improve the test suite (TODO).
  Should probably be the default in TE_CHECK().
* --stdin and --stdout allow to simplify many SciTECO scripts, avoiding
  temporary files, especially for womenpage generation (TODO).
* For processing potentially infinite streams, you will still have to
  read using ^T.
</pre>
</div>
</content>
</entry>
</feed>
