<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src/interface-curses, branch v2.1.0</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>netbsd-curses: fixed the default escape delay</title>
<updated>2024-10-15T08:30:18+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-10-15T08:30:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e307e56d5591f844c77425a9e72dca6c1cabd766'/>
<id>e307e56d5591f844c77425a9e72dca6c1cabd766</id>
<content type='text'>
* Apparently, netbsd-curses overwrites the escdelay on initscr() (if $ESCDELAY is not set),
  so we have to apply the default 25ms after screen initialization.
* The info line is not drawn correctly on netbsd-curses, but only on st/simpleterm.
  I assume this is just a shortcoming of the included terminfo entry.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Apparently, netbsd-curses overwrites the escdelay on initscr() (if $ESCDELAY is not set),
  so we have to apply the default 25ms after screen initialization.
* The info line is not drawn correctly on netbsd-curses, but only on st/simpleterm.
  I assume this is just a shortcoming of the included terminfo entry.
</pre>
</div>
</content>
</entry>
<entry>
<title>Gtk UI: support setting and getting clipboards containing null bytes</title>
<updated>2024-10-05T16:27:18+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-10-05T16:27:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=52d73e8b5d82aba0ec3c1b0efd8b6b0a1ee5b5a2'/>
<id>52d73e8b5d82aba0ec3c1b0efd8b6b0a1ee5b5a2</id>
<content type='text'>
* added TECO_ERROR_CLIPBOARD for all clipboard-related errors
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* added TECO_ERROR_CLIPBOARD for all clipboard-related errors
</pre>
</div>
</content>
</entry>
<entry>
<title>Git lexer: added support for TAG_EDITMSG and MERGE_MSG</title>
<updated>2024-09-26T13:12:49+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-26T13:12:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=c4a1c3a21818965f669ebc6a081f08323a6919f1'/>
<id>c4a1c3a21818965f669ebc6a081f08323a6919f1</id>
<content type='text'>
* Curses: "icons" have also been added
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Curses: "icons" have also been added
</pre>
</div>
</content>
</entry>
<entry>
<title>Curses: added "Git" icons for COMMIT_EDITMSG and git-rebase-todo</title>
<updated>2024-09-25T17:35:19+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-25T17:35:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=a06bcea66e865e85c0b2fc9f6fc3e94c3bedbcf5'/>
<id>a06bcea66e865e85c0b2fc9f6fc3e94c3bedbcf5</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</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: always wgetch() on a dummy pad, avoiding unnecessary wrefresh()</title>
<updated>2024-09-22T10:47:40+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-22T10:36:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=84cc45ebbdcd62a0bad33d65223a45dc146a0f07'/>
<id>84cc45ebbdcd62a0bad33d65223a45dc146a0f07</id>
<content type='text'>
* This is especially important on platforms, requiring the wgetch()
  poll workaround to detect CTRL+C (PDCurses/WinGUI).
  wgetch(cmdline_window) would implicitly wrefresh(cmdline_window),
  which resulted in additional flickering when pressing function keys.
  This is no longer so important since key macros are processed
  as an unity and the cmdline will be updated only after processing
  all of the characters contained in them, ie. only once after the key press.
  Still, there could have still been unwanted side effects.
  At the very least, wgetch(input_pad) should be faster.
* The XTerm clipboard implementation was getch()ing on stdscr,
  so potentially suffered from the same problem.
  It should be tested again.
* Since keypad() is now always enabled even on netbsd-curses.
  I assume that the function key processing bug in netbsd-curses
  has been fixed by now. We are not building any releases with
  netbsd-curses. But it should be retested.
* It does not resolve all flickering issues on PDCurses/WinGUI.
  Both the command line and the Scintilla view still flicker near
  the cursor. See
  https://github.com/Bill-Gray/PDCursesMod/issues/322
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This is especially important on platforms, requiring the wgetch()
  poll workaround to detect CTRL+C (PDCurses/WinGUI).
  wgetch(cmdline_window) would implicitly wrefresh(cmdline_window),
  which resulted in additional flickering when pressing function keys.
  This is no longer so important since key macros are processed
  as an unity and the cmdline will be updated only after processing
  all of the characters contained in them, ie. only once after the key press.
  Still, there could have still been unwanted side effects.
  At the very least, wgetch(input_pad) should be faster.
* The XTerm clipboard implementation was getch()ing on stdscr,
  so potentially suffered from the same problem.
  It should be tested again.
* Since keypad() is now always enabled even on netbsd-curses.
  I assume that the function key processing bug in netbsd-curses
  has been fixed by now. We are not building any releases with
  netbsd-curses. But it should be retested.
* It does not resolve all flickering issues on PDCurses/WinGUI.
  Both the command line and the Scintilla view still flicker near
  the cursor. See
  https://github.com/Bill-Gray/PDCursesMod/issues/322
