<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/TODO, branch session-extensions</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>bumped target release to v2.4.0 and updated README and TODO</title>
<updated>2025-03-29T14:25:05+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-29T13:53:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=c30a8963a2778ce4e1bd73b5fa667a2fff3693f2'/>
<id>c30a8963a2778ce4e1bd73b5fa667a2fff3693f2</id>
<content type='text'>
* Added a test case for the known bug of out-of-place modifiers.
  Well, this is a syntactic shortcoming rather than a true bug.
  But I did run into it more than once.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Added a test case for the known bug of out-of-place modifiers.
  Well, this is a syntactic shortcoming rather than a true bug.
  But I did run into it more than once.
</pre>
</div>
</content>
</entry>
<entry>
<title>rename sample.teco_ini to fallback.teco_ini and mung it by default</title>
<updated>2025-03-03T20:35:04+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-02T22:44:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=1b907dae072f2aa93d75d8c056a9bd02555a17f8'/>
<id>1b907dae072f2aa93d75d8c056a9bd02555a17f8</id>
<content type='text'>
* After installation, SciTECO will therefore start into a more userfriendly mode
  even if the user does not create a custom ~/.teco_ini.
  It is hoped that this will scare away less of new users, who
  are not willing to read through all of the documentation.
  Still, users are warned in the absence of ~/.teco_ini.
  This warning however, might not be immediately visible, especially
  not when running gsciteco without an attached console.
  (This will change once I redo the UI and allow a number of messages
  to be queued in the message area.)
* Theoretically, you could also just extend fallback.teco_ini from ~/.teco_ini,
  but that would require installing it into $SCITECOPATH.
* Since the fallback profile will now be munged automatically
  on a wide range of systems, we set up xclip only when detecting X11
  ($DISPLAY is non-empty).
  E.g. when running under Wayland or the Linux console, you still won't
  get the clipboard registers, which is probably better than having the
  clipboard operations fail once you try to use them.
* xclip is now "suggested" on Debian/Ubuntu.
  Unfortunately we cannot pull it in only in the presence of X11.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* After installation, SciTECO will therefore start into a more userfriendly mode
  even if the user does not create a custom ~/.teco_ini.
  It is hoped that this will scare away less of new users, who
  are not willing to read through all of the documentation.
  Still, users are warned in the absence of ~/.teco_ini.
  This warning however, might not be immediately visible, especially
  not when running gsciteco without an attached console.
  (This will change once I redo the UI and allow a number of messages
  to be queued in the message area.)
* Theoretically, you could also just extend fallback.teco_ini from ~/.teco_ini,
  but that would require installing it into $SCITECOPATH.
* Since the fallback profile will now be munged automatically
  on a wide range of systems, we set up xclip only when detecting X11
  ($DISPLAY is non-empty).
  E.g. when running under Wayland or the Linux console, you still won't
  get the clipboard registers, which is probably better than having the
  clipboard operations fail once you try to use them.
* xclip is now "suggested" on Debian/Ubuntu.
  Unfortunately we cannot pull it in only in the presence of X11.
</pre>
</div>
</content>
</entry>
<entry>
<title>GTK: always scroll caret when window size changes</title>
<updated>2025-03-02T00:48:42+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-01T23:36:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=38ae2e440127137c57a2d782cecffc3ce5e19804'/>
<id>38ae2e440127137c57a2d782cecffc3ce5e19804</id>
<content type='text'>
* The old implementation would scroll only once for the file first opened and too early.
  As a result, opening via `sciteco file:number` did not always scroll to the correct position.
  Also, `?` would usually not scroll the topic into view.
* Instead, we now always scroll in all views, but only if the size allocation changed.
  This ensures, we can still scroll with the mouse wheel.
* Therefore, we have to store the current size allocation per view.
  Instead of allocating a separate heap object, I decided to subclass the Scintilla GTK class.
* Some explicit casts are still necessary since teco_view_t is typedefed
  to `struct teco_view_t`, but we cannot easily rename the GObject instance structure.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The old implementation would scroll only once for the file first opened and too early.
  As a result, opening via `sciteco file:number` did not always scroll to the correct position.
  Also, `?` would usually not scroll the topic into view.
* Instead, we now always scroll in all views, but only if the size allocation changed.
  This ensures, we can still scroll with the mouse wheel.
* Therefore, we have to store the current size allocation per view.
  Instead of allocating a separate heap object, I decided to subclass the Scintilla GTK class.
