Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Miki Dovrat]

Hi,
My comments are below

Miki


 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...

I would like lyx to be visual, and I think it will solve this problem, since 
the cursor will STAY PUT in the location it is in without jumping anywhere. 
In latex, you will have \L's and \R's all over the place, and you can clean 
that up later - maybe when saving, maybe when leaving the row. I don't 
know enough about what lyx does (I wanted to get into it but I lack the 
time, maybe in the future...)

To sum up, I would like lyx, when it is inside a \L (English), to switch 
automatically to English, unless the user explicitly changes it with F12 
(\language hebrew), the cursor will NOT MOVE, and the text will be added 
where it was, whether it was English or Hebrew.

When moving across already written text, lyx, when spotting a move between 
\L and \R should move visually, i.e., to the end of the foreign text and go 
backwards (so the arrow keys move to the right direction), and change its 
language as well, again, unless explicitly changed by the user by pressing 
F12.

Lyx should then understand about spaces being adjacent visually, not 
logically, and fix adjacent spaces between RTL and LTR this way.

Is that not simpler to understand, as far as a user is concerned? I am not 
referring to coding problems here. Can that be accomplished?


 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?

Is it already in svn? if not, where is the patch? I will check.

 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 
 

was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Separating this into different issues, it's getting long...

Miki Dovrat wrote:

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...


I would like lyx to be visual, and I think it will solve this problem, since 
the cursor will STAY PUT in the location it is in without jumping anywhere. 


That will work when moving, but not when typing: when you type in 
hebrew, and then switch to english, and then back to hebrew --- where do 
you want the hebrew to continue: to the left or to the right of the 
english? I want it to continue on the left: usually I type in logical 
order, not first all the hebrew and then go back and insert the english...


In latex, you will have \L's and \R's all over the place, and you can clean 
that up later - maybe when saving, maybe when leaving the row. I don't 
know enough about what lyx does (I wanted to get into it but I lack the 
time, maybe in the future...)


To sum up, I would like lyx, when it is inside a \L (English), to switch 
automatically to English


I believe it does this...


, unless the user explicitly changes it with F12 (\language hebrew),
the cursor will NOT MOVE, and the text will be added 
where it was, whether it was English or Hebrew.


Again, this doesn't make sense when typing. It means after every 
insertion of an english word, you'll have to move the cursor before 
continuing to type in hebrew...

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Miki Dovrat wrote:


When moving across already written text, lyx, when spotting a move between 
\L and \R should move visually, i.e., to the end of the foreign text and go 
backwards (so the arrow keys move to the right direction), and change its 
language as well, again, unless explicitly changed by the user by pressing 
F12.


Regarding visual movement, I agree that it would solve some (not all!) 
of these issues. But I also think that implementing visual movement 
correctly will require some refactoring of the cursor movement code. I 
hope to get working on it soon, but even if it is ready before 1.5.0 is 
released, I'm not sure that those kinds of changes should go in at this 
point. And in that case, I'd rather focus in the meantime on issues 
which can, perhaps, be fixed for 1.5.0.

Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Abdelrazak Younes]

Dov Feldstern wrote:


, unless the user explicitly changes it with F12 (\language hebrew),
the cursor will NOT MOVE, and the text will be added where it was, 
whether it was English or Hebrew.


Again, this doesn't make sense when typing. It means after every 
insertion of an english word, you'll have to move the cursor before 
continuing to type in hebrew...


No, in Visual mode, when LyX detect an RTL characters the insertion 
should happen at the right place. IOW, the jumping will happen at 
_writing_ time not at cursor navigation time like in so-called 'logical 
mode'. IMHO of course :-)


Abdel.

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Abdelrazak Younes]

Miki Dovrat wrote:
To sum up, I would like lyx, when it is inside a \L (English), to switch 
automatically to English, unless the user explicitly changes it with F12 
(\language hebrew), the cursor will NOT MOVE, and the text will be added 
where it was, whether it was English or Hebrew.


When moving across already written text, lyx, when spotting a move between 
\L and \R should move visually, i.e., to the end of the foreign text and go 
backwards (so the arrow keys move to the right direction), and change its 
language as well, again, unless explicitly changed by the user by pressing 
F12.


Lyx should then understand about spaces being adjacent visually, not 
logically, and fix adjacent spaces between RTL and LTR this way.


Is that not simpler to understand, as far as a user is concerned?


FWIW I 100% agree with you but I am not (yet) an RTL writer :-)

I am not 
referring to coding problems here. Can that be accomplished?


I believe it would be simpler to achieve than the current complicated 
logical navigation. The difficult part would be the automagic insertion 
at the right place.


Abdel.

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Abdelrazak Younes]

Dov Feldstern wrote:

Miki Dovrat wrote:


When moving across already written text, lyx, when spotting a move 
between \L and \R should move visually, i.e., to the end of the 
foreign text and go backwards (so the arrow keys move to the right 
direction), and change its language as well, again, unless explicitly 
changed by the user by pressing F12.


Regarding visual movement, I agree that it would solve some (not all!) 
of these issues. But I also think that implementing visual movement 
correctly will require some refactoring of the cursor movement code. I 
hope to get working on it soon, but even if it is ready before 1.5.0 is 
released, I'm not sure that those kinds of changes should go in at this 
point. And in that case, I'd rather focus in the meantime on issues 
which can, perhaps, be fixed for 1.5.0.


Agreed :-)

Abdel.

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Miki Dovrat wrote:

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?


Is it already in svn? if not, where is the patch? I will check.


See http://permalink.gmane.org/gmane.editors.lyx.devel/87817. Let's 
continue the discussion of this issue in response to that thread.

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Dov Feldstern wrote:

Miki Dovrat wrote:



Are these solved with the above-mentioned fix?


Is it already in svn? if not, where is the patch? I will check.


See http://permalink.gmane.org/gmane.editors.lyx.devel/87817. Let's 
continue the discussion of this issue in response to that thread.





Sorry, wrong link. Anyhow, this is committed now (r18781).

Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Miki Dovrat]

I was going to say, let the cursor always stay where it is, and the user 
will learn to press END (end of line) to move it to continue typing. It is 
logical, (not in the logical direction sense), expected and easily adapted 
to by the user, as there are no surprises there.

Abdel's idea is even better. I second it.

When writing, lyx will assume you want to jump to the end of line, but when 
editing, it will assume you don't!!

Miki

Abdelrazak Younes [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
 Dov Feldstern wrote:

 , unless the user explicitly changes it with F12 (\language hebrew),
 the cursor will NOT MOVE, and the text will be added where it was, 
 whether it was English or Hebrew.

 Again, this doesn't make sense when typing. It means after every 
 insertion of an english word, you'll have to move the cursor before 
 continuing to type in hebrew...

 No, in Visual mode, when LyX detect an RTL characters the insertion should 
 happen at the right place. IOW, the jumping will happen at _writing_ time 
 not at cursor navigation time like in so-called 'logical mode'. IMHO of 
 course :-)

 Abdel.

 

Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Miki Dovrat wrote:
I was going to say, let the cursor always stay where it is, and the user 
will learn to press END (end of line) to move it to continue typing. It is 
logical, (not in the logical direction sense), expected and easily adapted 
to by the user, as there are no surprises there.


It doesn't seem logical at all to me, though I guess I user could get 
used to it. But I'm glad you've dropped this idea... ;)




Abdel's idea is even better. I second it.

When writing, lyx will assume you want to jump to the end of line, but when 
editing, it will assume you don't!!


How does one differentiate between writing and editing? By whether 
I'm at the end of a paragraph or not?


