<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/lib/session.tes, 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>&lt;EI&gt; has been repurposed and is the macro file inclusion (indirect file) command now</title>
<updated>2025-05-24T14:22:52+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-05-24T13:24:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=6e3da17a2fae11af9ae00d9b59bd0d752022e16b'/>
<id>6e3da17a2fae11af9ae00d9b59bd0d752022e16b</id>
<content type='text'>
* Improves DEC TECO-11 compatibility.
* &lt;EM&gt; is still supported as a synonym, but considered deprecated and is no longer documented.
  A warning is printed when invoked.
  It can be repurposed at any time in the future.
* `EI$` is not yet supported.
  I am unsure whether this makes any sense.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Improves DEC TECO-11 compatibility.
* &lt;EM&gt; is still supported as a synonym, but considered deprecated and is no longer documented.
  A warning is printed when invoked.
  It can be repurposed at any time in the future.
* `EI$` is not yet supported.
  I am unsure whether this makes any sense.
</pre>
</div>
</content>
</entry>
<entry>
<title>added tutorial document, which is automatically loaded on the first invocation</title>
<updated>2025-03-31T00:23:06+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-31T00:23:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=6afa02a161493c646e64fb6afca13de7d33fd699'/>
<id>6afa02a161493c646e64fb6afca13de7d33fd699</id>
<content type='text'>
* This is rendered with ms, so we now need the entire groff on Debian.
  This is not a big deal as it just adds a few kilobytes of build-time dependencies.
  Most platforms do not allow installation of some "groff-base" package anyway
  and always draw in the entire package.
* sciteco.tmac has been extended to disable page breaks on ms.
* The tutorial is installed like any other woman page and can be invoked
  interactively with ?tutorial$.
* It is optimized to be still usable on a plain 80x24 terminal.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This is rendered with ms, so we now need the entire groff on Debian.
  This is not a big deal as it just adds a few kilobytes of build-time dependencies.
  Most platforms do not allow installation of some "groff-base" package anyway
  and always draw in the entire package.
* sciteco.tmac has been extended to disable page breaks on ms.
* The tutorial is installed like any other woman page and can be invoked
  interactively with ?tutorial$.
* It is optimized to be still usable on a plain 80x24 terminal.
</pre>
</div>
</content>
</entry>
<entry>
<title>added session.fossil for setting up buffer sessions per Fossil repository</title>
<updated>2024-12-24T14:20:55+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-12-24T14:20:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=38d1f4c93849ab64b72a1bc7516e41d7ae99695d'/>
<id>38d1f4c93849ab64b72a1bc7516e41d7ae99695d</id>
<content type='text'>
* This goes into session.vcs as well.
* `fossil info` does not allow printing only the local-root property, so we have to do
  some parsing afterwards.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This goes into session.vcs as well.
* `fossil info` does not allow printing only the local-root property, so we have to do
  some parsing afterwards.
</pre>
</div>
</content>
</entry>
<entry>
<title>simplified session.svn: no need to mess around with XML</title>
<updated>2024-12-24T14:01:55+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-12-24T14:01:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=be23c9dbf7f7ff833c1801399a28570a87521acf'/>
<id>be23c9dbf7f7ff833c1801399a28570a87521acf</id>
<content type='text'>
* In fact, since SVN has --no-newline, this is even simpler than on Git and Mercurial.
* This requires at least Subversion v1.9 (2015, so should be safe).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* In fact, since SVN has --no-newline, this is even simpler than on Git and Mercurial.
* This requires at least Subversion v1.9 (2015, so should be safe).
</pre>
</div>
</content>
</entry>
<entry>
<title>introduced true block and EOL comments</title>
<updated>2024-12-24T10:29:32+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-12-24T10:29:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ef897b418a4487196e1dbc18a97046f8f0aea2e8'/>
<id>ef897b418a4487196e1dbc18a97046f8f0aea2e8</id>
<content type='text'>
* The previous convention of !* ... *! are now true block comments,
  i.e. they are parsed faster, don't spam the goto table and allow
  embedding of exclamation marks - only "*!" terminates the comment.
