<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/TODO, 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>updated TODO</title>
<updated>2024-10-15T16:02:42+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-10-15T16:02:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=95dca302011d49e465a1ee50f722684969e49781'/>
<id>95dca302011d49e465a1ee50f722684969e49781</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>^W^W and ^V^V can be typed completely with upcarets now and they case fold all expansions of ^EQq, ^EUq and so on</title>
<updated>2024-09-20T11:50:13+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-20T11:50:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=2b5b2a48f8db3d6b73a0f1a6e0aeab3a940b3b85'/>
<id>2b5b2a48f8db3d6b73a0f1a6e0aeab3a940b3b85</id>
<content type='text'>
* Previously, there was no way to enter upper-case mode in interactive commands since
  the Ctrl+W immediate editing command is interpreted everywhere.
* Without the case folding of ^EQq/^EUq results, the upper and lower case modes are actually pretty useless
  considering that modern keyboards have caps lock.
  So it was clear we need this, regardless of what the classic TECOs did.
  The TECO-11 manual is not very clear on this.
  tecoc apparently does not case-fold ^EQq results.
* This opens up new idioms, for instance
  `EUq^W^W^EQq$` in order to upper case register q.
  It's also the only way you can currently upper-case Unicode codepoints.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Previously, there was no way to enter upper-case mode in interactive commands since
  the Ctrl+W immediate editing command is interpreted everywhere.
* Without the case folding of ^EQq/^EUq results, the upper and lower case modes are actually pretty useless
  considering that modern keyboards have caps lock.
  So it was clear we need this, regardless of what the classic TECOs did.
  The TECO-11 manual is not very clear on this.
  tecoc apparently does not case-fold ^EQq results.
* This opens up new idioms, for instance
  `EUq^W^W^EQq$` in order to upper case register q.
  It's also the only way you can currently upper-case Unicode codepoints.
