<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src/parser.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>0,8ED: Automatic case-folding of commands</title>
<updated>2017-03-25T05:57:17+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2017-03-25T05:47:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=90baf34034af9363ee4cfa1654a8cc72dfc8c62e'/>
<id>90baf34034af9363ee4cfa1654a8cc72dfc8c62e</id>
<content type='text'>
 * when enabled, it will automatically upper-case all
   one or two letter commands (which are case insensitive).
 * also affects the up-carret control commands, so they when inserted
   they look more like real control commands.
 * specifically does not affect case-insensitive Q-Register specifications
 * the result are command lines that are better readable and conform
   to the coding style used in SciTECO's standard library.
   This eases reusing command lines as well.
 * Consequently, string-building and pattern match characters should
   be case-folded as well, but they aren't currently since
   State::process_edit_cmd() does not have sufficient insight
   into the MicroStateMachines. Also, it could not be delegated
   to the MicroStateMachines.
   Perhaps they should be abandoned in favour of embeddedable
   regular state machines; or regular state machines with a stack
   of return states?
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * when enabled, it will automatically upper-case all
   one or two letter commands (which are case insensitive).
 * also affects the up-carret control commands, so they when inserted
   they look more like real control commands.
 * specifically does not affect case-insensitive Q-Register specifications
 * the result are command lines that are better readable and conform
   to the coding style used in SciTECO's standard library.
   This eases reusing command lines as well.
 * Consequently, string-building and pattern match characters should
   be case-folded as well, but they aren't currently since
   State::process_edit_cmd() does not have sufficient insight
   into the MicroStateMachines. Also, it could not be delegated
   to the MicroStateMachines.
   Perhaps they should be abandoned in favour of embeddedable
   regular state machines; or regular state machines with a stack
   of return states?
