Re: position on changing defaults?

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
> > > > > AFAICT, the approach I proposed where most/all the movement commands get
> > > > > changed to call a special function in the interactive spec wouldn't
> > > > > suffer from any such problems.  I think it's the best approach so far.
> > > > I can not see what the advantage with an interactive spec over a property on
> > > > the function name is. Could you please tell?
> > > Very simple: no magic, no pre/post-command-hook.
>
> > Why is an interactive spec less magic than the property on a function name?
> > To the end user (non-lisper) it could be equally visible, or?
>
> The property is irrelevant.  The relevant problem is the code that uses
> those properties which is placed on pre/post-command-hook.

There are obviously (at least) two problems:
- whether to use property or interactive spec, and
- whether to do things in an interactive spec or in the command loop 
(maybe using a hook then).

Does not using only an interactive spec makes things very stiff? What if 
the user wants other commands (that he/she has not written self) to join 
the dance?

> > The pre-pre/post-post-command-hook I proposed has nothing to do with this,
> > or? (I believe such a hook could be used for other emulations too,
> > like Viper.)
>
> Such a proposal is just making things worse.

That is not my intention ;-)

If a property is used then the dance must happen in the command loop. 
For that I have (several times) suggested using new hooks:

  pre-pre pre doit post post-post

Handling of shift should AFAICS be done early, ie pre-pre.

There are however other emulations than the shift-emulation that may 
require handling as late as possible instead. One such thing is Vipers 
move-related copy and cut commands. I think a post-post hook could serve 
to generalize those Viper copy and cut commands. It could also be used 
to restrict movements to a field for example. (I cc:ed Michael K. I hope 
I am not misunderstanding this.)