Hi,
My replies to your replies :) :
>> 3. If I have a Hebrew paragraph with an English word like
>> ????? English ????? ?????
>> and I type continuously, the spaces are Hebrew. Now if I try to continue
>> the Hebrew to the right of the English word, but after the Hebrew space,
>> as to continue typing, I can't: If I am in English mode and I press F12
>> (bound to language hebrew), the cursor jumps to the left of the English
>> word. If I was already in hebrew (if the cursor was resting on a hebrew
>> word before and then I moved it to this position with the mouse), then
>> it's ok.
>
> This is correct. If you move to the right of the english through the
> english, then at the end you are still considered to be in English, at the
> end of the english; so switching to hebrew should move you to the left of
> the english. You can do what you want by moving to the beginning of the
> english, and then move back one more, that'll bring you to the space
> before the english; then if you move one Left, you'll be after the space,
> but still in hebrew. Typing in hebrew will then work as you want it to.
What you say is correct, and I have found that out, but it is not intuitive
and takes "learning" lyx's behavior.
Also, when you just land there with the mouse, you have the same "problem".
>>
>> 6. I cannot enter an inline equation to the right of the English word.
>
> This looks like a bug. If you're coming from the english, then I think
> that the equation should also be "in english" (see next comment), and then
> what you want to do would work. Can you open a bug for this in bugzilla
> (and see next comment)? Meanwhile, if you just select the entire inset,
> and switch it's language with F12, you'll get what you want.
This is bug 3011 in bugzilla.
> 7, 8 seem to be the same issue as in 6...?
Probably. I am not entering them as a separate bug for now.
>>
>> 10. References which get added RTL are backward in output, i.e. instead
>> of 12, 13, 14, etc. I get 21, 31, 41. Even if I try to switch the
>> language to English, the reference gets marked RTL. I suspect it will be
>> the same for figure numbers above 10. For equations it comes out fine for
>> some reason even above 10.
>
> Is the problem here in the display or in latex or both? I haven't checked
> this yet...
This is bug 3005. The output (DVI) comes out reversed. On screen you don't
see numbers anyway, you see labels. The references are inside the \R{ } in
latex and that is the problem I guess.
>> 11. If I try to enter an English word between two already typed Hebrew
>> words, to the right of the space, and I type "English " with a space, the
>> space gets deleted and I don't get a space between the word English and
>> the hebrew word to its right.
>>
>
> The correct way is for spaces around LTR text within RTL paragraphs (or
> vice versa) is for the space to be in the paragraph's language. Otherwise,
> ambiguities arise. So technically, what you're trying to do is wrong. You
> should first enter the space "in hebrew", and only then switch to english,
> and type in the english word.
But a user can't possibly know that in advance, but has to learn this
"quirk" of lyx.
> We tried to correct this in the case of regular typing --- i.e., if you
> type in hebrew, and then F12, space, and english --- then the space's
> language will automatically be switched to hebrew. But that will only
> happen when you type the next hebrew character. In the above case you're
> not doing that, so this doesn't happen. Again, the correct way is to have
> the space in the language of the surrounding paragraph.
I think you should let the user enter all the spaces he/she wants and then
take care of the double spacing. Right now lyx in some circumstances isn't
letting to enter even ONE space, let alone two.
>> 12. If I try to enter an English word between two already typed Hebrew
>> words, to the left of the space, I can't enter an LTR space to start
>> with, and if I write "English ", I am left with two spaces, one LTR and
>> to its right, the original RTL space.
>>
>
> Same as 11.
This isn't the same as 11. It is related to 11, but more severe in my
opinion, since since it leaves the text in an incorrect way, with two
spaces, one RTL and one LTR.
> No problem. It's just that there are real problems here, and I'm not sure
> there are good solutions to all of them. If you have suggestions for *how*
> to solve these issues, please send them in. Keep in mind though that what
> you want in one situation may not be what you want in another... One thing
> you could do is see if you think the situation in Word (or any other
> application) is better --- and if it is, we'll see if we can adopt that
> behavior. Again, though, note that there are some problems in LyX which do
> not arise in word (for example, the fact that we don't allow adjacent
> spaces in LyX) --- and we want to keep LyX's behavior in many of these
> cases...
Word isn't better, it is just "already learned" by us. I will play with open
office. The BEST thing in my opinion would be the visual behavior we already
discussed and you seem to agree with me.
>
> 1. I think you'll find it easier to deal with these things if you do mark
> the foreign language -- that way it's easier to see what's going on. I
> never found this distracting, but I guess that's a matter of taste. Maybe
> you can think of a different way of marking foreign languages, which would
> be less distracting.
Sure, but lyx marks RTL, not a foreign langauge, so if you are writing a
Hebrew document, it all gets marked instead of just the English parts. Maybe
that could be changed to make things better until true visual mode with an
intuitive and expected behavior is in place?
> 3. I may have sounded a little defensive about some of these issues ---
> if I did --- sorry ;) . It's just that for some of the issues, I'm not
> suer there's a good solution, at least not without getting into
> complicated heuristics for trying to figure out what the user really
> means...
Likewise, I am defensive about my bug list :), but don't take it personally.
Miki
