Vimpulse and vim-mode

[Frank Fischer]

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 ;)