On 23 Dec 2011, Titus von der Malsburg wrote: > On Fri, Dec 23, 2011 at 2:43 PM, Michael Markert > <[email protected]> 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
earlier.
Michael
pgpOvUe2aYQm0.pgp
Description: PGP signature
_______________________________________________ implementations-list mailing list [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
