$ followed by g j moves point at the beginning of next line
Judafa opened this issue · comments
Issue type
- Bug report
Environment
Emacs version: GNU Emacs 29.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0)
Operating System: ArcoLinux
Evil version: Evil version evil-git-9acd9cd
Evil installation type: MELPA
Graphical/Terminal: X11
Tested in a make emacs session (see CONTRIBUTING.md): No
Reproduction steps
- Start Emacs
Do evil-end-of-line followed by evil-next-visual-line
Expected behavior
Point goes to the end of the next visual line
Actual behavior
Point goes to the beginning of the next line
Further notes
I think I know where the problem comes from: the function evil-end-of-line first sets temporary-goal-column to most-positive-fixnum.
Makes sense in order to stay at the end of the line since most-positive-fixnum is (I assume) the biggest integer possible.
When evil-next-visual-line is call, the problem appears in the call to C function vertical-motion that is called with (most-positive-fixnum . some-line), throwing an out-of-range error.
To fix it, we should somehow make sure that the actual lenght of the line is provided there and not most-positive-fixnum.
clip.mp4
Hi @Judafa thanks for the bug report. I can't replicate it with the provided instructions. I tried checking out the version of evil you've reported 9acd9cd but git can't find that short hash. Can you confirm what version of evil you see this behaviour with?
Hello @tomdl89 ! Thanks for the fast reply, indeed my issue was incomplete: the problem shows up when (global-visual-line-mode 1) is called in addition. I just tested it on a vanilla emacs and it should be easily reproducable.
Just for record, here are the steps:
- run (global-visual-line-mode 1)
- do (evil-end-of-line)
- do (evil-next-visual-line)
@Judafa this should now be fixed in master. Please let me know if you observe otherwise.
Yes it works now! thanks a lot