This is what (I think) I said somewhere in this thread: in order to get 
the behavior to be more intuitive, you have to start using heuristics 
which try to figure out what did the user mean this time?. And the 
nature of heuristics is that they are sometimes right, sometimes wrong; 
and they certainly make the code more complicated. So yes, it's a 
possibility, but we should consider carefully if the heuristics are 
correct, and whether we want to implement them in each case...




Miki

Abdelrazak Younes [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]

Dov Feldstern wrote:


, unless the user explicitly changes it with F12 (\language hebrew),
the cursor will NOT MOVE, and the text will be added where it was, 
whether it was English or Hebrew.
Again, this doesn't make sense when typing. It means after every 
insertion of an english word, you'll have to move the cursor before 
continuing to type in hebrew...
No, in Visual mode, when LyX detect an RTL characters the insertion should 
happen at the right place. IOW, the jumping will happen at _writing_ time 
not at cursor navigation time like in so-called 'logical mode'. IMHO of 
course :-)


Abdel.

Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Dov Feldstern wrote:

Miki Dovrat wrote:
I was going to say, let the cursor always stay where it is, and the 
user will learn to press END (end of line) to move it to continue 
typing. It is logical, (not in the logical direction sense), 
expected and easily adapted to by the user, as there are no surprises 
there.


It doesn't seem logical at all to me, though I guess I user could get 
used to it. But I'm glad you've dropped this idea... ;)




Abdel's idea is even better. I second it.

When writing, lyx will assume you want to jump to the end of line, but 
when editing, it will assume you don't!!


How does one differentiate between writing and editing? By whether 
I'm at the end of a paragraph or not?


This is what (I think) I said somewhere in this thread: in order to get 
the behavior to be more intuitive, you have to start using heuristics 
which try to figure out what did the user mean this time?. And the 
nature of heuristics is that they are sometimes right, sometimes wrong; 
and they certainly make the code more complicated. So yes, it's a 
possibility, but we should consider carefully if the heuristics are 
correct, and whether we want to implement them in each case...




Also, heuristics make the application behave differently in different 
situations (that's there purpose!) --- which means that the application 
is less predictable unless the user exactly understands how the 
heuristic works...


Therefore, I would try to stay away from heuristics if possible, unless 
they are absolutely intuitive (and the heuristic that I provided above, 
I think, is not so intuitive).


And, the fact is, I think that in this specific case, LyX's behavior is 
perfectly logical and intuitive, and almost always what I want it to be. 
If you think otherwise, please explain again exactly what the specific 
situation is, how you got to that situation, and what you think LyX 
*should* do in that case...

Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Miki Dovrat]

Dov Feldstern wrote:

Dov Feldstern wrote:

Miki Dovrat wrote:
I was going to say, let the cursor always stay where it is, and the 
user will learn to press END (end of line) to move it to continue 
typing. It is logical, (not in the logical direction sense), 
expected and easily adapted to by the user, as there are no surprises 
there.


It doesn't seem logical at all to me, though I guess I user could get 
used to it. But I'm glad you've dropped this idea... ;)




Abdel's idea is even better. I second it.

When writing, lyx will assume you want to jump to the end of line, 
but when editing, it will assume you don't!!


How does one differentiate between writing and editing? By whether 
I'm at the end of a paragraph or not?


This is what (I think) I said somewhere in this thread: in order to 
get the behavior to be more intuitive, you have to start using 
heuristics which try to figure out what did the user mean this 
time?. And the nature of heuristics is that they are sometimes right, 
sometimes wrong; and they certainly make the code more complicated. So 
yes, it's a possibility, but we should consider carefully if the 
heuristics are correct, and whether we want to implement them in each 
case...




Also, heuristics make the application behave differently in different 
situations (that's there purpose!) --- which means that the application 
is less predictable unless the user exactly understands how the 
heuristic works...


Therefore, I would try to stay away from heuristics if possible, unless 
they are absolutely intuitive (and the heuristic that I provided above, 
I think, is not so intuitive).


And, the fact is, I think that in this specific case, LyX's behavior is 
perfectly logical and intuitive, and almost always what I want it to be. 
If you think otherwise, please explain again exactly what the specific 
situation is, how you got to that situation, and what you think LyX 
*should* do in that case...





I don't agree with you that lyx's behavior is perfectly logical and 
intuitive on this issue. You have open office by your side, as it 
behaves in the same (annoying) way (logical).


I see your point about heuristics being bad, I agree with that.

We have two conflicting demands here - You seem to like continuous 
typing and expect that F12 pressed (the second time) will jump to the 
end of the foreign text so that you can continue typing. That is a good 
expectation.


What I expect is that when I see the cursor in one position, the 
characters I type will actually get inserted IN THAT POSITION.


You can get used to pressing END (it seems that I somehow learned to do 
that using Word), and I can get used to going back one space and 
continuing from there, but which is more intuitive and less confusing? 
I think the confusing part is when the cursor jumps. You seem to already 
know that the cursor will jump and it doesn't bother you. It is very 
annoying to me that I have to understand about borders between RTL and 
LTR and to know that lyx isn't going to continue where the cursor is.


We need a mediator to rule, but it seems that you will be writing the 
code, so you have an advantage :)


Miki

Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Miki Dovrat]

Dov Feldstern wrote:

Dov Feldstern wrote:

Miki Dovrat wrote:
I was going to say, let the cursor always stay where it is, and the 
user will learn to press END (end of line) to move it to continue 
typing. It is logical, (not in the logical direction sense), 
expected and easily adapted to by the user, as there are no surprises 
there.


It doesn't seem logical at all to me, though I guess I user could get 
used to it. But I'm glad you've dropped this idea... ;)




Abdel's idea is even better. I second it.

When writing, lyx will assume you want to jump to the end of line, 
but when editing, it will assume you don't!!


How does one differentiate between writing and editing? By whether 
I'm at the end of a paragraph or not?


This is what (I think) I said somewhere in this thread: in order to 
get the behavior to be more intuitive, you have to start using 
heuristics which try to figure out what did the user mean this 
time?. And the nature of heuristics is that they are sometimes right, 
sometimes wrong; and they certainly make the code more complicated. So 
yes, it's a possibility, but we should consider carefully if the 
heuristics are correct, and whether we want to implement them in each 
case...




Also, heuristics make the application behave differently in different 
situations (that's there purpose!) --- which means that the application 
is less predictable unless the user exactly understands how the 
heuristic works...


Therefore, I would try to stay away from heuristics if possible, unless 
they are absolutely intuitive (and the heuristic that I provided above, 
I think, is not so intuitive).


And, the fact is, I think that in this specific case, LyX's behavior is 
perfectly logical and intuitive, and almost always what I want it to be. 
If you think otherwise, please explain again exactly what the specific 
situation is, how you got to that situation, and what you think LyX 
*should* do in that case...




Dov,

did you direct me to here in response to bug 3011?

Well, anyway, your fix for 3011 is working. I have version 18791.

Miki

I have found something very strange!!! a feature? Try this:
I changed my document to Hebrew, so that English gets marked foreign.

Type a line (starting with RTL) such as LTR LTR LTR  RTL RTL RTL

Now, in the border between LTR and RTL, to the LEFT of the space, it 
would seem that this is one cursor position, but with the mouse I can 
actually hit TWO points there (still to the left of the space but to the 
right of the English writing): one position continues the Hebrew, and 
the other position continues the English (the cursor is underlined).


Now, it would seem that IF the arrow keys could move through these two 
states (in our future visual mode, where the cursor will move without 
jumping to the beginning of English, but through the end of it) it would 
solve our conflict, as the cursor will tell us what is going to happen 
while editing. When you come from RTL, it will first be RTL, another - 
will move you to LTR (the end of it), and other - will move you 
backwards in the English, and while typing you would keep moving to the 
end of the line when pressing F12 for continuous typing like you want 
(which makes more sense to me now). That is OK by me, and it will 
actually be very good I think.


What do you think?

Currently, the arrow keys miss the continue English writing position 
since the behavior is logical, and the cursor goes directly to (ONE 
AFTER) the beginning of the English in logical mode.  I still don't 
understand why it jumps to one after the beginning of the foreign part. 
It could have easily have jumped to the beginning of English.


Miki

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Miki Dovrat]

