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

[Titus von der Malsburg]

Hi Frank,

I absolutely agree that combining Vim semantics with visual-line-mode
is not trivial.  However, at the moment Evil neutralizes some of the
main benefits of visual-line-mode and I think it's desirable to find a
solution for that problem.  For people doing mainly programming, this
might not be particularly important issue but for people who write a
lot of text in Emacs visual-line-mode can be essential.  Before I
switched to visual-line-mode, I hit M-q (or gqap) hundreds and
hundreds of times a day which is of course annoying.  I know there are
other solutions like auto-fill-mode and refill-mode that should work
with Evil out of the box but they all have disadvantages (like a fixed
fill-column) and visual-line-mode seems to become the standard way to
deal with long lines.

You recently provided me with a fix for some problems (like a proper
dd in visual-line-mode):

(evil-define-text-object evil-line (count)
  "Move COUNT - 1 lines down."
  (list (save-excursion
	  (beginning-of-visual-line)
	  (point))
	(save-excursion
	  (beginning-of-visual-line (1+ (or count 1)))
	  (point))))

I extended this with fixes for evil-insert-line and evil-append-line
(see below).  This addresses my most important use cases but it's of
course only a small step towards a complete solution.  Line and block
selection in visual state are more difficult to deal with, but they
are not common when working on continuous text anyway, so I can live
with that for now.

Next year, I will have more time and I will try to work on that
problem.  Perhaps I can finally contribute some else to Evil than
feature requests and bug reports ;-)

   Titus

(defun evil-insert-line (count &optional vcount)
  "Switch to Insert state just before the first non-blank character
on the current line. The insertion will be repeated COUNT times."
  (interactive "p")
  (if evil-auto-indent
      (goto-char (max (save-excursion (back-to-indentation) (point))
                      (save-excursion (beginning-of-visual-line) (point))))
    (beginning-of-visual-line))
  (setq evil-insert-count count
        evil-insert-lines nil
        evil-insert-vcount (and vcount
                                (> vcount 1)
                                (list (line-number-at-pos)
                                      #'evil-first-non-blank
                                      vcount)))
  (evil-insert-state 1))

(defun evil-append-line (count &optional vcount)
  "Switch to Insert state at the end of the current line.
The insertion will be repeated COUNT times."
  (interactive "p")
  (end-of-visual-line)
  (setq evil-insert-count count
        evil-insert-lines nil
        evil-insert-vcount (and vcount
                                (> vcount 1)
                                (list (line-number-at-pos)
                                      #'end-of-line
                                      vcount)))
  (evil-insert-state 1))


On Sat, Dec 24, 2011 at 11:32 AM, Frank Fischer
<frank.fischer at mathematik.tu-chemnitz.de> wrote:
> On Fri, Dec 23, 2011 at 03:42:00PM +0100, 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).
>> 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, this may be an ideal solution but it's not easy to achieve,
> e.g., who would you yank but especially paste visual lines or even
> visual blocks? It's not clear how operators and visual state should
> work on visual lines because a visual line is not really well defined
> but depends, e.g., on the current window size.
>
> Frank
>
> _______________________________________________
> implementations-list mailing list
> implementations-list at lists.ourproject.org
> https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list