Abdelrazak Younes wrote:
Dov Feldstern wrote:Hi!*) Abdel said: "I personally tend to think that the only clear option, one that does not leave room for complicated interpretation is to go for screen oriented movement: right is right and left is left. Of course supporting both mode would be better." +1. Yes, I agree that visual mode is clearer. However, it has its own problems: *) A selection may not be logically contiguousOn this point, I think we should not try to be too clever, the solution is simple really: During the selection process, when a RTL snippet is found within an LTR text, the full snippet should be selected: i.e. the same as we do for insets.
For visual mode, this sounds reasonable, at least as a first stage.For logical mode, it used to work, if we could get it working again I'd prefer that... (bug 3550).
*) Under this interpretation, what should the "backspace" key mean? Delete the previous character, or delete the character to the left ofthe cursor (where the arrow points)? It's not the same thing in RTL... And which character does the "delete" key delete? Depending on your answer to the previous question, "delete" and "backspace" may actually delete the same character, which doesn't make too much sense. So it's pretty clear (and that seems to be the consensus in other programs, as well), that backspace should still delete the logically previous character, even in visual mode.Agreed: backspace and delete are logical keys not visual.
Good, we're making progress! ;)
*) Andre said: "As a plain non-RTL-user I'd think the same. But of course the vote of someone actually using it should count more."+2. Yes, it is a rather humorous to hear all these opinions about whether or not this or that approach makes sense, given by people whohave never written in Bidi.Not being a bidi writer does not mean I will never be ;-) and please note that I already said that we should keep both mode if possible.
Sorry, you misunderstand me... I'm not saying that since you don't use bidi, then your opinion shouldn't count. What I *am* saying is, that when you do start writing bidi, I think you'll suddenly realize that what I'm suggesting will bother you less, and that the alternative to what I'm suggesting will bother you more, even if now it seems to make less sense to you...
And good, so we agree that we will keep both modes ;) .
) --- so please, instead of giving opinions about which approach does or does not make sense from the user's point of view, it would be much more helpful if you could help us out with the technical, programmatic, issues (and of course, make sure that nothing that we do interferes with reguar, non-bidi users). We've offered a few patches, but we need help working out the technical details, and you guys understand those better than we do. That's where we really need your help....If you have any technical comments about these patches, let's work them out. Otherwise, let's please commit them?I had comments about the goto about which I asked others to state their opinion. I implemented the isRTL() method specifically for Elazar's patch; so it's not like we don't help at all... If you want more Dov, you should be proactive and ask for commit access. You seem to be very cautious so I don't think JMarc will deny it. And at last we will have someone in charge of this stuff.
Abdel, you're so touchy! I wasn't saying that we're not getting any help, and I really do appreciate your help, on all kinds of issues. And Thank you for committing Elazar's patch! It's just that we always need even more ;) ... But seriously, I really do appreciate the help you've been giving us. :)
I'm willing to accept commit access, of course, and I'm even willing to be in charge of this stuff, at least for now. But I have very little time that I can actually put into LyX --- this week I've been putting in way more than I can afford --- so I don't want my getting commit access to be under any false pretenses. But if it helps, even if I will only commit from time to time, then sure, I'd be happy to get access. JMarc?
About you reverseDirection() patch, I am not sure that all RTL users will agree with you that the outer paragraph should drive the cursor movement. As I said, this is fine for small insets but not for multi-paragraph insets. I think we should try to implement somethingsimilar to Elazar's patch for mathed instead. If you can't do that then I'll apply your patch temporarily.
Okay, I think that I have a better example now for explaining why I think my approach is correct:
Using the current version (with Elazar's patch already in), try moving the cursor in the attached document (a math inset inside a footnote). It gets stuck again in the math inset, even after Elazar's patch, just because the math inset is now one level deeper!
Ask Elazar, I imagine that he would agree with me that that's not the desirable situation. There's no way around it: you have to be consistent with how you interpret the arrow keys throughout the paragraph, as soon as the interpretation is relative to the level you're at --- you get stuck. If instead of the isRTL() method used in that patch, we would use the function I'm proposing, which looks at the outermost paragraph, I believe the problem would not still exist.
I'll add fix this and add it to my suggested patch, I'll also fix the spacing issues that Andre' pointed out, we can wait to hear Elazar's opinion if you want --- but I really think that what I'm suggesting is the way that most bidi users would prefer.
Abdel.
Dov
rtl_insets_multilevel.lyx
Description: application/lyx
