<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/lib/fnkeys.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>fnkeys.tes: fixed cursor navigation at beginning and end of document</title>
<updated>2026-03-26T23:09:49+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-03-25T17:28:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=d456b21d604c7a252d630b132dfa5b4f6b67d4fc'/>
<id>d456b21d604c7a252d630b132dfa5b4f6b67d4fc</id>
<content type='text'>
There is no way to catch errors in ^Q since :^Q is already taken
as a dot-to-line conversion. :^Q is an extension, so we might still
want to repurpose it.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There is no way to catch errors in ^Q since :^Q is already taken
as a dot-to-line conversion. :^Q is an extension, so we might still
want to repurpose it.
</pre>
</div>
</content>
</entry>
<entry>
<title>fnkeys.tes: when preserving the horizontal column, take the character representations and tab draw modes into account</title>
<updated>2026-03-15T18:40:09+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-03-15T18:40:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=cfc78d159338a94feeabb3b474860786d1beebd5'/>
<id>cfc78d159338a94feeabb3b474860786d1beebd5</id>
<content type='text'>
When editing TECO source files with fnkeys.tes, you could get unexpected cursor jumps
since SCI_GETCOLUMN counts all control characters as single columns and would always expand
tabs, even if tabs are drawn like control codes.

This could have been changed in Scintilla itself, but Neil decided that
SCI_GETCOLUMN and SCI_FINDCOLUMN will not be changed.
See https://groups.google.com/g/scintilla-interest/c/aqxapyAcRiA
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When editing TECO source files with fnkeys.tes, you could get unexpected cursor jumps
since SCI_GETCOLUMN counts all control characters as single columns and would always expand
tabs, even if tabs are drawn like control codes.

This could have been changed in Scintilla itself, but Neil decided that
SCI_GETCOLUMN and SCI_FINDCOLUMN will not be changed.
See https://groups.google.com/g/scintilla-interest/c/aqxapyAcRiA
</pre>
</div>
</content>
</entry>
<entry>
<title>fnkeys.tes: fixed clicking the fold margin</title>
<updated>2025-09-15T12:30:34+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-09-15T12:30:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=06ca6afa81f553acde65af5e1dd1866690530580'/>
<id>06ca6afa81f553acde65af5e1dd1866690530580</id>
<content type='text'>
This was broken by e82dc6639e829490cb11267fa4a49ef97c6459ae, i.e. wasn't broken in v2.4.0.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This was broken by e82dc6639e829490cb11267fa4a49ef97c6459ae, i.e. wasn't broken in v2.4.0.
</pre>
</div>
</content>
</entry>
<entry>
<title>support folding via F1 and clicks in the folding margin</title>
<updated>2025-04-26T23:55:06+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-26T14:46:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e3498abfd8d95dbd083ccfd1d386f9ad37044a43'/>
<id>e3498abfd8d95dbd083ccfd1d386f9ad37044a43</id>
<content type='text'>
* Set up the folding margin in the currently empty margin column
  after the line number.
  On Gtk, this meant resetting all the marker symbols and their
  foreground/background colors as well as the margin's colors themselves.
  This looks like a bug. It's not necessary on Scinterm, which apparently
  uses the default/linenumber styles by default.
  Perhaps we should try upgrading Scintilla?
* The folding state is considered not to be directly controlled by the
  language (just like the scroll position and zoom level). That's why
  we can directly control it by clicking on the margin column.
* F1 can be used to toggle all folds globally.
* The only support within the C core necessary for folding is to make
  sure that the current line is unfolded after every keypress.
* We might add custom folding commands to the language later on
  (e.g. F+, F-). In this case, the key macros will have to be changed
  of course.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Set up the folding margin in the currently empty margin column
  after the line number.
  On Gtk, this meant resetting all the marker symbols and their
  foreground/background colors as well as the margin's colors themselves.
  This looks like a bug. It's not necessary on Scinterm, which apparently
  uses the default/linenumber styles by default.
  Perhaps we should try upgrading Scintilla?
