<feed xmlns='http://www.w3.org/2005/Atom'>
<title>sciteco/src/cmdline.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>improved Emscripten support: fixed configure-checks, generate *.js and detect EMCurses</title>
<updated>2018-06-10T23:10:19+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2018-06-10T23:10:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=524bc3960e6a6e5645ce904e20f72479e24e0a23'/>
<id>524bc3960e6a6e5645ce904e20f72479e24e0a23</id>
<content type='text'>
 * Emscripten can be used (theoretically) to build a host-only platform-independant version
   of SciTECO (running under node.js instead of the browser).
 * I ported netbsd-curses with Emscripten for that purpose. Therefore, adaptions for running
   in the browser are restricted to EMcurses now.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * Emscripten can be used (theoretically) to build a host-only platform-independant version
   of SciTECO (running under node.js instead of the browser).
 * I ported netbsd-curses with Emscripten for that purpose. Therefore, adaptions for running
   in the browser are restricted to EMcurses now.
</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>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>fixup to 89224899: fixed function key macros after $ and the rubout-command editing key</title>
<updated>2017-03-08T11:55:06+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2017-03-08T11:51:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=0a0d0b7cd9ce2942d5194762478a4e24cd05eca4'/>
<id>0a0d0b7cd9ce2942d5194762478a4e24cd05eca4</id>
<content type='text'>
 * StateEscape should return the same fnmacro mask as StateStart
 * When rubbing out a command, we should stop at StateEscape as well.
   Therefore we reintroduced States::is_start().
   RTTI is still not used.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * StateEscape should return the same fnmacro mask as StateStart
 * When rubbing out a command, we should stop at StateEscape as well.
   Therefore we reintroduced States::is_start().
   RTTI is still not used.
</pre>
</div>
</content>
</entry>
<entry>
<title>refactored commandline key processing: rewritten Cmdline::process_edit_cmd() as State::process_edit_cmd() virtual methods</title>
<updated>2017-03-07T18:23:25+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2017-03-07T18:23:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=892248991babb55366860488678632ab4ccdb0ba'/>
<id>892248991babb55366860488678632ab4ccdb0ba</id>
<content type='text'>
 * Cmdline::process_edit_cmd() was much too long and deeply nested.
   It used RTTI excessively to implement the state-specific behaviour.
   It became apparent that the behaviour is largely state-specific and could be
   modelled much more elegantly as virtual methods of State.
 * Basically, a state can now implement a method to customize its
   commandline behaviour.
   In the case that the state does not define custom behaviour for
   the key pressed, it can "chain" to the parent class' process_edit_cmd().
   This can be optimized to tail calls by the compiler.
 * The State::process_edit_cmd() implementations are still isolated in
   cmdline.cpp. This is not strictly necessary but allows us keep the
   already large compilations units like parser.cpp small.
   Also, the edit command processing has little to do with the rest of
   a state's functionality and is only used in interactive mode.
 * As a result, we have many small functions now which are much easier to
   maintain.
   This makes adding new and more complex context sensitive editing behaviour
   easier.
 * State-specific function key masking has been refactored by introducing
   State::get_fnmacro_mask().
 * This allowed us to remove the States::is_*() functions which have
   always been a crutch to support context-sensitive key handling.
 * RTTI is almost completely eradicated, except for exception handling
   and StdError(). Both remaining cases can probably be avoided in the
   future, allowing us to compile smaller binaries.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * Cmdline::process_edit_cmd() was much too long and deeply nested.
   It used RTTI excessively to implement the state-specific behaviour.
   It became apparent that the behaviour is largely state-specific and could be
   modelled much more elegantly as virtual methods of State.
 * Basically, a state can now implement a method to customize its
   commandline behaviour.
   In the case that the state does not define custom behaviour for
   the key pressed, it can "chain" to the parent class' process_edit_cmd().
   This can be optimized to tail calls by the compiler.
 * The State::process_edit_cmd() implementations are still isolated in
   cmdline.cpp. This is not strictly necessary but allows us keep the
   already large compilations units like parser.cpp small.
   Also, the edit command processing has little to do with the rest of
   a state's functionality and is only used in interactive mode.
 * As a result, we have many small functions now which are much easier to
   maintain.
   This makes adding new and more complex context sensitive editing behaviour
   easier.
 * State-specific function key masking has been refactored by introducing
   State::get_fnmacro_mask().
 * This allowed us to remove the States::is_*() functions which have
   always been a crutch to support context-sensitive key handling.
 * RTTI is almost completely eradicated, except for exception handling
   and StdError(). Both remaining cases can probably be avoided in the
   future, allowing us to compile smaller binaries.
