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`.

1 files changed, 5 insertions, 3 deletions

diff --git a/doc/sciteco.7.template b/doc/sciteco.7.template
index 1fe1dba..b43b4d2 100644
--- a/doc/sciteco.7.template
+++ b/doc/sciteco.7.template
@@ -1364,7 +1364,7 @@ are handled interactively.
 .SCITECO_TOPIC modifiers
 .
 A command's behaviour or syntax may be influenced by so called
-modifiers written in front of commands.
+modifiers written immediately in front of commands.
 Their specific influence of a modifier always depends on the concrete
 command following it.
 When specifying more than one modifier, their order is insignificant.
@@ -1383,8 +1383,8 @@ return 0 instead.
 .LP
 .SCITECO_TOPIC ::
 Two colons (\fB::\fP) can sometimes further modify a command's behavior \(em
-currently it is used by the \fB::S\fP search comparison command.
-On all other commands it will behave like a single colon.
+currently it is used by the \fB::S\fP search comparison command
+and a few related search-and-replace operations.
 .LP
 .SCITECO_TOPIC @ at
 When put in front of a command with string arguments,
@@ -1422,6 +1422,8 @@ escape character itself.
 The at (\fB@\fP) modifier may also sometimes be supported by commands,
 that do not accept string arguments.
 For instance, \fB@X\fIq\fR cuts text into Q-Register \fIq\fP.
+In front of word movement and deletion commands (e.g. \fBW\fP),
+it toggles the order of word vs. non-word characters that are skipped or deleted.
 \# But there is no common semantics for @ on regular commands, yet.
 \# We may some day add @Mq/.../ for passing string arguments to macro calls,
 \# but it will be yet another special case.