* The program exit code will usually not signal failures since they are caught earlier. * Therefore, we always have to capture and check stderr.
* It was initialized only once, so it could inherit the wrong local Q-Register table. A test case has been added for this particular bug. * Also, if starting from the profile (batch mode), the state machine could be initialized without undo, which then later cause problems on rubout in interactive mode. For instance, if S^EG[a] fails and you would repeatedly type `]`, the Q-Reg name could grow indefinitely. There were probably other issues as well. Even crashes should have been possible, although I couldn't reproduce them. * Since the state machine is required only for the pattern to regexp translation and is performed anew for every character in interactive mode, we now create a fresh state machine for every call and don't attempt any undo. There might be more efficient ways, like reusing the string building's Q-Reg parser state machine.
* A test case has been added, although it might have been accidental that on caused crashes.
Found thanks to the "infinite monkey" test.
Supposing that any monkey hitting keys on a typewriter, serving as a hardcopy SciTECO terminal, will sooner or later trigger bugs and crash the application, the new monkey-test.apl script emulates such a monkey. In fact it's a bit more elaborate as the generated macro follows the frequency distribution extracted from the corpus of SciTECO macro files (via monkey-parse.apl). This it is hoped, increases the chance to get into "interesting" parser states. This also adds a new hidden --sandbox argument, but it works only on FreeBSD (via Capsicum) so far. In sandbox mode, we cannot open any file or execute external commands. It is made sure, that SciTECO cannot assert in sandbox mode for scripts that would run without --sandbox, since assertions are the kind of things we would like to detect. SciTECO must be sandboxed during "infinite monkey" tests, so it cannot accidentally do any harm on the system running the tests. All macros in sandbox mode must currently be passed via --eval. Alternatively, we could add a test compilation unit and generate the test data directly in memory via C code. The new scripts are written in GNU APL 1.9 and will probably work only under FreeBSD. These scripts are not meant to be run by everyone.
* Any memory error will let the test case fail with code 66. * You can also call make check TESTSUITEFLAGS="--valgrind" * There is no program test for Valgrind in configure.ac for the time being. `valgrind` must be in $PATH. * All CI testsuite runs under Ubuntu are now with Valgrind.
* There was some boilerplate code missing in teco_state_search_all_initial(), that is present in teco_state_search_initial(). * Perhaps there should be a common function to avoid redundancies? * This will also fix the initialization of the string argument codepage for <N>.
* Supports all immediate editing commands.
Naturally it cannot emulate arbitrary key presses since there is no
canonic ASCII-encoding of function keys.
Key macros are not consequently also not testable.
The --fake-cmdline parameter is instead treated very similar to
a key macro expansion.
* Most importantly this allows adding test cases for rubout behavior
and bugs that are quite common.
* Added regression test cases for the last two rubout bugs.
* It's not easy to pass control codes in command line arguments in
a portable manner, so the test cases will often use { and }.
Control codes could be used e.g. by defining variables like
RUBOUT=`printf '\b'`
and referencing them with ${RUBOUT}.
* The old bug of saving gchar in gints, so teco_eol_reader_t::last_char could become negative. * When converting from an UTF-8 text with CRLF linebreaks, we could have data loss and corruptions. * On strings ending in UTF-8 characters, teco_eol_reader_t::offset would overflow, resulting in invalid reads and potentially insertion of data garbage. I observed this with G~ on Gtk. * Test cased updated. Couldn't reproduce the bug with the test suite, though.