diff options
author | Robin Haberkorn <robin.haberkorn@googlemail.com> | 2016-02-13 18:43:00 +0100 |
---|---|---|
committer | Robin Haberkorn <robin.haberkorn@googlemail.com> | 2016-02-15 15:00:55 +0100 |
commit | f08187e454f56954b41d95615ca2e370ba19667e (patch) | |
tree | 73e4080be9c638844c55755b9d3646146386e2c4 /src/parser.h | |
parent | d836579118d8632f21f17bf02f29695ec2d57495 (diff) | |
download | sciteco-f08187e454f56954b41d95615ca2e370ba19667e.tar.gz |
implemented <$$> command for returning from a macro
* <$$> is faster than jumping to the end of the macro
and enables shorter code for returning values from macros.
* this also replaces $$ as an immediate editing command.
In other words, command line termination is an ordinary command
now. The old behaviour was similar to what classic TECO did.
Classic TECO however had no choice than to track key presses
directly for command line termination as it did not keep track
about the parser state as input was typed.
This led to some glitches in the language. For instance
"FS$$" would terminate the command line, unless the second escape
was typed after backspace, etc. This behaviour is not worth copying
and SciTECO did a better job than that by making sure that at least the
second escape is only effective if it is not part of language syntax.
This still lead to some undesirable cases like "ES...$$$" that would
terminate the command line unexpectedly.
To terminate the command line after something like "FS$$", you will
now have to type "FS$$$$".
* As it is a regular command now - just executed immediately - and
its properties stay close to the macro return behaviour, command line
termination may now not always be performed when $$ is typed even
as a standalone command. E.g. "Ofoo$ !bar!$$ !foo!Obar$" will
curiously terminate the command line now.
* This also means that macros can finally terminate command lines
by using the command line editing commands ({ and }) to insert
$$ into the command line macro.
This is also of interest for function key macros.
* This implementation showed some serious shortcoming in SciTECO's
current parser that yet have to be fixed.
E.g. the macro "@^Ua{<$$>}" is currently unsafe since
loops abuse the expression stack for storing their state and $$
does not touch the expression stack. Calling "Ma>" would actually
continue the loop jumping to the beginning of the command line
since program counters referring to the macro A will be reused!
This cannot be easily solved by checking for loop termination
since being able to return that way from loops is a useful
feature. This is a problem even without loops and $$, e.g. as
in "@^Ua{1,2,3(4,5} Ma)".
Instead, a kind of expression stack frame pointer must be
added to macro invocation stack frames, pointing to the beginning
of the expression stack for the current frame.
At the end of macros or on return, the stack contents of
corresponding to the frame can be discarded while preserving the
immediate arguments at the time of the return or end-of-macro.
This would stabilize SciTECO's macro semantics.
* When a top-level macro returns in batch mode, it would
be a good idea to use the last argument to calculate the
process return code, so it can be set by SciTECO scripts (TODO).
Diffstat (limited to 'src/parser.h')
-rw-r--r-- | src/parser.h | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/src/parser.h b/src/parser.h index a1bfd75..fe8f08b 100644 --- a/src/parser.h +++ b/src/parser.h @@ -219,6 +219,14 @@ private: State *custom(gchar chr); }; +class StateEscape : public State { +public: + StateEscape(); + +private: + State *custom(gchar chr); +}; + class StateFCommand : public State { public: StateFCommand(); @@ -310,6 +318,7 @@ namespace States { extern StateStart start; extern StateControl control; extern StateASCII ascii; + extern StateEscape escape; extern StateFCommand fcommand; extern StateChangeDir changedir; extern StateCondCommand condcommand; |