[implementations-list] Broken selection in latest Vimpulse (r199)?
Hello, I vimdiffed yesterday (after not having updated for some time) to the latest Vimpulse as of revision 199 (and I swore I won't do that again -- I'm going to just use git-svn in the future ;-|), and visual mode exhibits the following bug for me: 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). It seems to be too obviously broken (actually I seem to be observing more bugs, but this is the most clear and deterministic one) for me to believe that you haven't noticed, but I still figured I'd ask before trying to investigate myself. Thanks and best regards, Štěpán
Date: Sat, 10 Apr 2010 02:28:29 +0200 From: [email protected]
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
On Sat, Apr 10, 2010 at 09:59:45AM +0000, Vegard Øye wrote:
This must be caused by old `vimpulse-map' bindings like
(vimpulse-map "dae" 'vimpulse-delete-a-sexp)
Oh! I didn't think about that... Thanks!
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.
Yeah, I noticed this (very cool) enhancement. Thank you very much for all the commentary, too. (Btw, I haven't really looked thoroughly at the implementation, but while applying the changes, all those `(defun vimpulse-{a,inner}-{w,W}ord ...)' immediately stroke my eye -- doesn't this just cry for some kind of macro that would define all such things for you or at least avoid some of the boilerplate?)
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.
Yeah. Actually I think you could (should) rather have released 0.3.1 as 0.4, at least, or even 1.0. The amount of work (and improvements) done to the package seems to call for a major version bump. Best wishes, Štěpán
Date: Sat, 10 Apr 2010 14:21:32 +0200 From: [email protected]
Btw, I haven't really looked thoroughly at the implementation, but while applying the changes, all those `(defun vimpulse-{a,inner}-{w,W}ord ...)' immediately stroke my eye -- doesn't this just cry for some kind of macro that would define all such things for you or at least avoid some of the boilerplate?
It definitely does, but things aren't set in stone yet. I'll keep things verbose for now, and return to the macro issue before release. (Even with a macro, I'd still want to define each object one by one. "Inner word" and "inner paren" mean very different things, for example, and some objects may have "linewise" tendencies while others do not (not implemented yet). So to some degree one needs to think of objects as individuals, even though they belong to the same species.)
Actually I think you could (should) rather have released 0.3.1 as 0.4, at least, or even 1.0. The amount of work (and improvements) done to the package seems to call for a major version bump.
I see your point. 0.3.1 was originally intended as a maintenance release, dealing with the large backlog of uncommitted patches which had accumulated at that point. It ended up dealing with a lot more, of course, mainly because I couldn't use Vimpulse the way I wanted (and I use Vimpulse for coding at Vimpulse!) without rewriting Visual mode. The next version will introduce even more code, and that code needs to get out of the controlled environment of my own computer and put to the test by other users. The bugs I encounter personally are, after all, fixed right away; it's the bugs discovered by others which are really elusive, from my point of view. We all use our software in slightly different ways, and that's what that makes user feedback so /literally/ invaluable. I am very grateful to all the people who take their time to complain when Vimpulse isn't working out, because it is vital to the maturement of the code. To be honest, I don't know what the next version /really/ should be called, but suffice to say 1.0 is still far off. Only with the help of you, the users, can we arrive at such a stable number. ;) Vegard _________________________________________________________________ Nye Windows 7: PCen som passer for deg. Finn ut mer. http://windows.microsoft.com/shop
From: [email protected] To: [email protected]
(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)
This code is outdated. Commit [5a6f053bdc] introduces the `vimpulse-define-text-object' macro, which is used thus: (vimpulse-define-text-object vimpulse-sexp (arg) "Select a S-expression." :keys '("ae" "ie") (vimpulse-inner-object-range arg 'backward-sexp 'forward-sexp)) We are nearing release. Any last-minute nits? :) Vegard _________________________________________________________________ Windows 7: Se direkte-TV fra den bærbare PCen. Finn ut mer. http://windows.microsoft.com/windows-7
On Sun, Apr 25, 2010 at 06:56:08PM +0000, Vegard Øye wrote:
From: [email protected] To: [email protected]
(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)
This code is outdated. Commit [5a6f053bdc] introduces the `vimpulse-define-text-object' macro, which is used thus:
(vimpulse-define-text-object vimpulse-sexp (arg) "Select a S-expression." :keys '("ae" "ie") (vimpulse-inner-object-range arg 'backward-sexp 'forward-sexp))
Thanks for the heads-up!
We are nearing release. Any last-minute nits? :)
Heh, let me see ((un)fortunately I still haven't really looked at the code -- you've made Vimpulse far too satisfactory for me to feel the urge (and it's also still quite a moving target)) ... So, nits you say... 1. I would bind `message-log-max' around all the calls to `message' in the Visual mode code to not have things like '-- VISUAL LINE --' go to the *Messages* buffer. 2. vimpulse-visual-mode.el:19: ;; Viper's movement commands, so that translation can be postphoned It's "postpone", not "postphone". 3. c0764e05b: -;; Also, thanks to Michael Kifer and those who contributed to Viper. +;; Also, thanks to Michael Kifer and Viper's contributors. FWIW, the former sounds better than the latter to me; in any case I don't see any typo in there? 4. `((quote ,type)) That makes one wondering why not just write `(',type) :) Also, are you sure you don't want to release 0.4 at least, instead of 0.3.2? Štěpán
Date: Sun, 25 Apr 2010 23:14:33 +0200 From: [email protected]
I would bind `message-log-max' around all the calls to `message' in the Visual mode code to not have things like '-- VISUAL LINE --' go to the *Messages* buffer.
Good idea, done in commit [79604b0aef]. I haven't affected the "Deleted 2 lines" messages, which are somewhat similar to "Mark set" and "Wrote <file>: 50 lines, 1500 characters" (which are logged), so I figure they should be logged too.
It's "postpone", not "postphone".
Ouch, how embarrassing. :) I know I have made this misspelling in the past, too. Fixed in commits [3a25bb3c0b] and [79604b0aef] (there were two of them).
c0764e05b: -;; Also, thanks to Michael Kifer and those who contributed to Viper. +;; Also, thanks to Michael Kifer and Viper's contributors.
FWIW, the former sounds better than the latter to me; in any case I don't see any typo in there?
I wanted to avoid the past tense.
`((quote ,type))
That makes one wondering why not just write `(',type) :)
Uh ... yeah, yours is better. Fixed in commit [8d33c49303]. That thing is passed to ,@ so that 'type becomes part of the macro expansion. ,@ doesn't change anything if you pass nil to it (the empty list), so I use it for conditionally including bits of code in the expansion. But, of course, I have to wrap those bits in a list first.
Also, are you sure you don't want to release 0.4 at least, instead of 0.3.2?
Yeah, it's probably a good idea not to get stuck with small version numbers. I plan to replace redo.el with Toby Cubitt's awesome undo-tree.el package, which means Vimpulse's dependencies will change; the version number should reflect that. 0.3.3 will probably be too subtle. This will be 0.4, then, and probably the last release to use redo.el. If so, it will be succeeded by 0.5. Vegard _________________________________________________________________ Nye Windows 7: PCen som passer for deg. Finn ut mer. http://windows.microsoft.com/shop
On Mon, Apr 26, 2010 at 10:49:27AM +0000, Vegard Øye wrote:
I plan to replace redo.el with Toby Cubitt's awesome undo-tree.el package, which means Vimpulse's dependencies will change;
Yeah, I've actually been using undo-tree for some time already, it's definitely better than redo.el, although I'm still not sure if I won't go back to Emacs' default -- undo in region seems more useful to me than having an undo tree (I know it's on Toby's TODO list, but I'm not sure it'll happen, any time soon at least). But undo-tree is of course more Vim-compatible, so it makes sense for Vimpulse anyway. 3cd9dad17ae: it's really "GNU Emacs Lisp Reference Manual" ^^^^^^ [à bas les fonts non-fixed-widths!] Štěpán
On Mon, Apr 26, 2010 at 02:48:30PM +0200, Štěpán Němec wrote:
undo in region seems more useful to me than having an undo tree (I know it's on Toby's TODO list, but I'm not sure it'll happen, any time soon at least).
... looks like my doubts were mistaken: <http://permalink.gmane.org/gmane.emacs.devel/124419> In that message (from today) Toby speaks about undo-in-region support as "nearly done" :-) Štěpán
Date: Sun, 2 May 2010 21:09:45 +0200 From: [email protected]
<http://permalink.gmane.org/gmane.emacs.devel/124419>
In that message (from today) Toby speaks about undo-in-region support as "nearly done" :-)
Good to hear! I added undo-tree.el code in commit [32efb55e1d]. The tree is accessed with :undolist (or just :ul), and may be navigated using vi keys. I suppose you would use the Emacs default of C-_ for "Visual undo", since Vim lacks this function? Vegard _________________________________________________________________ Nye Windows 7: PCen som passer for deg. Finn ut mer. http://windows.microsoft.com/shop
participants (2)
-
Vegard Øye -
Štěpán Němec