Re: Why does lyx use it's own keyboard instead of the systems?

[Dov Feldstern]

Micha Feigin wrote:

On Tue, 10 Mar 2009 11:44:46 +0200
Ronen Abravanel ron...@gmail.com wrote:


Before you rush into this change - Consider the following usecase:
Switching to math - When I'm in math-mode, I always want my keyboard layout
to be English. While In windows, The current keyboard layout override the
global one (If you put the cursor in an Hebrew context, the language will
switch to Hebrew, If you put your cursor in English context - you'll write
in English).
When I'm writing document, I want the Ctrl+m will be the only thing I need
to do in order to start typing math. Ctrl-m Alt-Shift Is match to
expensive..



good point, but you also have two input senarios in math.
1. Entering parameters (regular typing). AFAIK it should always be in english
because I don't think that latex can handle anything else
2. in text mode inside math mode, where you want to be able to type both
(although at the moment it requires explicitly entering the \R{} macro to get
hebrew in there

Does everyone agree on the first point and are you willing to manually change
in the second case or do you want some other behviour?


So - If LyX will use the native-system-keyboard-layout - It will have to be
able to change it depending the current context (Math\Regular) - And in
every OS.

On Tue, Mar 10, 2009 at 9:59 AM, Abdelrazak Younes you...@lyx.org wrote:


Micha Feigin wrote:


Sorry, sent off list by mistake

On Mon, 9 Mar 2009 22:05:51 +0100
Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 There are two issues. For running the dictionary you need to know  the

language.
For hebrew and arabic it's another issue, you need to know the  system
language
so that you know directionality. Hebrew is right to left. For  hebrew
characters
it may be easy to decide, for what about spaces and numbers? For  these
we need
to know the system keyboard language and not guess it from the
 character.

Under windows I know it's possible since for example word does it.
 Question is
whether this is possible to know under linux (I guess so since  there
are panel
applets that show the language). Which again comes down to the  question
whether
there is a technical issue why to work this way or not.


So you want to change language when the keyboard layout is changed at
 system level, right?
I never thought of these layouts as indicators of the actual  language.
If Qt gives us
this information, we should be able to do it.

JMarc



For every other program the system language is used for input (alt-shift
in my
case). So for example when writing mail or using oowriter I change the
system
language to change input. Lyx is the only exeption where I __have__ to
keep the
system language for english and bind (f12 in this case) to language
hebrew. It
makes things incosistent and non-intuitive, esspecially for new users.


I agree. For RTL languages, it makes a lot of sense to change the current
language together with the system. Advanced users wishing to change the
language independently should be able to disable this feature though.

Now, you have to find someone willing to implement this feature ;-)

FYI, a year or two ago I advocated that the text direction should be based
uniquely on the encoding, independently of the language settings, like Qt
does. But I failed to convince other developers.

Dov, are you reading this? ;-)

Abdel.



A little late, but yes, I am still lurking on the mailing lists... ;)

I think the main reason (to answer the title question) is that we don't know how 
to get/set the system-wide keyboard language in a cross-platform way. If it's 
possible to do that, then I think it should be fairly simple to implement a 
solution along the following lines:


Ideally, if it *were* possible to detect the system-wide keyboard language 
setting, then LyX should (optionally! for users that *want* this feature) set 
it's internal language to the system-wide setting, plain and simple. The only 
thing to make sure, though, is that in the same manner, whenever LyX chooses to 
change it's internal language, it should also *set* the system-wide keyboard 
setting to that language. I think that that would solve the issue raised by 
Ronen: when entering a math inset, LyX would set the internal, as well as the 
system-wide, language to english (or latex, technically? I forget the exact 
details), which would mean that the math text would be set correctly; and when 
exiting that inset, LyX automatically sets the language back to whatever it was 
before entering the inset. Similarly, when moving the cursor over existing text, 
LyX changes the language to match the underlying text. I'm almost certain that 
LyX already does all of this language setting --- except that not at the 
system-wide level, that's what would have to be added.


Note, however, that even if this is implemented, I think I would *still* choose 
to use LyX's keymaps, for reasons that I've explained elsewhere (last time 
around was at 

Re: Why does lyx use it's own keyboard instead of the systems?

[Dov Feldstern]

Micha Feigin wrote:

On Tue, 10 Mar 2009 11:44:46 +0200
Ronen Abravanel ron...@gmail.com wrote:


Before you rush into this change - Consider the following usecase:
Switching to math - When I'm in math-mode, I always want my keyboard layout
to be English. While In windows, The current keyboard layout override the
global one (If you put the cursor in an Hebrew context, the language will
switch to Hebrew, If you put your cursor in English context - you'll write
in English).
When I'm writing document, I want the Ctrl+m will be the only thing I need
to do in order to start typing math. Ctrl-m Alt-Shift Is match to
expensive..



good point, but you also have two input senarios in math.
1. Entering parameters (regular typing). AFAIK it should always be in english
because I don't think that latex can handle anything else
2. in text mode inside math mode, where you want to be able to type both
(although at the moment it requires explicitly entering the \R{} macro to get
hebrew in there

Does everyone agree on the first point and are you willing to manually change
in the second case or do you want some other behviour?


So - If LyX will use the native-system-keyboard-layout - It will have to be
able to change it depending the current context (Math\Regular) - And in
every OS.

On Tue, Mar 10, 2009 at 9:59 AM, Abdelrazak Younes you...@lyx.org wrote:


Micha Feigin wrote:


Sorry, sent off list by mistake

On Mon, 9 Mar 2009 22:05:51 +0100
Jean-Marc Lasgouttes lasgout...@lyx.org wrote:

 There are two issues. For running the dictionary you need to know  the

language.
For hebrew and arabic it's another issue, you need to know the  system
language
so that you know directionality. Hebrew is right to left. For  hebrew
characters
it may be easy to decide, for what about spaces and numbers? For  these
we need
to know the system keyboard language and not guess it from the
 character.

Under windows I know it's possible since for example word does it.
 Question is
whether this is possible to know under linux (I guess so since  there
are panel
applets that show the language). Which again comes down to the  question
whether
there is a technical issue why to work this way or not.


So you want to change language when the keyboard layout is changed at
 system level, right?
I never thought of these layouts as indicators of the actual  language.
If Qt gives us
this information, we should be able to do it.

JMarc



For every other program the system language is used for input (alt-shift
in my
case). So for example when writing mail or using oowriter I change the
system
language to change input. Lyx is the only exeption where I __have__ to
keep the
system language for english and bind (f12 in this case) to language
hebrew. It
makes things incosistent and non-intuitive, esspecially for new users.


I agree. For RTL languages, it makes a lot of sense to change the current
language together with the system. Advanced users wishing to change the
language independently should be able to disable this feature though.

Now, you have to find someone willing to implement this feature ;-)

FYI, a year or two ago I advocated that the text direction should be based
uniquely on the encoding, independently of the language settings, like Qt
does. But I failed to convince other developers.

Dov, are you reading this? ;-)

Abdel.



A little late, but yes, I am still lurking on the mailing lists... ;)

I think the main reason (to answer the title question) is that we don't know how 
to get/set the system-wide keyboard language in a cross-platform way. If it's 
possible to do that, then I think it should be fairly simple to implement a 
solution along the following lines:


Ideally, if it *were* possible to detect the system-wide keyboard language 
setting, then LyX should (optionally! for users that *want* this feature) set 
it's internal language to the system-wide setting, plain and simple. The only 
thing to make sure, though, is that in the same manner, whenever LyX chooses to 
change it's internal language, it should also *set* the system-wide keyboard 
setting to that language. I think that that would solve the issue raised by 
Ronen: when entering a math inset, LyX would set the internal, as well as the 
system-wide, language to english (or latex, technically? I forget the exact 
details), which would mean that the math text would be set correctly; and when 
exiting that inset, LyX automatically sets the language back to whatever it was 
before entering the inset. Similarly, when moving the cursor over existing text, 
LyX changes the language to match the underlying text. I'm almost certain that 
LyX already does all of this language setting --- except that not at the 
system-wide level, that's what would have to be added.


Note, however, that even if this is implemented, I think I would *still* choose 
to use LyX's keymaps, for reasons that I've explained elsewhere (last time 
around was at 

Re: Why does lyx use it's own keyboard instead of the systems?

[Dov Feldstern]

Micha Feigin wrote:

On Tue, 10 Mar 2009 11:44:46 +0200
Ronen Abravanel  wrote:


Before you rush into this change - Consider the following usecase:
Switching to math - When I'm in math-mode, I always want my keyboard layout
to be English. While In windows, The current keyboard layout override the
global one (If you put the cursor in an Hebrew context, the language will
switch to Hebrew, If you put your cursor in English context - you'll write
in English).
When I'm writing document, I want the Ctrl+m will be the only thing I need
to do in order to start typing math. "Ctrl-m Alt-Shift" Is match to
expensive..



good point, but you also have two input senarios in math.
1. Entering parameters (regular typing). AFAIK it should always be in english
because I don't think that latex can handle anything else
2. in text mode inside math mode, where you want to be able to type both
(although at the moment it requires explicitly entering the \R{} macro to get
hebrew in there

Does everyone agree on the first point and are you willing to manually change
in the second case or do you want some other behviour?


So - If LyX will use the native-system-keyboard-layout - It will have to be
able to change it depending the current context (Math\Regular) - And in
every OS.

On Tue, Mar 10, 2009 at 9:59 AM, Abdelrazak Younes  wrote:


Micha Feigin wrote:


Sorry, sent off list by mistake

On Mon, 9 Mar 2009 22:05:51 +0100
Jean-Marc Lasgouttes  wrote:

 There are two issues. For running the dictionary you need to know  the

language.
For hebrew and arabic it's another issue, you need to know the  system
language
so that you know directionality. Hebrew is right to left. For  hebrew
characters
it may be easy to decide, for what about spaces and numbers? For  these
we need
to know the system keyboard language and not guess it from the
 character.

Under windows I know it's possible since for example word does it.
 Question is
whether this is possible to know under linux (I guess so since  there
are panel
applets that show the language). Which again comes down to the  question
whether
there is a technical issue why to work this way or not.


So you want to change language when the keyboard layout is changed at
 system level, right?
I never thought of these layouts as indicators of the actual  language.
If Qt gives us
this information, we should be able to do it.

JMarc



For every other program the system language is used for input (alt-shift
in my
case). So for example when writing mail or using oowriter I change the
system
language to change input. Lyx is the only exeption where I __have__ to
keep the
system language for english and bind (f12 in this case) to language
hebrew. It
makes things incosistent and non-intuitive, esspecially for new users.


I agree. For RTL languages, it makes a lot of sense to change the current
language together with the system. Advanced users wishing to change the
language independently should be able to disable this feature though.

Now, you have to find someone willing to implement this feature ;-)

FYI, a year or two ago I advocated that the text direction should be based
uniquely on the encoding, independently of the language settings, like Qt
does. But I failed to convince other developers.

Dov, are you reading this? ;-)

Abdel.



A little late, but yes, I am still lurking on the mailing lists... ;)

I think the main reason (to answer the title question) is that we don't know how 
to get/set the system-wide keyboard language in a cross-platform way. If it's 
possible to do that, then I think it should be fairly simple to implement a 
solution along the following lines:


Ideally, if it *were* possible to detect the system-wide keyboard language 
setting, then LyX should (optionally! for users that *want* this feature) set 
it's internal language to the system-wide setting, plain and simple. The only 
thing to make sure, though, is that in the same manner, whenever LyX chooses to 
change it's internal language, it should also *set* the system-wide keyboard 
setting to that language. I think that that would solve the issue raised by 
Ronen: when entering a math inset, LyX would set the internal, as well as the 
system-wide, language to english (or latex, technically? I forget the exact 
details), which would mean that the math text would be set correctly; and when 
exiting that inset, LyX automatically sets the language back to whatever it was 
before entering the inset. Similarly, when moving the cursor over existing text, 
LyX changes the language to match the underlying text. I'm almost certain that 
LyX already does all of this language setting --- except that not at the 
system-wide level, that's what would have to be added.


