Closed axelf4 closed 5 months ago
Hi @axelf4 I'm away for a bit but will review in a few days. Please don't merge until I take a look. Cheers
I've had a quick look and agree that that test doesn't seem to correspond to behaviour in vim. I could have sworn I did test it against vim. Apart from my comment about g-up above, I think I'd rather merge this now as it does seem like something worth reversing. Then I can try to work out what I was thinking later! Cheers
Ah, had more of a look. I actually think what I implemented is how it should be (because if $ means "end of logical line regardless of what col that is, so persist this when moving logically", it makes sense to me that g$ would mean "end of visual line regardless of what visual col that is, so persist this when moving visually") rather than how vim actually does things. But alas the aim of evil is to emulate vim, despite how I think things should be. Weird that my conviction that it should be that way managed to blind me to how things are. Thanks for spotting!
Maybe a suggestion for an advice like
(define-advice evil-end-of-visual-line (:after (&rest _))
(setq temporary-goal-column most-positive-fixnum
this-command 'next-line))
could be added to the documentation? (Makes g$
anchor both j
/k
and gj
/gk
to EOL, but that is symmetric with $
.)
There already exists a method for sticking to EOL: Setting
temporary-goal-column
tomost-positive-fixnum
. As such, there is no need for the variableevil--visual-eol-anchored
introduced by commit e31bff8cb64d773bbfd9a8e326db8645eaee43fd.@tomdl89 I cannot replicate
evil-test-end-of-visual-line
in Vim, what motivated its addition? I have removed it here.