<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/doc, 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>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>support Groff v1.24.0 and later</title>
<updated>2026-03-22T11:01:08+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-03-22T11:01:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=aa454020558929ce1f15561c2bf8a06be182d115'/>
<id>aa454020558929ce1f15561c2bf8a06be182d115</id>
<content type='text'>
There has been a regression affecting early uses of `.device`.
See https://savannah.gnu.org/bugs/?67992
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There has been a regression affecting early uses of `.device`.
See https://savannah.gnu.org/bugs/?67992
</pre>
</div>
</content>
</entry>
<entry>
<title>Cheat Sheet: added `n===` example</title>
<updated>2026-01-10T15:38:48+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-01-10T15:38:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=f1c7b68b591a6b73d126189ef5ebf5b120d48d92'/>
<id>f1c7b68b591a6b73d126189ef5ebf5b120d48d92</id>
<content type='text'>
Otherwise the cheat sheet should be up to date.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Otherwise the cheat sheet should be up to date.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixup bcba0ef4486eb9baec3cd4d17250b91e1c8a7f79: fixed failures when building in doc/</title>
<updated>2026-01-01T19:02:42+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-01-01T19:02:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=3f711b83a851fd3247df1c7d2a19b3519e73fad7'/>
<id>3f711b83a851fd3247df1c7d2a19b3519e73fad7</id>
<content type='text'>
* When fixing up hash-bang lines, `::FS` returns a status integer, which was returned by the process
* also avoid expanding Make variables into TECO code - better pass it as a command-line argument
* should also fix OBS builds
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* When fixing up hash-bang lines, `::FS` returns a status integer, which was returned by the process
* also avoid expanding Make variables into TECO code - better pass it as a command-line argument
* should also fix OBS builds
</pre>
</div>
</content>
</entry>
<entry>
<title>no longer touch installed files at install-time</title>
<updated>2025-12-31T19:55:47+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-12-31T15:55:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=bcba0ef4486eb9baec3cd4d17250b91e1c8a7f79'/>
<id>bcba0ef4486eb9baec3cd4d17250b91e1c8a7f79</id>
<content type='text'>
* hash-bang lines in grosciteco.tes and tedoc.tes are fixed up
  at build time instead of install-time (via install-exec-hook).
* This will hopefully resolve problems with the FreeBSD port,
  since Poudriere installs the package as non-root but with BINMODE=555.
  The alternative would have been to set BINMODE=755 in the port which may not
  be acceptible by the official port committer.
  Anyway, I decided to go out of the way of any conflicts.
  See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?format=multiple&amp;id=283601
* On the downside, this will break install-path overrides at install-time
  (e.g. `make install bindir=...`).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* hash-bang lines in grosciteco.tes and tedoc.tes are fixed up
  at build time instead of install-time (via install-exec-hook).
* This will hopefully resolve problems with the FreeBSD port,
  since Poudriere installs the package as non-root but with BINMODE=555.
  The alternative would have been to set BINMODE=755 in the port which may not
  be acceptible by the official port committer.
  Anyway, I decided to go out of the way of any conflicts.
  See also https://bugs.freebsd.org/bugzilla/show_bug.cgi?format=multiple&amp;id=283601
* On the downside, this will break install-path overrides at install-time
  (e.g. `make install bindir=...`).
</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>implemented backup file mechanism</title>
<updated>2025-12-17T00:17:11+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-12-17T00:17:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=deed71ac895451041359d7b18e58eca0a0972bc3'/>
<id>deed71ac895451041359d7b18e58eca0a0972bc3</id>
<content type='text'>
* The backup mechanism is supposed to guard against crashes of SciTECO and
  unexpected program terminations (e.g. power cycling, etc.)
* In a given interval (no matter whether busy or idlying on the prompt)
  SciTECO saves all modified buffers with the filename~ (like most other editors).
  As an optimization files are not backed up if they have been backed up
  previously to avoid pointless and possibly slow file system writes.
* While the backup mechanism exists outside of the usual undo-paradigm -
  backup file creating is not bound to character input and it makes no sense
  to restore the exact state of backup files - there are some interesting
  interactions:
  * When a buffer is dirtyfied or saved that was previously backed up, it must always
    be reset to the DIRTY state on rubout, so backups are eventually recreated.
  * When a buffer is dirtyfied first (was clean), the backup file must be
    removed on rubout as well - we don't expect backup files for clean buffers.