Note, however, that even if this is implemented, I think I would *still* choose 
to use LyX's keymaps, for reasons that I've explained elsewhere (last time 
around was at 

Re: Hebrew and Nikud on Linux (Ubuntu)

[Dov Feldstern]

Nigel Pegram wrote:

Hi everyone,

I've been using Lyx for a while but have not been able to get nikud to 
work correctly. I can enter unicode, even to the point of consonantal 
Hebrew, but as soon as I add a vowel, I get errors.


I have attached a sample file with one point added. If I delete the 
vowel, the document is generated correctly. The relevant part of the log 
seems to be:


! Package ucs Error: Please activate option 'combine'.

See the ucs package documentation for explanation.

Type H return for immediate help.

...

l.32 שדגשֻ

\selectlanguage{polutonikogreek}

Composed characters can only be rendered correctly, when the option 
'combine' i


s activated

! Undefined control sequence.

\u-default-1467 #1-\...@cmb \qubuts

{#1}

l.32 שדגשֻ

\selectlanguage{polutonikogreek}

The control sequence at the end of the top line

of your error message was never \def'ed. If you have

misspelled it (e.g., `\hobx'), type `I' and the correct

spelling (e.g., `I\hbox'). Otherwise just continue,

and I'll forget about whatever was undefined.


The full log is also attached.


Lyx 1.6.1, Ubuntu 8.10

Any suggestions appreciated.

TIA
Nigel



I have had some success with this in the past, though I haven't tried it 
recently. It mostly has to do with whether latex itself has nikud support. So I 
would first focus on getting it working with latex itself.


There's culmus-latex (http://www.guyrutenberg.com/culmus-latex/), the latest 
version of which at least partially supports nikud; I'm not sure if it's 
packaged for ubuntu or if you have to install from source.


You might also want to ask about this on the ivritex mailing list 
(http://listserv.tau.ac.il/archives/ivritex.html) --- that's more 
latex-oriented, but again --- I think that's the real problem, not LyX.


I don't have time to look into this right now, but if you do follow this up and 
come up with anything interesting, please report it back here and/or update the 
bugzilla issue for nikud (http://bugzilla.lyx.org/show_bug.cgi?id=3366).


Good luck!
Dov

Re: Hebrew and Nikud on Linux (Ubuntu)

[Dov Feldstern]

Nigel Pegram wrote:

Hi everyone,

I've been using Lyx for a while but have not been able to get nikud to 
work correctly. I can enter unicode, even to the point of consonantal 
Hebrew, but as soon as I add a vowel, I get errors.


I have attached a sample file with one point added. If I delete the 
vowel, the document is generated correctly. The relevant part of the log 
seems to be:


! Package ucs Error: Please activate option 'combine'.

See the ucs package documentation for explanation.

Type H return for immediate help.

...

l.32 שדגשֻ

\selectlanguage{polutonikogreek}

Composed characters can only be rendered correctly, when the option 
'combine' i


s activated

! Undefined control sequence.

\u-default-1467 #1-\...@cmb \qubuts

{#1}

l.32 שדגשֻ

\selectlanguage{polutonikogreek}

The control sequence at the end of the top line

of your error message was never \def'ed. If you have

misspelled it (e.g., `\hobx'), type `I' and the correct

spelling (e.g., `I\hbox'). Otherwise just continue,

and I'll forget about whatever was undefined.


The full log is also attached.


Lyx 1.6.1, Ubuntu 8.10

Any suggestions appreciated.

TIA
Nigel



I have had some success with this in the past, though I haven't tried it 
recently. It mostly has to do with whether latex itself has nikud support. So I 
would first focus on getting it working with latex itself.


There's culmus-latex (http://www.guyrutenberg.com/culmus-latex/), the latest 
version of which at least partially supports nikud; I'm not sure if it's 
packaged for ubuntu or if you have to install from source.


You might also want to ask about this on the ivritex mailing list 
(http://listserv.tau.ac.il/archives/ivritex.html) --- that's more 
latex-oriented, but again --- I think that's the real problem, not LyX.


I don't have time to look into this right now, but if you do follow this up and 
come up with anything interesting, please report it back here and/or update the 
bugzilla issue for nikud (http://bugzilla.lyx.org/show_bug.cgi?id=3366).


Good luck!
Dov

Re: Hebrew and Nikud on Linux (Ubuntu)

[Dov Feldstern]

Nigel Pegram wrote:

Hi everyone,

I've been using Lyx for a while but have not been able to get nikud to 
work correctly. I can enter unicode, even to the point of consonantal 
Hebrew, but as soon as I add a vowel, I get errors.


I have attached a sample file with one point added. If I delete the 
vowel, the document is generated correctly. The relevant part of the log 
seems to be:


! Package ucs Error: Please activate option 'combine'.

See the ucs package documentation for explanation.

Type H  for immediate help.

...

l.32 שדגשֻ

\selectlanguage{polutonikogreek}

Composed characters can only be rendered correctly, when the option 
'combine' i


s activated

! Undefined control sequence.

\u-default-1467 #1->\...@cmb \qubuts

{#1}

l.32 שדגשֻ

\selectlanguage{polutonikogreek}

The control sequence at the end of the top line

of your error message was never \def'ed. If you have

misspelled it (e.g., `\hobx'), type `I' and the correct

spelling (e.g., `I\hbox'). Otherwise just continue,

and I'll forget about whatever was undefined.


The full log is also attached.


Lyx 1.6.1, Ubuntu 8.10

Any suggestions appreciated.

TIA
Nigel



I have had some success with this in the past, though I haven't tried it 
recently. It mostly has to do with whether latex itself has nikud support. So I 
would first focus on getting it working with latex itself.


There's culmus-latex (http://www.guyrutenberg.com/culmus-latex/), the latest 
version of which at least partially supports nikud; I'm not sure if it's 
packaged for ubuntu or if you have to install from source.


You might also want to ask about this on the ivritex mailing list 
(http://listserv.tau.ac.il/archives/ivritex.html) --- that's more 
latex-oriented, but again --- I think that's the real problem, not LyX.


I don't have time to look into this right now, but if you do follow this up and 
come up with anything interesting, please report it back here and/or update the 
bugzilla issue for nikud (http://bugzilla.lyx.org/show_bug.cgi?id=3366).


Good luck!
Dov

Re: getting a document with no page numbers

[Dov Feldstern]

Micha wrote:

I trying to get a document with no page numbers and for some reason it's just
not working.

both
\pagestyle{empty}
\thispagestyle{empty}

seem to be ignored.

Any idea on where to look for the culprit?
the document style is article, bibtex and amstex are in use. The document is
both hebrew and english

thanks


\thispagestyle{empty} works for me (1.7svn, article, hebrew and english, but no 
bibtex or amstex). Note that the command has to be in ERT on the specific page, 
not in the preamble (which is obvious, given that it's for a specific page --- 
but I think I once had trouble because of that ;) ). Besides the ERT, I also set 
the Document-Settings...-Page Layout-Heading style to empty --- I'm not 
sure if both are necessary or not...


HTH!
Dov

Re: Key bindings

[Dov Feldstern]

Peleg Michaeli wrote:

On Fri, 2008-11-21 at 23:18 +, Guenter Milde wrote:

So you really have a Psi-key?


Well, yes. I type a lot of math, so I have configured my keyboard to
have all of the greek letters, including √, ∞, ∝, ≤≥ ⊆⊇ ⊂⊃ ←→ ⇐⇒ − ≠ ≡ ∀
∃ and many more. I thought that it might really shorten my LyX
experience (though, I still mostly use vim for LaTeX, but LyX is much
better with Hebrew), but...

In 1.6, you will get a  text-psi in text and (with the above fix) a
kursive math \psi in the LaTeX output. 


...but I guess I'll need 1.6 for that. Well, I'm quite scared of this,
since I only have ubuntu 7.04 and I don't know how it'll react, and
since it took me a while to configure Hebrew properly in that LyX (I've
been through hell, actually... but maybe this hell is related to
configuring the Hebrew fonts in pdflatex, actually, and not in LyX? I'm
not so sure...)

I'll have to think about it a bit (add information if you like to!)

Thanks a lot,
Peleg.




Hi, Peleg!

I'm not totally clear as to how your keyboard is set up, and I think that that 
may be the problem (for what it's worth, I'm able to create the C-g y binding 
without any trouble, with Hebrew; this is in 2.0svn, but I don't think this 
should have changed appreciably even from 1.5).


Do you use a keyboard map (Tools-Preferences-Keyboard- use keyboard math; 
the exact menus may be a little different in 1.5)?


Does your keyboard output english or hebrew (i.e., do you switch languages at 
the keyboard level, or *only* using F12 in LyX)?


When you say so I have configured my keyboard to have all of the greek letters, 
including √, ∞, ∝, ≤≥ ⊆⊇ ⊂⊃ ←→ ⇐⇒ − ≠ ≡ ∀ ∃ and many more --- did you do 
anything to actually configure the keyboard, or just paste stickers on or 
something? I mean, when you press a key, will LyX be getting a g or some 
unicode character?


Depending on your answers to these questions, I *may* be able to help a 
little...

Dov

Re: Key bindings

[Dov Feldstern]

Peleg Michaeli wrote:

On Fri, 2008-11-21 at 13:27 +, Guenter Milde wrote:

You could try to grep for C-g in all bind files that are read directly
or
indirectly. 


I have found these:
./bind/xemacs.bind:\bind C-g  cancel
./bind/xemacs.bind:\bind C-x C-gbuffer-view ps
./bind/mac.bind:\bind C-g error-next
./bind/emacs.bind:\bind C-g cancel
./bind/emacs.bind:\bind C-x C-gbuffer-view ps
./bind/cua.bind:\bind C-g error-next

Do you think it is safe to delete these?



They shouldn't all be bothering you, only the ones you include are activated. 
Probably it's cua -- that's the default.


what exactly does your bind file look like?


And: how can I know if these files are really readed?

(the above is the result of grep in /usr/share/lyx1.5.1/)


Thanks,
Peleg.

Re: Key bindings

[Dov Feldstern]

Peleg Michaeli wrote:

On Sat, 2008-11-22 at 20:28 +0200, Dov Feldstern wrote:

They shouldn't all be bothering you, only the ones you include are
activated. 
Probably it's cua -- that's the default.


what exactly does your bind file look like? 


I'm attaching cua and hebrew here.

The cua.bind is in usr/share/... and the hebrew.bind is in
~/.lyx1.5.1/bind/



The first line of hebrew.bind (\bind_file cua) is including cua.bind. I don't 
remember the rules in terms of whether you can override bindings, and they may 
also have changes since 1.5. The easiest thing to do may be to just copy 
cua.bind from /usr to your local lyx bind directory, rename it to mycua or 
something, get rid of the C-g y in there, and include that in hebrew instead 
of cua. See if that helps.




Thanks,
Peleg.

Re: Key bindings

[Dov Feldstern]

Peleg Michaeli wrote:

On Sat, 2008-11-22 at 17:34 +, Peleg Michaeli wrote:

When you say so I have configured my keyboard to have all of the
greek letters, 

including √, ∞, ∝, ≤≥ ⊆⊇ ⊂⊃ ←→ ⇐⇒ − ≠ ≡ ∀ ∃ and many more --- did
you do 

anything to actually configure the keyboard, or just paste stickers
on or 

something? I mean, when you press a key, will LyX be getting a g
or some 

unicode character?

Very simple: I have reconfigured GNOME, so now when I press Alt Gr +
s, for example, I get σ. If I press the same key combination with
Caps-Lock on, or with Shift key pressed as well, I get Σ. Pressing the
key that is just near the z key on its left produces ∀, and doing
that
with Shift produces ∃, and many more options.

I haven't put any stickers. I know the keys (at least most of them) by
heart − it's very simple. I do it like that since even though I know
TeX
quite good, it is much shorter to write emails to friends like this:
Let x∈P and y∈Q. Since P and Q are normal, xyx^-1y^-1∈P∩Q={e}... ⇒
something... or compare ...hence P\subseteq Q to ...hence P⊆Q.

So, in LyX, when I press Alt Gr + a I get α, but I don't want to get
α
− I want to get \alpha, and I believed that LyX might have a
solution
to this need (and, apparently, it has − but only in 1.6). Vim, for
example, knows really well how to deal with that.

It is important to say also that the configuration is very basic, and
it
works in ANY software on my computer, including LyX. It's not a hack
in the risky aspect of it.

Depending on your answers to these questions, I *may* be able to
help a little... 


Hi Dov -
Can you think of any solution to this without switching to LyX 1.6 ?


Thanks,
Peleg.




No. However, perhaps you can try installing 1.6 in a virtualized environment 
(Qemu, VirtualBox are relatively easy to set up, I think), so that it won't 
affect your production system until you've got it configured correctly...

Re: getting a document with no page numbers

[Dov Feldstern]

Micha wrote:

I trying to get a document with no page numbers and for some reason it's just
not working.

both
\pagestyle{empty}
\thispagestyle{empty}

seem to be ignored.

Any idea on where to look for the culprit?
the document style is article, bibtex and amstex are in use. The document is
both hebrew and english

thanks


\thispagestyle{empty} works for me (1.7svn, article, hebrew and english, but no 
bibtex or amstex). Note that the command has to be in ERT on the specific page, 
not in the preamble (which is obvious, given that it's for a specific page --- 
but I think I once had trouble because of that ;) ). Besides the ERT, I also set 
the Document-Settings...-Page Layout-Heading style to empty --- I'm not 
sure if both are necessary or not...


HTH!
Dov

Re: Key bindings

[Dov Feldstern]

Peleg Michaeli wrote:

On Fri, 2008-11-21 at 23:18 +, Guenter Milde wrote:

So you really have a Psi-key?


Well, yes. I type a lot of math, so I have configured my keyboard to
have all of the greek letters, including √, ∞, ∝, ≤≥ ⊆⊇ ⊂⊃ ←→ ⇐⇒ − ≠ ≡ ∀
∃ and many more. I thought that it might really shorten my LyX
experience (though, I still mostly use vim for LaTeX, but LyX is much
better with Hebrew), but...

In 1.6, you will get a  text-psi in text and (with the above fix) a
kursive math \psi in the LaTeX output. 


...but I guess I'll need 1.6 for that. Well, I'm quite scared of this,
since I only have ubuntu 7.04 and I don't know how it'll react, and
since it took me a while to configure Hebrew properly in that LyX (I've
been through hell, actually... but maybe this hell is related to
configuring the Hebrew fonts in pdflatex, actually, and not in LyX? I'm
not so sure...)

I'll have to think about it a bit (add information if you like to!)

Thanks a lot,
Peleg.




Hi, Peleg!

I'm not totally clear as to how your keyboard is set up, and I think that that 
may be the problem (for what it's worth, I'm able to create the C-g y binding 
without any trouble, with Hebrew; this is in 2.0svn, but I don't think this 
should have changed appreciably even from 1.5).


Do you use a keyboard map (Tools-Preferences-Keyboard- use keyboard math; 
the exact menus may be a little different in 1.5)?


Does your keyboard output english or hebrew (i.e., do you switch languages at 
the keyboard level, or *only* using F12 in LyX)?


When you say so I have configured my keyboard to have all of the greek letters, 
including √, ∞, ∝, ≤≥ ⊆⊇ ⊂⊃ ←→ ⇐⇒ − ≠ ≡ ∀ ∃ and many more --- did you do 
anything to actually configure the keyboard, or just paste stickers on or 
something? I mean, when you press a key, will LyX be getting a g or some 
unicode character?


Depending on your answers to these questions, I *may* be able to help a 
little...

Dov

Re: Key bindings

[Dov Feldstern]

Peleg Michaeli wrote:

On Fri, 2008-11-21 at 13:27 +, Guenter Milde wrote:

You could try to grep for C-g in all bind files that are read directly
or
indirectly. 


I have found these:
./bind/xemacs.bind:\bind C-g  cancel
./bind/xemacs.bind:\bind C-x C-gbuffer-view ps
./bind/mac.bind:\bind C-g error-next
./bind/emacs.bind:\bind C-g cancel
./bind/emacs.bind:\bind C-x C-gbuffer-view ps
./bind/cua.bind:\bind C-g error-next

Do you think it is safe to delete these?



They shouldn't all be bothering you, only the ones you include are activated. 
Probably it's cua -- that's the default.


what exactly does your bind file look like?


And: how can I know if these files are really readed?

(the above is the result of grep in /usr/share/lyx1.5.1/)


Thanks,
Peleg.

Re: Key bindings

[Dov Feldstern]

Peleg Michaeli wrote:

On Sat, 2008-11-22 at 20:28 +0200, Dov Feldstern wrote:

They shouldn't all be bothering you, only the ones you include are
activated. 
Probably it's cua -- that's the default.


what exactly does your bind file look like? 


I'm attaching cua and hebrew here.

The cua.bind is in usr/share/... and the hebrew.bind is in
~/.lyx1.5.1/bind/



The first line of hebrew.bind (\bind_file cua) is including cua.bind. I don't 
remember the rules in terms of whether you can override bindings, and they may 
also have changes since 1.5. The easiest thing to do may be to just copy 
cua.bind from /usr to your local lyx bind directory, rename it to mycua or 
something, get rid of the C-g y in there, and include that in hebrew instead 
of cua. See if that helps.




Thanks,
Peleg.

Re: Key bindings

[Dov Feldstern]

Peleg Michaeli wrote:

On Sat, 2008-11-22 at 17:34 +, Peleg Michaeli wrote:

When you say so I have configured my keyboard to have all of the
greek letters, 

including √, ∞, ∝, ≤≥ ⊆⊇ ⊂⊃ ←→ ⇐⇒ − ≠ ≡ ∀ ∃ and many more --- did
you do 

anything to actually configure the keyboard, or just paste stickers
on or 

something? I mean, when you press a key, will LyX be getting a g
or some 

unicode character?

Very simple: I have reconfigured GNOME, so now when I press Alt Gr +
s, for example, I get σ. If I press the same key combination with
Caps-Lock on, or with Shift key pressed as well, I get Σ. Pressing the
key that is just near the z key on its left produces ∀, and doing
that
with Shift produces ∃, and many more options.

I haven't put any stickers. I know the keys (at least most of them) by
heart − it's very simple. I do it like that since even though I know
TeX
quite good, it is much shorter to write emails to friends like this:
Let x∈P and y∈Q. Since P and Q are normal, xyx^-1y^-1∈P∩Q={e}... ⇒
something... or compare ...hence P\subseteq Q to ...hence P⊆Q.

So, in LyX, when I press Alt Gr + a I get α, but I don't want to get
α
− I want to get \alpha, and I believed that LyX might have a
solution
to this need (and, apparently, it has − but only in 1.6). Vim, for
example, knows really well how to deal with that.

It is important to say also that the configuration is very basic, and
it
works in ANY software on my computer, including LyX. It's not a hack
in the risky aspect of it.

Depending on your answers to these questions, I *may* be able to
help a little... 


Hi Dov -
Can you think of any solution to this without switching to LyX 1.6 ?


Thanks,
Peleg.




No. However, perhaps you can try installing 1.6 in a virtualized environment 
(Qemu, VirtualBox are relatively easy to set up, I think), so that it won't 
affect your production system until you've got it configured correctly...

Re: getting a document with no page numbers

[Dov Feldstern]

Micha wrote:

I trying to get a document with no page numbers and for some reason it's just
not working.

both
\pagestyle{empty}
\thispagestyle{empty}

seem to be ignored.

Any idea on where to look for the culprit?
the document style is article, bibtex and amstex are in use. The document is
both hebrew and english

thanks


\thispagestyle{empty} works for me (1.7svn, article, hebrew and english, but no 
bibtex or amstex). Note that the command has to be in ERT on the specific page, 
not in the preamble (which is obvious, given that it's for a specific page --- 
but I think I once had trouble because of that ;) ). Besides the ERT, I also set 
the Document->Settings...->Page Layout->Heading style to "empty" --- I'm not 
sure if both are necessary or not...


HTH!
Dov

Re: Key bindings

[Dov Feldstern]

Peleg Michaeli wrote:

On Fri, 2008-11-21 at 23:18 +, Guenter Milde wrote:

So you really have a Psi-key?


Well, yes. I type a lot of math, so I have configured my keyboard to
have all of the greek letters, including √, ∞, ∝, ≤≥ ⊆⊇ ⊂⊃ ←→ ⇐⇒ − ≠ ≡ ∀
∃ and many more. I thought that it might really shorten my LyX
experience (though, I still mostly use vim for LaTeX, but LyX is much
better with Hebrew), but...

In 1.6, you will get a  text-psi in text and (with the above fix) a
kursive math \psi in the LaTeX output. 


...but I guess I'll need 1.6 for that. Well, I'm quite scared of this,
since I only have ubuntu 7.04 and I don't know how it'll react, and
since it took me a while to configure Hebrew properly in that LyX (I've
been through hell, actually... but maybe this hell is related to
configuring the Hebrew fonts in pdflatex, actually, and not in LyX? I'm
not so sure...)

I'll have to think about it a bit (add information if you like to!)

Thanks a lot,
Peleg.




Hi, Peleg!

I'm not totally clear as to how your keyboard is set up, and I think that that 
may be the problem (for what it's worth, I'm able to create the "C-g y" binding 
without any trouble, with Hebrew; this is in 2.0svn, but I don't think this 
should have changed appreciably even from 1.5).


Do you use a keyboard map (Tools->Preferences->Keyboard-> "use keyboard math"; 
the exact menus may be a little different in 1.5)?


Does your keyboard output english or hebrew (i.e., do you switch languages at 
the keyboard level, or *only* using F12 in LyX)?


When you say "so I have configured my keyboard to have all of the greek letters, 
including √, ∞, ∝, ≤≥ ⊆⊇ ⊂⊃ ←→ ⇐⇒ − ≠ ≡ ∀ ∃ and many more" --- did you do 
anything to actually configure the keyboard, or just paste stickers on or 
something? I mean, when you press a key, will LyX be getting a "g" or some 
unicode character?


Depending on your answers to these questions, I *may* be able to help a 
little...

Dov

Re: Key bindings

[Dov Feldstern]

Peleg Michaeli wrote:

On Fri, 2008-11-21 at 13:27 +, Guenter Milde wrote:

You could try to grep for C-g in all bind files that are read directly
or
indirectly. 


I have found these:
./bind/xemacs.bind:\bind "C-g"  "cancel"
./bind/xemacs.bind:\bind "C-x C-g""buffer-view ps"
./bind/mac.bind:\bind "C-g" "error-next"
./bind/emacs.bind:\bind "C-g" "cancel"
./bind/emacs.bind:\bind "C-x C-g""buffer-view ps"
./bind/cua.bind:\bind "C-g" "error-next"

Do you think it is safe to delete these?



They shouldn't all be bothering you, only the ones you include are activated. 
Probably it's cua -- that's the default.


what exactly does your bind file look like?


And: how can I know if these files are really readed?

(the above is the result of grep in /usr/share/lyx1.5.1/)


Thanks,
Peleg.

Re: Key bindings

[Dov Feldstern]

Peleg Michaeli wrote:

On Sat, 2008-11-22 at 20:28 +0200, Dov Feldstern wrote:

They shouldn't all be bothering you, only the ones you include are
activated. 
Probably it's cua -- that's the default.


what exactly does your bind file look like? 


I'm attaching cua and hebrew here.

The cua.bind is in usr/share/... and the hebrew.bind is in
~/.lyx1.5.1/bind/



The first line of hebrew.bind ("\bind_file cua") is including cua.bind. I don't 
remember the rules in terms of whether you can override bindings, and they may 
also have changes since 1.5. The easiest thing to do may be to just copy 
cua.bind from /usr to your local lyx bind directory, rename it to mycua or 
something, get rid of the "C-g y" in there, and include that in hebrew instead 
of cua. See if that helps.




Thanks,
Peleg.

Re: Key bindings

[Dov Feldstern]

Peleg Michaeli wrote:

On Sat, 2008-11-22 at 17:34 +, Peleg Michaeli wrote:

When you say "so I have configured my keyboard to have all of the
greek letters, 

including √, ∞, ∝, ≤≥ ⊆⊇ ⊂⊃ ←→ ⇐⇒ − ≠ ≡ ∀ ∃ and many more" --- did
you do 

anything to actually configure the keyboard, or just paste stickers
on or 

something? I mean, when you press a key, will LyX be getting a "g"
or some 

unicode character?

Very simple: I have reconfigured GNOME, so now when I press "Alt Gr +
s", for example, I get σ. If I press the same key combination with
Caps-Lock on, or with Shift key pressed as well, I get Σ. Pressing the
key that is just near the "z" key on its left produces ∀, and doing
that
with Shift produces ∃, and many more options.

I haven't put any stickers. I know the keys (at least most of them) by
heart − it's very simple. I do it like that since even though I know
TeX
quite good, it is much shorter to write emails to friends like this:
"Let x∈P and y∈Q. Since P and Q are normal, xyx^-1y^-1∈P∩Q={e}... ⇒
something..." or compare "...hence P\subseteq Q" to "...hence P⊆Q".

So, in LyX, when I press "Alt Gr + a" I get α, but I don't want to get
α
− I want to get "\alpha", and I believed that LyX might have a
solution
to this need (and, apparently, it has − but only in 1.6). Vim, for
example, knows really well how to deal with that.

It is important to say also that the configuration is very basic, and
it
works in ANY software on my computer, including LyX. It's not a "hack"
in the risky aspect of it.

Depending on your answers to these questions, I *may* be able to
help a little... 


Hi Dov -
Can you think of any solution to this without switching to LyX 1.6 ?


Thanks,
Peleg.




No. However, perhaps you can try installing 1.6 in a virtualized environment 
(Qemu, VirtualBox are relatively easy to set up, I think), so that it won't 
affect your production system until you've got it configured correctly...

Re: Still no composing, and a crash...

[Dov Feldstern]

I'm continuing this discussion on the lyx-devel list, anyone on this list who's 
interested can continue following it there 
(http://permalink.gmane.org/gmane.editors.lyx.devel/108759)


Dov Feldstern wrote:

John Coppens wrote:

Hello people.

I'm not a very frequent user of LyX, but irregularly I do use it, and
seem to run into recurrent problems.

I reported the accented character composing problem a while ago (it just
doesn't work - I can't type Compose-e-', and get é, as I _can_ with other
programs, like sylpheed).


If it works in other programs, that probably means that your os is setup 
to handle this, so there should be no need for LyX's built-in keymaps. Try

disabling the use keyboard map option, and see if that helps.


To be sure, I compiled and installed 1.5.5, and still have the same
problem.
But, worse, I tried to change the keyboard map, and LyX just crashed.
This message appeared on the terminal:

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting
instructions in Help-Introduction and send us a bug report, if
necessary. Thanks ! Bye. Aborted

To reproduce:

LyX - Tools - Preferences - Select Keyboard - Enable 'Use keyboard
map' - Press 'Browse' (Crash).



This shouldn't happen. Are you able to produce a backtrace of this? What 
version of LyX are you using?



Am I doing something wrong here?

John

Re: Still no composing, and a crash...

[Dov Feldstern]

I'm continuing this discussion on the lyx-devel list, anyone on this list who's 
interested can continue following it there 
(http://permalink.gmane.org/gmane.editors.lyx.devel/108759)


Dov Feldstern wrote:

John Coppens wrote:

Hello people.

I'm not a very frequent user of LyX, but irregularly I do use it, and
seem to run into recurrent problems.

I reported the accented character composing problem a while ago (it just
doesn't work - I can't type Compose-e-', and get é, as I _can_ with other
programs, like sylpheed).


If it works in other programs, that probably means that your os is setup 
to handle this, so there should be no need for LyX's built-in keymaps. Try

disabling the use keyboard map option, and see if that helps.


To be sure, I compiled and installed 1.5.5, and still have the same
problem.
But, worse, I tried to change the keyboard map, and LyX just crashed.
This message appeared on the terminal:

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting
instructions in Help-Introduction and send us a bug report, if
necessary. Thanks ! Bye. Aborted

To reproduce:

LyX - Tools - Preferences - Select Keyboard - Enable 'Use keyboard
map' - Press 'Browse' (Crash).



This shouldn't happen. Are you able to produce a backtrace of this? What 
version of LyX are you using?



Am I doing something wrong here?

John

Re: Still no composing, and a crash...

[Dov Feldstern]

I'm continuing this discussion on the lyx-devel list, anyone on this list who's 
interested can continue following it there 
(http://permalink.gmane.org/gmane.editors.lyx.devel/108759)


Dov Feldstern wrote:

John Coppens wrote:

Hello people.

I'm not a very frequent user of LyX, but irregularly I do use it, and
seem to run into recurrent problems.

I reported the accented character composing problem a while ago (it just
doesn't work - I can't type Compose-e-', and get é, as I _can_ with other
programs, like sylpheed).


If it works in other programs, that probably means that your os is setup 
to handle this, so there should be no need for LyX's built-in keymaps. Try

disabling the "use keyboard map" option, and see if that helps.


To be sure, I compiled and installed 1.5.5, and still have the same
problem.
But, worse, I tried to change the keyboard map, and LyX just crashed.
This message appeared on the terminal:

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting
instructions in Help->Introduction and send us a bug report, if
necessary. Thanks ! Bye. Aborted

To reproduce:

LyX -> Tools -> Preferences -> Select Keyboard -> Enable 'Use keyboard
map' -> Press 'Browse' (Crash).



This shouldn't happen. Are you able to produce a backtrace of this? What 
version of LyX are you using?



Am I doing something wrong here?

John

Re: keyboard question

[Dov Feldstern]

Pavel Sanda wrote:

On Wed, Jul 02, 2008 at 09:13:27PM +0200, Pavel Sanda wrote:

Should we get rid of our own keyboard mapping soonish then?

Does anybody still use it and could not use alternatives provided by his
environment?

yes it is still used, i remember some screem last time we discussed this.

The main argument I remember was It works, so why remove it. Now we
seem to have cases where it works (as expected) is not necessarily 
true...


no, one relevant case was to be able to use the same scheme for different
platforms; another argument came from Dov, probably something with hebrew
things...



Pavel is correct, there are certain features which the keymap offers which I 
think would be very hard to offer, especially in a system-independent manner, 
without keymaps (details below).


I haven't followed this thread very closely, and I do not use dead keys --- I'm 
not sure how they're supposed to work at all --- so I don't feel qualified to 
provide suggestions with regard to the original problem. It isn't clear to me 
whether keymaps were or were not being used in this case. But perhaps if they 
were, then the user should just try to shut them off. In any case, I don't think 
that keymaps should ever interfere with anything, if they are shut off (if they 
do, it's a bug, not a problem with keymaps per se).



Specifically, these are some of the features which I think would be hard to 
implement without keymaps:


*) when moving the cursor across text in different languages, it's nice if the 
language is automatically changed to match the text under the cursor (similar to 
when placing the cursor on \emph text, the input automatically becomes \emph. I 
don't know how this could be done without keymaps.


*) at least on my setup, which I switch the language at the keyboard level, it 
is switched for all applications. I find it much nicer if the language is 
switched only for the single application (in our case, LyX) in which I asked to 
switch it. An extreme example of why the alternative is annoying: if I switch 
the keyboard to hebrew in LyX, and then ctrl-d to view the dvi, xdvik pops up, 
but then doesn't recognize 'q' to close (because my keyboard is now set to Hebrew).


*) At least for hebrew, we need to perform two actions when switching languages: 
(1) change the input to hebrew; and (2): switch the text language to hebrew. 
It's nice if we can perform both actions with one keypress. This is not 
possible, though, if the keyboard input switching happens independently of LyX.



If all of the above issues can be solved without LyX's keymaps, then I don't 
mind having keymaps removed. But until that time, I do use keymaps. And again, I 
don't think it should interfere with anything for anyone who doesn't want to use 
them.


Dov


P.S. here's a link to my arguments in favor of keymaps from a previous round of 
discussions: http://permalink.gmane.org/gmane.editors.lyx.devel/88939


(Pavel --- thanks for remembering that this issue is important to me!)

Re: Still no composing, and a crash...

[Dov Feldstern]

John Coppens wrote:

Hello people.

I'm not a very frequent user of LyX, but irregularly I do use it, and
seem to run into recurrent problems.

I reported the accented character composing problem a while ago (it just
doesn't work - I can't type Compose-e-', and get é, as I _can_ with other
programs, like sylpheed). 



If it works in other programs, that probably means that your os is setup to 
handle this, so there should be no need for LyX's built-in keymaps. Try

disabling the use keyboard map option, and see if that helps.


To be sure, I compiled and installed 1.5.5, and still have the same
problem. 


But, worse, I tried to change the keyboard map, and LyX just crashed.
This message appeared on the terminal:

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting
instructions in Help-Introduction and send us a bug report, if
necessary. Thanks ! Bye. Aborted

To reproduce:

LyX - Tools - Preferences - Select Keyboard - Enable 'Use keyboard
map' - Press 'Browse' (Crash).



This shouldn't happen. Are you able to produce a backtrace of this? What version 
of LyX are you using?



Am I doing something wrong here?

John

Re: Still no composing, and a crash...

[Dov Feldstern]

Dov Feldstern wrote:


What version of LyX are you using?



Sorry, you already mentioned it's 1.5.5 ;)

Re: keyboard question

[Dov Feldstern]

Pavel Sanda wrote:

On Wed, Jul 02, 2008 at 09:13:27PM +0200, Pavel Sanda wrote:

Should we get rid of our own keyboard mapping soonish then?

Does anybody still use it and could not use alternatives provided by his
environment?

yes it is still used, i remember some screem last time we discussed this.

The main argument I remember was It works, so why remove it. Now we
seem to have cases where it works (as expected) is not necessarily 
true...


no, one relevant case was to be able to use the same scheme for different
platforms; another argument came from Dov, probably something with hebrew
things...



Pavel is correct, there are certain features which the keymap offers which I 
think would be very hard to offer, especially in a system-independent manner, 
without keymaps (details below).


I haven't followed this thread very closely, and I do not use dead keys --- I'm 
not sure how they're supposed to work at all --- so I don't feel qualified to 
provide suggestions with regard to the original problem. It isn't clear to me 
whether keymaps were or were not being used in this case. But perhaps if they 
were, then the user should just try to shut them off. In any case, I don't think 
that keymaps should ever interfere with anything, if they are shut off (if they 
do, it's a bug, not a problem with keymaps per se).



Specifically, these are some of the features which I think would be hard to 
implement without keymaps:


*) when moving the cursor across text in different languages, it's nice if the 
language is automatically changed to match the text under the cursor (similar to 
when placing the cursor on \emph text, the input automatically becomes \emph. I 
don't know how this could be done without keymaps.


*) at least on my setup, which I switch the language at the keyboard level, it 
is switched for all applications. I find it much nicer if the language is 
switched only for the single application (in our case, LyX) in which I asked to 
switch it. An extreme example of why the alternative is annoying: if I switch 
the keyboard to hebrew in LyX, and then ctrl-d to view the dvi, xdvik pops up, 
but then doesn't recognize 'q' to close (because my keyboard is now set to Hebrew).


*) At least for hebrew, we need to perform two actions when switching languages: 
(1) change the input to hebrew; and (2): switch the text language to hebrew. 
It's nice if we can perform both actions with one keypress. This is not 
possible, though, if the keyboard input switching happens independently of LyX.



If all of the above issues can be solved without LyX's keymaps, then I don't 
mind having keymaps removed. But until that time, I do use keymaps. And again, I 
don't think it should interfere with anything for anyone who doesn't want to use 
them.


Dov


P.S. here's a link to my arguments in favor of keymaps from a previous round of 
discussions: http://permalink.gmane.org/gmane.editors.lyx.devel/88939


(Pavel --- thanks for remembering that this issue is important to me!)

Re: Still no composing, and a crash...

[Dov Feldstern]

John Coppens wrote:

Hello people.

I'm not a very frequent user of LyX, but irregularly I do use it, and
seem to run into recurrent problems.

I reported the accented character composing problem a while ago (it just
doesn't work - I can't type Compose-e-', and get é, as I _can_ with other
programs, like sylpheed). 



If it works in other programs, that probably means that your os is setup to 
handle this, so there should be no need for LyX's built-in keymaps. Try

disabling the use keyboard map option, and see if that helps.


To be sure, I compiled and installed 1.5.5, and still have the same
problem. 


But, worse, I tried to change the keyboard map, and LyX just crashed.
This message appeared on the terminal:

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting
instructions in Help-Introduction and send us a bug report, if
necessary. Thanks ! Bye. Aborted

To reproduce:

LyX - Tools - Preferences - Select Keyboard - Enable 'Use keyboard
map' - Press 'Browse' (Crash).



This shouldn't happen. Are you able to produce a backtrace of this? What version 
of LyX are you using?



Am I doing something wrong here?

John

Re: Still no composing, and a crash...

[Dov Feldstern]

Dov Feldstern wrote:


What version of LyX are you using?



Sorry, you already mentioned it's 1.5.5 ;)

Re: keyboard question

[Dov Feldstern]

Pavel Sanda wrote:

On Wed, Jul 02, 2008 at 09:13:27PM +0200, Pavel Sanda wrote:

Should we get rid of our own keyboard mapping soonish then?

Does anybody still use it and could not use alternatives provided by his
environment?

yes it is still used, i remember some screem last time we discussed this.

The main argument I remember was "It works, so why remove it". Now we
seem to have cases where "it works (as expected)" is not necessarily 
true...


no, one relevant case was to be able to use the same scheme for different
platforms; another argument came from Dov, probably something with hebrew
things...



Pavel is correct, there are certain features which the keymap offers which I 
think would be very hard to offer, especially in a system-independent manner, 
without keymaps (details below).


I haven't followed this thread very closely, and I do not use dead keys --- I'm 
not sure how they're supposed to work at all --- so I don't feel qualified to 
provide suggestions with regard to the original problem. It isn't clear to me 
whether keymaps were or were not being used in this case. But perhaps if they 
were, then the user should just try to shut them off. In any case, I don't think 
that keymaps should ever interfere with anything, if they are shut off (if they 
do, it's a bug, not a problem with keymaps per se).



Specifically, these are some of the features which I think would be hard to 
implement without keymaps:


*) when moving the cursor across text in different languages, it's nice if the 
language is automatically changed to match the text under the cursor (similar to 
when placing the cursor on \emph text, the input automatically becomes \emph. I 
don't know how this could be done without keymaps.


*) at least on my setup, which I switch the language at the keyboard level, it 
is switched for all applications. I find it much nicer if the language is 
switched only for the single application (in our case, LyX) in which I asked to 
switch it. An extreme example of why the alternative is annoying: if I switch 
the keyboard to hebrew in LyX, and then ctrl-d to view the dvi, xdvik pops up, 
but then doesn't recognize 'q' to close (because my keyboard is now set to Hebrew).


*) At least for hebrew, we need to perform two actions when switching languages: 
(1) change the input to hebrew; and (2): switch the text language to hebrew. 
It's nice if we can perform both actions with one keypress. This is not 
possible, though, if the keyboard input switching happens independently of LyX.



If all of the above issues can be solved without LyX's keymaps, then I don't 
mind having keymaps removed. But until that time, I do use keymaps. And again, I 
don't think it should interfere with anything for anyone who doesn't want to use 
them.


Dov


P.S. here's a link to my arguments in favor of keymaps from a previous round of 
discussions: http://permalink.gmane.org/gmane.editors.lyx.devel/88939


(Pavel --- thanks for remembering that this issue is important to me!)

Re: Still no composing, and a crash...

[Dov Feldstern]

John Coppens wrote:

Hello people.

I'm not a very frequent user of LyX, but irregularly I do use it, and
seem to run into recurrent problems.

I reported the accented character composing problem a while ago (it just
doesn't work - I can't type Compose-e-', and get é, as I _can_ with other
programs, like sylpheed). 



If it works in other programs, that probably means that your os is setup to 
handle this, so there should be no need for LyX's built-in keymaps. Try

disabling the "use keyboard map" option, and see if that helps.


To be sure, I compiled and installed 1.5.5, and still have the same
problem. 


But, worse, I tried to change the keyboard map, and LyX just crashed.
This message appeared on the terminal:

lyx: SIGSEGV signal caught
Sorry, you have found a bug in LyX. Please read the bug-reporting
instructions in Help->Introduction and send us a bug report, if
necessary. Thanks ! Bye. Aborted

To reproduce:

LyX -> Tools -> Preferences -> Select Keyboard -> Enable 'Use keyboard
map' -> Press 'Browse' (Crash).



This shouldn't happen. Are you able to produce a backtrace of this? What version 
of LyX are you using?



Am I doing something wrong here?

John

Re: Still no composing, and a crash...

[Dov Feldstern]

Dov Feldstern wrote:


What version of LyX are you using?



Sorry, you already mentioned it's 1.5.5 ;)

Re: [OT] templating latex

[Dov Feldstern]

Rich Shepard wrote:

On Fri, 4 Apr 2008, Dov Feldstern wrote:

Based on your example, I would strongly recommend that you look into 
http://www.cheetahtemplate.org/ --- it's a wonderful tool, and it 
looks to me like it may be just what you're looking for.


Dov,

  Thank you for the recommendation. But, I don't see why I want to put html
code in my python application in order to produce .tex files. Or write xml.
I see the value of the templater for web applications and unstructured
reports. However, that's not what I need.



Hmmm, I thought that perhaps I had misunderstood what you're trying to do, but 
on reading the thread again, it still seems to me like cheetah may be what you 
want ;) . I'll explain:


Cheetah is actually orthogonal to html --- it's just that html is what it is 
usually used for, and I guess the manual is geared towards that. But in fact, it 
can be used for anything --- code generation, for example; as well as typesetting.


So basically, what you would do is this: start out with a latex file that 
outputs something that you want. Then, just replace the instances of the data in 
the latex file with the variables in cheetah's format. The result is a template 
which is basically a .tex file, but which has variables in place of the actual 
data. When you instantiate the template with actual data, you get a .tex file. 
No html/xml whatsoever involved in this.


Attached is an example which is similar to the example you posted. Here's one 
way of how you can use it, but since this is python, there are many other ways, 
depending on which is most convenient for your workflow.


0) you'll obviously have to install cheetah if you actually want to try this out

1) We'll create a file with the actual data that we want to fill the template 
with. In this case, we're going to use pickle to dump it into a file 
cheetah.data. Note that what we dump into this file should be a dictionary, 
whose keys are strings of the names of the variable that we reference in the 
template (title and pairData, in our case), and whose values are the values we 
want to give these variables.


 Python 2.3.4 (#2, Jan  5 2005, 08:24:51)
 [GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2
 Type help, copyright, credits or license for more information.
 Executing Local Startup... Done.
  pairData = [(Jobs,Tax base),
 ...   (Jobs,Infrastructure),
 ...   (Jobs,Schools),
 ...   (Jobs,Housing),
 ...   (Jobs,Medical care),
 ...   (Jobs,Sustainability),
 ...   (Jobs,Traffic volume),
 ...   (Tax base,Infrastructure),
 ...   (Tax base,Schools),
 ...   (Tax base,Housing),
 ...   (Tax base,Medical care),
 ...   (Tax base,Sustainability),
 ...   (Tax base,Traffic volume),
 ...   (Infrastructure,Schools),
 ...   (Infrastructure,Housing),
 ...   (Infrastructure,Medical care),
 ...   (Infrastructure,Sustainability),
 ...   (Infrastructure,Traffic volume),
 ...   (Schools,Housing),
 ...   (Schools,Medical care),
 ...   (Schools,Sustainability),
 ...   (Schools,Traffic volume),
 ...   (Housing,Medical care),
 ...   (Housing,Sustainability),
 ...   (Housing,Traffic volume),
 ...   (Medical care,Sustainability),
 ...   (Medical care,Traffic volume),
 ...   (Sustainability,Traffic volume)]
  title=Cheetah Example
  from pickle import dump
  dump({'pairData':pairData, 'title':title}, open(cheetah.data, w))
  (Ctrl-D)

2) We now have the template (cheetah.tmpl) and the data (cheetah.data). We now 
want to create the actual tex file:


 [EMAIL PROTECTED] cheetah fill --oext tex --pickle cheetah.data cheetah.tmpl

the result is a file called cheetah.tex.

This is just a normal tex file. run  latex on it, view the dvi, etc.

Now you discover that the output is not exactly what you want. But the beauty is 
this: this is purely a latex (or LyX, if you choose to template LyX) issue, and 
to solve it you just edit the template until you get the result that you want.


Hope this helps!
Dov

\documentclass[oneside,english]{article}
\usepackage{palatino}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[dvips] {geometry}
\geometry{verbose,letterpaper,tmargin=1.5cm,bmargin=1.5cm,lmargin=1.5cm,rmargin=1.5cm}
\pagestyle{empty}

\makeatletter

\date{}
\setlength\headsep{4.4cm}
\setlength{\textheight}{18.5cm}
\setlength{\textwidth}{25.0cm}

\usepackage{babel}
\makeatother

\begin{document}

\title{$title}
\maketitle

\vspace{6cm} % space below title to line up first line with OMR form

Fill in the box under \'Economic\' on this line --

\vspace{1.5cm}

Record your position on the project here --

\vspace{3cm}

#for $left,$right in $pairData
$left\hspace{3cm}$right

#end for
\end{document}

Re: [OT] templating latex

[Dov Feldstern]

Rich Shepard wrote:

On Fri, 4 Apr 2008, Dov Feldstern wrote:

Based on your example, I would strongly recommend that you look into 
http://www.cheetahtemplate.org/ --- it's a wonderful tool, and it 
looks to me like it may be just what you're looking for.


Dov,

  Thank you for the recommendation. But, I don't see why I want to put html
code in my python application in order to produce .tex files. Or write xml.
I see the value of the templater for web applications and unstructured
reports. However, that's not what I need.



Hmmm, I thought that perhaps I had misunderstood what you're trying to do, but 
on reading the thread again, it still seems to me like cheetah may be what you 
want ;) . I'll explain:


Cheetah is actually orthogonal to html --- it's just that html is what it is 
usually used for, and I guess the manual is geared towards that. But in fact, it 
can be used for anything --- code generation, for example; as well as typesetting.


So basically, what you would do is this: start out with a latex file that 
outputs something that you want. Then, just replace the instances of the data in 
the latex file with the variables in cheetah's format. The result is a template 
which is basically a .tex file, but which has variables in place of the actual 
data. When you instantiate the template with actual data, you get a .tex file. 
No html/xml whatsoever involved in this.


Attached is an example which is similar to the example you posted. Here's one 
way of how you can use it, but since this is python, there are many other ways, 
depending on which is most convenient for your workflow.


0) you'll obviously have to install cheetah if you actually want to try this out

1) We'll create a file with the actual data that we want to fill the template 
with. In this case, we're going to use pickle to dump it into a file 
cheetah.data. Note that what we dump into this file should be a dictionary, 
whose keys are strings of the names of the variable that we reference in the 
template (title and pairData, in our case), and whose values are the values we 
want to give these variables.


 Python 2.3.4 (#2, Jan  5 2005, 08:24:51)
 [GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2
 Type help, copyright, credits or license for more information.
 Executing Local Startup... Done.
  pairData = [(Jobs,Tax base),
 ...   (Jobs,Infrastructure),
 ...   (Jobs,Schools),
 ...   (Jobs,Housing),
 ...   (Jobs,Medical care),
 ...   (Jobs,Sustainability),
 ...   (Jobs,Traffic volume),
 ...   (Tax base,Infrastructure),
 ...   (Tax base,Schools),
 ...   (Tax base,Housing),
 ...   (Tax base,Medical care),
 ...   (Tax base,Sustainability),
 ...   (Tax base,Traffic volume),
 ...   (Infrastructure,Schools),
 ...   (Infrastructure,Housing),
 ...   (Infrastructure,Medical care),
 ...   (Infrastructure,Sustainability),
 ...   (Infrastructure,Traffic volume),
 ...   (Schools,Housing),
 ...   (Schools,Medical care),
 ...   (Schools,Sustainability),
 ...   (Schools,Traffic volume),
 ...   (Housing,Medical care),
 ...   (Housing,Sustainability),
 ...   (Housing,Traffic volume),
 ...   (Medical care,Sustainability),
 ...   (Medical care,Traffic volume),
 ...   (Sustainability,Traffic volume)]
  title=Cheetah Example
  from pickle import dump
  dump({'pairData':pairData, 'title':title}, open(cheetah.data, w))
  (Ctrl-D)

2) We now have the template (cheetah.tmpl) and the data (cheetah.data). We now 
want to create the actual tex file:


 [EMAIL PROTECTED] cheetah fill --oext tex --pickle cheetah.data cheetah.tmpl

the result is a file called cheetah.tex.

This is just a normal tex file. run  latex on it, view the dvi, etc.

Now you discover that the output is not exactly what you want. But the beauty is 
this: this is purely a latex (or LyX, if you choose to template LyX) issue, and 
to solve it you just edit the template until you get the result that you want.


Hope this helps!
Dov

\documentclass[oneside,english]{article}
\usepackage{palatino}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage[dvips] {geometry}
\geometry{verbose,letterpaper,tmargin=1.5cm,bmargin=1.5cm,lmargin=1.5cm,rmargin=1.5cm}
\pagestyle{empty}

\makeatletter

\date{}
\setlength\headsep{4.4cm}
\setlength{\textheight}{18.5cm}
\setlength{\textwidth}{25.0cm}

\usepackage{babel}
\makeatother

\begin{document}

\title{$title}
\maketitle

\vspace{6cm} % space below title to line up first line with OMR form

Fill in the box under \'Economic\' on this line --

\vspace{1.5cm}

Record your position on the project here --

\vspace{3cm}

#for $left,$right in $pairData
$left\hspace{3cm}$right

#end for
\end{document}

Re: [OT] templating latex

[Dov Feldstern]

Rich Shepard wrote:

On Fri, 4 Apr 2008, Dov Feldstern wrote:

Based on your example, I would strongly recommend that you look into 
http://www.cheetahtemplate.org/ --- it's a wonderful tool, and it 
looks to me like it may be just what you're looking for.


Dov,

  Thank you for the recommendation. But, I don't see why I want to put html
code in my python application in order to produce .tex files. Or write xml.
I see the value of the templater for web applications and unstructured
reports. However, that's not what I need.



Hmmm, I thought that perhaps I had misunderstood what you're trying to do, but 
on reading the thread again, it still seems to me like cheetah may be what you 
want ;) . I'll explain:


Cheetah is actually orthogonal to html --- it's just that html is what it is 
usually used for, and I guess the manual is geared towards that. But in fact, it 
can be used for anything --- code generation, for example; as well as typesetting.


So basically, what you would do is this: start out with a latex file that 
outputs something that you want. Then, just replace the instances of the data in 
the latex file with the variables in cheetah's format. The result is a template 
which is basically a .tex file, but which has variables in place of the actual 
data. When you instantiate the template with actual data, you get a .tex file. 
No html/xml whatsoever involved in this.


Attached is an example which is similar to the example you posted. Here's one 
way of how you can use it, but since this is python, there are many other ways, 
depending on which is most convenient for your workflow.


0) you'll obviously have to install cheetah if you actually want to try this out

1) We'll create a file with the actual data that we want to fill the template 
with. In this case, we're going to use pickle to dump it into a file 
"cheetah.data". Note that what we dump into this file should be a dictionary, 
whose keys are strings of the names of the variable that we reference in the 
template (title and pairData, in our case), and whose values are the values we 
want to give these variables.


 Python 2.3.4 (#2, Jan  5 2005, 08:24:51)
 [GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 Executing Local Startup... Done.
 >>> pairData = [("Jobs","Tax base"),
 ...   ("Jobs","Infrastructure"),
 ...   ("Jobs","Schools"),
 ...   ("Jobs","Housing"),
 ...   ("Jobs","Medical care"),
 ...   ("Jobs","Sustainability"),
 ...   ("Jobs","Traffic volume"),
 ...   ("Tax base","Infrastructure"),
 ...   ("Tax base","Schools"),
 ...   ("Tax base","Housing"),
 ...   ("Tax base","Medical care"),
 ...   ("Tax base","Sustainability"),
 ...   ("Tax base","Traffic volume"),
 ...   ("Infrastructure","Schools"),
 ...   ("Infrastructure","Housing"),
 ...   ("Infrastructure","Medical care"),
 ...   ("Infrastructure","Sustainability"),
 ...   ("Infrastructure","Traffic volume"),
 ...   ("Schools","Housing"),
 ...   ("Schools","Medical care"),
 ...   ("Schools","Sustainability"),
 ...   ("Schools","Traffic volume"),
 ...   ("Housing","Medical care"),
 ...   ("Housing","Sustainability"),
 ...   ("Housing","Traffic volume"),
 ...   ("Medical care","Sustainability"),
 ...   ("Medical care","Traffic volume"),
 ...   ("Sustainability","Traffic volume")]
 >>> title="Cheetah Example"
 >>> from pickle import dump
 >>> dump({'pairData':pairData, 'title':title}, open("cheetah.data", "w"))
 >>> (Ctrl-D)

2) We now have the template (cheetah.tmpl) and the data (cheetah.data). We now 
want to create the actual tex file:


 [EMAIL PROTECTED]> cheetah fill --oext tex --pickle cheetah.data cheetah.tmpl

the result is a file called cheetah.tex.

This is just a normal tex file. run  latex on it, view the dvi, etc.

Now you discover that the output is not exactly what you want. But the beauty is 
this: this is purely a latex (or LyX, if you choose to template LyX) issue, and 
to solve it you jus

[OT] templating latex (was: Re: Creating a Document Programmatically)

[Dov Feldstern]

Rich Shepard wrote:

On Tue, 25 Mar 2008, Rich Shepard wrote:


 Has anyone done this? Our model is written in Python, so we can use the
open() and write() methods to squirt strings to a disk file.


  After learning PyX (Python wrapper for TeX/LaTeX primarily for graphics),
and trying to use it to write the reports, I'm back to embedding LaTeX
markup in Python comments. Risking public humiliation (Hey! I'm used to 
that

since I testify at all sorts of government hearings.), I'm posting my first
abortive attempt to learn how to do the job. Small file attached; as 
long as

you have python installed on your system, it will run.


Based on your example, I would strongly recommend that you look into 
http://www.cheetahtemplate.org/ --- it's a wonderful tool, and it looks to me 
like it may be just what you're looking for.


Enjoy!
Dov

[OT] templating latex (was: Re: Creating a Document Programmatically)

[Dov Feldstern]

Rich Shepard wrote:

On Tue, 25 Mar 2008, Rich Shepard wrote:


 Has anyone done this? Our model is written in Python, so we can use the
open() and write() methods to squirt strings to a disk file.


  After learning PyX (Python wrapper for TeX/LaTeX primarily for graphics),
and trying to use it to write the reports, I'm back to embedding LaTeX
markup in Python comments. Risking public humiliation (Hey! I'm used to 
that

since I testify at all sorts of government hearings.), I'm posting my first
abortive attempt to learn how to do the job. Small file attached; as 
long as

you have python installed on your system, it will run.


Based on your example, I would strongly recommend that you look into 
http://www.cheetahtemplate.org/ --- it's a wonderful tool, and it looks to me 
like it may be just what you're looking for.


Enjoy!
Dov

[OT] templating latex (was: Re: Creating a Document Programmatically)

[Dov Feldstern]

Rich Shepard wrote:

On Tue, 25 Mar 2008, Rich Shepard wrote:


 Has anyone done this? Our model is written in Python, so we can use the
open() and write() methods to squirt strings to a disk file.


  After learning PyX (Python wrapper for TeX/LaTeX primarily for graphics),
and trying to use it to write the reports, I'm back to embedding LaTeX
markup in Python comments. Risking public humiliation (Hey! I'm used to 
that

since I testify at all sorts of government hearings.), I'm posting my first
abortive attempt to learn how to do the job. Small file attached; as 
long as

you have python installed on your system, it will run.


Based on your example, I would strongly recommend that you look into 
http://www.cheetahtemplate.org/ --- it's a wonderful tool, and it looks to me 
like it may be just what you're looking for.


Enjoy!
Dov

Re: Fuzzy fonts (Hebrew)

[Dov Feldstern]

Peleg Michaeli wrote:

Thank you all for your replies!

I will try ivritex's mailing list; it's quite weird, because I do have
culmus fonts installed - the problem is with ivritex, still?



Probably. My understanding is that most of the functionality of ivritex 
has already been incorporated into babel (3.8, I believe). However, that 
does *not* include usage of the culmus fonts --- so the fact that 
they're installed in the system doesn't mean that latex knows how to use 
them yet. That is still under development under the auspices of ivritex, 
and can be downloaded here 
https://sourceforge.net/project/showfiles.php?group_id=33341. But I 
think that it's not complete yet, though I'm not sure.


So here's what I would do:

1) try installing culmus-latex from the above link, and see how it is. 
You might want to try the subversion repository, which is slightly more 
up-to-date.


2) If it's not good enough, get in touch with the ivritex mailing list 
and see if anyone knows what the current status is: is this still being 
developed? Will this work ever be incorporated into babel, too?


3) It would be interesting to understand how the culmus fonts *do* 
already work in latex on Windows --- maybe that can point in a direction 
for getting it working on Linux, too... Agai, the ivritex list is where 
I would pursue this...



Anyway, it is comfoting that you can see both in a good quality.

Yes, I am not using adobe reader (since it is not free software); I am
using just simple PDF viewer (actually, Evince 0.8.1) - for the
experiment, I have tried a different PDF viewer - KGhostView 0.2.0 - and
it looks much better - but this software is awfully slow and have
problems with zoomings.



Hmmm, I guess you're more idealistic than me... I have found that the 
quality in Acrobat Reader (which is at least free as in beer) is often 
significantly better than the open source alternatives that I have tried 
--- though I haven't tried these in a couple of years, so things may be 
better today. I'm sorry to hear the evince isn't better, I was hoping 
that perhaps it would be. You might want to try okular --- it's the new 
KDE viewer, still under development, I believe. Haven't tried it myself, 
though...


Dov

Re: Fuzzy fonts (Hebrew)

[Dov Feldstern]

Peleg Michaeli wrote:

Thank you all for your replies!

I will try ivritex's mailing list; it's quite weird, because I do have
culmus fonts installed - the problem is with ivritex, still?



Probably. My understanding is that most of the functionality of ivritex 
has already been incorporated into babel (3.8, I believe). However, that 
does *not* include usage of the culmus fonts --- so the fact that 
they're installed in the system doesn't mean that latex knows how to use 
them yet. That is still under development under the auspices of ivritex, 
and can be downloaded here 
https://sourceforge.net/project/showfiles.php?group_id=33341. But I 
think that it's not complete yet, though I'm not sure.


So here's what I would do:

1) try installing culmus-latex from the above link, and see how it is. 
You might want to try the subversion repository, which is slightly more 
up-to-date.


2) If it's not good enough, get in touch with the ivritex mailing list 
and see if anyone knows what the current status is: is this still being 
developed? Will this work ever be incorporated into babel, too?


3) It would be interesting to understand how the culmus fonts *do* 
already work in latex on Windows --- maybe that can point in a direction 
for getting it working on Linux, too... Agai, the ivritex list is where 
I would pursue this...



Anyway, it is comfoting that you can see both in a good quality.

Yes, I am not using adobe reader (since it is not free software); I am
using just simple PDF viewer (actually, Evince 0.8.1) - for the
experiment, I have tried a different PDF viewer - KGhostView 0.2.0 - and
it looks much better - but this software is awfully slow and have
problems with zoomings.



Hmmm, I guess you're more idealistic than me... I have found that the 
quality in Acrobat Reader (which is at least free as in beer) is often 
significantly better than the open source alternatives that I have tried 
--- though I haven't tried these in a couple of years, so things may be 
better today. I'm sorry to hear the evince isn't better, I was hoping 
that perhaps it would be. You might want to try okular --- it's the new 
KDE viewer, still under development, I believe. Haven't tried it myself, 
though...


Dov

Re: Fuzzy fonts (Hebrew)

[Dov Feldstern]

Peleg Michaeli wrote:

Thank you all for your replies!

I will try ivritex's mailing list; it's quite weird, because I do have
culmus fonts installed - the problem is with ivritex, still?



Probably. My understanding is that most of the functionality of ivritex 
has already been incorporated into babel (3.8, I believe). However, that 
does *not* include usage of the culmus fonts --- so the fact that 
they're installed in the system doesn't mean that latex knows how to use 
them yet. That is still under development under the auspices of ivritex, 
and can be downloaded here 
https://sourceforge.net/project/showfiles.php?group_id=33341. But I 
think that it's not complete yet, though I'm not sure.


So here's what I would do:

1) try installing culmus-latex from the above link, and see how it is. 
You might want to try the subversion repository, which is slightly more 
up-to-date.


2) If it's not good enough, get in touch with the ivritex mailing list 
and see if anyone knows what the current status is: is this still being 
developed? Will this work ever be incorporated into babel, too?


3) It would be interesting to understand how the culmus fonts *do* 
already work in latex on Windows --- maybe that can point in a direction 
for getting it working on Linux, too... Agai, the ivritex list is where 
I would pursue this...



Anyway, it is comfoting that you can see both in a good quality.

Yes, I am not using adobe reader (since it is not free software); I am
using just simple PDF viewer (actually, Evince 0.8.1) - for the
experiment, I have tried a different PDF viewer - KGhostView 0.2.0 - and
it looks much better - but this software is awfully slow and have
problems with zoomings.



Hmmm, I guess you're more idealistic than me... I have found that the 
quality in Acrobat Reader (which is at least free as in beer) is often 
significantly better than the open source alternatives that I have tried 
--- though I haven't tried these in a couple of years, so things may be 
better today. I'm sorry to hear the evince isn't better, I was hoping 
that perhaps it would be. You might want to try okular --- it's the new 
KDE viewer, still under development, I believe. Haven't tried it myself, 
though...


Dov

Re: Fuzzy fonts (Hebrew)

[Dov Feldstern]

Peleg Michaeli wrote:

Hey...

First of all - thanks for your reply.

Before I do all of your suggested tests (which I will do) I just have to
say: it seems like the pdf you've sent me has fuzzy Hebrew as well!


Perhaps the problem is with the pdf *viewer* that you're using? Some
files I use look horrible in gv, but they're fine using acroread...



Well - as I understand, PDF should embed the fonts inside it, so it's
not impossible that we see the documents in two computers in two
different ways; so for the example, I will add here links to two
documents that I have generated using LyX, one while I had Windows, and
one in my ubuntu. The two documents are generated from the same source
file, so you'll probably see the huge differences.

The link to the windows generated PDF is here:
- http://www.freeall.org/peleg/math/TOP_MMN16-C-windows.pdf
And the link the the ubuntu generated PDF is here:
- http://www.freeall.org/peleg/math/TOP_MMN16-C-ubuntu.pdf

See the difference?


Hmmm, not really :( ... both files look OK to me. Of course they use
different fonts --- on Windows you're probably using the culmus fonts,
and on ubuntu the fonts that come with ivritex (which are not yet culmus
fonts, and not as nice) --- but in terms of quality I don't see a
difference... Regarding the use of culmus fonts on linux, there has been
some work in that direction going on in ivritex, I strongly urge you to
ping the mailing list there to see if there's any progress with this
(and I don't really know the details, they may be able to confirm
whether or not what I'm saying is correct).



Here is the source for BOTH of the PDFs:
- http://www.freeall.org/peleg/math/TOP_MMN16.lyx

Thanks again,
hopefully I will do the rest of the tests some other time.

Peleg.

Re: Fuzzy fonts (Hebrew)

[Dov Feldstern]

Peleg Michaeli wrote:

Hey...

First of all - thanks for your reply.

Before I do all of your suggested tests (which I will do) I just have to
say: it seems like the pdf you've sent me has fuzzy Hebrew as well!


Perhaps the problem is with the pdf *viewer* that you're using? Some
files I use look horrible in gv, but they're fine using acroread...



Well - as I understand, PDF should embed the fonts inside it, so it's
not impossible that we see the documents in two computers in two
different ways; so for the example, I will add here links to two
documents that I have generated using LyX, one while I had Windows, and
one in my ubuntu. The two documents are generated from the same source
file, so you'll probably see the huge differences.

The link to the windows generated PDF is here:
- http://www.freeall.org/peleg/math/TOP_MMN16-C-windows.pdf
And the link the the ubuntu generated PDF is here:
- http://www.freeall.org/peleg/math/TOP_MMN16-C-ubuntu.pdf

See the difference?


Hmmm, not really :( ... both files look OK to me. Of course they use
different fonts --- on Windows you're probably using the culmus fonts,
and on ubuntu the fonts that come with ivritex (which are not yet culmus
fonts, and not as nice) --- but in terms of quality I don't see a
difference... Regarding the use of culmus fonts on linux, there has been
some work in that direction going on in ivritex, I strongly urge you to
ping the mailing list there to see if there's any progress with this
(and I don't really know the details, they may be able to confirm
whether or not what I'm saying is correct).



Here is the source for BOTH of the PDFs:
- http://www.freeall.org/peleg/math/TOP_MMN16.lyx

Thanks again,
hopefully I will do the rest of the tests some other time.

Peleg.

Re: Fuzzy fonts (Hebrew)

[Dov Feldstern]

Peleg Michaeli wrote:

Hey...

First of all - thanks for your reply.

Before I do all of your suggested tests (which I will do) I just have to
say: it seems like the pdf you've sent me has fuzzy Hebrew as well!


Perhaps the problem is with the pdf *viewer* that you're using? Some
files I use look horrible in gv, but they're fine using acroread...



Well - as I understand, PDF should embed the fonts inside it, so it's
not impossible that we see the documents in two computers in two
different ways; so for the example, I will add here links to two
documents that I have generated using LyX, one while I had Windows, and
one in my ubuntu. The two documents are generated from the same source
file, so you'll probably see the huge differences.

The link to the "windows" generated PDF is here:
- http://www.freeall.org/peleg/math/TOP_MMN16-C-windows.pdf
And the link the the "ubuntu" generated PDF is here:
- http://www.freeall.org/peleg/math/TOP_MMN16-C-ubuntu.pdf

See the difference?


Hmmm, not really :( ... both files look OK to me. Of course they use
different fonts --- on Windows you're probably using the culmus fonts,
and on ubuntu the fonts that come with ivritex (which are not yet culmus
fonts, and not as nice) --- but in terms of "quality" I don't see a
difference... Regarding the use of culmus fonts on linux, there has been
some work in that direction going on in ivritex, I strongly urge you to
ping the mailing list there to see if there's any progress with this
(and I don't really know the details, they may be able to confirm
whether or not what I'm saying is correct).



Here is the source for BOTH of the PDFs:
- http://www.freeall.org/peleg/math/TOP_MMN16.lyx

Thanks again,
hopefully I will do the rest of the tests some other time.

Peleg.

Re: Fuzzy fonts (Hebrew)

[Dov Feldstern]

Peleg Michaeli wrote:

Hello.

Since I have moved to Linux (ubuntu 7.04) and installed LyX (1.5.1)
(before that I had Windows XP and LyX 1.5.something), my PDF documents
are generated with low quality, both in Hebrew and English; though,
DVI/PS documents are fine.

I believe that it is somehow related to fonts; and I guess that this is
a problem with pdflatex and not directly with LyX; but when I tried to
generate PDFs from pure .tex files (with Hebrew) using pdflatex, it
seems like it wasn't fuzzy, so maybe LyX DOES have something to do with
that.

For sure, I will add here two files that I have tested. The first test
is in Hebrew and is very simple; I have tried it with pdftex command,
and it worked fine. here is the code:



Hi!

I'm afraid I can't help too much, but it does sound like the problem is 
with fonts or with the tex setup, and not with LyX per se. I tried 
generating from the LyX file you attached and it looks fine to me  (see 
attached; BTW, your binary attachments don't seem to have made it 
through...). Here are a few things you can try:


*) try going the ps2pdf or dvipdfm path, instead of pdflatex. Does that 
make any difference?


*) try exporting from LyX to .tex (both plain tex and pdflatex), and 
then generating the pdf from those files as if they were pure .tex. Does 
that work?


*) If none of these things help, I would also try asking on the ivritex 
mailing list --- chances are someone there will be able to provide more 
help. Also, try providing more information abut your setup: what tex 
distribution are you using (TeXLive, tetex, ...)?


Once you provide the answers to the above issues, perhaps we'll  be able 
to figure out what's going wrong...


Good luck!
Dov


a1.pdf
Description: Adobe PDF document

Re: Fuzzy fonts (Hebrew)

[Dov Feldstern]

Peleg Michaeli wrote:

Hello.

Since I have moved to Linux (ubuntu 7.04) and installed LyX (1.5.1)
(before that I had Windows XP and LyX 1.5.something), my PDF documents
are generated with low quality, both in Hebrew and English; though,
DVI/PS documents are fine.

I believe that it is somehow related to fonts; and I guess that this is
a problem with pdflatex and not directly with LyX; but when I tried to
generate PDFs from pure .tex files (with Hebrew) using pdflatex, it
seems like it wasn't fuzzy, so maybe LyX DOES have something to do with
that.

For sure, I will add here two files that I have tested. The first test
is in Hebrew and is very simple; I have tried it with pdftex command,
and it worked fine. here is the code:



Hi!

I'm afraid I can't help too much, but it does sound like the problem is 
with fonts or with the tex setup, and not with LyX per se. I tried 
generating from the LyX file you attached and it looks fine to me  (see 
attached; BTW, your binary attachments don't seem to have made it 
through...). Here are a few things you can try:


*) try going the ps2pdf or dvipdfm path, instead of pdflatex. Does that 
make any difference?


*) try exporting from LyX to .tex (both plain tex and pdflatex), and 
then generating the pdf from those files as if they were pure .tex. Does 
that work?


*) If none of these things help, I would also try asking on the ivritex 
mailing list --- chances are someone there will be able to provide more 
help. Also, try providing more information abut your setup: what tex 
distribution are you using (TeXLive, tetex, ...)?


Once you provide the answers to the above issues, perhaps we'll  be able 
to figure out what's going wrong...


Good luck!
Dov


a1.pdf
Description: Adobe PDF document

Re: Fuzzy fonts (Hebrew)

[Dov Feldstern]

Peleg Michaeli wrote:

Hello.

Since I have moved to Linux (ubuntu 7.04) and installed LyX (1.5.1)
(before that I had Windows XP and LyX 1.5.something), my PDF documents
are generated with low quality, both in Hebrew and English; though,
DVI/PS documents are fine.

I believe that it is somehow related to fonts; and I guess that this is
a problem with pdflatex and not directly with LyX; but when I tried to
generate PDFs from pure .tex files (with Hebrew) using pdflatex, it
seems like it wasn't fuzzy, so maybe LyX DOES have something to do with
that.

For sure, I will add here two files that I have tested. The first test
is in Hebrew and is very simple; I have tried it with pdftex command,
and it worked fine. here is the code:



Hi!

I'm afraid I can't help too much, but it does sound like the problem is 
with fonts or with the tex setup, and not with LyX per se. I tried 
generating from the LyX file you attached and it looks fine to me  (see 
attached; BTW, your binary attachments don't seem to have made it 
through...). Here are a few things you can try:


*) try going the ps2pdf or dvipdfm path, instead of pdflatex. Does that 
make any difference?


*) try exporting from LyX to .tex (both plain tex and pdflatex), and 
then generating the pdf from those files as if they were pure .tex. Does 
that work?


*) If none of these things help, I would also try asking on the ivritex 
mailing list --- chances are someone there will be able to provide more 
help. Also, try providing more information abut your setup: what tex 
distribution are you using (TeXLive, tetex, ...)?


Once you provide the answers to the above issues, perhaps we'll  be able 
to figure out what's going wrong...


Good luck!
Dov


a1.pdf
Description: Adobe PDF document

visual cursor mode (Bidi)

[Dov Feldstern]

Hi!

I've just committed to 1.6.0svn a series of patches which add the option 
of visual mode for bidi cursor movement. This patch series is *not* 
going to be ported back to 1.5.x, that would be too complicated at this 
point. And as 1.6.0 is nearing (?) an alpha release, I hope this won't 
be too troublesome.


I'd be happy to get some feedback about this from anyone who is capable 
of compiling from svn and is interested in testing this out. I'm sure 
that there are some tweaks that will be necessary. Also, there were a 
few issues which were discussed some months ago, and which I felt could 
be better addressed once visual mode was implemented (e.g., behavior of 
spaces at RTL/LTR boundaries, etc.). Finally, there are some specific 
issues which are directly related to visual mode, which have not been 
implemented yet, and which I hope to complete:


*) ctrl-LEFT and ctrl-RIGHT (word-at-a-time movement), HOME and END keys
*) switching between RTL and LTR languages at an RTL/LTR border 
sometimes causes the cursor to jump; I consider that behavior acceptable 
for logical mode, but not in visual mode
*) tables and matrices (and multiline math in general) have not been 
tested, and I'm also not sure what the correct behavior should be in all 
these cases


So, again, I'd be happy to get any feedback, and if there are problems, 
it would be great if a minimal LyX document which shows the anomalous 
behavior could be attached.


Dov

visual cursor mode (Bidi)

[Dov Feldstern]

Hi!

I've just committed to 1.6.0svn a series of patches which add the option 
of visual mode for bidi cursor movement. This patch series is *not* 
going to be ported back to 1.5.x, that would be too complicated at this 
point. And as 1.6.0 is nearing (?) an alpha release, I hope this won't 
be too troublesome.


I'd be happy to get some feedback about this from anyone who is capable 
of compiling from svn and is interested in testing this out. I'm sure 
that there are some tweaks that will be necessary. Also, there were a 
few issues which were discussed some months ago, and which I felt could 
be better addressed once visual mode was implemented (e.g., behavior of 
spaces at RTL/LTR boundaries, etc.). Finally, there are some specific 
issues which are directly related to visual mode, which have not been 
implemented yet, and which I hope to complete:


*) ctrl-LEFT and ctrl-RIGHT (word-at-a-time movement), HOME and END keys
*) switching between RTL and LTR languages at an RTL/LTR border 
sometimes causes the cursor to jump; I consider that behavior acceptable 
for logical mode, but not in visual mode
*) tables and matrices (and multiline math in general) have not been 
tested, and I'm also not sure what the correct behavior should be in all 
these cases


So, again, I'd be happy to get any feedback, and if there are problems, 
it would be great if a minimal LyX document which shows the anomalous 
behavior could be attached.


Dov

visual cursor mode (Bidi)

[Dov Feldstern]

Hi!

I've just committed to 1.6.0svn a series of patches which add the option 
of "visual mode" for bidi cursor movement. This patch series is *not* 
going to be ported back to 1.5.x, that would be too complicated at this 
point. And as 1.6.0 is nearing (?) an alpha release, I hope this won't 
be too troublesome.


I'd be happy to get some feedback about this from anyone who is capable 
of compiling from svn and is interested in testing this out. I'm sure 
that there are some tweaks that will be necessary. Also, there were a 
few issues which were discussed some months ago, and which I felt could 
be better addressed once visual mode was implemented (e.g., behavior of 
spaces at RTL/LTR boundaries, etc.). Finally, there are some specific 
issues which are directly related to visual mode, which have not been 
implemented yet, and which I hope to complete:


*) ctrl-LEFT and ctrl-RIGHT (word-at-a-time movement), HOME and END keys
*) switching between RTL and LTR languages at an RTL/LTR border 
sometimes causes the cursor to jump; I consider that behavior acceptable 
for logical mode, but not in visual mode
*) tables and matrices (and multiline math in general) have not been 
tested, and I'm also not sure what the correct behavior should be in all 
these cases


So, again, I'd be happy to get any feedback, and if there are problems, 
it would be great if a minimal LyX document which shows the anomalous 
behavior could be attached.


Dov

Re: Compare Changes/Differences between LyX Documents

[Dov Feldstern]

Juergen Spitzmueller wrote:

Bo Peng wrote:


http://www.cs.bgu.ac.il/~dekelts/ldiff/

Quite interesting, do you see any hope of integrating this to lyx?


ldiff basically just compares tex files (LyX files are converted to tex via
lyx -e by the script). I think we should build in some native comparing
feature instead (which will mark differences with our change tracking
markup). IIRC we have an enhancement request about this.

Jürgen



Once we move to the xml format, we may be able to leverage some generic 
xml-diff tools. One that seems quite good (though not very active): 
http://www.logilab.org/859/


Dov

Re: Compare Changes/Differences between LyX Documents

[Dov Feldstern]

Juergen Spitzmueller wrote:

Bo Peng wrote:


http://www.cs.bgu.ac.il/~dekelts/ldiff/

Quite interesting, do you see any hope of integrating this to lyx?


ldiff basically just compares tex files (LyX files are converted to tex via
lyx -e by the script). I think we should build in some native comparing
feature instead (which will mark differences with our change tracking
markup). IIRC we have an enhancement request about this.

Jürgen



Once we move to the xml format, we may be able to leverage some generic 
xml-diff tools. One that seems quite good (though not very active): 
http://www.logilab.org/859/


Dov

Re: Compare Changes/Differences between LyX Documents

[Dov Feldstern]

Juergen Spitzmueller wrote:

Bo Peng wrote:


http://www.cs.bgu.ac.il/~dekelts/ldiff/

Quite interesting, do you see any hope of integrating this to lyx?


ldiff basically just compares tex files (LyX files are converted to tex via
lyx -e by the script). I think we should build in some native comparing
feature instead (which will mark differences with our change tracking
markup). IIRC we have an enhancement request about this.

Jürgen



Once we move to the xml format, we may be able to leverage some generic 
xml-diff tools. One that seems quite good (though not very active): 
http://www.logilab.org/859/


Dov

Re: Hebrew on Mac OS X

[Dov Feldstern]

Alexander Maryanovsky wrote:

On Dec 19, 2007 8:14 PM, Dov Feldstern [EMAIL PROTECTED] wrote:

Hi!

Abdel, thanks for the heads up. I just haven't been able to keep up with
the mailing list / development in the past few weeks... :(

I don't really understand much at all about the packaging. My
understanding is that these are LaTeX issues, over which LyX has no
control, and which are also very platform specific. So I'm afraid I
can't be of much help here...


Dov, I'm not an expert, but my understanding is also that my issue is
a LaTeX issue. I think, however, that you're missing my point.
On platforms where a package manager is the standard way to obtain
software, LyX installs great, and I have no complaints. On platforms
where the standard way to obtain software is by downloading a file
from a website (Windows, Mac OS X), however, an application should,
whenever possible, include all of its dependencies in the installation
file. Basically, my point is that It is not user-friendly if an
application does not work properly out-of-the box.



I am not disputing that. As I said, I just don't know anything about the 
packaging, so I can't help out here. And as Abdel said, any 
contributions are, of course, welcome...


Dov

Re: Hebrew on Mac OS X

[Dov Feldstern]

Alexander Maryanovsky wrote:

On Dec 19, 2007 8:14 PM, Dov Feldstern [EMAIL PROTECTED] wrote:

Hi!

Abdel, thanks for the heads up. I just haven't been able to keep up with
the mailing list / development in the past few weeks... :(

I don't really understand much at all about the packaging. My
understanding is that these are LaTeX issues, over which LyX has no
control, and which are also very platform specific. So I'm afraid I
can't be of much help here...


Dov, I'm not an expert, but my understanding is also that my issue is
a LaTeX issue. I think, however, that you're missing my point.
On platforms where a package manager is the standard way to obtain
software, LyX installs great, and I have no complaints. On platforms
where the standard way to obtain software is by downloading a file
from a website (Windows, Mac OS X), however, an application should,
whenever possible, include all of its dependencies in the installation
file. Basically, my point is that It is not user-friendly if an
application does not work properly out-of-the box.



I am not disputing that. As I said, I just don't know anything about the 
packaging, so I can't help out here. And as Abdel said, any 
contributions are, of course, welcome...


Dov

Re: Hebrew on Mac OS X

[Dov Feldstern]

Alexander Maryanovsky wrote:

On Dec 19, 2007 8:14 PM, Dov Feldstern <[EMAIL PROTECTED]> wrote:

Hi!

Abdel, thanks for the heads up. I just haven't been able to keep up with
the mailing list / development in the past few weeks... :(

I don't really understand much at all about the packaging. My
understanding is that these are LaTeX issues, over which LyX has no
control, and which are also very platform specific. So I'm afraid I
can't be of much help here...


Dov, I'm not an expert, but my understanding is also that my issue is
a LaTeX issue. I think, however, that you're missing my point.
On platforms where a package manager is the standard way to obtain
software, LyX installs great, and I have no complaints. On platforms
where the standard way to obtain software is by downloading a file
from a website (Windows, Mac OS X), however, an application should,
whenever possible, include all of its dependencies in the installation
file. Basically, my point is that It is not user-friendly if an
application does not work properly out-of-the box.



I am not disputing that. As I said, I just don't know anything about the 
packaging, so I can't help out here. And as Abdel said, any 
contributions are, of course, welcome...


Dov

Re: Hebrew on Mac OS X

[Dov Feldstern]

Abdelrazak Younes wrote:

Alexander Maryanovsky wrote:
On 12/19/07, [EMAIL PROTECTED] 
[EMAIL PROTECTED] wrote:

It means that the jesus font (an hebraic font) is unavailable on your
system. I guess that you have to install the hebrew package on your 
latex

distribution to get a set of hebrew fonts.


I just installed ivritex-dist
(http://downloads.sourceforge.net/ivritex/ivritex-1.2.1-dist.tar.gz by
copying its contents into ~/Library/texmf) and now the error isn't
displayed, but all Hebrew text appears blank in the output file, be it
DVI or PDF (English text appears fine).

I know this isn't a LyX issue, but could you help me anyway, or at
least point me somewhere where I could get help?

On a related note, don't you guys think that an application should
work out of the box, without having to go hunt around the internet for
packages and such?


Sure and you are welcome to help us toward this goal ;-)


If LyX claims to support Hebrew, why not go all the
way and include all the required stuff in its installation? Are the
licenses incompatible or something?


Any investigation is welcome. We only have one Hebrew developer (Dov, 
are you reading this?) and he will gladly accept your help.


Abdel.




Hi!

Abdel, thanks for the heads up. I just haven't been able to keep up with 
the mailing list / development in the past few weeks... :(


I don't really understand much at all about the packaging. My 
understanding is that these are LaTeX issues, over which LyX has no 
control, and which are also very platform specific. So I'm afraid I 
can't be of much help here...


And I second Charles suggestion: the ivritex mailing list could be 
helpful regarding hebrew-specific latex issues. I seem to recall that 
there was someone else asking about Mac OS X a few months ago, so you 
might also want to search the ivritex archives.


Sorry I couldn't be of much help...

Dov

Re: Hebrew on Mac OS X

[Dov Feldstern]

Abdelrazak Younes wrote:

Alexander Maryanovsky wrote:
On 12/19/07, [EMAIL PROTECTED] 
[EMAIL PROTECTED] wrote:

It means that the jesus font (an hebraic font) is unavailable on your
system. I guess that you have to install the hebrew package on your 
latex

distribution to get a set of hebrew fonts.


I just installed ivritex-dist
(http://downloads.sourceforge.net/ivritex/ivritex-1.2.1-dist.tar.gz by
copying its contents into ~/Library/texmf) and now the error isn't
displayed, but all Hebrew text appears blank in the output file, be it
DVI or PDF (English text appears fine).

I know this isn't a LyX issue, but could you help me anyway, or at
least point me somewhere where I could get help?

On a related note, don't you guys think that an application should
work out of the box, without having to go hunt around the internet for
packages and such?


Sure and you are welcome to help us toward this goal ;-)


If LyX claims to support Hebrew, why not go all the
way and include all the required stuff in its installation? Are the
licenses incompatible or something?


Any investigation is welcome. We only have one Hebrew developer (Dov, 
are you reading this?) and he will gladly accept your help.


Abdel.




Hi!

Abdel, thanks for the heads up. I just haven't been able to keep up with 
the mailing list / development in the past few weeks... :(


I don't really understand much at all about the packaging. My 
understanding is that these are LaTeX issues, over which LyX has no 
control, and which are also very platform specific. So I'm afraid I 
can't be of much help here...


And I second Charles suggestion: the ivritex mailing list could be 
helpful regarding hebrew-specific latex issues. I seem to recall that 
there was someone else asking about Mac OS X a few months ago, so you 
might also want to search the ivritex archives.


Sorry I couldn't be of much help...

Dov

Re: Hebrew on Mac OS X

[Dov Feldstern]

Abdelrazak Younes wrote:

Alexander Maryanovsky wrote:
On 12/19/07, [EMAIL PROTECTED] 
<[EMAIL PROTECTED]> wrote:

It means that the jesus font (an hebraic font) is unavailable on your
system. I guess that you have to install the hebrew package on your 
latex

distribution to get a set of hebrew fonts.


I just installed ivritex-dist
(http://downloads.sourceforge.net/ivritex/ivritex-1.2.1-dist.tar.gz by
copying its contents into ~/Library/texmf) and now the error isn't
displayed, but all Hebrew text appears blank in the output file, be it
DVI or PDF (English text appears fine).

I know this isn't a LyX issue, but could you help me anyway, or at
least point me somewhere where I could get help?

On a related note, don't you guys think that an application should
work out of the box, without having to go hunt around the internet for
packages and such?


Sure and you are welcome to help us toward this goal ;-)


If LyX claims to support Hebrew, why not go all the
way and include all the required stuff in its installation? Are the
licenses incompatible or something?


Any investigation is welcome. We only have one Hebrew developer (Dov, 
are you reading this?) and he will gladly accept your help.


Abdel.




Hi!

Abdel, thanks for the heads up. I just haven't been able to keep up with 
the mailing list / development in the past few weeks... :(


I don't really understand much at all about the packaging. My 
understanding is that these are LaTeX issues, over which LyX has no 
control, and which are also very platform specific. So I'm afraid I 
can't be of much help here...


And I second Charles suggestion: the ivritex mailing list could be 
helpful regarding hebrew-specific latex issues. I seem to recall that 
there was someone else asking about Mac OS X a few months ago, so you 
might also want to search the ivritex archives.


Sorry I couldn't be of much help...

Dov

Re: long inlined math inside right-to-left article

[Dov Feldstern]

Yitzhak Zangi wrote:

I write Hebrew article, and when an inlined formula exceeds the length of
the line, it breaks and it is starting from the (left) end of the line till
where the text ends, and resuming in the middle of the next line to the
(right) begginning, so the text resumes in the middle of the line. (I think
everyone who writes in both languages know this problem)
I tried to fix it by using \{..} command to keep it together, but then all
the fomula is displayed in the first line as too long line.
Using Ctrl-Enter won't help either, because the first line look then short,
and because LyX isn't WYSIWYG, I need to see the output to know if the
formula is broken or not.
Is there any elegant way to fix the problem??

(N.B. I don't know LaTeX yet)

Thanks.



Hi!

I don't exactly understand the issue --- could you perhaps provide a 
minimal LyX file in which this problem is apparent? Also, what version 
of LyX are you using?


Dov

Re: long inlined math inside right-to-left article

[Dov Feldstern]

Yitzhak Zangi wrote:

I write Hebrew article, and when an inlined formula exceeds the length of
the line, it breaks and it is starting from the (left) end of the line till
where the text ends, and resuming in the middle of the next line to the
(right) begginning, so the text resumes in the middle of the line. (I think
everyone who writes in both languages know this problem)
I tried to fix it by using \{..} command to keep it together, but then all
the fomula is displayed in the first line as too long line.
Using Ctrl-Enter won't help either, because the first line look then short,
and because LyX isn't WYSIWYG, I need to see the output to know if the
formula is broken or not.
Is there any elegant way to fix the problem??

(N.B. I don't know LaTeX yet)

Thanks.



Hi!

I don't exactly understand the issue --- could you perhaps provide a 
minimal LyX file in which this problem is apparent? Also, what version 
of LyX are you using?


Dov

Re: long inlined math inside right-to-left article

[Dov Feldstern]

Yitzhak Zangi wrote:

I write Hebrew article, and when an inlined formula exceeds the length of
the line, it breaks and it is starting from the (left) end of the line till
where the text ends, and resuming in the middle of the next line to the
(right) begginning, so the text resumes in the middle of the line. (I think
everyone who writes in both languages know this problem)
I tried to fix it by using \{..} command to keep it together, but then all
the fomula is displayed in the first line as too long line.
Using Ctrl-Enter won't help either, because the first line look then short,
and because LyX isn't WYSIWYG, I need to see the output to know if the
formula is broken or not.
Is there any elegant way to fix the problem??

(N.B. I don't know LaTeX yet)

Thanks.



Hi!

I don't exactly understand the issue --- could you perhaps provide a 
minimal LyX file in which this problem is apparent? Also, what version 
of LyX are you using?


Dov

Re: Configuring LyX for Arabic or Persian

[Dov Feldstern]

amp3030 wrote:

Hi all,

I am trying to configure LyX to write in Persian (Farsi) or Arabic, but I
cannot do that. I have installed lyx on my ubuntu 7.10 system using
Synaptic. I have also installed texlive-lang-arab, texlive-extra-utils and
texlive-xetex packages.
I followed instructions of the official LyX wiki page carefully, but nothing
is gonna working.

When I use Farsi/Arabic (Arabi) as the language, an error message says: You
haven't defined the languafe farsi/arabic yet.

Can anyone help to resolve this?

Thanks in advance,
Masoud.


Hi!

Could you please provide a more information: specifically, what version 
of LyX are you using? What is your default language set to, what is the 
language of the current document? And what exactly are you trying to do: 
write the entire document in Farsi/Arabic, just insert a word here or 
there in an otherwise english document, or what?


Dov

Re: Configuring LyX for Arabic or Persian

[Dov Feldstern]

amp3030 wrote:

Hi all,

I am trying to configure LyX to write in Persian (Farsi) or Arabic, but I
cannot do that. I have installed lyx on my ubuntu 7.10 system using
Synaptic. I have also installed texlive-lang-arab, texlive-extra-utils and
texlive-xetex packages.
I followed instructions of the official LyX wiki page carefully, but nothing
is gonna working.

When I use Farsi/Arabic (Arabi) as the language, an error message says: You
haven't defined the languafe farsi/arabic yet.

Can anyone help to resolve this?

Thanks in advance,
Masoud.


Hi!

Could you please provide a more information: specifically, what version 
of LyX are you using? What is your default language set to, what is the 
language of the current document? And what exactly are you trying to do: 
write the entire document in Farsi/Arabic, just insert a word here or 
there in an otherwise english document, or what?


Dov

Re: Configuring LyX for Arabic or Persian

[Dov Feldstern]

amp3030 wrote:

Hi all,

I am trying to configure LyX to write in Persian (Farsi) or Arabic, but I
cannot do that. I have installed lyx on my ubuntu 7.10 system using
Synaptic. I have also installed texlive-lang-arab, texlive-extra-utils and
texlive-xetex packages.
I followed instructions of the official LyX wiki page carefully, but nothing
is gonna working.

When I use Farsi/Arabic (Arabi) as the language, an error message says: You
haven't defined the languafe farsi/arabic yet.

Can anyone help to resolve this?

Thanks in advance,
Masoud.


Hi!

Could you please provide a more information: specifically, what version 
of LyX are you using? What is your default language set to, what is the 
language of the current document? And what exactly are you trying to do: 
write the entire document in Farsi/Arabic, just insert a word here or 
there in an otherwise english document, or what?


Dov

Re: LyX1.5.2: Keyboard problem

[Dov Feldstern]

Nicolás wrote:

Hi!

In previous versions of LyX I could use (in Windows) (Alt gr + ´) + 
o in order to get an accented o: ó. In LyX 1.5.2 (and I think also 
in 1.5.1) this does not work. Is this a bug or do I have to configure 
something? Thanks!


Cheers,
Nicolás



I have no idea how the mechanism you describe used to work, but here's a
long shot: try turning off the Right-to-left language support option
in the preferences, and see if that makes a difference.

If it does, please let us know!

Dov

Re: LyX1.5.2: Keyboard problem

[Dov Feldstern]

Nicolás wrote:

Hi!

In previous versions of LyX I could use (in Windows) (Alt gr + ´) + 
o in order to get an accented o: ó. In LyX 1.5.2 (and I think also 
in 1.5.1) this does not work. Is this a bug or do I have to configure 
something? Thanks!


Cheers,
Nicolás



I have no idea how the mechanism you describe used to work, but here's a
long shot: try turning off the Right-to-left language support option
in the preferences, and see if that makes a difference.

If it does, please let us know!

Dov

Re: LyX1.5.2: Keyboard problem

[Dov Feldstern]

Nicolás wrote:

Hi!

In previous versions of LyX I could use (in Windows) (Alt gr + "´") + 
"o" in order to get an accented o: "ó". In LyX 1.5.2 (and I think also 
in 1.5.1) this does not work. Is this a bug or do I have to configure 
something? Thanks!


Cheers,
Nicolás



I have no idea how the mechanism you describe used to work, but here's a
long shot: try turning off the "Right-to-left language support" option
in the preferences, and see if that makes a difference.

If it does, please let us know!

Dov

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

Thanks. Your suggestion worked, after changing the primary keyboard
map to null. It works with both the mini-buffer command and through
the Text style - Customize dialog box.



Great! I'm glad I was able to help.


One more question, is the issue of the options for fontenc and babel
addressed in version 1.5.2?



Uwe, do you remember what the story is with this issue, regarding farsi? 
(see below for more details)



Ernesto Posse wrote:

But apparently the solution is to modify the options for fontenc and
babel as follows:

\usepackage[LFE,LAE,OT1]{fontenc}
\usepackage[farsi,english]{babel}

So LyX should generate these instead of the default

\usepackage[T1]{fontenc}
\usepackage{babel}


Uwe, I believe you worked on this at some point? I may have thwarted
your efforts then...? Do you know what the current situation is?


Nevertheless, LaTeX does give some warnings:
LaTeX Font Warning: Encoding `LFE' has changed to `OT1' for symbol font.

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

Thanks. Your suggestion worked, after changing the primary keyboard
map to null. It works with both the mini-buffer command and through
the Text style - Customize dialog box.



Great! I'm glad I was able to help.


One more question, is the issue of the options for fontenc and babel
addressed in version 1.5.2?



Uwe, do you remember what the story is with this issue, regarding farsi? 
(see below for more details)



Ernesto Posse wrote:

But apparently the solution is to modify the options for fontenc and
babel as follows:

\usepackage[LFE,LAE,OT1]{fontenc}
\usepackage[farsi,english]{babel}

So LyX should generate these instead of the default

\usepackage[T1]{fontenc}
\usepackage{babel}


Uwe, I believe you worked on this at some point? I may have thwarted
your efforts then...? Do you know what the current situation is?


Nevertheless, LaTeX does give some warnings:
LaTeX Font Warning: Encoding `LFE' has changed to `OT1' for symbol font.

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

Thanks. Your suggestion worked, after changing the primary keyboard
map to null. It works with both the mini-buffer command and through
the Text style -> Customize dialog box.



Great! I'm glad I was able to help.


One more question, is the issue of the options for fontenc and babel
addressed in version 1.5.2?



Uwe, do you remember what the story is with this issue, regarding farsi? 
(see below for more details)



Ernesto Posse wrote:

But apparently the solution is to modify the options for fontenc and
babel as follows:

\usepackage[LFE,LAE,OT1]{fontenc}
\usepackage[farsi,english]{babel}

So LyX should generate these instead of the default

\usepackage[T1]{fontenc}
\usepackage{babel}


Uwe, I believe you worked on this at some point? I may have thwarted
your efforts then...? Do you know what the current situation is?


Nevertheless, LaTeX does give some warnings:
"LaTeX Font Warning: Encoding `LFE' has changed to `OT1' for symbol font.

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

On 9/29/07, Dov Feldstern dfeldstern-rhxOsnTko2JWk0Htik3J/[EMAIL PROTECTED] 
wrote:


Ernesto Posse wrote:

I think the arabi package was installed correctly, since MiKTeX didn't
give me any errors. I don't know how else to check if it is correctly
installed (it has about 207 files.) I tried reinstalling it, but I
obtain the same results.


One way to check would be to see if you can compile a regular latex
(non-LyX) file with Farsi, maybe arabi includes some Farsi examples you
could test with. If you are able to do that, then it means that
arabi/latex are set up correctly, and the problem is getting LyX to work
with it. Otherwise, it means the problem is with your latex/arabi setup,
and there's not too much point in trying to get LyX to work before you
fix that.



I didn't find any examples in the arabi package, but I wrote my own.
Apparently the error occurs when using the babel package:

This compiles fine:

\documentclass[farsi,english]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8,latin9]{inputenc}
\begin{document}
hello
\end{document}

But if I try to use a command from farsi, such as \alefhamza, I get a
babel error: (even if I don't use babel, which is odd:)
Package babel Error: You haven't loaded the option english yet.

If I add

\usepackage{babel}

I get

LaTeX Error: Encoding scheme `LAE' unknown.

But apparently the solution is to modify the options for fontenc and
babel as follows:

\usepackage[LFE,LAE,OT1]{fontenc}
\usepackage[farsi,english]{babel}

So LyX should generate these instead of the default

\usepackage[T1]{fontenc}
\usepackage{babel}



Uwe, I believe you worked on this at some point? I may have thwarted 
your efforts then...? Do you know what the current situation is?



Nevertheless, LaTeX does give some warnings:
LaTeX Font Warning: Encoding `LFE' has changed to `OT1' for symbol font.




Furthermore, I spoke too soon when I said that just typing worked
fine. When I switch languages, it does seem to correctly switch the
script, except for punctuation symbols. Only latin letters and digits
seem to be correctly rendered, but the rest of the keyboard seems
stuck with the other keyboard map. Only when I switch off keybord
maps do I get the correct symbols.


Hmm, this is strange. What have you set your primary and secondary
keymaps to? What is your default language (Tools - Preferences -
Language settings - Language) and what is the document language
(Document - Settings... - Language)? Which language seems to be
working correctly, and which does not? Can you give an exact recipe for
reproducing (e.g.: open a new document, set language to , type
abc...)?




It's working for me (with a few slight variations on your setup and 
recipe -- see below --- perhaps those will help).



Primary: american


Try switching this (primary) to null --- I think that means that your 
default language will be used.



Secondary: farsi

Default language: English

Things seem to go awry when the language is switched, regardless of
whether keyboard maps are on or off.

(this seems to indicate that the problem is not with the keymaps, but 
elsewhere in your system. Could it be that by accident you also switched 
the language at the OS-keyboard-level?)



Here's the recipe:

1. Open new document
2. type some text, including punctuation symbols
3. Set language to Farsi (Edit-Test Style-Customize-Language set to Farsi)


Try switching languages by typing language farsi in the minibuffer 
(Alt-x).



4. Type some text.
5. Set language to English or American (Edit-Test
Style-Customize-Language set to English)


Again, try the same command as above (still with farsi! this will 
toggle farsi off).



6. Type text. Punctuation symbols are now wrong.


Does this help?

If it does, you can bind the language farsi command to a key, see, 
e.g., the suggestions here: 
http://permalink.gmane.org/gmane.editors.lyx.devel/88941 .


Dov

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

On 9/29/07, Dov Feldstern dfeldstern-rhxOsnTko2JWk0Htik3J/[EMAIL PROTECTED] 
wrote:


Ernesto Posse wrote:

I think the arabi package was installed correctly, since MiKTeX didn't
give me any errors. I don't know how else to check if it is correctly
installed (it has about 207 files.) I tried reinstalling it, but I
obtain the same results.


One way to check would be to see if you can compile a regular latex
(non-LyX) file with Farsi, maybe arabi includes some Farsi examples you
could test with. If you are able to do that, then it means that
arabi/latex are set up correctly, and the problem is getting LyX to work
with it. Otherwise, it means the problem is with your latex/arabi setup,
and there's not too much point in trying to get LyX to work before you
fix that.



I didn't find any examples in the arabi package, but I wrote my own.
Apparently the error occurs when using the babel package:

This compiles fine:

\documentclass[farsi,english]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8,latin9]{inputenc}
\begin{document}
hello
\end{document}

But if I try to use a command from farsi, such as \alefhamza, I get a
babel error: (even if I don't use babel, which is odd:)
Package babel Error: You haven't loaded the option english yet.

If I add

\usepackage{babel}

I get

LaTeX Error: Encoding scheme `LAE' unknown.

But apparently the solution is to modify the options for fontenc and
babel as follows:

\usepackage[LFE,LAE,OT1]{fontenc}
\usepackage[farsi,english]{babel}

So LyX should generate these instead of the default

\usepackage[T1]{fontenc}
\usepackage{babel}



Uwe, I believe you worked on this at some point? I may have thwarted 
your efforts then...? Do you know what the current situation is?



Nevertheless, LaTeX does give some warnings:
LaTeX Font Warning: Encoding `LFE' has changed to `OT1' for symbol font.




Furthermore, I spoke too soon when I said that just typing worked
fine. When I switch languages, it does seem to correctly switch the
script, except for punctuation symbols. Only latin letters and digits
seem to be correctly rendered, but the rest of the keyboard seems
stuck with the other keyboard map. Only when I switch off keybord
maps do I get the correct symbols.


Hmm, this is strange. What have you set your primary and secondary
keymaps to? What is your default language (Tools - Preferences -
Language settings - Language) and what is the document language
(Document - Settings... - Language)? Which language seems to be
working correctly, and which does not? Can you give an exact recipe for
reproducing (e.g.: open a new document, set language to , type
abc...)?




It's working for me (with a few slight variations on your setup and 
recipe -- see below --- perhaps those will help).



Primary: american


Try switching this (primary) to null --- I think that means that your 
default language will be used.



Secondary: farsi

Default language: English

Things seem to go awry when the language is switched, regardless of
whether keyboard maps are on or off.

(this seems to indicate that the problem is not with the keymaps, but 
elsewhere in your system. Could it be that by accident you also switched 
the language at the OS-keyboard-level?)



Here's the recipe:

1. Open new document
2. type some text, including punctuation symbols
3. Set language to Farsi (Edit-Test Style-Customize-Language set to Farsi)


Try switching languages by typing language farsi in the minibuffer 
(Alt-x).



4. Type some text.
5. Set language to English or American (Edit-Test
Style-Customize-Language set to English)


Again, try the same command as above (still with farsi! this will 
toggle farsi off).



6. Type text. Punctuation symbols are now wrong.


Does this help?

If it does, you can bind the language farsi command to a key, see, 
e.g., the suggestions here: 
http://permalink.gmane.org/gmane.editors.lyx.devel/88941 .


Dov

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

On 9/29/07, Dov Feldstern  
wrote:


Ernesto Posse wrote:

I think the arabi package was installed correctly, since MiKTeX didn't
give me any errors. I don't know how else to check if it is correctly
installed (it has about 207 files.) I tried reinstalling it, but I
obtain the same results.


One way to check would be to see if you can "compile" a regular latex
(non-LyX) file with Farsi, maybe arabi includes some Farsi examples you
could test with. If you are able to do that, then it means that
arabi/latex are set up correctly, and the problem is getting LyX to work
with it. Otherwise, it means the problem is with your latex/arabi setup,
and there's not too much point in trying to get LyX to work before you
fix that.



I didn't find any examples in the arabi package, but I wrote my own.
Apparently the error occurs when using the babel package:

This compiles fine:

\documentclass[farsi,english]{article}
\usepackage[T1]{fontenc}
\usepackage[utf8,latin9]{inputenc}
\begin{document}
hello
\end{document}

But if I try to use a command from farsi, such as \alefhamza, I get a
babel error: (even if I don't use babel, which is odd:)
Package babel Error: You haven't loaded the option english yet.

If I add

\usepackage{babel}

I get

LaTeX Error: Encoding scheme `LAE' unknown.

But apparently the solution is to modify the options for fontenc and
babel as follows:

\usepackage[LFE,LAE,OT1]{fontenc}
\usepackage[farsi,english]{babel}

So LyX should generate these instead of the default

\usepackage[T1]{fontenc}
\usepackage{babel}



Uwe, I believe you worked on this at some point? I may have thwarted 
your efforts then...? Do you know what the current situation is?



Nevertheless, LaTeX does give some warnings:
"LaTeX Font Warning: Encoding `LFE' has changed to `OT1' for symbol font.




Furthermore, I spoke too soon when I said that just typing worked
fine. When I switch languages, it does seem to correctly switch the
script, except for punctuation symbols. Only latin letters and digits
seem to be correctly rendered, but the rest of the keyboard seems
"stuck" with the other keyboard map. Only when I switch off keybord
maps do I get the correct symbols.


Hmm, this is strange. What have you set your primary and secondary
keymaps to? What is your default language (Tools -> Preferences ->
Language settings -> Language) and what is the document language
(Document -> Settings... -> Language)? Which language seems to be
working correctly, and which does not? Can you give an exact recipe for
reproducing (e.g.: open a new document, set language to , type
"abc"...)?




It's working for me (with a few slight variations on your setup and 
recipe -- see below --- perhaps those will help).



Primary: american


Try switching this (primary) to "null" --- I think that means that your 
default language will be used.



Secondary: farsi

Default language: English

Things seem to go awry when the language is switched, regardless of
whether keyboard maps are on or off.

(this seems to indicate that the problem is not with the keymaps, but 
elsewhere in your system. Could it be that by accident you also switched 
the language at the OS-keyboard-level?)



Here's the recipe:

1. Open new document
2. type some text, including punctuation symbols
3. Set language to Farsi (Edit->Test Style->Customize->Language set to Farsi)


Try switching languages by typing "language farsi" in the minibuffer 
(Alt-x).



4. Type some text.
5. Set language to English or American (Edit->Test
Style->Customize->Language set to English)


Again, try the same command as above (still with "farsi"! this will 
toggle farsi off).



6. Type text. Punctuation symbols are now wrong.


Does this help?

If it does, you can bind the "language farsi" command to a key, see, 
e.g., the suggestions here: 
http://permalink.gmane.org/gmane.editors.lyx.devel/88941 .


Dov

Re: Language Change

[Dov Feldstern]

snvv wrote:

Hello

I use sid debian with LyX 1.5-1 and I have a rather strange problem. 

When I change language (alt+shift) the LyX menu is activated. Thus, in order 
to write I have to press once the mouse (cursor) in the text to continue.


I thought might be a LyX config but I can't find anything about it.

Any suggestion please?

sn



Hi!

It doesn't sound like a LyX config issue, sounds more like a bad 
interaction between LyX and the Desktop Environment. Here are a few 
suggestions, though they are probably not what you were hoping for, it's 
more workarounds than solutions:


1) Pressing Alt a second time may be enough to release the menu, so you 
don't have to go to the mouse every time you switch languages.


2) You might want to consider changing the key combination you use for 
switching languages (at the OS- / Window Manager- / Desktop Environment- 
level). I changed the combination I use, because there are some LyX 
bindings which I used a lot that contained Alt-Shift (e.g., 
Alt-Shift-right and Alt-Shift-left to increase/decrease the nesting 
level, for example in a listing). You can probably do this through the 
Gnome/KDE configuration if you're using one of those, or directly using 
setxkbmap.


3) I like using keymaps for switching languages in LyX, rather than 
switching at the keyboard level. To do that, you go to Tools - 
Preferences... - Look and feel - Keyboard, and check the use keyboard 
map option. Then select the primary and secondary keymaps that you want 
(I have 'null' as my primary, which I guess means no keymap). To switch 
between the keymaps, you have two options: if you're using an RTL 
language, then just switching to that language should automatically 
activate the keymap. Otherwise, you have to first make sure that the RTL 
option is turned off (Tools - Preferences... - Language settings - 
Language, and *un*check Right-to-left language support), and then you 
can use the Alt-k-1 and Alt-k-2 keybindings to select the primary or 
secondary keyboard, Alt-k-t to toggle between them (I myself use Hebrew, 
which is an RTL language, so I don't use these bindings).


Note, however, that regardless of how you switch the keyboard, you 
should also set the language correctly (Edit - Text style - 
Customized... - Language, or using the language  lfun), in order 
to let latex know what language the text is in, so that it can output it 
correctly. For this reason, using a keymap is an advantage, because then 
you can create a key binding which will both switch the keyboard and set 
the language with one keypress. I don't know how to achieve this if 
you're switching languages at the OS-level.


Dov

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

I think the arabi package was installed correctly, since MiKTeX didn't
give me any errors. I don't know how else to check if it is correctly
installed (it has about 207 files.) I tried reinstalling it, but I
obtain the same results.



One way to check would be to see if you can compile a regular latex 
(non-LyX) file with Farsi, maybe arabi includes some Farsi examples you 
could test with. If you are able to do that, then it means that 
arabi/latex are set up correctly, and the problem is getting LyX to work 
with it. Otherwise, it means the problem is with your latex/arabi setup, 
and there's not too much point in trying to get LyX to work before you 
fix that.



Furthermore, I spoke too soon when I said that just typing worked
fine. When I switch languages, it does seem to correctly switch the
script, except for punctuation symbols. Only latin letters and digits
seem to be correctly rendered, but the rest of the keyboard seems
stuck with the other keyboard map. Only when I switch off keybord
maps do I get the correct symbols.



Hmm, this is strange. What have you set your primary and secondary 
keymaps to? What is your default language (Tools - Preferences - 
Language settings - Language) and what is the document language 
(Document - Settings... - Language)? Which language seems to be 
working correctly, and which does not? Can you give an exact recipe for 
reproducing (e.g.: open a new document, set language to , type 
abc...)?


Dov

Re: Language Change

[Dov Feldstern]

snvv wrote:

Hello

I use sid debian with LyX 1.5-1 and I have a rather strange problem. 

When I change language (alt+shift) the LyX menu is activated. Thus, in order 
to write I have to press once the mouse (cursor) in the text to continue.


I thought might be a LyX config but I can't find anything about it.

Any suggestion please?

sn



Hi!

It doesn't sound like a LyX config issue, sounds more like a bad 
interaction between LyX and the Desktop Environment. Here are a few 
suggestions, though they are probably not what you were hoping for, it's 
more workarounds than solutions:


1) Pressing Alt a second time may be enough to release the menu, so you 
don't have to go to the mouse every time you switch languages.


2) You might want to consider changing the key combination you use for 
switching languages (at the OS- / Window Manager- / Desktop Environment- 
level). I changed the combination I use, because there are some LyX 
bindings which I used a lot that contained Alt-Shift (e.g., 
Alt-Shift-right and Alt-Shift-left to increase/decrease the nesting 
level, for example in a listing). You can probably do this through the 
Gnome/KDE configuration if you're using one of those, or directly using 
setxkbmap.