Hi,
My comments are below

Miki


 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...

I would like lyx to be visual, and I think it will solve this problem, since 
the cursor will STAY PUT in the location it is in without jumping anywhere. 
In latex, you will have \L's and \R's all over the place, and you can clean 
that up "later" - maybe when saving, maybe when leaving the row. I don't 
know enough about what lyx does (I wanted to get into it but I lack the 
time, maybe in the future...)

To sum up, I would like lyx, when it is inside a \L (English), to switch 
automatically to English, unless the user explicitly changes it with F12 
(\language hebrew), the cursor will NOT MOVE, and the text will be added 
where it was, whether it was English or Hebrew.

When moving across already written text, lyx, when spotting a move between 
\L and \R should move visually, i.e., to the end of the foreign text and go 
backwards (so the arrow keys move to the right direction), and change its 
language as well, again, unless explicitly changed by the user by pressing 
F12.

Lyx should then understand about spaces being adjacent visually, not 
logically, and fix adjacent spaces between RTL and LTR this way.

Is that not simpler to understand, as far as a user is concerned? I am not 
referring to coding problems here. Can that be accomplished?

>>
 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?

Is it already in svn? if not, where is the patch? I will check.

 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 

was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Separating this into different issues, it's getting long...

Miki Dovrat wrote:

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...


I would like lyx to be visual, and I think it will solve this problem, since 
the cursor will STAY PUT in the location it is in without jumping anywhere. 


That will work when moving, but not when typing: when you type in 
hebrew, and then switch to english, and then back to hebrew --- where do 
you want the hebrew to continue: to the left or to the right of the 
english? I want it to continue on the left: usually I type in logical 
order, not first all the hebrew and then go back and insert the english...


In latex, you will have \L's and \R's all over the place, and you can clean 
that up "later" - maybe when saving, maybe when leaving the row. I don't 
know enough about what lyx does (I wanted to get into it but I lack the 
time, maybe in the future...)


To sum up, I would like lyx, when it is inside a \L (English), to switch 
automatically to English


I believe it does this...


, unless the user explicitly changes it with F12 (\language hebrew),
the cursor will NOT MOVE, and the text will be added 
where it was, whether it was English or Hebrew.


Again, this doesn't make sense when typing. It means after every 
insertion of an english word, you'll have to move the cursor before 
continuing to type in hebrew...

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Miki Dovrat wrote:


When moving across already written text, lyx, when spotting a move between 
\L and \R should move visually, i.e., to the end of the foreign text and go 
backwards (so the arrow keys move to the right direction), and change its 
language as well, again, unless explicitly changed by the user by pressing 
F12.


Regarding visual movement, I agree that it would solve some (not all!) 
of these issues. But I also think that implementing visual movement 
correctly will require some refactoring of the cursor movement code. I 
hope to get working on it soon, but even if it is ready before 1.5.0 is 
released, I'm not sure that those kinds of changes should go in at this 
point. And in that case, I'd rather focus in the meantime on issues 
which can, perhaps, be fixed for 1.5.0.

Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Abdelrazak Younes]

Dov Feldstern wrote:


, unless the user explicitly changes it with F12 (\language hebrew),
the cursor will NOT MOVE, and the text will be added where it was, 
whether it was English or Hebrew.


Again, this doesn't make sense when typing. It means after every 
insertion of an english word, you'll have to move the cursor before 
continuing to type in hebrew...


No, in Visual mode, when LyX detect an RTL characters the insertion 
should happen at the right place. IOW, the jumping will happen at 
_writing_ time not at cursor navigation time like in so-called 'logical 
mode'. IMHO of course :-)


Abdel.

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Abdelrazak Younes]

Miki Dovrat wrote:
To sum up, I would like lyx, when it is inside a \L (English), to switch 
automatically to English, unless the user explicitly changes it with F12 
(\language hebrew), the cursor will NOT MOVE, and the text will be added 
where it was, whether it was English or Hebrew.


When moving across already written text, lyx, when spotting a move between 
\L and \R should move visually, i.e., to the end of the foreign text and go 
backwards (so the arrow keys move to the right direction), and change its 
language as well, again, unless explicitly changed by the user by pressing 
F12.


Lyx should then understand about spaces being adjacent visually, not 
logically, and fix adjacent spaces between RTL and LTR this way.


Is that not simpler to understand, as far as a user is concerned?


FWIW I 100% agree with you but I am not (yet) an RTL writer :-)

I am not 
referring to coding problems here. Can that be accomplished?


I believe it would be simpler to achieve than the current complicated 
logical navigation. The difficult part would be the automagic insertion 
at the right place.


Abdel.

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Abdelrazak Younes]

Dov Feldstern wrote:

Miki Dovrat wrote:


When moving across already written text, lyx, when spotting a move 
between \L and \R should move visually, i.e., to the end of the 
foreign text and go backwards (so the arrow keys move to the right 
direction), and change its language as well, again, unless explicitly 
changed by the user by pressing F12.


Regarding visual movement, I agree that it would solve some (not all!) 
of these issues. But I also think that implementing visual movement 
correctly will require some refactoring of the cursor movement code. I 
hope to get working on it soon, but even if it is ready before 1.5.0 is 
released, I'm not sure that those kinds of changes should go in at this 
point. And in that case, I'd rather focus in the meantime on issues 
which can, perhaps, be fixed for 1.5.0.


Agreed :-)

Abdel.

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Miki Dovrat wrote:

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?


Is it already in svn? if not, where is the patch? I will check.


See http://permalink.gmane.org/gmane.editors.lyx.devel/87817. Let's 
continue the discussion of this issue in response to that thread.

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Dov Feldstern wrote:

Miki Dovrat wrote:



Are these solved with the above-mentioned fix?


Is it already in svn? if not, where is the patch? I will check.


See http://permalink.gmane.org/gmane.editors.lyx.devel/87817. Let's 
continue the discussion of this issue in response to that thread.





Sorry, wrong link. Anyhow, this is committed now (r18781).

Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Miki Dovrat]

I was going to say, let the cursor always stay where it is, and the user 
will learn to press END (end of line) to move it to continue typing. It is 
logical, (not in the "logical" direction sense), expected and easily adapted 
to by the user, as there are no surprises there.

Abdel's idea is even better. I second it.

When writing, lyx will assume you want to jump to the end of line, but when 
editing, it will assume you don't!!

Miki

"Abdelrazak Younes" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
> Dov Feldstern wrote:
>
>>> , unless the user explicitly changes it with F12 (\language hebrew),
>>> the cursor will NOT MOVE, and the text will be added where it was, 
>>> whether it was English or Hebrew.
>>
>> Again, this doesn't make sense when typing. It means after every 
>> insertion of an english word, you'll have to move the cursor before 
>> continuing to type in hebrew...
>
> No, in Visual mode, when LyX detect an RTL characters the insertion should 
> happen at the right place. IOW, the jumping will happen at _writing_ time 
> not at cursor navigation time like in so-called 'logical mode'. IMHO of 
> course :-)
>
> Abdel.
>
> 

Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Miki Dovrat wrote:
I was going to say, let the cursor always stay where it is, and the user 
will learn to press END (end of line) to move it to continue typing. It is 
logical, (not in the "logical" direction sense), expected and easily adapted 
to by the user, as there are no surprises there.


