<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src/interface-gtk, branch libxcurses</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>implemented the ^W command for refreshing the screen in loops, for sleeping and also the CTRL+L immediate editing command</title>
<updated>2025-08-01T19:53:54+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-08-01T19:53:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=daead48672e56af966911abc4efe1e54573c02cc'/>
<id>daead48672e56af966911abc4efe1e54573c02cc</id>
<content type='text'>
* ^W can be added to loops in order to view progress in interactive mode.
  It also sleeps for a given number of milliseconds (10ms by default).
* In batch mode it is therefore the sleep command.
* Since CTRL+W is an immediate editing command, you will usually type it Caret+W.
  ASCII 23 however will also be accepted.
* While ^W only updates the screen, you can force a complete redraw by pressing CTRL+L.
  This is what most terminal applications use for redrawing.
  It will make it harder to insert ASCII 12, but this is seldom necessary since it
  is a form feed.
  ^L (ASCII 12 and the upcaret variant ) is still a whitespace character and therefore treated as a NOP.
* DEC TECO had CTRL+W as the refresh immediate editing command.
  Video TECO uses &lt;ET&gt; as a regular command for refreshign in loops.
  I'd rather keep ET reserved as a potential terminal configuration command
  as in DEC TECO, though.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* ^W can be added to loops in order to view progress in interactive mode.
  It also sleeps for a given number of milliseconds (10ms by default).
* In batch mode it is therefore the sleep command.
* Since CTRL+W is an immediate editing command, you will usually type it Caret+W.
  ASCII 23 however will also be accepted.
* While ^W only updates the screen, you can force a complete redraw by pressing CTRL+L.
  This is what most terminal applications use for redrawing.
  It will make it harder to insert ASCII 12, but this is seldom necessary since it
  is a form feed.
  ^L (ASCII 12 and the upcaret variant ) is still a whitespace character and therefore treated as a NOP.
* DEC TECO had CTRL+W as the refresh immediate editing command.
  Video TECO uses &lt;ET&gt; as a regular command for refreshign in loops.
  I'd rather keep ET reserved as a potential terminal configuration command
  as in DEC TECO, though.
</pre>
</div>
</content>
</entry>
<entry>
<title>implemented ^T command: allows typing by code and getting characters from stdin or the user</title>
<updated>2025-07-30T21:33:43+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-30T20:58:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=2ec568579823c991b919fa3a2c8583a8db21cb81'/>
<id>2ec568579823c991b919fa3a2c8583a8db21cb81</id>
<content type='text'>
* n:^T always prints bytes (cf. :^A)
* ^T without arguments returns a codepoint or byte from stdin.
  In interactive mode, this currentply places a cursor in the message line and waits for a keypress.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* n:^T always prints bytes (cf. :^A)
* ^T without arguments returns a codepoint or byte from stdin.
  In interactive mode, this currentply places a cursor in the message line and waits for a keypress.
</pre>
</div>
</content>
</entry>
<entry>
<title>implemented the &lt;^A&gt; command for printing arbitrary strings</title>
<updated>2025-07-25T21:42:15+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-24T22:41:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=eee669a76b3c0b1928475d55d9e1333b3d15bb8c'/>
<id>eee669a76b3c0b1928475d55d9e1333b3d15bb8c</id>
<content type='text'>
* Greatly improved usability as a scripting language.
* The command is in DEC TECO, but in contrast to DEC TECO, we also
  support string building constructs in ^A.
* Required some refactoring: As we want it to write everything verbatim
  to stdout, the per-interface method is now teco_interface_msg_literal()
  and it has to deal with unprintable characters.
  When displaying in the UI, we use teco_curses_format_str() and TecoGtkLabel
  functions/widgets to deal with possible control codes.
* Numbers printed with `=` have to be written with a trailing linefeed,
  which would also be visible as a reverse "LF" in the UI.
  Not sure whether this is acceptable - the alternative would be to strip
  the strings before displaying them.
* Messages written to stdout are also auto-flushed at the moment.
  In the future we might want to put flushing under control of the language.
  Perhaps :^A could inhibit the flushing.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Greatly improved usability as a scripting language.
* The command is in DEC TECO, but in contrast to DEC TECO, we also
  support string building constructs in ^A.