3) I like using keymaps for switching languages in LyX, rather than 
switching at the keyboard level. To do that, you go to Tools - 
Preferences... - Look and feel - Keyboard, and check the use keyboard 
map option. Then select the primary and secondary keymaps that you want 
(I have 'null' as my primary, which I guess means no keymap). To switch 
between the keymaps, you have two options: if you're using an RTL 
language, then just switching to that language should automatically 
activate the keymap. Otherwise, you have to first make sure that the RTL 
option is turned off (Tools - Preferences... - Language settings - 
Language, and *un*check Right-to-left language support), and then you 
can use the Alt-k-1 and Alt-k-2 keybindings to select the primary or 
secondary keyboard, Alt-k-t to toggle between them (I myself use Hebrew, 
which is an RTL language, so I don't use these bindings).


Note, however, that regardless of how you switch the keyboard, you 
should also set the language correctly (Edit - Text style - 
Customized... - Language, or using the language  lfun), in order 
to let latex know what language the text is in, so that it can output it 
correctly. For this reason, using a keymap is an advantage, because then 
you can create a key binding which will both switch the keyboard and set 
the language with one keypress. I don't know how to achieve this if 
you're switching languages at the OS-level.


Dov

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

I think the arabi package was installed correctly, since MiKTeX didn't
give me any errors. I don't know how else to check if it is correctly
installed (it has about 207 files.) I tried reinstalling it, but I
obtain the same results.



One way to check would be to see if you can compile a regular latex 
(non-LyX) file with Farsi, maybe arabi includes some Farsi examples you 
could test with. If you are able to do that, then it means that 
arabi/latex are set up correctly, and the problem is getting LyX to work 
with it. Otherwise, it means the problem is with your latex/arabi setup, 
and there's not too much point in trying to get LyX to work before you 
fix that.



Furthermore, I spoke too soon when I said that just typing worked
fine. When I switch languages, it does seem to correctly switch the
script, except for punctuation symbols. Only latin letters and digits
seem to be correctly rendered, but the rest of the keyboard seems
stuck with the other keyboard map. Only when I switch off keybord
maps do I get the correct symbols.



Hmm, this is strange. What have you set your primary and secondary 
keymaps to? What is your default language (Tools - Preferences - 
Language settings - Language) and what is the document language 
(Document - Settings... - Language)? Which language seems to be 
working correctly, and which does not? Can you give an exact recipe for 
reproducing (e.g.: open a new document, set language to , type 
abc...)?


Dov

Re: Language Change

[Dov Feldstern]

snvv wrote:

Hello

I use sid debian with LyX 1.5-1 and I have a rather strange problem. 

When I change language (alt+shift) the LyX menu is activated. Thus, in order 
to write I have to press once the mouse (cursor) in the text to continue.


I thought might be a LyX config but I can't find anything about it.

Any suggestion please?

sn



Hi!

It doesn't sound like a LyX config issue, sounds more like a bad 
interaction between LyX and the Desktop Environment. Here are a few 
suggestions, though they are probably not what you were hoping for, it's 
more workarounds than solutions:


1) Pressing Alt a second time may be enough to release the menu, so you 
don't have to go to the mouse every time you switch languages.


