<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src/spawn.cpp, branch v2.5.2</title>
<subtitle>Scintilla-based Text Editor and COrrector</subtitle>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/'/>
<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>
<entry>
<title>fixed and optimized piping very large buffers via EC/EG</title>
<updated>2017-03-23T08:53:02+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2017-03-23T08:02:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=4038aa23ab80bf52e98ffe69442ccd5e0cf79a89'/>
<id>4038aa23ab80bf52e98ffe69442ccd5e0cf79a89</id>
<content type='text'>
 * test case: HECcat$ on a large buffer (&gt;= 64kb)
   truncates the buffer or repeats its beginning
 * it turns out that the incremental writing to the process' stdin
   was broken. We were always writing data from the beginning of the buffer
   which fails if the stdin watcher must be activated more than once.
 * Also, EOLWriter::convert() can validly return 0, even if bytes have
   been written on the data sink, so this value cannot be used to
   check whether the process has closed its stdin.
   We now make sure that the entire buffer range is written to stdin.
 * Piping large buffers no longer removes the buffer gap.
   This makes little difference when filtering via EC since
   it will change the buffer gap anyway.
   Can make a huge difference when not touching the buffer, though
   (e.g. HEGAcat$).
 * I did not add a test suite case since that requires
   a very large test file and it cannot be easily generated automatically.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * test case: HECcat$ on a large buffer (&gt;= 64kb)
   truncates the buffer or repeats its beginning
 * it turns out that the incremental writing to the process' stdin
   was broken. We were always writing data from the beginning of the buffer
   which fails if the stdin watcher must be activated more than once.
 * Also, EOLWriter::convert() can validly return 0, even if bytes have
   been written on the data sink, so this value cannot be used to
   check whether the process has closed its stdin.
   We now make sure that the entire buffer range is written to stdin.
 * Piping large buffers no longer removes the buffer gap.
   This makes little difference when filtering via EC since
   it will change the buffer gap anyway.
   Can make a huge difference when not touching the buffer, though
   (e.g. HEGAcat$).
 * I did not add a test suite case since that requires
   a very large test file and it cannot be easily generated automatically.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed Q-Reg autocompletion for `Q` command</title>
<updated>2017-03-18T20:52:22+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2017-03-18T20:41:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=5069c3b800a5806ef132d187c4ec93d037d55ad2'/>
<id>5069c3b800a5806ef132d187c4ec93d037d55ad2</id>
<content type='text'>
 * StateQueryQReg is now derived from StateExpectQReg
   whose semantics have been changed slightly.
 * The alternative would have been another common base class for both
   StateQueryQReg and StateExpectQReg.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * StateQueryQReg is now derived from StateExpectQReg
   whose semantics have been changed slightly.
 * The alternative would have been another common base class for both
   StateQueryQReg and StateExpectQReg.
