Miki Dovrat wrote:
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".
Can you think of a sane way to solve this?
What do you want LyX to do: to say that if you've been typing in english
and then switch the language to hebrew, that it should jump back to
before the english, and continue inserting the hebrew there? 'cause I
think that's what would be necessary to do what you want in this case
--- but then just plain typing in would be a real pain: you type some
hebrew, want to insert a word in english so you switch to english, type
the word, then switch back to hebrew (you want to continue typing ---
after the english word, of course) and find yourself before the english
word!
I don't see any way out. And BTW, I'm not sure --- but I don't think
that visual mode will solve this, either...
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.
See the fix I sent separately...
7, 8 seem to be the same issue as in 6...?
Probably. I am not entering them as a separate bug for now.
Are these solved with the above-mentioned fix?
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.
Hmmm... I see that this was like that in 1.3.X, too, so it's not a
regression. Any ideas on how to solve it? There are a few issues for
which "I know" what needs to be done at the latex level, but I don't
really know latex+hebrew/ivritex well enough in order to understand why
exactly... (e.g., I think bug 3555 is a similar thing, see
http://permalink.gmane.org/gmane.editors.lyx.devel/82823). If you can
help in this respect, that would be great!
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.
Again, this *is* a "quirk" of LyX relative to other editors, but it's a
result of the fact that LyX doesn't allow multiple spaces. I guess we
might be able to do something better in this situation --- how about
opening a bug for this? Or better yet, a patch...?
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.
Not exactly. The problem is, that LyX is not allowing two spaces which
are adjacent *logically* --- but in this case, they are not adjacent
visually. So it looks as if it's not allowing even one space at that
logical position, but in fact there already is a space in that logical
position, it's just on the other side... Again, open a bug for this (I
think it's the same as the last issue) and we can try to fix it sometime...
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.
Okay, but it's the same cause... In the bug you open for 11, make sure
to specifically mention this case as well... I think we should be able
to solve these all together.
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,
I'm the last person in the world to say it's better... ;) All I'm saying
is, for any specific bug you mention, the behavior can be compared to
Word or OpenOffice or any other editor. If the behavior in those editors
seems to make more sense (in same cases it will, in other it won't),
then we can see about the possibility of implementing it that way in
LyX, too. I imagine that for some of these issues we'll find other
applications which behave better; and sometimes we'll be able to make
LyX behave the same; though other times we may decide that what works
for other applications doesn't necessarily work for LyX.
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.
Yes, and I've been giving it some thought over the past few days. It may
be possible to get a quick hack together quickly, but I think that a
good solution requires some thinking, and I'd rather do the thinking and
not rush to get this in before 1.5.0. So we'll have something to look
forward to in 1.5.1...
And again, visual movement is not a cure for everything...
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.
No, If you change the document's language to Hebrew
(document->settings...->language), then only the english will be marked
as foreign. At least that's the behavior I see...
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
Dov