</pre>
</div>
</content>
</entry>
<entry>
<title>roll back to the old mallinfo() implementation of memory limiting on Linux and added a FreeBSD/jemalloc-specific implementation</title>
<updated>2017-03-06T21:09:17+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2017-03-06T16:34:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=a2e52ca49c6a5495f134648e91647008dca4a742'/>
<id>a2e52ca49c6a5495f134648e91647008dca4a742</id>
<content type='text'>
 * largely reverts 39cfc573, but leaves in minor and documentation
   changes.
 * further experimentation of memory limiting using malloc() wrapping
   has shown additional problems, like dlsym() calling malloc-functions,
   further reducing the implementation to glibc-specific means.
   This means there had been no implementation for FreeBSD and checks
   would have to rely on undocumented internal implementation details
   of different libcs, which is not a good thing.
   * Other problems have been identified, like having to wrap calloc(),
     guarding against underruns and multi-thread safety had been identified
     but could be worked around.
 * A technique by calculating the memory usage as sbrk(0) - &amp;end
   has been shown to be effective enough, at least on glibc.
   However even on glibc it has shortcomings since malloc() will
   somtimes use mmap() for allocations and the technique
   relies on implementation details of the libc.
   Furthermore another malloc_trim(0) had to be added to the error
   recovery in interactive mode, since glibc does not adjust the program break
   automatically (to avoid syscalls I presume).
 * On FreeBSD/jemalloc, the sbrk(0) method totally fails because jemalloc
   exclusively allocates via mmap() -&gt; that solution was discarded as well.
 * Since all evaluated techniques turn out to be highly platform
   specific, I reverted to the simple and stable platform-specific
   mallinfo() API on Linux.
 * On FreeBSD/jemalloc, it's possible to use mallctl("stats.allocated")
   for the same purpose - so it works there, too now.
   It's slower than the other techniques, though.
 * A lengthy discussion has been added to memory.cpp, so that we
   do not repeat the previous mistakes.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * largely reverts 39cfc573, but leaves in minor and documentation
   changes.
 * further experimentation of memory limiting using malloc() wrapping
   has shown additional problems, like dlsym() calling malloc-functions,
   further reducing the implementation to glibc-specific means.
   This means there had been no implementation for FreeBSD and checks
   would have to rely on undocumented internal implementation details
   of different libcs, which is not a good thing.
   * Other problems have been identified, like having to wrap calloc(),
     guarding against underruns and multi-thread safety had been identified
     but could be worked around.
 * A technique by calculating the memory usage as sbrk(0) - &amp;end
   has been shown to be effective enough, at least on glibc.
   However even on glibc it has shortcomings since malloc() will
   somtimes use mmap() for allocations and the technique
   relies on implementation details of the libc.
   Furthermore another malloc_trim(0) had to be added to the error
   recovery in interactive mode, since glibc does not adjust the program break
   automatically (to avoid syscalls I presume).
 * On FreeBSD/jemalloc, the sbrk(0) method totally fails because jemalloc
   exclusively allocates via mmap() -&gt; that solution was discarded as well.
 * Since all evaluated techniques turn out to be highly platform
   specific, I reverted to the simple and stable platform-specific
   mallinfo() API on Linux.
 * On FreeBSD/jemalloc, it's possible to use mallctl("stats.allocated")
   for the same purpose - so it works there, too now.
   It's slower than the other techniques, though.
 * A lengthy discussion has been added to memory.cpp, so that we
   do not repeat the previous mistakes.
</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>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>auto-completion of Q-Register names, goto labels and help topics</title>
<updated>2016-11-20T00:52:39+00:00</updated>
<author>
<name>Robin Haberkorn</name>
<email>robin.haberkorn@googlemail.com</email>
</author>
<published>2016-11-19T22:59:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.fmsbw.de/sciteco/commit/?id=84ab1698e63170a94cfa1c5d99b7316cf3c2b584'/>
<id>84ab1698e63170a94cfa1c5d99b7316cf3c2b584</id>
<content type='text'>
 * Using a common implementation in RBTreeString::auto_complete().
   This is very efficient even for very huge tables since only
   an O(log(n)) lookup is required and then all entries with a matching
   prefix are iterated. Worst-case complexity is still O(n), since all
   entries may be legitimate completions.
   If necessary, the number of matching entries could be restricted, though.
 * Auto completes short and long Q-Reg names.
   Short names are "case-insensitive" (since they are upper-cased).
   Long specs are terminated with a closing bracket.
 * Long spec completions may have problems with names containing
   funny characters since they may be misinterpreted as string building
   characters or contain braces. All the auto-completions suffered from
   this problem already (see TODO).
 * This greatly simplifies investigating the Q-Register name spaces
   interactively and e.g. calling macros with long names, inserting
   environment registers etc.
 * Goto labels are terminated with commas since they may be part
   of a computed goto.
 * Help topics are matched case insensitive (just like the topic
   lookup itself) and are terminated with the escape character.
   This greatly simplifies navigating womanpages and looking up
   topics with long names.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 * Using a common implementation in RBTreeString::auto_complete().
   This is very efficient even for very huge tables since only
   an O(log(n)) lookup is required and then all entries with a matching
   prefix are iterated. Worst-case complexity is still O(n), since all
   entries may be legitimate completions.
   If necessary, the number of matching entries could be restricted, though.
 * Auto completes short and long Q-Reg names.
   Short names are "case-insensitive" (since they are upper-cased).
   Long specs are terminated with a closing bracket.
 * Long spec completions may have problems with names containing
   funny characters since they may be misinterpreted as string building
   characters or contain braces. All the auto-completions suffered from
   this problem already (see TODO).
 * This greatly simplifies investigating the Q-Register name spaces
   interactively and e.g. calling macros with long names, inserting
   environment registers etc.
 * Goto labels are terminated with commas since they may be part
   of a computed goto.
 * Help topics are matched case insensitive (just like the topic
   lookup itself) and are terminated with the escape character.
   This greatly simplifies navigating womanpages and looking up
   topics with long names.
</pre>
</div>
</content>
</entry>
</feed>