It doesn't seem logical at all to me, though I guess I user could get 
used to it. But I'm glad you've dropped this idea... ;)




Abdel's idea is even better. I second it.

When writing, lyx will assume you want to jump to the end of line, but when 
editing, it will assume you don't!!


How does one differentiate between "writing" and "editing"? By whether 
I'm at the end of a paragraph or not?


This is what (I think) I said somewhere in this thread: in order to get 
the behavior to be more intuitive, you have to start using heuristics 
which try to figure out "what did the user mean this time?". And the 
nature of heuristics is that they are sometimes right, sometimes wrong; 
and they certainly make the code more complicated. So yes, it's a 
possibility, but we should consider carefully if the heuristics are 
correct, and whether we want to implement them in each case...




Miki

"Abdelrazak Younes" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]

Dov Feldstern wrote:


, unless the user explicitly changes it with F12 (\language hebrew),
the cursor will NOT MOVE, and the text will be added where it was, 
whether it was English or Hebrew.
Again, this doesn't make sense when typing. It means after every 
insertion of an english word, you'll have to move the cursor before 
continuing to type in hebrew...
No, in Visual mode, when LyX detect an RTL characters the insertion should 
happen at the right place. IOW, the jumping will happen at _writing_ time 
not at cursor navigation time like in so-called 'logical mode'. IMHO of 
course :-)


Abdel.

Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Dov Feldstern wrote:

Miki Dovrat wrote:
I was going to say, let the cursor always stay where it is, and the 
user will learn to press END (end of line) to move it to continue 
typing. It is logical, (not in the "logical" direction sense), 
expected and easily adapted to by the user, as there are no surprises 
there.


It doesn't seem logical at all to me, though I guess I user could get 
used to it. But I'm glad you've dropped this idea... ;)




Abdel's idea is even better. I second it.

When writing, lyx will assume you want to jump to the end of line, but 
when editing, it will assume you don't!!


How does one differentiate between "writing" and "editing"? By whether 
I'm at the end of a paragraph or not?


This is what (I think) I said somewhere in this thread: in order to get 
the behavior to be more intuitive, you have to start using heuristics 
which try to figure out "what did the user mean this time?". And the 
nature of heuristics is that they are sometimes right, sometimes wrong; 
and they certainly make the code more complicated. So yes, it's a 
possibility, but we should consider carefully if the heuristics are 
correct, and whether we want to implement them in each case...




Also, heuristics make the application behave differently in different 
situations (that's there purpose!) --- which means that the application 
is less predictable unless the user exactly understands how the 
heuristic works...


Therefore, I would try to stay away from heuristics if possible, unless 
they are absolutely intuitive (and the heuristic that I provided above, 
I think, is not so intuitive).


And, the fact is, I think that in this specific case, LyX's behavior is 
perfectly logical and intuitive, and almost always what I want it to be. 
If you think otherwise, please explain again exactly what the specific 
situation is, how you got to that situation, and what you think LyX 
*should* do in that case...

Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Miki Dovrat]

Dov Feldstern wrote:

Dov Feldstern wrote:

Miki Dovrat wrote:
I was going to say, let the cursor always stay where it is, and the 
user will learn to press END (end of line) to move it to continue 
typing. It is logical, (not in the "logical" direction sense), 
expected and easily adapted to by the user, as there are no surprises 
there.


It doesn't seem logical at all to me, though I guess I user could get 
used to it. But I'm glad you've dropped this idea... ;)




Abdel's idea is even better. I second it.

When writing, lyx will assume you want to jump to the end of line, 
but when editing, it will assume you don't!!


How does one differentiate between "writing" and "editing"? By whether 
I'm at the end of a paragraph or not?


This is what (I think) I said somewhere in this thread: in order to 
get the behavior to be more intuitive, you have to start using 
heuristics which try to figure out "what did the user mean this 
time?". And the nature of heuristics is that they are sometimes right, 
sometimes wrong; and they certainly make the code more complicated. So 
yes, it's a possibility, but we should consider carefully if the 
heuristics are correct, and whether we want to implement them in each 
case...




Also, heuristics make the application behave differently in different 
situations (that's there purpose!) --- which means that the application 
is less predictable unless the user exactly understands how the 
heuristic works...


Therefore, I would try to stay away from heuristics if possible, unless 
they are absolutely intuitive (and the heuristic that I provided above, 
I think, is not so intuitive).


And, the fact is, I think that in this specific case, LyX's behavior is 
perfectly logical and intuitive, and almost always what I want it to be. 
If you think otherwise, please explain again exactly what the specific 
situation is, how you got to that situation, and what you think LyX 
*should* do in that case...





I don't agree with you that lyx's behavior is perfectly logical and 
intuitive on this issue. You have open office by your side, as it 
behaves in the same (annoying) way (logical).


I see your point about heuristics being bad, I agree with that.

We have two conflicting "demands" here - You seem to like continuous 
typing and expect that F12 pressed (the second time) will jump to the 
end of the foreign text so that you can continue typing. That is a good 
expectation.


What I expect is that when I see the cursor in one position, the 
characters I type will actually get inserted IN THAT POSITION.


You can get used to pressing END (it seems that I somehow learned to do 
that using Word), and I can get used to going back one space and 
continuing from there, but which is more intuitive and less confusing? 
I think the confusing part is when the cursor jumps. You seem to already 
know that the cursor will jump and it doesn't bother you. It is very 
annoying to me that I have to understand about borders between RTL and 
LTR and to know that lyx isn't going to continue where the cursor is.


We need a mediator to rule, but it seems that you will be writing the 
code, so you have an advantage :)


Miki

Re: was: Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Miki Dovrat]

Dov Feldstern wrote:

Dov Feldstern wrote:

Miki Dovrat wrote:
I was going to say, let the cursor always stay where it is, and the 
user will learn to press END (end of line) to move it to continue 
typing. It is logical, (not in the "logical" direction sense), 
expected and easily adapted to by the user, as there are no surprises 
there.


It doesn't seem logical at all to me, though I guess I user could get 
used to it. But I'm glad you've dropped this idea... ;)




Abdel's idea is even better. I second it.

When writing, lyx will assume you want to jump to the end of line, 
but when editing, it will assume you don't!!


How does one differentiate between "writing" and "editing"? By whether 
I'm at the end of a paragraph or not?


This is what (I think) I said somewhere in this thread: in order to 
get the behavior to be more intuitive, you have to start using 
heuristics which try to figure out "what did the user mean this 
time?". And the nature of heuristics is that they are sometimes right, 
sometimes wrong; and they certainly make the code more complicated. So 
yes, it's a possibility, but we should consider carefully if the 
heuristics are correct, and whether we want to implement them in each 
case...