* Required some refactoring: As we want it to write everything verbatim
  to stdout, the per-interface method is now teco_interface_msg_literal()
  and it has to deal with unprintable characters.
  When displaying in the UI, we use teco_curses_format_str() and TecoGtkLabel
  functions/widgets to deal with possible control codes.
* Numbers printed with `=` have to be written with a trailing linefeed,
  which would also be visible as a reverse "LF" in the UI.
  Not sure whether this is acceptable - the alternative would be to strip
  the strings before displaying them.
* Messages written to stdout are also auto-flushed at the moment.
  In the future we might want to put flushing under control of the language.
  Perhaps :^A could inhibit the flushing.
</pre>
</div>
</content>
</entry>
<entry>
<title>make some array declarations real constants</title>
<updated>2025-07-17T22:12:45+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-17T22:12:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=45b9dea901cec7045be1a98f61d48d41dc965a9f'/>
<id>45b9dea901cec7045be1a98f61d48d41dc965a9f</id>
<content type='text'>
* `static const char *p = "FOO"` is not a true constant since
  the variable p can still be changed.
  It has to be declared as `static const char *const p = "FOO"`,
  so that the pointer itself is constant.
* In case of string constants, it's easier however to use `static const char p[] = "FOO"`.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* `static const char *p = "FOO"` is not a true constant since
  the variable p can still be changed.
  It has to be declared as `static const char *const p = "FOO"`,
  so that the pointer itself is constant.
* In case of string constants, it's easier however to use `static const char p[] = "FOO"`.
</pre>
</div>
</content>
</entry>
<entry>
<title>the primary clipboard is now chosen by the 10th bit in the ED flags</title>
<updated>2025-07-15T21:15:33+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-15T21:15:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=4794367ce0c31f820bf2bd72d44c886984e3f7ed'/>
<id>4794367ce0c31f820bf2bd72d44c886984e3f7ed</id>
<content type='text'>
* `[q]~` was broken and resulted in crashes since it reset the clipboard character to 0.
  In fact, if we don't want to break the `[a]b` idiom we cannot use the numeric cell
  of register `~`.
* Therefore we no longer use the numeric part of register `~`.
  Once the clipboard registers are initialized they completely replace
  any existing register with the same name that may have been
  set in the profile.
  So we still don't leak any memory.
  (But perhaps it would now be better to fail with an error
  if one of the clipboard registers already exist?)
* Instead, bit 10 (1024) of ED is now used to change the default
  clipboard to the primary selection.
  The alternative might have been an EJ flag or even a special register containing
  the name of the default clipboard register.
* partially reverses 8c6de6cc718debf44f6056a4c34c4fbb13bc5020
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* `[q]~` was broken and resulted in crashes since it reset the clipboard character to 0.
  In fact, if we don't want to break the `[a]b` idiom we cannot use the numeric cell
  of register `~`.
* Therefore we no longer use the numeric part of register `~`.
  Once the clipboard registers are initialized they completely replace
  any existing register with the same name that may have been
  set in the profile.
  So we still don't leak any memory.
  (But perhaps it would now be better to fail with an error
  if one of the clipboard registers already exist?)
* Instead, bit 10 (1024) of ED is now used to change the default
  clipboard to the primary selection.
  The alternative might have been an EJ flag or even a special register containing
  the name of the default clipboard register.
* partially reverses 8c6de6cc718debf44f6056a4c34c4fbb13bc5020
</pre>
</div>
</content>
</entry>
<entry>
<title>allow changing the default clipboard by setting the `~` integer</title>
<updated>2025-07-12T21:53:58+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-12T21:53:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=8c6de6cc718debf44f6056a4c34c4fbb13bc5020'/>
<id>8c6de6cc718debf44f6056a4c34c4fbb13bc5020</id>
<content type='text'>
* It continues to default to 67 (C), which is the system clipboard.
  But you can now overwrite it e.g. by adding `^^PU~` to the profile.
* This fixes a minor memory leak:
  If you set one of the clipboard registers in the profile (initializing
  them as plain registers), the clipboard register had been leaked.
  The clipboard registers now replace any existing register,
  while at the same time preserving the numeric part.