* There is currently no automatic way to restore backup files.
  This could potentially be done by opener.tes and session.tes in the future,
  although you couldn't currently always get meaningful user feedback
  (whether he wants to restore the file).
  Perhaps we should at least log a message when detecting backup files that
  are newer than the file that is being opened.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The backup mechanism is supposed to guard against crashes of SciTECO and
  unexpected program terminations (e.g. power cycling, etc.)
* In a given interval (no matter whether busy or idlying on the prompt)
  SciTECO saves all modified buffers with the filename~ (like most other editors).
  As an optimization files are not backed up if they have been backed up
  previously to avoid pointless and possibly slow file system writes.
* While the backup mechanism exists outside of the usual undo-paradigm -
  backup file creating is not bound to character input and it makes no sense
  to restore the exact state of backup files - there are some interesting
  interactions:
  * When a buffer is dirtyfied or saved that was previously backed up, it must always
    be reset to the DIRTY state on rubout, so backups are eventually recreated.
  * When a buffer is dirtyfied first (was clean), the backup file must be
    removed on rubout as well - we don't expect backup files for clean buffers.
* There is currently no automatic way to restore backup files.
  This could potentially be done by opener.tes and session.tes in the future,
  although you couldn't currently always get meaningful user feedback
  (whether he wants to restore the file).
  Perhaps we should at least log a message when detecting backup files that
  are newer than the file that is being opened.
</pre>
</div>
</content>
</entry>
<entry>
<title>avoid GNU Make grouped targets and templates to build womanpages</title>
<updated>2025-11-18T19:30:29+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-11-18T19:16:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=03496e976dbb492c4f58db1a82ca6351ea937fc4'/>
<id>03496e976dbb492c4f58db1a82ca6351ea937fc4</id>
<content type='text'>
* grosciteco.tes generates two output files.
  First this was modeled with `%.woman %.woman.tec : ...`, but it creates independant rules
  which could result in superfluous builds and broke parallel builds.
  Then I tried grouped targets (`%.woman %.woman.tec &amp;: ...`) which were supposed to solve the
  problem cleanly. However they turned out to be buggy with pattern rules,
  so I used templates instead.
  Unfortunately grouped targets turned out to be unreliable in general and that broke
  some older platforms, resulting in broken .woman.tec files.
* The same can be achieved by declaring .woman files the main artifact and
  having an empty rule like `%.woman.tec : %.woman;`.
  If anything draws in .woman.tec, it will still execute the rule only once.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* grosciteco.tes generates two output files.
  First this was modeled with `%.woman %.woman.tec : ...`, but it creates independant rules
  which could result in superfluous builds and broke parallel builds.
  Then I tried grouped targets (`%.woman %.woman.tec &amp;: ...`) which were supposed to solve the
  problem cleanly. However they turned out to be buggy with pattern rules,
  so I used templates instead.
  Unfortunately grouped targets turned out to be unreliable in general and that broke
  some older platforms, resulting in broken .woman.tec files.
* The same can be achieved by declaring .woman files the main artifact and
  having an empty rule like `%.woman.tec : %.woman;`.
  If anything draws in .woman.tec, it will still execute the rule only once.
</pre>
</div>
</content>
</entry>
<entry>
<title>updated sciteco(7), README and TODO: mention the configurable command line</title>
<updated>2025-11-09T19:03:41+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-11-09T19:03:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=2662b8e4b17c815a2636125f86a040b6beceb17d'/>
<id>2662b8e4b17c815a2636125f86a040b6beceb17d</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>updated all links to the new "Knowledge Base" and mention mailing lists</title>
<updated>2025-09-28T20:10:32+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-09-28T20:10:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=716e996c5b9a6d3277aca4bea97de4c5339d0aef'/>
<id>716e996c5b9a6d3277aca4bea97de4c5339d0aef</id>
<content type='text'>
* The Knowledge Base replaces the Github wiki.
* The mailing lists replace the Github bug tracker, discussions and pull requests.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The Knowledge Base replaces the Github wiki.
* The mailing lists replace the Github bug tracker, discussions and pull requests.
</pre>
</div>
</content>
</entry>
</feed>