* Some explicit casts are still necessary since teco_view_t is typedefed
  to `struct teco_view_t`, but we cannot easily rename the GObject instance structure.
</pre>
</div>
</content>
</entry>
<entry>
<title>GTK: set the mouse cursor on the Scintilla view to signal business and on the popup entries</title>
<updated>2025-03-02T00:46:36+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-01T13:14:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=2e601e3c6c27de6625c9b7d5d32177141e25acf6'/>
<id>2e601e3c6c27de6625c9b7d5d32177141e25acf6</id>
<content type='text'>
* By default, use the "text" cursor - this is the default Scintilla cursor, but
  inhibited by the GtkEventBox I used to catch all input events.
* When processing input events, the cursor is changed to "wait".
  This is done with a small delay in order to avoid flickering during normal typing.
  The cursor is only changed after 100ms of activity, i.e. only when executing long loops
  or external programs.
* We use the raw GSource API since it's tricky to work with source ids if the
  source could be removed in the meantime.
* The popup entries' cursor is also changed to "pointer" (hand) to give a hint that
  it can be clicked.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* By default, use the "text" cursor - this is the default Scintilla cursor, but
  inhibited by the GtkEventBox I used to catch all input events.
* When processing input events, the cursor is changed to "wait".
  This is done with a small delay in order to avoid flickering during normal typing.
  The cursor is only changed after 100ms of activity, i.e. only when executing long loops
  or external programs.
* We use the raw GSource API since it's tricky to work with source ids if the
  source could be removed in the meantime.
* The popup entries' cursor is also changed to "pointer" (hand) to give a hint that
  it can be clicked.
</pre>
</div>
</content>
</entry>
<entry>
<title>implemented ncurses clipboard support via external processes</title>
<updated>2025-02-27T08:38:42+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-02-27T08:38:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=f421c8fcf3c47c78c666906165006969ff21429e'/>
<id>f421c8fcf3c47c78c666906165006969ff21429e</id>
<content type='text'>
* As an alternative to OSC-52, which is rarely supported by terminal emulators.
* Makes the new mouse support much more useful since you rely on good builtin
  clipboard support. You can no longer e.g. just double-click a word to copy it into
  the "primary" selection as terminal emulators do by default.
* Set $SCITECO_CLIPBOARD_SET/GET e.g. to xclip, way-copy, pbcopy or some wrapper script.
* This is currently using POSIX-specific popen() API, so it behaves a bit different
  to command execution via EC/EG.
  I am not sure if it's worth rewriting with the GSpawn-API, since it will be used
  only on POSIX anyway and a GSpawn-based implementation is likely to be a bit larger.
* Should there be some small command-line utility for interacting (esp. pasting) via OSC-52,
  built-in OSC-52 support could well be removed from SciTECO.
  Currently, I know only of https://github.com/theimpostor/osc/ and it requires
  very recent Go compilers. (I still haven't tested it. Quite possibly, pasting when run as
  a piped command is impossible.)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* As an alternative to OSC-52, which is rarely supported by terminal emulators.
* Makes the new mouse support much more useful since you rely on good builtin
  clipboard support. You can no longer e.g. just double-click a word to copy it into
  the "primary" selection as terminal emulators do by default.
* Set $SCITECO_CLIPBOARD_SET/GET e.g. to xclip, way-copy, pbcopy or some wrapper script.
* This is currently using POSIX-specific popen() API, so it behaves a bit different
  to command execution via EC/EG.
  I am not sure if it's worth rewriting with the GSpawn-API, since it will be used
  only on POSIX anyway and a GSpawn-based implementation is likely to be a bit larger.
* Should there be some small command-line utility for interacting (esp. pasting) via OSC-52,
  built-in OSC-52 support could well be removed from SciTECO.
  Currently, I know only of https://github.com/theimpostor/osc/ and it requires
  very recent Go compilers. (I still haven't tested it. Quite possibly, pasting when run as
  a piped command is impossible.)
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed rubbing out `?` (help) after editing a Q-Register</title>
<updated>2025-02-24T01:04:47+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-02-24T01:04:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=376da1ea68879229d43704ebe70874020d0e8fd6'/>
<id>376da1ea68879229d43704ebe70874020d0e8fd6</id>
<content type='text'>
* Test case: @EQa// @?/EX/ -- Rubout should return you to the Q-Register view.
* The test suite has been extended.
  Unfortunately we cannot currently directly check whether we're editing a Q-Register.
  But we add a magic number of characters to the Q-Register, that we can check afterwards.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Test case: @EQa// @?/EX/ -- Rubout should return you to the Q-Register view.