* All remaining Q-Reg table insertions use a new function
  teco_qreg_table_insert_unique() which adds an assertion, so that
  we notice any future possible memory leaks.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* It continues to default to 67 (C), which is the system clipboard.
  But you can now overwrite it e.g. by adding `^^PU~` to the profile.
* This fixes a minor memory leak:
  If you set one of the clipboard registers in the profile (initializing
  them as plain registers), the clipboard register had been leaked.
  The clipboard registers now replace any existing register,
  while at the same time preserving the numeric part.
* All remaining Q-Reg table insertions use a new function
  teco_qreg_table_insert_unique() which adds an assertion, so that
  we notice any future possible memory leaks.
</pre>
</div>
</content>
</entry>
<entry>
<title>GTK: handle (smooth) scrolling with a scroll controller</title>
<updated>2025-07-01T19:29:36+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-07-01T19:29:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=9e3746a4e42f98cad7dfe5b41779ffa81bd4366a'/>
<id>9e3746a4e42f98cad7dfe5b41779ffa81bd4366a</id>
<content type='text'>
* On interfaces, which only support smooth scrolling, we had to emulate
  discrete events. Moreover, once we enabled GDK_SMOOTH_SCROLL_MASK,
  systems that would previously report discrete UP/DOWN events, would
  suddenly report GDK_SCROLL_SMOOTH.
* Converting from smooth scroll events to discrete scroll events
  turned out to be trickier than anticipated.
  Scrolling was therefore more sluggish than it used to be before
  2f448c976889fe60aba8557b5aa4aa0a0d939281.
* Scrolling is therefore now delegated to a GtkEventControllerScroll,
  which is used to synthesize a discrete GDK_SCROLL event that's
  fed into the usual event pipeline via teco_interface_input_cb().
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* On interfaces, which only support smooth scrolling, we had to emulate
  discrete events. Moreover, once we enabled GDK_SMOOTH_SCROLL_MASK,
  systems that would previously report discrete UP/DOWN events, would
  suddenly report GDK_SCROLL_SMOOTH.
* Converting from smooth scroll events to discrete scroll events
  turned out to be trickier than anticipated.
  Scrolling was therefore more sluggish than it used to be before
  2f448c976889fe60aba8557b5aa4aa0a0d939281.
* Scrolling is therefore now delegated to a GtkEventControllerScroll,
  which is used to synthesize a discrete GDK_SCROLL event that's
  fed into the usual event pipeline via teco_interface_input_cb().
</pre>
</div>
</content>
</entry>
<entry>
<title>GTK: fixed scrolling on systems that only support smooth scrolling</title>
<updated>2025-06-12T19:33:09+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-06-12T19:06:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=2f448c976889fe60aba8557b5aa4aa0a0d939281'/>
<id>2f448c976889fe60aba8557b5aa4aa0a0d939281</id>
<content type='text'>
* Apparently, we cannot disable smooth scrolling on a per-application basis,
  so I have to handle both discrete and smooth scrolling events.
* Since SciTECO's scroll API (-EJ) is based on discrete scrolling, we now
  emulate discrete scroll events by accumulating the delta_y of smooth scroll events.
  The threshold value of 12 is chosen arbitrarily, but based on an example in
  the Gtk documentation.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Apparently, we cannot disable smooth scrolling on a per-application basis,
  so I have to handle both discrete and smooth scrolling events.
* Since SciTECO's scroll API (-EJ) is based on discrete scrolling, we now
  emulate discrete scroll events by accumulating the delta_y of smooth scroll events.
  The threshold value of 12 is chosen arbitrarily, but based on an example in
  the Gtk documentation.
</pre>
</div>
</content>
</entry>
<entry>
<title>auto-expand folds even after mouse events</title>
<updated>2025-05-02T08:59:31+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-05-02T04:33:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=62eb87b149166588d766d5a272e5232ecf86be5d'/>
<id>62eb87b149166588d766d5a272e5232ecf86be5d</id>
<content type='text'>
The ^KMOUSE macro can also change dot and it was possible
to place dot into invisible areas at the end of the document.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The ^KMOUSE macro can also change dot and it was possible
to place dot into invisible areas at the end of the document.
</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>
</feed>