Also, heuristics make the application behave differently in different 
situations (that's there purpose!) --- which means that the application 
is less predictable unless the user exactly understands how the 
heuristic works...


Therefore, I would try to stay away from heuristics if possible, unless 
they are absolutely intuitive (and the heuristic that I provided above, 
I think, is not so intuitive).


And, the fact is, I think that in this specific case, LyX's behavior is 
perfectly logical and intuitive, and almost always what I want it to be. 
If you think otherwise, please explain again exactly what the specific 
situation is, how you got to that situation, and what you think LyX 
*should* do in that case...




Dov,

did you direct me to here in response to bug 3011?

Well, anyway, your fix for 3011 is working. I have version 18791.

Miki

I have found something very strange!!! a feature? Try this:
I changed my document to Hebrew, so that English gets marked foreign.

Type a line (starting with RTL) such as LTR LTR LTR  RTL RTL RTL

Now, in the border between LTR and RTL, to the LEFT of the space, it 
would seem that this is one cursor position, but with the mouse I can 
actually hit TWO points there (still to the left of the space but to the 
right of the English writing): one position continues the Hebrew, and 
the other position continues the English (the cursor is underlined).


Now, it would seem that IF the arrow keys could move through these two 
states (in our future visual mode, where the cursor will move without 
jumping to the beginning of English, but through the end of it) it would 
solve our conflict, as the cursor will tell us what is going to happen 
while editing. When you come from RTL, it will first be RTL, another <- 
will move you to LTR (the end of it), and other <- will move you 
backwards in the English, and while typing you would keep moving to the 
end of the line when pressing F12 for continuous typing like you want 
(which makes more sense to me now). That is OK by me, and it will 
actually be very good I think.


What do you think?

Currently, the arrow keys miss the "continue English writing" position 
since the behavior is logical, and the cursor goes directly to (ONE 
AFTER) the beginning of the English in logical mode.  I still don't 
understand why it jumps to one after the beginning of the foreign part. 
It could have easily have jumped to the beginning of English.


Miki

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Stefan Schimanski wrote:
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...


Didn't I post a patch for exactly this which somebody called not needed?

Stefan


I know, Stefan ;) .

I don't think I actually said that it was not needed. What I did say 
was that it's an additional layer on top of what we already put in, and 
that it would be easier to see what still needs to be done once we had 
the first part committed. I also said that the patch you sent was still 
not doing everything correctly --- and I'm still not sure what the 
correct thing to do is. Miki --- please do try Stefan's patch and see if 
it answers your needs, and if it doesn't maybe it's at least in the 
right direction. But I think we need to figure out what should be done, 
if anything, before writing more patches, and I'm still not clear on that...


Dov

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Stefan Schimanski wrote:
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...


Didn't I post a patch for exactly this which somebody called "not needed"?

Stefan


I know, Stefan ;) .

I don't think I actually said that it was "not needed". What I did say 
was that it's an additional layer on top of what we already put in, and 
that it would be easier to see what still needs to be done once we had 
the first part committed. I also said that the patch you sent was still 
not doing everything correctly --- and I'm still not sure what the 
correct thing to do is. Miki --- please do try Stefan's patch and see if 
it answers your needs, and if it doesn't maybe it's at least in the 
right direction. But I think we need to figure out what should be done, 
if anything, before writing more patches, and I'm still not clear on that...


Dov

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Miki Dovrat]

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 

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

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 

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Stefan Schimanski]

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...


Didn't I post a patch for exactly this which somebody called not  
needed?


Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Miki Dovrat]

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...

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

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 

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Stefan Schimanski]

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...


Didn't I post a patch for exactly this which somebody called "not  
needed"?


Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Miki Dovrat]

Hi,

I am using lyx svn version 18738 from Monday night.

I have found a few problems with the Bidi:

1. Cursor movement is not yet visual, i.e. the cursor goes opposite to 
the arrow key on foreign parts. I don't know if it was your intention to 
include that already.


2. I can't tell whether to use backspace or delete, since cursor isn't 
visual.


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.


4. Going backwards, when the cursor finishes the English word, it jumps 
to before the hebrew space, and stays in English mode, so that if I 
press a letter it comes out English even though I am in Hebrew.


5. Going forward, when the cursor moves one position after the hebrew 
space, the position jumps to one after the the first English character 
(i.e. to between E and n in English) and it is still in Hebrew mode, so 
the letter I enter is hebrew.


6. I cannot enter an inline equation to the right of the English word. 
It jumps to the left of it.  I can trick lyx into doing this by entering 
the equation to the right of the boundary space, near the Hebrew part, 
and then adding the space between the hebrew word and the equation. The 
space between the word English and my equation is RTL. My equation is 
marked RTL, if that makes any sense. If I delete the space between the 
equation and the English word, I cannot put it back again. If I enter a 
LTR space, it gets deleted. I can't enter a RTL space (see paragraph 3).


7. Same for equation to the left of English text, If I enter it to the 
left of the word English, then it's OK (its LTR, but before the word 
English, i.e. to its left). If I enter it to the left of the Hebrew 
space (to the left of the word English), it is marked RTL, and if I 
delete the space between it and the English word, I can't put it back 
again. If I try a LTR space, it isn't entered. F12 jumps the cursor to 
the right of the English word.


8. I can't insert a cross reference to the right of English text. It 
jumps to the left of it. You can enter it to the left of Hebrew text, 
and then delete the space, and then add the Hebrew space.


9. Why do equations get marked LTR?

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.


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.


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.


13. Same as 11 and 12 but for Hebrew words between already typed English.

I am sure there are more :)
sorry to be picky.

In my opinion, these problems are SERIOUS and really handicap lyx as a 
Hebrew typesetter at this point. They make serious work with Hebrew 
technical document (with lots of English terms in it, references and 
equations) in lyx very annoying and cumbersome.
All of these can be fixed by voodoo such as starting a fresh 
paragraph, and then deleting the carriage return and such solutions, but 
I urge you to try and fix it before the release. Please?


If anything isn't clear in my examples, don't hesitate to ask and I will 
clarify what I meant.


Miki

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Miki Dovrat wrote:

Hi,



Hi, Miki!


I am using lyx svn version 18738 from Monday night.


Good!



I have found a few problems with the Bidi:

1. Cursor movement is not yet visual, i.e. the cursor goes opposite to 
the arrow key on foreign parts. I don't know if it was your intention to 
include that already.




No, Visual movement may not be done before 1.5.0. I hope that by 1.5.1 
we'll have it...


2. I can't tell whether to use backspace or delete, since cursor isn't 
visual.




Yes, this is a problem (and will be a problem in Visual mode, too, as 
backspace by convention is considered a logical action, and thus will 
*always* delete the *logically* previous character. That's what it 
should be doing now, too, if not --- it's a bug.)


So:
a. it's good that we have undo ;)
b. what I sometimes do is SHIFT+RIGHT/LEFT to select what I want to 
delete, that way I see what's about to be deleted, and then delete...



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.


In general, the idea is that on the borders between LTR and RTL, you 
stay in the language that you are coming from. I believe this is the way 
most applications deal with this, and now LyX does too. Again, this 
problem will probably be solved with visual mode, hopefully not too long 
from now...




4. Going backwards, when the cursor finishes the English word, it jumps 
to before the hebrew space, and stays in English mode, so that if I 
press a letter it comes out English even though I am in Hebrew.


This is a different issue, it's a bug with the keymap, which I have a 
patch for waiting to be OKed. (see bug 3811)




5. Going forward, when the cursor moves one position after the hebrew 
space, the position jumps to one after the the first English character 
(i.e. to between E and n in English) and it is still in Hebrew mode, so 
the letter I enter is hebrew.


Same as 4.



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.


It jumps to the left of it.  I can trick lyx into doing this by entering 
the equation to the right of the boundary space, near the Hebrew part, 
and then adding the space between the hebrew word and the equation. The 
space between the word English and my equation is RTL. My equation is 
marked RTL, if that makes any sense.


Yes, the inset is marked as RTL, which is separate from what's inside 
it (try this with a footnote, where the text inside can also be RTL: 
you'll see that the language of the inset and the language of the text 
inside it are independent). I don't know if this is intentional or not, 
but I think that it does make a certain amount of sense. The problem 
above is just the the inset is not keeping the current language, but 
rather reverting to the paragraph's language...


If I delete the space between the 
equation and the English word, I cannot put it back again. If I enter a 
LTR space, it gets deleted. I can't enter a RTL space (see paragraph 3).


7. Same for equation to the left of English text, If I enter it to the 
left of the word English, then it's OK (its LTR, but before the word 
English, i.e. to its left). If I enter it to the left of the Hebrew 
space (to the left of the word English), it is marked RTL, and if I 
delete the space between it and the English word, I can't put it back 
again. If I try a LTR space, it isn't entered. F12 jumps the cursor to 
the right of the English word.


