Closed Judafa closed 3 months ago
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:
@Judafa this should now be fixed in master. Please let me know if you observe otherwise.
Yes it works now! thanks a lot
Issue type
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): NoReproduction steps
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.
https://github.com/emacs-evil/evil/assets/62807929/e3ae0386-e892-4883-b97f-f4d785cde337