<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/sample.teco_ini, branch v2.3.0</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<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>allow OSC-52 clipboards on all terminal emulators</title>
<updated>2024-09-23T09:45:25+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-23T09:35:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=c2887621a37f429e2e05b561631fff01da8bd462'/>
<id>c2887621a37f429e2e05b561631fff01da8bd462</id>
<content type='text'>
* The XTerm version is still checked if we detect running under XTerm.
* Actually, the XTerm implementation is broken for Unicode clipboard contents.
* Kitty supports OSC-52, but you __must__ enable read-clipboard.
  With read-clipboard-ask, there will be a timeout.
  But we cannot read without a timeout since otherwise we would hang indefinitely
  if the escape sequence turns out to not work.
* For urxvt, I have hacked an existing extension:
  https://gist.github.com/rhaberkorn/d7406420b69841ebbcab97548e38b37d
* st currently supports only setting the clipboard, but not querying it.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The XTerm version is still checked if we detect running under XTerm.
* Actually, the XTerm implementation is broken for Unicode clipboard contents.
* Kitty supports OSC-52, but you __must__ enable read-clipboard.
  With read-clipboard-ask, there will be a timeout.
  But we cannot read without a timeout since otherwise we would hang indefinitely
  if the escape sequence turns out to not work.
* For urxvt, I have hacked an existing extension:
  https://gist.github.com/rhaberkorn/d7406420b69841ebbcab97548e38b37d