8. I can't insert a cross reference to the right of English text. It 
jumps to the left of it. You can enter it to the left of Hebrew text, 
and then delete the space, and then add the Hebrew space.




7, 8 seem to be the same issue as in 6...?

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Miki Dovrat]

Hi,

I am using lyx svn version 18738 from Monday night.

I have found a few problems with the Bidi:

1. Cursor movement is not yet visual, i.e. the cursor goes opposite to 
the arrow key on foreign parts. I don't know if it was your intention to 
include that already.


2. I can't tell whether to use backspace or delete, since cursor isn't 
visual.


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.


4. Going backwards, when the cursor finishes the English word, it jumps 
to before the hebrew space, and stays in English mode, so that if I 
press a letter it comes out English even though I am in Hebrew.


5. Going forward, when the cursor moves one position after the hebrew 
space, the position jumps to one after the the first English character 
(i.e. to between E and n in English) and it is still in Hebrew mode, so 
the letter I enter is hebrew.


6. I cannot enter an inline equation to the right of the English word. 
It jumps to the left of it.  I can trick lyx into doing this by entering 
the equation to the right of the boundary space, near the Hebrew part, 
and then adding the space between the hebrew word and the equation. The 
space between the word "English" and my equation is RTL. My equation is 
marked RTL, if that makes any sense. If I delete the space between the 
equation and the English word, I cannot put it back again. If I enter a 
LTR space, it gets deleted. I can't enter a RTL space (see paragraph 3).


7. Same for equation to the left of English text, If I enter it to the 
left of the word "English", then it's OK (its LTR, but before the word 
"English", i.e. to its left). If I enter it to the left of the Hebrew 
space (to the left of the word "English"), it is marked RTL, and if I 
delete the space between it and the English word, I can't put it back 
again. If I try a LTR space, it isn't entered. F12 jumps the cursor to 
the right of the English word.


8. I can't insert a cross reference to the right of English text. It 
jumps to the left of it. You can enter it to the left of Hebrew text, 
and then delete the space, and then add the Hebrew space.


9. Why do equations get marked LTR?

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.


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.


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.


13. Same as 11 and 12 but for Hebrew words between already typed English.

I am sure there are more :)
sorry to be picky.

In my opinion, these problems are SERIOUS and really handicap lyx as a 
Hebrew typesetter at this point. They make serious work with Hebrew 
technical document (with lots of English terms in it, references and 
equations) in lyx very annoying and cumbersome.
All of these can be fixed by "voodoo" such as starting a fresh 
paragraph, and then deleting the carriage return and such solutions, but 
I urge you to try and fix it before the release. Please?


If anything isn't clear in my examples, don't hesitate to ask and I will 
clarify what I meant.


Miki

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Miki Dovrat wrote:

Hi,



Hi, Miki!


I am using lyx svn version 18738 from Monday night.


Good!



I have found a few problems with the Bidi:

1. Cursor movement is not yet visual, i.e. the cursor goes opposite to 
the arrow key on foreign parts. I don't know if it was your intention to 
include that already.




No, Visual movement may not be done before 1.5.0. I hope that by 1.5.1 
we'll have it...


2. I can't tell whether to use backspace or delete, since cursor isn't 
visual.




Yes, this is a problem (and will be a problem in Visual mode, too, as 
backspace by convention is considered a "logical" action, and thus will 
*always* delete the *logically* previous character. That's what it 
should be doing now, too, if not --- it's a bug.)


So:
a. it's good that we have undo ;)
b. what I sometimes do is SHIFT+RIGHT/LEFT to select what I want to 
delete, that way I see what's about to be deleted, and then delete...



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.


In general, the idea is that on the borders between LTR and RTL, you 
stay in the language that you are coming from. I believe this is the way 
most applications deal with this, and now LyX does too. Again, this 
problem will probably be solved with visual mode, hopefully not too long 
from now...




4. Going backwards, when the cursor finishes the English word, it jumps 
to before the hebrew space, and stays in English mode, so that if I 
press a letter it comes out English even though I am in Hebrew.


This is a different issue, it's a bug with the keymap, which I have a 
patch for waiting to be OKed. (see bug 3811)




5. Going forward, when the cursor moves one position after the hebrew 
space, the position jumps to one after the the first English character 
(i.e. to between E and n in English) and it is still in Hebrew mode, so 
the letter I enter is hebrew.


Same as 4.



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.


It jumps to the left of it.  I can trick lyx into doing this by entering 
the equation to the right of the boundary space, near the Hebrew part, 
and then adding the space between the hebrew word and the equation. The 
space between the word "English" and my equation is RTL. My equation is 
marked RTL, if that makes any sense.


Yes, the "inset" is marked as RTL, which is separate from what's inside 
it (try this with a footnote, where the text inside can also be RTL: 
you'll see that the language of the inset and the language of the text 
inside it are independent). I don't know if this is intentional or not, 
but I think that it does make a certain amount of sense. The problem 
above is just the the inset is not keeping the "current" language, but 
rather reverting to the paragraph's language...


If I delete the space between the 
equation and the English word, I cannot put it back again. If I enter a 
LTR space, it gets deleted. I can't enter a RTL space (see paragraph 3).


7. Same for equation to the left of English text, If I enter it to the 
left of the word "English", then it's OK (its LTR, but before the word 
"English", i.e. to its left). If I enter it to the left of the Hebrew 
space (to the left of the word "English"), it is marked RTL, and if I 
delete the space between it and the English word, I can't put it back 
again. If I try a LTR space, it isn't entered. F12 jumps the cursor to 
the right of the English word.


8. I can't insert a cross reference to the right of English text. It 
jumps to the left of it. You can enter it to the left of Hebrew text, 
and then delete the space, and then add the Hebrew space.




7, 8 seem to be the same 

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Stefan Schimanski]

Thank you for your feedback.


אבג space F!2abcspaceF12 דהו

I get

אבג [ abc]דהו


Yes, that is what I would expect from the current implementation ( only 
the space should be eliminated. Will check that.


when I move back (to the space) with the cursor the extra space is 
eliminated (I've attached a screenshot to show how it looks on screen). 
If I do the same thing in Lyx 1.4 (I guess it's the same as lyx1.5 
without the patches) it results in


אבג [abc] דהו


In LyX 1.5 RC1 you will also get this, but internally (and later when 
exporting to Latex!) you get the upper behavior.


But you have a point here. Maybe one can do something about it when 
inserting character? Don't know yet.


Stefan

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Stefan Schimanski]

Thank you for your feedback.


אבג  abc דהו

I get

אבג [ abc]דהו


Yes, that is what I would expect from the current implementation ( only 
the space should be eliminated. Will check that.


when I move back (to the space) with the cursor the extra space is 
eliminated (I've attached a screenshot to show how it looks on screen). 
If I do the same thing in Lyx 1.4 (I guess it's the same as lyx1.5 
without the patches) it results in


אבג [abc] דהו


In LyX 1.5 RC1 you will also get this, but internally (and later when 
exporting to Latex!) you get the upper behavior.


But you have a point here. Maybe one can do something about it when 
inserting character? Don't know yet.


Stefan

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Stefan Schimanski]

I think we have basically two things to discuss now:

1) the space issue at the boundaries between RTL/LTR
2) the visual movement

