Yes, I see that. Yuck... I hadn't noticed it before. So yeah, there's still a problem with selection there...
In fact no, it's a bug of cursorX and hence the cursor position is wrong as well, even without selection. So the selection is just a consequence of that.
So, what should we do now? I can fix either: I can make the getFont method to behave like the bidi algorithm, or I can make the bidi algorithm to handle spaces like normal characters, or I can make the cursorX method to compute the right position according to the bidi algorithm (at the moment its logic uses both, hence the bug), hence the bug would be gone, but we keep the difference between GUI and output. Opinions?Well, I'm still not sure, I'd like to hear more opinions from Bidi users...I think my inclination is this: we "ignore" the language of spaces, and make them behave according to the bidi algorithm (or even better, first decide how they should be treated, according to the bidi algorithm, and then set their language accordingly --- would that be possible?
getFont must be tweaked a bit to use the outer font for space at the end/start of RTL segments. It's possible and probably not very hard.
The advantage is this: that would also make them show up on the screen as they are treated internally, and more importantly: would make latex treat them correctly). I bridle at the fact that we are forcing something on the user, but OTOH I can't think of any situation where the user would want to force different behavior. And the alternative would also require the lyx2lyx changes...
Will try it out....
But again, I want opinions from other Bidi users (and any other developers, too).
Don't know. Most people don't care about Bidi, maybe on the user list might be more fruitful. One has to create a few pictures which show the different possible implementations.
PGP.sig
Description: Signierter Teil der Nachricht
