<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/lib, branch master-fmsbw-ci</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>LSP: save $SCITECO_LSP and $SCITECO_LSP_ROOT as part of buffer sessions</title>
<updated>2026-08-11T19:26:38+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-08-11T19:20:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=9b904f5b7e9ea45b8ea5991f6eeb19c2f3949874'/>
<id>9b904f5b7e9ea45b8ea5991f6eeb19c2f3949874</id>
<content type='text'>
If you have projects in different languages you can set different LSPs.
The default will still come from ~/.teco_ini if you decide to set one.
The default for $SCITECO_LSP_ROOT is set by session.tes' VCS integration
based on the VCS root, but you could still overwrite it per session.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If you have projects in different languages you can set different LSPs.
The default will still come from ~/.teco_ini if you decide to set one.
The default for $SCITECO_LSP_ROOT is set by session.tes' VCS integration
based on the VCS root, but you could still overwrite it per session.
</pre>
</div>
</content>
</entry>
<entry>
<title>support lookups via language servers (LSP)</title>
<updated>2026-08-10T22:38:31+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-08-02T13:24:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=44f5bf677282308b959411c416da2b5b08db2062'/>
<id>44f5bf677282308b959411c416da2b5b08db2062</id>
<content type='text'>
* The main interface is the `FT` command.
  `FT` was an undocumented Video TECO command for etags/ctags lookups.
  I don't want to exactly copy its interface, though.
* `FT` allows looking up symbol names,
  definitions and references.
* ctags will be supported via ctags-lsp.
  LSP support is more powerful though and works without
  regenerating TAGS files all the time.
  The LSP will also allow you to customize auto-completions
  using SciTECO itself (i.e. by writing a language server
  in SciTECO).
* For multiple results, `FT$` can be used to cycle through
  results - this should mimic repeated `S$` or `N$`.
* `:FT...$` does a fuzzy search. IMHO it's not important
  to return a status integer instead. `FT` will only
  really be used in interactive mode.
* Document synchronization is supported via hooks from
  ring.c and via Scintilla notifications.
* Currently, the LSP communication is based on blocking
  GIOChannels. This means that a misbehaving hanging
  server could "lock up" the entire editor (FIXME).
  Only on ncurses you can always kill the subprocess by
  pressing CTRL+C.
  We need helper functions in spawn.c to read and write
  with interruptions.
* The textDocument/didChange notification transmits
  not only all edits, but all files' contents as well
  during initial synchronization.
  Therefore it is optimized to write and JSON-escape
  data without copying them around in memory and without
  destroying the buffer gap.
* Use $SCITECO_LSP to configure the language server.
  You can also use `tee` to capture stdin and stdout.
  Perhaps $SCITECO_LSP should be saved in .teco_session,
  so you can change it between projects?
* $SCITECO_LSP_ROOT is used to point to the project's
  root directory. session.tes will set it up automatically.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The main interface is the `FT` command.
  `FT` was an undocumented Video TECO command for etags/ctags lookups.
  I don't want to exactly copy its interface, though.
* `FT` allows looking up symbol names,
  definitions and references.
* ctags will be supported via ctags-lsp.
  LSP support is more powerful though and works without
  regenerating TAGS files all the time.
  The LSP will also allow you to customize auto-completions
  using SciTECO itself (i.e. by writing a language server
  in SciTECO).
* For multiple results, `FT$` can be used to cycle through
  results - this should mimic repeated `S$` or `N$`.
* `:FT...$` does a fuzzy search. IMHO it's not important
  to return a status integer instead. `FT` will only
  really be used in interactive mode.
* Document synchronization is supported via hooks from
  ring.c and via Scintilla notifications.
* Currently, the LSP communication is based on blocking
  GIOChannels. This means that a misbehaving hanging
  server could "lock up" the entire editor (FIXME).
  Only on ncurses you can always kill the subprocess by
  pressing CTRL+C.
  We need helper functions in spawn.c to read and write
  with interruptions.
* The textDocument/didChange notification transmits
  not only all edits, but all files' contents as well
  during initial synchronization.
  Therefore it is optimized to write and JSON-escape
  data without copying them around in memory and without
  destroying the buffer gap.
* Use $SCITECO_LSP to configure the language server.
  You can also use `tee` to capture stdin and stdout.
  Perhaps $SCITECO_LSP should be saved in .teco_session,
  so you can change it between projects?
* $SCITECO_LSP_ROOT is used to point to the project's
  root directory. session.tes will set it up automatically.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed lexer initialization if $SCITECOPATH happens to contain glob characters</title>
