<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/lib/lexers, branch v2.4.0</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>added CSS lexer configuration</title>
<updated>2025-04-18T18:51:27+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-18T18:51:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=3cf370be02322cb0688af9f5465c251b379283a1'/>
<id>3cf370be02322cb0688af9f5465c251b379283a1</id>
<content type='text'>
Especially useful since Gtk users are supposed to edit ~/.teco_css.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Especially useful since Gtk users are supposed to edit ~/.teco_css.
</pre>
</div>
</content>
</entry>
<entry>
<title>Gtk/win32: fixed fonts and therefore pango warnings on startup (closes #7)</title>
<updated>2025-04-18T18:27:00+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-18T18:27:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=91fa1656600a52eddf650ea550e7cbd69d72903e'/>
<id>91fa1656600a52eddf650ea550e7cbd69d72903e</id>
<content type='text'>
* The default womanpage font is the abstract "Serif" now, so that should be
  more portable. "Times" wasn't found on Windows.
* Win32 distributions include a custom .teco_css now, which
  removes the small-caps font attribute from the type label.
  The default Gtk theme on Windows references the "Segoe UI" font
  and it doesn't have a small-caps variant.
  In fact no default Windows font appears to have one.
* We could add a custom .teco_ini to win32 distributions as well,
  but there is currently no need for it.
* Do not distribute the /win32 files. They are used only for building
  Win32/64 packages. There is no point in distributing them in the tarball if
  the /debian and /freebsd directories aren't distributed as well.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The default womanpage font is the abstract "Serif" now, so that should be
  more portable. "Times" wasn't found on Windows.
* Win32 distributions include a custom .teco_css now, which
  removes the small-caps font attribute from the type label.
  The default Gtk theme on Windows references the "Segoe UI" font
  and it doesn't have a small-caps variant.
  In fact no default Windows font appears to have one.
* We could add a custom .teco_ini to win32 distributions as well,
  but there is currently no need for it.
* Do not distribute the /win32 files. They are used only for building
  Win32/64 packages. There is no point in distributing them in the tarball if
  the /debian and /freebsd directories aren't distributed as well.
</pre>
</div>
</content>
</entry>
<entry>
<title>added SQL lexer configuration</title>
<updated>2025-04-09T15:31:31+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-09T15:31:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=7d29ae8b7175bfb884d43225373ff0bae467c974'/>
<id>7d29ae8b7175bfb884d43225373ff0bae467c974</id>
<content type='text'>
* Unfortunately, the Lexilla lexer does not recognize PostgreSQL multiline
  strings between $$...$$.
* All of the other SQL variants, that Scite supports, are skipped for the time
  being. They'd probably have to be separate SciTECO lexer configs anyway.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Unfortunately, the Lexilla lexer does not recognize PostgreSQL multiline
  strings between $$...$$.
* All of the other SQL variants, that Scite supports, are skipped for the time
  being. They'd probably have to be separate SciTECO lexer configs anyway.
</pre>
</div>
</content>
</entry>
<entry>
<title>improved the "asm" (x86 assembly) lexer</title>
<updated>2025-04-02T23:28:30+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-04-02T23:28:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=d6aaaab12d9e44dba4b0833efc879d2792712f0f'/>
<id>d6aaaab12d9e44dba4b0833efc879d2792712f0f</id>
<content type='text'>
There are still some glitches with non-mainstream assemblers like A86, though.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are still some glitches with non-mainstream assemblers like A86, though.
</pre>
</div>
</content>
</entry>
<entry>
<title>the ES command (send Scintilla message) now supports passing both wParam and lParam as null-terminated strings</title>
<updated>2025-03-23T15:42:07+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-23T15:31:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=9e101ec36e0bf45f294f63015e0352d1d08d641d'/>
<id>9e101ec36e0bf45f294f63015e0352d1d08d641d</id>
<content type='text'>
* Being able to embed null bytes into the lParam string is
  practically useless - there aren't any messages where this is useful
  and where there are no native SciTECO counterparts - so this case is now catched
  and the null-byte separates wParam from lParam.
* wParam can be the empty string, but it is not supported to pass wParam as a
  string and lParam as the empty string.
  If the second string argument ends in ^@, lParam is popped from the stack instead.
* This is a temporary workaround until we can properly parse the Scintilla.iface and
  generate more elegant per-message wrappers.
* It in particular unlocks the SCI_SETREPRESENTATION and SCI_SETPROPERTY messages.
  The former allows us to write a special hex-editor macro which sets hexadecimal
  character representations, while the latter allows you to set lexer properties.
* The C-based lexers ("cpp" in Lexilla) can now take preprocessor definitions into account.
  This is disabled by default, unless you set lexer.c.defines before opening a file.
  You can also set it interactively and re-set the lexer. For instance:
  ^U[lexer.c.defines]NDEBUG$ M[lexer.set.c]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Being able to embed null bytes into the lParam string is
  practically useless - there aren't any messages where this is useful
  and where there are no native SciTECO counterparts - so this case is now catched
  and the null-byte separates wParam from lParam.
* wParam can be the empty string, but it is not supported to pass wParam as a
  string and lParam as the empty string.
  If the second string argument ends in ^@, lParam is popped from the stack instead.
* This is a temporary workaround until we can properly parse the Scintilla.iface and
  generate more elegant per-message wrappers.
* It in particular unlocks the SCI_SETREPRESENTATION and SCI_SETPROPERTY messages.
  The former allows us to write a special hex-editor macro which sets hexadecimal
  character representations, while the latter allows you to set lexer properties.
* The C-based lexers ("cpp" in Lexilla) can now take preprocessor definitions into account.
  This is disabled by default, unless you set lexer.c.defines before opening a file.
  You can also set it interactively and re-set the lexer. For instance:
  ^U[lexer.c.defines]NDEBUG$ M[lexer.set.c]
</pre>
</div>
</content>
</entry>
<entry>
<title>sciteco lexer: enable 2-char soft tabs by default</title>
<updated>2025-03-12T11:06:58+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-12T11:06:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=cefe7e65281a34c20da7288618d1df11d3b9db28'/>
<id>cefe7e65281a34c20da7288618d1df11d3b9db28</id>
<content type='text'>
* You practically never want to indent in SciTECO code with hard tabs, as the hard tab is
  an insertion command.
* 2-char soft tabs are the convention in SciTECO's included macros.
* Fixes the M#it macro among other things.
* If you do want to insert an insertion-with-tab command (ASCII 9), you almost always will
  want to type it ^I instead.
  Real ASCII 9s should consequently be highlighted, ie. there should be a character representation.
  Unfortunately, character representations are currently set in C code and cannot be changed via &lt;ES&gt;.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* You practically never want to indent in SciTECO code with hard tabs, as the hard tab is
  an insertion command.
* 2-char soft tabs are the convention in SciTECO's included macros.
* Fixes the M#it macro among other things.
* If you do want to insert an insertion-with-tab command (ASCII 9), you almost always will
  want to type it ^I instead.
  Real ASCII 9s should consequently be highlighted, ie. there should be a character representation.
  Unfortunately, character representations are currently set in C code and cannot be changed via &lt;ES&gt;.
</pre>
</div>
</content>
</entry>
<entry>
<title>Asciidoc, Markdown and Git lexers: enable word wrapping by default</title>
<updated>2025-03-08T19:45:42+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-08T19:45:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=edad78b3a1d2403fb499ebd0f99b1a962a447d1a'/>
<id>edad78b3a1d2403fb499ebd0f99b1a962a447d1a</id>
<content type='text'>
These are all more or less plain text formats.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
These are all more or less plain text formats.
</pre>
</div>
</content>
</entry>
<entry>
<title>added "email" lexer for writing mails</title>
<updated>2025-03-08T19:03:48+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2025-03-08T19:03:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=bdf35b89fe8d653847ab077d4183b71feebd48d2'/>
<id>bdf35b89fe8d653847ab077d4183b71feebd48d2</id>
<content type='text'>
* Highlights both 1st level and 2nd level quotes and signatures.
* This also sets the edge to 78 columns, as is recommended for email and
  enables word wrapping.
  The edge mode is not set, since it kind of looks ugly in Scinterm.
* Helps when using SciTECO as the email editor for instance in the
  Aerc mail client.
* Unfortunately, we cannot set up Scintilla to automatically break words
  after 78 columns (or perhaps that's a good thing).
  You can use the M#rf reformat-paragraph macro to reflow paragraphs
  before sending the mail.
  This will take the edge column into account even if no edge mode is set.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Highlights both 1st level and 2nd level quotes and signatures.
* This also sets the edge to 78 columns, as is recommended for email and
  enables word wrapping.
  The edge mode is not set, since it kind of looks ugly in Scinterm.
* Helps when using SciTECO as the email editor for instance in the
  Aerc mail client.
* Unfortunately, we cannot set up Scintilla to automatically break words
  after 78 columns (or perhaps that's a good thing).
  You can use the M#rf reformat-paragraph macro to reflow paragraphs
  before sending the mail.
  This will take the edge column into account even if no edge mode is set.
</pre>
</div>
</content>
</entry>
<entry>
<title>introduced true block and EOL comments</title>
<updated>2024-12-24T10:29:32+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-12-24T10:29:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=ef897b418a4487196e1dbc18a97046f8f0aea2e8'/>
<id>ef897b418a4487196e1dbc18a97046f8f0aea2e8</id>
<content type='text'>
* The previous convention of !* ... *! are now true block comments,
  i.e. they are parsed faster, don't spam the goto table and allow
  embedding of exclamation marks - only "*!" terminates the comment.
* It is therefore now forbidden to have goto labels beginning with "*".
* Also support "!!" to introduce EOL comments (like C++'s //).
  This disallows empty labels, but they weren't useful anyway.
  This is the shortest way to begin a comment.
* All comment labels have been converted to true comments, to ensure
  that syntax highlighting works correctly.
  EOL comments are used for single line commented-out code, since it's
  easiest to uncomment - you don't have to jump to the line end.
  This is a pure convention / coding style.
  Other people might do it differently.
* It's of course still possible to abuse goto labels as comments
  as TECO did for ages.
* In lexing / syntax highlighting, labels and comments are highlighted differently.
* When syntax highlighting, a single "!" will first be highlighted as a label
  since it's not yet unambiguous. Once you type the second character (* or !),
  the first character is retroactively styled as a comment as well.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The previous convention of !* ... *! are now true block comments,
  i.e. they are parsed faster, don't spam the goto table and allow
  embedding of exclamation marks - only "*!" terminates the comment.
* It is therefore now forbidden to have goto labels beginning with "*".
* Also support "!!" to introduce EOL comments (like C++'s //).
  This disallows empty labels, but they weren't useful anyway.
  This is the shortest way to begin a comment.
* All comment labels have been converted to true comments, to ensure
  that syntax highlighting works correctly.
  EOL comments are used for single line commented-out code, since it's
  easiest to uncomment - you don't have to jump to the line end.
  This is a pure convention / coding style.
  Other people might do it differently.
* It's of course still possible to abuse goto labels as comments
  as TECO did for ages.
* In lexing / syntax highlighting, labels and comments are highlighted differently.
* When syntax highlighting, a single "!" will first be highlighted as a label
  since it's not yet unambiguous. Once you type the second character (* or !),
  the first character is retroactively styled as a comment as well.
</pre>
</div>
</content>
</entry>
<entry>
<title>update sciteco.tes: this again highlights commands, but not Q-Register names</title>
<updated>2024-12-13T21:23:47+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2024-12-13T21:23:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=a673abe372df0a112e075737640dd3786587f870'/>
<id>a673abe372df0a112e075737640dd3786587f870</id>
<content type='text'>
It's a bit easier on the eyes.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It's a bit easier on the eyes.
</pre>
</div>
</content>
</entry>
</feed>
