diff options
| author | Robin Haberkorn <robin.haberkorn@googlemail.com> | 2025-04-08 23:26:38 +0300 |
|---|---|---|
| committer | Robin Haberkorn <robin.haberkorn@googlemail.com> | 2025-04-09 00:33:40 +0300 |
| commit | 7c0e4fbb1d1f0d19d11c7417c55a305654ab1c83 (patch) | |
| tree | 35a99cefee7b63510f6765be4193b5a069c1eec2 /tests/testsuite.at | |
| parent | a7e66807871c70a99909fcf78335309ae1505055 (diff) | |
| download | sciteco-7c0e4fbb1d1f0d19d11c7417c55a305654ab1c83.tar.gz | |
tightened rules for specifying modifiers
* Instead of separate stand-alone commands, they are now allowed only immediately
in front of the commands that accept them.
* The order is still insignificant if both `@` and `:` are accepted.
* The number of colon modifiers is now also checked.
We basically get this for free.
* `@` has syntactic significance, so it could not be set conditionally anyway.
Still, it was possible to provoke bugs were `@` was interpreted conditionally
as in `@ 2<I/foo/$>`.
* Even when not causing bugs, a mistyped `@` would often influence the
__next__ command, causing unexpected behavior, for instance when
typing `@(233C)W`.
* While it was theoretically possible to set `:` conditionally, it could also
be "passed through" accidentally to some command where it wasn't expected as in
`:Ifoo$ C`.
I do not know of any real useful application or idiom of a conditionally set `:`.
If there would happen to be some kind of useful application, `:'` and `:|` could
be re-allowed easily, though.
* I was condidering introducing a common parser state for modified commands,
but that would have been tricky and introduce a lot of redundant command lists.
So instead, we now simply everywhere check for excess modifiers.
To simplify this task, teco_machine_main_transition_t now contains flags
signaling whether the transition is allowed with `@` or `:` modifiers set.
It currently only has to be checked in the start state, after `E` and `F`.
Diffstat (limited to 'tests/testsuite.at')
| -rw-r--r-- | tests/testsuite.at | 15 |
1 files changed, 8 insertions, 7 deletions
diff --git a/tests/testsuite.at b/tests/testsuite.at index 20869f4..20a76c5 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -59,6 +59,14 @@ AT_CHECK([$SCITECO -e "(1-6*5-1)+30\"N(0/0)'"], 0, ignore, ignore) AT_CHECK([$SCITECO -e "(1-6*5-1*2*2)+33\"N(0/0)'"], 0, ignore, ignore) AT_CLEANUP +AT_SETUP([Modifiers]) +AT_CHECK([$SCITECO -e '@:W$ :@W$'], 0, ignore, ignore) +# Detect invalid modifiers +AT_CHECK([$SCITECO -e '@J'], 1, ignore, ignore) +AT_CHECK([$SCITECO -e ': '], 1, ignore, ignore) +AT_CHECK([$SCITECO -e '::C$'], 1, ignore, ignore) +AT_CLEANUP + AT_SETUP([Closing loops at the correct macro level]) AT_CHECK([$SCITECO -e '@^Ua{>} <Ma'], 1, ignore, ignore) AT_CLEANUP @@ -352,13 +360,6 @@ AT_CHECK([$SCITECO -e "| (0/0) '"], 1, ignore, ignore) AT_XFAIL_IF(true) AT_CLEANUP -AT_SETUP([Out-of-place modifiers]) -# NOTE: `J` does not currently support @-modifiers. -# This should be a syntax error. -AT_CHECK([$SCITECO -e "@I/foo^J/ @J Xa"], 1, ignore, ignore) -AT_XFAIL_IF(true) -AT_CLEANUP - # NOTE: This bug depends on specific build options of Glib's # PCRE which is not predictable. # It segfaults at least on Ubuntu 20.04 (libpcre3 v2:8.39). |