<updated>2026-07-24T14:15:46+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-07-24T14:15:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=378b9da1476cdcac14332b89f6286a450c4a7757'/>
<id>378b9da1476cdcac14332b89f6286a450c4a7757</id>
<content type='text'>
* Always use ^ENq instead of ^EQq in the first argument of `EN`.
* Added a "Globbing" test case - globbing was undertested anyway.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Always use ^ENq instead of ^EQq in the first argument of `EN`.
* Added a "Globbing" test case - globbing was undertested anyway.
</pre>
</div>
</content>
</entry>
<entry>
<title>XML lexer is activated for _service files and YAML for *.sls (Salt States)</title>
<updated>2026-07-10T23:25:42+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-07-10T23:25:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=064307df0c2d635b1805a0f59f694f9ec103e96a'/>
<id>064307df0c2d635b1805a0f59f694f9ec103e96a</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>support "default colors"</title>
<updated>2026-05-09T22:15:52+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-05-09T22:15:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=58a0f8def5742248bf235c7c9cd9d3efcb334751'/>
<id>58a0f8def5742248bf235c7c9cd9d3efcb334751</id>
<content type='text'>
* The terminal's default foreground and background colors
  are now used by default (`sciteco --no-profile`), so SciTECO
  integrates naturally into all terminal color schemes, even
  dark-on-bright ones.
* The default Scintilla colors use only 0x000000 (COLOR_BLACK) and 0xC0C0C0 (COLOR_WHITE)
  now.
* You can use `7EJ` to configure the default colors in color
  schemes or your profile.
  All existing color schemes had to disable default colors
  (`-1,-1,7EJ`) since they wouldn't look well otherwise.
* You may add `-1,7EJ` to ~/.teco_ini when using a terminal emulator
  with a washed-out palettized COLOR_BLACK.
  We cannot detect the terminal's default colors automatically.
* Scinterm updated to v6.0.
  We require a not-yet-upstreamed patch:
  https://github.com/orbitalquark/scinterm/pull/40
* In fact, we might decide not to support default colors at all in Scinterm,
  so this feature should be considered experimental.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The terminal's default foreground and background colors
  are now used by default (`sciteco --no-profile`), so SciTECO
  integrates naturally into all terminal color schemes, even
  dark-on-bright ones.
* The default Scintilla colors use only 0x000000 (COLOR_BLACK) and 0xC0C0C0 (COLOR_WHITE)
  now.
* You can use `7EJ` to configure the default colors in color
  schemes or your profile.
  All existing color schemes had to disable default colors
  (`-1,-1,7EJ`) since they wouldn't look well otherwise.
* You may add `-1,7EJ` to ~/.teco_ini when using a terminal emulator
  with a washed-out palettized COLOR_BLACK.
  We cannot detect the terminal's default colors automatically.
* Scinterm updated to v6.0.
  We require a not-yet-upstreamed patch:
  https://github.com/orbitalquark/scinterm/pull/40
* In fact, we might decide not to support default colors at all in Scinterm,
  so this feature should be considered experimental.
</pre>
</div>
</content>
</entry>
<entry>
<title>opener.check-recovery: don't pollute Q-register `_`</title>
<updated>2026-04-27T16:48:54+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-27T16:48:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=14b7d1fc5621c3251115ccf577beaabf8ab0eccc'/>
<id>14b7d1fc5621c3251115ccf577beaabf8ab0eccc</id>
<content type='text'>
This has been broken since v2.5.2.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This has been broken since v2.5.2.
</pre>
</div>
</content>
</entry>
<entry>
<title>Curses: support arbitrary RGB colors</title>
<updated>2026-04-26T00:00:18+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-26T00:00:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=282fa65c0d547c89eac6cd4c7e91496a280bece7'/>
<id>282fa65c0d547c89eac6cd4c7e91496a280bece7</id>
<content type='text'>
* Instead of supporting only 16 predefined RGB placeholder
  values in Scintilla messages and styles, you can now use
  arbitrary RGB values and colors are allocated via the terminal
  on the fly.
  You no longer need to call 3EJ to change the default color
  palette.
* The placeholder RGB values are still available.
  Since you will usually want exact RGB values when using
  anything outside of the range of 16 default colors
  and the RGB placeholders will not always exactly correspond
  to their RGB value, you can now call `0,3EJ` to ignore
  the default palette and allocate all colors dynamically.
