<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/README, branch v2.0.0</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<entry>
<title>Nightly Builds are uploaded as a Github release now instead of artefacts</title>
<updated>2022-11-27T16:25:09+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2022-11-26T02:47:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=9c789e80407cdfe3f5f7d2feb8e77bdeb130b78a'/>
<id>9c789e80407cdfe3f5f7d2feb8e77bdeb130b78a</id>
<content type='text'>
* replace actions/upload-artifact with pyTooling/Actions/releaser
* The release URL will never change:
  https://github.com/rhaberkorn/sciteco/releases/tag/nightly
* On the downside there is now a "nightly" tag in the repo that will
  be updated to HEAD whenever a nightly build runs - but other than that it does no harm.
* Compared with artifacts, the new method has several advantages:
  * No more nightly.link Github App required
  * We can add arbitrary files into releases and no longer have to ZIP everything.
    So you can now download the Debian packages separately, the Mac OS "package" is a tar.gz
    (instead of zipped tar).
    For the Windows packages not much changes, though.
  * Files get updated in the "Nightly Builds" release even when individual jobs in the
    nightly.yml workflow fail.
    With artefacts, the entire workflow must be successful.
  * Releases are not deleted after 90 days as opposed to artefacts.
    So when my workflow breaks next time, there will still be files to download
    for a long time.
 * As a downside, the file names in the release have to be uniform and must not contain
   versions, commit hashes and dates so that uploads replace old files instead of adding
   new ones.
   Some manual cleanup could still be necessary after large packaging changes.
   This could be worked around, by uploading everything first as artefacts and updating the
   release in a separate job, but is not worth the trouble IMHO.
 * Another disadvantage is that there will be no old nightly builds to download
   (although these were not easily downloadable for end users before).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* replace actions/upload-artifact with pyTooling/Actions/releaser
* The release URL will never change:
  https://github.com/rhaberkorn/sciteco/releases/tag/nightly
* On the downside there is now a "nightly" tag in the repo that will
  be updated to HEAD whenever a nightly build runs - but other than that it does no harm.
* Compared with artifacts, the new method has several advantages:
  * No more nightly.link Github App required
  * We can add arbitrary files into releases and no longer have to ZIP everything.
    So you can now download the Debian packages separately, the Mac OS "package" is a tar.gz
    (instead of zipped tar).
    For the Windows packages not much changes, though.
  * Files get updated in the "Nightly Builds" release even when individual jobs in the
    nightly.yml workflow fail.
    With artefacts, the entire workflow must be successful.
  * Releases are not deleted after 90 days as opposed to artefacts.
    So when my workflow breaks next time, there will still be files to download
    for a long time.
 * As a downside, the file names in the release have to be uniform and must not contain
   versions, commit hashes and dates so that uploads replace old files instead of adding
   new ones.
   Some manual cleanup could still be necessary after large packaging changes.
   This could be worked around, by uploading everything first as artefacts and updating the
   release in a separate job, but is not worth the trouble IMHO.
 * Another disadvantage is that there will be no old nightly builds to download
   (although these were not easily downloadable for end users before).
