<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/sample.teco_ini, branch v2.0.0</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>.teco_ini: don't set up any margins or indention settings on the unnamed buffer</title>
<updated>2023-06-18T17:05:30+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2023-06-18T17:05:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=b65c64a200dac8194dacc90ae2150b683f64cd8a'/>
<id>b65c64a200dac8194dacc90ae2150b683f64cd8a</id>
<content type='text'>
* The lexer.test.* macros don't work on the unnamed buffer,
  so any per-language indention settings etc. could be accidentally
  applied to the unnamed buffer.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The lexer.test.* macros don't work on the unnamed buffer,
  so any per-language indention settings etc. could be accidentally
  applied to the unnamed buffer.
</pre>
</div>
</content>
</entry>
<entry>
<title>0,8ED: Automatic case-folding of commands</title>
<updated>2017-03-25T05:57:17+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2017-03-25T05:47:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=90baf34034af9363ee4cfa1654a8cc72dfc8c62e'/>
<id>90baf34034af9363ee4cfa1654a8cc72dfc8c62e</id>
<content type='text'>
 * when enabled, it will automatically upper-case all
   one or two letter commands (which are case insensitive).
 * also affects the up-carret control commands, so they when inserted
   they look more like real control commands.
 * specifically does not affect case-insensitive Q-Register specifications
 * the result are command lines that are better readable and conform
   to the coding style used in SciTECO's standard library.
   This eases reusing command lines as well.
 * Consequently, string-building and pattern match characters should
   be case-folded as well, but they aren't currently since
   State::process_edit_cmd() does not have sufficient insight
   into the MicroStateMachines. Also, it could not be delegated
   to the MicroStateMachines.
   Perhaps they should be abandoned in favour of embeddedable
   regular state machines; or regular state machines with a stack
   of return states?
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * when enabled, it will automatically upper-case all
   one or two letter commands (which are case insensitive).
 * also affects the up-carret control commands, so they when inserted
   they look more like real control commands.
 * specifically does not affect case-insensitive Q-Register specifications
 * the result are command lines that are better readable and conform
   to the coding style used in SciTECO's standard library.
   This eases reusing command lines as well.
 * Consequently, string-building and pattern match characters should
   be case-folded as well, but they aren't currently since
   State::process_edit_cmd() does not have sufficient insight
   into the MicroStateMachines. Also, it could not be delegated
   to the MicroStateMachines.
   Perhaps they should be abandoned in favour of embeddedable
   regular state machines; or regular state machines with a stack
   of return states?
