[implementations-list] Broken selection in latest Vimpulse (r199)?

[Vegard Øye]

> Date: Sat, 10 Apr 2010 02:28:29 +0200
> From: stepnem at gmail.com
>
> When I select some text, just pressing `d' or `y' does not execute the
> corresponding actions any more -- it seems to be waiting for another key
> (and indeed, after pressing another key, the action is executed).

This must be caused by old `vimpulse-map' bindings like

    (vimpulse-map "dae" 'vimpulse-delete-a-sexp)

Immediate fix: get rid of any old "cae" and "dae" bindings lying around
and define `vimpulse-change-a-sexp' and `vimpulse-delete-a-sexp' as
what they should have been all the time: proper text objects.

    (defun vimpulse-sexp (arg)
      "Select a S-expression."
      (interactive "p")
      (vimpulse-mark-object
       'vimpulse-inner-object-range arg
       'backward-sexp
       'forward-sexp))

    (define-key vimpulse-operator-basic-map "ae" 'vimpulse-sexp)

Now your operations is not restricted to "change" and "delete": you
can yank a S-exp with yae, indent it with =ae, ROT13 encrypt it
with g?ae (er, well, proof of concept :), and so on.

Long-winded explanation follows:

When you pressed d, Emacs needed at least one more key to determine
whether to call `vimpulse-delete-a-sexp' or `vimpulse-delete'. This is
transparent in vi (command) state, where you would press an additional
key anyway, but makes no sense in Visual mode.

It is not immediately obvious how to deal with this, because
/Vim exhibits the same behavior/. That is, if you have something like
the following in .vimrc,

    map dae <Esc>

then Vim will wait for another key following d in both command mode
/and/ Visual mode. The only difference is that Vim has a timeout, so
it waits half a second before defaulting to "delete", while Emacs
waits indefinitely. (I don't know how to implement the delay in Emacs.)

Possible solutions:

  1. Restrict "careful" keybindings to the state they were bound in.
     (A careful binding is one that sits on top of a previous one
     instead of overwriting it, like "dae".) The problem with this
     approach is that it's probably overkill: inheriting careful
     bindings from another state can be useful.

  2. Bind operator commands in both Visual mode and vi mode, rather
     than inheriting them from vi mode. Then Visual mode's clear-cut
     binding of "d" would override vi mode's careful binding. (This
     is how it worked previously: Visual mode had its own change and
     delete commands.) In other words,

         (define-key vimpulse-visual-basic-map "c" 'vimpulse-change)
         (define-key vimpulse-visual-basic-map "d" 'vimpulse-delete)

     would immediately solve the problem.

But it is not obvious that there /is/ a problem here. Rather, the
problem stems from the old, hackish way of achieving S-exp text
objects with careful bindings. Originally, Viper/Vimpulse had no
simple way to add new "motions" after keys like c, d and y, so I just
bolted some extra keybindings on top of the existing structure with
`vimpulse-map'. It was dirty, but it worked.

Now that you have checked out the latest revision, there's no more
need for that, thanks to the new Operator-Pending mode. As in Vim,
it provides a separate keymap for when c, d, y etc. are "pending",
which makes it very easy to add new text objects. Operator commands
can be combined with Emacs movement, e.g., both d C-M-f and d M-h
work. Furthermore, it's quite straightforward to define one's own
operator commands: just include a special `interactive' form. See
vimpulse-operator.el for more details.

There are still some things which needs to be ironed out, but I'd say
we are about 80% on the way to Vimpulse 0.3.2 in terms of work.

Vegard 		 	   		  
_________________________________________________________________
Windows Live™ Mail. Flere kontoer på ett sted.
http://download.live.com/wlmail