* It is therefore now forbidden to have goto labels beginning with "*".
* Also support "!!" to introduce EOL comments (like C++'s //).
  This disallows empty labels, but they weren't useful anyway.
  This is the shortest way to begin a comment.
* All comment labels have been converted to true comments, to ensure
  that syntax highlighting works correctly.
  EOL comments are used for single line commented-out code, since it's
  easiest to uncomment - you don't have to jump to the line end.
  This is a pure convention / coding style.
  Other people might do it differently.
* It's of course still possible to abuse goto labels as comments
  as TECO did for ages.
* In lexing / syntax highlighting, labels and comments are highlighted differently.
* When syntax highlighting, a single "!" will first be highlighted as a label
  since it's not yet unambiguous. Once you type the second character (* or !),
  the first character is retroactively styled as a comment as well.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The previous convention of !* ... *! are now true block comments,
  i.e. they are parsed faster, don't spam the goto table and allow
  embedding of exclamation marks - only "*!" terminates the comment.
* It is therefore now forbidden to have goto labels beginning with "*".
* Also support "!!" to introduce EOL comments (like C++'s //).
  This disallows empty labels, but they weren't useful anyway.
  This is the shortest way to begin a comment.
* All comment labels have been converted to true comments, to ensure
  that syntax highlighting works correctly.
  EOL comments are used for single line commented-out code, since it's
  easiest to uncomment - you don't have to jump to the line end.
  This is a pure convention / coding style.
  Other people might do it differently.
* It's of course still possible to abuse goto labels as comments
  as TECO did for ages.
* In lexing / syntax highlighting, labels and comments are highlighted differently.
* When syntax highlighting, a single "!" will first be highlighted as a label
  since it's not yet unambiguous. Once you type the second character (* or !),
  the first character is retroactively styled as a comment as well.
</pre>
</div>
</content>
</entry>
<entry>
<title>session.tes: store the current tab style (width and hard-tabs); fixed for filenames containing ASCII 27</title>
<updated>2024-11-11T15:33:07+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-11-11T15:33:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=eff72334e1896062de24a4eb60c2d5899bba11cd'/>
<id>eff72334e1896062de24a4eb60c2d5899bba11cd</id>
<content type='text'>
* You can now set a per-file tab style, that differs from the defaults established
  in the ED hook.
  This is important especially since we do not yet support per-project .teco_ini
  scripts where you could establish differing policies depending on the VCS repository.
  (The latter would be easy to implement, but we cannot currently easily extend the
  existing ED hooks.)
* It's unlikely that files contain an ASCII 27, but not impossible.
  Therefore we now use ASCII 0 (^@) as a terminator.
  This indeed be safe under UNIX.
  Even better would be a string building construct for escaping ASCII 27 ($), though,
  as that would work with arbitrary bytes.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* You can now set a per-file tab style, that differs from the defaults established
  in the ED hook.
  This is important especially since we do not yet support per-project .teco_ini
  scripts where you could establish differing policies depending on the VCS repository.
  (The latter would be easy to implement, but we cannot currently easily extend the
  existing ED hooks.)
* It's unlikely that files contain an ASCII 27, but not impossible.
  Therefore we now use ASCII 0 (^@) as a terminator.
  This indeed be safe under UNIX.
  Even better would be a string building construct for escaping ASCII 27 ($), though,
  as that would work with arbitrary bytes.
</pre>
</div>
</content>
</entry>
<entry>
<title>globbing supports character classes now and ^EN string building construct to escape glob patterns</title>
<updated>2016-11-01T06:23:49+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-11-01T05:58:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=9f6cba5c0370aee2f9803abbc35ab7e67f57ee84'/>
<id>9f6cba5c0370aee2f9803abbc35ab7e67f57ee84</id>
<content type='text'>
 * globbing is fnmatch(3) compatible, now on every supported platform.
 * which means that escaping of glob patterns is possible now.
   ^ENq has been introduced to ease this task.
 * This finally allows you to pass unmodified filenames to EB.
   Previously it was impossible to open file names containing glob wildcards.
 * this was achieved by moving from GPattern to GRegex as the underlying
   implementation.
 * The glob pattern is converted to a regular expression before being
   compiled to a GRegex.
   This turned out to be trickier than anticipated (~140 lines of code)
   and has a runtime penalty of course (complexity is O(2*n) over the
   pattern length).
   It is IMHO still better than the alternatives, like importing
   external code from libiberty, which is potentially non-cross-platform.
 * Using GRegex also opens the potential of supporting brace "expansions"
   later in the form of glob pattern constructs
   (they won't actually expand but match alternatives).
 * is_glob_pattern() has been simplified and moved to Globber::is_pattern().
   It makes sense to reuse the Globber class namespace instead of using
   plain functions for functions working on glob patterns.
 * The documentation has a new subsection on glob patterns now.
 * Testsuite extended with glob pattern test cases
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * globbing is fnmatch(3) compatible, now on every supported platform.
 * which means that escaping of glob patterns is possible now.
   ^ENq has been introduced to ease this task.
 * This finally allows you to pass unmodified filenames to EB.
   Previously it was impossible to open file names containing glob wildcards.
 * this was achieved by moving from GPattern to GRegex as the underlying
   implementation.
 * The glob pattern is converted to a regular expression before being
   compiled to a GRegex.
   This turned out to be trickier than anticipated (~140 lines of code)
   and has a runtime penalty of course (complexity is O(2*n) over the
   pattern length).
   It is IMHO still better than the alternatives, like importing
   external code from libiberty, which is potentially non-cross-platform.
 * Using GRegex also opens the potential of supporting brace "expansions"
   later in the form of glob pattern constructs
   (they won't actually expand but match alternatives).
 * is_glob_pattern() has been simplified and moved to Globber::is_pattern().
   It makes sense to reuse the Globber class namespace instead of using
   plain functions for functions working on glob patterns.
 * The documentation has a new subsection on glob patterns now.
 * Testsuite extended with glob pattern test cases
</pre>
</div>
</content>
</entry>
<entry>
<title>session.tes: save and restore the working directory as part of the session</title>
<updated>2016-04-05T15:34:53+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-04-05T15:05:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=9e97b5820975cb44775f62805dc6366d7eec3411'/>
<id>9e97b5820975cb44775f62805dc6366d7eec3411</id>
<content type='text'>
 * turned out to be a very handy feature
 * can be turned off by setting register `session.savedir` to false
 * also fixed the line endings in .teco_session files to line-feed (ie. native)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * turned out to be a very handy feature
 * can be turned off by setting register `session.savedir` to false
 * also fixed the line endings in .teco_session files to line-feed (ie. native)
</pre>
</div>
</content>
</entry>
<entry>
<title>implemented &lt;$$&gt; command for returning from a macro</title>
<updated>2016-02-15T14:00:55+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-02-13T17:43:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=f08187e454f56954b41d95615ca2e370ba19667e'/>
<id>f08187e454f56954b41d95615ca2e370ba19667e</id>
<content type='text'>
 * &lt;$$&gt; is faster than jumping to the end of the macro
   and enables shorter code for returning values from macros.
 * this also replaces $$ as an immediate editing command.
   In other words, command line termination is an ordinary command
   now. The old behaviour was similar to what classic TECO did.
   Classic TECO however had no choice than to track key presses
   directly for command line termination as it did not keep track
   about the parser state as input was typed.
   This led to some glitches in the language. For instance
   "FS$$" would terminate the command line, unless the second escape
   was typed after backspace, etc. This behaviour is not worth copying
   and SciTECO did a better job than that by making sure that at least the
   second escape is only effective if it is not part of language syntax.
   This still lead to some undesirable cases like "ES...$$$" that would
   terminate the command line unexpectedly.
   To terminate the command line after something like "FS$$", you will
   now have to type "FS$$$$".
 * As it is a regular command now - just executed immediately - and
   its properties stay close to the macro return behaviour, command line
   termination may now not always be performed when $$ is typed even
   as a standalone command. E.g. "Ofoo$ !bar!$$ !foo!Obar$" will
   curiously terminate the command line now.
 * This also means that macros can finally terminate command lines
   by using the command line editing commands ({ and }) to insert
   $$ into the command line macro.
   This is also of interest for function key macros.
 * This implementation showed some serious shortcoming in SciTECO's
   current parser that yet have to be fixed.
   E.g. the macro "@^Ua{&lt;$$&gt;}" is currently unsafe since
   loops abuse the expression stack for storing their state and $$
   does not touch the expression stack. Calling "Ma&gt;" would actually
   continue the loop jumping to the beginning of the command line
   since program counters referring to the macro A will be reused!
   This cannot be easily solved by checking for loop termination
   since being able to return that way from loops is a useful
   feature. This is a problem even without loops and $$, e.g. as
   in "@^Ua{1,2,3(4,5} Ma)".
   Instead, a kind of expression stack frame pointer must be
   added to macro invocation stack frames, pointing to the beginning
   of the expression stack for the current frame.
   At the end of macros or on return, the stack contents of
   corresponding to the frame can be discarded while preserving the
   immediate arguments at the time of the return or end-of-macro.
   This would stabilize SciTECO's macro semantics.
 * When a top-level macro returns in batch mode, it would
   be a good idea to use the last argument to calculate the
   process return code, so it can be set by SciTECO scripts (TODO).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * &lt;$$&gt; is faster than jumping to the end of the macro
   and enables shorter code for returning values from macros.
 * this also replaces $$ as an immediate editing command.
   In other words, command line termination is an ordinary command
   now. The old behaviour was similar to what classic TECO did.
   Classic TECO however had no choice than to track key presses
   directly for command line termination as it did not keep track
   about the parser state as input was typed.
   This led to some glitches in the language. For instance
   "FS$$" would terminate the command line, unless the second escape
   was typed after backspace, etc. This behaviour is not worth copying
   and SciTECO did a better job than that by making sure that at least the
   second escape is only effective if it is not part of language syntax.
   This still lead to some undesirable cases like "ES...$$$" that would
   terminate the command line unexpectedly.
   To terminate the command line after something like "FS$$", you will
   now have to type "FS$$$$".
 * As it is a regular command now - just executed immediately - and
   its properties stay close to the macro return behaviour, command line
   termination may now not always be performed when $$ is typed even
   as a standalone command. E.g. "Ofoo$ !bar!$$ !foo!Obar$" will
   curiously terminate the command line now.
 * This also means that macros can finally terminate command lines
   by using the command line editing commands ({ and }) to insert
   $$ into the command line macro.
   This is also of interest for function key macros.
 * This implementation showed some serious shortcoming in SciTECO's
   current parser that yet have to be fixed.
   E.g. the macro "@^Ua{&lt;$$&gt;}" is currently unsafe since
   loops abuse the expression stack for storing their state and $$
   does not touch the expression stack. Calling "Ma&gt;" would actually
   continue the loop jumping to the beginning of the command line
   since program counters referring to the macro A will be reused!
   This cannot be easily solved by checking for loop termination
   since being able to return that way from loops is a useful
   feature. This is a problem even without loops and $$, e.g. as
   in "@^Ua{1,2,3(4,5} Ma)".
   Instead, a kind of expression stack frame pointer must be
   added to macro invocation stack frames, pointing to the beginning
   of the expression stack for the current frame.
   At the end of macros or on return, the stack contents of
   corresponding to the frame can be discarded while preserving the
   immediate arguments at the time of the return or end-of-macro.
   This would stabilize SciTECO's macro semantics.
 * When a top-level macro returns in batch mode, it would
   be a good idea to use the last argument to calculate the
   process return code, so it can be set by SciTECO scripts (TODO).
</pre>
</div>
</content>
</entry>
<entry>
<title>&lt;:Q&gt; returns -1 for non-existent registers now</title>
<updated>2015-06-29T15:10:03+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2015-06-29T14:46:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=95ebb1c7d7969fa642192ce8e6c9efa8249979d9'/>
<id>95ebb1c7d7969fa642192ce8e6c9efa8249979d9</id>
<content type='text'>
 * added a new OPTIONAL behaviour for QRegSpecMachines
 * allows you to implement commands that have an optional Q-Register
   argument that should not be initialized if undefined.
 * Using QRegSpecMachine::fail() you may still check for existence of
   the register conditionally to emulate the QREG_REQUIRED behaviour.
 * Using :Q for checking for register existence makes sense, because
   usually you will want to check for both existence and non-emptyness
   as in :Qq"&gt;. So in this common case, you no longer have to
   keep in mind that the register may also be undefined.
 * This finally allows us to create arrays in the Q-Register
   tables without keeping a separate entry for the number of elements.
   E.g. an array.0 to array.N can be iterated like this:
   0Ui &lt;:Q[array.^E\i]:; ! work with element i ! %i&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * added a new OPTIONAL behaviour for QRegSpecMachines
 * allows you to implement commands that have an optional Q-Register
   argument that should not be initialized if undefined.
 * Using QRegSpecMachine::fail() you may still check for existence of
   the register conditionally to emulate the QREG_REQUIRED behaviour.
 * Using :Q for checking for register existence makes sense, because
   usually you will want to check for both existence and non-emptyness
   as in :Qq"&gt;. So in this common case, you no longer have to
   keep in mind that the register may also be undefined.
 * This finally allows us to create arrays in the Q-Register
   tables without keeping a separate entry for the number of elements.
   E.g. an array.0 to array.N can be iterated like this:
   0Ui &lt;:Q[array.^E\i]:; ! work with element i ! %i&gt;
</pre>
</div>
</content>
</entry>
</feed>
