evil-next-line doesn't work as expected under visual-line-mode
I just updated to the latest version of evil. Unfortunately evil-next-line doesn't work as previously under visual-line-mode. It goes to the next buffer line instead of to the next visual line. Is this is a bug or a configuration issue? Titus
On 23 Dec 2011, Titus von der Malsburg wrote:
I just updated to the latest version of evil. Unfortunately evil-next-line doesn't work as previously under visual-line-mode. It goes to the next buffer line instead of to the next visual line. Is this is a bug or a configuration issue?
Neither, it's a wrong expectation ;) Vim does not do it as well. What you can do is using `gj`: `evil-next-visual-line`. Or switch the two: #+begin_src emacs-lisp (define-key evil-normal-state-map (kbd "j") 'evil-next-visual-line) (define-key evil-normal-state-map (kbd "k") 'evil-previous-visual-line) (define-key evil-normal-state-map (kbd "gj") 'evil-next-line) (define-key evil-normal-state-map (kbd "gk") 'evil-previous-line) #+end_src Michael
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). 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. Titus
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
Hi Michael, I should have said in my last mail that your code does exactly what I want. So thank you very much for that! On Fri, Dec 23, 2011 at 5:08 PM, Michael Markert <[email protected]> wrote:
Vim wraps like `visual-line-mode' by default and `gj' is already present in vim:
I don't think ':set wrap' does the same as visual-line-mode. The documentation of visual-line-mode says: "It turns on word-wrapping in the current buffer, and rebinds C-a, C-e, and C-k to commands that operate by visual lines instead of logical lines." Vim, at least the versions I have worked with (whatever Debian or Ubuntu provided over the last ten years), does something different. First, it doesn't wrap at word-boundaries but wherever the window ends. Also, the analogous commands to C-a, C-e, C-k in Vim operate on the buffer line (as stored in the file) instead of on the visual line. E.g. d$ deletes until the next newline character, whereas C-k under visual-line-mode kills only the rest of the visual line. In fact, switching off visual-line-mode gives me more or less the same behavior as Vim. Thanks again for providing a fix for my problem! Titus
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 <[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). 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
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 <[email protected]> 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 <[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). 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 [email protected] https://lists.ourproject.org/cgi-bin/mailman/listinfo/implementations-list
participants (3)
-
Frank Fischer -
Michael Markert -
Titus von der Malsburg