Maybe we should seperate it to keep the overview, using two different  
topics...


Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Hi,

If you need help testing the RTL support I'm willing to help as much as I can. I
write most of my files in Hebrew and therefore I use RTL a lot.
I may need a bit of guiding on how to compile the patches... (I don't have much
experience in using patches).

Sincerely,
Ran Rutenberg




Hi Ran (and any other would-be Bidi testers),

Please try out the patches from 
http://permalink.gmane.org/gmane.editors.lyx.devel/86921 and let us know 
(preferably in a reply to that thread, but I reply to here is also fine) 
how you feel about the proposed behavior.


Working with patches is as follows (this is for linux, I don't know how 
it's done on other platforms): given a source tree in ~/lyx-devel/ (you 
should usually svn update before applying the patches), and a patch file 
x.patch, you apply the patch like this:


 cd ~/lyx-devel
 patch -p1  x.patch

where the -p1 says that one level of the directory hierarchy in the 
patch file should be stripped in order to match with the current 
location: if you look at one of the above patches, you'll see that there 
are separate sections for each file, with a header that looks like this:


Index: lyx-devel/src/Bidi.cpp
===
--- lyx-devel.orig/src/Bidi.cpp2007-06-06 10:16:43.0 +0200
+++ lyx-devel/src/Bidi.cpp2007-06-06 10:38:19.0 +0200

since the path in the patch starts at lyx-devel/, and since you're 
already there, you want the first level to be stripped from the name, 
and from the current directory the file to patch should be found using 
only src/Bidi.cpp, without the leading lyx-devel (because you're 
already in it). Note that this would also work if your tree is called 
xyz rather than lyx-devel --- that's part of the beauty of path-stripping.


So you can just apply the patches one after the other (but the order is 
important).


To unapply a patch, just add the -R (reverse) flag. Of course, when 
unapplying, the opposite order should be used, i.e., the last patch 
applied should be removed first.


Finally, note that if for any reason your tree is different from the 
tree on which the patch was created (because you have local 
modifications, or just because the tree itself has been updated since 
the patch was created), the patch may not apply cleanly. In this case, 
the output will say something like failed to apply Hunk #3, and a 
reject file is created which tells you what was not applied. This is 
the slightly more complicated part if you're new to patches, but 
hopefully for now you won't have to deal with it...


Hope this helps!
Dov

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Guy Rutenberg]

Hi,

Dov Feldstern [EMAIL PROTECTED] writes:



Hi Ran (and any other would-be Bidi testers),

Please try out the patches from
http://permalink.gmane.org/gmane.editors.lyx.devel/86921 and let us know
(preferably in a reply to that thread, but I reply to here is also fine)
how you feel about the proposed behavior.



I've applied the four patches in that post. It looks good and doesn't cause
problems.
I found still a small bug in functionality
if I type
אבג space F!2abcspaceF12 דהו

I get

אבג [ abc]דהו

when I move back (to the space) with the cursor the extra space is
eliminated (I've attached a screenshot to show how it looks on screen). If I
do the same thing in Lyx 1.4 (I guess it's the same as lyx1.5 without the
patches) it results in

אבג [abc] דהו

which is bettter in my opinion. The important thing is that Lyx 1.4 only
moves the space after I type דהו in hebrew so that the space doesn't
change location wrongly  as it would if the English text would also be typed
in RTL.

The first image(screenshot11.png) shows the result of the input in lyx
1.5with the patches, and the second one in lyx
1.4. I prefer the result in lyx 1.4 as it's more intuitive I think for the
user.

Regards,

Guy
attachment: screenshot12.pngattachment: screenshot11.png

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Stefan Schimanski]

I think we have basically two things to discuss now:

1) the space issue at the boundaries between RTL/LTR
2) the visual movement

Maybe we should seperate it to keep the overview, using two different  
topics...


Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Dov Feldstern]

Hi,

If you need help testing the RTL support I'm willing to help as much as I can. I
write most of my files in Hebrew and therefore I use RTL a lot.
I may need a bit of guiding on how to compile the patches... (I don't have much
experience in using patches).

Sincerely,
Ran Rutenberg




Hi Ran (and any other would-be Bidi testers),

Please try out the patches from 
http://permalink.gmane.org/gmane.editors.lyx.devel/86921 and let us know 
(preferably in a reply to that thread, but I reply to here is also fine) 
how you feel about the proposed behavior.


Working with patches is as follows (this is for linux, I don't know how 
it's done on other platforms): given a source tree in ~/lyx-devel/ (you 
should usually svn update before applying the patches), and a patch file 
x.patch, you apply the patch like this:


> cd ~/lyx-devel
> patch -p1 < x.patch

where the -p1 says that one level of the directory hierarchy in the 
patch file should be stripped in order to match with the current 
location: if you look at one of the above patches, you'll see that there 
are separate sections for each file, with a header that looks like this:


Index: lyx-devel/src/Bidi.cpp
===
--- lyx-devel.orig/src/Bidi.cpp2007-06-06 10:16:43.0 +0200
+++ lyx-devel/src/Bidi.cpp2007-06-06 10:38:19.0 +0200

since the path in the patch starts at lyx-devel/, and since you're 
already there, you want the first level to be stripped from the name, 
and from the current directory the file to patch should be found using 
only "src/Bidi.cpp", without the leading lyx-devel (because you're 
already in it). Note that this would also work if your tree is called 
xyz rather than lyx-devel --- that's part of the beauty of path-stripping.


So you can just apply the patches one after the other (but the order is 
important).


To unapply a patch, just add the -R (reverse) flag. Of course, when 
unapplying, the opposite order should be used, i.e., the last patch 
applied should be removed first.


Finally, note that if for any reason your tree is different from the 
tree on which the patch was created (because you have local 
modifications, or just because the tree itself has been updated since 
the patch was created), the patch may not apply cleanly. In this case, 
the output will say something like "failed to apply Hunk #3", and a 
"reject file" is created which tells you what was not applied. This is 
the slightly more complicated part if you're new to patches, but 
hopefully for now you won't have to deal with it...


Hope this helps!
Dov

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Guy Rutenberg]

Hi,

Dov Feldstern <[EMAIL PROTECTED]> writes:



Hi Ran (and any other would-be Bidi testers),

Please try out the patches from
http://permalink.gmane.org/gmane.editors.lyx.devel/86921 and let us know
(preferably in a reply to that thread, but I reply to here is also fine)
how you feel about the proposed behavior.



I've applied the four patches in that post. It looks good and doesn't cause
problems.
I found still a small bug in functionality
if I type
אבג  abc דהו

I get

אבג [ abc]דהו

when I move back (to the space) with the cursor the extra space is
eliminated (I've attached a screenshot to show how it looks on screen). If I
do the same thing in Lyx 1.4 (I guess it's the same as lyx1.5 without the
patches) it results in

אבג [abc] דהו

which is bettter in my opinion. The important thing is that Lyx 1.4 only
moves the space after I type "דהו" in hebrew so that the space doesn't
change location wrongly  as it would if the English text would also be typed
in RTL.

The first image(screenshot11.png) shows the result of the input in lyx
1.5with the patches, and the second one in lyx
1.4. I prefer the result in lyx 1.4 as it's more intuitive I think for the
user.

Regards,

Guy
<><>

WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Stefan Schimanski]

Hi!

