1. Frank Fischer
  2. evil
Issue #66 wontfix

evil-end-of-visual-line doesn't work as expected when visual-line-mode is off

Anonymous created an issue

instead of moving to the end of the actual untruncated line the command instead moves to where the line would have been truncated if visual-line-mode was enabled.

when in visual-line-mode it works fine, but when visual-line-mode is off it should go to the actual end of line.

Comments (7)

  1. Frank Fischer repo owner
    • changed status to open

    I'm not sure what the correct behavior is. Even if visual-line-mode is off lines could be wrapped at the window boundaries. Therefore a "visual-line" still has meaning and the distinction may be preferable.

  2. Anonymous

    No I don't think that's right.

    When using standard line wrapping you have no option of moving across pseudo lines, and equally you do not have the option of moving to pseudo EOL.

    This is the whole point of visual-line-mode - to allow movement between pseudo lines and naturally pseudo EOL.

    What you suggest is to be able to move to pseudo EOL but without being able to move across pseudo lines (visual-line-mode disabled but wrap-mode enabled, with the current behaviour of evil-end-of-visual-line as is).

    You also make the assumption that anyone who bothers with visual-line-mode will for some reason want to use standard line wrapping when visual-line-mode is off - I really don't see why anyone would do that, for a number of reasons, main one being that when visual-line-mode users turn it off they expect all wrapping to be off i.e. go into truncate-mode, the natural polar opposite to enabled visual-line-mode. In truncate-mode the current behaviour of evil-end-of-visual-line is broken as it sends me to some arbitrary position near the screen edge (since I can't see exactly where the break would occur), and any subsequent jumps land me in random places on the line since I have absolutely no clue where the next pseudo break _would_ be as I can't see beyond the window edge.

    Again, the whole point of visual-line-mode is to conditionally switch between jumping to screen edge or hard EOL, same with jumping across wrapped lines or hard lines - both controlled by whether visual-line-mode is enabled or not.

  3. Titus von der Malsburg

    I always thought that the point of visual line mode was to insert soft line breaks at word boundaries where non visual mode breaks in the middle of words. I agree that the semantics are not perfectly clear but I favor Franks interpretation. The name end-of-visual-line just doesn't make much sense when it doesn't mean go to the end of what visually appears to be a line. Franks interpretation is also consistent with Emacs' own interpretation: when visual-line-mode is switched off, end-of-visual-line moves the cursor not to the next line break but to the end of what visually appears to be a line.

  4. Frank Fischer repo owner

    There may very well be situations where one does not want visual-line-mode but wants standard line wrapping. For example, I for myself prefer standard line-wrapping when programming because a want to see the whole lines but at the same time want to see to which *real* line each *visual* line belongs to - I tried visual-line-mode but never liked it in that situations. Other people may have similar preferences.

    The current implementation seems to be consistent with both, Emacs and Vim, as Titus pointed out. For example movements like "gj" or "gk" as well as "g$" or "g^" move point according to the actual visible lines, no matter if wrapping of whatever kind is enabled or disabled. The same holds for Emacs motions (AFAIK).

    But there is currently a bug: evil-end-of-visual-line moves point one character too far (a typical emacs motion issue), i.e. to first character after the last on the visual line instead of that last character.

  5. Frank Fischer repo owner

    But of course you can utilize evil's ability to define special keybindings whenever another keymap is active, e.g., the following code should map "$" and "^" to evil-end-of-visual-line and evil-beginning-of-visual-line if and only if visual-line-mode is active

    (evil-define-key 'motion visual-line-mode-map "$" 'evil-end-of-visual-line 
                                                  "^" 'evil-beginning-of-visual-line)

    and otherwise the default bindings remain active. This may be the behavior you want.

  6. Anonymous

    Alright fair enough you make valid points, each to his own.

    I'll go with your suggested bit of code to remap the keys how I like.


  7. Log in to comment