evil-next-line doesn't work as expected under visual-line-mode

Michael Markert markert.michael at googlemail.com
Fri Dec 23 17:08:44 CET 2011

On 23 Dec 2011, Titus von der Malsburg wrote:

> On Fri, Dec 23, 2011 at 2:43 PM, Michael Markert
> <markert.michael at googlemail.com> wrote:
>> On 23 Dec 2011, Titus von der Malsburg wrote:
>> Neither, it's a wrong expectation ;) Vim does not do it as well.
> Hm, not sure I agree.  As far as I know Vim doesn't have something
> analogous to visual-line-mode (:set wrap is not quite the same).

That's not true. Vim wraps like `visual-line-mode' by default and `gj'
is already present in vim:

    gj		or					*gj* *g<Down>*
    g<Down>			[count] display lines downward.  |exclusive| motion.
                Differs from 'j' when lines wrap, and when used with
                an operator, because it's not linewise.  {not in Vi}

> Therefore, I would say that it's not entirely clear what the authentic
> Vim behavior should be under visual-line-mode.  My understanding of
> visual-line-mode is that visual lines should have largely the same
> semantics as buffer-lines have when visual-line-mode is switched off.
> That is, even if something is just one line in the underlying file, it
> should look & feel like several real lines in Emacs if it doesn't fit
> on one line visually.  Hence, I would argue that a visual lines should
> behave like a buffer line in Evil, which means that j, k, <up>, <down>
> should move to the next visual line and not to the next buffer line.

Well Evil tries to emulate Vim and thus copies Vim's semantics. Changing
the behaviour here would also lead to inconsistencies with <n>G (well
you can change that too, but because you want corresponding line numbers
you now have to change linum-mode as well ...)

If that's the semantics you want: Just remap using the code I pasted

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
Url : https://lists.ourproject.org/pipermail/implementations-list/attachments/20111223/54a8ee42/attachment.pgp 

More information about the implementations-list mailing list