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? (inthat 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 thecursor 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 thesame 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
PGP.sig
Description: Signierter Teil der Nachricht