* The folding state is considered not to be directly controlled by the
  language (just like the scroll position and zoom level). That's why
  we can directly control it by clicking on the margin column.
* F1 can be used to toggle all folds globally.
* The only support within the C core necessary for folding is to make
  sure that the current line is unfolded after every keypress.
* We might add custom folding commands to the language later on
  (e.g. F+, F-). In this case, the key macros will have to be changed
  of course.
</pre>
</div>
</content>
</entry>
<entry>
<title>fnkeys.tes: mouse scrolling scrolls 2 lines by default and left clicks update the horizontal position (4EJ)</title>
<updated>2025-04-09T17:20:15+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-09T17:20:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=72aa210cc103af971c7a77660f014b11475af3aa'/>
<id>72aa210cc103af971c7a77660f014b11475af3aa</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>scroll caret __almost__ always automatically after key presses</title>
<updated>2025-04-04T00:53:07+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-04T00:36:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=d2f759a1d4c8a42db73ac62cb8317847a1b40249'/>
<id>d2f759a1d4c8a42db73ac62cb8317847a1b40249</id>
<content type='text'>
* The old heuristics - scroll if dot changes after key press -
  turned out to be too simplistic.
  They broke the clang-format macro (M#cf), which left the view at the
  top of the document since the entire document is temporarily erased.
  Other simplified examples of this bug would be:
  @^Um{[: HECcat$ ]:} Mm
  Or even: @^Um{[: H@X.aG.a ]:} Mm
* Actually, the heuristics could be tricked even without deleting any
  significant amount of text from the buffer.
  The following test case replaces the previous character with a linefeed
  in a single key press:
  @^Um{-DI^J$} Mm
  If executed on the last visible line, dot wouldn't be scrolled into the view
  since it did not change.
* At the same time, we'd like to keep the existing mouse scroll behavior from
  fnkeys.tes, which is allowed to scroll dot outside of the visible area.
  Therefore, dot is scrolled into view always, except after mouse events.
  You may have to call SCI_SCROLLCARET manually in the ^KMOUSE macro,
  which is arguably not always straight forward.
* Some macros like M#cf may still leave the vertical scrolling position
  in unexpected positions. This could either be fixed by eradicating all
  remaining automatic scrolling from Scintilla or by explicitly restoring
  the vertical position from the macro (FIXME).
* This was broken since the introduction of mouse support,
  so it wasn't in v2.3.0.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The old heuristics - scroll if dot changes after key press -
  turned out to be too simplistic.
  They broke the clang-format macro (M#cf), which left the view at the
  top of the document since the entire document is temporarily erased.
  Other simplified examples of this bug would be:
  @^Um{[: HECcat$ ]:} Mm
  Or even: @^Um{[: H@X.aG.a ]:} Mm
* Actually, the heuristics could be tricked even without deleting any
  significant amount of text from the buffer.
  The following test case replaces the previous character with a linefeed
  in a single key press:
  @^Um{-DI^J$} Mm
  If executed on the last visible line, dot wouldn't be scrolled into the view
  since it did not change.
* At the same time, we'd like to keep the existing mouse scroll behavior from
  fnkeys.tes, which is allowed to scroll dot outside of the visible area.
  Therefore, dot is scrolled into view always, except after mouse events.
  You may have to call SCI_SCROLLCARET manually in the ^KMOUSE macro,
  which is arguably not always straight forward.
* Some macros like M#cf may still leave the vertical scrolling position
  in unexpected positions. This could either be fixed by eradicating all
  remaining automatic scrolling from Scintilla or by explicitly restoring
  the vertical position from the macro (FIXME).
* This was broken since the introduction of mouse support,
  so it wasn't in v2.3.0.
</pre>
</div>
</content>
</entry>
<entry>
<title>harmonized all word-movement and deletion commands: they move/delete until the beginning of words now</title>
<updated>2025-03-22T11:13:53+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-22T10:45:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=867d22e419afe769f05ad26b61c6ea5ea1432c3c'/>
<id>867d22e419afe769f05ad26b61c6ea5ea1432c3c</id>
<content type='text'>
* All commands and their documentations were inconsistent.
  * ^W rubbed out to the beginning of words.
  * Shift+Right (fnkeys.tes) moved to the beginning of the next word if
    invoked at the beginning of a word and to the end of the next word otherwise.
  * &lt;W&gt; (and &lt;V&gt; and &lt;Y&gt; by extension) moved to the end of the next word.
  * The cheat sheet would claim that &lt;W&gt; moves to the beginning of the next word.
* Video TECO's &lt;W&gt; command would differ again from everything else.
  With positive arguments, it moved to the beginning of words, while
  with negative it moved to end of words.
  I decided not to copy this behavior.
* It has been decided to adopt a consistent beginning-of-words policy.
  -W therefore differs from Video TECO in moving to the beginning of the
  current or previous word.
* teco_find_words() is now based on parsing the document pointer, instead
  of relying on SCI_WORDENDPOSITION, since the latter cannot actually be
  used to skip strictly non-word characters.
  This requires a constant amount of Scintilla messages but will require fewer
  messages only when moving for more than 3 words.
* The semantics of &lt;W&gt; are therefore now consistent with Vim and Emacs as well.
* Shift+Right/Left is still based on SCI_WORDENDPOSITION, so it's behavior
  differs slightly from &lt;W&gt; for instance at the end of lines, as it will
  stop at linebreaks.
* Unfortunately, these changes will break lots of macros, among others
  the M#rf, M#sp and git.blame macros ("Useful macros" from the wiki).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* All commands and their documentations were inconsistent.
  * ^W rubbed out to the beginning of words.
  * Shift+Right (fnkeys.tes) moved to the beginning of the next word if
    invoked at the beginning of a word and to the end of the next word otherwise.
  * &lt;W&gt; (and &lt;V&gt; and &lt;Y&gt; by extension) moved to the end of the next word.
  * The cheat sheet would claim that &lt;W&gt; moves to the beginning of the next word.
* Video TECO's &lt;W&gt; command would differ again from everything else.
  With positive arguments, it moved to the beginning of words, while
  with negative it moved to end of words.
  I decided not to copy this behavior.
* It has been decided to adopt a consistent beginning-of-words policy.
  -W therefore differs from Video TECO in moving to the beginning of the
  current or previous word.
* teco_find_words() is now based on parsing the document pointer, instead
  of relying on SCI_WORDENDPOSITION, since the latter cannot actually be
  used to skip strictly non-word characters.
  This requires a constant amount of Scintilla messages but will require fewer
  messages only when moving for more than 3 words.
* The semantics of &lt;W&gt; are therefore now consistent with Vim and Emacs as well.
* Shift+Right/Left is still based on SCI_WORDENDPOSITION, so it's behavior
  differs slightly from &lt;W&gt; for instance at the end of lines, as it will
  stop at linebreaks.
* Unfortunately, these changes will break lots of macros, among others
  the M#rf, M#sp and git.blame macros ("Useful macros" from the wiki).
</pre>
</div>
</content>
</entry>
<entry>
<title>implemented mouse support via special ^KMOUSE and &lt;EJ&gt; with negative keys</title>
<updated>2025-02-15T23:20:39+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-02-02T10:17:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=b87c56799ab6f6d651e1dc6c712a625545a4ad5f'/>
<id>b87c56799ab6f6d651e1dc6c712a625545a4ad5f</id>
<content type='text'>
* You need to set 0,64ED to enable mouse processing in Curses.
  It is always enabled in Gtk as it should never make the experience worse.
  sample.teco_ini enables mouse support, since this should be the new default.
  `sciteco --no-profile` won't have it enabled, though.
* On curses, it requires the ncurses mouse protocol version 2, which will
  also be supported by PDCurses.
* Similar to the Curses API, a special key macro ^KMOUSE is inserted if any of the supported
  mouse events has been detected.
* You can then use -EJ to get the type of mouse event, which can be used
  with a computed goto in the command-line editing macro.
  Alternatively, this could have been solved with separate ^KMOUSE:PRESSED,
  ^KMOUSE:RELEASED etc. pseudo-key macros.
* The default ^KMOUSE implementation in fnkeys.tes supports the following:
  * Left click: Edit command line to jump to position.
  * Ctrl+left click: Jump to beginning of line.
  * Right click: Insert position or position range (when dragging).
  * Double right click: insert range for word under cursor
  * Ctrl+right click: Insert beginning of line
  * Scroll wheel: scrolls (faster with shift)
  * Ctrl+scroll wheel: zoom (GTK-only)
* Currently, there is no visual feedback when "selecting" ranges
  via right-click+drag.
  This would be tricky to do and most terminal emulators do not appear
  to support continuous mouse updates.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* You need to set 0,64ED to enable mouse processing in Curses.
  It is always enabled in Gtk as it should never make the experience worse.
  sample.teco_ini enables mouse support, since this should be the new default.
  `sciteco --no-profile` won't have it enabled, though.
* On curses, it requires the ncurses mouse protocol version 2, which will
  also be supported by PDCurses.
* Similar to the Curses API, a special key macro ^KMOUSE is inserted if any of the supported
  mouse events has been detected.
* You can then use -EJ to get the type of mouse event, which can be used
  with a computed goto in the command-line editing macro.
  Alternatively, this could have been solved with separate ^KMOUSE:PRESSED,
  ^KMOUSE:RELEASED etc. pseudo-key macros.
* The default ^KMOUSE implementation in fnkeys.tes supports the following:
  * Left click: Edit command line to jump to position.
  * Ctrl+left click: Jump to beginning of line.
  * Right click: Insert position or position range (when dragging).
  * Double right click: insert range for word under cursor
  * Ctrl+right click: Insert beginning of line
  * Scroll wheel: scrolls (faster with shift)
  * Ctrl+scroll wheel: zoom (GTK-only)
* Currently, there is no visual feedback when "selecting" ranges
  via right-click+drag.
  This would be tricky to do and most terminal emulators do not appear
  to support continuous mouse updates.
</pre>
</div>
</content>
</entry>
<entry>
<title>implemented the ^Q command for converting between line and glyph positions</title>
<updated>2024-12-08T13:10:29+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-12-08T02:22:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=bd87ff40e73929e761e1233aa812a6736cacbed1'/>
<id>bd87ff40e73929e761e1233aa812a6736cacbed1</id>
<content type='text'>
* As known from DEC TECO, but extended to convert absolute positions to line numbers as well.
  :^Q returns the current line.
* Especially useful in macros that accept line arguments,
  as it is much shorter than something like
  ^E@ES/LINEFROMPOSITION//+Q.l@ES/POSITIONFROMLINE//:^E-.
* On the other hand, the fact that ^Q checks the line range means we cannot
  easily replace lexer.checkheader with something like
  [:J 0,^Q::S...$ ]:
  Using SCI_POSITIONFROMLINE still has the advantage that it returns `Z` for out-of-bounds ranges
  which would be cumbersome to write with the current ^Q.
* Perhaps there should be a separate command for converting between absolute lines and positions
  and :^Q should be repurposed to return a failure boolean for out-of-range values?
* fnkeys.tes could be simplified.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* As known from DEC TECO, but extended to convert absolute positions to line numbers as well.
  :^Q returns the current line.
* Especially useful in macros that accept line arguments,
  as it is much shorter than something like
  ^E@ES/LINEFROMPOSITION//+Q.l@ES/POSITIONFROMLINE//:^E-.
* On the other hand, the fact that ^Q checks the line range means we cannot
  easily replace lexer.checkheader with something like
  [:J 0,^Q::S...$ ]:
  Using SCI_POSITIONFROMLINE still has the advantage that it returns `Z` for out-of-bounds ranges
  which would be cumbersome to write with the current ^Q.
* Perhaps there should be a separate command for converting between absolute lines and positions
  and :^Q should be repurposed to return a failure boolean for out-of-range values?
* fnkeys.tes could be simplified.
</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>
</feed>