* Allows for more than 16 colors on the screen simultaneously.
  Also simplifies the solarized.tes color scheme.
  Since both Scinterm and SciTECO try not to touch the 16
  default colors, you also no longer have to deal with
  restoring the palette after program termination
  (which was never reliable anyway).
* Color schemes with non-default colors (solarized.tes)
  may now be broken on TERM=linux-16color (Linux VT)
  since Scinterm will get only 8 colors, but solarized.tes
  needs 16.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Instead of supporting only 16 predefined RGB placeholder
  values in Scintilla messages and styles, you can now use
  arbitrary RGB values and colors are allocated via the terminal
  on the fly.
  You no longer need to call 3EJ to change the default color
  palette.
* The placeholder RGB values are still available.
  Since you will usually want exact RGB values when using
  anything outside of the range of 16 default colors
  and the RGB placeholders will not always exactly correspond
  to their RGB value, you can now call `0,3EJ` to ignore
  the default palette and allocate all colors dynamically.
* Allows for more than 16 colors on the screen simultaneously.
  Also simplifies the solarized.tes color scheme.
  Since both Scinterm and SciTECO try not to touch the 16
  default colors, you also no longer have to deal with
  restoring the palette after program termination
  (which was never reliable anyway).
* Color schemes with non-default colors (solarized.tes)
  may now be broken on TERM=linux-16color (Linux VT)
  since Scinterm will get only 8 colors, but solarized.tes
  needs 16.
</pre>
</div>
</content>
</entry>
<entry>
<title>Curses: fixed rendering bright/light colors on 8-color terminals</title>
<updated>2026-04-16T23:18:20+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-16T23:18:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=869de7c6270c50481499c201aa16aa5bc3a56739'/>
<id>869de7c6270c50481499c201aa16aa5bc3a56739</id>
<content type='text'>
* Scinterm was simply rendering them as black, thus effectively
  breaking the Linux and FreeBSD vts with terminal.tes.
* I was considering to render light black as white on 8-color terminals,
  so it's always readable.
  However, if you add in A_BOLD there is a good chance that the
  color will end up grey - at least it does in the virtual terminals (consoles).
* There is no need to use bright colors in the Scintilla view defaults.
  E.g. 0xFFFFF is "light white".
  However on 8-color terminals this will be rendered like white anyway.
  The new defaults are closer to what terminal.tes does.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Scinterm was simply rendering them as black, thus effectively
  breaking the Linux and FreeBSD vts with terminal.tes.
* I was considering to render light black as white on 8-color terminals,
  so it's always readable.
  However, if you add in A_BOLD there is a good chance that the
  color will end up grey - at least it does in the virtual terminals (consoles).
* There is no need to use bright colors in the Scintilla view defaults.
  E.g. 0xFFFFF is "light white".
  However on 8-color terminals this will be rendered like white anyway.
  The new defaults are closer to what terminal.tes does.
</pre>
</div>
</content>
</entry>
<entry>
<title>`^A` now accepts an optional integer to specify the message severity</title>
<updated>2026-04-14T21:19:45+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-13T23:16:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=34af154e92383161666751ca69a288c98f5cca60'/>
<id>34af154e92383161666751ca69a288c98f5cca60</id>
<content type='text'>
* I.e. you can now log warnings and errors from SciTECO code as well.
* We do not need a version of ^A accepting code points, since this is
  supported by ^T already.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* I.e. you can now log warnings and errors from SciTECO code as well.
* We do not need a version of ^A accepting code points, since this is
  supported by ^T already.
</pre>
</div>
</content>
</entry>
<entry>
<title>opener.check-recovery now checks for and warns about the presence of recovery `#files#`</title>
<updated>2026-04-13T14:44:34+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>rhaberkorn@fmsbw.de</email>
</author>
<published>2026-04-13T14:44:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=cd48ea8f00567f30d9685f96a12b8f123a121f62'/>
<id>cd48ea8f00567f30d9685f96a12b8f123a121f62</id>
<content type='text'>
* This could have been in ring.c, but in the future we may want to script
  the behavior in case recovery files are detected.
* The warnings are currently written as user messages, which looks
  ugly in interactive mode.
  Once n^A is supported, we can write them as regular warnings, though (FIXME).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* This could have been in ring.c, but in the future we may want to script
  the behavior in case recovery files are detected.
* The warnings are currently written as user messages, which looks
  ugly in interactive mode.
  Once n^A is supported, we can write them as regular warnings, though (FIXME).
</pre>
</div>
</content>
</entry>
</feed>
