avy-linum-mode clashes with visual-line-mode #369
Comments
ghost-of-freedom
added a commit
to ghost-of-freedom/avy
that referenced
this issue
Nov 11, 2023
Avy uses screen lines when visual-line-mode is active, but linum marks only logical lines, so the indicators do not match the actual characters avy will use to jump, when both visual-line-mode and avy-linum-mode is active. We're taking linum's side here, and not using the visual-line code branches in avy when avy-linum-mode is active. It would be nice if linum could be forced to accept avy's reality instead, perhaps having an option to choose which side to take with a variable, but unfortunately I didn't find anything that would suggest such configuration could be possible, neither in linum, nor in nlinum for that matter. I also wrapped one naked visual-line-mode condition in a (bound-and-true-p) for consistency; I'm not sure if that change is necessary, and it can be reverted in case of trouble. Signed-off-by: ghost-of-freedom <97169326+ghost-of-freedom@users.noreply.github.com>
ghost-of-freedom
added a commit
to ghost-of-freedom/avy
that referenced
this issue
Nov 11, 2023
Avy uses screen lines when visual-line-mode is active, but linum marks only logical lines, so the indicators do not match the actual characters avy will use to jump, when both visual-line-mode and avy-linum-mode is active. We're taking linum's side here, and not using the visual-line code branches in avy when avy-linum-mode is active. It would be nice if linum could be forced to accept avy's reality instead, perhaps having an option to choose which side to take with a variable, but unfortunately I didn't find anything that would suggest such configuration could be possible, neither in linum, nor in nlinum for that matter. I also wrapped one naked visual-line-mode condition in a (bound-and-true-p) for consistency; I'm not sure if that change is necessary, and it can be reverted in case of trouble. Signed-off-by: ghost-of-freedom <97169326+ghost-of-freedom@users.noreply.github.com>
ghost-of-freedom
added a commit
to ghost-of-freedom/avy
that referenced
this issue
Nov 11, 2023
Avy uses screen lines when visual-line-mode is active, but linum marks only logical lines, so the indicators do not match the actual characters avy will use to jump, when both visual-line-mode and avy-linum-mode is active. We're taking linum's side here, and not using the visual-line code branches in avy when avy-linum-mode is active. It would be nice if linum could be forced to accept avy's reality instead, perhaps having an option to choose which side to take with a variable, but unfortunately I didn't find anything that would suggest such configuration could be possible, neither in linum, nor in nlinum for that matter. I also wrapped one naked visual-line-mode condition in a (bound-and-true-p) for consistency; I'm not sure if that change is necessary, and it can be reverted in case of trouble. Signed-off-by: ghost-of-freedom <97169326+ghost-of-freedom@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Avy has hardcoded traversal by screen lines when visual-line-mode is active, but linum marks only logical lines, creating a disparity and producing wrong results when using
avy-goto-linewithavy-linum-modeandvisual-line-modeactive (see here for information what screen and logical lines are in this context).I think this could be easily fixed by checking if
avy-linum-modeis off, before we decide to move by screen lines. I'll make the changes and link the pull request here, so you can see if that's an acceptable solution.By the way, linum-mode has become officially obsolete in Emacs 29 (see here); the recommendation is to use nlinum instead (I'm not even taking display-line-numbers-mode into consideration). Is it something that's easy to replace, or is it a more involved change? At a glance, nlinum exposes a variable that can be set to a function returning string to display on the fringe(?), something that linum seems to have lacked. Do you think that would make it easier to plug in?
The text was updated successfully, but these errors were encountered: