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.
* 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.
* 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.
* a table reference was stored in the UndoToken. * since there are only two tables at a given moment, this can be avoided by having two different undo tokens, one for globals and one for locals. * Practically, undo tokens for locals are only created for the top-level local Q-Reg table since macro calls with locals with set must_undo to false since the local table is destroyed with the macro return.
* 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.
* we can use root() instead of min() which is faster
* 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.
* test case: rubout 1U[foo] * this probably also leaked memory if it didn't crash * a missing cast from RBTree::remove() was missing. This cast is necessary since QRegister uses multiple inheritance. The offset of RBEntryString might not be 0 in QRegister. Also, since the base class is no longer virtual, a cast to the virtual QRegister class is necessary to ensure that subclass destructors get called. This might have not caused problems before since RBEntry was virtual or the compiler just happened to reorder the instance structures.
* whenever the implementation class was not exactly RBEntryType, it had to have a virtual destructor since RBTree cared about cleanup and had to delete its members. * Since it does not allocate them, it is consistent to remove RBTree::clear(). The destructor now only checks that subclasses have cleaned up. Implementing cleanup in the subclasses is trivial. * Consequently, RBEntryString no longer has to be virtual. HelpIndex and GotoTables are completely non-virtual now which saves memory (and a bit of cleanup speed). For QRegister, not much changes, though.