</pre>
</div>
</content>
</entry>
<entry>
<title>updated copyright to 2017</title>
<updated>2017-03-03T14:32:57+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2017-03-03T14:32:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=0bbcd7652a948424156968298e4d2f27b998cfe2'/>
<id>0bbcd7652a948424156968298e4d2f27b998cfe2</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>the manual generator (generator-docs.tes) has been cleaned up and is now called tedoc.tes</title>
<updated>2016-11-18T06:25:00+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-11-16T15:30:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=be39ab9fdbaba118ece1dcc3e064c8452fcdd277'/>
<id>be39ab9fdbaba118ece1dcc3e064c8452fcdd277</id>
<content type='text'>
 * some code simplifications
 * it now supports command line arguments via getopt.tes.
 * the -C flag enabled C/C++ mode.
   By default tedoc parses SciTECO code which means it can be used
   to document macro packages as well.
 * Therefore it is installed as a separate tool now.
   It may be used as a Groff preprocessor for third-party macro
   authors to generate (wo)man pages.
 * there's a man page tedoc.tes(1)
 * The troff placeholder macro is now called ".TEDOC".
 * Help topics can now be specified after the starting comment /*$ or !*$.
   Topics have been defined for all built-in commands.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * some code simplifications
 * it now supports command line arguments via getopt.tes.
 * the -C flag enabled C/C++ mode.
   By default tedoc parses SciTECO code which means it can be used
   to document macro packages as well.
 * Therefore it is installed as a separate tool now.
   It may be used as a Groff preprocessor for third-party macro
   authors to generate (wo)man pages.
 * there's a man page tedoc.tes(1)
 * The troff placeholder macro is now called ".TEDOC".
 * Help topics can now be specified after the starting comment /*$ or !*$.
   Topics have been defined for all built-in commands.
</pre>
</div>
</content>
</entry>
<entry>
<title>Integrated clipboard support</title>
<updated>2016-08-19T01:29:11+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-08-16T03:04:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=61ff6e97c57f62ee3ad4ffc2166e433bc060e7cb'/>
<id>61ff6e97c57f62ee3ad4ffc2166e433bc060e7cb</id>
<content type='text'>
 * mapped to different registers beginning with "~"
 * on supported platforms accessing the clipboard is as easy as
   X~ or G~.
   Naturally this also allows clipboards to be pasted in
   string arguments/insertions (^EQ~).
 * Currently, Gtk+, PDCurses and ncurses/XTerm are supported.
   For XTerm clipboard support, users must set 0,256ED to enable
   it since we cannot check for XTerm window ops programmatically
   (at least without libX11).
 * When clipboard regs exist, the clipboard can also be deemed functional.
   This allows macros to fall back to xclip(1) if necessary.
 * EOL handling has been moved into a new file eol.c and eol.h.
   EOL translation no longer depends on GIOChannels but can be
   memory-backed as well.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * mapped to different registers beginning with "~"
 * on supported platforms accessing the clipboard is as easy as
   X~ or G~.
   Naturally this also allows clipboards to be pasted in
   string arguments/insertions (^EQ~).
 * Currently, Gtk+, PDCurses and ncurses/XTerm are supported.
   For XTerm clipboard support, users must set 0,256ED to enable
   it since we cannot check for XTerm window ops programmatically
   (at least without libX11).
 * When clipboard regs exist, the clipboard can also be deemed functional.
   This allows macros to fall back to xclip(1) if necessary.
 * EOL handling has been moved into a new file eol.c and eol.h.
   EOL translation no longer depends on GIOChannels but can be
   memory-backed as well.
</pre>
</div>
</content>
</entry>
<entry>
<title>added ^E@ string building character</title>
<updated>2016-06-04T19:01:53+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-06-04T19:01:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=16e9b0dc459f3ac198495127498b2255eb94c1ce'/>
<id>16e9b0dc459f3ac198495127498b2255eb94c1ce</id>
<content type='text'>
 * allows expansion of Q-Register contents with UNIX shell quoting
 * This especially improves the usefulness of the EC/EG commands as
   we can reliably determine that a TECO string (ie. Q-Register)
   will end up as a single argument to the spawned process.
   A previous workaround was to enclose ^EQ in quotes, but it does
   not work e.g. if the register contains the wrong kind of quotes or
   other magic shell characters.
 * NOTE: In order to be absolutely sure about the runtime behaviour of
   EC plus ^E@, you will have to enable UNIX98 shell emulation in portable
   macros.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * allows expansion of Q-Register contents with UNIX shell quoting
 * This especially improves the usefulness of the EC/EG commands as
   we can reliably determine that a TECO string (ie. Q-Register)
   will end up as a single argument to the spawned process.
   A previous workaround was to enclose ^EQ in quotes, but it does
   not work e.g. if the register contains the wrong kind of quotes or
   other magic shell characters.
 * NOTE: In order to be absolutely sure about the runtime behaviour of
   EC plus ^E@, you will have to enable UNIX98 shell emulation in portable
   macros.
</pre>
</div>
</content>
</entry>
<entry>
<title>EG and EC use $SHELL and $COMSPEC as the default command interpreters now</title>
<updated>2016-02-24T04:04:15+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-02-24T04:04:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=39124fd2ad6a3e0bf51d4b7c91fafef6108eacd5'/>
<id>39124fd2ad6a3e0bf51d4b7c91fafef6108eacd5</id>
<content type='text'>
 * The default command interpreter will thus be inherited from
   the operating system. In the case of UNIX from the user's
   passwd entry.
   E.g. if bash is used, bash extensions can be used immediately
   if flag 128 is not set in the ED flags.
 * On DOS-like systems there are also alternative interpreters
   (e.g. 4NT, 4OS2) that are configurable now.
 * At least on UNIX with $SHELL it is not guaranteed that
   the interpreter supports the standard command line arguments
   like "-c". If they don't, this will cause problems with EC.
   Since $SHELL is mapped to a Q-Register, it can however
   always be easily customized for SciTECO sessions in the
   user's .teco_ini.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * The default command interpreter will thus be inherited from
   the operating system. In the case of UNIX from the user's
   passwd entry.
   E.g. if bash is used, bash extensions can be used immediately
   if flag 128 is not set in the ED flags.
 * On DOS-like systems there are also alternative interpreters
   (e.g. 4NT, 4OS2) that are configurable now.
 * At least on UNIX with $SHELL it is not guaranteed that
   the interpreter supports the standard command line arguments
   like "-c". If they don't, this will cause problems with EC.
   Since $SHELL is mapped to a Q-Register, it can however
   always be easily customized for SciTECO sessions in the
   user's .teco_ini.
</pre>
</div>
</content>
</entry>
<entry>
<title>updated copyright to 2016</title>
<updated>2016-01-28T01:45:18+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-01-28T01:25:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e3818dae4b4a5fa2af9c982a0b3a3cf4d15cb373'/>
<id>e3818dae4b4a5fa2af9c982a0b3a3cf4d15cb373</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>added full Haiku OS support (non x86_gcc2)</title>
<updated>2015-07-28T09:18:44+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2015-07-27T18:31:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=c3f7aa7252ad9adb51cef1e35f566883ef953aad'/>
<id>c3f7aa7252ad9adb51cef1e35f566883ef953aad</id>
<content type='text'>
 * Haiku can be handled like UNIX in most respects
   since it is POSIX compliant, has a UNIX-like terminal
   emulator and uses ncurses.
 * still the Glib platform macro is G_OS_HAIKU instead of
   G_OS_UNIX, so the preprocessor conditionals had to be adapted.
 * the only functional difference between a Haiku and UNIX build
   is the default SCITECOCONFIG path.
   We use the config path returned by Glib instead of $HOME,
   so .teco_ini will be in ~/config/settings on Haiku.
   Other UNIX ports appear to use the same conventions.
 * Some Haiku-specific restrictions still apply:
   * Haiku's terminal is xterm-compatible, but only supports
     8 colors. Therefore only the terminal.tes color scheme
     can be used and the terminal must be set up to
     "Use bright instead of bold text".
   * The terminal has artifacts. This appears to be a Haiku
     bug and affects other curses applications as well.
   * GTK is yet unsupported on Haiku, so there may never be
     a GUI port (unless someone writes a QT GUI for SciTECO).
   * SciTECO cannot be built with the legacy gcc2 used for
     BeOS compatibility on Haiku. This would require too many
     changes for an obsolete platform.
     BeOS and the x86_gcc2 platform of Haiku will therefore
     never be supported.
     The PPC and ARM platforms of Haiku should work but are untested.
 * a HaikuPorts recipe will be provided for the next regular
   SciTECO release. This should hopefully allow installation via
   HaikuDepot.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * Haiku can be handled like UNIX in most respects
   since it is POSIX compliant, has a UNIX-like terminal
   emulator and uses ncurses.
 * still the Glib platform macro is G_OS_HAIKU instead of
   G_OS_UNIX, so the preprocessor conditionals had to be adapted.
 * the only functional difference between a Haiku and UNIX build
   is the default SCITECOCONFIG path.
   We use the config path returned by Glib instead of $HOME,
   so .teco_ini will be in ~/config/settings on Haiku.
   Other UNIX ports appear to use the same conventions.
 * Some Haiku-specific restrictions still apply:
   * Haiku's terminal is xterm-compatible, but only supports
     8 colors. Therefore only the terminal.tes color scheme
     can be used and the terminal must be set up to
     "Use bright instead of bold text".
   * The terminal has artifacts. This appears to be a Haiku
     bug and affects other curses applications as well.
   * GTK is yet unsupported on Haiku, so there may never be
     a GUI port (unless someone writes a QT GUI for SciTECO).
   * SciTECO cannot be built with the legacy gcc2 used for
     BeOS compatibility on Haiku. This would require too many
     changes for an obsolete platform.
     BeOS and the x86_gcc2 platform of Haiku will therefore
     never be supported.
     The PPC and ARM platforms of Haiku should work but are untested.
 * a HaikuPorts recipe will be provided for the next regular
   SciTECO release. This should hopefully allow installation via
   HaikuDepot.
</pre>
</div>
</content>
</entry>
</feed>
