Am Montag, 28. Februar 2011 schrieb Frank Fischer: > I really like the idea of making operators as close to usual emacs > commands as possible. This is certainly possible for character > motions, but how do you tell which kind of motion the region belongs > to? Call different commands depending on the type? Modify point and > mark? The latter is possible for character and linewise motions, but > what about block? Furthermore modifying point and mark may be > problematic. Several commands have rules where to place point after > execution depending on the original position of point (before > modification to respect the visual region). > > I can think of defining operators with arguments > (BEG END &optional (type 'char) register) > and an apropriate interactive specification. This would enable them > to behave like normal region-operations but gives the additional > possibilities to pass further important information. But then there > is the problem how to pass the additional arguments interactively. > But it sounds as if you have a good idea how to do this ;)
The more I think about it I wonder if this is really the right idea using the full power of interactive. One could easily use custom interactive statements with lisp expressions like (interactive (list (region-beginning) (region-end) (vimu:current-motion-type) (vimu:current-motion-register))) (or similar) to provide all the required information. I think this would fit nicely into the usual Emacs commands and provides the additional information for vimu and they can be called non-interactively as any other function. Of course we can hide this rather complicate interactive statements behind some macros. I think this could solve all issues I mentioned in the last post and should be a good compromise. The other question that comes into my mind is the following. In vim-mode, as I told, I prevent an operator to be executed until the following motion has been executed. This can be done as above if the interactive form uses some kind of recursive edit (right?). I would still prefer some way to delay the execution of the operator until the motion has been selected without making operator-pending special. Is this possible easily (e.g., can a special pre-command-hook delay the execution of the current command)? In vim-mode I used to macros vim:defmotion to do this magic, but this does not work with standard Emacs functions. And I have a further question. We must certainly specify some additional properties for commands, e.g., some commands are repeatable while others are not repeatable, some should preserve visual-mode (e.g., several window and scrolling commands which are not really motions - they cannot be used with an operator and sometimes don't even change point) while others disable visual-mode (most editing commands). How do we specify theses properties? I can think of two possibilities: 1. mark them *explicitely* in some property list 2. make them part of the function definition In vim-mode I used the latter one by specifying some special parameters in the parameter-list of a command, e.g. (vim:defcmd vim:scroll-up (count keep-visual) ...) I do not really like this approach because those parameters are, well, no parameters. Perhaps some additional magic (interactive) parameters? Something similar? I think specifying these properties directly in the command-definition is the right way because then the command definition is more self-explanatory (each command should be specified by one and only one statement). Bye, Frank PS: don't bother I used "vimu" in the examples above, I just needed some prefix ;) _______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
