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, 2 insertions, 2 deletions

diff --git a/src/error.h b/src/error.h
index b672024..3c81257 100644
--- a/src/error.h
+++ b/src/error.h
@@ -77,10 +77,10 @@ teco_error_syntax_set(GError **error, gunichar chr)
 }
 
 static inline void
-teco_error_modifier_set(GError **error, gchar modifier)
+teco_error_modifier_set(GError **error, gchar chr)
 {
 	g_set_error(error, TECO_ERROR, TECO_ERROR_MODIFIER,
-	            "Excess \"%c\"-modifier", modifier);
+	            "Unexpected modifier on <%c>", chr);
 }
 
 static inline void