</pre>
</div>
</content>
</entry>
<entry>
<title>PDCurses/WinGUI: fixed Unicode icons on win32</title>
<updated>2024-09-21T11:17:36+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-21T11:17:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=6f166676c7cbd9fd572ffa2938f3737436a10f42'/>
<id>6f166676c7cbd9fd572ffa2938f3737436a10f42</id>
<content type='text'>
* Turns out that "%C" in wprintw() does not work with non-ANSI chars.
* We still don't want to introduce the Curses widechar API,
  so I added teco_curses_add_wc() as a replacement for wadd_wch().
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Turns out that "%C" in wprintw() does not work with non-ANSI chars.
* We still don't want to introduce the Curses widechar API,
  so I added teco_curses_add_wc() as a replacement for wadd_wch().
</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>the SciTECO parser is Unicode-based now (refs #5)</title>
<updated>2024-09-11T14:14:27+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-11T10:21:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=68578072bfaf6054a96bb6bcedfccb6e56a508fe'/>
<id>68578072bfaf6054a96bb6bcedfccb6e56a508fe</id>
<content type='text'>
The following rules apply:
 * All SciTECO macros __must__ be in valid UTF-8, regardless of the
   the register's configured encoding.
   This is checked against before execution, so we can use glib's non-validating
   UTF-8 API afterwards.
 * Things will inevitably get slower as we have to validate all macros first
   and convert to gunichar for each and every character passed into the parser.
   As an optimization, it may make sense to have our own inlineable version of
   g_utf8_get_char() (TODO).
   Also, Unicode glyphs in syntactically significant positions may be case-folded -
   just like ASCII chars were. This is is of course slower than case folding
   ASCII. The impact of this should be measured and perhaps we should restrict
   case folding to a-z via teco_ascii_toupper().
 * The language itself does not use any non-ANSI characters, so you don't have to
   use UTF-8 characters.
 * Wherever the parser expects a single character, it will now accept an arbitrary
   Unicode/UTF-8 glyph as well.
   In other words, you can call macros like M§ instead of having to write M[§].
   You can also get the codepoint of any Unicode character with ^^x.
   Pressing an Unicode character in the start state or in Ex and Fx will now
   give a sane error message.
 * When pressing a key which produces a multi-byte UTF-8 sequence, the character
   gets translated back and forth multiple times:
   1. It's converted to an UTF-8 string, either buffered or by IME methods (Gtk).
      On Curses we could directly get a wide char using wget_wch(), but it's
      not currently used, so we don't depend on widechar curses.
   2. Parsed into gunichar for passing into the edit command callbacks.
      This also validates the codepoint - everything later on can assume valid
      codepoints and valid UTF-8 strings.
   3. Once the edit command handling decides to insert the key into the command line,
      it is serialized back into an UTF-8 string as the command line macro has
      to be in UTF-8 (like all other macros).
   4. The parser reads back gunichars without validation for passing into
      the parser callbacks.
 * Flickering in the Curses UI and Pango warnings in Gtk, due to incompletely
   inserted and displayed UTF-8 sequences, are now fixed.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The following rules apply:
 * All SciTECO macros __must__ be in valid UTF-8, regardless of the
   the register's configured encoding.
   This is checked against before execution, so we can use glib's non-validating
   UTF-8 API afterwards.
 * Things will inevitably get slower as we have to validate all macros first
   and convert to gunichar for each and every character passed into the parser.
   As an optimization, it may make sense to have our own inlineable version of
   g_utf8_get_char() (TODO).
   Also, Unicode glyphs in syntactically significant positions may be case-folded -
   just like ASCII chars were. This is is of course slower than case folding
   ASCII. The impact of this should be measured and perhaps we should restrict
   case folding to a-z via teco_ascii_toupper().
 * The language itself does not use any non-ANSI characters, so you don't have to
   use UTF-8 characters.
 * Wherever the parser expects a single character, it will now accept an arbitrary
   Unicode/UTF-8 glyph as well.
   In other words, you can call macros like M§ instead of having to write M[§].
   You can also get the codepoint of any Unicode character with ^^x.
   Pressing an Unicode character in the start state or in Ex and Fx will now
   give a sane error message.
 * When pressing a key which produces a multi-byte UTF-8 sequence, the character
   gets translated back and forth multiple times:
   1. It's converted to an UTF-8 string, either buffered or by IME methods (Gtk).
      On Curses we could directly get a wide char using wget_wch(), but it's
      not currently used, so we don't depend on widechar curses.
   2. Parsed into gunichar for passing into the edit command callbacks.
      This also validates the codepoint - everything later on can assume valid
      codepoints and valid UTF-8 strings.
   3. Once the edit command handling decides to insert the key into the command line,
      it is serialized back into an UTF-8 string as the command line macro has
      to be in UTF-8 (like all other macros).
   4. The parser reads back gunichars without validation for passing into
      the parser callbacks.
 * Flickering in the Curses UI and Pango warnings in Gtk, due to incompletely
   inserted and displayed UTF-8 sequences, are now fixed.
</pre>
</div>
</content>
</entry>
</feed>