* The test suite has been extended.
  Unfortunately we cannot currently directly check whether we're editing a Q-Register.
  But we add a magic number of characters to the Q-Register, that we can check afterwards.
</pre>
</div>
</content>
</entry>
<entry>
<title>updated TODO</title>
<updated>2025-02-23T02:07:46+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-02-14T22:32:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=c667b14942c5c32d41dcb7cb63a90c39621546d4'/>
<id>c667b14942c5c32d41dcb7cb63a90c39621546d4</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>support :EF for saving a file before closing it</title>
<updated>2025-01-19T11:57:51+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-01-19T11:57:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=1a1baebf95b493bf62528ad8c00900cb789a96bd'/>
<id>1a1baebf95b493bf62528ad8c00900cb789a96bd</id>
<content type='text'>
Analoguous to :EX, but always saves the file like EW$, not only if it's dirty.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Analoguous to :EX, but always saves the file like EW$, not only if it's dirty.
</pre>
</div>
</content>
</entry>
<entry>
<title>mention the Alpine package and updated TODO</title>
<updated>2025-01-12T23:05:58+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-01-12T23:05:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=2e16a589f6876bc6520bd430ed3e51599e3d0c4a'/>
<id>2e16a589f6876bc6520bd430ed3e51599e3d0c4a</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>support +line[,column] and filename:line:column syntaxes when opening files</title>
<updated>2024-12-30T02:00:44+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-12-30T02:00:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e2eff00a9c0d89a196bb297b4958473a681ddfee'/>
<id>e2eff00a9c0d89a196bb297b4958473a681ddfee</id>
<content type='text'>
* This is done via the new opener.tes in the standard library.
* Some programs that use $EDITOR expect the +line syntax to work.
* You can copy filename:line:column directly from GCC error messages
  and filename:line from grep output.
* Since there may be safe file names beginning with "+" or containing colons,
  there needs to be a way to turn this off, especially for scripts that don't
  know anything about the filenames to open.
  This is done with "--".
  Unfortunately, the first "--", that stops parameter processing,
  is always removed from the command line and not passed down into TECO land.
  This is not a problem for stand-alone scripts,
  since the script filename is already stopping option processing, so "--"
  would get passed down.
  But when calling the profile via `sciteco -- ...`, you could prevent leading
  minus signs to cause problems but since the `--` is removed, opener.tes cannot
  use it as a hint.
  Therefore, we introduced `-S` as a new alternative to `--`, that's always passed
  down as `--` (i.e. it is equivalent to "-- --").
  In other words, `sciteco -S *` will always open exactly the specified files
  without any danger of misinterpreting certain file names.
  Should we ever switch to a custom option parsing algorithm, we might preserve
  "--" (unless after --mung) and thus get rid of "-S".
* This advanced behavior can be tweaked by the user relatively easily.
  In the easiest case, we could replace M[opener] with
  &lt;:L;R 0X.f [* @EB/^EN.f/ ]* L&gt;
  in ~/.teco_ini to completely disable the special syntax.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This is done via the new opener.tes in the standard library.
* Some programs that use $EDITOR expect the +line syntax to work.
* You can copy filename:line:column directly from GCC error messages
  and filename:line from grep output.
* Since there may be safe file names beginning with "+" or containing colons,
  there needs to be a way to turn this off, especially for scripts that don't
  know anything about the filenames to open.
  This is done with "--".
  Unfortunately, the first "--", that stops parameter processing,
  is always removed from the command line and not passed down into TECO land.
  This is not a problem for stand-alone scripts,
  since the script filename is already stopping option processing, so "--"
  would get passed down.
  But when calling the profile via `sciteco -- ...`, you could prevent leading
  minus signs to cause problems but since the `--` is removed, opener.tes cannot
  use it as a hint.
  Therefore, we introduced `-S` as a new alternative to `--`, that's always passed
  down as `--` (i.e. it is equivalent to "-- --").
  In other words, `sciteco -S *` will always open exactly the specified files
  without any danger of misinterpreting certain file names.
  Should we ever switch to a custom option parsing algorithm, we might preserve
  "--" (unless after --mung) and thus get rid of "-S".
* This advanced behavior can be tweaked by the user relatively easily.
  In the easiest case, we could replace M[opener] with
  &lt;:L;R 0X.f [* @EB/^EN.f/ ]* L&gt;
  in ~/.teco_ini to completely disable the special syntax.
</pre>
</div>
</content>
</entry>
</feed>
