vimpulse bug: visual-line does not select final newline

Thu Aug 19 17:48:45 CEST 2010

Vegard Øye <vegard_oye at hotmail.com> 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