</pre>
</div>
</content>
</entry>
<entry>
<title>Ctrl+^ is no longer translated to a single caret in string building (refs #20)</title>
<updated>2024-09-19T10:53:14+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-19T10:53:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=fcf962edded2d6a7cb638909587167261e4f2bb0'/>
<id>fcf962edded2d6a7cb638909587167261e4f2bb0</id>
<content type='text'>
* Ctrl+^ (30) and Caret+caret (^^) were both translated to a single caret.
  While there might be some reason to keep this behavior for double-caret,
  it is certainly pointless for Ctrl+^.
* That gives you an easy way to insert Ctrl+^ (code 30) into documents with &lt;I&gt;.
  Perviously, you either had to insert a double-caret, typing 4 carets in a row,
  or you had to use &lt;EI&gt; or 30I$.
* The special handling of double-caret could perhaps be abolished altogether,
  as we also have ^Q^ to escape plain carets.
  The double-caret syntax is very archaic from the time that there was no proper
  ^Q as far as I recall correctly.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Ctrl+^ (30) and Caret+caret (^^) were both translated to a single caret.
  While there might be some reason to keep this behavior for double-caret,
  it is certainly pointless for Ctrl+^.
* That gives you an easy way to insert Ctrl+^ (code 30) into documents with &lt;I&gt;.
  Perviously, you either had to insert a double-caret, typing 4 carets in a row,
  or you had to use &lt;EI&gt; or 30I$.
* The special handling of double-caret could perhaps be abolished altogether,
  as we also have ^Q^ to escape plain carets.
  The double-caret syntax is very archaic from the time that there was no proper
  ^Q as far as I recall correctly.
</pre>
</div>
</content>
</entry>
<entry>
<title>"special" Q-Registers now support EQq/.../ (load) and E%q/.../ (save) commands</title>
<updated>2024-09-19T01:34:03+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-19T01:05:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=8fbd0b3ff42ae10c3735801ad17f5345fdc77766'/>
<id>8fbd0b3ff42ae10c3735801ad17f5345fdc77766</id>
<content type='text'>
* @EQ$/.../ sets the current directory from the contents of the given file.
  @E%$/.../ stores the currend directory in the given file.
* @EQ*/.../ will fail, just like ^U*...$.
  @E%*/.../ stores the current buffer's name in the given file.
* It's especially useful with the clipboard registers.
  There could still be a minor bug in @E%~/.../ with regard to EOL normalization
  as teco_view_save() will use the EOL style of the current document, which
  may not be the style of the Q-Reg contents.
  Conversions can generally be avoided for these particular commands.
  But without teco_view_save() we'd have to care about save point creation.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* @EQ$/.../ sets the current directory from the contents of the given file.
  @E%$/.../ stores the currend directory in the given file.
* @EQ*/.../ will fail, just like ^U*...$.
  @E%*/.../ stores the current buffer's name in the given file.
* It's especially useful with the clipboard registers.
  There could still be a minor bug in @E%~/.../ with regard to EOL normalization
  as teco_view_save() will use the EOL style of the current document, which
  may not be the style of the Q-Reg contents.
  Conversions can generally be avoided for these particular commands.
  But without teco_view_save() we'd have to care about save point creation.
</pre>
</div>
</content>
</entry>
<entry>
<title>check that local register is not edited at the end of macro calls</title>
<updated>2024-09-18T10:32:16+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-18T10:32:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=b7b98405089e69dfae0fc11e2a423860f50756e9'/>
<id>b7b98405089e69dfae0fc11e2a423860f50756e9</id>
<content type='text'>
* This was unsafe and could easily result in crashes, since teco_qreg_current
  would afterwards point to an already freed Q-Register.
* Since automatically editing another register or buffer is not easy to do right,
  we throw an error instead.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This was unsafe and could easily result in crashes, since teco_qreg_current
  would afterwards point to an already freed Q-Register.
* Since automatically editing another register or buffer is not easy to do right,
  we throw an error instead.
</pre>
</div>
</content>
</entry>
<entry>
<title>updated TODO</title>
<updated>2024-09-16T21:38:35+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-16T21:38:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=f93b1b5afbf821c736f988c354850d63620a195f'/>
<id>f93b1b5afbf821c736f988c354850d63620a195f</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>update TODO</title>
<updated>2024-09-12T14:51:54+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-09-12T14:51:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=711e674080baa25cd6f454785df7590e45345733'/>
<id>711e674080baa25cd6f454785df7590e45345733</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>updated TODO</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-11T14:12:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=3e09ed822aed1b2ec1214d11a9c67ff427f56fa8'/>
<id>3e09ed822aed1b2ec1214d11a9c67ff427f56fa8</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>updated TODO</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-09T16:04:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=afb86d824db771586876078e8844049e451b283d'/>
<id>afb86d824db771586876078e8844049e451b283d</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>prefer libncursesw (widechar variant) (refs #5)</title>
<updated>2024-09-09T16:17:03+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-08-28T12:03:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=f79a6f65acde9753ea65887e0e0d4bc7f76ff52b'/>
<id>f79a6f65acde9753ea65887e0e0d4bc7f76ff52b</id>
<content type='text'>
* Some platforms like Ubuntu actually ship widechar and non-widechar versions
  of ncurses with different pkg-config files.
  Other platforms like FreeBSD will ship an "ncursesw" and "ncurses" pkg-config file
  but both point to the same wide-char library anyway.
* Currently we are not using wide-char APIs to ensure maximum compatibility even with
  embedded systems where ncurses might be built without widechar support.
  But in order to handle Unicode correctly, we still need to link against the widechar version
  of ncurses (if available).
* Compilation on platforms without a widechar ncurses is now handled by the common
  AC_CHECK_LIB() fallback (which might actually find a widechar version anyway if it just
  didn't install the pkg-config file).
  If necessary, we could also check for the "ncurses" package if "ncursesw" is not found.
* This fixes Unicode display and input on Ubuntu.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Some platforms like Ubuntu actually ship widechar and non-widechar versions
  of ncurses with different pkg-config files.
  Other platforms like FreeBSD will ship an "ncursesw" and "ncurses" pkg-config file
  but both point to the same wide-char library anyway.
* Currently we are not using wide-char APIs to ensure maximum compatibility even with
  embedded systems where ncurses might be built without widechar support.
  But in order to handle Unicode correctly, we still need to link against the widechar version
  of ncurses (if available).
* Compilation on platforms without a widechar ncurses is now handled by the common
  AC_CHECK_LIB() fallback (which might actually find a widechar version anyway if it just
  didn't install the pkg-config file).
  If necessary, we could also check for the "ncurses" package if "ncursesw" is not found.
* This fixes Unicode display and input on Ubuntu.
</pre>
</div>
</content>
</entry>
</feed>