</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>allow dollar sign as another variant of ^[ (discard all arguments or return)</title>
<updated>2016-11-30T18:26:16+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-11-30T18:26:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e4d5a995a037ae938d08480359a53dc097deec21'/>
<id>e4d5a995a037ae938d08480359a53dc097deec21</id>
<content type='text'>
 * some classic TECOs have this
 * just like ^[, dollar works as a command only, not as a string terminator
 * it improves the readability of macros using printable characters only
 * it closes a gap in the language by allowing $$ (double-dollar) and
   ^[$ as printable ways to write the return from macro command.
   ^[^[ was not and is not possible.
 * since command line termination is a regular interactive return-command
   in SciTECO, double-dollar will also terminate the command line now.
   This will be allowed unless it turns out to be a cause of trouble.
 * The handling of unterminated commands has been cleaned up by
   introducing State::end_of_macro().
   Most commands (and thus states) except the start state cannot be
   valid at the end of a macro since this indicates an unterminated/incomplete
   command.
   All lookahead-commands (currently only ^[) will end implicitly
   at the end of a macro and so will need a way to perform their action.
   The virtual method allows these actions to be defined with the rest
   of the state's implementation.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * some classic TECOs have this
 * just like ^[, dollar works as a command only, not as a string terminator
 * it improves the readability of macros using printable characters only
 * it closes a gap in the language by allowing $$ (double-dollar) and
   ^[$ as printable ways to write the return from macro command.
   ^[^[ was not and is not possible.
 * since command line termination is a regular interactive return-command
   in SciTECO, double-dollar will also terminate the command line now.
   This will be allowed unless it turns out to be a cause of trouble.
 * The handling of unterminated commands has been cleaned up by
   introducing State::end_of_macro().
   Most commands (and thus states) except the start state cannot be
   valid at the end of a macro since this indicates an unterminated/incomplete
   command.
   All lookahead-commands (currently only ^[) will end implicitly
   at the end of a macro and so will need a way to perform their action.
   The virtual method allows these actions to be defined with the rest
   of the state's implementation.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed rubout of the first command after command line termination ($$)</title>
<updated>2016-11-27T21:47:27+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-11-27T21:47:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=8460f925248b99e94169bbfa9f2645de677f2e27'/>
<id>8460f925248b99e94169bbfa9f2645de677f2e27</id>
<content type='text'>
 * The $$ would leave the current state pointing to the "escape" state
   which was manually fixed up in macro return handling but not in command line
   return (ie. termination) handling.
   Therefore the initial state at the start of the command line after $$
   was the "escape" state.
   The rubout-last-command immediate editing command would consequently
   end up in an infinite loop trying to reach the start state.
 * This has been fixed by setting the state before throwing Return().
   Some additional paranoia assertions have been added to prevent this
   bug in the future.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * The $$ would leave the current state pointing to the "escape" state
   which was manually fixed up in macro return handling but not in command line
   return (ie. termination) handling.
   Therefore the initial state at the start of the command line after $$
   was the "escape" state.
   The rubout-last-command immediate editing command would consequently
   end up in an infinite loop trying to reach the start state.
 * This has been fixed by setting the state before throwing Return().
   Some additional paranoia assertions have been added to prevent this
   bug in the future.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed local Q-Register management on certain broken platforms</title>
<updated>2016-11-22T17:15:21+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-11-22T15:16:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=0bf380ff110897d2b5db2e22ef6efe1e9ba9888d'/>
<id>0bf380ff110897d2b5db2e22ef6efe1e9ba9888d</id>
<content type='text'>
 * on MSVCRT/MinGW, space allocated with alloca()/g_newa() was apparently
   freed once the first exception was caught.
   This prevented the proper destruction of local Q-Reg tables and
   broke the Windows port.
 * Since all alternatives to alloca() like VLAs are not practical,
   the default Q-Register initialization has been moved out of the
   QRegisterTable constructor into QRegisterTable::insert_defaults().
 * The remaining QRegisterTable initialization and destruction is
   very cheap, so we simply reserve an empty QRegisterTable for
   local registers on every Execute::macro() call.
   The default registers are only initialized when required, though.
 * All of this has to change anyway once we replace the
   C++ call-stack approach to macro calls with our own macro
   call frame memory management.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * on MSVCRT/MinGW, space allocated with alloca()/g_newa() was apparently
   freed once the first exception was caught.
   This prevented the proper destruction of local Q-Reg tables and
   broke the Windows port.
 * Since all alternatives to alloca() like VLAs are not practical,
   the default Q-Register initialization has been moved out of the
   QRegisterTable constructor into QRegisterTable::insert_defaults().
 * The remaining QRegisterTable initialization and destruction is
   very cheap, so we simply reserve an empty QRegisterTable for
   local registers on every Execute::macro() call.
   The default registers are only initialized when required, though.
 * All of this has to change anyway once we replace the
   C++ call-stack approach to macro calls with our own macro
   call frame memory management.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed glib warnings about using g_mem_set_vtable() and revised memory limiting</title>
<updated>2016-11-20T17:18:36+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-11-20T08:00:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=b7ff56db631be7416cf228dff89cb23d753e4ec8'/>
<id>b7ff56db631be7416cf228dff89cb23d753e4ec8</id>
<content type='text'>
 * we were basing the glib allocators on throwing std::bad_alloc just like
   the C++ operators. However, this always was unsafe since we were throwing
   exceptions across plain-C frames (Glib).
   Also, the memory vtable has been deprecated in Glib, resulting in
   ugly warnings.
 * Instead, we now let the C++ new/delete operators work like Glib
   by basing them on g_malloc/g_slice.
   This means they will assert and the application will terminate
   abnormally in case of OOM. OOMs cannot be handled properly anyway, so it is
   more important to have a good memory limiting mechanism.
 * Memory limiting has been completely revised.
   Instead of approximating undo stack sizes using virtual methods
   (which is unprecise and comes with a performance penalty),
   we now use a common base class SciTECO::Object to count the memory
   required by all objects allocated within SciTECO.
   This is less precise than using global replacement new/deletes
   which would allow us to control allocations in all C++ code including
   Scintilla, but they are only supported as of C++14 (GCC 5) and adding compile-time
   checks would be cumbersome.
   In any case, we're missing Glib allocations (esp. strings).
 * As a platform-specific extension, on Linux/glibc we use mallinfo()
   to count the exact memory usage of the process.
   On Windows, we use GetProcessMemoryInfo() -- the latter implementation
   is currently UNTESTED.
 * We use g_malloc() for new/delete operators when there is
   malloc_trim() since g_slice does not free heap chunks properly
   (probably does its own mmap()ing), rendering malloc_trim() ineffective.
   We've also benchmarked g_slice on Linux/glib (malloc_trim() shouldn't
   be available elsewhere) and found that it brings no significant
   performance benefit.
   On all other platforms, we use g_slice since it is assumed
   that it at least does not hurt.
   The new g_slice based allocators should be tested on MSVCRT
   since I assume that they bring a significant performance benefit
   on Windows.
 * Memory limiting does now work in batch mode as well and is still
   enabled by default.
 * The old UndoTokenWithSize CRTP hack could be removed.
   UndoStack operations should be a bit faster now.
   But on the other hand, there will be an overhead due to repeated
   memory limit checking on every processed character.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * we were basing the glib allocators on throwing std::bad_alloc just like
   the C++ operators. However, this always was unsafe since we were throwing
   exceptions across plain-C frames (Glib).
   Also, the memory vtable has been deprecated in Glib, resulting in
   ugly warnings.
 * Instead, we now let the C++ new/delete operators work like Glib
   by basing them on g_malloc/g_slice.
   This means they will assert and the application will terminate
   abnormally in case of OOM. OOMs cannot be handled properly anyway, so it is
   more important to have a good memory limiting mechanism.
 * Memory limiting has been completely revised.
   Instead of approximating undo stack sizes using virtual methods
   (which is unprecise and comes with a performance penalty),
   we now use a common base class SciTECO::Object to count the memory
   required by all objects allocated within SciTECO.
   This is less precise than using global replacement new/deletes
   which would allow us to control allocations in all C++ code including
   Scintilla, but they are only supported as of C++14 (GCC 5) and adding compile-time
   checks would be cumbersome.
   In any case, we're missing Glib allocations (esp. strings).
 * As a platform-specific extension, on Linux/glibc we use mallinfo()
   to count the exact memory usage of the process.
   On Windows, we use GetProcessMemoryInfo() -- the latter implementation
   is currently UNTESTED.
 * We use g_malloc() for new/delete operators when there is
   malloc_trim() since g_slice does not free heap chunks properly
   (probably does its own mmap()ing), rendering malloc_trim() ineffective.
   We've also benchmarked g_slice on Linux/glib (malloc_trim() shouldn't
   be available elsewhere) and found that it brings no significant
   performance benefit.
   On all other platforms, we use g_slice since it is assumed
   that it at least does not hurt.
   The new g_slice based allocators should be tested on MSVCRT
   since I assume that they bring a significant performance benefit
   on Windows.
 * Memory limiting does now work in batch mode as well and is still
   enabled by default.
 * The old UndoTokenWithSize CRTP hack could be removed.
   UndoStack operations should be a bit faster now.
   But on the other hand, there will be an overhead due to repeated
   memory limit checking on every processed character.
</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>implemented self-documenting (online) help system</title>
<updated>2016-11-18T06:05:52+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-02-26T01:02:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=e7867fb0d9979c550e6e3d7597ece73b680c4af6'/>
<id>e7867fb0d9979c550e6e3d7597ece73b680c4af6</id>
<content type='text'>
 * the new "?" (help) command can be used to look up
   help topics.
 * help topics are index from $SCITECOPATH/women/*.woman.tec
   files.
 * looking up a help topic opens the corresponding "womanpage"
   and jumps to the position of the topic (it acts like an anchor
   into the document).
 * styling is performed by *.woman.tec files.
 * Setting up the Scintilla view and munging the *.tec file
   is performed by the new "woman.tes" lexer.
   On supporting UIs (Gtk), womanpages are shown in a variable-width
   font.
 * Woman pages are usually not hand-written, but generated from manpages.
   A special Groff post-processor grosciteco has been introduced for this
   purpose. It is much like grotty, but can output SciTECO macros for styling
   the document (ie. the *.woman.tec files).
   It is documented in its own man-page.
 * grosciteco also introduces sciteco.tmac - special Troff macros
   for controlling the formatting of the document in SciTECO.
   It also defines .SCITECO_TOPIC which can be used to mark up
   help topics/terms in Troff markup.
 * Woman pages are generated/formatted by grosciteco at compile-time, so
   they will work on platforms without Groff (ie. as on windows).
 * Groff has been added as a hard compile-time requirement.
 * The sciteco(1) and sciteco(7) man pages have been augmented with
   help topic anchors.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * the new "?" (help) command can be used to look up
   help topics.
 * help topics are index from $SCITECOPATH/women/*.woman.tec
   files.
 * looking up a help topic opens the corresponding "womanpage"
   and jumps to the position of the topic (it acts like an anchor
   into the document).
 * styling is performed by *.woman.tec files.
 * Setting up the Scintilla view and munging the *.tec file
   is performed by the new "woman.tes" lexer.
   On supporting UIs (Gtk), womanpages are shown in a variable-width
   font.
 * Woman pages are usually not hand-written, but generated from manpages.
   A special Groff post-processor grosciteco has been introduced for this
   purpose. It is much like grotty, but can output SciTECO macros for styling
   the document (ie. the *.woman.tec files).
   It is documented in its own man-page.
 * grosciteco also introduces sciteco.tmac - special Troff macros
   for controlling the formatting of the document in SciTECO.
   It also defines .SCITECO_TOPIC which can be used to mark up
   help topics/terms in Troff markup.
 * Woman pages are generated/formatted by grosciteco at compile-time, so
   they will work on platforms without Groff (ie. as on windows).
 * Groff has been added as a hard compile-time requirement.
 * The sciteco(1) and sciteco(7) man pages have been augmented with
   help topic anchors.
</pre>
</div>
</content>
</entry>
<entry>
<title>fixed segfault when munging empty scripts</title>
<updated>2016-11-16T15:34:35+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-11-15T23:52:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=c0fe49457d37e4c51cd4fd829895a60ae24bc8af'/>
<id>c0fe49457d37e4c51cd4fd829895a60ae24bc8af</id>
<content type='text'>
 * empty scripts are SciTECO scripts with an Hash-Bang line but no
   EOL characters.
   They are simply ignored now.
 * A test case cannot be added since 1) it's hard to create the test
   script with AT_DATA - we'd have to add it to the repo instead.
   2) If the bug is not occurring, SciTECO starts into interactive mode
   which cannot be inhibited unless the script is __not__ empty.
 * Skipping the Hash-Bang line is optimized now, saving one iteration
   of the macro just to find out it contains no CR (which is
   the most common case).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * empty scripts are SciTECO scripts with an Hash-Bang line but no
   EOL characters.
   They are simply ignored now.
 * A test case cannot be added since 1) it's hard to create the test
   script with AT_DATA - we'd have to add it to the repo instead.
   2) If the bug is not occurring, SciTECO starts into interactive mode
   which cannot be inhibited unless the script is __not__ empty.
 * Skipping the Hash-Bang line is optimized now, saving one iteration
   of the macro just to find out it contains no CR (which is
   the most common case).
</pre>
</div>
</content>
</entry>
</feed>
