The offset now just keeps track how far off we are after up/down (if
you do not hit the exact pixel column. To decide now if you really
want a new target_x as described above, you additionally check if
your current cursor position plus the offset is pixel-wise exactly
the old target_x. Then it's very probable that you want to keep the
target_x.

Hope that logic is reasonable. I like how it feels when moving around
with the cursor. Of course all that is heuristic and therefore matter
of discussion and taste.

Sorry for being bold, but I don't understand very well this explanation. When repeatedly going down, does target_x + offset_x remain constant? (in
that case it may be that this quantity was called target_x in the old
method)

No: "The offset now just keeps track how far off we are after up/down (if you do not hit the exact pixel column)"

This means that target_x is constant. pos+offset = target_x as long as you are going upwards.

The old way: set target_x = cursor_x after every cursor movement which is NOT up/down, use target_x in up/down (without changing it) for setting the
cursor from coordinates.

The "after every cursor movement" might be the problem of the approach. You have to spread those all over your code.

It seems to me that the old way was more straightforward for exactly the
same behavior. What are the advantages of the new approach?

The advantages are that it is implemented and probably shorter without touching every cursor function. Otherwise there is none.

Stefan

Attachment: PGP.sig
Description: Signierter Teil der Nachricht

Reply via email to