</pre>
</div>
</content>
</entry>
<entry>
<title>added Mac OS nightly builds (#8)</title>
<updated>2021-10-23T22:47:50+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-10-15T12:24:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=3269a008fe146571c4f5443acb0437e7e987353f'/>
<id>3269a008fe146571c4f5443acb0437e7e987353f</id>
<content type='text'>
* Only x86_64 builds are supported for the time being.
  They have been tested on Mac OS 10.15 (Darling) and 11 (thanks to @dertuxmalwieder).
* Curses glitches remain on Mac OS as reported by @dertuxmalwieder.
  Under Darling with a Linux terminal emulator, everything looks as it should.
* We don't build AppBundles or pkg installers but instead came up with a rather
  ideosyncratic way of packaging:
  The packages are tarballs of the installation tree with all dependant libraries
  added under /usr/local/lib/sciteco - thanks to dylibbundler.
  The archives are supposed to be unpacked into the UNIX tree root (`tar -C / -xf sciteco.tar`)
  and it will be necessary to "de-quarantine" all the binaries.
  Details will be documented in the wiki:
  https://github.com/rhaberkorn/sciteco/wiki/Mac-OS-Support
* Perhaps we will also ship an installation script (TODO).
* AppBundles would have the disadvantage that they cannot be directly installed
  into $PATH. On the other hand, this would be relatively easy to do afterwards.
  An AppBundle would need certain code adaptions for Mac OS, though.
* Gtk+ builds are not yet supported as I cannot test them with "Darling".
* All Nightly Build artifact names now mention the target architecture.
* build Win32 nightly builds with windows-2019
  * May improve compatibility slightly in the future as we should
    always build our binaries on the oldest possible system.
  * Does not change anything currently since windows-2019 == windows-latest.
  * CI still uses windows-latest and may therefore one day switch to windows-2022.
 * updated README
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Only x86_64 builds are supported for the time being.
  They have been tested on Mac OS 10.15 (Darling) and 11 (thanks to @dertuxmalwieder).
* Curses glitches remain on Mac OS as reported by @dertuxmalwieder.
  Under Darling with a Linux terminal emulator, everything looks as it should.
* We don't build AppBundles or pkg installers but instead came up with a rather
  ideosyncratic way of packaging:
  The packages are tarballs of the installation tree with all dependant libraries
  added under /usr/local/lib/sciteco - thanks to dylibbundler.
  The archives are supposed to be unpacked into the UNIX tree root (`tar -C / -xf sciteco.tar`)
  and it will be necessary to "de-quarantine" all the binaries.
  Details will be documented in the wiki:
  https://github.com/rhaberkorn/sciteco/wiki/Mac-OS-Support
* Perhaps we will also ship an installation script (TODO).
* AppBundles would have the disadvantage that they cannot be directly installed
  into $PATH. On the other hand, this would be relatively easy to do afterwards.
  An AppBundle would need certain code adaptions for Mac OS, though.
* Gtk+ builds are not yet supported as I cannot test them with "Darling".
* All Nightly Build artifact names now mention the target architecture.
* build Win32 nightly builds with windows-2019
  * May improve compatibility slightly in the future as we should
    always build our binaries on the oldest possible system.
  * Does not change anything currently since windows-2019 == windows-latest.
  * CI still uses windows-latest and may therefore one day switch to windows-2022.
 * updated README
</pre>
</div>
</content>
</entry>
<entry>
<title>improved PDCurses detection</title>
<updated>2021-06-08T17:10:03+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-06-07T21:24:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=58dee5546e38a17f597bbd2da76d527eaa729282'/>
<id>58dee5546e38a17f597bbd2da76d527eaa729282</id>
<content type='text'>
* follow the current terminology:
  * PDCurses/Win32a is now called PDCursesMod and includes all other PDCurses ports as well.
    The Win32 GUI port is now called PDCurses/WinGUI.
  * PDCurses/Win32 is now called PDCurses/WinCon.
* Since PDCursesMod supports WinCon as well, we use the PDCURSES_MOD macro only
  to detect PDCursesMod API extensions.
  GUIs (detached from system console) might be available both in classic PDCurses as well
  as in PDCursesMod.
  Only PDCursesMod allows detection of the port used *at runtime* using PDC_get_version().
  We therefore introduced a --with-interface=pdcurses-gui that must be given whenever
  compiling for any kind of GUI port (including SDL on "classic" PDCurses).
* The PDCURSES macro is used to detect all PDCurses (whether classic or PDCursesMod) API extensions.
* __PDCURSES__ is used to detect PDCurses whenever API extensions are not required.
* Assume that A_UNDERLINE now works even on WinCon.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* follow the current terminology:
  * PDCurses/Win32a is now called PDCursesMod and includes all other PDCurses ports as well.
    The Win32 GUI port is now called PDCurses/WinGUI.
  * PDCurses/Win32 is now called PDCurses/WinCon.
* Since PDCursesMod supports WinCon as well, we use the PDCURSES_MOD macro only
  to detect PDCursesMod API extensions.
  GUIs (detached from system console) might be available both in classic PDCurses as well
  as in PDCursesMod.
  Only PDCursesMod allows detection of the port used *at runtime* using PDC_get_version().
  We therefore introduced a --with-interface=pdcurses-gui that must be given whenever
  compiling for any kind of GUI port (including SDL on "classic" PDCurses).
* The PDCURSES macro is used to detect all PDCurses (whether classic or PDCursesMod) API extensions.
* __PDCURSES__ is used to detect PDCurses whenever API extensions are not required.
* Assume that A_UNDERLINE now works even on WinCon.
</pre>
</div>
</content>
</entry>
<entry>
<title>added nightly builds for GTK+ 3 on Win32 (currently broken)</title>
<updated>2021-06-08T17:10:03+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-06-07T16:23:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=b6de523a77149b0262403721ede2ee57c0d3716e'/>
<id>b6de523a77149b0262403721ede2ee57c0d3716e</id>
<content type='text'>
* turns out that we need icon themes and pixbuf loaders as well
* GTK assumes an UNIX like hierarchy, so we package sciteco.exe and
  all DLLs into a bin/ subdir.
* The SciTECO icons probably shouldn't be in bin/.
  If we installed them into the hicolor icon theme, GTK might
  pick them up automatically. This would work under Windows and UNIX.
* The GTK builds are still broken.
  I do really need a real system (MSYS installation) to play around.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* turns out that we need icon themes and pixbuf loaders as well
* GTK assumes an UNIX like hierarchy, so we package sciteco.exe and
  all DLLs into a bin/ subdir.
* The SciTECO icons probably shouldn't be in bin/.
  If we installed them into the hicolor icon theme, GTK might
  pick them up automatically. This would work under Windows and UNIX.
* The GTK builds are still broken.
  I do really need a real system (MSYS installation) to play around.
</pre>
</div>
</content>
</entry>
<entry>
<title>README: added link to the new Mac OS wiki page and mention Chocolatey package.</title>
<updated>2021-06-05T14:02:28+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-06-05T13:47:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=a5733728560d300774a4322ed18fc75b5946d4de'/>
<id>a5733728560d300774a4322ed18fc75b5946d4de</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>use memory polling (--disable-malloc-replacement) on Mac OS X</title>
<updated>2021-06-05T00:31:39+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-06-04T15:16:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=9fa78ca99e32c0f27b6071cc2ddffdf43cb9b9d4'/>
<id>9fa78ca99e32c0f27b6071cc2ddffdf43cb9b9d4</id>
<content type='text'>
* I could not get malloc replacement via dlmalloc to work.
  This does not work like on Linux by overwriting weak malloc() functions.
  It should theoretically be possible to overwrite the default malloc zone
  but I could not properly debug this since I can only build for Mac OS
  via CI.
* memory polling seems to work though - test suite runs through
  and it includes memory limiting test cases.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* I could not get malloc replacement via dlmalloc to work.
  This does not work like on Linux by overwriting weak malloc() functions.
  It should theoretically be possible to overwrite the default malloc zone
  but I could not properly debug this since I can only build for Mac OS
  via CI.
* memory polling seems to work though - test suite runs through
  and it includes memory limiting test cases.
</pre>
</div>
</content>
</entry>
<entry>
<title>Continuous Integration artifacts are now built only once a day (nightly builds) and include Gtk+ versions</title>
<updated>2021-05-31T22:44:49+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-05-31T22:44:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=f1b17f7d2bf03ed798520c3a5f322c0d79f3787c'/>
<id>f1b17f7d2bf03ed798520c3a5f322c0d79f3787c</id>
<content type='text'>
* The CI tests are unchanged. The workflow file has been renamed to ci.yml, though.
* Nightly builds are described by nightly.yml and are built at 4:13.
* Nightly Ubuntu package builds now include the Gtk+ 3 packages.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* The CI tests are unchanged. The workflow file has been renamed to ci.yml, though.
* Nightly builds are described by nightly.yml and are built at 4:13.
* Nightly Ubuntu package builds now include the Gtk+ 3 packages.
</pre>
</div>
</content>
</entry>
<entry>
<title>cosmetic changes to continuous-integration.yml and mention availability of nightly builds in README</title>
<updated>2021-05-30T18:46:03+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-05-30T18:46:03+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=d0c8cb91b089e735fb288cf0fd44afb20e08a89c'/>
<id>d0c8cb91b089e735fb288cf0fd44afb20e08a89c</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>continuous-integration.yml: fixed "apt-get install" and show badge in README</title>
<updated>2021-05-30T12:34:10+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-05-30T12:27:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=f6a6d3d43c7d0c5b5a56ea3f32458b07174686a5'/>
<id>f6a6d3d43c7d0c5b5a56ea3f32458b07174686a5</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>THE GREAT CEEIFICATION EVENT</title>
<updated>2021-05-30T01:12:56+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2021-05-30T00:38:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=432ad24e382681f1c13b07e8486e91063dd96e2e'/>
<id>432ad24e382681f1c13b07e8486e91063dd96e2e</id>
<content type='text'>
This is a total conversion of SciTECO to plain C (GNU C11).
The chance was taken to improve a lot of internal datastructures,
fix fundamental bugs and lay the foundations of future features.
The GTK user interface is now in an useable state!
All changes have been squashed together.

The language itself has almost not changed at all, except for:

* Detection of string terminators (usually Escape) now takes
  the string building characters into account.
  A string is only terminated outside of string building characters.
  In other words, you can now for instance write
  I^EQ[Hello$world]$
  This removes one of the last bits of shellisms which is out of
  place in SciTECO where no tokenization/lexing is performed.
  Consequently, the current termination character can also be
  escaped using ^Q/^R.
  This is used by auto completions to make sure that strings
  are inserted verbatim and without unwanted sideeffects.
* All strings can now safely contain null-characters
  (see also: 8-bit cleanliness).
  The null-character itself (^@) is not (yet) a valid SciTECO
  command, though.

An incomplete list of changes:

* We got rid of the BSD headers for RB trees and lists/queues.
  The problem with them was that they used a form of metaprogramming
  only to gain a bit of type safety. It also resulted in less
  readble code. This was a C++ desease.
  The new code avoids metaprogramming only to gain type safety.
  The BSD tree.h has been replaced by rb3ptr by Jens Stimpfle
  (https://github.com/jstimpfle/rb3ptr).
  This implementation is also more memory efficient than BSD's.
  The BSD list.h and queue.h has been replaced with a custom
  src/list.h.
* Fixed crashes, performance issues and compatibility issues with
  the Gtk 3 User Interface.
  It is now more or less ready for general use.
  The GDK lock is no longer used to avoid using deprecated functions.
  On the downside, the new implementation (driving the Gtk event loop
  stepwise) is even slower than the old one.
  A few glitches remain (see TODO), but it is hoped that they will
  be resolved by the Scintilla update which will be performed soon.
* A lot of program units have been split up, so they are shorter
  and easier to maintain: core-commands.c, qreg-commands.c,
  goto-commands.c, file-utils.h.
* Parser states are simply structs of callbacks now.
  They still use a kind of polymorphy using a preprocessor trick.
  TECO_DEFINE_STATE() takes an initializer list that will be
  merged with the default list of field initializers.
  To "subclass" states, you can simply define new macros that add
  initializers to existing macros.
* Parsers no longer have a "transitions" table but the input_cb()
  may use switch-case statements.
  There are also teco_machine_main_transition_t now which can
  be used to implement simple transitions. Additionally, you
  can specify functions to execute during transitions.
  This largely avoids long switch-case-statements.
* Parsers are embeddable/reusable now, at least in parse-only mode.
  This does not currently bring any advantages but may later
  be used to write a Scintilla lexer for TECO syntax highlighting.
  Once parsers are fully embeddable, it will also be possible
  to run TECO macros in a kind of coroutine which would allow
  them to process string arguments in real time.
* undo.[ch] still uses metaprogramming extensively but via
  the C preprocessor of course. On the downside, most undo
  token generators must be initiated explicitly (theoretically
  we could have used embedded functions / trampolines to
  instantiate automatically but this has turned out to be
  dangereous).
  There is a TECO_DEFINE_UNDO_CALL() to generate closures for
  arbitrary functions now (ie. to call an arbitrary function
  at undo-time). This simplified a lot of code and is much
  shorter than manually pushing undo tokens in many cases.
* Instead of the ridiculous C++ Curiously Recurring Template
  Pattern to achieve static polymorphy for user interface
  implementations, we now simply declare all functions to
  implement in interface.h and link in the implementations.
  This is possible since we no longer hace to define
  interface subclasses (all state is static variables in
  the interface's *.c files).
* Headers are now significantly shorter than in C++ since
  we can often hide more of our "class" implementations.
* Memory counting is based on dlmalloc for most platforms now.
  Unfortunately, there is no malloc implementation that
  provides an efficient constant-time memory counter that
  is guaranteed to decrease when freeing memory.
  But since we use a defined malloc implementation now,
  malloc_usable_size() can be used safely for tracking memory use.
  malloc() replacement is very tricky on Windows, so we
  use a poll thread on Windows. This can also be enabled
  on other supported platforms using --disable-malloc-replacement.
  All in all, I'm still not pleased with the state of memory
  limiting. It is a mess.
* Error handling uses GError now. This has the advantage that
  the GError codes can be reused once we support error catching
  in the SciTECO language.
* Added a few more test suite cases.
* Haiku is no longer supported as builds are instable and
  I did not manage to debug them - quite possibly Haiku bugs
  were responsible.
* Glib v2.44 or later are now required.
  The GTK UI requires Gtk+ v3.12 or later now.
  The GtkFlowBox fallback and sciteco-wrapper workaround are
  no longer required.
* We now extensively use the GCC/Clang-specific g_auto
  feature (automatic deallocations when leaving the current
  code block).
* Updated copyright to 2021.
  SciTECO has been in continuous development, even though there
  have been no commits since 2018.
* Since these changes are so significant, the target release has
  been set to v2.0.
  It is planned that beginning with v3.0, the language will be
  kept stable.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This is a total conversion of SciTECO to plain C (GNU C11).
The chance was taken to improve a lot of internal datastructures,
fix fundamental bugs and lay the foundations of future features.
The GTK user interface is now in an useable state!
All changes have been squashed together.

The language itself has almost not changed at all, except for:

* Detection of string terminators (usually Escape) now takes
  the string building characters into account.
  A string is only terminated outside of string building characters.
  In other words, you can now for instance write
  I^EQ[Hello$world]$
  This removes one of the last bits of shellisms which is out of
  place in SciTECO where no tokenization/lexing is performed.
  Consequently, the current termination character can also be
  escaped using ^Q/^R.
  This is used by auto completions to make sure that strings
  are inserted verbatim and without unwanted sideeffects.
* All strings can now safely contain null-characters
  (see also: 8-bit cleanliness).
  The null-character itself (^@) is not (yet) a valid SciTECO
  command, though.

An incomplete list of changes:

* We got rid of the BSD headers for RB trees and lists/queues.
  The problem with them was that they used a form of metaprogramming
  only to gain a bit of type safety. It also resulted in less
  readble code. This was a C++ desease.
  The new code avoids metaprogramming only to gain type safety.
  The BSD tree.h has been replaced by rb3ptr by Jens Stimpfle
  (https://github.com/jstimpfle/rb3ptr).
  This implementation is also more memory efficient than BSD's.
  The BSD list.h and queue.h has been replaced with a custom
  src/list.h.
* Fixed crashes, performance issues and compatibility issues with
  the Gtk 3 User Interface.
  It is now more or less ready for general use.
  The GDK lock is no longer used to avoid using deprecated functions.
  On the downside, the new implementation (driving the Gtk event loop
  stepwise) is even slower than the old one.
  A few glitches remain (see TODO), but it is hoped that they will
  be resolved by the Scintilla update which will be performed soon.
* A lot of program units have been split up, so they are shorter
  and easier to maintain: core-commands.c, qreg-commands.c,
  goto-commands.c, file-utils.h.
* Parser states are simply structs of callbacks now.
  They still use a kind of polymorphy using a preprocessor trick.
  TECO_DEFINE_STATE() takes an initializer list that will be
  merged with the default list of field initializers.
  To "subclass" states, you can simply define new macros that add
  initializers to existing macros.
* Parsers no longer have a "transitions" table but the input_cb()
  may use switch-case statements.
  There are also teco_machine_main_transition_t now which can
  be used to implement simple transitions. Additionally, you
  can specify functions to execute during transitions.
  This largely avoids long switch-case-statements.
* Parsers are embeddable/reusable now, at least in parse-only mode.
  This does not currently bring any advantages but may later
  be used to write a Scintilla lexer for TECO syntax highlighting.
  Once parsers are fully embeddable, it will also be possible
  to run TECO macros in a kind of coroutine which would allow
  them to process string arguments in real time.
* undo.[ch] still uses metaprogramming extensively but via
  the C preprocessor of course. On the downside, most undo
  token generators must be initiated explicitly (theoretically
  we could have used embedded functions / trampolines to
  instantiate automatically but this has turned out to be
  dangereous).
  There is a TECO_DEFINE_UNDO_CALL() to generate closures for
  arbitrary functions now (ie. to call an arbitrary function
  at undo-time). This simplified a lot of code and is much
  shorter than manually pushing undo tokens in many cases.
* Instead of the ridiculous C++ Curiously Recurring Template
  Pattern to achieve static polymorphy for user interface
  implementations, we now simply declare all functions to
  implement in interface.h and link in the implementations.
  This is possible since we no longer hace to define
  interface subclasses (all state is static variables in
  the interface's *.c files).
* Headers are now significantly shorter than in C++ since
  we can often hide more of our "class" implementations.
* Memory counting is based on dlmalloc for most platforms now.
  Unfortunately, there is no malloc implementation that
  provides an efficient constant-time memory counter that
  is guaranteed to decrease when freeing memory.
  But since we use a defined malloc implementation now,
  malloc_usable_size() can be used safely for tracking memory use.
  malloc() replacement is very tricky on Windows, so we
  use a poll thread on Windows. This can also be enabled
  on other supported platforms using --disable-malloc-replacement.
  All in all, I'm still not pleased with the state of memory
  limiting. It is a mess.
* Error handling uses GError now. This has the advantage that
  the GError codes can be reused once we support error catching
  in the SciTECO language.
* Added a few more test suite cases.
* Haiku is no longer supported as builds are instable and
  I did not manage to debug them - quite possibly Haiku bugs
  were responsible.
* Glib v2.44 or later are now required.
  The GTK UI requires Gtk+ v3.12 or later now.
  The GtkFlowBox fallback and sciteco-wrapper workaround are
  no longer required.
* We now extensively use the GCC/Clang-specific g_auto
  feature (automatic deallocations when leaving the current
  code block).
* Updated copyright to 2021.
  SciTECO has been in continuous development, even though there
  have been no commits since 2018.
* Since these changes are so significant, the target release has
  been set to v2.0.
  It is planned that beginning with v3.0, the language will be
  kept stable.
</pre>
</div>
</content>
</entry>
</feed>