</pre>
</div>
</content>
</entry>
<entry>
<title>updated sample.teco_ini: 2EJ now sets a more or less global memory limit</title>
<updated>2016-11-20T17:33:17+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-11-20T17:33:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=bece75c1b7d2e67cda9850ca42a9cd8011658d21'/>
<id>bece75c1b7d2e67cda9850ca42a9cd8011658d21</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>implemented self-documenting (online) help system</title>
<updated>2016-11-18T06:05:52+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-02-26T01:02:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e7867fb0d9979c550e6e3d7597ece73b680c4af6'/>
<id>e7867fb0d9979c550e6e3d7597ece73b680c4af6</id>
<content type='text'>
 * the new "?" (help) command can be used to look up
   help topics.
 * help topics are index from $SCITECOPATH/women/*.woman.tec
   files.
 * looking up a help topic opens the corresponding "womanpage"
   and jumps to the position of the topic (it acts like an anchor
   into the document).
 * styling is performed by *.woman.tec files.
 * Setting up the Scintilla view and munging the *.tec file
   is performed by the new "woman.tes" lexer.
   On supporting UIs (Gtk), womanpages are shown in a variable-width
   font.
 * Woman pages are usually not hand-written, but generated from manpages.
   A special Groff post-processor grosciteco has been introduced for this
   purpose. It is much like grotty, but can output SciTECO macros for styling
   the document (ie. the *.woman.tec files).
   It is documented in its own man-page.
 * grosciteco also introduces sciteco.tmac - special Troff macros
   for controlling the formatting of the document in SciTECO.
   It also defines .SCITECO_TOPIC which can be used to mark up
   help topics/terms in Troff markup.
 * Woman pages are generated/formatted by grosciteco at compile-time, so
   they will work on platforms without Groff (ie. as on windows).
 * Groff has been added as a hard compile-time requirement.
 * The sciteco(1) and sciteco(7) man pages have been augmented with
   help topic anchors.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * the new "?" (help) command can be used to look up
   help topics.
 * help topics are index from $SCITECOPATH/women/*.woman.tec
   files.
 * looking up a help topic opens the corresponding "womanpage"
   and jumps to the position of the topic (it acts like an anchor
   into the document).
 * styling is performed by *.woman.tec files.
 * Setting up the Scintilla view and munging the *.tec file
   is performed by the new "woman.tes" lexer.
   On supporting UIs (Gtk), womanpages are shown in a variable-width
   font.
 * Woman pages are usually not hand-written, but generated from manpages.
   A special Groff post-processor grosciteco has been introduced for this
   purpose. It is much like grotty, but can output SciTECO macros for styling
   the document (ie. the *.woman.tec files).
   It is documented in its own man-page.
 * grosciteco also introduces sciteco.tmac - special Troff macros
   for controlling the formatting of the document in SciTECO.
   It also defines .SCITECO_TOPIC which can be used to mark up
   help topics/terms in Troff markup.
 * Woman pages are generated/formatted by grosciteco at compile-time, so
   they will work on platforms without Groff (ie. as on windows).
 * Groff has been added as a hard compile-time requirement.
 * The sciteco(1) and sciteco(7) man pages have been augmented with
   help topic anchors.
</pre>
</div>
</content>
</entry>
<entry>
<title>Integrated clipboard support</title>
<updated>2016-08-19T01:29:11+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-08-16T03:04:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=61ff6e97c57f62ee3ad4ffc2166e433bc060e7cb'/>
<id>61ff6e97c57f62ee3ad4ffc2166e433bc060e7cb</id>
<content type='text'>
 * mapped to different registers beginning with "~"
 * on supported platforms accessing the clipboard is as easy as
   X~ or G~.
   Naturally this also allows clipboards to be pasted in
   string arguments/insertions (^EQ~).
 * Currently, Gtk+, PDCurses and ncurses/XTerm are supported.
   For XTerm clipboard support, users must set 0,256ED to enable
   it since we cannot check for XTerm window ops programmatically
   (at least without libX11).
 * When clipboard regs exist, the clipboard can also be deemed functional.
   This allows macros to fall back to xclip(1) if necessary.
 * EOL handling has been moved into a new file eol.c and eol.h.
   EOL translation no longer depends on GIOChannels but can be
   memory-backed as well.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * mapped to different registers beginning with "~"
 * on supported platforms accessing the clipboard is as easy as
   X~ or G~.
   Naturally this also allows clipboards to be pasted in
   string arguments/insertions (^EQ~).
 * Currently, Gtk+, PDCurses and ncurses/XTerm are supported.
   For XTerm clipboard support, users must set 0,256ED to enable
   it since we cannot check for XTerm window ops programmatically
   (at least without libX11).
 * When clipboard regs exist, the clipboard can also be deemed functional.
   This allows macros to fall back to xclip(1) if necessary.
 * EOL handling has been moved into a new file eol.c and eol.h.
   EOL translation no longer depends on GIOChannels but can be
   memory-backed as well.
</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>Gtk UI: automatically configure font of the command line</title>
<updated>2016-02-03T14:31:56+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-02-03T14:20:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=a1fa7643092ba2e1ee2cbe38392fba3d15c6718d'/>
<id>a1fa7643092ba2e1ee2cbe38392fba3d15c6718d</id>
<content type='text'>
 * This uses the font and size of STYLE_DEFAULT.
 * We cannot just pass the font down to the user CSS.
   There are no font variables in Gtk CSS.
   Therefore we configure the command line widget directly.
   This can still be overwritten by an user CSS.
 * Instead of using the deprecated gtk_widget_modify_font(),
   we generate CSS. Ugly, but still better than writing our
   own style provider.
 * Font setting is exposed to the user using a new optional
   Q-Reg "lexer.font". The numeric part is the point size
   multiplied with 100 (fractional point size).
   * Font setting in lexer.auto is skipped in Curses
     where it is irrelevant anyway to speed up startup.
 * Perhaps the "Monospace" font name is also a good default
   value instead of Courier?

fixup
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * This uses the font and size of STYLE_DEFAULT.
 * We cannot just pass the font down to the user CSS.
   There are no font variables in Gtk CSS.
   Therefore we configure the command line widget directly.
   This can still be overwritten by an user CSS.
 * Instead of using the deprecated gtk_widget_modify_font(),
   we generate CSS. Ugly, but still better than writing our
   own style provider.
 * Font setting is exposed to the user using a new optional
   Q-Reg "lexer.font". The numeric part is the point size
   multiplied with 100 (fractional point size).
   * Font setting in lexer.auto is skipped in Curses
     where it is irrelevant anyway to speed up startup.
 * Perhaps the "Monospace" font name is also a good default
   value instead of Courier?

fixup
</pre>
</div>
</content>
</entry>
<entry>
<title>enable function key macros automatically when sourcing fnkeys.tes</title>
<updated>2015-06-27T14:29:13+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2015-06-27T14:29:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=859a831ab061d3d906351fe213e1f7ac80ac10cb'/>
<id>859a831ab061d3d906351fe213e1f7ac80ac10cb</id>
<content type='text'>
 * this simplifies profile setup
 * should anybody wish to load the default function key macros but
   not enable function key support, he/she can still explicitly call
   "64,0ED" to disable them again.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * this simplifies profile setup
 * should anybody wish to load the default function key macros but
   not enable function key support, he/she can still explicitly call
   "64,0ED" to disable them again.
</pre>
</div>
</content>
</entry>
<entry>
<title>disable all Scintilla margins by default</title>
<updated>2015-06-24T13:53:28+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2015-06-24T13:53:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=007cfe736327ea8775fa6bf6bd49257132cf45f2'/>
<id>007cfe736327ea8775fa6bf6bd49257132cf45f2</id>
<content type='text'>
 * it makes little sense to keep Scintilla's default for new views
   which gives margin 1 (non-folding symbols) a fixed width of 16 pixels.
   The interpretation of this width is UI-dependant.
 * it is more consistent to disable all margins initially.
   this is also the minimalist setup shown when you run e.g. with --no-profile.
 * the default look of SciTECO will be more like classic TECOs.
   This is also what has been requested in #4.
 * sample.teco_ini does no longer have to disable margin 1 explicitly
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * it makes little sense to keep Scintilla's default for new views
   which gives margin 1 (non-folding symbols) a fixed width of 16 pixels.
   The interpretation of this width is UI-dependant.
 * it is more consistent to disable all margins initially.
   this is also the minimalist setup shown when you run e.g. with --no-profile.
 * the default look of SciTECO will be more like classic TECOs.
   This is also what has been requested in #4.
 * sample.teco_ini does no longer have to disable margin 1 explicitly
</pre>
</div>
</content>
</entry>
<entry>
<title>sample.teco_ini: avoid unnecessary ED-hook recursions</title>
<updated>2015-06-22T02:11:23+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2015-06-20T13:51:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ca6043bd631091661211d1e332d33219f967a043'/>
<id>ca6043bd631091661211d1e332d33219f967a043</id>
<content type='text'>
 * disable ED hook while exuting the "add" hook.
   This avoids the "edit" hook being invoked recursively.
 * the speed improvement was not measurable, but it also won't
   hurt
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * disable ED hook while exuting the "add" hook.
   This avoids the "edit" hook being invoked recursively.
 * the speed improvement was not measurable, but it also won't
   hurt
</pre>
</div>
</content>
</entry>
</feed>
