Re: Arabic\Farsi and XeTeX, testing a patch

[Ronen Abravanel]

In Unicode there is a strict convention, for both Hebrew and Arabic:

The character for open braces is the same as in English, and the same with
close braces, and it mirrored in the display.
** Standard English keyboard layout, Shift+9 creates (, ASCII code #41
and Shift+0 creates ), ASCII code #41
* In Hebrew keyboard layout, Shift+0 creates ASCII #40  [open] and Shift+9
creates #41 (close)
* Unicode algorithm switch the screen-display of many characters according
to the general direction.
List of mirrored-chars from Perl's Unicode library:
http://perl5.git.perl.org/perl.git/blob/HEAD:/lib/unicore/BidiMirroring.txt
The mirroring part of Unicode standard:
http://unicode.org/reports/tr9/#Mirroring
Unicode is the same for Hebrew and Arabic.

So, proper unicode  text is
Hebrew #40 Hebrew #41 Hebrew
(and the same for Arabic)

LaTeX\PDFLaTeX needs to get ASCII#41 for open Hebrew brace and #40 for
close Hebrew brace.
For Arabic, (according to LyX's pdf-latex output), Same as Unicode: #40
open and #41 close.
BUT! for other type of braces:  for example, angle, =#60 =#62,
So, in Arabic, as in Hebrew, One opens with #62 and close with, #60.
I'm not sure how the PDF produced by this convention look like, as
texlive-lang-arabic (debian) is not sufficient to compile it. I'll assume
that lyx produce proper output. s

Example text with these conventions:
hebrew #41 hebrew #40 hebrew #62 hebrew #60 hebrew
arabic #40 arabic #41 arabic #62 arabic #60 arabic


XeTeX conforms with Unicode (#40 to open and #41 to close,
display-direction defined by the surrounding language)

In LyX:
* Hebrew: Shift+0 = open = #41. Shift+9=close =#40.
* Arabic: Shift+0 = #40, but LyX draws it as #41, according to Unicode
standard. Shift+9=#41, but LyX draws #40.


So, this is weird!
It seems like Arabic-regular-tex format is inconsistent: the behavior of ()
is different then the behavior of . Further more, the char display on the
screen when one type Shift+9 or Shift+0 is opposite to the one on (my)
keyboard.
In any other aspect, Arabic and Hebrew in LyX are the same, and opposite
from Unicode.


I'm not sure how one can solve the mess:
One option is to make LyX editor full Unicode complaint. I'm sure it will
require a lot of work, file-format change and non-trivial conversion.  and
then, only the-non-polyglassia output will have to switch the braces
backwards.
Other options is just keep patching the different kind of Unicode-outputs,
the same is done in bug #8251 (And it seems that solving #8278 will be more
complicated, as no one around the xhtml exporter uses BufferParams, so it
will be a long way to carry it.

Ronen.



On Sun, Jul 29, 2012 at 12:32 PM, Jürgen Spitzmüller sp...@lyx.org wrote:

 2012/7/28 Ronen Abravanel ron...@gmail.com:
  When I'm typing Hebrew, I want to open braces by typing Shift+0  and
 close
  by Shift+9
  When I'm typing English, I want to open braces with Shift+0 and close
 with
  Shift+0
 
  I'm not sure what you mean by correct input .

 I suppose there might be arguments for both ways, depending on the
 perspective. The current Hebrew way (in LyX) is to get on screen
 (and in the output) the parenthesis in the form it is represented on
 the keyboard -- i.e.: if I press ), I want to get ).

 The current Arabic way could be oriented on the (Western) semantics
 of the glyphs: The ( key produces an opening parenthesis, both in
 LTR -- (open... -- and in RTL -- ...nepo). But this is just me
 guessing wildly.

 What is inconsistent in the Arabic way, at least, is that it only
 concerns (round) parentheses. All other brackets -- [], {},  -- are
 handled as in Hebrew, and they are also stored reversed in the LyX
 file (as in Hebrew).

 Jürgen

Re: Arabic\Farsi and XeTeX, testing a patch

[Ronen Abravanel]

In Unicode there is a strict convention, for both Hebrew and Arabic:

The character for open braces is the same as in English, and the same with
"close braces", and it mirrored in the display.
** Standard "English" keyboard layout, Shift+9 creates (, ASCII code #41
and Shift+0 creates ), ASCII code #41
* In Hebrew keyboard layout, Shift+0 creates ASCII #40  [open] and Shift+9
creates #41 (close)
* Unicode algorithm switch the screen-display of many characters according
to the "general" direction.
List of mirrored-chars from Perl's Unicode library:
http://perl5.git.perl.org/perl.git/blob/HEAD:/lib/unicore/BidiMirroring.txt
The mirroring part of Unicode standard:
http://unicode.org/reports/tr9/#Mirroring
Unicode is the same for Hebrew and Arabic.

So, proper unicode  text is
Hebrew #40 Hebrew #41 Hebrew
(and the same for Arabic)

LaTeX\PDFLaTeX needs to get ASCII#41 for open Hebrew brace and #40 for
close Hebrew brace.
For Arabic, (according to LyX's pdf-latex output), Same as Unicode: #40
open and #41 close.
BUT! for other type of braces:  for example, angle, "<"=#60 ">"=#62,
So, in Arabic, as in Hebrew, One opens with #62 and close with, #60.
I'm not sure how the PDF produced by this convention look like, as
texlive-lang-arabic (debian) is not sufficient to compile it. I'll assume
that lyx produce proper output. s

Example text with these conventions:
hebrew #41 hebrew #40 hebrew #62 hebrew #60 hebrew
arabic #40 arabic #41 arabic #62 arabic #60 arabic


XeTeX conforms with Unicode (#40 to open and #41 to close,
display-direction defined by the surrounding language)

In LyX:
* Hebrew: Shift+0 = "open" = #41. Shift+9="close" =#40.
* Arabic: Shift+0 = #40, but LyX draws it as #41, according to Unicode
standard. Shift+9=#41, but LyX draws #40.


So, this is weird!
It seems like Arabic-regular-tex format is inconsistent: the behavior of ()
is different then the behavior of <>. Further more, the char display on the
screen when one type Shift+9 or Shift+0 is opposite to the one on (my)
keyboard.
In any other aspect, Arabic and Hebrew in LyX are the same, and opposite
from Unicode.


I'm not sure how one can solve the mess:
One option is to make LyX editor full Unicode complaint. I'm sure it will
require a lot of work, file-format change and non-trivial conversion.  and
then, only the-non-polyglassia output will have to switch the braces
backwards.
Other options is just keep patching the different kind of Unicode-outputs,
the same is done in bug #8251 (And it seems that solving #8278 will be more
complicated, as no one around the xhtml exporter uses BufferParams, so it
will be a long way to carry it.

Ronen.



On Sun, Jul 29, 2012 at 12:32 PM, Jürgen Spitzmüller <sp...@lyx.org> wrote:

> 2012/7/28 Ronen Abravanel <ron...@gmail.com>:
> > When I'm typing Hebrew, I want to open braces by typing Shift+0  and
> close
> > by Shift+9
> > When I'm typing English, I want to open braces with Shift+0 and close
> with
> > Shift+0
> >
> > I'm not sure what you mean by "correct input" .
>
> I suppose there might be arguments for both ways, depending on the
> perspective. The current "Hebrew" way (in LyX) is to get on screen
> (and in the output) the parenthesis in the form it is represented on
> the keyboard -- i.e.: if I press ")", I want to get ")".
>
> The current "Arabic" way could be oriented on the (Western) semantics
> of the glyphs: The "(" key produces an opening parenthesis, both in
> LTR -- "(open..." -- and in RTL -- "...nepo)". But this is just me
> guessing wildly.
>
> What is inconsistent in the "Arabic" way, at least, is that it only
> concerns (round) parentheses. All other brackets -- [], {}, <> -- are
> handled as in Hebrew, and they are also stored reversed in the LyX
> file (as in Hebrew).
>
> Jürgen
>

Re: LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

On Thu, Jul 19, 2012 at 11:17 AM, Guenter Milde mi...@users.sf.net wrote:

 On 2012-07-18, Ronen Abravanel wrote:
  On Wed, Jul 18, 2012 at 11:09 AM, Guenter Milde mi...@users.sf.net
 wrote:
  On 2012-07-16, Ronen Abravanel wrote:

 ...

  * What do you get if the example is written as

  שלום (שלום)

in LyX?

  Just Hello (Hello) in hebrew
  In LyX it's
  שלום (שלום)


  * How would you write the same in OpenOffice or some other word
  processor?

  If I *write* the same thing in a different word processor (OO, ms word or
  other bidi-supported WP) I get the brace proper. If I paste the tex-code
  into a word processor, it's inverted as in the PDF.

 This is why I wonder whether XeTeX gets it right (i.e. compatible with
 other
 applications) and pdfLaTeX does it wrong.

 Then, instead of fixing XeTeX input, we would need a fix for the export
 to traditional TeX and a way to convert existing LyX documents.

 Günter


XeTexX get in in the modern (unicode) sense of right.
LyX, by default, input it wrong, but LyX output is good for pdfLaTeX.

LyX fixes it's output in the plain-text output, and my patch apply the same
correction for Hebrew-XeTeX output...

Ronen

Re: LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

On Thu, Jul 19, 2012 at 11:17 AM, Guenter Milde <mi...@users.sf.net> wrote:

> On 2012-07-18, Ronen Abravanel wrote:
> > On Wed, Jul 18, 2012 at 11:09 AM, Guenter Milde <mi...@users.sf.net>
> wrote:
> >> On 2012-07-16, Ronen Abravanel wrote:
>
> ...
>
> >> * What do you get if the example is written as
>
> >> שלום (שלום)
>
> >>   in LyX?
>
> > Just "Hello (Hello)" in hebrew
> > In LyX it's
> > שלום (שלום)
>
>
> >> * How would you write the same in OpenOffice or some other "word
> >> processor"?
>
> > If I *write* the same thing in a different word processor (OO, ms word or
> > other bidi-supported WP) I get the brace proper. If I paste the tex-code
> > into a word processor, it's inverted as in the PDF.
>
> This is why I wonder whether XeTeX gets it right (i.e. compatible with
> other
> applications) and pdfLaTeX does it wrong.
>
> Then, instead of "fixing" XeTeX input, we would need a fix for the export
> to traditional TeX and a way to convert existing LyX documents.
>
> Günter
>
>
XeTexX get in in the modern (unicode) sense of right.
LyX, by default, input it "wrong", but LyX output is good for pdfLaTeX.

LyX fixes it's output in the plain-text output, and my patch apply the same
correction for Hebrew-XeTeX output...

Ronen

Re: LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

On Wed, Jul 18, 2012 at 11:09 AM, Guenter Milde mi...@users.sf.net wrote:

 On 2012-07-16, Ronen Abravanel wrote:

  [-- Type: text/plain, Encoding: quoted-printable --]

  These files produced directly by the GIT version of LyX.
  As you can see, the braces are the inverted in both the PDF and the TeX
  files.

 However, they are inverted in the source file too!

 * What do you get if the example is written as

 שלום (שלום)

   in LyX?

Just Hello (Hello) in hebrew
In LyX it's
שלום (שלום)


 * How would you write the same in OpenOffice or some other word
 processor?

If I *write* the same thing in a different word processor (OO, ms word or
other bidi-supported WP) I get the brace proper. If I paste the tex-code
into a word processor, it's inverted as in the PDF.


 After all, this is rather a XeTeX vs. pdfLaTeX problem: what does an
 internet recherche for Hebrew polyglossia XeTeX reveal? Did you also try
 LuaTeX?


Never seen working LuaTeX in Hebrew.


 Günter



Anyway, I fixed it (patch in my previews mail).
The bug is in the old latex\latex export: the hebrew support in LaTeX
was broken so it was fixed in LyX. now, XeTeX need to get proper text so
LyX should produce proper unicode file.

Ronen.

Re: LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

On Wed, Jul 18, 2012 at 11:09 AM, Guenter Milde <mi...@users.sf.net> wrote:

> On 2012-07-16, Ronen Abravanel wrote:
>
> > [-- Type: text/plain, Encoding: quoted-printable --]
>
> > These files produced directly by the GIT version of LyX.
> > As you can see, the braces are the inverted in both the PDF and the TeX
> > files.
>
> However, they are inverted in the source file too!
>
> * What do you get if the example is written as
>
> שלום (שלום)
>
>   in LyX?
>
Just "Hello (Hello)" in hebrew
In LyX it's
שלום (שלום)


> * How would you write the same in OpenOffice or some other "word
> processor"?
>
If I *write* the same thing in a different word processor (OO, ms word or
other bidi-supported WP) I get the brace proper. If I paste the tex-code
into a word processor, it's inverted as in the PDF.


> After all, this is rather a XeTeX vs. pdfLaTeX problem: what does an
> internet recherche for "Hebrew polyglossia XeTeX" reveal? Did you also try
> LuaTeX?
>

Never seen working LuaTeX in Hebrew.

>
> Günter
>
>

Anyway, I fixed it (patch in my previews mail).
The "bug" is in the "old" latex\latex export: the hebrew support in LaTeX
was broken so it was fixed in LyX. now, XeTeX need to get proper text so
LyX should produce proper unicode file.

Ronen.

Re: LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

These files produced directly by the GIT version of LyX.
As you can see, the braces are the inverted in both the PDF and the TeX
files.

Ronen.


On Fri, Jul 13, 2012 at 9:38 PM, Ronen Abravanel ron...@gmail.com wrote:

 1. you are right. one can do that, and it would be a nice workaround. But
 I prefer lyx will  produce clean TeX file.
 2. Attached some examples:
 the text in the *xetex and *pdf files are identical. in the pdf, you can
 see that the braces are rendered backword, and also if you will open the
 .tex file in unicode-enables editor.


 note: I cheated a little. In my work-computer I have lyx 2.1 development
 version, and the xetex file compiled straight forward. In my lyx 2.03 in my
 laptop, I had to move one line in the preamble.


 Ronen

 On Fri, Jul 13, 2012 at 11:00 AM, Guenter Milde mi...@users.sf.netwrote:

 On 2012-07-12, Ronen Abravanel wrote:

  as the Hebrew support of LaTeX is not developed for the last several
  years, I decided to try and export Hebrew document to PDF using XeTeX,

 Are there problems that did not get solved for years, or is there no
 development because it just works?

  where the grate Bidi packge by Vafa Khalighi is under active
  development, and merged in polyglossia.

  LyX 2.0 support XeTeX support, but there are some slight problem:

  1. when exporting to regular latex, one should wrap english text
  (like
  numbers, math, etc..)  inside Hebrew parts by \L{.,, }.

 Do you do this with raw LaTeX (ERT) or is there an inset for the task
 (should be easy to write one if its not already there).

  not true in XeTeX. Attached an ugly patch that removes such \L, but:
  a. it's pretty ugly. I'm sure there is better way to do it. I will be
 happy
  for suggestions about ways to improve it.

 For documents that shall work in both, pdflatex and xelatex, it might be
 best to have a dummy definition like

   \ifxetex
  \providecommand*{\L}[1]{#1}
   \fi

 either in the documents LaTeX preamble or in the module defining the text
 inset).

 ...

  2. LyX making some problems with the braces { } ( ) etc in Right-to-left
  parts:
  When one writes Right-to-left text that should look like
  (1) text ( inside braces ) more text
  it outputs as
  (2) text ) inside braces ( more text
  or, to be more accurate,
  עברית ( עוד טקסט this part is INSIDE  עוד טקסט ) בחוץ this part is
 outside
  .  בחוץ
  Will be output as
  עברית ) עוד טקסט this part is INSIDE  עוד טקסט ( בחוץ this part is
 outside
  . בחוץ
  It all looks OK when rendering using pdflatex, but using XeTeX, it
 appears
  wrong.
  I couldn't find the part in LyX that handle that part. I will be happy
 for
  directions regarding where to look.

 I don't know a solution for this part. It looks like the two engines do
 not agree on whether ( and ) are opening vs. closing or right vs.
 left parantheses.

 You may try to create a minimal *.tex exampe file that works with XeTeX
 and import this to LyX or try to recreate the correct syntax in LyX
 (comparing the ViewSource output with the correct XeTeX source).

 Günter





brase_test_lyx_git.lyx
Description: Binary data


brase_test_lyx_git.pdf
Description: Adobe PDF document


brase_test_lyx_git.tex
Description: TeX document

Re: LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

OK. I fixed it.

(All the functions mentioned below are from Paragraph.cpp)

It seems like there is a proper function to do it, getUChar, and I just had
to call it from the proper place.

I called it from latexSpecialChar, and it works, but in order to do so, I
hat to pass BufferParams to latexSpecialChar, which is ugly.

Diff file and examples can be found here:
http://www.technion.ac.il/~ronen/temp/bidi_Tex/

The patch is very specific and very ugly. How should I improve it in order
to be able to merge it into LyX's upstream?

Thanks,
Ronen.

On Mon, Jul 16, 2012 at 5:22 PM, Ronen Abravanel ron...@gmail.com wrote:

 These files produced directly by the GIT version of LyX.
 As you can see, the braces are the inverted in both the PDF and the TeX
 files.

 Ronen.


 On Fri, Jul 13, 2012 at 9:38 PM, Ronen Abravanel ron...@gmail.com wrote:

 1. you are right. one can do that, and it would be a nice workaround. But
 I prefer lyx will  produce clean TeX file.
 2. Attached some examples:
 the text in the *xetex and *pdf files are identical. in the pdf, you can
 see that the braces are rendered backword, and also if you will open the
 .tex file in unicode-enables editor.


 note: I cheated a little. In my work-computer I have lyx 2.1 development
 version, and the xetex file compiled straight forward. In my lyx 2.03 in my
 laptop, I had to move one line in the preamble.


 Ronen

 On Fri, Jul 13, 2012 at 11:00 AM, Guenter Milde mi...@users.sf.netwrote:

 On 2012-07-12, Ronen Abravanel wrote:

  as the Hebrew support of LaTeX is not developed for the last several
  years, I decided to try and export Hebrew document to PDF using XeTeX,

 Are there problems that did not get solved for years, or is there no
 development because it just works?

  where the grate Bidi packge by Vafa Khalighi is under active
  development, and merged in polyglossia.

  LyX 2.0 support XeTeX support, but there are some slight problem:

  1. when exporting to regular latex, one should wrap english text
  (like
  numbers, math, etc..)  inside Hebrew parts by \L{.,, }.

 Do you do this with raw LaTeX (ERT) or is there an inset for the task
 (should be easy to write one if its not already there).

  not true in XeTeX. Attached an ugly patch that removes such \L, but:
  a. it's pretty ugly. I'm sure there is better way to do it. I will be
 happy
  for suggestions about ways to improve it.

 For documents that shall work in both, pdflatex and xelatex, it might be
 best to have a dummy definition like

   \ifxetex
  \providecommand*{\L}[1]{#1}
   \fi

 either in the documents LaTeX preamble or in the module defining the text
 inset).

 ...

  2. LyX making some problems with the braces { } ( ) etc in
 Right-to-left
  parts:
  When one writes Right-to-left text that should look like
  (1) text ( inside braces ) more text
  it outputs as
  (2) text ) inside braces ( more text
  or, to be more accurate,
  עברית ( עוד טקסט this part is INSIDE  עוד טקסט ) בחוץ this part is
 outside
  .  בחוץ
  Will be output as
  עברית ) עוד טקסט this part is INSIDE  עוד טקסט ( בחוץ this part is
 outside
  . בחוץ
  It all looks OK when rendering using pdflatex, but using XeTeX, it
 appears
  wrong.
  I couldn't find the part in LyX that handle that part. I will be happy
 for
  directions regarding where to look.

 I don't know a solution for this part. It looks like the two engines do
 not agree on whether ( and ) are opening vs. closing or right vs.
 left parantheses.

 You may try to create a minimal *.tex exampe file that works with XeTeX
 and import this to LyX or try to recreate the correct syntax in LyX
 (comparing the ViewSource output with the correct XeTeX source).

 Günter

Re: LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

These files produced directly by the GIT version of LyX.
As you can see, the braces are the inverted in both the PDF and the TeX
files.

Ronen.


On Fri, Jul 13, 2012 at 9:38 PM, Ronen Abravanel <ron...@gmail.com> wrote:

> 1. you are right. one can do that, and it would be a nice workaround. But
> I prefer lyx will  produce clean TeX file.
> 2. Attached some examples:
> the text in the *xetex and *pdf files are identical. in the pdf, you can
> see that the braces are rendered backword, and also if you will open the
> .tex file in unicode-enables editor.
>
>
> note: I cheated a little. In my work-computer I have lyx 2.1 development
> version, and the xetex file compiled straight forward. In my lyx 2.03 in my
> laptop, I had to move one line in the preamble.
>
>
> Ronen
>
> On Fri, Jul 13, 2012 at 11:00 AM, Guenter Milde <mi...@users.sf.net>wrote:
>
>> On 2012-07-12, Ronen Abravanel wrote:
>>
>> > as the Hebrew support of LaTeX is not developed for the last several
>> > years, I decided to try and export Hebrew document to PDF using XeTeX,
>>
>> Are there problems that did not get solved for years, or is there no
>> development because it "just works"?
>>
>> > where the grate Bidi packge by Vafa Khalighi is under active
>> > development, and merged in polyglossia.
>>
>> > LyX 2.0 support XeTeX support, but there are some slight problem:
>>
>> > 1. when exporting to regular latex, one should wrap "english" text
>>  (like
>> > numbers, math, etc..)  inside Hebrew parts by \L{.,, }.
>>
>> Do you do this with raw LaTeX (ERT) or is there an inset for the task
>> (should be easy to write one if its not already there).
>>
>> > not true in XeTeX. Attached an ugly patch that removes such \L, but:
>> > a. it's pretty ugly. I'm sure there is better way to do it. I will be
>> happy
>> > for suggestions about ways to improve it.
>>
>> For documents that shall work in both, pdflatex and xelatex, it might be
>> best to have a dummy definition like
>>
>>   \ifxetex
>>  \providecommand*{\L}[1]{#1}
>>   \fi
>>
>> either in the documents LaTeX preamble or in the module defining the text
>> inset).
>>
>> ...
>>
>> > 2. LyX making some problems with the braces { } ( ) etc in Right-to-left
>> > parts:
>> > When one writes Right-to-left text that should look like
>> > (1) text ( inside braces ) more text
>> > it outputs as
>> > (2) text ) inside braces ( more text
>> > or, to be more accurate,
>> > עברית ( עוד טקסט this part is INSIDE  עוד טקסט ) בחוץ this part is
>> outside
>> > .  בחוץ
>> > Will be output as
>> > עברית ) עוד טקסט this part is INSIDE  עוד טקסט ( בחוץ this part is
>> outside
>> > . בחוץ
>> > It all looks OK when rendering using pdflatex, but using XeTeX, it
>> appears
>> > wrong.
>> > I couldn't find the part in LyX that handle that part. I will be happy
>> for
>> > directions regarding where to look.
>>
>> I don't know a solution for this part. It looks like the two engines do
>> not agree on whether ( and ) are "opening" vs. "closing" or "right" vs.
>> "left" parantheses.
>>
>> You may try to create a minimal *.tex exampe file that works with XeTeX
>> and import this to LyX or try to recreate the correct syntax in LyX
>> (comparing the View>Source output with the correct XeTeX source).
>>
>> Günter
>>
>>
>


brase_test_lyx_git.lyx
Description: Binary data


brase_test_lyx_git.pdf
Description: Adobe PDF document


brase_test_lyx_git.tex
Description: TeX document

Re: LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

OK. I fixed it.

(All the functions mentioned below are from Paragraph.cpp)

It seems like there is a proper function to do it, getUChar, and I just had
to call it from the proper place.

I called it from latexSpecialChar, and it works, but in order to do so, I
hat to pass BufferParams to latexSpecialChar, which is ugly.

Diff file and examples can be found here:
http://www.technion.ac.il/~ronen/temp/bidi_Tex/

The patch is very specific and very ugly. How should I improve it in order
to be able to merge it into LyX's upstream?

Thanks,
Ronen.

On Mon, Jul 16, 2012 at 5:22 PM, Ronen Abravanel <ron...@gmail.com> wrote:

> These files produced directly by the GIT version of LyX.
> As you can see, the braces are the inverted in both the PDF and the TeX
> files.
>
> Ronen.
>
>
> On Fri, Jul 13, 2012 at 9:38 PM, Ronen Abravanel <ron...@gmail.com> wrote:
>
>> 1. you are right. one can do that, and it would be a nice workaround. But
>> I prefer lyx will  produce clean TeX file.
>> 2. Attached some examples:
>> the text in the *xetex and *pdf files are identical. in the pdf, you can
>> see that the braces are rendered backword, and also if you will open the
>> .tex file in unicode-enables editor.
>>
>>
>> note: I cheated a little. In my work-computer I have lyx 2.1 development
>> version, and the xetex file compiled straight forward. In my lyx 2.03 in my
>> laptop, I had to move one line in the preamble.
>>
>>
>> Ronen
>>
>> On Fri, Jul 13, 2012 at 11:00 AM, Guenter Milde <mi...@users.sf.net>wrote:
>>
>>> On 2012-07-12, Ronen Abravanel wrote:
>>>
>>> > as the Hebrew support of LaTeX is not developed for the last several
>>> > years, I decided to try and export Hebrew document to PDF using XeTeX,
>>>
>>> Are there problems that did not get solved for years, or is there no
>>> development because it "just works"?
>>>
>>> > where the grate Bidi packge by Vafa Khalighi is under active
>>> > development, and merged in polyglossia.
>>>
>>> > LyX 2.0 support XeTeX support, but there are some slight problem:
>>>
>>> > 1. when exporting to regular latex, one should wrap "english" text
>>>  (like
>>> > numbers, math, etc..)  inside Hebrew parts by \L{.,, }.
>>>
>>> Do you do this with raw LaTeX (ERT) or is there an inset for the task
>>> (should be easy to write one if its not already there).
>>>
>>> > not true in XeTeX. Attached an ugly patch that removes such \L, but:
>>> > a. it's pretty ugly. I'm sure there is better way to do it. I will be
>>> happy
>>> > for suggestions about ways to improve it.
>>>
>>> For documents that shall work in both, pdflatex and xelatex, it might be
>>> best to have a dummy definition like
>>>
>>>   \ifxetex
>>>  \providecommand*{\L}[1]{#1}
>>>   \fi
>>>
>>> either in the documents LaTeX preamble or in the module defining the text
>>> inset).
>>>
>>> ...
>>>
>>> > 2. LyX making some problems with the braces { } ( ) etc in
>>> Right-to-left
>>> > parts:
>>> > When one writes Right-to-left text that should look like
>>> > (1) text ( inside braces ) more text
>>> > it outputs as
>>> > (2) text ) inside braces ( more text
>>> > or, to be more accurate,
>>> > עברית ( עוד טקסט this part is INSIDE  עוד טקסט ) בחוץ this part is
>>> outside
>>> > .  בחוץ
>>> > Will be output as
>>> > עברית ) עוד טקסט this part is INSIDE  עוד טקסט ( בחוץ this part is
>>> outside
>>> > . בחוץ
>>> > It all looks OK when rendering using pdflatex, but using XeTeX, it
>>> appears
>>> > wrong.
>>> > I couldn't find the part in LyX that handle that part. I will be happy
>>> for
>>> > directions regarding where to look.
>>>
>>> I don't know a solution for this part. It looks like the two engines do
>>> not agree on whether ( and ) are "opening" vs. "closing" or "right" vs.
>>> "left" parantheses.
>>>
>>> You may try to create a minimal *.tex exampe file that works with XeTeX
>>> and import this to LyX or try to recreate the correct syntax in LyX
>>> (comparing the View>Source output with the correct XeTeX source).
>>>
>>> Günter
>>>
>>>
>>
>

Re: LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

1. you are right. one can do that, and it would be a nice workaround. But I
prefer lyx will  produce clean TeX file.
2. Attached some examples:
the text in the *xetex and *pdf files are identical. in the pdf, you can
see that the braces are rendered backword, and also if you will open the
.tex file in unicode-enables editor.


note: I cheated a little. In my work-computer I have lyx 2.1 development
version, and the xetex file compiled straight forward. In my lyx 2.03 in my
laptop, I had to move one line in the preamble.


Ronen

On Fri, Jul 13, 2012 at 11:00 AM, Guenter Milde mi...@users.sf.net wrote:

 On 2012-07-12, Ronen Abravanel wrote:

  as the Hebrew support of LaTeX is not developed for the last several
  years, I decided to try and export Hebrew document to PDF using XeTeX,

 Are there problems that did not get solved for years, or is there no
 development because it just works?

  where the grate Bidi packge by Vafa Khalighi is under active
  development, and merged in polyglossia.

  LyX 2.0 support XeTeX support, but there are some slight problem:

  1. when exporting to regular latex, one should wrap english text  (like
  numbers, math, etc..)  inside Hebrew parts by \L{.,, }.

 Do you do this with raw LaTeX (ERT) or is there an inset for the task
 (should be easy to write one if its not already there).

  not true in XeTeX. Attached an ugly patch that removes such \L, but:
  a. it's pretty ugly. I'm sure there is better way to do it. I will be
 happy
  for suggestions about ways to improve it.

 For documents that shall work in both, pdflatex and xelatex, it might be
 best to have a dummy definition like

   \ifxetex
  \providecommand*{\L}[1]{#1}
   \fi

 either in the documents LaTeX preamble or in the module defining the text
 inset).

 ...

  2. LyX making some problems with the braces { } ( ) etc in Right-to-left
  parts:
  When one writes Right-to-left text that should look like
  (1) text ( inside braces ) more text
  it outputs as
  (2) text ) inside braces ( more text
  or, to be more accurate,
  עברית ( עוד טקסט this part is INSIDE  עוד טקסט ) בחוץ this part is
 outside
  .  בחוץ
  Will be output as
  עברית ) עוד טקסט this part is INSIDE  עוד טקסט ( בחוץ this part is
 outside
  . בחוץ
  It all looks OK when rendering using pdflatex, but using XeTeX, it
 appears
  wrong.
  I couldn't find the part in LyX that handle that part. I will be happy
 for
  directions regarding where to look.

 I don't know a solution for this part. It looks like the two engines do
 not agree on whether ( and ) are opening vs. closing or right vs.
 left parantheses.

 You may try to create a minimal *.tex exampe file that works with XeTeX
 and import this to LyX or try to recreate the correct syntax in LyX
 (comparing the ViewSource output with the correct XeTeX source).

 Günter




brace_example_pdflatex.lyx
Description: Binary data


brace_example_pdflatex.pdf
Description: Adobe PDF document


brace_example_xetex.lyx
Description: Binary data


brace_example_xetex.pdf
Description: Adobe PDF document


brace_example_xetex.tex
Description: TeX document


brace_example_pdflatex.tex
Description: TeX document

Re: LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

1. you are right. one can do that, and it would be a nice workaround. But I
prefer lyx will  produce clean TeX file.
2. Attached some examples:
the text in the *xetex and *pdf files are identical. in the pdf, you can
see that the braces are rendered backword, and also if you will open the
.tex file in unicode-enables editor.


note: I cheated a little. In my work-computer I have lyx 2.1 development
version, and the xetex file compiled straight forward. In my lyx 2.03 in my
laptop, I had to move one line in the preamble.


Ronen

On Fri, Jul 13, 2012 at 11:00 AM, Guenter Milde <mi...@users.sf.net> wrote:

> On 2012-07-12, Ronen Abravanel wrote:
>
> > as the Hebrew support of LaTeX is not developed for the last several
> > years, I decided to try and export Hebrew document to PDF using XeTeX,
>
> Are there problems that did not get solved for years, or is there no
> development because it "just works"?
>
> > where the grate Bidi packge by Vafa Khalighi is under active
> > development, and merged in polyglossia.
>
> > LyX 2.0 support XeTeX support, but there are some slight problem:
>
> > 1. when exporting to regular latex, one should wrap "english" text  (like
> > numbers, math, etc..)  inside Hebrew parts by \L{.,, }.
>
> Do you do this with raw LaTeX (ERT) or is there an inset for the task
> (should be easy to write one if its not already there).
>
> > not true in XeTeX. Attached an ugly patch that removes such \L, but:
> > a. it's pretty ugly. I'm sure there is better way to do it. I will be
> happy
> > for suggestions about ways to improve it.
>
> For documents that shall work in both, pdflatex and xelatex, it might be
> best to have a dummy definition like
>
>   \ifxetex
>  \providecommand*{\L}[1]{#1}
>   \fi
>
> either in the documents LaTeX preamble or in the module defining the text
> inset).
>
> ...
>
> > 2. LyX making some problems with the braces { } ( ) etc in Right-to-left
> > parts:
> > When one writes Right-to-left text that should look like
> > (1) text ( inside braces ) more text
> > it outputs as
> > (2) text ) inside braces ( more text
> > or, to be more accurate,
> > עברית ( עוד טקסט this part is INSIDE  עוד טקסט ) בחוץ this part is
> outside
> > .  בחוץ
> > Will be output as
> > עברית ) עוד טקסט this part is INSIDE  עוד טקסט ( בחוץ this part is
> outside
> > . בחוץ
> > It all looks OK when rendering using pdflatex, but using XeTeX, it
> appears
> > wrong.
> > I couldn't find the part in LyX that handle that part. I will be happy
> for
> > directions regarding where to look.
>
> I don't know a solution for this part. It looks like the two engines do
> not agree on whether ( and ) are "opening" vs. "closing" or "right" vs.
> "left" parantheses.
>
> You may try to create a minimal *.tex exampe file that works with XeTeX
> and import this to LyX or try to recreate the correct syntax in LyX
> (comparing the View>Source output with the correct XeTeX source).
>
> Günter
>
>


brace_example_pdflatex.lyx
Description: Binary data


brace_example_pdflatex.pdf
Description: Adobe PDF document


brace_example_xetex.lyx
Description: Binary data


brace_example_xetex.pdf
Description: Adobe PDF document


brace_example_xetex.tex
Description: TeX document


brace_example_pdflatex.tex
Description: TeX document

LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

Hello to you all,

as the Hebrew support of LaTeX is not developed for the last several years,
I decided to try and export Hebrew document to PDF using XeTeX, where the
grate Bidi packge by Vafa Khalighi is under active development, and merged
in polyglossia.

LyX 2.0 support XeTeX support, but there are some slight problem:

1. when exporting to regular latex, one should wrap englishtext  (like
numbers, math, etc..)  inside Hebrew parts by \L{.,, }. In XeTeX, it dose
not true in XeTeX. Attached an ugly patch that removes such \L, but:
a. it's pretty ugly. I'm sure there is better way to do it. I will be happy
for suggestions about ways to improve it.
b. Just above the hebrew treatment there is Farsi treatment. I think it
should be the same in Farsi but I don't sure. anyone knows?


2. LyX making some problems with the braces { } ( ) etc in Right-to-left
parts:
When one writes Right-to-left text that should look like
(1) text ( inside braces ) more text
it outputs as
(2) text ) inside braces ( more text
or, to be more accurate,
עברית ( עוד טקסט this part is INSIDE  עוד טקסט ) בחוץ this part is outside
.  בחוץ
Will be output as
עברית ) עוד טקסט this part is INSIDE  עוד טקסט ( בחוץ this part is outside
. בחוץ
It all looks OK when rendering using pdflatex, but using XeTeX, it appears
wrong.
I couldn't find the part in LyX that handle that part. I will be happy for
directions regarding where to look.

Thanks,
Ronen Abravanel


remove_L.diff
Description: Binary data

LyX, XeTeX, bidi and Hebrew

[Ronen Abravanel]

Hello to you all,

as the Hebrew support of LaTeX is not developed for the last several years,
I decided to try and export Hebrew document to PDF using XeTeX, where the
grate Bidi packge by Vafa Khalighi is under active development, and merged
in polyglossia.

LyX 2.0 support XeTeX support, but there are some slight problem:

1. when exporting to regular latex, one should wrap "english"text  (like
numbers, math, etc..)  inside Hebrew parts by \L{.,, }. In XeTeX, it dose
not true in XeTeX. Attached an ugly patch that removes such \L, but:
a. it's pretty ugly. I'm sure there is better way to do it. I will be happy
for suggestions about ways to improve it.
b. Just above the hebrew treatment there is Farsi treatment. I think it
should be the same in Farsi but I don't sure. anyone knows?


2. LyX making some problems with the braces { } ( ) etc in Right-to-left
parts:
When one writes Right-to-left text that should look like
(1) text ( inside braces ) more text
it outputs as
(2) text ) inside braces ( more text
or, to be more accurate,
עברית ( עוד טקסט this part is INSIDE  עוד טקסט ) בחוץ this part is outside
.  בחוץ
Will be output as
עברית ) עוד טקסט this part is INSIDE  עוד טקסט ( בחוץ this part is outside
. בחוץ
It all looks OK when rendering using pdflatex, but using XeTeX, it appears
wrong.
I couldn't find the part in LyX that handle that part. I will be happy for
directions regarding where to look.

Thanks,
Ronen Abravanel


remove_L.diff
Description: Binary data

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

BTW, can I get privileges to open track-tickets?

(username: ronen)

On Sat, May 26, 2012 at 5:24 PM, Ronen Abravanel ron...@gmail.com wrote:

 Patch for LyXAction.cpp attached. (i also added example for inserting
 graphics using inset-inset


 On Fri, May 25, 2012 at 3:42 PM, Jean-Marc Lasgouttes 
 lasgout...@lyx.orgwrote:

 Le 25/05/2012 13:21, Ronen Abravanel a écrit :

  I added an optional set argument to LFUN_LANGUAGE and fixed the menu
 entery.

 Anythhing else? Should I fix the LFUN documentation?


 Good. I would handle the case where no language is given to reset to
 default language (this is what is done with the layout lfun). This allows
 to to have a keybinding for resetting the langage.

 Yes, in LyXAction.cpp

 JMarc

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

BTW, can I get privileges to open track-tickets?

(username: ronen)

On Sat, May 26, 2012 at 5:24 PM, Ronen Abravanel <ron...@gmail.com> wrote:

> Patch for LyXAction.cpp attached. (i also added example for inserting
> graphics using inset-inset
>
>
> On Fri, May 25, 2012 at 3:42 PM, Jean-Marc Lasgouttes 
> <lasgout...@lyx.org>wrote:
>
>> Le 25/05/2012 13:21, Ronen Abravanel a écrit :
>>
>>  I added an optional "set" argument to LFUN_LANGUAGE and fixed the menu
>>> entery.
>>>
>>> Anythhing else? Should I fix the LFUN documentation?
>>>
>>
>> Good. I would handle the case where no language is given to reset to
>> default language (this is what is done with the "layout" lfun). This allows
>> to to have a keybinding for resetting the langage.
>>
>> Yes, in LyXAction.cpp
>>
>> JMarc
>>
>>
>

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

Patch for LyXAction.cpp attached. (i also added example for inserting
graphics using inset-inset

On Fri, May 25, 2012 at 3:42 PM, Jean-Marc Lasgouttes lasgout...@lyx.orgwrote:

 Le 25/05/2012 13:21, Ronen Abravanel a écrit :

  I added an optional set argument to LFUN_LANGUAGE and fixed the menu
 entery.

 Anythhing else? Should I fix the LFUN documentation?


 Good. I would handle the case where no language is given to reset to
 default language (this is what is done with the layout lfun). This allows
 to to have a keybinding for resetting the langage.

 Yes, in LyXAction.cpp

 JMarc




language_toggle_LyXAction_cpp.patch
Description: Binary data

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

Patch for LyXAction.cpp attached. (i also added example for inserting
graphics using inset-inset

On Fri, May 25, 2012 at 3:42 PM, Jean-Marc Lasgouttes <lasgout...@lyx.org>wrote:

> Le 25/05/2012 13:21, Ronen Abravanel a écrit :
>
>  I added an optional "set" argument to LFUN_LANGUAGE and fixed the menu
>> entery.
>>
>> Anythhing else? Should I fix the LFUN documentation?
>>
>
> Good. I would handle the case where no language is given to reset to
> default language (this is what is done with the "layout" lfun). This allows
> to to have a keybinding for resetting the langage.
>
> Yes, in LyXAction.cpp
>
> JMarc
>
>


language_toggle_LyXAction_cpp.patch
Description: Binary data

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

I added an optional set argument to LFUN_LANGUAGE and fixed the menu
entery.

Anythhing else? Should I fix the LFUN documentation?

On Wed, May 23, 2012 at 11:37 PM, Stephan Witt st.w...@gmx.net wrote:

 Currently I'm really short on time.

 I'd vote for keeping the traditional behavior and add the optional
 argument set for internal API use.
 This has to be used by the context menu code.

 Stephan

 Am 23.05.2012 um 20:59 schrieb Ronen Abravanel:

  So, which one of the suggestions should I implement?
 
  On Mon, May 7, 2012 at 1:39 PM, Ronen Abravanel ron...@gmail.com
 wrote:
  If there are only few such commands, the 1st options seems best.
  If there are many, the last..
 
  Ronen
 
 
  On Wed, May 2, 2012 at 11:58 AM, Jean-Marc Lasgouttes 
 lasgout...@lyx.org wrote:
  Le 29/04/2012 14:13, Vincent van Ravesteijn a écrit :
 
  I think it is a bug. I would vote for disabling the LFUN when the
  languages are the same. This will make it possible for the reporter to
  define: command-alternatives language hebrew; language english to
 toggle.
 
  I especially object to introduce a difference in behaviour based on the
  fact whether there is a selection or not. I would not expect something
  different to happen.
 
  I think these lfuns have two faces: interactive and API.
  * as an API, I would expect to be able to set language to french and
 not care about what the language was before that
  * as an interactive function, toggling between the given value and the
 default is very desirable and fits what is done by other font-changing
 functions.
 
  We probably need to offer the two possibilities, either by
  * two sets of lfuns language/language-set, font-emph/font-emph-set
  * an optional argument set
  * a prefix command notoggle (notoggle language french)
 
  Of course, a way that preserves the preexisting semantics of lfuns would
 be best.
 
  Similarly, having the possibility to have layout toggle between the
 given layout and standard layout could be useful for toolbars.
 
  JMarc
 
 




language_toggle_set.patch
Description: Binary data

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

I added an optional "set" argument to LFUN_LANGUAGE and fixed the menu
entery.

Anythhing else? Should I fix the LFUN documentation?

On Wed, May 23, 2012 at 11:37 PM, Stephan Witt <st.w...@gmx.net> wrote:

> Currently I'm really short on time.
>
> I'd vote for keeping the "traditional" behavior and add the optional
> argument "set" for internal API use.
> This has to be used by the context menu code.
>
> Stephan
>
> Am 23.05.2012 um 20:59 schrieb Ronen Abravanel:
>
> > So, which one of the suggestions should I implement?
> >
> > On Mon, May 7, 2012 at 1:39 PM, Ronen Abravanel <ron...@gmail.com>
> wrote:
> > If there are only few such commands, the 1st options seems best.
> > If there are many, the last..
> >
> > Ronen
> >
> >
> > On Wed, May 2, 2012 at 11:58 AM, Jean-Marc Lasgouttes <
> lasgout...@lyx.org> wrote:
> > Le 29/04/2012 14:13, Vincent van Ravesteijn a écrit :
> >
> > I think it is a bug. I would vote for disabling the LFUN when the
> > languages are the same. This will make it possible for the reporter to
> > define: "command-alternatives language hebrew; language english" to
> toggle.
> >
> > I especially object to introduce a difference in behaviour based on the
> > fact whether there is a selection or not. I would not expect something
> > different to happen.
> >
> > I think these lfuns have two faces: interactive and API.
> > * as an API, I would expect to be able to set language to "french" and
> not care about what the language was before that
> > * as an interactive function, toggling between the given value and the
> default is very desirable and fits what is done by other font-changing
> functions.
> >
> > We probably need to offer the two possibilities, either by
> > * two sets of lfuns language/language-set, font-emph/font-emph-set
> > * an optional argument "set"
> > * a prefix command "notoggle" ("notoggle language french")
> >
> > Of course, a way that preserves the preexisting semantics of lfuns would
> be best.
> >
> > Similarly, having the possibility to have "layout" toggle between the
> given layout and standard layout could be useful for toolbars.
> >
> > JMarc
> >
> >
>
>


language_toggle_set.patch
Description: Binary data

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

So, which one of the suggestions should I implement?

On Mon, May 7, 2012 at 1:39 PM, Ronen Abravanel ron...@gmail.com wrote:

 If there are only few such commands, the 1st options seems best.
 If there are many, the last..

 Ronen


 On Wed, May 2, 2012 at 11:58 AM, Jean-Marc Lasgouttes 
 lasgout...@lyx.orgwrote:

 Le 29/04/2012 14:13, Vincent van Ravesteijn a écrit :

  I think it is a bug. I would vote for disabling the LFUN when the
 languages are the same. This will make it possible for the reporter to
 define: command-alternatives language hebrew; language english to
 toggle.

 I especially object to introduce a difference in behaviour based on the
 fact whether there is a selection or not. I would not expect something
 different to happen.


 I think these lfuns have two faces: interactive and API.
 * as an API, I would expect to be able to set language to french and
 not care about what the language was before that
 * as an interactive function, toggling between the given value and the
 default is very desirable and fits what is done by other font-changing
 functions.

 We probably need to offer the two possibilities, either by
 * two sets of lfuns language/language-set, font-emph/font-emph-set
 * an optional argument set
 * a prefix command notoggle (notoggle language french)

 Of course, a way that preserves the preexisting semantics of lfuns would
 be best.

 Similarly, having the possibility to have layout toggle between the
 given layout and standard layout could be useful for toolbars.

 JMarc

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

So, which one of the suggestions should I implement?

On Mon, May 7, 2012 at 1:39 PM, Ronen Abravanel <ron...@gmail.com> wrote:

> If there are only few such commands, the 1st options seems best.
> If there are many, the last..
>
> Ronen
>
>
> On Wed, May 2, 2012 at 11:58 AM, Jean-Marc Lasgouttes 
> <lasgout...@lyx.org>wrote:
>
>> Le 29/04/2012 14:13, Vincent van Ravesteijn a écrit :
>>
>>  I think it is a bug. I would vote for disabling the LFUN when the
>>> languages are the same. This will make it possible for the reporter to
>>> define: "command-alternatives language hebrew; language english" to
>>> toggle.
>>>
>>> I especially object to introduce a difference in behaviour based on the
>>> fact whether there is a selection or not. I would not expect something
>>> different to happen.
>>>
>>
>> I think these lfuns have two faces: interactive and API.
>> * as an API, I would expect to be able to set language to "french" and
>> not care about what the language was before that
>> * as an interactive function, toggling between the given value and the
>> default is very desirable and fits what is done by other font-changing
>> functions.
>>
>> We probably need to offer the two possibilities, either by
>> * two sets of lfuns language/language-set, font-emph/font-emph-set
>> * an optional argument "set"
>> * a prefix command "notoggle" ("notoggle language french")
>>
>> Of course, a way that preserves the preexisting semantics of lfuns would
>> be best.
>>
>> Similarly, having the possibility to have "layout" toggle between the
>> given layout and standard layout could be useful for toolbars.
>>
>> JMarc
>>
>
>

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

If there are only few such commands, the 1st options seems best.
If there are many, the last..

Ronen

On Wed, May 2, 2012 at 11:58 AM, Jean-Marc Lasgouttes lasgout...@lyx.orgwrote:

 Le 29/04/2012 14:13, Vincent van Ravesteijn a écrit :

  I think it is a bug. I would vote for disabling the LFUN when the
 languages are the same. This will make it possible for the reporter to
 define: command-alternatives language hebrew; language english to
 toggle.

 I especially object to introduce a difference in behaviour based on the
 fact whether there is a selection or not. I would not expect something
 different to happen.


 I think these lfuns have two faces: interactive and API.
 * as an API, I would expect to be able to set language to french and not
 care about what the language was before that
 * as an interactive function, toggling between the given value and the
 default is very desirable and fits what is done by other font-changing
 functions.

 We probably need to offer the two possibilities, either by
 * two sets of lfuns language/language-set, font-emph/font-emph-set
 * an optional argument set
 * a prefix command notoggle (notoggle language french)

 Of course, a way that preserves the preexisting semantics of lfuns would
 be best.

 Similarly, having the possibility to have layout toggle between the
 given layout and standard layout could be useful for toolbars.

 JMarc

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

If there are only few such commands, the 1st options seems best.
If there are many, the last..

Ronen

On Wed, May 2, 2012 at 11:58 AM, Jean-Marc Lasgouttes wrote:

> Le 29/04/2012 14:13, Vincent van Ravesteijn a écrit :
>
>  I think it is a bug. I would vote for disabling the LFUN when the
>> languages are the same. This will make it possible for the reporter to
>> define: "command-alternatives language hebrew; language english" to
>> toggle.
>>
>> I especially object to introduce a difference in behaviour based on the
>> fact whether there is a selection or not. I would not expect something
>> different to happen.
>>
>
> I think these lfuns have two faces: interactive and API.
> * as an API, I would expect to be able to set language to "french" and not
> care about what the language was before that
> * as an interactive function, toggling between the given value and the
> default is very desirable and fits what is done by other font-changing
> functions.
>
> We probably need to offer the two possibilities, either by
> * two sets of lfuns language/language-set, font-emph/font-emph-set
> * an optional argument "set"
> * a prefix command "notoggle" ("notoggle language french")
>
> Of course, a way that preserves the preexisting semantics of lfuns would
> be best.
>
> Similarly, having the possibility to have "layout" toggle between the
> given layout and standard layout could be useful for toolbars.
>
> JMarc
>

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

Presumably, the orginal  (prior to 2.02) behavior is a bug. But it's very
usable bug. Specifically, all the how to use LyX in Hebrew manuals on the
Internet (and there are many of these) use it, and will have to change.

So, it will make sense to use the toggle-method, but it will annoy many
people.

Ronen.

On Sun, Apr 29, 2012 at 3:13 PM, Vincent van Ravesteijn v...@lyx.org wrote:

 Op 29-4-2012 11:29, Stephan Witt schreef:

  This patch restores the font toggle feature if there is no selection.
 I looked into this and it is that way:

 Given one invokes the LFUN_LANGUAGE with a value different from current
 one at current position.
 Then the language is changed to the new value. If one passes the current
 one the language it is
 set (back) to the document or default language.

 E. g. one has document language english. The first call of language
 hebrew switches to hebrew.
 The next call of language hebrew switches back to english.

 Now I want to ask: is this a bug or a feature? The patch I've posted
 restores the old behavior.
 So it is not bad. But is it good? If nobody objects I'd like to commit
 that thing.


 I think it is a bug. I would vote for disabling the LFUN when the
 languages are the same. This will make it possible for the reporter to
 define: command-alternatives language hebrew; language english to toggle.

 I especially object to introduce a difference in behaviour based on the
 fact whether there is a selection or not. I would not expect something
 different to happen.

 See the attached.

 Vincent

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

This will also require many instructions/ definition change, but it will be
simpler change.

Ronen

On Sun, Apr 29, 2012 at 6:02 PM, Jean-Marc Lasgouttes lasgout...@lyx.orgwrote:

 Le 29/04/12 16:55, Ronen Abravanel a écrit :

  Presumably, the orginal  (prior to 2.02) behavior is a bug. But it's
 very usable bug. Specifically, all the how to use LyX in Hebrew
 manuals on the Internet (and there are many of these) use it, and will
 have to change.

 So, it will make sense to use the toggle-method, but it will annoy many
 people.


 I would propose to introduce a language-toggle lfun to this end, then.

 JMarc

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

Presumably, the "orginal"  (prior to 2.02) behavior is a bug. But it's very
usable bug. Specifically, all the "how to use LyX in Hebrew" manuals on the
Internet (and there are many of these) use it, and will have to change.

So, it will make sense to use the toggle-method, but it will annoy many
people.

Ronen.

On Sun, Apr 29, 2012 at 3:13 PM, Vincent van Ravesteijn  wrote:

> Op 29-4-2012 11:29, Stephan Witt schreef:
>
>  This patch restores the font toggle feature if there is no selection.
>> I looked into this and it is that way:
>>
>> Given one invokes the LFUN_LANGUAGE with a value different from current
>> one at current position.
>> Then the language is changed to the new value. If one passes the current
>> one the language it is
>> set (back) to the document or default language.
>>
>> E. g. one has document language english. The first call of "language
>> hebrew" switches to hebrew.
>> The next call of "language hebrew" switches back to english.
>>
>> Now I want to ask: is this a bug or a feature? The patch I've posted
>> restores the old behavior.
>> So it is not bad. But is it good? If nobody objects I'd like to commit
>> that thing.
>>
>
> I think it is a bug. I would vote for disabling the LFUN when the
> languages are the same. This will make it possible for the reporter to
> define: "command-alternatives language hebrew; language english" to toggle.
>
> I especially object to introduce a difference in behaviour based on the
> fact whether there is a selection or not. I would not expect something
> different to happen.
>
> See the attached.
>
> Vincent
>

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

This will also require many instructions/ definition change, but it will be
simpler change.

Ronen

On Sun, Apr 29, 2012 at 6:02 PM, Jean-Marc Lasgouttes <lasgout...@lyx.org>wrote:

> Le 29/04/12 16:55, Ronen Abravanel a écrit :
>
>  Presumably, the "orginal"  (prior to 2.02) behavior is a bug. But it's
>> very usable bug. Specifically, all the "how to use LyX in Hebrew"
>> manuals on the Internet (and there are many of these) use it, and will
>> have to change.
>>
>> So, it will make sense to use the toggle-method, but it will annoy many
>> people.
>>
>
> I would propose to introduce a language-toggle lfun to this end, then.
>
> JMarc
>
>

annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

Good morning,

I'm using LyX for quite a while for writing bi-lingual documents, in both
Hebrew and English. In order to write such documents, I define one language
in documents-settings, and then, created a key-binding to language
hebrew [or, language english], and then invoke the shortcut in order to
toggle between the two language.

Since LyX 2.02, that was change: invoking language language-name dose
not toggle between languages, but switch into the specified language. The
change made the the usage of LyX for writing bi-lingual documents very
tiresome.


The code change is very simple:

int
src/Text3.cpp, Line 1924 (SVN version)
toggleAndShow(cur, this, font, false);


should be change to

toggleAndShow(cur, this, font, true); //true is the default
argument, so it can as well be left blank


The change was mad in:
http://www.lyx.org/trac/changeset/39735/lyxsvn/lyx-devel/trunk/src/Text3.cpp



But it it so simple, I can only assume that this behavior was deliberated.
If so, please, reconsider.


Thanks,
Ronen Abravanel

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

It seems the change was done in order to fix:

http://www.lyx.org/trac/ticket/7778

possible solution which will enbale to toggle languages and keep the bug
fixed:


If we can disable switching into corrent language, we can use
LFUN_COMMAND_ALTERNATIVES. Somthing like

command-alternatives language hebrew; language english

Which will switch the the other language.

(if I understood correctly the manual, I assume one can check waht is the
current language and then if (*lang == *cur_lang)  {enable  = false;
break;} will do the work)


On Fri, Apr 27, 2012 at 5:49 PM, Ronen Abravanel ron...@gmail.com wrote:

 Good morning,

 I'm using LyX for quite a while for writing bi-lingual documents, in both
 Hebrew and English. In order to write such documents, I define one language
 in documents-settings, and then, created a key-binding to language
 hebrew [or, language english], and then invoke the shortcut in order to
 toggle between the two language.

 Since LyX 2.02, that was change: invoking language language-name dose
 not toggle between languages, but switch into the specified language. The
 change made the the usage of LyX for writing bi-lingual documents very
 tiresome.


 The code change is very simple:

 int
 src/Text3.cpp, Line 1924 (SVN version)
 toggleAndShow(cur, this, font, false);


 should be change to

 toggleAndShow(cur, this, font, true); //true is the default
 argument, so it can as well be left blank


 The change was mad in:

 http://www.lyx.org/trac/changeset/39735/lyxsvn/lyx-devel/trunk/src/Text3.cpp



 But it it so simple, I can only assume that this behavior was deliberated.
 If so, please, reconsider.


 Thanks,
 Ronen Abravanel

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

And a patch that perform my suggestion is attachted.

Ronen Abravanel



On Fri, Apr 27, 2012 at 6:04 PM, Ronen Abravanel ron...@gmail.com wrote:

 It seems the change was done in order to fix:

 http://www.lyx.org/trac/ticket/7778

 possible solution which will enbale to toggle languages and keep the bug
 fixed:


 If we can disable switching into corrent language, we can use
 LFUN_COMMAND_ALTERNATIVES. Somthing like

 command-alternatives language hebrew; language english

 Which will switch the the other language.

 (if I understood correctly the manual, I assume one can check waht is the
 current language and then if (*lang == *cur_lang)  {enable  = false;
 break;} will do the work)



 On Fri, Apr 27, 2012 at 5:49 PM, Ronen Abravanel ron...@gmail.com wrote:

 Good morning,

 I'm using LyX for quite a while for writing bi-lingual documents, in both
 Hebrew and English. In order to write such documents, I define one language
 in documents-settings, and then, created a key-binding to language
 hebrew [or, language english], and then invoke the shortcut in order to
 toggle between the two language.

 Since LyX 2.02, that was change: invoking language language-name dose
 not toggle between languages, but switch into the specified language. The
 change made the the usage of LyX for writing bi-lingual documents very
 tiresome.


 The code change is very simple:

 int
 src/Text3.cpp, Line 1924 (SVN version)
 toggleAndShow(cur, this, font, false);


 should be change to

 toggleAndShow(cur, this, font, true); //true is the default
 argument, so it can as well be left blank


 The change was mad in:

 http://www.lyx.org/trac/changeset/39735/lyxsvn/lyx-devel/trunk/src/Text3.cpp



 But it it so simple, I can only assume that this behavior was
 deliberated. If so, please, reconsider.


 Thanks,
 Ronen Abravanel





language_toggle.diff
Description: Binary data

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

Even better!

On Fri, Apr 27, 2012 at 8:10 PM, Stephan Witt st.w...@gmx.net wrote:

 Am 27.04.2012 um 17:33 schrieb Ronen Abravanel:

  And a patch that perform my suggestion is attachted.
 
  Ronen Abravanel
 
 
 
  On Fri, Apr 27, 2012 at 6:04 PM, Ronen Abravanel ron...@gmail.com
 wrote:
  It seems the change was done in order to fix:
 
  http://www.lyx.org/trac/ticket/7778

 Yes. That's correct.

 Wouldn't it be easier for you to make it more smart with respect to the
 current selection?
 Like the attached patch?

 Stephan

annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

Good morning,

I'm using LyX for quite a while for writing bi-lingual documents, in both
Hebrew and English. In order to write such documents, I define one language
in documents->settings, and then, created a key-binding to "language
hebrew" [or, "language english"], and then invoke the shortcut in order to
toggle between the two language.

Since LyX 2.02, that was change: invoking "language " dose
not toggle between languages, but switch into the specified language. The
change made the the usage of LyX for writing bi-lingual documents very
tiresome.


The code change is very simple:

int
src/Text3.cpp, Line 1924 (SVN version)
toggleAndShow(cur, this, font, false);


should be change to

toggleAndShow(cur, this, font, true); //true is the default
argument, so it can as well be left blank


The change was mad in:
http://www.lyx.org/trac/changeset/39735/lyxsvn/lyx-devel/trunk/src/Text3.cpp



But it it so simple, I can only assume that this behavior was deliberated.
If so, please, reconsider.


Thanks,
Ronen Abravanel

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

It seems the change was done in order to fix:

http://www.lyx.org/trac/ticket/7778

possible solution which will enbale to toggle languages and keep the bug
fixed:


If we can disable switching into corrent language, we can use
LFUN_COMMAND_ALTERNATIVES. Somthing like

command-alternatives language hebrew; language english

Which will switch the the "other" language.

(if I understood correctly the manual, I assume one can check waht is the
current language and then "if (*lang == *cur_lang)  {enable  = false;
break;}   "  will do the work)


On Fri, Apr 27, 2012 at 5:49 PM, Ronen Abravanel <ron...@gmail.com> wrote:

> Good morning,
>
> I'm using LyX for quite a while for writing bi-lingual documents, in both
> Hebrew and English. In order to write such documents, I define one language
> in documents->settings, and then, created a key-binding to "language
> hebrew" [or, "language english"], and then invoke the shortcut in order to
> toggle between the two language.
>
> Since LyX 2.02, that was change: invoking "language " dose
> not toggle between languages, but switch into the specified language. The
> change made the the usage of LyX for writing bi-lingual documents very
> tiresome.
>
>
> The code change is very simple:
>
> int
> src/Text3.cpp, Line 1924 (SVN version)
> toggleAndShow(cur, this, font, false);
>
>
> should be change to
>
> toggleAndShow(cur, this, font, true); //true is the default
> argument, so it can as well be left blank
>
>
> The change was mad in:
>
> http://www.lyx.org/trac/changeset/39735/lyxsvn/lyx-devel/trunk/src/Text3.cpp
>
>
>
> But it it so simple, I can only assume that this behavior was deliberated.
> If so, please, reconsider.
>
>
> Thanks,
> Ronen Abravanel
>

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

And a patch that perform my suggestion is attachted.

Ronen Abravanel



On Fri, Apr 27, 2012 at 6:04 PM, Ronen Abravanel <ron...@gmail.com> wrote:

> It seems the change was done in order to fix:
>
> http://www.lyx.org/trac/ticket/7778
>
> possible solution which will enbale to toggle languages and keep the bug
> fixed:
>
>
> If we can disable switching into corrent language, we can use
> LFUN_COMMAND_ALTERNATIVES. Somthing like
>
> command-alternatives language hebrew; language english
>
> Which will switch the the "other" language.
>
> (if I understood correctly the manual, I assume one can check waht is the
> current language and then "if (*lang == *cur_lang)  {enable  = false;
> break;}   "  will do the work)
>
>
>
> On Fri, Apr 27, 2012 at 5:49 PM, Ronen Abravanel <ron...@gmail.com> wrote:
>
>> Good morning,
>>
>> I'm using LyX for quite a while for writing bi-lingual documents, in both
>> Hebrew and English. In order to write such documents, I define one language
>> in documents->settings, and then, created a key-binding to "language
>> hebrew" [or, "language english"], and then invoke the shortcut in order to
>> toggle between the two language.
>>
>> Since LyX 2.02, that was change: invoking "language " dose
>> not toggle between languages, but switch into the specified language. The
>> change made the the usage of LyX for writing bi-lingual documents very
>> tiresome.
>>
>>
>> The code change is very simple:
>>
>> int
>> src/Text3.cpp, Line 1924 (SVN version)
>> toggleAndShow(cur, this, font, false);
>>
>>
>> should be change to
>>
>> toggleAndShow(cur, this, font, true); //true is the default
>> argument, so it can as well be left blank
>>
>>
>> The change was mad in:
>>
>> http://www.lyx.org/trac/changeset/39735/lyxsvn/lyx-devel/trunk/src/Text3.cpp
>>
>>
>>
>> But it it so simple, I can only assume that this behavior was
>> deliberated. If so, please, reconsider.
>>
>>
>> Thanks,
>> Ronen Abravanel
>>
>
>


language_toggle.diff
Description: Binary data

Re: annoying behavior of Lyx 2.02+ -- Language toggle

[Ronen Abravanel]

Even better!

On Fri, Apr 27, 2012 at 8:10 PM, Stephan Witt <st.w...@gmx.net> wrote:

> Am 27.04.2012 um 17:33 schrieb Ronen Abravanel:
>
> > And a patch that perform my suggestion is attachted.
> >
> > Ronen Abravanel
> >
> >
> >
> > On Fri, Apr 27, 2012 at 6:04 PM, Ronen Abravanel <ron...@gmail.com>
> wrote:
> > It seems the change was done in order to fix:
> >
> > http://www.lyx.org/trac/ticket/7778
>
> Yes. That's correct.
>
> Wouldn't it be easier for you to make it more smart with respect to the
> current selection?
> Like the attached patch?
>
> Stephan
>
>

Re: tutorials / slides for seminars or workshops (was: 'Re: LyX Promotion')

[Ronen Abravanel]

Translated my stuff to english:
http://technion.ac.il/~ronen/lyxlecture2/en/

probably there are some grammar problems. use freely.

On Wed, Mar 23, 2011 at 8:51 PM, Liviu Andronic landronim...@gmail.comwrote:

 On Wed, Mar 23, 2011 at 7:45 PM, Ronen Abravanel ron...@gmail.com wrote:
   department, and I started with very short into on LaTeX and in what
   scene
   LyX is different from word, and then about 40 minutes of
 demonstration
   of
   what can I do and how can I do that.
  
   If there is nothing better, I can translate my tutorial to English
 (few
  
  What is the original language of the tutorial? Maybe I could digest it
  myself.
 
  Hebrew.
 
 Oh, I haven't gotten to Hebrew yet. :) If you have time and it's not
 much bother, I would indeed much appreciate a starting point for my
 workshop. Please let me know.

 Cheers
 Liviu

Re: tutorials / slides for seminars or workshops (was: 'Re: LyX Promotion')

[Ronen Abravanel]

Translated my stuff to english:
http://technion.ac.il/~ronen/lyxlecture2/en/

probably there are some grammar problems. use freely.

On Wed, Mar 23, 2011 at 8:51 PM, Liviu Andronic <landronim...@gmail.com>wrote:

> On Wed, Mar 23, 2011 at 7:45 PM, Ronen Abravanel <ron...@gmail.com> wrote:
> >> > department, and I started with very short into on LaTeX and "in what
> >> > scene
> >> > LyX is different from word", and then about 40 minutes of
> demonstration
> >> > of
> >> > what can I do and how can I do that.
> >> >
> >> > If there is nothing better, I can translate my tutorial to English
> (few
> >> >
> >> What is the original language of the tutorial? Maybe I could digest it
> >> myself.
> >>
> > Hebrew.
> >
> Oh, I haven't gotten to Hebrew yet. :) If you have time and it's not
> much bother, I would indeed much appreciate a starting point for my
> workshop. Please let me know.
>
> Cheers
> Liviu
>

Re: tutorials / slides for seminars or workshops (was: 'Re: LyX Promotion')

[Ronen Abravanel]

On Tue, Mar 22, 2011 at 11:49 PM, Liviu Andronic landronim...@gmail.comwrote:

 On Tue, Mar 22, 2011 at 10:23 PM, Ronen Abravanel ron...@gmail.com
 wrote:
  How long should it be? A year ago I had one hour workshop on LyX in my
 
 I highly doubt that it would exceed an hour.


  department, and I started with very short into on LaTeX and in what
 scene
  LyX is different from word, and then about 40 minutes of demonstration
 of
  what can I do and how can I do that.
 
  If there is nothing better, I can translate my tutorial to English (few
 
 What is the original language of the tutorial? Maybe I could digest it
 myself.

 Hebrew.


  beamer-slides, and 3 pages of do that in order to achieve this...
 list...
 
 This is a nice idea for a tutorial, too.
 Liviu



  Ronen
 
  On Tue, Mar 22, 2011 at 6:38 PM, Liviu Andronic landronim...@gmail.com
  wrote:
 
  Dear all
  I think this is a very good idea.
 
 
  On Tue, Mar 22, 2011 at 4:51 PM, Rob Oakes lyx-de...@oak-tree.us
 wrote:
   4.) It seems that there are people willing to help promote/evangelize
   LyX, but I'm not sure we offer much in the way of promotional
 materials to
   help. Would it be worthwhile to create a limited number of tutorials
 for
   people, like Venom, who will be holding seminars or workshops? (I've
 also
   thought about teaching a design workshop through my local library, and
 these
   materials would help provide a curriculum.)
  
  I will be holding a workshop on LyX to graduate types at my university
  and I'm not very sure where from to begin. Some ready materials
  (slides on the advantages of LyX/LaTeX over MS Word and the hord, step
  by step tutorials for creating your first document in LyX, using
  bibliography and fancier features) would be of enormous help.
 
  At the moment I plan to start with the 'Help  Documentation' in
  preparing my tutorial. Perhaps some of you have already passed through
  this experience and have some materials readily available? If so,
  please post them here.
 
  Regards
  Liviu
 
 



 --
 Do you know how to read?
 http://www.alienetworks.com/srtest.cfm
 http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
 Do you know how to write?
 http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail

Re: tutorials / slides for seminars or workshops (was: 'Re: LyX Promotion')

[Ronen Abravanel]

On Tue, Mar 22, 2011 at 11:49 PM, Liviu Andronic <landronim...@gmail.com>wrote:

> On Tue, Mar 22, 2011 at 10:23 PM, Ronen Abravanel <ron...@gmail.com>
> wrote:
> > How long should it be? A year ago I had one hour workshop on LyX in my
> >
> I highly doubt that it would exceed an hour.
>
>
> > department, and I started with very short into on LaTeX and "in what
> scene
> > LyX is different from word", and then about 40 minutes of demonstration
> of
> > what can I do and how can I do that.
> >
> > If there is nothing better, I can translate my tutorial to English (few
> >
> What is the original language of the tutorial? Maybe I could digest it
> myself.
>
> Hebrew.

>
> > beamer-slides, and 3 pages of "do that in order to achieve this..."
> list...
> >
> This is a nice idea for a tutorial, too.
> Liviu
>
>
>
> > Ronen
> >
> > On Tue, Mar 22, 2011 at 6:38 PM, Liviu Andronic <landronim...@gmail.com>
> > wrote:
> >>
> >> Dear all
> >> I think this is a very good idea.
> >>
> >>
> >> On Tue, Mar 22, 2011 at 4:51 PM, Rob Oakes <lyx-de...@oak-tree.us>
> wrote:
> >> > 4.) It seems that there are people willing to help promote/evangelize
> >> > LyX, but I'm not sure we offer much in the way of promotional
> materials to
> >> > help. Would it be worthwhile to create a limited number of tutorials
> for
> >> > people, like Venom, who will be holding seminars or workshops? (I've
> also
> >> > thought about teaching a design workshop through my local library, and
> these
> >> > materials would help provide a curriculum.)
> >> >
> >> I will be holding a workshop on LyX to graduate types at my university
> >> and I'm not very sure where from to begin. Some ready materials
> >> (slides on the advantages of LyX/LaTeX over MS Word and the hord, step
> >> by step tutorials for creating your first document in LyX, using
> >> bibliography and fancier features) would be of enormous help.
> >>
> >> At the moment I plan to start with the 'Help > Documentation' in
> >> preparing my tutorial. Perhaps some of you have already passed through
> >> this experience and have some materials readily available? If so,
> >> please post them here.
> >>
> >> Regards
> >> Liviu
> >
> >
>
>
>
> --
> Do you know how to read?
> http://www.alienetworks.com/srtest.cfm
> http://goodies.xfce.org/projects/applications/xfce4-dict#speed-reader
> Do you know how to write?
> http://garbl.home.comcast.net/~garbl/stylemanual/e.htm#e-mail
>

Re: tutorials / slides for seminars or workshops (was: 'Re: LyX Promotion')

[Ronen Abravanel]

How long should it be? A year ago I had one hour workshop on LyX in my
department, and I started with very short into on LaTeX and in what scene
LyX is different from word, and then about 40 minutes of demonstration of
what can I do and how can I do that.

If there is nothing better, I can translate my tutorial to English (few
beamer-slides, and 3 pages of do that in order to achieve this... list...

Ronen

On Tue, Mar 22, 2011 at 6:38 PM, Liviu Andronic landronim...@gmail.comwrote:

 Dear all
 I think this is a very good idea.


 On Tue, Mar 22, 2011 at 4:51 PM, Rob Oakes lyx-de...@oak-tree.us wrote:
  4.) It seems that there are people willing to help promote/evangelize
 LyX, but I'm not sure we offer much in the way of promotional materials to
 help. Would it be worthwhile to create a limited number of tutorials for
 people, like Venom, who will be holding seminars or workshops? (I've also
 thought about teaching a design workshop through my local library, and these
 materials would help provide a curriculum.)
 
 I will be holding a workshop on LyX to graduate types at my university
 and I'm not very sure where from to begin. Some ready materials
 (slides on the advantages of LyX/LaTeX over MS Word and the hord, step
 by step tutorials for creating your first document in LyX, using
 bibliography and fancier features) would be of enormous help.

 At the moment I plan to start with the 'Help  Documentation' in
 preparing my tutorial. Perhaps some of you have already passed through
 this experience and have some materials readily available? If so,
 please post them here.

 Regards
 Liviu

Re: tutorials / slides for seminars or workshops (was: 'Re: LyX Promotion')

[Ronen Abravanel]

How long should it be? A year ago I had one hour workshop on LyX in my
department, and I started with very short into on LaTeX and "in what scene
LyX is different from word", and then about 40 minutes of demonstration of
what can I do and how can I do that.

If there is nothing better, I can translate my tutorial to English (few
beamer-slides, and 3 pages of "do that in order to achieve this..." list...

Ronen

On Tue, Mar 22, 2011 at 6:38 PM, Liviu Andronic wrote:

> Dear all
> I think this is a very good idea.
>
>
> On Tue, Mar 22, 2011 at 4:51 PM, Rob Oakes  wrote:
> > 4.) It seems that there are people willing to help promote/evangelize
> LyX, but I'm not sure we offer much in the way of promotional materials to
> help. Would it be worthwhile to create a limited number of tutorials for
> people, like Venom, who will be holding seminars or workshops? (I've also
> thought about teaching a design workshop through my local library, and these
> materials would help provide a curriculum.)
> >
> I will be holding a workshop on LyX to graduate types at my university
> and I'm not very sure where from to begin. Some ready materials
> (slides on the advantages of LyX/LaTeX over MS Word and the hord, step
> by step tutorials for creating your first document in LyX, using
> bibliography and fancier features) would be of enormous help.
>
> At the moment I plan to start with the 'Help > Documentation' in
> preparing my tutorial. Perhaps some of you have already passed through
> this experience and have some materials readily available? If so,
> please post them here.
>
> Regards
> Liviu
>

Bug in 2.0RC1? language changing change the language of already written text.

[Ronen Abravanel]

Hello,

I started using LyX 2.0RC1, and by now, there is only one thing that
bothers  me:
While I'm typing a document in one language, and then, when the cursor is
right after the last word (with no space), I'm typing language hebrew  in
the minibuffer (or: using predefined shortcuts that commits the same). The
language do changes, but the last word is also marked and it's language
switched.

For example, If I write one two^, and when the cursor is where the ^ is,
changes the language, it will convert into one [owt],  when the two is
reversed, as it thinks it's in Hebrew, and the [ - ] part is marked.

This is new behavior - it was not there in some previous versions of 2.0,
but it's there in beta 4.

Thanks,
Ronen.

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Ronen Abravanel]

My most common situation in which this is a problem is the following

Hebrew text (English translation) more hebrew..

For most language, you wouldn't mind if the  ( ) will be in English or in
other language, but Hebrew is written from right to left, which means the
Parentheses  are written in reverse. Meaning, if the closing parentheses
will be in English, it will apear as:

Hebrew text ((English Hebrew

(Or something like that)

there fore, the following parentheses or comma must be at the same language
as the paragraph language, and not as the last-word language.

My override now is

hebrew (english ) hebrew, or hebrew english , hebrew [note the space before
the comma or the closing parentheses], and that's both ugly and wrong.

An Hebrew example:
כותב בעברית (english) עברית -- In this way its typed when the closing
parentheses is hebrew
כותב בעברית ((english  עברית. -- here the closing parentheses is english

Thanks,
Ronen.


On Tue, Mar 8, 2011 at 6:18 PM, Stephan Witt st.w...@gmx.net wrote:

 Am 08.03.2011 um 16:51 schrieb Ronen Abravanel:

  Hello,
 
  I started using LyX 2.0RC1, and by now, there is only one thing that
 bothers  me:
  While I'm typing a document in one language, and then, when the cursor is
 right after the last word (with no space), I'm typing language hebrew  in
 the minibuffer (or: using predefined shortcuts that commits the same). The
 language do changes, but the last word is also marked and it's language
 switched.
 
  For example, If I write one two^, and when the cursor is where the ^
 is, changes the language, it will convert into one [owt],  when the two
 is reversed, as it thinks it's in Hebrew, and the [ - ] part is marked.
 
  This is new behavior - it was not there in some previous versions of 2.0,
 but it's there in beta 4.

 Yes, this is new - but it's meant as a feature.
 If you change the language without any selection LyX changes the language
 of the word under the cursor.

 Do you want to change the language for the delimiter following the word?
 Sorry, I don't know anything about hebrew.

 Stephan

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Ronen Abravanel]

Works grate for me...


On Tue, Mar 8, 2011 at 10:54 PM, Stephan Witt st.w...@gmx.net wrote:

 Am 08.03.2011 um 17:36 schrieb Ronen Abravanel:

  My most common situation in which this is a problem is the following
 
  Hebrew text (English translation) more hebrew..
 
  For most language, you wouldn't mind if the  ( ) will be in English or
 in other language, but Hebrew is written from right to left, which means the
 Parentheses  are written in reverse. Meaning, if the closing parentheses
 will be in English, it will apear as:
 
  Hebrew text ((English Hebrew
 
  (Or something like that)
 
  there fore, the following parentheses or comma must be at the same
 language as the paragraph language, and not as the last-word language.

 I believe you.

 The attached patch changes this to restore the old behavior when cursor is
 at the word end.
 Ok to apply?

 Stephan

Bug in 2.0RC1? language changing change the language of already written text.

[Ronen Abravanel]

Hello,

I started using LyX 2.0RC1, and by now, there is only one thing that
bothers  me:
While I'm typing a document in one language, and then, when the cursor is
right after the last word (with no space), I'm typing "language hebrew"  in
the minibuffer (or: using predefined shortcuts that commits the same). The
language do changes, but the last word is also marked and it's language
switched.

For example, If I write "one two^", and when the cursor is where the ^ is,
changes the language, it will convert into "one [owt]",  when the "two" is
reversed, as it "thinks" it's in Hebrew, and the [ - ] part is marked.

This is new behavior - it was not there in some previous versions of 2.0,
but it's there in beta 4.

Thanks,
Ronen.

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Ronen Abravanel]

My most common situation in which this is a problem is the following

Hebrew text (English translation) more hebrew..

For most language, you wouldn't mind if the " ( )" will be in English or in
other language, but Hebrew is written from right to left, which means the
Parentheses  are written in reverse. Meaning, if the closing parentheses
will be in English, it will apear as:

Hebrew text ((English Hebrew

(Or something like that)

there fore, the following parentheses or comma must be at the same language
as the paragraph language, and not as the last-word language.

My override now is

hebrew (english ) hebrew, or hebrew english , hebrew [note the space before
the comma or the closing parentheses], and that's both ugly and wrong.

An Hebrew example:
כותב בעברית (english) עברית -- In this way its typed when the closing
parentheses is hebrew
כותב בעברית ((english  עברית. -- here the closing parentheses is english

Thanks,
Ronen.


On Tue, Mar 8, 2011 at 6:18 PM, Stephan Witt <st.w...@gmx.net> wrote:

> Am 08.03.2011 um 16:51 schrieb Ronen Abravanel:
>
> > Hello,
> >
> > I started using LyX 2.0RC1, and by now, there is only one thing that
> bothers  me:
> > While I'm typing a document in one language, and then, when the cursor is
> right after the last word (with no space), I'm typing "language hebrew"  in
> the minibuffer (or: using predefined shortcuts that commits the same). The
> language do changes, but the last word is also marked and it's language
> switched.
> >
> > For example, If I write "one two^", and when the cursor is where the ^
> is, changes the language, it will convert into "one [owt]",  when the "two"
> is reversed, as it "thinks" it's in Hebrew, and the [ - ] part is marked.
> >
> > This is new behavior - it was not there in some previous versions of 2.0,
> but it's there in beta 4.
>
> Yes, this is new - but it's meant as a feature.
> If you change the language without any selection LyX changes the language
> of the word under the cursor.
>
> Do you want to change the language for the delimiter following the word?
> Sorry, I don't know anything about hebrew.
>
> Stephan

Re: Bug in 2.0RC1? language changing change the language of already written text.

[Ronen Abravanel]

Works grate for me...


On Tue, Mar 8, 2011 at 10:54 PM, Stephan Witt <st.w...@gmx.net> wrote:

> Am 08.03.2011 um 17:36 schrieb Ronen Abravanel:
>
> > My most common situation in which this is a problem is the following
> >
> > Hebrew text (English translation) more hebrew..
> >
> > For most language, you wouldn't mind if the " ( )" will be in English or
> in other language, but Hebrew is written from right to left, which means the
> Parentheses  are written in reverse. Meaning, if the closing parentheses
> will be in English, it will apear as:
> >
> > Hebrew text ((English Hebrew
> >
> > (Or something like that)
> >
> > there fore, the following parentheses or comma must be at the same
> language as the paragraph language, and not as the last-word language.
>
> I believe you.
>
> The attached patch changes this to restore the old behavior when cursor is
> at the word end.
> Ok to apply?
>
> Stephan
>
>

Re: LyX 2.0 crash when choosing a word from the spell-checker context menu

[Ronen Abravanel]

I'm using the SVN current trunk.
The bug happened with 3-days ago SVN version on Ubuntu 10.04 and on
20-minutes-ago svn version (Rev 35607) on Ubuntu 10.10.

In order to get the crash I'm typing a wrong word, when the
red-wiggly-line appears, I right-clicking the word and choose some random
word from the list.
Crash almost every time.

Any more details I can supply?

Ronen.

On Tue, Oct 12, 2010 at 1:09 AM, Stephan Witt st.w...@gmx.net wrote:

 Am 12.10.2010 um 03:16 schrieb Ronen Abravanel:

  Starting program: /home/ronen/dev/lyx/svn/lyx-devel/src/lyx
  [Thread debugging using libthread_db enabled]
  /usr/include/c++/4.4/bits/basic_string.h:738: typename
 _Alloc::rebind_CharT::other::reference std::basic_stringChar, Traits,
 Alloc::operator[](typename _Alloc::rebind_CharT::other::size_type) [with
 _CharT = wchar_t, _Traits = std::char_traitswchar_t, _Alloc =
 std::allocatorwchar_t]: Assertion '__pos = size()' failed.
 
  Program received signal SIGABRT, Aborted.
  0x0012d422 in __kernel_vsyscall ()
  (gdb) bt
  #0  0x0012d422 in __kernel_vsyscall ()
  #1  0x01139651 in raise () from /lib/tls/i686/cmov/libc.so.6
  #2  0x0113ca82 in abort () from /lib/tls/i686/cmov/libc.so.6
  #3  0x082686d0 in std::basic_stringwchar_t, std::char_traitswchar_t,
 std::allocatorwchar_t ::operator[](unsigned int) ()
  #4  0x08252d4a in lyx::Paragraph::isWordSeparator (this=0x908f7b0,
 pos=24)
  at Paragraph.cpp:2795
  #5  0x08252f1d in lyx::Paragraph::locateWord (this=0x908f7b0,
  fr...@0xbfff80e8, t...@0xbfff80dc, loc=lyx::WHOLE_WORD)
  at Paragraph.cpp:3353
  #6  0x08263242 in lyx::Paragraph::Private::rangeOfSpellCheck
 (this=0x908f7b0)
  at Paragraph.cpp:391
  #7  lyx::Paragraph::spellCheck (this=0x908f7b0) at Paragraph.cpp:3632

 Hi Ronen,

 thank you for doing the backtrace.
 Can you please give me some details?
 You're using SVN current trunk code?
 What are you doing to get the crash?

 Stephan

Re: LyX 2.0 crash when choosing a word from the spell-checker context menu

[Ronen Abravanel]

Awesome.  Works for me perfectly.

Thanks!


On Tue, Oct 12, 2010 at 3:09 PM, Stephan Witt st.w...@gmx.net wrote:

 Am 12.10.2010 um 19:00 schrieb John McCabe-Dansted:

  On Tue, Oct 12, 2010 at 10:43 PM, Ronen Abravanel ron...@mit.edu
 wrote:
  Any more details I can supply?

 No, I got it already. Thanks.

  I don't think any more is required. This seems to be another way to
 reproduce:
  http://www.lyx.org/trac/ticket/6945
  (I submitted this bug a few hours after your original report, which
  would be why you couldn't find it).
 
  I tried your recipe, and as with #6945, it appears to be a regression
  in r35362.

 Should by fixed now (r35616).

 Stephan

Re: LyX 2.0 crash when choosing a word from the spell-checker context menu

[Ronen Abravanel]

I'm using the SVN current trunk.
The bug happened with 3-days ago SVN version on Ubuntu 10.04 and on
20-minutes-ago svn version (Rev 35607) on Ubuntu 10.10.

In order to get the crash I'm typing a "wrong" word, when the
red-wiggly-line appears, I right-clicking the word and choose some random
word from the list.
Crash almost every time.

Any more details I can supply?

Ronen.

On Tue, Oct 12, 2010 at 1:09 AM, Stephan Witt <st.w...@gmx.net> wrote:

> Am 12.10.2010 um 03:16 schrieb Ronen Abravanel:
>
> > Starting program: /home/ronen/dev/lyx/svn/lyx-devel/src/lyx
> > [Thread debugging using libthread_db enabled]
> > /usr/include/c++/4.4/bits/basic_string.h:738: typename
> _Alloc::rebind<_CharT>::other::reference std::basic_string<Char, Traits,
> Alloc>::operator[](typename _Alloc::rebind<_CharT>::other::size_type) [with
> _CharT = wchar_t, _Traits = std::char_traits, _Alloc =
> std::allocator]: Assertion '__pos <= size()' failed.
> >
> > Program received signal SIGABRT, Aborted.
> > 0x0012d422 in __kernel_vsyscall ()
> > (gdb) bt
> > #0  0x0012d422 in __kernel_vsyscall ()
> > #1  0x01139651 in raise () from /lib/tls/i686/cmov/libc.so.6
> > #2  0x0113ca82 in abort () from /lib/tls/i686/cmov/libc.so.6
> > #3  0x082686d0 in std::basic_string<wchar_t, std::char_traits,
> std::allocator >::operator[](unsigned int) ()
> > #4  0x08252d4a in lyx::Paragraph::isWordSeparator (this=0x908f7b0,
> pos=24)
> > at Paragraph.cpp:2795
> > #5  0x08252f1d in lyx::Paragraph::locateWord (this=0x908f7b0,
> > fr...@0xbfff80e8, t...@0xbfff80dc, loc=lyx::WHOLE_WORD)
> > at Paragraph.cpp:3353
> > #6  0x08263242 in lyx::Paragraph::Private::rangeOfSpellCheck
> (this=0x908f7b0)
> > at Paragraph.cpp:391
> > #7  lyx::Paragraph::spellCheck (this=0x908f7b0) at Paragraph.cpp:3632
>
> Hi Ronen,
>
> thank you for doing the backtrace.
> Can you please give me some details?
> You're using SVN current trunk code?
> What are you doing to get the crash?
>
> Stephan

Re: LyX 2.0 crash when choosing a word from the spell-checker context menu

[Ronen Abravanel]

Awesome.  Works for me perfectly.

Thanks!


On Tue, Oct 12, 2010 at 3:09 PM, Stephan Witt <st.w...@gmx.net> wrote:

> Am 12.10.2010 um 19:00 schrieb John McCabe-Dansted:
>
> > On Tue, Oct 12, 2010 at 10:43 PM, Ronen Abravanel <ron...@mit.edu>
> wrote:
> >> Any more details I can supply?
>
> No, I got it already. Thanks.
>
> > I don't think any more is required. This seems to be another way to
> reproduce:
> > http://www.lyx.org/trac/ticket/6945
> > (I submitted this bug a few hours after your original report, which
> > would be why you couldn't find it).
> >
> > I tried your recipe, and as with #6945, it appears to be a regression
> > in r35362.
>
> Should by fixed now (r35616).
>
> Stephan

LyX 2.0 crash when choosing a word from the spell-checker context menu

[Ronen Abravanel]

Hi,

I'm using SVN version from recent days, but this problem also accord in
older versions:

Sometime, when I'm right-clicking misspelled word with wiggly-red-line
beneath, and then choose the correct word from the context menu, LyX crash.
The output in the console is:

ro...@goon:~/dev/lyx/svn/lyx-devel$ ./src/lyx
/usr/include/c++/4.4/bits/basic_string.h:738: typename
_Alloc::rebind_CharT::other::reference std::basic_stringChar, Traits,
Alloc::operator[](typename _Alloc::rebind_CharT::other::size_type) [with
_CharT = wchar_t, _Traits = std::char_traitswchar_t, _Alloc =
std::allocatorwchar_t]: Assertion '__pos = size()' failed.
Aborted


I couldn't find any track ticket for this problem. Was I right?
What can I do in order to help specify the bug further?

Thanks,
Ronen

Re: LyX 2.0 crash when choosing a word from the spell-checker context menu

[Ronen Abravanel]

::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from
/usr/lib/libQtCore.so.4
#47 0x00ea44aa in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) ()
   from /usr/lib/libQtCore.so.4
#48 0x00898dde in QMenu::exec(QPoint const, QAction*) ()
   from /usr/lib/libQtGui.so.4
#49 0x0863b59f in lyx::frontend::GuiWorkArea::contextMenuEvent (
this=0x9099628, e=0xbfffd4b8) at GuiWorkArea.cpp:704
#50 0x00454f38 in QWidget::event(QEvent*) () from /usr/lib/libQtGui.so.4
#51 0x00850fd3 in QFrame::event(QEvent*) () from /usr/lib/libQtGui.so.4
#52 0x008eb382 in QAbstractScrollArea::viewportEvent(QEvent*) ()
   from /usr/lib/libQtGui.so.4
#53 0x008edc65 in ?? () from /usr/lib/libQtGui.so.4
#54 0x00ea4cda in
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject---Type
return to continue, or q return to quit---
*, QEvent*) () from /usr/lib/libQtCore.so.4
#55 0x003f64b9 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
   from /usr/lib/libQtGui.so.4
#56 0x003fd470 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/libQtGui.so.4
#57 0x085de96f in lyx::frontend::GuiApplication::notify (this=0x8c512c0,
receiver=0x9018e78, event=0xbfffd4b8) at GuiApplication.cpp:2141
#58 0x00ea5a3b in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
   from /usr/lib/libQtCore.so.4
#59 0x0048ddfe in QCoreApplication::sendSpontaneousEvent(QObject*, QEvent*)
()
   from /usr/lib/libQtGui.so.4
#60 0x004880f4 in ?? () from /usr/lib/libQtGui.so.4
#61 0x00487511 in QApplication::x11ProcessEvent(_XEvent*) ()
   from /usr/lib/libQtGui.so.4
#62 0x004b660a in ?? () from /usr/lib/libQtGui.so.4
#63 0x001825e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#64 0x001862d8 in ?? () from /lib/libglib-2.0.so.0
#65 0x001864b8 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#66 0x00ed15d5 in
QEventDispatcherGlib::processEvents(QFlagsQEventLoop::ProcessEventsFlag)
() from /usr/lib/libQtCore.so.4
#67 0x004b6135 in ?? () from /usr/lib/libQtGui.so.4
#68 0x00ea4059 in
QEventLoop::processEvents(QFlagsQEventLoop::ProcessEventsFlag) () from
/usr/lib/libQtCore.so.4
---Type return to continue, or q return to quit---
#69 0x00ea44aa in QEventLoop::exec(QFlagsQEventLoop::ProcessEventsFlag) ()
   from /usr/lib/libQtCore.so.4
#70 0x00ea869f in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#71 0x003f6577 in QApplication::exec() () from /usr/lib/libQtGui.so.4
#72 0x085ddfde in lyx::frontend::GuiApplication::exec (this=0x8c512c0)
at GuiApplication.cpp:1921
#73 0x081fedf3 in lyx::LyX::exec (this=0xb3b8, ar...@0xb3e0,
argv=0xb484) at LyX.cpp:383
#74 0x08076dd0 in main (argc=1, argv=0xb484) at main.cpp:43


On Mon, Oct 11, 2010 at 5:57 PM, Pavel Sanda sa...@lyx.org wrote:

 Ronen Abravanel wrote:
  What can I do in order to help specify the bug further?

 1. to find a recipy how to reproduce (maybe hard)
 2. at least to produce a backtrace
 http://wiki.lyx.org/FAQ/FurtherHelp#toc4

 pavel

LyX 2.0 crash when choosing a word from the spell-checker context menu

[Ronen Abravanel]

Hi,

I'm using SVN version from recent days, but this problem also accord in
older versions:

Sometime, when I'm right-clicking misspelled word with wiggly-red-line
beneath, and then choose the correct word from the context menu, LyX crash.
The output in the console is:

ro...@goon:~/dev/lyx/svn/lyx-devel$ ./src/lyx
/usr/include/c++/4.4/bits/basic_string.h:738: typename
_Alloc::rebind<_CharT>::other::reference std::basic_string::operator[](typename _Alloc::rebind<_CharT>::other::size_type) [with
_CharT = wchar_t, _Traits = std::char_traits, _Alloc =
std::allocator]: Assertion '__pos <= size()' failed.
Aborted


I couldn't find any track ticket for this problem. Was I right?
What can I do in order to help specify the bug further?

Thanks,
Ronen

Re: LyX 2.0 crash when choosing a word from the spell-checker context menu

[Ronen Abravanel]

 0x00ea44aa in QEventLoop::exec(QFlags) ()
   from /usr/lib/libQtCore.so.4
#48 0x00898dde in QMenu::exec(QPoint const&, QAction*) ()
   from /usr/lib/libQtGui.so.4
#49 0x0863b59f in lyx::frontend::GuiWorkArea::contextMenuEvent (
this=0x9099628, e=0xbfffd4b8) at GuiWorkArea.cpp:704
#50 0x00454f38 in QWidget::event(QEvent*) () from /usr/lib/libQtGui.so.4
#51 0x00850fd3 in QFrame::event(QEvent*) () from /usr/lib/libQtGui.so.4
#52 0x008eb382 in QAbstractScrollArea::viewportEvent(QEvent*) ()
   from /usr/lib/libQtGui.so.4
#53 0x008edc65 in ?? () from /usr/lib/libQtGui.so.4
#54 0x00ea4cda in
QCoreApplicationPrivate::sendThroughObjectEventFilters(QObject---Type
 to continue, or q  to quit---
*, QEvent*) () from /usr/lib/libQtCore.so.4
#55 0x003f64b9 in QApplicationPrivate::notify_helper(QObject*, QEvent*) ()
   from /usr/lib/libQtGui.so.4
#56 0x003fd470 in QApplication::notify(QObject*, QEvent*) ()
   from /usr/lib/libQtGui.so.4
#57 0x085de96f in lyx::frontend::GuiApplication::notify (this=0x8c512c0,
receiver=0x9018e78, event=0xbfffd4b8) at GuiApplication.cpp:2141
#58 0x00ea5a3b in QCoreApplication::notifyInternal(QObject*, QEvent*) ()
   from /usr/lib/libQtCore.so.4
#59 0x0048ddfe in QCoreApplication::sendSpontaneousEvent(QObject*, QEvent*)
()
   from /usr/lib/libQtGui.so.4
#60 0x004880f4 in ?? () from /usr/lib/libQtGui.so.4
#61 0x00487511 in QApplication::x11ProcessEvent(_XEvent*) ()
   from /usr/lib/libQtGui.so.4
#62 0x004b660a in ?? () from /usr/lib/libQtGui.so.4
#63 0x001825e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#64 0x001862d8 in ?? () from /lib/libglib-2.0.so.0
#65 0x001864b8 in g_main_context_iteration () from /lib/libglib-2.0.so.0
#66 0x00ed15d5 in
QEventDispatcherGlib::processEvents(QFlags)
() from /usr/lib/libQtCore.so.4
#67 0x004b6135 in ?? () from /usr/lib/libQtGui.so.4
#68 0x00ea4059 in
QEventLoop::processEvents(QFlags) () from
/usr/lib/libQtCore.so.4
---Type  to continue, or q  to quit---
#69 0x00ea44aa in QEventLoop::exec(QFlags) ()
   from /usr/lib/libQtCore.so.4
#70 0x00ea869f in QCoreApplication::exec() () from /usr/lib/libQtCore.so.4
#71 0x003f6577 in QApplication::exec() () from /usr/lib/libQtGui.so.4
#72 0x085ddfde in lyx::frontend::GuiApplication::exec (this=0x8c512c0)
at GuiApplication.cpp:1921
#73 0x081fedf3 in lyx::LyX::exec (this=0xb3b8, ar...@0xb3e0,
argv=0xb484) at LyX.cpp:383
#74 0x08076dd0 in main (argc=1, argv=0xb484) at main.cpp:43


On Mon, Oct 11, 2010 at 5:57 PM, Pavel Sanda <sa...@lyx.org> wrote:

> Ronen Abravanel wrote:
> > What can I do in order to help specify the bug further?
>
> 1. to find a recipy how to reproduce (maybe hard)
> 2. at least to produce a backtrace
> http://wiki.lyx.org/FAQ/FurtherHelp#toc4
>
> pavel
>

Re: Patch: Diagram inset

[Ronen Abravanel]

On Sun, Sep 19, 2010 at 3:35 AM, Pavel Sanda sa...@lyx.org wrote:

 Ronen Abravanel wrote:
  Pavel -- Thanks. I removed big portion of the code that was not needed.

 good news

  I can refactor both XYMatrix and Diagram class to have one common base
  class, but it will take me a while. How urgent things should be ready for
  2.0?

 personally i would prefer not to touch XYMatrix ;)
 (basically because i dont know all its features and can't test whether we
 killed something...)

 so my proposal was rather that Diagram would be child of XYMatrix,
 althought i
 understand the philosophical point behind common virtual class.
 so in case other devs are not against, i would choose the simpler route...

 but as i have written before the class is so small that i would accept
 even the current version if the inheritance bussiness makes things
 complicated ;)

  +def revert_diagram(document):
  +  i = 0
  +  re_diagram = re.compile(r'\\begin_inset Formula .*\\Diagram',
 re.DOTALL)
  +  while True:
  +i = find_token(document.body, '\\begin_inset Formula', i)
  +if i == -1:
  +  print returning

 debug output is not needed

  +  return
  +j = find_end_of_inset(document.body, i)
  +if j == -1:
  +print Melformed document!

 typo

  +return
  +m = re_diagram.search(\n.join(document.body[i:j]))

 i'm surprised about this newline, but you are right its there.
 strange. i still think the postscript output will be the same
 but who knows...

  + * \file InsetMathDiagram.h
  + * This file is part of LyX, the document processor.
  + * Licence details can be found in the file COPYING.
  + *
  + * \author André Pönitz
  +* \author Ronen Abravanel

 whitespace

 pavel

diff -rupN lyx-2.0.0alpha6/lib/lyx2lyx/lyx_2_0.py lyx-2.0.0alpha6_feynFinal/lib/lyx2lyx/lyx_2_0.py
--- lyx-2.0.0alpha6/lib/lyx2lyx/lyx_2_0.py	2010-09-15 16:33:40.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/lib/lyx2lyx/lyx_2_0.py	2010-09-19 10:49:58.0 -0400
@@ -1568,7 +1568,6 @@ def revert_fontcolor(document):
+ ', ' + str(blueout) + '}\n'
+ '\\color{document_fontcolor}\n')
 
-
 def revert_shadedboxcolor(document):
  Reverts shaded box color to preamble code 
 i = 0
@@ -2161,6 +2160,26 @@ def revert_rule(document):
   else:
 return
 
+def revert_diagram(document):
+  i = 0
+  re_diagram = re.compile(r'\\begin_inset Formula .*\\Diagram', re.DOTALL)
+  while True:
+i = find_token(document.body, '\\begin_inset Formula', i)
+if i == -1:
+  return
+j = find_end_of_inset(document.body, i)
+if j == -1:
+document.warning(Malformed LyX document: Can't find end of line inset.)
+return 
+m = re_diagram.search(\n.join(document.body[i:j]))
+if not m:
+  i += 1
+  continue
+add_to_preamble(document, \\use_package{feyn})
+# only need to do it once!
+return
+
+
 
 ##
 # Conversion hub
@@ -2221,10 +2240,12 @@ convert = [[346, []],
[397, [remove_Nameref]],
[398, []],
[399, [convert_mathdots]],
-   [400, [convert_rule]]
+   [400, [convert_rule]],
+   [401, []]
   ]
 
-revert =  [[399, [revert_rule]],
+revert =  [[400, [revert_diagram]],
+   [399, [revert_rule]],
[398, [revert_mathdots]],
[397, [revert_mathrsfs]],
[396, []],
diff -rupN lyx-2.0.0alpha6/src/Buffer.cpp lyx-2.0.0alpha6_feynFinal/src/Buffer.cpp
--- lyx-2.0.0alpha6/src/Buffer.cpp	2010-09-15 16:33:41.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/Buffer.cpp	2010-09-18 22:33:25.0 -0400
@@ -127,7 +127,7 @@ namespace {
 
 // Do not remove the comment below, so we get merge conflict in
 // independent branches. Instead add your own.
-int const LYX_FORMAT = 400; // uwestoehr: support for \rule
+int const LYX_FORMAT = 401; // uwestoehr: support for \rule \\Ronen: support for \Diagrasr
 
 typedef mapstring, bool DepClean;
 typedef mapdocstring, pairInsetLabel const *, Buffer::References  RefCache;
diff -rupN lyx-2.0.0alpha6/src/insets/InsetCode.h lyx-2.0.0alpha6_feynFinal/src/insets/InsetCode.h
--- lyx-2.0.0alpha6/src/insets/InsetCode.h	2010-09-15 16:33:43.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/insets/InsetCode.h	2010-09-18 21:22:40.0 -0400
@@ -223,6 +223,8 @@ enum InsetCode {
 	///
 	PREVIEW_CODE,
 	///
+	MATH_DIAGRAM_CODE, 
+	///
 	INSET_CODE_SIZE,
 };
 
diff -rupN lyx-2.0.0alpha6/src/insets/Inset.cpp lyx-2.0.0alpha6_feynFinal/src/insets/Inset.cpp
--- lyx-2.0.0alpha6/src/insets/Inset.cpp	2010-09-15 16:33:42.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/insets/Inset.cpp	2010-09-18 21:23:37.0 -0400
@@ -168,6 +168,7 @@ static void build_translator()
 	insetnames[MATH_XARROW_CODE] = InsetName(mathxarrow);
 	insetnames[MATH_XYARROW_CODE] = InsetName(mathxyarrow);
 	insetnames[MATH_XYMATRIX_CODE] = InsetName(mathxymatrix);
+	insetnames[MATH_DIAGRAM_CODE] = InsetName(mathdiagram

Re: When preview is on

[Ronen Abravanel]

It seems that that simple patch do the trick (Preview is rendered on Instant
Preview - On OR No math..)


On Sun, Sep 19, 2010 at 3:48 AM, Pavel Sanda sa...@lyx.org wrote:

 Ronen Abravanel wrote:
  Currently, in Lyx 2.0, there are 3 modes for preview:
  * On -- Preview is working for math and preview-inset
  * No math --
  * Off
 
  My 1st question is what the different between no math and Off? what
 else
  is previewed other than math and preview inset?

 for example external insets use this mechanism to render pictures

  My second concern is the reason this mail is on the developers list: Is
  there any reason no to separate the rendering of the preview-inset from
  regular math? for 98 percent of my math -- I prefer it will not be
 rendered.
  But for the other two percent -- the diagrams (either using \xymatrix,
 the
  new \Diagram inset, or just plain-old ERT), I would really like to be
  previewed.
 
  If it's some arbitrary decision, and you didn't thought it's important,
 I'll
  be happy to try and do the change..

 original author is currently away... personally i have no problem with
 separating it.
 i guess that you would be happy to connect no math with your usecase?

 (although i'll be happy for some
  pointers, as I don't yet very familiar with lyx' code).

 for the insetpreview part, quick peek gives two possibly interesting
 commits 38890, 33890:

 git log --author=vfr |grep -A2 InsetPreview
New file format for InsetPreview introduced in r38890.

git-svn-id: 
 svn://svn.lyx.org/lyx/lyx-devel/tr...@33891a592a061-630c-0410-9148-cb99ea01b6c8
 --
Introduce InsetPreview.

git-svn-id: 
 svn://svn.lyx.org/lyx/lyx-devel/tr...@33890a592a061-630c-0410-9148-cb99ea01b6c8

 pavel

--- lyx-2.0.0alpha6_feyn/src/insets/InsetPreview.cpp	2010-09-15 16:33:43.0 -0400
+++ lyx-2.0.0alpha6/src/insets/InsetPreview.cpp	2010-09-19 11:56:12.0 -0400
@@ -78,7 +78,7 @@ void InsetPreview::preparePreview(DocIte
 
 bool InsetPreview::previewState(BufferView * bv) const
 {
-	if (!editing(bv)  RenderPreview::status() == LyXRC::PREVIEW_ON) {
+	if (!editing(bv)  (RenderPreview::status() == LyXRC::PREVIEW_ON || RenderPreview::status() == LyXRC::PREVIEW_NO_MATH)) {
 		graphics::PreviewImage const * pimage =
 			preview_-getPreviewImage(bv-buffer());
 		return pimage  pimage-image();

Re: Patch: Diagram inset

[Ronen Abravanel]

On Sun, Sep 19, 2010 at 11:46 AM, Richard Heck rgh...@comcast.net wrote:

 On 9/19/10 11:19 AM, Ronen Abravanel wrote:


 +def revert_diagram(document):
 +  i = 0
 +  re_diagram = re.compile(r'\\begin_inset Formula .*\\Diagram',
 re.DOTALL)
 +  while True:
 +i = find_token(document.body, '\\begin_inset Formula', i)
 +if i == -1:
 +  return
 +j = find_end_of_inset(document.body, i)
 +if j == -1:
 +document.warning(Malformed LyX document: Can't find end of line
 inset.)

 +return
 +m = re_diagram.search(\n.join(document.body[i:j]))
 +if not m:
 +  i += 1
 +  continue
 +add_to_preamble(document, \\use_package{feyn})
 +# only need to do it once!
 +return
 +
 +



 Like Pavel, I'm a bit puzzled by this. I see the newline in
 InsetXYMatrix::write() and now in your code, but I hadn't realized we put
 newlines into the math stuff. Anyway, better not to assume they're not
 there.

I don't understand how all this mechanism works. I just assume the XTMatrix
works, and then change the things I do understand.



  +int const LYX_FORMAT = 401; // uwestoehr: support for \rule \\Ronen:
 support for \Diagrasr



 You can take Uwe's comment out, which applied to format 400, and just have
 yours. The main thing is just to have a comment there.

 Otherwise looks fine to me, though I'm not expert on the math stuff.

 rh


(The only part changes now: The comment in Buffer.cpp)
diff -rupN lyx-2.0.0alpha6/lib/lyx2lyx/lyx_2_0.py lyx-2.0.0alpha6_feynFinal/lib/lyx2lyx/lyx_2_0.py
--- lyx-2.0.0alpha6/lib/lyx2lyx/lyx_2_0.py	2010-09-15 16:33:40.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/lib/lyx2lyx/lyx_2_0.py	2010-09-19 10:49:58.0 -0400
@@ -1568,7 +1568,6 @@ def revert_fontcolor(document):
+ ', ' + str(blueout) + '}\n'
+ '\\color{document_fontcolor}\n')
 
-
 def revert_shadedboxcolor(document):
  Reverts shaded box color to preamble code 
 i = 0
@@ -2161,6 +2160,26 @@ def revert_rule(document):
   else:
 return
 
+def revert_diagram(document):
+  i = 0
+  re_diagram = re.compile(r'\\begin_inset Formula .*\\Diagram', re.DOTALL)
+  while True:
+i = find_token(document.body, '\\begin_inset Formula', i)
+if i == -1:
+  return
+j = find_end_of_inset(document.body, i)
+if j == -1:
+document.warning(Malformed LyX document: Can't find end of line inset.)
+return 
+m = re_diagram.search(\n.join(document.body[i:j]))
+if not m:
+  i += 1
+  continue
+add_to_preamble(document, \\use_package{feyn})
+# only need to do it once!
+return
+
+
 
 ##
 # Conversion hub
@@ -2221,10 +2240,12 @@ convert = [[346, []],
[397, [remove_Nameref]],
[398, []],
[399, [convert_mathdots]],
-   [400, [convert_rule]]
+   [400, [convert_rule]],
+   [401, []]
   ]
 
-revert =  [[399, [revert_rule]],
+revert =  [[400, [revert_diagram]],
+   [399, [revert_rule]],
[398, [revert_mathdots]],
[397, [revert_mathrsfs]],
[396, []],
diff -rupN lyx-2.0.0alpha6/src/Buffer.cpp lyx-2.0.0alpha6_feynFinal/src/Buffer.cpp
--- lyx-2.0.0alpha6/src/Buffer.cpp	2010-09-15 16:33:41.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/Buffer.cpp	2010-09-18 22:33:25.0 -0400
@@ -127,7 +127,7 @@ namespace {
 
 // Do not remove the comment below, so we get merge conflict in
 // independent branches. Instead add your own.
-int const LYX_FORMAT = 400; // uwestoehr: support for \rule
+int const LYX_FORMAT = 401; // Ronen: support for \Diagram
 
 typedef mapstring, bool DepClean;
 typedef mapdocstring, pairInsetLabel const *, Buffer::References  RefCache;
diff -rupN lyx-2.0.0alpha6/src/insets/InsetCode.h lyx-2.0.0alpha6_feynFinal/src/insets/InsetCode.h
--- lyx-2.0.0alpha6/src/insets/InsetCode.h	2010-09-15 16:33:43.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/insets/InsetCode.h	2010-09-18 21:22:40.0 -0400
@@ -223,6 +223,8 @@ enum InsetCode {
 	///
 	PREVIEW_CODE,
 	///
+	MATH_DIAGRAM_CODE, 
+	///
 	INSET_CODE_SIZE,
 };
 
diff -rupN lyx-2.0.0alpha6/src/insets/Inset.cpp lyx-2.0.0alpha6_feynFinal/src/insets/Inset.cpp
--- lyx-2.0.0alpha6/src/insets/Inset.cpp	2010-09-15 16:33:42.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/insets/Inset.cpp	2010-09-18 21:23:37.0 -0400
@@ -168,6 +168,7 @@ static void build_translator()
 	insetnames[MATH_XARROW_CODE] = InsetName(mathxarrow);
 	insetnames[MATH_XYARROW_CODE] = InsetName(mathxyarrow);
 	insetnames[MATH_XYMATRIX_CODE] = InsetName(mathxymatrix);
+	insetnames[MATH_DIAGRAM_CODE] = InsetName(mathdiagram);
 	insetnames[MATH_MACRO_CODE] = InsetName(mathmacro);
 
 	passed = true;
diff -rupN lyx-2.0.0alpha6/src/LaTeXFeatures.cpp lyx-2.0.0alpha6_feynFinal/src/LaTeXFeatures.cpp
--- lyx-2.0.0alpha6/src/LaTeXFeatures.cpp	2010-09-15 16:33:41.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/LaTeXFeatures.cpp	2010-09-18 12:00

Re: When preview is on

[Ronen Abravanel]

Is there a good reason no to do that change?


On Sun, Sep 19, 2010 at 4:09 PM, Pavel Sanda sa...@lyx.org wrote:

 Ronen Abravanel wrote:
  It seems that that simple patch do the trick (Preview is rendered on
 Instant
  Preview - On OR No math..)

 yes i was expecting it...
 pavel

Re: Patch: Diagram inset

[Ronen Abravanel]

I'll need a password for the wiki..

Thanks,
Ronen.

On Sun, Sep 19, 2010 at 6:46 PM, Pavel Sanda sa...@lyx.org wrote:

 Pavel Sanda wrote:
  Ronen Abravanel wrote:
 
   (The only part changes now: The comment in Buffer.cpp)

 everything is in now.
 most probably you want to put some bullet into latex section of newinlyx20
 wiki.

  also post the example file...
 pave

Re: Patch: Diagram inset

[Ronen Abravanel]

On Sun, Sep 19, 2010 at 3:35 AM, Pavel Sanda <sa...@lyx.org> wrote:

> Ronen Abravanel wrote:
> > Pavel -- Thanks. I removed big portion of the code that was not needed.
>
> good news
>
> > I can refactor both XYMatrix and Diagram class to have one common base
> > class, but it will take me a while. How urgent things should be ready for
> > 2.0?
>
> personally i would prefer not to touch XYMatrix ;)
> (basically because i dont know all its features and can't test whether we
> killed something...)
>
> so my proposal was rather that Diagram would be child of XYMatrix,
> althought i
> understand the philosophical point behind common virtual class.
> so in case other devs are not against, i would choose the simpler route...
>
> but as i have written before the class is so small that i would accept
> even the current version if the inheritance bussiness makes things
> complicated ;)
>
> > +def revert_diagram(document):
> > +  i = 0
> > +  re_diagram = re.compile(r'\\begin_inset Formula .*\\Diagram',
> re.DOTALL)
> > +  while True:
> > +i = find_token(document.body, '\\begin_inset Formula', i)
> > +if i == -1:
> > +  print "returning"
>
> debug output is not needed
>
> > +  return
> > +j = find_end_of_inset(document.body, i)
> > +if j == -1:
> > +print "Melformed document!"
>
> typo
>
> > +return
> > +m = re_diagram.search("\n".join(document.body[i:j]))
>
> i'm surprised about this newline, but you are right its there.
> strange. i still think the postscript output will be the same
> but who knows...
>
> > + * \file InsetMathDiagram.h
> > + * This file is part of LyX, the document processor.
> > + * Licence details can be found in the file COPYING.
> > + *
> > + * \author André Pönitz
> > +* \author Ronen Abravanel
>
> whitespace
>
> pavel
>
diff -rupN lyx-2.0.0alpha6/lib/lyx2lyx/lyx_2_0.py lyx-2.0.0alpha6_feynFinal/lib/lyx2lyx/lyx_2_0.py
--- lyx-2.0.0alpha6/lib/lyx2lyx/lyx_2_0.py	2010-09-15 16:33:40.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/lib/lyx2lyx/lyx_2_0.py	2010-09-19 10:49:58.0 -0400
@@ -1568,7 +1568,6 @@ def revert_fontcolor(document):
+ ', ' + str(blueout) + '}\n'
+ '\\color{document_fontcolor}\n')
 
-
 def revert_shadedboxcolor(document):
 " Reverts shaded box color to preamble code "
 i = 0
@@ -2161,6 +2160,26 @@ def revert_rule(document):
   else:
 return
 
+def revert_diagram(document):
+  i = 0
+  re_diagram = re.compile(r'\\begin_inset Formula .*\\Diagram', re.DOTALL)
+  while True:
+i = find_token(document.body, '\\begin_inset Formula', i)
+if i == -1:
+  return
+j = find_end_of_inset(document.body, i)
+if j == -1:
+document.warning("Malformed LyX document: Can't find end of line inset.")
+return 
+m = re_diagram.search("\n".join(document.body[i:j]))
+if not m:
+  i += 1
+  continue
+add_to_preamble(document, "\\use_package{feyn}")
+# only need to do it once!
+return
+
+
 
 ##
 # Conversion hub
@@ -2221,10 +2240,12 @@ convert = [[346, []],
[397, [remove_Nameref]],
[398, []],
[399, [convert_mathdots]],
-   [400, [convert_rule]]
+   [400, [convert_rule]],
+   [401, []]
   ]
 
-revert =  [[399, [revert_rule]],
+revert =  [[400, [revert_diagram]],
+   [399, [revert_rule]],
[398, [revert_mathdots]],
[397, [revert_mathrsfs]],
[396, []],
diff -rupN lyx-2.0.0alpha6/src/Buffer.cpp lyx-2.0.0alpha6_feynFinal/src/Buffer.cpp
--- lyx-2.0.0alpha6/src/Buffer.cpp	2010-09-15 16:33:41.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/Buffer.cpp	2010-09-18 22:33:25.0 -0400
@@ -127,7 +127,7 @@ namespace {
 
 // Do not remove the comment below, so we get merge conflict in
 // independent branches. Instead add your own.
-int const LYX_FORMAT = 400; // uwestoehr: support for \rule
+int const LYX_FORMAT = 401; // uwestoehr: support for \rule \\Ronen: support for \Diagrasr
 
 typedef map<string, bool> DepClean;
 typedef map<docstring, pair > RefCache;
diff -rupN lyx-2.0.0alpha6/src/insets/InsetCode.h lyx-2.0.0alpha6_feynFinal/src/insets/InsetCode.h
--- lyx-2.0.0alpha6/src/insets/InsetCode.h	2010-09-15 16:33:43.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/insets/InsetCode.h	2010-09-18 21:22:40.0 -0400
@@ -223,6 +223,8 @@ enum InsetCode {
 	///
 	PREVIEW_CODE,
 	///
+	MATH_DIAGRAM_CODE, 
+	///
 	INSET_CODE_SIZE,
 };
 
diff -rupN lyx-2.0.0alpha6/src/insets/Inset.cpp lyx-2.0.0alpha6_feynFinal/src/insets/Inset.cpp
--- lyx-2.0.0alpha6/src/insets/Inset.cpp	2010-09-15 16:33:42

Re: When preview is on

[Ronen Abravanel]

It seems that that simple patch do the trick (Preview is rendered on Instant
Preview -> On OR No math..)


On Sun, Sep 19, 2010 at 3:48 AM, Pavel Sanda <sa...@lyx.org> wrote:

> Ronen Abravanel wrote:
> > Currently, in Lyx 2.0, there are 3 modes for preview:
> > * On -- Preview is working for math and preview-inset
> > * No math --
> > * Off
> >
> > My 1st question is what the different between "no math" and Off? what
> else
> > is previewed other than math and preview inset?
>
> for example external insets use this mechanism to render pictures
>
> > My second concern is the reason this mail is on the developers list: Is
> > there any reason no to separate the rendering of the preview-inset from
> > regular math? for 98 percent of my math -- I prefer it will not be
> rendered.
> > But for the other two percent -- the diagrams (either using \xymatrix,
> the
> > new \Diagram inset, or just plain-old ERT), I would really like to be
> > previewed.
> >
> > If it's some arbitrary decision, and you didn't thought it's important,
> I'll
> > be happy to try and do the change..
>
> original author is currently away... personally i have no problem with
> separating it.
> i guess that you would be happy to connect "no math" with your usecase?
>
> >(although i'll be happy for some
> > pointers, as I don't yet very familiar with lyx' code).
>
> for the insetpreview part, quick peek gives two possibly interesting
> commits 38890, 33890:
>
> git log --author=vfr |grep -A2 InsetPreview
>New file format for InsetPreview introduced in r38890.
>
>git-svn-id: 
> svn://svn.lyx.org/lyx/lyx-devel/tr...@33891a592a061-630c-0410-9148-cb99ea01b6c8
> --
>Introduce InsetPreview.
>
>git-svn-id: 
> svn://svn.lyx.org/lyx/lyx-devel/tr...@33890a592a061-630c-0410-9148-cb99ea01b6c8
>
> pavel
>
--- lyx-2.0.0alpha6_feyn/src/insets/InsetPreview.cpp	2010-09-15 16:33:43.0 -0400
+++ lyx-2.0.0alpha6/src/insets/InsetPreview.cpp	2010-09-19 11:56:12.0 -0400
@@ -78,7 +78,7 @@ void InsetPreview::preparePreview(DocIte
 
 bool InsetPreview::previewState(BufferView * bv) const
 {
-	if (!editing(bv) && RenderPreview::status() == LyXRC::PREVIEW_ON) {
+	if (!editing(bv) && (RenderPreview::status() == LyXRC::PREVIEW_ON || RenderPreview::status() == LyXRC::PREVIEW_NO_MATH)) {
 		graphics::PreviewImage const * pimage =
 			preview_->getPreviewImage(bv->buffer());
 		return pimage && pimage->image();

Re: Patch: Diagram inset

[Ronen Abravanel]

On Sun, Sep 19, 2010 at 11:46 AM, Richard Heck <rgh...@comcast.net> wrote:

> On 9/19/10 11:19 AM, Ronen Abravanel wrote:
>
>>
>> +def revert_diagram(document):
>> +  i = 0
>> +  re_diagram = re.compile(r'\\begin_inset Formula .*\\Diagram',
>> re.DOTALL)
>> +  while True:
>> +i = find_token(document.body, '\\begin_inset Formula', i)
>> +if i == -1:
>> +  return
>> +j = find_end_of_inset(document.body, i)
>> +if j == -1:
>> +document.warning("Malformed LyX document: Can't find end of line
>> inset.")
>>
>> +return
>> +m = re_diagram.search("\n".join(document.body[i:j]))
>> +if not m:
>> +  i += 1
>> +  continue
>> +add_to_preamble(document, "\\use_package{feyn}")
>> +# only need to do it once!
>> +return
>> +
>> +
>>
>>
>>
> Like Pavel, I'm a bit puzzled by this. I see the newline in
> InsetXYMatrix::write() and now in your code, but I hadn't realized we put
> newlines into the math stuff. Anyway, better not to assume they're not
> there.
>
I don't understand how all this mechanism works. I just assume the XTMatrix
works, and then change the things I do understand.


>
>  +int const LYX_FORMAT = 401; // uwestoehr: support for \rule \\Ronen:
>> support for \Diagrasr
>>
>>
>>
> You can take Uwe's comment out, which applied to format 400, and just have
> yours. The main thing is just to have a comment there.
>
> Otherwise looks fine to me, though I'm not expert on the math stuff.
>
> rh
>

(The only part changes now: The comment in Buffer.cpp)
diff -rupN lyx-2.0.0alpha6/lib/lyx2lyx/lyx_2_0.py lyx-2.0.0alpha6_feynFinal/lib/lyx2lyx/lyx_2_0.py
--- lyx-2.0.0alpha6/lib/lyx2lyx/lyx_2_0.py	2010-09-15 16:33:40.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/lib/lyx2lyx/lyx_2_0.py	2010-09-19 10:49:58.0 -0400
@@ -1568,7 +1568,6 @@ def revert_fontcolor(document):
+ ', ' + str(blueout) + '}\n'
+ '\\color{document_fontcolor}\n')
 
-
 def revert_shadedboxcolor(document):
 " Reverts shaded box color to preamble code "
 i = 0
@@ -2161,6 +2160,26 @@ def revert_rule(document):
   else:
 return
 
+def revert_diagram(document):
+  i = 0
+  re_diagram = re.compile(r'\\begin_inset Formula .*\\Diagram', re.DOTALL)
+  while True:
+i = find_token(document.body, '\\begin_inset Formula', i)
+if i == -1:
+  return
+j = find_end_of_inset(document.body, i)
+if j == -1:
+document.warning("Malformed LyX document: Can't find end of line inset.")
+return 
+m = re_diagram.search("\n".join(document.body[i:j]))
+if not m:
+  i += 1
+  continue
+add_to_preamble(document, "\\use_package{feyn}")
+# only need to do it once!
+return
+
+
 
 ##
 # Conversion hub
@@ -2221,10 +2240,12 @@ convert = [[346, []],
[397, [remove_Nameref]],
[398, []],
[399, [convert_mathdots]],
-   [400, [convert_rule]]
+   [400, [convert_rule]],
+   [401, []]
   ]
 
-revert =  [[399, [revert_rule]],
+revert =  [[400, [revert_diagram]],
+   [399, [revert_rule]],
[398, [revert_mathdots]],
[397, [revert_mathrsfs]],
[396, []],
diff -rupN lyx-2.0.0alpha6/src/Buffer.cpp lyx-2.0.0alpha6_feynFinal/src/Buffer.cpp
--- lyx-2.0.0alpha6/src/Buffer.cpp	2010-09-15 16:33:41.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/Buffer.cpp	2010-09-18 22:33:25.0 -0400
@@ -127,7 +127,7 @@ namespace {
 
 // Do not remove the comment below, so we get merge conflict in
 // independent branches. Instead add your own.
-int const LYX_FORMAT = 400; // uwestoehr: support for \rule
+int const LYX_FORMAT = 401; // Ronen: support for \Diagram
 
 typedef map<string, bool> DepClean;
 typedef map<docstring, pair > RefCache;
diff -rupN lyx-2.0.0alpha6/src/insets/InsetCode.h lyx-2.0.0alpha6_feynFinal/src/insets/InsetCode.h
--- lyx-2.0.0alpha6/src/insets/InsetCode.h	2010-09-15 16:33:43.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/insets/InsetCode.h	2010-09-18 21:22:40.0 -0400
@@ -223,6 +223,8 @@ enum InsetCode {
 	///
 	PREVIEW_CODE,
 	///
+	MATH_DIAGRAM_CODE, 
+	///
 	INSET_CODE_SIZE,
 };
 
diff -rupN lyx-2.0.0alpha6/src/insets/Inset.cpp lyx-2.0.0alpha6_feynFinal/src/insets/Inset.cpp
--- lyx-2.0.0alpha6/src/insets/Inset.cpp	2010-09-15 16:33:42.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/insets/Inset.cpp	2010-09-18 21:23:37.0 -0400
@@ -168,6 +168,7 @@ static void build_translator()
 	insetnames[MATH_XARROW_CODE] = InsetName("mathxarrow");
 	insetnames[MATH_XYARROW_CODE] = InsetName("mathxyarrow");
 	insetnames[MATH_XYMATRIX_CO

Re: When preview is on

[Ronen Abravanel]

Is there a good reason no to do that change?


On Sun, Sep 19, 2010 at 4:09 PM, Pavel Sanda <sa...@lyx.org> wrote:

> Ronen Abravanel wrote:
> > It seems that that simple patch do the trick (Preview is rendered on
> Instant
> > Preview -> On OR No math..)
>
> yes i was expecting it...
> pavel
>

Re: Patch: Diagram inset

[Ronen Abravanel]

I'll need a password for the wiki..

Thanks,
Ronen.

On Sun, Sep 19, 2010 at 6:46 PM, Pavel Sanda <sa...@lyx.org> wrote:

> Pavel Sanda wrote:
> > Ronen Abravanel wrote:
> >
> > > (The only part changes now: The comment in Buffer.cpp)
>
> everything is in now.
> most probably you want to put some bullet into latex section of newinlyx20
> wiki.
>
> > also post the example file...
> >pave
>

Patch: Diagram inset

[Ronen Abravanel]

Hello,

I created a patch that adds a Feynman diagram inset into lyx. The inset is
based on the inst Diagram in the package feyn (
http://www.ctan.org/tex-archive/fonts/feyn/ ) . The inset is meant to
replace the hack described in the 3rd section of the following document:
http://www.technion.ac.il/~ronen/latex/lyx_quantum.pdf
http://www.technion.ac.il/~ronen/latex/lyx_quantum.lyx

The patch is based on 2.0 Alpha 6, and based mostly on copied code from
XYMatrix inset.

I will appreciate comments regarding the patch. Is it too late to include it
in 2.0?

Thanks,
Ronen Abravanel
diff -rupN lyx-2.0.0alpha6/src/insets/InsetCode.h lyx-2.0.0alpha6_feynFinal/src/insets/InsetCode.h
--- lyx-2.0.0alpha6/src/insets/InsetCode.h	2010-09-15 16:33:43.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/insets/InsetCode.h	2010-09-18 12:00:16.0 -0400
@@ -223,6 +223,8 @@ enum InsetCode {
 	///
 	PREVIEW_CODE,
 	///
+	MATH_DIAGRAM_CODE, //RCHANGE
+	///
 	INSET_CODE_SIZE,
 };
 
diff -rupN lyx-2.0.0alpha6/src/insets/Inset.cpp lyx-2.0.0alpha6_feynFinal/src/insets/Inset.cpp
--- lyx-2.0.0alpha6/src/insets/Inset.cpp	2010-09-15 16:33:42.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/insets/Inset.cpp	2010-09-18 12:00:16.0 -0400
@@ -168,6 +168,7 @@ static void build_translator()
 	insetnames[MATH_XARROW_CODE] = InsetName(mathxarrow);
 	insetnames[MATH_XYARROW_CODE] = InsetName(mathxyarrow);
 	insetnames[MATH_XYMATRIX_CODE] = InsetName(mathxymatrix);
+	insetnames[MATH_DIAGRAM_CODE] = InsetName(mathdyagram);
 	insetnames[MATH_MACRO_CODE] = InsetName(mathmacro);
 
 	passed = true;
diff -rupN lyx-2.0.0alpha6/src/LaTeXFeatures.cpp lyx-2.0.0alpha6_feynFinal/src/LaTeXFeatures.cpp
--- lyx-2.0.0alpha6/src/LaTeXFeatures.cpp	2010-09-15 16:33:41.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/LaTeXFeatures.cpp	2010-09-18 12:00:16.0 -0400
@@ -746,6 +746,9 @@ string const LaTeXFeatures::getPackages(
 	if (mustProvide(xy))
 		packages  \\usepackage[all]{xy}\n;
 
+	if (mustProvide(feyn))
+		packages  \\usepackage{feyn}\n; //Diagram
+
 	if (mustProvide(ulem))
 		packages  \\PassOptionsToPackage{normalem}{ulem}\n
 			\\usepackage{ulem}\n;
diff -rupN lyx-2.0.0alpha6/src/lyxmathed.cpp lyx-2.0.0alpha6_feynFinal/src/lyxmathed.cpp
--- lyx-2.0.0alpha6/src/lyxmathed.cpp	2010-09-16 04:26:35.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/lyxmathed.cpp	2010-09-18 12:00:16.0 -0400
@@ -52,6 +52,7 @@
 #include mathed/InsetMathUnknown.cpp 
 #include mathed/InsetMathXArrow.cpp 
 #include mathed/InsetMathXYMatrix.cpp 
+#include mathed/InsetMathDiagram.cpp
 #include mathed/MathAtom.cpp 
 #include mathed/MathAutoCorrect.cpp 
 #include mathed/MathData.cpp 
diff -rupN lyx-2.0.0alpha6/src/Makefile.am lyx-2.0.0alpha6_feynFinal/src/Makefile.am
--- lyx-2.0.0alpha6/src/Makefile.am	2010-09-15 16:33:42.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/Makefile.am	2010-09-18 12:00:16.0 -0400
@@ -409,6 +409,7 @@ SOURCEFILESMATHED = \
 	mathed/InsetMathUnknown.cpp \
 	mathed/InsetMathXArrow.cpp \
 	mathed/InsetMathXYMatrix.cpp \
+	mathed/InsetMathDiagram.cpp \
 	mathed/MathAtom.cpp \
 	mathed/MathAutoCorrect.cpp \
 	mathed/MathData.cpp \
@@ -474,6 +475,7 @@ HEADERFILESMATHED = \
 	mathed/InsetMathUnknown.h \
 	mathed/InsetMathXArrow.h \
 	mathed/InsetMathXYMatrix.h \
+	mathed/InsetMathDiagram.h \
 	mathed/MathAtom.h \
 	mathed/MathAutoCorrect.h \
 	mathed/MathData.h \
diff -rupN lyx-2.0.0alpha6/src/mathed/InsetMathDiagram.cpp lyx-2.0.0alpha6_feynFinal/src/mathed/InsetMathDiagram.cpp
--- lyx-2.0.0alpha6/src/mathed/InsetMathDiagram.cpp	1969-12-31 19:00:00.0 -0500
+++ lyx-2.0.0alpha6_feynFinal/src/mathed/InsetMathDiagram.cpp	2010-09-18 12:00:16.0 -0400
@@ -0,0 +1,143 @@
+/**
+ * \file InsetMathDiagram.cpp
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author André Pönitz, Ronen Abravanel
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+
+#include config.h
+
+#include InsetMathDiagram.h
+
+#include LaTeXFeatures.h
+#include MathStream.h
+
+#include ostream
+
+namespace lyx {
+
+
+InsetMathDiagram::InsetMathDiagram(Buffer * buf, Length const  s, char c,
+	bool e) : InsetMathGrid(buf, 1, 1), spacing_(s), spacing_code_(c),
+	equal_spacing_(e)
+{
+}
+
+
+Inset * InsetMathDiagram::clone() const
+{
+	return new InsetMathDiagram(*this);
+}
+
+
+int InsetMathDiagram::colsep() const
+{
+	return 10;
+}
+
+
+int InsetMathDiagram::rowsep() const
+{
+	return 10;
+}
+
+
+void InsetMathDiagram::metrics(MetricsInfo  mi, Dimension  dim) const
+{
+	if (mi.base.style == LM_ST_DISPLAY)
+		mi.base.style = LM_ST_TEXT;
+	InsetMathGrid::metrics(mi, dim);
+}
+
+
+void InsetMathDiagram::write(WriteStream  os) const
+{
+	MathEnsurer ensurer(os);
+	os  \\Diagram;
+	if (equal_spacing_) {
+		os  @!;
+		switch (spacing_code_) {
+		case '0':
+		case 'R':
+		case 'C':
+			os  spacing_code_;
+		}
+	} else {
+		switch (spacing_code_) {
+		case 'R':
+		case 'C

Re: Patch: Diagram inset

[Ronen Abravanel]

);
 	insetnames[MATH_XYARROW_CODE] = InsetName(mathxyarrow);
 	insetnames[MATH_XYMATRIX_CODE] = InsetName(mathxymatrix);
+	insetnames[MATH_DIAGRAM_CODE] = InsetName(mathdiagram);
 	insetnames[MATH_MACRO_CODE] = InsetName(mathmacro);
 
 	passed = true;
diff -rupN lyx-2.0.0alpha6/src/LaTeXFeatures.cpp lyx-2.0.0alpha6_feynFinal/src/LaTeXFeatures.cpp
--- lyx-2.0.0alpha6/src/LaTeXFeatures.cpp	2010-09-15 16:33:41.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/LaTeXFeatures.cpp	2010-09-18 12:00:16.0 -0400
@@ -746,6 +746,9 @@ string const LaTeXFeatures::getPackages(
 	if (mustProvide(xy))
 		packages  \\usepackage[all]{xy}\n;
 
+	if (mustProvide(feyn))
+		packages  \\usepackage{feyn}\n; //Diagram
+
 	if (mustProvide(ulem))
 		packages  \\PassOptionsToPackage{normalem}{ulem}\n
 			\\usepackage{ulem}\n;
diff -rupN lyx-2.0.0alpha6/src/Makefile.am lyx-2.0.0alpha6_feynFinal/src/Makefile.am
--- lyx-2.0.0alpha6/src/Makefile.am	2010-09-15 16:33:42.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/Makefile.am	2010-09-18 12:00:16.0 -0400
@@ -409,6 +409,7 @@ SOURCEFILESMATHED = \
 	mathed/InsetMathUnknown.cpp \
 	mathed/InsetMathXArrow.cpp \
 	mathed/InsetMathXYMatrix.cpp \
+	mathed/InsetMathDiagram.cpp \
 	mathed/MathAtom.cpp \
 	mathed/MathAutoCorrect.cpp \
 	mathed/MathData.cpp \
@@ -474,6 +475,7 @@ HEADERFILESMATHED = \
 	mathed/InsetMathUnknown.h \
 	mathed/InsetMathXArrow.h \
 	mathed/InsetMathXYMatrix.h \
+	mathed/InsetMathDiagram.h \
 	mathed/MathAtom.h \
 	mathed/MathAutoCorrect.h \
 	mathed/MathData.h \
diff -rupN lyx-2.0.0alpha6/src/mathed/InsetMathDiagram.cpp lyx-2.0.0alpha6_feynFinal/src/mathed/InsetMathDiagram.cpp
--- lyx-2.0.0alpha6/src/mathed/InsetMathDiagram.cpp	1969-12-31 19:00:00.0 -0500
+++ lyx-2.0.0alpha6_feynFinal/src/mathed/InsetMathDiagram.cpp	2010-09-18 22:19:13.0 -0400
@@ -0,0 +1,96 @@
+/**
+ * \file InsetMathDiagram.cpp
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author André Pönitz
+ * \author Ronen Abravanel
+*
+ * Full author contact details are available in file CREDITS.
+ */
+
+#include config.h
+
+#include InsetMathDiagram.h
+
+#include LaTeXFeatures.h
+#include MathStream.h
+
+#include ostream
+
+namespace lyx {
+
+
+InsetMathDiagram::InsetMathDiagram(Buffer * buf, Length const  s, char c,
+	bool e) : InsetMathGrid(buf, 1, 1)
+{
+}
+
+
+Inset * InsetMathDiagram::clone() const
+{
+	return new InsetMathDiagram(*this);
+}
+
+
+int InsetMathDiagram::colsep() const
+{
+	return 10;
+}
+
+
+int InsetMathDiagram::rowsep() const
+{
+	return 10;
+}
+
+
+void InsetMathDiagram::metrics(MetricsInfo  mi, Dimension  dim) const
+{
+	if (mi.base.style == LM_ST_DISPLAY)
+		mi.base.style = LM_ST_TEXT;
+	InsetMathGrid::metrics(mi, dim);
+}
+
+
+void InsetMathDiagram::write(WriteStream  os) const
+{
+	MathEnsurer ensurer(os);
+	os  \\Diagram;
+	os  '{';
+	InsetMathGrid::write(os);
+	os  }\n;
+}
+
+
+void InsetMathDiagram::infoize(odocstream  os) const
+{
+	os  Diagram ;
+	InsetMathGrid::infoize(os);
+}
+
+
+void InsetMathDiagram::normalize(NormalStream  os) const
+{
+	os  [Diagram ;
+	InsetMathGrid::normalize(os);
+	os  ']';
+}
+
+
+void InsetMathDiagram::maple(MapleStream  os) const
+{
+	os  Diagram(;
+	InsetMathGrid::maple(os);
+	os  ')';
+}
+
+
+void InsetMathDiagram::validate(LaTeXFeatures  features) const
+{
+	features.require(feyn);
+	InsetMathGrid::validate(features);
+}
+
+
+} // namespace lyx
diff -rupN lyx-2.0.0alpha6/src/mathed/InsetMathDiagram.h lyx-2.0.0alpha6_feynFinal/src/mathed/InsetMathDiagram.h
--- lyx-2.0.0alpha6/src/mathed/InsetMathDiagram.h	1969-12-31 19:00:00.0 -0500
+++ lyx-2.0.0alpha6_feynFinal/src/mathed/InsetMathDiagram.h	2010-09-18 21:49:11.0 -0400
@@ -0,0 +1,61 @@
+// -*- C++ -*-
+/**
+ * \file InsetMathDiagram.h
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author André Pönitz
+* \author Ronen Abravanel
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+
+#ifndef MATH_DIAGRAM_H
+#define MATH_DIAGRAM_H
+
+#include Length.h
+#include InsetMathGrid.h
+
+
+namespace lyx {
+
+
+class InsetMathDiagram : public InsetMathGrid {
+public:
+	///
+	InsetMathDiagram(Buffer * buf, Length const  = Length(), char c = '\0',
+		bool equal_spacing = false);
+	///
+	void metrics(MetricsInfo , Dimension ) const;
+	///
+	InsetMathDiagram const * asDiagramInset() const { return this; }
+	///
+	virtual int colsep() const;
+	///
+	virtual int rowsep() const;
+
+	///
+	void normalize();
+	///
+	void write(WriteStream  os) const;
+	///
+	void infoize(odocstream  os) const;
+	///
+	void normalize(NormalStream ) const;
+	///
+	void maple(MapleStream ) const;
+	///
+	void validate(LaTeXFeatures  features) const;
+	///
+	InsetCode lyxCode() const { return MATH_DIAGRAM_CODE; }
+
+private:
+	///
+	virtual Inset * clone() const;
+
+};
+
+
+
+} // namespace lyx
+#endif
diff -rupN lyx-2.0.0alpha6/src/mathed

When preview is on

[Ronen Abravanel]

Currently, in Lyx 2.0, there are 3 modes for preview:
* On -- Preview is working for math and preview-inset
* No math --
* Off

My 1st question is what the different between no math and Off? what else
is previewed other than math and preview inset?

My second concern is the reason this mail is on the developers list: Is
there any reason no to separate the rendering of the preview-inset from
regular math? for 98 percent of my math -- I prefer it will not be rendered.
But for the other two percent -- the diagrams (either using \xymatrix, the
new \Diagram inset, or just plain-old ERT), I would really like to be
previewed.

If it's some arbitrary decision, and you didn't thought it's important, I'll
be happy to try and do the change.. (although i'll be happy for some
pointers, as I don't yet very familiar with lyx' code).


Ronen.

Patch: Diagram inset

[Ronen Abravanel]

Hello,

I created a patch that adds a Feynman diagram inset into lyx. The inset is
based on the inst "Diagram" in the package feyn (
http://www.ctan.org/tex-archive/fonts/feyn/ ) . The inset is meant to
replace the hack described in the 3rd section of the following document:
http://www.technion.ac.il/~ronen/latex/lyx_quantum.pdf
http://www.technion.ac.il/~ronen/latex/lyx_quantum.lyx

The patch is based on 2.0 Alpha 6, and based mostly on copied code from
XYMatrix inset.

I will appreciate comments regarding the patch. Is it too late to include it
in 2.0?

Thanks,
Ronen Abravanel
diff -rupN lyx-2.0.0alpha6/src/insets/InsetCode.h lyx-2.0.0alpha6_feynFinal/src/insets/InsetCode.h
--- lyx-2.0.0alpha6/src/insets/InsetCode.h	2010-09-15 16:33:43.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/insets/InsetCode.h	2010-09-18 12:00:16.0 -0400
@@ -223,6 +223,8 @@ enum InsetCode {
 	///
 	PREVIEW_CODE,
 	///
+	MATH_DIAGRAM_CODE, //RCHANGE
+	///
 	INSET_CODE_SIZE,
 };
 
diff -rupN lyx-2.0.0alpha6/src/insets/Inset.cpp lyx-2.0.0alpha6_feynFinal/src/insets/Inset.cpp
--- lyx-2.0.0alpha6/src/insets/Inset.cpp	2010-09-15 16:33:42.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/insets/Inset.cpp	2010-09-18 12:00:16.0 -0400
@@ -168,6 +168,7 @@ static void build_translator()
 	insetnames[MATH_XARROW_CODE] = InsetName("mathxarrow");
 	insetnames[MATH_XYARROW_CODE] = InsetName("mathxyarrow");
 	insetnames[MATH_XYMATRIX_CODE] = InsetName("mathxymatrix");
+	insetnames[MATH_DIAGRAM_CODE] = InsetName("mathdyagram");
 	insetnames[MATH_MACRO_CODE] = InsetName("mathmacro");
 
 	passed = true;
diff -rupN lyx-2.0.0alpha6/src/LaTeXFeatures.cpp lyx-2.0.0alpha6_feynFinal/src/LaTeXFeatures.cpp
--- lyx-2.0.0alpha6/src/LaTeXFeatures.cpp	2010-09-15 16:33:41.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/LaTeXFeatures.cpp	2010-09-18 12:00:16.0 -0400
@@ -746,6 +746,9 @@ string const LaTeXFeatures::getPackages(
 	if (mustProvide("xy"))
 		packages << "\\usepackage[all]{xy}\n";
 
+	if (mustProvide("feyn"))
+		packages << "\\usepackage{feyn}\n"; //Diagram
+
 	if (mustProvide("ulem"))
 		packages << "\\PassOptionsToPackage{normalem}{ulem}\n"
 			"\\usepackage{ulem}\n";
diff -rupN lyx-2.0.0alpha6/src/lyxmathed.cpp lyx-2.0.0alpha6_feynFinal/src/lyxmathed.cpp
--- lyx-2.0.0alpha6/src/lyxmathed.cpp	2010-09-16 04:26:35.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/lyxmathed.cpp	2010-09-18 12:00:16.0 -0400
@@ -52,6 +52,7 @@
 #include "mathed/InsetMathUnknown.cpp" 
 #include "mathed/InsetMathXArrow.cpp" 
 #include "mathed/InsetMathXYMatrix.cpp" 
+#include "mathed/InsetMathDiagram.cpp"
 #include "mathed/MathAtom.cpp" 
 #include "mathed/MathAutoCorrect.cpp" 
 #include "mathed/MathData.cpp" 
diff -rupN lyx-2.0.0alpha6/src/Makefile.am lyx-2.0.0alpha6_feynFinal/src/Makefile.am
--- lyx-2.0.0alpha6/src/Makefile.am	2010-09-15 16:33:42.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/Makefile.am	2010-09-18 12:00:16.0 -0400
@@ -409,6 +409,7 @@ SOURCEFILESMATHED = \
 	mathed/InsetMathUnknown.cpp \
 	mathed/InsetMathXArrow.cpp \
 	mathed/InsetMathXYMatrix.cpp \
+	mathed/InsetMathDiagram.cpp \
 	mathed/MathAtom.cpp \
 	mathed/MathAutoCorrect.cpp \
 	mathed/MathData.cpp \
@@ -474,6 +475,7 @@ HEADERFILESMATHED = \
 	mathed/InsetMathUnknown.h \
 	mathed/InsetMathXArrow.h \
 	mathed/InsetMathXYMatrix.h \
+	mathed/InsetMathDiagram.h \
 	mathed/MathAtom.h \
 	mathed/MathAutoCorrect.h \
 	mathed/MathData.h \
diff -rupN lyx-2.0.0alpha6/src/mathed/InsetMathDiagram.cpp lyx-2.0.0alpha6_feynFinal/src/mathed/InsetMathDiagram.cpp
--- lyx-2.0.0alpha6/src/mathed/InsetMathDiagram.cpp	1969-12-31 19:00:00.0 -0500
+++ lyx-2.0.0alpha6_feynFinal/src/mathed/InsetMathDiagram.cpp	2010-09-18 12:00:16.0 -0400
@@ -0,0 +1,143 @@
+/**
+ * \file InsetMathDiagram.cpp
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author André Pönitz, Ronen Abravanel
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+
+#include 
+
+#include "InsetMathDiagram.h"
+
+#include "LaTeXFeatures.h"
+#include "MathStream.h"
+
+#include 
+
+namespace lyx {
+
+
+InsetMathDiagram::InsetMathDiagram(Buffer * buf, Length const & s, char c,
+	bool e) : InsetMathGrid(buf, 1, 1), spacing_(s), spacing_code_(c),
+	equal_spacing_(e)
+{
+}
+
+
+Inset * InsetMathDiagram::clone() const
+{
+	return new InsetMathDiagram(*this);
+}
+
+
+int InsetMathDiagram::colsep() const
+{
+	return 10;
+}
+
+
+int InsetMathDiagram::rowsep() const
+{
+	return 10;
+}
+
+
+void InsetMathDiagram::metrics(MetricsInfo & mi, Dimension & dim) const
+{
+	if (mi.base.style == LM_ST_DISPLAY)
+		mi.base.style = LM_ST_TEXT;
+	InsetMathGrid::metrics(mi, di

Re: Patch: Diagram inset

[Ronen Abravanel]

s/Inset.cpp
--- lyx-2.0.0alpha6/src/insets/Inset.cpp	2010-09-15 16:33:42.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/insets/Inset.cpp	2010-09-18 21:23:37.0 -0400
@@ -168,6 +168,7 @@ static void build_translator()
 	insetnames[MATH_XARROW_CODE] = InsetName("mathxarrow");
 	insetnames[MATH_XYARROW_CODE] = InsetName("mathxyarrow");
 	insetnames[MATH_XYMATRIX_CODE] = InsetName("mathxymatrix");
+	insetnames[MATH_DIAGRAM_CODE] = InsetName("mathdiagram");
 	insetnames[MATH_MACRO_CODE] = InsetName("mathmacro");
 
 	passed = true;
diff -rupN lyx-2.0.0alpha6/src/LaTeXFeatures.cpp lyx-2.0.0alpha6_feynFinal/src/LaTeXFeatures.cpp
--- lyx-2.0.0alpha6/src/LaTeXFeatures.cpp	2010-09-15 16:33:41.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/LaTeXFeatures.cpp	2010-09-18 12:00:16.0 -0400
@@ -746,6 +746,9 @@ string const LaTeXFeatures::getPackages(
 	if (mustProvide("xy"))
 		packages << "\\usepackage[all]{xy}\n";
 
+	if (mustProvide("feyn"))
+		packages << "\\usepackage{feyn}\n"; //Diagram
+
 	if (mustProvide("ulem"))
 		packages << "\\PassOptionsToPackage{normalem}{ulem}\n"
 			"\\usepackage{ulem}\n";
diff -rupN lyx-2.0.0alpha6/src/Makefile.am lyx-2.0.0alpha6_feynFinal/src/Makefile.am
--- lyx-2.0.0alpha6/src/Makefile.am	2010-09-15 16:33:42.0 -0400
+++ lyx-2.0.0alpha6_feynFinal/src/Makefile.am	2010-09-18 12:00:16.0 -0400
@@ -409,6 +409,7 @@ SOURCEFILESMATHED = \
 	mathed/InsetMathUnknown.cpp \
 	mathed/InsetMathXArrow.cpp \
 	mathed/InsetMathXYMatrix.cpp \
+	mathed/InsetMathDiagram.cpp \
 	mathed/MathAtom.cpp \
 	mathed/MathAutoCorrect.cpp \
 	mathed/MathData.cpp \
@@ -474,6 +475,7 @@ HEADERFILESMATHED = \
 	mathed/InsetMathUnknown.h \
 	mathed/InsetMathXArrow.h \
 	mathed/InsetMathXYMatrix.h \
+	mathed/InsetMathDiagram.h \
 	mathed/MathAtom.h \
 	mathed/MathAutoCorrect.h \
 	mathed/MathData.h \
diff -rupN lyx-2.0.0alpha6/src/mathed/InsetMathDiagram.cpp lyx-2.0.0alpha6_feynFinal/src/mathed/InsetMathDiagram.cpp
--- lyx-2.0.0alpha6/src/mathed/InsetMathDiagram.cpp	1969-12-31 19:00:00.0 -0500
+++ lyx-2.0.0alpha6_feynFinal/src/mathed/InsetMathDiagram.cpp	2010-09-18 22:19:13.0 -0400
@@ -0,0 +1,96 @@
+/**
+ * \file InsetMathDiagram.cpp
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author André Pönitz
+ * \author Ronen Abravanel
+*
+ * Full author contact details are available in file CREDITS.
+ */
+
+#include 
+
+#include "InsetMathDiagram.h"
+
+#include "LaTeXFeatures.h"
+#include "MathStream.h"
+
+#include 
+
+namespace lyx {
+
+
+InsetMathDiagram::InsetMathDiagram(Buffer * buf, Length const & s, char c,
+	bool e) : InsetMathGrid(buf, 1, 1)
+{
+}
+
+
+Inset * InsetMathDiagram::clone() const
+{
+	return new InsetMathDiagram(*this);
+}
+
+
+int InsetMathDiagram::colsep() const
+{
+	return 10;
+}
+
+
+int InsetMathDiagram::rowsep() const
+{
+	return 10;
+}
+
+
+void InsetMathDiagram::metrics(MetricsInfo & mi, Dimension & dim) const
+{
+	if (mi.base.style == LM_ST_DISPLAY)
+		mi.base.style = LM_ST_TEXT;
+	InsetMathGrid::metrics(mi, dim);
+}
+
+
+void InsetMathDiagram::write(WriteStream & os) const
+{
+	MathEnsurer ensurer(os);
+	os << "\\Diagram";
+	os << '{';
+	InsetMathGrid::write(os);
+	os << "}\n";
+}
+
+
+void InsetMathDiagram::infoize(odocstream & os) const
+{
+	os << "Diagram ";
+	InsetMathGrid::infoize(os);
+}
+
+
+void InsetMathDiagram::normalize(NormalStream & os) const
+{
+	os << "[Diagram ";
+	InsetMathGrid::normalize(os);
+	os << ']';
+}
+
+
+void InsetMathDiagram::maple(MapleStream & os) const
+{
+	os << "Diagram(";
+	InsetMathGrid::maple(os);
+	os << ')';
+}
+
+
+void InsetMathDiagram::validate(LaTeXFeatures & features) const
+{
+	features.require("feyn");
+	InsetMathGrid::validate(features);
+}
+
+
+} // namespace lyx
diff -rupN lyx-2.0.0alpha6/src/mathed/InsetMathDiagram.h lyx-2.0.0alpha6_feynFinal/src/mathed/InsetMathDiagram.h
--- lyx-2.0.0alpha6/src/mathed/InsetMathDiagram.h	1969-12-31 19:00:00.0 -0500
+++ lyx-2.0.0alpha6_feynFinal/src/mathed/InsetMathDiagram.h	2010-09-18 21:49:11.0 -0400
@@ -0,0 +1,61 @@
+// -*- C++ -*-
+/**
+ * \file InsetMathDiagram.h
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author André Pönitz
+* \author Ronen Abravanel
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+
+#ifndef MATH_DIAGRAM_H
+#define MATH_DIAGRAM_H
+
+#include "Length.h"
+#include "InsetMathGrid.h"
+
+
+namespace lyx {
+
+
+class InsetMathDiagram : public InsetMathGrid {
+public:
+	///
+	InsetMathDiagram(Buffer * buf, Length const & = Length(), char c = '

When preview is on

[Ronen Abravanel]

Currently, in Lyx 2.0, there are 3 modes for preview:
* On -- Preview is working for math and preview-inset
* No math --
* Off

My 1st question is what the different between "no math" and Off? what else
is previewed other than math and preview inset?

My second concern is the reason this mail is on the developers list: Is
there any reason no to separate the rendering of the preview-inset from
regular math? for 98 percent of my math -- I prefer it will not be rendered.
But for the other two percent -- the diagrams (either using \xymatrix, the
new \Diagram inset, or just plain-old ERT), I would really like to be
previewed.

If it's some arbitrary decision, and you didn't thought it's important, I'll
be happy to try and do the change.. (although i'll be happy for some
pointers, as I don't yet very familiar with lyx' code).


Ronen.

Re: English section names in a Hebrew article: TOC bug

[Ronen Abravanel]

On Sun, May 30, 2010 at 2:14 AM, Enrico Forestieri for...@lyx.org wrote:

 On Sat, May 29, 2010 at 09:37:15PM +0300, Amir Rachum wrote:

  This works, and I already use this sort of workaround (only with an empty
  math-mode).
  However, when I do this, it prints the section header (in the section
  itself) aligned to the right side of the page instead of the left, and it
  looks really bad (people have commented to me on how it looks).

 You could try using the Short Title option in order to force the
 exact appearance you want in the toc. Does the attached example work?

 --
 Enrico


Works grate with LyX 1.64 \ Ivritex on ubuntu 9.10 :-)

-Ronen

Re: English section names in a Hebrew article: TOC bug

[Ronen Abravanel]

On Sun, May 30, 2010 at 2:14 AM, Enrico Forestieri  wrote:

> On Sat, May 29, 2010 at 09:37:15PM +0300, Amir Rachum wrote:
>
> > This works, and I already use this sort of workaround (only with an empty
> > math-mode).
> > However, when I do this, it prints the section header (in the section
> > itself) aligned to the right side of the page instead of the left, and it
> > looks really bad (people have commented to me on how it looks).
>
> You could try using the "Short Title" option in order to force the
> exact appearance you want in the toc. Does the attached example work?
>
> --
> Enrico
>

Works grate with LyX 1.64 \ Ivritex on ubuntu 9.10 :-)

-Ronen

Re: I want to add Feyn support to LyX, and I need some guidance

[Ronen Abravanel]

On Wed, Dec 9, 2009 at 1:13 AM, Pavel Sanda sa...@lyx.org wrote:

 Ronen Abravanel wrote:
  One case:
  \feyn{fs f gl f glu f fs}
 
  I can't add spaces.. And they are important

 argh.. and ctrl+space can't be used? is suppose no :(
 in any case this looks like that you want to enhance math inset
 and not to create completely new one inset.

 Now,
\renewcommand{\text}{\feyn}
will work, but it disable my \text.
When I'm saying inset, I mean things like \text ore \matrix, not like
What happen  when I'm pressing Ctrl+M. Please correct me if it's not the
correct phrase.


  Other case:
  \Diagram{\vertexlabel^a \\
  fd \\
   g\vertexlabel_{\mu,c} \\
  \vertexlabel_b fu\\
  }
 
  I can't add  \\ and  for an array-like environment.

 the array environemtns in math can't be used?

No, because I want it to be called \Diagram and not \Begin{array}.
(Here, I could not make \renewcommand or such to work).


 pavel

Re: I want to add Feyn support to LyX, and I need some guidance

[Ronen Abravanel]

On Wed, Dec 9, 2009 at 1:13 AM, Pavel Sanda <sa...@lyx.org> wrote:

> Ronen Abravanel wrote:
> > One case:
> > \feyn{fs f gl f glu f fs}
> >
> > I can't add spaces.. And they are important
>
> argh.. and ctrl+space can't be used? is suppose no :(
> in any case this looks like that you want to enhance math inset
> and not to create completely new one inset.
>
> Now,
\renewcommand{\text}{\feyn}
will work, but it disable my \text.
When I'm saying "inset", I mean things like "\text" ore "\matrix", not like
"What happen  when I'm pressing Ctrl+M". Please correct me if it's not the
correct phrase.


> > Other case:
> > \Diagram{\vertexlabel^a \\
> > fd \\
> > & g\vertexlabel_{\mu,c} \\
> > \vertexlabel_b fu\\
> > }
> >
> > I can't add  "\\" and "&" for an array-like environment.
>
> the array environemtns in math can't be used?
>
No, because I want it to be called "\Diagram" and not "\Begin{array}".
(Here, I could not make \renewcommand or such to work).


> pavel
>

Re: I want to add Feyn support to LyX, and I need some guidance

[Ronen Abravanel]

It would be, If I could insert ERT *inside* math mode, like
$\frac{\sqrt{ put my diagrams or inset or ERT or somethig here..  }}{6}
\\A lot more math,,$
I can put all my math as ERT. But I can also write all my document in plain
LaTeX...

On Tue, Dec 8, 2009 at 10:26 PM, Pavel Sanda sa...@lyx.org wrote:

 Ronen Abravanel wrote:
  One of the fun thing about this package, is that it's enable you to add
 your
  diagrams as part of an equation.  So, if I want to write, like
  \frac{Diagram...}{Other Diagram} + ... and stuff, It will be much more
  continent In math-mode.

 i still dont understand why ERT is not enough for your inset1?

 pavel

  Your solution seems convenient for my 2nd stage -- Yo use instant
 preview
  instead of replacing fonts. But the name-changed  text inset can not be
  too complicated, as it works just fine with
  \renewcommand{\text}{\Feyn}
  Aside of the fact it disable my \text inset..
 
  On Sun, Dec 6, 2009 at 1:29 AM, Pavel Sanda sa...@lyx.org wrote:
 
   Ronen Abravanel wrote:
I'll start adding the support in my local copy of lyx, and
 afterwards, if
   it
will be good enough, I'll be glad to contribute it to lyx.
  
   i dont want to sound too pesimistic, but your project looks quite
   ambitious,
   which usually ends up somewhere in the void... :) i haven't worked with
   feyn
   package, but wouldn't be ERT + instant preview for this ERT enough? not
 to
   mention
   that stepping into implementation of this would solve support for many
   other
   packages in one step.
  
   pavel
  

Re: I want to add Feyn support to LyX, and I need some guidance

[Ronen Abravanel]

One case:
\feyn{fs f gl f glu f fs}

I can't add spaces.. And they are important

Other case:
\Diagram{\vertexlabel^a \\
fd \\
 g\vertexlabel_{\mu,c} \\
\vertexlabel_b fu\\
}

I can't add  \\ and  for an array-like environment.

On Wed, Dec 9, 2009 at 1:01 AM, Pavel Sanda sa...@lyx.org wrote:

 Ronen Abravanel wrote:
  It would be, If I could insert ERT *inside* math mode, like
  $\frac{\sqrt{ put my diagrams or inset or ERT or somethig here..  }}{6}
  \\A lot more math,,$

 can you show me the code, which you are not able to put into math?
 all those latex \macros can be typed there.

 pavel

Re: I want to add Feyn support to LyX, and I need some guidance

[Ronen Abravanel]

It would be, If I could insert ERT *inside* math mode, like
$\frac{\sqrt{   }}{6}
\\A lot more math,,$
I can put all my math as ERT. But I can also write all my document in plain
LaTeX...

On Tue, Dec 8, 2009 at 10:26 PM, Pavel Sanda <sa...@lyx.org> wrote:

> Ronen Abravanel wrote:
> > One of the fun thing about this package, is that it's enable you to add
> your
> > diagrams as part of an equation.  So, if I want to write, like
> > \frac{Diagram...}{Other Diagram} + ... and stuff, It will be much more
> > continent In math-mode.
>
> i still dont understand why ERT is not enough for your inset1?
>
> pavel
>
> > Your solution seems convenient for my "2nd stage" -- Yo use instant
> preview
> > instead of replacing fonts. But the "name-changed  text inset" can not be
> > too complicated, as it works just fine with
> > "\renewcommand{\text}{\Feyn}"
> > Aside of the fact it disable my "\text" inset..
> >
> > On Sun, Dec 6, 2009 at 1:29 AM, Pavel Sanda <sa...@lyx.org> wrote:
> >
> > > Ronen Abravanel wrote:
> > > > I'll start adding the support in my local copy of lyx, and
> afterwards, if
> > > it
> > > > will be good enough, I'll be glad to contribute it to lyx.
> > >
> > > i dont want to sound too pesimistic, but your project looks quite
> > > ambitious,
> > > which usually ends up somewhere in the void... :) i haven't worked with
> > > feyn
> > > package, but wouldn't be ERT + instant preview for this ERT enough? not
> to
> > > mention
> > > that stepping into implementation of this would solve support for many
> > > other
> > > packages in one step.
> > >
> > > pavel
> > >
>

Re: I want to add Feyn support to LyX, and I need some guidance

[Ronen Abravanel]

One case:
\feyn{fs f gl f glu f fs}

I can't add spaces.. And they are important

Other case:
\Diagram{\vertexlabel^a \\
fd \\
& g\vertexlabel_{\mu,c} \\
\vertexlabel_b fu\\
}

I can't add  "\\" and "&" for an array-like environment.

On Wed, Dec 9, 2009 at 1:01 AM, Pavel Sanda <sa...@lyx.org> wrote:

> Ronen Abravanel wrote:
> > It would be, If I could insert ERT *inside* math mode, like
> > $\frac{\sqrt{   }}{6}
> > \\A lot more math,,$
>
> can you show me the code, which you are not able to put into math?
> all those latex \macros can be typed there.
>
> pavel
>

I want to add Feyn support to LyX, and I need some guidance

[Ronen Abravanel]

Feyn is a Feynman diagram package for latex.
(Feynman diagrams:  http://en.wikipedia.org/wiki/Feynman_diagram,   Feyn:
http://nxg.me.uk/dist/feyn/. Here is some examples:
http://ctan.org/tex-archive/fonts/feyn/feyn.pdf)

Basically,  it's a font and several macros, that allow the user to type some
regular text in math-mode that compiles as a diagram.

In order to allow my to type more easily diagrams into lyx, I want to
conduct the following:


   - Add \feyn inset.
  - for 1st stage, it will act, in LyX, the same as \rm or \text inset:
  It will allow the user to type just regular text, with  \ and
spaces etc..
  as the name of the inset will be feyn and not text, it will
compile as a
  Feynman diagram.
  -   In the next stage, I'll try to replace the font presented in LyX
  in that inset. So, typing g will render as curly line and not
as g, for
  example
   - Add \Diagram inset, in the same stages
  - This inset is used in order to bundle a diagram in an array. I will
  need to use the base of array or matrix inset, with, aside
of the name,
  only one change: I will want the inner entries to act as text
inset (as it
  will allow to type spaces, etc..)


I'll start adding the support in my local copy of lyx, and afterwards, if it
will be good enough, I'll be glad to contribute it to lyx.


Some questions, for the beginning:

   - Aside creating cpp \ h files define an inset, do I need to register it
   someware?
   - Where do the text inset defined? I found the \mahtbf, but I could not
   find the text..


Thanks,
Ronen.

Re: I want to add Feyn support to LyX, and I need some guidance

[Ronen Abravanel]

One of the fun thing about this package, is that it's enable you to add your
diagrams as part of an equation.  So, if I want to write, like
\frac{Diagram...}{Other Diagram} + ... and stuff, It will be much more
continent In math-mode.

Your solution seems convenient for my 2nd stage -- Yo use instant preview
instead of replacing fonts. But the name-changed  text inset can not be
too complicated, as it works just fine with
\renewcommand{\text}{\Feyn}
Aside of the fact it disable my \text inset..

On Sun, Dec 6, 2009 at 1:29 AM, Pavel Sanda sa...@lyx.org wrote:

 Ronen Abravanel wrote:
  I'll start adding the support in my local copy of lyx, and afterwards, if
 it
  will be good enough, I'll be glad to contribute it to lyx.

 i dont want to sound too pesimistic, but your project looks quite
 ambitious,
 which usually ends up somewhere in the void... :) i haven't worked with
 feyn
 package, but wouldn't be ERT + instant preview for this ERT enough? not to
 mention
 that stepping into implementation of this would solve support for many
 other
 packages in one step.

 pavel

I want to add Feyn support to LyX, and I need some guidance

[Ronen Abravanel]

Feyn is a Feynman diagram package for latex.
(Feynman diagrams:  http://en.wikipedia.org/wiki/Feynman_diagram,   Feyn:
http://nxg.me.uk/dist/feyn/. Here is some examples:
http://ctan.org/tex-archive/fonts/feyn/feyn.pdf)

Basically,  it's a font and several macros, that allow the user to type some
regular text in math-mode that compiles as a diagram.

In order to allow my to type more easily diagrams into lyx, I want to
conduct the following:


   - Add "\feyn" inset.
  - for 1st stage, it will act, in LyX, the same as \rm or \text inset:
  It will allow the user to type just regular text, with  "\" and
spaces etc..
  as the name of the inset will be "feyn" and not "text", it will
compile as a
  Feynman diagram.
  -   In the next stage, I'll try to replace the font presented in LyX
  in that inset. So, typing "g" will render as curly line and not
as "g", for
  example
   - Add "\Diagram" inset, in the same stages
  - This inset is used in order to bundle a diagram in an array. I will
  need to use the base of "array" or "matrix" inset, with, aside
of the name,
  only one change: I will want the inner entries to act as "text"
inset (as it
  will allow to type spaces, etc..)


I'll start adding the support in my local copy of lyx, and afterwards, if it
will be good enough, I'll be glad to contribute it to lyx.


Some questions, for the beginning:

   - Aside creating cpp \ h files define an inset, do I need to register it
   someware?
   - Where do the "text" inset defined? I found the \mahtbf, but I could not
   find the "text"..


Thanks,
Ronen.

Re: I want to add Feyn support to LyX, and I need some guidance

[Ronen Abravanel]

One of the fun thing about this package, is that it's enable you to add your
diagrams as part of an equation.  So, if I want to write, like
\frac{Diagram...}{Other Diagram} + ... and stuff, It will be much more
continent In math-mode.

Your solution seems convenient for my "2nd stage" -- Yo use instant preview
instead of replacing fonts. But the "name-changed  text inset" can not be
too complicated, as it works just fine with
"\renewcommand{\text}{\Feyn}"
Aside of the fact it disable my "\text" inset..

On Sun, Dec 6, 2009 at 1:29 AM, Pavel Sanda <sa...@lyx.org> wrote:

> Ronen Abravanel wrote:
> > I'll start adding the support in my local copy of lyx, and afterwards, if
> it
> > will be good enough, I'll be glad to contribute it to lyx.
>
> i dont want to sound too pesimistic, but your project looks quite
> ambitious,
> which usually ends up somewhere in the void... :) i haven't worked with
> feyn
> package, but wouldn't be ERT + instant preview for this ERT enough? not to
> mention
> that stepping into implementation of this would solve support for many
> other
> packages in one step.
>
> pavel
>