2) You might want to consider changing the key combination you use for 
switching languages (at the OS- / Window Manager- / Desktop Environment- 
level). I changed the combination I use, because there are some LyX 
bindings which I used a lot that contained Alt-Shift (e.g., 
Alt-Shift-right and Alt-Shift-left to increase/decrease the nesting 
level, for example in a listing). You can probably do this through the 
Gnome/KDE configuration if you're using one of those, or directly using 
setxkbmap.


3) I like using keymaps for switching languages in LyX, rather than 
switching at the keyboard level. To do that, you go to Tools -> 
Preferences... -> Look and feel -> Keyboard, and check the "use keyboard 
map" option. Then select the primary and secondary keymaps that you want 
(I have 'null' as my primary, which I guess means no keymap). To switch 
between the keymaps, you have two options: if you're using an RTL 
language, then just switching to that language should automatically 
activate the keymap. Otherwise, you have to first make sure that the RTL 
option is turned off (Tools -> Preferences... -> Language settings -> 
Language, and *un*check "Right-to-left language support"), and then you 
can use the Alt-k-1 and Alt-k-2 keybindings to select the primary or 
secondary keyboard, Alt-k-t to toggle between them (I myself use Hebrew, 
which is an RTL language, so I don't use these bindings).


Note, however, that regardless of how you switch the keyboard, you 
should also set the language correctly (Edit -> Text style -> 
Customized... -> Language, or using the "language " lfun), in order 
to let latex know what language the text is in, so that it can output it 
correctly. For this reason, using a keymap is an advantage, because then 
you can create a key binding which will both switch the keyboard and set 
the language with one keypress. I don't know how to achieve this if 
you're switching languages at the OS-level.


Dov

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

I think the arabi package was installed correctly, since MiKTeX didn't
give me any errors. I don't know how else to check if it is correctly
installed (it has about 207 files.) I tried reinstalling it, but I
obtain the same results.



One way to check would be to see if you can "compile" a regular latex 
(non-LyX) file with Farsi, maybe arabi includes some Farsi examples you 
could test with. If you are able to do that, then it means that 
arabi/latex are set up correctly, and the problem is getting LyX to work 
with it. Otherwise, it means the problem is with your latex/arabi setup, 
and there's not too much point in trying to get LyX to work before you 
fix that.



Furthermore, I spoke too soon when I said that just typing worked
fine. When I switch languages, it does seem to correctly switch the
script, except for punctuation symbols. Only latin letters and digits
seem to be correctly rendered, but the rest of the keyboard seems
"stuck" with the other keyboard map. Only when I switch off keybord
maps do I get the correct symbols.



Hmm, this is strange. What have you set your primary and secondary 
keymaps to? What is your default language (Tools -> Preferences -> 
Language settings -> Language) and what is the document language 
(Document -> Settings... -> Language)? Which language seems to be 
working correctly, and which does not? Can you give an exact recipe for 
reproducing (e.g.: open a new document, set language to , type 
"abc"...)?


Dov

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

Is it possible to write a document in LyX (1.5.1) that mixes two (or
more) scripts? If so, how?

I have been able to install and use an alternative keyboard map for a
non-latin script, but, even though one can specify two keyboard maps,
I have not been able to find anywhere in the documentation how to
select the second map.

Thanks.



Hi!

Yes, it is possible, there are actually a few different ways to do it. 
However, your success may also depend on which scripts specifically you 
are talking about.


The easiest way is perhaps to just switch the keyboard at the OS-level. 
Depending on your OS / Desktop Environment, you can probably change the 
keyboard's language, and then whatever you type will be in that script.


Another option is to use LyX's built-in keymaps. It sounds like you have 
already discovered this option. In order to use it, you can use the 
following keybindings: M-k 1 M-k 2 to choose the primary / secondary 
keymap; M-k t to toggle between them. Two caveats, though: Firstly, 
Keymaps currently support only two scripts simultaneously. Secondly, if 
both scripts you want to use are non-RTL, you have to turn off the RTL 
option (see the RELEASE-NOTES, or 
http://www.lyx.org/trac/browser/lyx-devel/branches/BRANCH_1_5_X/RELEASE-NOTES#L31?rev=20486).


Personally, I prefer keymaps. I have pointed out some of the reasons why 
in a previous post 
(http://permalink.gmane.org/gmane.editors.lyx.devel/88939), you can see 
there if those reasons make sense to you or not, and that may help you 
decide which method is better for you.


Note, however, that regardless of which method you use, you should also 
make sure that the language of the text (Edit - Text style - 
Customized... - Language) is set correctly. Otherwise, chances are that 
latex will choke on the non-latin characters. This is where using a LyX 
keymap has an advantage: since you can change the keymap from within 
LyX, you can create a keybinding which will both switch the keymap and 
set the language using only a single keystroke. I don't know of any way 
to do this if you use OS-level keyboard support.


If you provide a little more specific information (which scripts? what 
OS are your working on? ...) we may be able to provide further assistance.


Dov

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

Great, thanks. I wasn't setting  Edit - Text style -Customized...
- Language properly. Is there a key binding for this option?



There is an lfun called language which does exactly this, and which 
you can bind to any key you want. In Hebrew, we use F12 for the binding. 
I suggest adapting one of the files attached here, just use the language 
farsi: http://permalink.gmane.org/gmane.editors.lyx.devel/88941 . Just 
place the file to your .lyx/bind directory (I'm not sure what the 
Windows equivalent is, the truth is you could probably place the file 
anywhere), and select it as your bind file (Tools - Preferences... - 
Look and feel - User interface).


Note that since you're using an RTL language, then you shouldn't even 
have to use the bindings for explicitly setting the keymap (M-k 1, etc.) 
--- it should happen automatically when you switch the language.



When I am typing, it seems to work, but when I try to view it (for
example in DVI) I get latex errors such as:

LaTeX Error: Encoding scheme `LAE' unknown.
Command \alefhamza unavailable in encoding T1.
Package inputenc Error: Unicode char \u8:0' not set up for use with LaTeX.

I am trying to mix English and Farsi. I followed the instructions from
the Wiki (http://wiki.lyx.org/Windows/Farsi). I am running LyX 1.5.1
on Windows Vista, with MiKTeX 2.6.

What could be the problem?


I don't know the Farsi stuff, Mostafa is our Farsi expert. But some 
things I would check: are you sure that the arabi latex package is 
installed and set up correctly? What's bothering me is that the LAE 
encoding scheme seems to be unknown, I believe that's what should be 
used for Farsi.


Uwe, Mostafa --- any ideas?



By the way, I found that in menus.bind, both options for M-k o and
M-k x are set to keymap-off. If I change one of them to
'keymap-on', it seems to be ignored.


I'm not even sure what the keymap-off and keymap-on lfuns are supposed 
to do... But as I said above, for an RTL language, you shouldn't need 
any of the keymap lfuns, switching the language should take care of this 
as long as you've setup the keymaps to be used.






On 9/27/07, Dov Feldstern [EMAIL PROTECTED] wrote:

Ernesto Posse wrote:

Is it possible to write a document in LyX (1.5.1) that mixes two (or
more) scripts? If so, how?

I have been able to install and use an alternative keyboard map for a
non-latin script, but, even though one can specify two keyboard maps,
I have not been able to find anywhere in the documentation how to
select the second map.

Thanks.


Hi!

Yes, it is possible, there are actually a few different ways to do it.
However, your success may also depend on which scripts specifically you
are talking about.

The easiest way is perhaps to just switch the keyboard at the OS-level.
Depending on your OS / Desktop Environment, you can probably change the
keyboard's language, and then whatever you type will be in that script.

Another option is to use LyX's built-in keymaps. It sounds like you have
already discovered this option. In order to use it, you can use the
following keybindings: M-k 1 M-k 2 to choose the primary / secondary
keymap; M-k t to toggle between them. Two caveats, though: Firstly,
Keymaps currently support only two scripts simultaneously. Secondly, if
both scripts you want to use are non-RTL, you have to turn off the RTL
option (see the RELEASE-NOTES, or
http://www.lyx.org/trac/browser/lyx-devel/branches/BRANCH_1_5_X/RELEASE-NOTES#L31?rev=20486).

Personally, I prefer keymaps. I have pointed out some of the reasons why
in a previous post
(http://permalink.gmane.org/gmane.editors.lyx.devel/88939), you can see
there if those reasons make sense to you or not, and that may help you
decide which method is better for you.

Note, however, that regardless of which method you use, you should also
make sure that the language of the text (Edit - Text style -
Customized... - Language) is set correctly. Otherwise, chances are that
latex will choke on the non-latin characters. This is where using a LyX
keymap has an advantage: since you can change the keymap from within
LyX, you can create a keybinding which will both switch the keymap and
set the language using only a single keystroke. I don't know of any way
to do this if you use OS-level keyboard support.

If you provide a little more specific information (which scripts? what
OS are your working on? ...) we may be able to provide further assistance.

Dov

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

Is it possible to write a document in LyX (1.5.1) that mixes two (or
more) scripts? If so, how?

I have been able to install and use an alternative keyboard map for a
non-latin script, but, even though one can specify two keyboard maps,
I have not been able to find anywhere in the documentation how to
select the second map.

Thanks.



Hi!

Yes, it is possible, there are actually a few different ways to do it. 
However, your success may also depend on which scripts specifically you 
are talking about.


The easiest way is perhaps to just switch the keyboard at the OS-level. 
Depending on your OS / Desktop Environment, you can probably change the 
keyboard's language, and then whatever you type will be in that script.


Another option is to use LyX's built-in keymaps. It sounds like you have 
already discovered this option. In order to use it, you can use the 
following keybindings: M-k 1 M-k 2 to choose the primary / secondary 
keymap; M-k t to toggle between them. Two caveats, though: Firstly, 
Keymaps currently support only two scripts simultaneously. Secondly, if 
both scripts you want to use are non-RTL, you have to turn off the RTL 
option (see the RELEASE-NOTES, or 
http://www.lyx.org/trac/browser/lyx-devel/branches/BRANCH_1_5_X/RELEASE-NOTES#L31?rev=20486).


Personally, I prefer keymaps. I have pointed out some of the reasons why 
in a previous post 
(http://permalink.gmane.org/gmane.editors.lyx.devel/88939), you can see 
there if those reasons make sense to you or not, and that may help you 
decide which method is better for you.


Note, however, that regardless of which method you use, you should also 
make sure that the language of the text (Edit - Text style - 
Customized... - Language) is set correctly. Otherwise, chances are that 
latex will choke on the non-latin characters. This is where using a LyX 
keymap has an advantage: since you can change the keymap from within 
LyX, you can create a keybinding which will both switch the keymap and 
set the language using only a single keystroke. I don't know of any way 
to do this if you use OS-level keyboard support.


If you provide a little more specific information (which scripts? what 
OS are your working on? ...) we may be able to provide further assistance.


Dov

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

Great, thanks. I wasn't setting  Edit - Text style -Customized...
- Language properly. Is there a key binding for this option?



There is an lfun called language which does exactly this, and which 
you can bind to any key you want. In Hebrew, we use F12 for the binding. 
I suggest adapting one of the files attached here, just use the language 
farsi: http://permalink.gmane.org/gmane.editors.lyx.devel/88941 . Just 
place the file to your .lyx/bind directory (I'm not sure what the 
Windows equivalent is, the truth is you could probably place the file 
anywhere), and select it as your bind file (Tools - Preferences... - 
Look and feel - User interface).


Note that since you're using an RTL language, then you shouldn't even 
have to use the bindings for explicitly setting the keymap (M-k 1, etc.) 
--- it should happen automatically when you switch the language.



When I am typing, it seems to work, but when I try to view it (for
example in DVI) I get latex errors such as:

LaTeX Error: Encoding scheme `LAE' unknown.
Command \alefhamza unavailable in encoding T1.
Package inputenc Error: Unicode char \u8:0' not set up for use with LaTeX.

I am trying to mix English and Farsi. I followed the instructions from
the Wiki (http://wiki.lyx.org/Windows/Farsi). I am running LyX 1.5.1
on Windows Vista, with MiKTeX 2.6.

What could be the problem?


I don't know the Farsi stuff, Mostafa is our Farsi expert. But some 
things I would check: are you sure that the arabi latex package is 
installed and set up correctly? What's bothering me is that the LAE 
encoding scheme seems to be unknown, I believe that's what should be 
used for Farsi.


Uwe, Mostafa --- any ideas?



By the way, I found that in menus.bind, both options for M-k o and
M-k x are set to keymap-off. If I change one of them to
'keymap-on', it seems to be ignored.


I'm not even sure what the keymap-off and keymap-on lfuns are supposed 
to do... But as I said above, for an RTL language, you shouldn't need 
any of the keymap lfuns, switching the language should take care of this 
as long as you've setup the keymaps to be used.






On 9/27/07, Dov Feldstern [EMAIL PROTECTED] wrote:

Ernesto Posse wrote:

Is it possible to write a document in LyX (1.5.1) that mixes two (or
more) scripts? If so, how?

I have been able to install and use an alternative keyboard map for a
non-latin script, but, even though one can specify two keyboard maps,
I have not been able to find anywhere in the documentation how to
select the second map.

Thanks.


Hi!

Yes, it is possible, there are actually a few different ways to do it.
However, your success may also depend on which scripts specifically you
are talking about.

The easiest way is perhaps to just switch the keyboard at the OS-level.
Depending on your OS / Desktop Environment, you can probably change the
keyboard's language, and then whatever you type will be in that script.

Another option is to use LyX's built-in keymaps. It sounds like you have
already discovered this option. In order to use it, you can use the
following keybindings: M-k 1 M-k 2 to choose the primary / secondary
keymap; M-k t to toggle between them. Two caveats, though: Firstly,
Keymaps currently support only two scripts simultaneously. Secondly, if
both scripts you want to use are non-RTL, you have to turn off the RTL
option (see the RELEASE-NOTES, or
http://www.lyx.org/trac/browser/lyx-devel/branches/BRANCH_1_5_X/RELEASE-NOTES#L31?rev=20486).

Personally, I prefer keymaps. I have pointed out some of the reasons why
in a previous post
(http://permalink.gmane.org/gmane.editors.lyx.devel/88939), you can see
there if those reasons make sense to you or not, and that may help you
decide which method is better for you.

Note, however, that regardless of which method you use, you should also
make sure that the language of the text (Edit - Text style -
Customized... - Language) is set correctly. Otherwise, chances are that
latex will choke on the non-latin characters. This is where using a LyX
keymap has an advantage: since you can change the keymap from within
LyX, you can create a keybinding which will both switch the keymap and
set the language using only a single keystroke. I don't know of any way
to do this if you use OS-level keyboard support.

If you provide a little more specific information (which scripts? what
OS are your working on? ...) we may be able to provide further assistance.

Dov

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

Is it possible to write a document in LyX (1.5.1) that mixes two (or
more) scripts? If so, how?

I have been able to install and use an alternative keyboard map for a
non-latin script, but, even though one can specify two keyboard maps,
I have not been able to find anywhere in the documentation how to
select the second map.

Thanks.



Hi!

Yes, it is possible, there are actually a few different ways to do it. 
However, your success may also depend on which scripts specifically you 
are talking about.


The easiest way is perhaps to just switch the keyboard at the OS-level. 
Depending on your OS / Desktop Environment, you can probably change the 
"keyboard's language", and then whatever you type will be in that script.


Another option is to use LyX's built-in keymaps. It sounds like you have 
already discovered this option. In order to use it, you can use the 
following keybindings: "M-k 1" "M-k 2" to choose the primary / secondary 
keymap; "M-k t" to toggle between them. Two caveats, though: Firstly, 
Keymaps currently support only two scripts simultaneously. Secondly, if 
both scripts you want to use are non-RTL, you have to turn off the RTL 
option (see the RELEASE-NOTES, or 
http://www.lyx.org/trac/browser/lyx-devel/branches/BRANCH_1_5_X/RELEASE-NOTES#L31?rev=20486).


Personally, I prefer keymaps. I have pointed out some of the reasons why 
in a previous post 
(http://permalink.gmane.org/gmane.editors.lyx.devel/88939), you can see 
there if those reasons make sense to you or not, and that may help you 
decide which method is better for you.


Note, however, that regardless of which method you use, you should also 
make sure that the language of the text (Edit -> Text style -> 
Customized... -> Language) is set correctly. Otherwise, chances are that 
latex will choke on the non-latin characters. This is where using a LyX 
keymap has an advantage: since you can change the keymap from within 
LyX, you can create a keybinding which will both switch the keymap and 
set the language using only a single keystroke. I don't know of any way 
to do this if you use OS-level keyboard support.


If you provide a little more specific information (which scripts? what 
OS are your working on? ...) we may be able to provide further assistance.


Dov

Re: Miximg scripts.

[Dov Feldstern]

Ernesto Posse wrote:

Great, thanks. I wasn't setting  "Edit -> Text style ->Customized...
-> Language" properly. Is there a key binding for this option?



There is an lfun called "language" which does exactly this, and which 
you can bind to any key you want. In Hebrew, we use F12 for the binding. 
I suggest adapting one of the files attached here, just use the language 
"farsi": http://permalink.gmane.org/gmane.editors.lyx.devel/88941 . Just 
place the file to your .lyx/bind directory (I'm not sure what the 
Windows equivalent is, the truth is you could probably place the file 
anywhere), and select it as your bind file (Tools -> Preferences... -> 
Look and feel -> User interface).


Note that since you're using an RTL language, then you shouldn't even 
have to use the bindings for explicitly setting the keymap (M-k 1, etc.) 
--- it should happen automatically when you switch the language.



When I am typing, it seems to work, but when I try to view it (for
example in DVI) I get latex errors such as:

LaTeX Error: Encoding scheme `LAE' unknown.
Command \alefhamza unavailable in encoding T1.
Package inputenc Error: Unicode char \u8:0' not set up for use with LaTeX.

I am trying to mix English and Farsi. I followed the instructions from
the Wiki (http://wiki.lyx.org/Windows/Farsi). I am running LyX 1.5.1
on Windows Vista, with MiKTeX 2.6.

What could be the problem?


I don't know the Farsi stuff, Mostafa is our Farsi expert. But some 
things I would check: are you sure that the "arabi" latex package is 
installed and set up correctly? What's bothering me is that the LAE 
encoding scheme seems to be unknown, I believe that's what should be 
used for Farsi.


Uwe, Mostafa --- any ideas?



By the way, I found that in menus.bind, both options for "M-k o" and
"M-k x" are set to "keymap-off". If I change one of them to
'keymap-on', it seems to be ignored.


I'm not even sure what the keymap-off and keymap-on lfuns are supposed 
to do... But as I said above, for an RTL language, you shouldn't need 
any of the keymap lfuns, switching the language should take care of this 
as long as you've setup the keymaps to be used.






On 9/27/07, Dov Feldstern <[EMAIL PROTECTED]> wrote:

Ernesto Posse wrote:

Is it possible to write a document in LyX (1.5.1) that mixes two (or
more) scripts? If so, how?

I have been able to install and use an alternative keyboard map for a
non-latin script, but, even though one can specify two keyboard maps,
I have not been able to find anywhere in the documentation how to
select the second map.

Thanks.


Hi!

Yes, it is possible, there are actually a few different ways to do it.
However, your success may also depend on which scripts specifically you
are talking about.

The easiest way is perhaps to just switch the keyboard at the OS-level.
Depending on your OS / Desktop Environment, you can probably change the
"keyboard's language", and then whatever you type will be in that script.

Another option is to use LyX's built-in keymaps. It sounds like you have
already discovered this option. In order to use it, you can use the
following keybindings: "M-k 1" "M-k 2" to choose the primary / secondary
keymap; "M-k t" to toggle between them. Two caveats, though: Firstly,
Keymaps currently support only two scripts simultaneously. Secondly, if
both scripts you want to use are non-RTL, you have to turn off the RTL
option (see the RELEASE-NOTES, or
http://www.lyx.org/trac/browser/lyx-devel/branches/BRANCH_1_5_X/RELEASE-NOTES#L31?rev=20486).

Personally, I prefer keymaps. I have pointed out some of the reasons why
in a previous post
(http://permalink.gmane.org/gmane.editors.lyx.devel/88939), you can see
there if those reasons make sense to you or not, and that may help you
decide which method is better for you.

Note, however, that regardless of which method you use, you should also
make sure that the language of the text (Edit -> Text style ->
Customized... -> Language) is set correctly. Otherwise, chances are that
latex will choke on the non-latin characters. This is where using a LyX
keymap has an advantage: since you can change the keymap from within
LyX, you can create a keybinding which will both switch the keymap and
set the language using only a single keystroke. I don't know of any way
to do this if you use OS-level keyboard support.

If you provide a little more specific information (which scripts? what
OS are your working on? ...) we may be able to provide further assistance.

Dov

Re: [OT] keymaps

[Dov Feldstern]

Charles de Miramon wrote:

Dov Feldstern wrote:


If we're talking about keymaps, then yes, I find them very useful. I
posted my reasons on the developers list a while back, and I hope to
eventually do some work on improving them, too. See
http://permalink.gmane.org/gmane.editors.lyx.devel/88939 .



If LyX was capable of communicating with the window manager through dbus, it
could send a message switch the keyboard to Hebrew when you enter the
cursor in a Hebrew text. 



I don't *want* to switch the keyboard at the system level. As I 
explained in item (4), I only want to switch the keyboard in my specific 
application (LyX), not for the entire OS.



KWin is capable of launching a window in a specific locale, so you can get
an Hebrew LyX in an English desktop.


I don't need KWin for that --- I can just set the locale in my shell 
before starting lyx (or wrapping it in a script, if I want to do that 
all the time). But anyhow, I'm not sure what the relevance of this is to 
keymaps: I use a Hebrew keymap in an English-UI LyX, the two issue are 
totally independent of each other, and they should remain that way.




It is not cross-platform, 


This is a major consideration.


but on one platform with a little scripting you
can get much more configurability than you can ever code into LyX. For
example, you could script then when you enter an Hebrew text a virtual
Hebrew keyboard appears on screen.



I don't see why keymaps are in the way of this kind of configurability. 
 Keymaps have a very specific use, and for my needs at least, they do 
what they're supposed to do better than any of the alternatives. If you 
also want to add dbus support --- for this or for any other purpose, 
then by all means, do (though the cross-platform issue would have to be 
considered).


As I've mentioned already, I don't see why anyone should *object* to 
keymaps. If you prefer the alternatives, the keymaps don't interfere 
with them in any way. But for those of us who *do* like keymaps, they 
are very useful, and can be made even more so with a little more work 
(which I still hope to get to eventually).



Cheers,
Charles


Dov

Re: [OT] keymaps

[Dov Feldstern]

Charles de Miramon wrote:

Dov Feldstern wrote:


If we're talking about keymaps, then yes, I find them very useful. I
posted my reasons on the developers list a while back, and I hope to
eventually do some work on improving them, too. See
http://permalink.gmane.org/gmane.editors.lyx.devel/88939 .



If LyX was capable of communicating with the window manager through dbus, it
could send a message switch the keyboard to Hebrew when you enter the
cursor in a Hebrew text. 



I don't *want* to switch the keyboard at the system level. As I 
explained in item (4), I only want to switch the keyboard in my specific 
application (LyX), not for the entire OS.



KWin is capable of launching a window in a specific locale, so you can get
an Hebrew LyX in an English desktop.


I don't need KWin for that --- I can just set the locale in my shell 
before starting lyx (or wrapping it in a script, if I want to do that 
all the time). But anyhow, I'm not sure what the relevance of this is to 
keymaps: I use a Hebrew keymap in an English-UI LyX, the two issue are 
totally independent of each other, and they should remain that way.




It is not cross-platform, 


This is a major consideration.


but on one platform with a little scripting you
can get much more configurability than you can ever code into LyX. For
example, you could script then when you enter an Hebrew text a virtual
Hebrew keyboard appears on screen.



I don't see why keymaps are in the way of this kind of configurability. 
 Keymaps have a very specific use, and for my needs at least, they do 
what they're supposed to do better than any of the alternatives. If you 
also want to add dbus support --- for this or for any other purpose, 
then by all means, do (though the cross-platform issue would have to be 
considered).


As I've mentioned already, I don't see why anyone should *object* to 
keymaps. If you prefer the alternatives, the keymaps don't interfere 
with them in any way. But for those of us who *do* like keymaps, they 
are very useful, and can be made even more so with a little more work 
(which I still hope to get to eventually).



Cheers,
Charles


Dov

Re: [OT] keymaps

[Dov Feldstern]

Charles de Miramon wrote:

Dov Feldstern wrote:


If we're talking about keymaps, then yes, I find them very useful. I
posted my reasons on the developers list a while back, and I hope to
eventually do some work on improving them, too. See
http://permalink.gmane.org/gmane.editors.lyx.devel/88939 .



If LyX was capable of communicating with the window manager through dbus, it
could send a message "switch the keyboard to Hebrew" when you enter the
cursor in a Hebrew text. 



I don't *want* to switch the keyboard at the system level. As I 
explained in item (4), I only want to switch the keyboard in my specific 
application (LyX), not for the entire OS.



KWin is capable of launching a window in a specific locale, so you can get
an Hebrew LyX in an English desktop.


I don't need KWin for that --- I can just set the locale in my shell 
before starting lyx (or wrapping it in a script, if I want to do that 
all the time). But anyhow, I'm not sure what the relevance of this is to 
keymaps: I use a Hebrew keymap in an English-UI LyX, the two issue are 
totally independent of each other, and they should remain that way.




It is not cross-platform, 


This is a major consideration.


but on one platform with a little scripting you
can get much more configurability than you can ever code into LyX. For
example, you could script then when you enter an Hebrew text a virtual
Hebrew keyboard appears on screen.



I don't see why keymaps are in the way of this kind of configurability. 
 Keymaps have a very specific use, and for my needs at least, they do 
what they're supposed to do better than any of the alternatives. If you 
also want to add dbus support --- for this or for any other purpose, 
then by all means, do (though the cross-platform issue would have to be 
considered).


As I've mentioned already, I don't see why anyone should *object* to 
keymaps. If you prefer the alternatives, the keymaps don't interfere 
with them in any way. But for those of us who *do* like keymaps, they 
are very useful, and can be made even more so with a little more work 
(which I still hope to get to eventually).



Cheers,
Charles


Dov

[OT] keymaps (was: Re: dead keys)

[Dov Feldstern]

Charles de Miramon wrote:


By the way, is there anybody who uses this lyx-specific keyboard
configuration ? In my opinion, it looks like a relic of the past and a
useless layer of complexity. Keyboards should be configured OS-wide.


If we're talking about keymaps, then yes, I find them very useful. I 
posted my reasons on the developers list a while back, and I hope to 
eventually do some work on improving them, too. See 
http://permalink.gmane.org/gmane.editors.lyx.devel/88939 .


However, I don't really know anything about dead-keys (I don't use 
them), so I'm not sure if it's the same keymap mechanism or not...


 
Cheers,

Charles


Dov

[OT] keymaps (was: Re: dead keys)

[Dov Feldstern]

Charles de Miramon wrote:


By the way, is there anybody who uses this lyx-specific keyboard
configuration ? In my opinion, it looks like a relic of the past and a
useless layer of complexity. Keyboards should be configured OS-wide.


If we're talking about keymaps, then yes, I find them very useful. I 
posted my reasons on the developers list a while back, and I hope to 
eventually do some work on improving them, too. See 
http://permalink.gmane.org/gmane.editors.lyx.devel/88939 .


However, I don't really know anything about dead-keys (I don't use 
them), so I'm not sure if it's the same keymap mechanism or not...


 
Cheers,

Charles


Dov

[OT] keymaps (was: Re: dead keys)

[Dov Feldstern]

Charles de Miramon wrote:


By the way, is there anybody who uses this lyx-specific keyboard
configuration ? In my opinion, it looks like a relic of the past and a
useless layer of complexity. Keyboards should be configured OS-wide.


If we're talking about keymaps, then yes, I find them very useful. I 
posted my reasons on the developers list a while back, and I hope to 
eventually do some work on improving them, too. See 
http://permalink.gmane.org/gmane.editors.lyx.devel/88939 .


However, I don't really know anything about dead-keys (I don't use 
them), so I'm not sure if it's the same keymap mechanism or not...


 
Cheers,

Charles


Dov

Re: Problem with Hebrew Lyx - Reply

[Dov Feldstern]

Gideon Livshits wrote:

Hello!

Firstly, I would like to thank you for your quick response to my 
problem. It means a lot!


You're welcome. In general, you'll find people on the lyx mailing lists 
to be very responsive and helpful :) .


(BTW, I'm CC-ing the mailing lists, so that this gets into the mailing 
lists archives, and may prove useful to other users. For those other 
users: this is correspondence regarding 
http://bugzilla.lyx.org/show_bug.cgi?id=4228)




I sent an example file to the following address: [EMAIL PROTECTED]

I attach it again here.



The file you sent works for me --- so my guess is that it's a latex 
configuration issue. See below...


Soon after posting the bug, I realized that I should have kept the 
encoding default, which I did (as you mentioned). This changed the list 
of errors - from about 8 to only one, in which it complained it was 
lacking the jerus10 font, and therefore would produce neither dvi nor 
postscript.


To clarify, I am giving you all the relevant details:
Under Document Settings I have made the following changes (to 
accommodate Hebrew):

Document Class: article (Hebrew)
Postscript driver: Dvips (tried this because I saw the others weren't 
working - it too doesn't work)

Fonts: Changed nothing (kept defaults)
The same goes for everything else, I only changed the language to 
Hebrew. I *kept* the original tick under Use language's default encoding.


Under Preferences the only change I made was to select Hebrew as the 
default language instead of Hebrew (which I think is wrong anyway, since 
it apparently applies to the language of interface, which I want to stay 
in English). 


(Hmm..., I think the user interface also has to do with locale settings 
--- you should be able to change the default document language without 
changing the UI, maybe by playing around with those. If you're compiling 
from source, you can use the --disable-nls option when configuring, and 
then the UI will certainly not change... But this has nothing to do with 
the main problem we're discussing.)


So here it is:

User interface file: default
Bind file: mac
Default Language: Hebrew.


(also as an aside: some additional LyX setup which you might want to 
perform is to use keymaps --- these allow you to use Hebrew without 
having to switch languages at the keyboard level; and then also to have 
some keybindings for switching languages. See Dekel's instructions at 
http://www.cs.bgu.ac.il/~dekelts/lyx/instructions2.html, though you'll 
have to play around with it to see which parts you want and which you 
don't, they may not be up to date; and see 
http://permalink.gmane.org/gmane.editors.lyx.devel/88941 for key 
bindings files --- I would use these instead of the ones Dekel mentions.)


My Latex distribution is LiveTex 2007. You mention ivritex - I don't 
know what this is, and I don't have it installed (at least I think I 
don't). Would this fix everything? Do you know where I could get it?


ivritex (http://ivritex.sf.net) is the name of the project for adding 
Hebrew support to babel. It used to be a standalone package, but has 
been incorporated into the latest versions of babel, so if you have 
babel 3.8 then it already includes hebrew support built-in. However, you 
may still need other support packages (fonts, etc.).


I'm using TeXLive 2007 (I assume this is the same as LiveTeX?), though 
I'm on Linux/debian. This already uses babel 3.8, so there's no need for 
installing ivritex separately. There's a debian package called 
texlive-lang-hebrew, which provides a latex package called cjhebrew 
which provides the additional support needed. Try and see if you have 
some similar package that you could install.


Another option is to use the culmus fonts. For that, I think that you'll 
have to download the culmus fonts (http://culmus.sourceforge.net/, 
chances are it's also bundled for your OS), as well as install (from 
source) culmus-latex, which is an in-development part of ivritex for 
supporting the culmus fonts 
(http://sourceforge.net/project/showfiles.php?group_id=33341). Just 
installing that package may be enough.


In either case, I think one or both of the two options mentioned above 
is what will solve your issue (again, let us know either way). If you 
still need more help with correctly setting up Hebrew with LaTeX, you 
should also check out the ivritex mailing list.




Thanks a lot for all your help,

Gideon

P. S. Please tell me if I missed something or if you need more information.



Good luck, Gmar Hatima Tova!
Dov

Re: Problem with Hebrew Lyx - Reply

[Dov Feldstern]

Gideon Livshits wrote:

Hello!

Firstly, I would like to thank you for your quick response to my 
problem. It means a lot!


You're welcome. In general, you'll find people on the lyx mailing lists 
to be very responsive and helpful :) .


(BTW, I'm CC-ing the mailing lists, so that this gets into the mailing 
lists archives, and may prove useful to other users. For those other 
users: this is correspondence regarding 
http://bugzilla.lyx.org/show_bug.cgi?id=4228)




I sent an example file to the following address: [EMAIL PROTECTED]

I attach it again here.



The file you sent works for me --- so my guess is that it's a latex 
configuration issue. See below...


Soon after posting the bug, I realized that I should have kept the 
encoding default, which I did (as you mentioned). This changed the list 
of errors - from about 8 to only one, in which it complained it was 
lacking the jerus10 font, and therefore would produce neither dvi nor 
postscript.


To clarify, I am giving you all the relevant details:
Under Document Settings I have made the following changes (to 
accommodate Hebrew):

Document Class: article (Hebrew)
Postscript driver: Dvips (tried this because I saw the others weren't 
working - it too doesn't work)

Fonts: Changed nothing (kept defaults)
The same goes for everything else, I only changed the language to 
Hebrew. I *kept* the original tick under Use language's default encoding.


Under Preferences the only change I made was to select Hebrew as the 
default language instead of Hebrew (which I think is wrong anyway, since 
it apparently applies to the language of interface, which I want to stay 
in English). 


(Hmm..., I think the user interface also has to do with locale settings 
--- you should be able to change the default document language without 
changing the UI, maybe by playing around with those. If you're compiling 
from source, you can use the --disable-nls option when configuring, and 
then the UI will certainly not change... But this has nothing to do with 
the main problem we're discussing.)


So here it is:

User interface file: default
Bind file: mac
Default Language: Hebrew.


(also as an aside: some additional LyX setup which you might want to 
perform is to use keymaps --- these allow you to use Hebrew without 
having to switch languages at the keyboard level; and then also to have 
some keybindings for switching languages. See Dekel's instructions at 
http://www.cs.bgu.ac.il/~dekelts/lyx/instructions2.html, though you'll 
have to play around with it to see which parts you want and which you 
don't, they may not be up to date; and see 
http://permalink.gmane.org/gmane.editors.lyx.devel/88941 for key 
bindings files --- I would use these instead of the ones Dekel mentions.)


My Latex distribution is LiveTex 2007. You mention ivritex - I don't 
know what this is, and I don't have it installed (at least I think I 
don't). Would this fix everything? Do you know where I could get it?


ivritex (http://ivritex.sf.net) is the name of the project for adding 
Hebrew support to babel. It used to be a standalone package, but has 
been incorporated into the latest versions of babel, so if you have 
babel 3.8 then it already includes hebrew support built-in. However, you 
may still need other support packages (fonts, etc.).


I'm using TeXLive 2007 (I assume this is the same as LiveTeX?), though 
I'm on Linux/debian. This already uses babel 3.8, so there's no need for 
installing ivritex separately. There's a debian package called 
texlive-lang-hebrew, which provides a latex package called cjhebrew 
which provides the additional support needed. Try and see if you have 
some similar package that you could install.


Another option is to use the culmus fonts. For that, I think that you'll 
have to download the culmus fonts (http://culmus.sourceforge.net/, 
chances are it's also bundled for your OS), as well as install (from 
source) culmus-latex, which is an in-development part of ivritex for 
supporting the culmus fonts 
(http://sourceforge.net/project/showfiles.php?group_id=33341). Just 
installing that package may be enough.


In either case, I think one or both of the two options mentioned above 
is what will solve your issue (again, let us know either way). If you 
still need more help with correctly setting up Hebrew with LaTeX, you 
should also check out the ivritex mailing list.




Thanks a lot for all your help,

Gideon

P. S. Please tell me if I missed something or if you need more information.



Good luck, Gmar Hatima Tova!
Dov

Re: Problem with Hebrew Lyx - Reply

[Dov Feldstern]

Gideon Livshits wrote:

Hello!

Firstly, I would like to thank you for your quick response to my 
problem. It means a lot!


You're welcome. In general, you'll find people on the lyx mailing lists 
to be very responsive and helpful :) .


(BTW, I'm CC-ing the mailing lists, so that this gets into the mailing 
lists archives, and may prove useful to other users. For those other 
users: this is correspondence regarding 
http://bugzilla.lyx.org/show_bug.cgi?id=4228)




I sent an example file to the following address: [EMAIL PROTECTED]

I attach it again here.



The file you sent works for me --- so my guess is that it's a latex 
configuration issue. See below...


Soon after posting the bug, I realized that I should have kept the 
encoding default, which I did (as you mentioned). This changed the list 
of errors - from about 8 to only one, in which it complained it was 
lacking the jerus10 font, and therefore would produce neither dvi nor 
postscript.


To clarify, I am giving you all the relevant details:
Under Document Settings I have made the following changes (to 
accommodate Hebrew):

Document Class: article (Hebrew)
Postscript driver: Dvips (tried this because I saw the others weren't 
working - it too doesn't work)

Fonts: Changed nothing (kept defaults)
The same goes for everything else, I only changed the language to 
Hebrew. I *kept* the original tick under "Use language's default encoding".


Under Preferences the only change I made was to select Hebrew as the 
default language instead of Hebrew (which I think is wrong anyway, since 
it apparently applies to the language of interface, which I want to stay 
in English). 


(Hmm..., I think the user interface also has to do with locale settings 
--- you should be able to change the default document language without 
changing the UI, maybe by playing around with those. If you're compiling 
from source, you can use the --disable-nls option when configuring, and 
then the UI will certainly not change... But this has nothing to do with 
the main problem we're discussing.)


So here it is:

User interface file: default
Bind file: mac
Default Language: Hebrew.


(also as an aside: some additional LyX setup which you might want to 
perform is to use keymaps --- these allow you to use Hebrew without 
having to switch languages at the keyboard level; and then also to have 
some keybindings for switching languages. See Dekel's instructions at 
http://www.cs.bgu.ac.il/~dekelts/lyx/instructions2.html, though you'll 
have to play around with it to see which parts you want and which you 
don't, they may not be up to date; and see 
http://permalink.gmane.org/gmane.editors.lyx.devel/88941 for key 
bindings files --- I would use these instead of the ones Dekel mentions.)


My Latex distribution is LiveTex 2007. You mention ivritex - I don't 
know what this is, and I don't have it installed (at least I think I 
don't). Would this fix everything? Do you know where I could get it?


ivritex (http://ivritex.sf.net) is the name of the project for adding 
Hebrew support to babel. It used to be a standalone package, but has 
been incorporated into the latest versions of babel, so if you have 
babel 3.8 then it already includes hebrew support built-in. However, you 
may still need other support packages (fonts, etc.).


I'm using TeXLive 2007 (I assume this is the same as LiveTeX?), though 
I'm on Linux/debian. This already uses babel 3.8, so there's no need for 
installing ivritex separately. There's a debian package called 
texlive-lang-hebrew, which provides a latex package called cjhebrew 
which provides the additional support needed. Try and see if you have 
some similar package that you could install.


Another option is to use the culmus fonts. For that, I think that you'll 
have to download the culmus fonts (http://culmus.sourceforge.net/, 
chances are it's also bundled for your OS), as well as install (from 
source) culmus-latex, which is an in-development part of ivritex for 
supporting the culmus fonts 
(http://sourceforge.net/project/showfiles.php?group_id=33341). Just 
installing that package may be enough.


In either case, I think one or both of the two options mentioned above 
is what will solve your issue (again, let us know either way). If you 
still need more help with correctly setting up Hebrew with LaTeX, you 
should also check out the ivritex mailing list.




Thanks a lot for all your help,

Gideon

P. S. Please tell me if I missed something or if you need more information.



Good luck, Gmar Hatima Tova!
Dov

Re: using rc1

[Dov Feldstern]

Sven Schreiber wrote:


Abdelrazak Younes schrieb:

I think these bugs will not show up in RC1 if you disable the RTL
support option in the Preference-Language Settings-Language option.



Very interesting, thank you for the hint!

I don't mean to be disrespectful for RTL language users, but maybe
disabling that option by default would be safer? (Assuming that the
majority of lyx users don't use RTL.)

thanks,
sven



:) . Actually, we are now experimenting with going in the other 
direction --- i.e., enabling this option by default --- and we may in 
the future get rid of the option entirely (i.e., have it always on). So 
it would be better if (as soon as you're using a version in which the 
above bugs are fixed) you would switch the RTL option back on, and then 
let us know if you see anything bad resulting from this: more bugs, 
slowness (which is solved by turning RTL off), etc. If we see that it 
really affects non-RTL users adversely, then we will go back to having 
it off by default. But if it doesn't hurt, we'd rather have it on.


Dov

Re: using rc1

[Dov Feldstern]

Sven Schreiber wrote:


Abdelrazak Younes schrieb:

I think these bugs will not show up in RC1 if you disable the RTL
support option in the Preference-Language Settings-Language option.



Very interesting, thank you for the hint!

I don't mean to be disrespectful for RTL language users, but maybe
disabling that option by default would be safer? (Assuming that the
majority of lyx users don't use RTL.)

thanks,
sven



:) . Actually, we are now experimenting with going in the other 
direction --- i.e., enabling this option by default --- and we may in 
the future get rid of the option entirely (i.e., have it always on). So 
it would be better if (as soon as you're using a version in which the 
above bugs are fixed) you would switch the RTL option back on, and then 
let us know if you see anything bad resulting from this: more bugs, 
slowness (which is solved by turning RTL off), etc. If we see that it 
really affects non-RTL users adversely, then we will go back to having 
it off by default. But if it doesn't hurt, we'd rather have it on.


Dov

Re: using rc1

[Dov Feldstern]

Sven Schreiber wrote:


Abdelrazak Younes schrieb:

I think these bugs will not show up in RC1 if you disable the "RTL
support" option in the Preference->Language Settings->Language option.



Very interesting, thank you for the hint!

I don't mean to be disrespectful for RTL language users, but maybe
disabling that option by default would be safer? (Assuming that the
majority of lyx users don't use RTL.)

thanks,
sven



:) . Actually, we are now experimenting with going in the other 
direction --- i.e., enabling this option by default --- and we may in 
the future get rid of the option entirely (i.e., have it always on). So 
it would be better if (as soon as you're using a version in which the 
above bugs are fixed) you would switch the RTL option back on, and then 
let us know if you see anything bad resulting from this: more bugs, 
slowness (which is solved by turning RTL off), etc. If we see that it 
really affects non-RTL users adversely, then we will go back to having 
it off by default. But if it doesn't hurt, we'd rather have it on.


Dov

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

[Dov Feldstern]

Miki Dovrat wrote:

Hi,

I already replied Stefan off list, but I will post this again so anyone can 
comment.


The brain (at least mine) does not like movement to the opposite side. When
you press the left arrow, you expect the cursor to move to the left. Try
riding a bike with the hands crossed, wear a helmet!!!

So I think the visual movement is the most convenient and intuitive.

Microsoft Word is an example of how NOT to do it. It does not change the RTL
or LTR mode except by an explicit request by the user (ALT-SHIFT), and even
as you cruise into a RTL part, and you want to add a letter, if you were
writing English before, the added letter will be English. And the cursor
movement is to the opposite side (it jumps to the end of the RTL, and goes
backwards in opposite of the arrow key).

As far as getting used to logical movement, you can get used to anything,
but it is easier to get used to good things. Nobody complains about Word
since the Israeli market is small and big companies always do us (the Hebrew
users) a favor by thinking about us at all, so we accept whatever is given
us.

I would like lyx to be a little smarter, and to change its RTL or LTR mode
by itself as you move across already written text. When you point at a word,
the most COMMON intention is to add letter or fix spelling or continue
writing, so lyx should already put you in the right language (it doesn't do
so now). If you want the opposite language, I think you should ask for it
explicitly once you are in place.

Thanks for the interest.

Miki


Stefan Schimanski [EMAIL PROTECTED] wrote in 
message news:[EMAIL PROTECTED] 







Hi all!

Instead of replying individually to all the messages on this subject, 
I'll try to sum up my responses here.


First of all, just for the record --- as Miki pointed out, I *am* an RTL 
user ;) . I also have a lot of experience with Bidi editing in LyX. It's 
just that this issue is particularly thorny --- because what I consider 
to be the correct solution (the one that does not impose limits on the 
user) is 99.9% of the time *not* what the user meant (I'll explain below).


-

But first: a side issue which has been raised in this thread is that of 
visual movement.


A feature request for this already appears in bugzilla 
(http://bugzilla.lyx.org/show_bug.cgi?id=3577). Note, however, that this 
should *not* replace logical mode, but rather be an option for the user 
to choose which she prefers.


Regarding implementation of visual mode:

*) I agree 100% with Miki above about how it should work: the current 
language should be determined by the current font, *not* by remembering 
what the last font was.


*) The basic idea for implementing visual mode is dead simple: pressing 
RIGHT in LTR paragraphs (LEFT in RTL) should move to position 
vis2log(log2vis(pos)+1), and the opposite is with -1. (vis2log and 
log2vis are in Bidi.cpp. In this case, Stefan, I think you're going to 
*have* to use them, I don't see any way around it).
But there are a lot of details to work out: there may still be issues of 
boundary, I'm not sure; there also may be some logic needed in order to 
make the transitions between paragraphs behave correctly (e.g., I'm in 
an LTR paragraph moving RIGHT. When I reach the end of the paragraph, 
pressing RIGHT again should move me to the *end* of the first line in 
the next paragraph if it's RTL. I'm not sure if this is already covered 
by vis2log or not.); math insets would have to be adjusted separately, I 
think. But basically that's it. But I think it'll take a little work to 
work out the kinks.


I'm attaching a patch which just demonstrates the feasibility of this 
approach. It crashes all over (or shall I say: left and right?) --- I 
don't deal with any edge (no pun intended) case whatever. But if you 
type in some mixed English--Hebrew text on a single line, with the mouse 
move the cursor somewhere that's not at an edge, then you can move 
around visually as long as you stay away from the edge. But the problem, 
of course, is working out all the details...


In the meantime, we have tried to make cursor movement in bidi documents 
behave a little more predictably:


In an LTR paragraph, RIGHT moves forward (logically) --- both in RTL and 
in LTR texts (so in RTL it's moving opposite to the arrow, yes) --- and 
LEFT backwards. And the reverse for RTL paragraphs. Insets (e.g., 
footnote) within a paragraph also follow this rule: in an RTL inset 
inside an LTR paragraph, arrow direction will be backwards. This was 
implemented in order to avoid the cursor getting stuck between RTL and 
LTR insets, as it used to up until now.


Two other differences which provide the user with some visual feedback 
which make typing bidi a little easier:
1) The language of spaces is now marked; so if something funny is 
happening with spaces in bidi, it's a little easier to figure out why.
2) As in previous versions of LyX, the cursor will now change shape