Vegard Øye <[email protected]> writes:
On 2010-08-18 20:07, Craig Tenney wrote:
Here's what I've discovered: If 'vimpulse.elc' exists, 'Vyp' doesn't work correctly (i.e. it doesn't grab the final newline). If I delete the 'elc' file, 'Vyp' works as expected. If I byte-compile 'vimpulse.el' again, the 'Vyp' problem returns.
Thanks for this very valuable information. I've confirmed the bug, which should be fixed in commit [edcc432584]; please test. :)
What caused the bug is that Vimpulse inspects the `interactive' form of the command to be executed to determine if it is an operator (like "c", "d", "y") or not. That form looks a little different when compiled, obviously, so the inspection failed. The relation of this to the missing newline is explained below.
Are you sure? I can see no difference in the result of `interactive-form' (and the old definition of `vimpulse-operator-cmd-p') for compiled and uncompiled functions, so I don't think this is the actual problem.
I'm still lost on the vimpulse-surround thing, but that is presumably someone else's domain.
I can now explain this, too.
[...]
Rewriting the code along the lines of approach #2 in the post below is one solution.[1] Another is to list the commands in `vimpulse-newline-cmds':
(add-to-list 'vimpulse-newline-cmds 'vimpulse-change-surround-or-change) (add-to-list 'vimpulse-newline-cmds 'vimpulse-delete-surround-or-delete)
This works, thanks for pointing that out.
At this point, I think it would be beneficial to define operators with a dedicated `vimpulse-define-operator' macro to make their special standing more explicit. I recall Štěpán has proposed this already.
Yeah, the manual interactive spec "parsing" is fragile. Štěpán