<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/doc/sciteco.1.in, 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>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>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>moved most resources to fmsbw.de</title>
<updated>2025-09-21T14:30:15+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2025-09-21T09:37:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=c08ce4b183726c9f0eeeb5a40e04e7306c7f5e4e'/>
<id>c08ce4b183726c9f0eeeb5a40e04e7306c7f5e4e</id>
<content type='text'>
* The new official homepage is https://sciteco.fmsbw.de/
* My new contact address is rhaberkorn AT fmsbw.de.
* The scintilla-mirror is now also on https://git.fmsbw.de/scintilla-mirror/
* Added CI script for my server on fmsbw.de that builds
  the website.
  It's run in a FreeBSD container, but does not currently
  distribute FreeBSD binaries.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The new official homepage is https://sciteco.fmsbw.de/
* My new contact address is rhaberkorn AT fmsbw.de.
* The scintilla-mirror is now also on https://git.fmsbw.de/scintilla-mirror/
* Added CI script for my server on fmsbw.de that builds
  the website.
  It's run in a FreeBSD container, but does not currently
  distribute FreeBSD binaries.
</pre>
</div>
</content>
</entry>
<entry>
<title>command-line arguments are no longer passed via the unnamed buffer, but via special Q-registers ^Ax</title>
<updated>2025-08-06T13:46:37+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-08-06T13:46:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=280cb9da39fc7b5357f6071926d511394f6d0152'/>
<id>280cb9da39fc7b5357f6071926d511394f6d0152</id>
<content type='text'>
* The unnamed buffer is also used for reading from --stdin, so you couldn't practically combine
  --stdin with passing command-line arguments to macros.
* The old approach of passing command-line arguments via lines in the
  unnamed buffer was flawed anyway as it wouldn't work with filenames containing LF.
  This is just a very ancient feature, written when there weren't even long Q-reg names in SciTECO.
* You can now e.g. pipe into SciTECO and edit what was read interactively, e.g. `dmesg | sciteco -i`.
  You can practically use SciTECO as a pager.
* htbl.tes is now a command-line filter (uses -qio).
* grosciteco.tes reads Troff intermediate code from stdin, so we no longer need
  "*.intermediate" temporary files.
* added a getopt.tes test case to the testsuite.
* This change unfortunately breaks most macros accepting command-line arguments,
  even if they used getopt.tes.
  It also requires updating ~/.teco_ini - see fallback.teco_ini.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The unnamed buffer is also used for reading from --stdin, so you couldn't practically combine
  --stdin with passing command-line arguments to macros.
* The old approach of passing command-line arguments via lines in the
  unnamed buffer was flawed anyway as it wouldn't work with filenames containing LF.
  This is just a very ancient feature, written when there weren't even long Q-reg names in SciTECO.
* You can now e.g. pipe into SciTECO and edit what was read interactively, e.g. `dmesg | sciteco -i`.
  You can practically use SciTECO as a pager.
* htbl.tes is now a command-line filter (uses -qio).
* grosciteco.tes reads Troff intermediate code from stdin, so we no longer need
  "*.intermediate" temporary files.
* added a getopt.tes test case to the testsuite.
* This change unfortunately breaks most macros accepting command-line arguments,
  even if they used getopt.tes.
  It also requires updating ~/.teco_ini - see fallback.teco_ini.
</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>
<entry>
<title>added -v/--version and &lt;EO&gt; command</title>
<updated>2025-07-31T14:19:07+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-31T14:19:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ca70c9061146386ce0986631cd7fc9209a935a34'/>
<id>ca70c9061146386ce0986631cd7fc9209a935a34</id>
<content type='text'>
* DEC TECO had an &lt;EO&gt; command.
  In contrast to DEC TECO's implementation, the value reported by
  &lt;EO&gt; encodes a major.minor.micro semantic version.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* DEC TECO had an &lt;EO&gt; command.
  In contrast to DEC TECO's implementation, the value reported by
  &lt;EO&gt; encodes a major.minor.micro semantic version.
</pre>
</div>
</content>
</entry>
<entry>
<title>implemented &lt;:Gq&gt; for printing the Q-Register string as a message instead of inserting it</title>
<updated>2025-07-25T21:42:15+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-25T11:12:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=24c3bfc4f18f06a465b70afa45783d568402abdf'/>
<id>24c3bfc4f18f06a465b70afa45783d568402abdf</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>support &lt;==&gt; and &lt;===&gt; for printing octal and hexadecimal numbers</title>
<updated>2025-07-20T21:33:13+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-20T21:19:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=48dcfd22f9c2db5cf6745eaec0ff28895858c638'/>
<id>48dcfd22f9c2db5cf6745eaec0ff28895858c638</id>
<content type='text'>
* These are famously in DEC TECO-11, but also in Video TECO.
* The implementation is tricky. They need to use lookahead states,
  but this would be inacceptable during interactive execution.
  Therefore only if executing from the end of the command line
  `==` and `===` are allowed to print multiple values.
  The number is therefore also not popped form the stack immediately
  but only peeked. It's popped only when it has been decided that
  the command has ended.
* This may break existing macros that use multiple `=` in a row
  to print multiple values from the stack.
  You will now e.g. have to insert whitespace to separate such `=` commands.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* These are famously in DEC TECO-11, but also in Video TECO.
* The implementation is tricky. They need to use lookahead states,
  but this would be inacceptable during interactive execution.
  Therefore only if executing from the end of the command line
  `==` and `===` are allowed to print multiple values.
  The number is therefore also not popped form the stack immediately
  but only peeked. It's popped only when it has been decided that
  the command has ended.
* This may break existing macros that use multiple `=` in a row
  to print multiple values from the stack.
  You will now e.g. have to insert whitespace to separate such `=` commands.
</pre>
</div>
</content>
</entry>
<entry>
<title>allow process exit status to be determined by macros</title>
<updated>2025-05-18T15:23:25+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-05-18T15:23:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=fe3535dbeec8f3f0fca9e6b895c993e59846e103'/>
<id>fe3535dbeec8f3f0fca9e6b895c993e59846e103</id>
<content type='text'>
* Any value left on the numeric stack now determines the exit code.
  This ensures you can call n^C as the SciTECO version of exit(n).
  It will also work with n$$ in the top level macro.
  But you don't necessarily need any of these commands.
* Could be useful in shell scripting as in
  `sciteco -e "@EB/file/ :@S/foo/\"F1'"` to fail `foo` is not found.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Any value left on the numeric stack now determines the exit code.
  This ensures you can call n^C as the SciTECO version of exit(n).
  It will also work with n$$ in the top level macro.
  But you don't necessarily need any of these commands.
* Could be useful in shell scripting as in
  `sciteco -e "@EB/file/ :@S/foo/\"F1'"` to fail `foo` is not found.
</pre>
</div>
</content>
</entry>
</feed>