* st currently supports only setting the clipboard, but not querying it.
</pre>
</div>
</content>
</entry>
<entry>
<title>Curses: added support for cool Unicode icons (refs #5)</title>
<updated>2024-09-16T20:30:35+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-16T20:30:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=8744502cbe42c98422a798c06f4c8ce033725412'/>
<id>8744502cbe42c98422a798c06f4c8ce033725412</id>
<content type='text'>
* Practically requires one of the "Nerd Font" fonts,
  so it's disabled by default.
  Add 0,512ED to the profile to enable them.
* The new ED flag could be used to control Gtk icons as well,
  but they are left always-enabled for the time being.
  Is there any reason anybody would like to disable icons in Gtk?
* The list of icons has been adapted and extended from exa:
  https://github.com/ogham/exa/blob/master/src/output/icons.rs
* The icons are hardcoded as presorted lists,
  so we can binary search them.
  This could change in the future. If there is any demand,
  they could be made configurable via Q-Registers as well.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Practically requires one of the "Nerd Font" fonts,
  so it's disabled by default.
  Add 0,512ED to the profile to enable them.
* The new ED flag could be used to control Gtk icons as well,
  but they are left always-enabled for the time being.
  Is there any reason anybody would like to disable icons in Gtk?
* The list of icons has been adapted and extended from exa:
  https://github.com/ogham/exa/blob/master/src/output/icons.rs
* The icons are hardcoded as presorted lists,
  so we can binary search them.
  This could change in the future. If there is any demand,
  they could be made configurable via Q-Registers as well.
</pre>
</div>
</content>
</entry>
<entry>
<title>function key macros have been reworked into a more generic key macro feature</title>
<updated>2024-09-12T14:44:13+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-12T11:55:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=abb5d23eba21a2aafda0346c0c5dd845561b2aa2'/>
<id>abb5d23eba21a2aafda0346c0c5dd845561b2aa2</id>
<content type='text'>
* ALL keypresses (the UTF-8 sequences resulting from key presses) can now be remapped.
* This is especially useful with Unicode support, as you might want to alias
  international characters to their corresponding latin form in the start state,
  so you don't have to change keyboard layouts so often.
  This is done automatically in Gtk, where we have hardware key press information,
  but has to be done with key macros in Curses.
  There is a new key mask 4 (bit 3) for that purpose now.
* Also, you might want to define non-ANSI letters to perform special functions in
  the start state where it won't be accepted by the parser anyway.
  Suppose you have a macro M→, you could define
  @^U[^K→]{m→} 1^_U[^K→]
  This effectively "extends" the parser and allow you to call macro "→" by a single
  key press. See also #5.
* The register prefix has been changed from ^F (for function) to ^K (for key).
  This is the only thing you have to change in order to migrate existing
  function key macros.
* Key macros are enabled by default. There is no longer any way to disable
  function key handling in curses, as I never found any reason or need to disable it.
  Theoretically, the default ESCDELAY could turn out to be too small and function
  keys don't get through. I doubt that's possible unless on extremely slow serial lines.
  Even then, you'd have to increase ESCDELAY and instead of disabling function keys
  simply define an escape surrogate.
* The ED flag has been removed and its place is reserved for a future mouse support flag
  (which does make sense to disable in curses sometimes).
  fnkeys.tes is consequently also enabled by default in sample.teco_ini.
* Key macros are handled as an unit. If one character results in an error,
  the entire string is rubbed out.
  This fixes the "CLOSE" key on Gtk.
  It also makes sure that the original error message is preserved and not overwritten
  by some subsequent syntax error.
  It was never useful that we kept inserting characters after the first error.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* ALL keypresses (the UTF-8 sequences resulting from key presses) can now be remapped.
* This is especially useful with Unicode support, as you might want to alias
  international characters to their corresponding latin form in the start state,
  so you don't have to change keyboard layouts so often.
  This is done automatically in Gtk, where we have hardware key press information,
  but has to be done with key macros in Curses.
  There is a new key mask 4 (bit 3) for that purpose now.
* Also, you might want to define non-ANSI letters to perform special functions in
  the start state where it won't be accepted by the parser anyway.
  Suppose you have a macro M→, you could define
  @^U[^K→]{m→} 1^_U[^K→]
  This effectively "extends" the parser and allow you to call macro "→" by a single
  key press. See also #5.
* The register prefix has been changed from ^F (for function) to ^K (for key).
  This is the only thing you have to change in order to migrate existing
  function key macros.
* Key macros are enabled by default. There is no longer any way to disable
  function key handling in curses, as I never found any reason or need to disable it.
  Theoretically, the default ESCDELAY could turn out to be too small and function
  keys don't get through. I doubt that's possible unless on extremely slow serial lines.
  Even then, you'd have to increase ESCDELAY and instead of disabling function keys
  simply define an escape surrogate.
* The ED flag has been removed and its place is reserved for a future mouse support flag
  (which does make sense to disable in curses sometimes).
  fnkeys.tes is consequently also enabled by default in sample.teco_ini.
* Key macros are handled as an unit. If one character results in an error,
  the entire string is rubbed out.
  This fixes the "CLOSE" key on Gtk.
  It also makes sure that the original error message is preserved and not overwritten
  by some subsequent syntax error.
  It was never useful that we kept inserting characters after the first error.
</pre>
</div>
</content>
</entry>
<entry>
<title>sample.teco_ini: fixed opening files with glob characters in their names</title>
<updated>2024-09-09T17:24:18+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-06T18:34:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=dd36439cc88315c53ba8beeca751ac4e7cd40e11'/>
<id>dd36439cc88315c53ba8beeca751ac4e7cd40e11</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>added raw ANSI mode to facilitate 8-bit clean editing (refs #5)</title>
<updated>2024-09-09T16:22:21+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-09T14:54:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=4f231871a0208ec9bcc2679fce25d3b9795d1597'/>
<id>4f231871a0208ec9bcc2679fce25d3b9795d1597</id>
<content type='text'>
* When enabled with bit 2 in the ED flags (0,4ED),
  all registers and buffers will get the raw ANSI encoding (as if 0EE had been
  called on them).
  You can still manually change the encoding, eg. by calling 65001EE afterwards.
* Also the ANSI mode sets up character representations for all bytes &gt;= 0x80.
  This is currently done only depending on the ED flag, not when setting 0EE.
* Since setting 16,4ED for 8-bit clean editing in a macro can be tricky -
  the default unnamed buffer will still be at UTF-8 and at least a bunch
  of environment registers as well - we added the command line option
  `--8bit` (short `-8`) which configures the ED flags very early on.
  As another advantage you can mung the profile in 8-bit mode as well
  when using SciTECO as a sort of interactive hex editor.
* Disable UTF-8 checks in 8-bit clean mode (sample.teco_ini).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* When enabled with bit 2 in the ED flags (0,4ED),
  all registers and buffers will get the raw ANSI encoding (as if 0EE had been
  called on them).
  You can still manually change the encoding, eg. by calling 65001EE afterwards.
* Also the ANSI mode sets up character representations for all bytes &gt;= 0x80.
  This is currently done only depending on the ED flag, not when setting 0EE.
* Since setting 16,4ED for 8-bit clean editing in a macro can be tricky -
  the default unnamed buffer will still be at UTF-8 and at least a bunch
  of environment registers as well - we added the command line option
  `--8bit` (short `-8`) which configures the ED flags very early on.
  As another advantage you can mung the profile in 8-bit mode as well
  when using SciTECO as a sort of interactive hex editor.
* Disable UTF-8 checks in 8-bit clean mode (sample.teco_ini).
</pre>
</div>
</content>
</entry>
<entry>
<title>Codepage guessing is done in .teco_ini (refs #5)</title>
<updated>2024-09-09T16:22:21+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-08-30T23:23:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=b729ee46ebf139399f695c2443cc5a6fdbcbdbe2'/>
<id>b729ee46ebf139399f695c2443cc5a6fdbcbdbe2</id>
<content type='text'>
* There isn't much we can do anyway.
  We can detect if it's Unicode and otherwise default to _some_ codepage.
  However, we do not even known which codepage should be preferred.
* This is actually trivial to implement in pure SciTECO.
  Having it in the profile gives you the ability to customize the default non-UTF code page.
  E.g. if you are working a lot with KOI-8 documents, you could change &lt;1EE&gt; to &lt;204EE&gt;.
* Since the Unicode validity check is a noticable slowdown,
  we limit it to the first 1024 bytes.
  This speeds up startup significantly compared to checking all codepoints in every document.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* There isn't much we can do anyway.
  We can detect if it's Unicode and otherwise default to _some_ codepage.
  However, we do not even known which codepage should be preferred.
* This is actually trivial to implement in pure SciTECO.
  Having it in the profile gives you the ability to customize the default non-UTF code page.
  E.g. if you are working a lot with KOI-8 documents, you could change &lt;1EE&gt; to &lt;204EE&gt;.
* Since the Unicode validity check is a noticable slowdown,
  we limit it to the first 1024 bytes.
  This speeds up startup significantly compared to checking all codepoints in every document.
</pre>
</div>
</content>
</entry>
<entry>
<title>implemented &lt;EE&gt; and &lt;^E&gt; commands for configuring encodings and translating between glyph and byte offsets (refs #5)</title>
<updated>2024-09-09T16:22:21+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-08-30T14:15:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e384e4fde604564a3bc140b89bb8c1556a726464'/>
<id>e384e4fde604564a3bc140b89bb8c1556a726464</id>
<content type='text'>
* ^E is heavily overloaded and can also be used to check whether a given index is valid
  (as it is the same that most movement commands to internally).
  Besides that, it is mainly useful for interfacing with Scintilla messages.
* EE takes a code page or 0 for ANSI/ASCII.
  Currently all documents and new registers are UTF-8.
  There will have to be some kind of codepage inheritance and a single-byte-only mode.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* ^E is heavily overloaded and can also be used to check whether a given index is valid
  (as it is the same that most movement commands to internally).
  Besides that, it is mainly useful for interfacing with Scintilla messages.
* EE takes a code page or 0 for ANSI/ASCII.
  Currently all documents and new registers are UTF-8.
  There will have to be some kind of codepage inheritance and a single-byte-only mode.
</pre>
</div>
</content>
</entry>
<entry>
<title>cursor movement via fnkeys.tes now preserves the column as in most text editors</title>
<updated>2024-01-28T03:32:47+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-01-28T03:21:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=f2b070cb6ced1828c3328b02f0b437cf19a7cfd1'/>
<id>f2b070cb6ced1828c3328b02f0b437cf19a7cfd1</id>
<content type='text'>
* Horizontal movements (left/right cursor keys) establish the current column
  and vertical movements (up/down) will try to keep on that column.
* This has long been problematic in SciTECO as it requires state that gets
  reversed when the command line replacement takes place.
* I experimented with encoding the current horizontal position into the braced
  movement operations as in (123C5U$), but I decided that this was clumsy and
  I generally did not want these expressions to become even larger.
* Instead I decided to add some minimal support to the C core in the form of 4EJ
  which is like a number register only that it does NOT get reversed on rubout.
  This is exploited by the fnkeys.tes macros by storing the current position
  beyond replacements.
* In theory, this should be a property of the document, but we cannot easily
  store custom parameters per document.
  So instead, there is just one global variable.
  When editing another buffer, it gets reset to .ESGETCOLUMN$$.
  sample.teco_ini has been updated.
* The current X position only makes sense in the context of fnkeys.tes, as
  TECO commands like &lt;C&gt; are not necessarily "horizonal" movements.
  For the same reason, the core does not try to initialize 4EJ automatically
  when editing new buffers.
  It's entirely left to the TECO macros.
* The commandline replacement is more robust now as it checks braced
  expressions at the end of the command line more thorougly.
  It will no longer swallow all preceding braced expressions.
  Only if they are at least 4 characters in length and end in `C)` or `R)`.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Horizontal movements (left/right cursor keys) establish the current column
  and vertical movements (up/down) will try to keep on that column.
* This has long been problematic in SciTECO as it requires state that gets
  reversed when the command line replacement takes place.
* I experimented with encoding the current horizontal position into the braced
  movement operations as in (123C5U$), but I decided that this was clumsy and
  I generally did not want these expressions to become even larger.
* Instead I decided to add some minimal support to the C core in the form of 4EJ
  which is like a number register only that it does NOT get reversed on rubout.
  This is exploited by the fnkeys.tes macros by storing the current position
  beyond replacements.
* In theory, this should be a property of the document, but we cannot easily
  store custom parameters per document.
  So instead, there is just one global variable.
  When editing another buffer, it gets reset to .ESGETCOLUMN$$.
  sample.teco_ini has been updated.
* The current X position only makes sense in the context of fnkeys.tes, as
  TECO commands like &lt;C&gt; are not necessarily "horizonal" movements.
  For the same reason, the core does not try to initialize 4EJ automatically
  when editing new buffers.
  It's entirely left to the TECO macros.
* The commandline replacement is more robust now as it checks braced
  expressions at the end of the command line more thorougly.
  It will no longer swallow all preceding braced expressions.
  Only if they are at least 4 characters in length and end in `C)` or `R)`.
</pre>
</div>
</content>
</entry>
<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>
</feed>
