Cursor moves to awkward position after enable visual-line-navigation in orgmode

[bebound]

Description

After enable visual-line-navigation with SPC-t-L, the cursor can move to the right of ... (fold section), and press h can't move cursor now. It shows beginning of line.

Reproduction guide 🪲

• Start Emacs
• Enable visual line mode
• Move cursor to the right of ... in other lines
  
• Use jk to move cursor to the ... line, then the cursor is at the right of ...
  
• I can't use h to move cursor to left. Instead, I have to use l to let it move to the 'real' end of line, then I'm able to use h to move cursor to left.
  

Observed behaviour: 👀 💔
I can't use h to move cursor.

Expected behaviour: ❤️ 😄
I can use h to move the cursor left.

It's also okay to prevent moving right of ..., as the <Tab> key doesn't work in this awkward position.

System Info 💻

• OS: darwin
• Emacs: 29.1
• Spacemacs: 0.999.0
• Spacemacs branch: develop (rev. 13c8050)
• Graphic display: t
• Running in daemon: nil
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

((auto-completion :variables auto-completion-enable-snippets-in-popup nil auto-completion-enable-help-tooltip t auto-completion-enable-sort-by-usage t)
 better-defaults git treemacs
 (org :variables org-enable-hugo-support t org-startup-indented t org-enable-sticky-header t)
 osx multiple-cursors org
 (shell :variables shell-default-height 30 shell-default-position 'bottom)
 (spell-checking :variables spell-checking-enable-auto-dictionary t)
 treemacs)

• System configuration features: ACL GNUTLS JSON LIBXML2 MODULES NOTIFY KQUEUE PDUMPER SQLITE3 THREADS TOOLKIT_SCROLL_BARS TREE_SITTER XWIDGETS ZLIB

Backtrace 🐾

<<BACKTRACE IF RELEVANT>>

[alexey0308]

Hi @bebound, in my case I can use "h" to move to the left, but I have to press it twice.

Have you tried to set inside the user-init block?

(setq evil-respect-visual-line-mode t)

The docs for this variable says that it defines "Whether movement commands respect ‘visual-line-mode’."

This does not feel like spacemacs bug though, probably you may refer to the evil-org-mode package and search for similar issues reported there with regard of visual-line mode behaviour or create a new one.

[bebound]

(setq evil-respect-visual-line-mode t) does not have any effect.

It's weird that you can move the cursor to left when it's at the right of .... h binds to evil-backward-char, and it shows beginning of line.

After press l to move cursor to here, then I'm able to use double press h to move it to left.

Sorry, I'm not familiar with emacs and don't know how to create an empty config to verify if this issue is related to Evil or Spacemacs.

[alexey0308]

ok, in another buffer I could reproduce what you observe. Previously I was not able to get the cursor at the very end of the line, but when it is there it is indeed stuck and I can not use "h".

I tried to switch to the emacs keybinding (C-z) and this problem does not exist there, only in evil-mode.

Upd.: in insert-mode I can move with arrows everywhere.

[smile13241324]

@bebound @alexey0308 can you give me a hint how you managed to get your cursor right of the ... in normal mode? I am really trying to but my cursor stops before the elipsis except when I switch to insert mode however when I switch back to normal mode and my cursor is right of the elipsis it automatically jumps to the left of it.

With this behaviour this bug should not longer occur at all. Can you still reproduce the issue? If not it may have been fixed somewhere in between.

[fnussbaum]

I cannot reproduce this either with up-to-date Emacs, org and evil.

[alexey0308]

Hi @smile13241324,

I've just updated the packages and pulled the recent devel:

• open javascript layer README.org

• SPC-t-L

• z-a on line 141 (Choossing formatter)

• place a cursor at the line below and to the right of the ...:

  

• k to go up:
  

[fnussbaum]

@alexey0308 Thank you! I can now reproduce the following:

in my case I can use "h" to move to the left, but I have to press it twice.

But I cannot reproduce the original issue where h did not work at all before pressing l.

In any case this seems to be caused by evil. Setting either evil-move-beyond-eol or evil-cross-lines to t leads to the expected behaviour on my system.

[smile13241324]

Than @alexey0308 and @fnussbaum I can finally reproduce your issue. However I think this is a configuration issue rather than a coding one.

If someone activates visual line mode also evil-move-beyond-eol and evil-cross-lines as well as evil-respect-visual-line-mode can be activated though they impair a performance penalty which not all users will want to accept.

I'll move this ticket to the FAQ session for others to find but would not change our code to always activate those settings.