Myself and Dov Feldstern are working on the support for Right-To-Left  
languages in LyX. In the latest RC1 there are many things which are  
not the way they should be. As we are not using Right-To-Left ourself  
we lack a bit the experience how it should look like and what is most  
convenient.


To get it right WE ARE LOOKING FOR:

  PEOPLE USING RTL languages and who are able and WILLING TO TRY OUT  
PATCHES

  against the subversion code and to compile it.

You don't have to be a developer, just user of a RTL language who  
wants to have LyX 1.5 to behave the right way (tm).


One decision which is open and must be settled:

THE SPACE ISSUE
===

What we are investigating right now is the handling of spaces on the  
boundary of RTL and LTR text. Take a look at the picture. The blue  
underline marks the character which have a RTL font. So the picture  
shows the four cases possible.


spaces.png
Description: application/applefile
inline: spaces.png

There are several possibilities now to interpret the underlined  
spaces (short RTL spaces):


* The LyX 1.3 magic way: the RTL spaces behave in fact like LTR  
spaces, i.e. they are put where non-underlined spaces would be. See  
this example:


  - In english WERBEH_english the _ is in fact behind the W
So in Latex you would write english\R{HEBREW } english

The consequence is that the cursor strangely (IMO) jumps from behind  
the W to the right in the moment you enter the space. If you have  
used LyX 1.3 you might be familiar with this behavior:


  english |WERBEHenglish == english WERBEH_|english

If you continue now typing a character the cursor (and the space)  
jumps back:


  english WERBEH_| == english |H_WERBEHenglish ==
  english H_WERBEH_|english

* The non-magic way: the spaces are no special characters. They stay  
at the position you type them. See this example:


  english |WERBEHenglish == english |_WERBEHenglish ==
  english |H_WERBEHenglish

If you change back to English and continue typing the cursor will go  
to the right, i.e.:


  == english H_WERBEH|english == english H_WERBEH |english

In Latex you would type the same:

  english \R{HEBREW H} english

Of course two spaces, one inside the RTL, one outside, are merged  
silently by Latex,

i.e. english \R{HEBREW } will look the same as english \R{HEBREW}.

If you have an opinion, please tell us.

Thanks
  Stefan Schimanski

PGP.sig
Description: Signierter Teil der Nachricht

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Pavel Sanda]

 You don't have to be a developer, just user of a RTL language who  
 wants to have LyX 1.5 to behave the right way (tm).

what about to post it to the user list ?
pavel

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Stefan Schimanski]

Am 05.06.2007 um 14:18 schrieb Pavel Sanda:


You don't have to be a developer, just user of a RTL language who
wants to have LyX 1.5 to behave the right way (tm).


That was my intention. Noticed it after it was sent. Sent it again to  
the users list, but it didn't show yet


Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Ran Rutenberg]

Stefan Schimanski [EMAIL PROTECTED] writes:

 Myself and Dov Feldstern are working on the support for Right-To-Left  
 languages in LyX. In the latest RC1 there are many things which are  
 not the way they should be. As we are not using Right-To-Left ourself  
 we lack a bit the experience how it should look like and what is most  
 convenient.
 
 To get it right WE ARE LOOKING FOR:
 
PEOPLE USING RTL languages and who are able and WILLING TO TRY OUT  
 PATCHES
against the subversion code and to compile it.
 
 You don't have to be a developer, just user of a RTL language who  
 wants to have LyX 1.5 to behave the right way (tm).



Hi,

If you need help testing the RTL support I'm willing to help as much as I can. I
write most of my files in Hebrew and therefore I use RTL a lot.
I may need a bit of guiding on how to compile the patches... (I don't have much
experience in using patches).

Sincerely,
Ran Rutenberg

WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Stefan Schimanski]

Hi!

Myself and Dov Feldstern are working on the support for Right-To-Left  
languages in LyX. In the latest RC1 there are many things which are  
not the way they should be. As we are not using Right-To-Left ourself  
we lack a bit the experience how it should look like and what is most  
convenient.


To get it right WE ARE LOOKING FOR:

  PEOPLE USING RTL languages and who are able and WILLING TO TRY OUT  
PATCHES

  against the subversion code and to compile it.

You don't have to be a developer, just user of a RTL language who  
wants to have LyX 1.5 to behave the right way (tm).


One decision which is open and must be settled:

THE SPACE ISSUE
===

What we are investigating right now is the handling of spaces on the  
boundary of RTL and LTR text. Take a look at the picture. The blue  
underline marks the character which have a RTL font. So the picture  
shows the four cases possible.


spaces.png
Description: application/applefile
<>

There are several possibilities now to interpret the underlined  
spaces (short RTL spaces):


* The LyX 1.3 magic way: the RTL spaces behave in fact like LTR  
spaces, i.e. they are put where non-underlined spaces would be. See  
this example:


  - In "english WERBEH_english" the _ is in fact behind the W
So in Latex you would write "english\R{HEBREW } english"

The consequence is that the cursor strangely (IMO) jumps from behind  
the W to the right in the moment you enter the space. If you have  
used LyX 1.3 you might be familiar with this behavior:


  "english |WERBEHenglish" ==> "english WERBEH_|english"

If you continue now typing a character the cursor (and the space)  
jumps back:


  "english WERBEH_|" ==> "english |H_WERBEHenglish" ==>
  "english H_WERBEH_|english"

* The non-magic way: the spaces are no special characters. They stay  
at the position you type them. See this example:


  "english |WERBEHenglish" ==> "english |_WERBEHenglish" ==>
  "english |H_WERBEHenglish"

If you change back to English and continue typing the cursor will go  
to the right, i.e.:


  ==> "english H_WERBEH|english" ==> "english H_WERBEH |english"

In Latex you would type the same:

  "english \R{HEBREW H} english"

Of course two spaces, one inside the RTL, one outside, are merged  
silently by Latex,

i.e. "english \R{HEBREW }" will look the same as "english \R{HEBREW}".

If you have an opinion, please tell us.

Thanks
  Stefan Schimanski

PGP.sig
Description: Signierter Teil der Nachricht

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Pavel Sanda]

> You don't have to be a developer, just user of a RTL language who  
> wants to have LyX 1.5 to behave the right way (tm).

what about to post it to the user list ?
pavel

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Stefan Schimanski]

Am 05.06.2007 um 14:18 schrieb Pavel Sanda:


You don't have to be a developer, just user of a RTL language who
wants to have LyX 1.5 to behave the right way (tm).


That was my intention. Noticed it after it was sent. Sent it again to  
the users list, but it didn't show yet


Stefan


PGP.sig
Description: Signierter Teil der Nachricht

Re: WANTED: users of Right-To-Left languages who want proper support in LyX 1.5

[Ran Rutenberg]

Stefan Schimanski <[EMAIL PROTECTED]> writes:

> Myself and Dov Feldstern are working on the support for Right-To-Left  
> languages in LyX. In the latest RC1 there are many things which are  
> not the way they should be. As we are not using Right-To-Left ourself  
> we lack a bit the experience how it should look like and what is most  
> convenient.
> 
> To get it right WE ARE LOOKING FOR:
> 
>PEOPLE USING RTL languages and who are able and WILLING TO TRY OUT  
> PATCHES
>against the subversion code and to compile it.
> 
> You don't have to be a developer, just user of a RTL language who  
> wants to have LyX 1.5 to behave the right way (tm).



Hi,

If you need help testing the RTL support I'm willing to help as much as I can. I
write most of my files in Hebrew and therefore I use RTL a lot.
I may need a bit of guiding on how to compile the patches... (I don't have much
experience in using patches).

Sincerely,
Ran Rutenberg