Re: [patch] Math macros not imported, Bug #21
Am 23.05.2007 um 01:52 schrieb Uwe Stöhr:
First, I like your patch and give an OK.
FYI, I tried with these examples:
5 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
6 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
What is the difference?
Nothing :)
Only for information: Why can't this and 5 and 6 not be imported
into a MathMacro?:
Optional parameters are not supported.
11 \def\foo A#1B{(#1)} $\foo 1{23}345$
12 \def\foo#1..#2{(#1|#2)} $\foo 1{23}345$
11 will transform only \foo A1B into (1), i.e. with pattern
matching. That's not supported by the MathParser (maybe it could be
done, but it's just not implemented). 12 is similar.
13 \def\foo#1#3{(#1|#2)} $\foo 1{23}345$
14 \def\foo#1#1{(#1|#2)} $\foo 1{23}345$
These two are not valid. The parameter numbers must increase exactly
by one, without duplication, starting from 1.
A recursive macro like \def\foo#1{\def\baa{#1}} is parsed,
creating first the \baa MathMacro, then the \foo MathMacro with a
\baa MathMacro inside. I think we have to exclude this case, i.e. a
recursive macro should go into an ERT as well.
Why do you think it should be excluded? Currently I can create
recursive MathMacros I only have to assure the correct definition
order.
It should be included because it is not properly evaluated. LyX only
has a global macro table at the moment. So calling a recursive
macro twice will result in strange results.
Btw. while you are working on this stuff: I pointed out in bug 1394
http://bugzilla.lyx.org/show_bug.cgi?id=1394
that it is annoying that the definitions aren't placed to the
document preamble. There should at least be an option to put the
definitions t the preamble, there is no reason why this is not
allowed.
Well, we could put macro into the preamble which are defined at the
very beginning of the document. In all other cases there is a
semantical difference if the macro's name already appears before.
Don't know how to do it properly. Maybe one could mark macros as
preamble-macros? Any suggestion?
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Re: [patch] Math macros not imported, Bug #21
It should be included because it is not properly evaluated. LyX only has a global macro table at the moment. So calling a recursive macro twice will result in strange results. s/included/excluded/ Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] Math macros not imported, Bug #21
I would like to hear what André has to say about this patch. :-) As André gave his OK and me too this can go in right? regards Uwe
Re: [patch] Math macros not imported, Bug #21
On Thursday 24 May 2007 00:25:46 Uwe Stöhr wrote: As André gave his OK and me too this can go in right? Yep. :-) regards Uwe -- José Abílio
Re: [patch] Math macros not imported, Bug #21
Am 23.05.2007 um 01:52 schrieb Uwe Stöhr:
First, I like your patch and give an OK.
> FYI, I tried with these examples:
> 5 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
> 6 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
What is the difference?
Nothing :)
Only for information: Why can't this and 5 and 6 not be imported
into a MathMacro?:
Optional parameters are not supported.
> 11 \def\foo A#1B{(#1)} $\foo 1{23}345$
> 12 \def\foo#1..#2{(#1|#2)} $\foo 1{23}345$
11 will transform only "\foo A1B into (1), i.e. with pattern
matching. That's not supported by the MathParser (maybe it could be
done, but it's just not implemented). 12 is similar.
> 13 \def\foo#1#3{(#1|#2)} $\foo 1{23}345$
> 14 \def\foo#1#1{(#1|#2)} $\foo 1{23}345$
These two are not valid. The parameter numbers must increase exactly
by one, without duplication, starting from 1.
> A recursive macro like \def\foo#1{\def\baa{#1}} is parsed,
creating first the \baa MathMacro, then > the \foo MathMacro with a
\baa MathMacro inside. I think we have to exclude this case, i.e. a
> recursive macro should go into an ERT as well.
Why do you think it should be excluded? Currently I can create
recursive MathMacros I only have to assure the correct definition
order.
It should be included because it is not properly evaluated. LyX only
has a global macro table at the moment. So "calling" a recursive
macro twice will result in strange results.
Btw. while you are working on this stuff: I pointed out in bug 1394
http://bugzilla.lyx.org/show_bug.cgi?id=1394
that it is annoying that the definitions aren't placed to the
document preamble. There should at least be an option to put the
definitions t the preamble, there is no reason why this is not
allowed.
Well, we could put macro into the preamble which are defined at the
very beginning of the document. In all other cases there is a
semantical difference if the macro's name already appears before.
Don't know how to do it properly. Maybe one could mark macros as
preamble-macros? Any suggestion?
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Re: [patch] Math macros not imported, Bug #21
It should be included because it is not properly evaluated. LyX only has a global macro table at the moment. So "calling" a recursive macro twice will result in strange results. s/included/excluded/ Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] Math macros not imported, Bug #21
> I would like to hear what André has to say about this patch. :-) As André gave his OK and me too this can go in right? regards Uwe
Re: [patch] Math macros not imported, Bug #21
On Thursday 24 May 2007 00:25:46 Uwe Stöhr wrote: > As André gave his OK and me too this can go in right? Yep. :-) > regards Uwe -- José Abílio
[patch] Math macros not imported, Bug #21
I backported my fix to trunk as proposed by Uwe. The patch is attached to the bug report: http://bugzilla.lyx.org/show_bug.cgi?id=21 Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] Math macros not imported, Bug #21
I'm sure this would be most welcome to people who exchange LyX files with pure LaTeX users. Stefan Schimanski wrote: I backported my fix to trunk as proposed by Uwe. The patch is attached to the bug report: http://bugzilla.lyx.org/show_bug.cgi?id=21 Stefan -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [patch] Math macros not imported, Bug #21
On Tuesday 22 May 2007 7:08:55 am Stefan Schimanski wrote: I backported my fix to trunk as proposed by Uwe. The patch is attached to the bug report: http://bugzilla.lyx.org/show_bug.cgi?id=21 I would like to hear what André has to say about this patch. :-) Stefan -- José Abílio
Re: [patch] Math macros not imported, Bug #21
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan I backported my fix to trunk as proposed by Uwe. The patch is
Stefan attached to the bug report:
Stefan http://bugzilla.lyx.org/show_bug.cgi?id=21
What do you do with definition more complicated than
\def\foo#1{\bar{#1}}
like for example
\def\foo(#1,#2){\bar{#1}{#2}}
?
These should be detected and transformed to ERT.
JMarc
Re: [patch] Math macros not imported, Bug #21
Am 22.05.2007 um 12:31 schrieb Jean-Marc Lasgouttes:
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
Stefan I backported my fix to trunk as proposed by Uwe. The patch is
Stefan attached to the bug report:
Stefan http://bugzilla.lyx.org/show_bug.cgi?id=21
What do you do with definition more complicated than
\def\foo#1{\bar{#1}}
like for example
\def\foo(#1,#2){\bar{#1}{#2}}
?
These should be detected and transformed to ERT.
They are. Look at the while loop. It looks for the { character. As
long as only proper #n arguments come, the macro is assumed to be
compatible (i.e. simple == true). If he sees something else simple is
set to false and later only an ERT is created, no MathMacro.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Re: [patch] Math macros not imported, Bug #21
Stefan == Stefan Schimanski [EMAIL PROTECTED] writes:
These should be detected and transformed to ERT.
Stefan They are. Look at the while loop. It looks for the {
Stefan character. As long as only proper #n arguments come, the macro
Stefan is assumed to be compatible (i.e. simple == true). If he sees
Stefan something else simple is set to false and later only an ERT is
Stefan created, no MathMacro.
OK, I misunderstood the code. This is very good.
JMarc
Re: [patch] Math macros not imported, Bug #21
FYI, I tried with these examples:
1 \newcommand{\foo}{42} $\foo 1{23}345$
2 \newcommand{\foo}[1]{(#1)} $\foo 1{23}345$
3 \newcommand{\foo}[1]{(#1|#1)} $\foo 1{23}345$
4 \newcommand{\foo}[2]{(#1|#2)} $\foo 1{23}345$
5 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
6 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
7 \def\foo{42} $\foo 1{23}345$
8 \def\foo#1{(#1)} $\foo 1{23}345$
9 \def\foo #1{(#1)} $\foo 1{23}345$
10 \def\foo#1#2{(#1|#2)} $\foo 1{23}345$
11 \def\foo A#1B{(#1)} $\foo 1{23}345$
12 \def\foo#1..#2{(#1|#2)} $\foo 1{23}345$
13 \def\foo#1#3{(#1|#2)} $\foo 1{23}345$
14 \def\foo#1#1{(#1|#2)} $\foo 1{23}345$
They work fine, i.e. 1,2,3,4,7,8,9,10 are converted into MathMacros.
A recursive macro like \def\foo#1{\def\baa{#1}} is parsed, creating
first the \baa MathMacro, then the \foo MathMacro with a \baa
MathMacro inside. I think we have to exclude this case, i.e. a
recursive macro should go into an ERT as well.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Re: [patch] Math macros not imported, Bug #21
On Tue, May 22, 2007 at 08:49:31AM +0100, José Matos wrote: On Tuesday 22 May 2007 7:08:55 am Stefan Schimanski wrote: I backported my fix to trunk as proposed by Uwe. The patch is attached to the bug report: http://bugzilla.lyx.org/show_bug.cgi?id=21 I would like to hear what André has to say about this patch. :-) I know that something like that might work in theory, I do not see anything obviously wrong with the patch (we talk about http://bugzilla.lyx.org/attachment.cgi?id=1715action=view, aren't we), but I have no time to verify it works in practice. I'd assume that Stefan tested his patch extensively and given that tex2lyx is not infallible in general I would think it might do more good than potential harm, even that late in the release cycle. Andre'
Re: [patch] Math macros not imported, Bug #21
On Tue, May 22, 2007 at 01:58:42PM +0200, Stefan Schimanski wrote:
FYI, I tried with these examples:
1 \newcommand{\foo}{42} $\foo 1{23}345$
2 \newcommand{\foo}[1]{(#1)} $\foo 1{23}345$
3 \newcommand{\foo}[1]{(#1|#1)} $\foo 1{23}345$
4 \newcommand{\foo}[2]{(#1|#2)} $\foo 1{23}345$
5 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
6 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
7 \def\foo{42} $\foo 1{23}345$
8 \def\foo#1{(#1)} $\foo 1{23}345$
9 \def\foo #1{(#1)} $\foo 1{23}345$
10 \def\foo#1#2{(#1|#2)} $\foo 1{23}345$
11 \def\foo A#1B{(#1)} $\foo 1{23}345$
12 \def\foo#1..#2{(#1|#2)} $\foo 1{23}345$
13 \def\foo#1#3{(#1|#2)} $\foo 1{23}345$
14 \def\foo#1#1{(#1|#2)} $\foo 1{23}345$
They work fine, i.e. 1,2,3,4,7,8,9,10 are converted into MathMacros.
A recursive macro like \def\foo#1{\def\baa{#1}} is parsed, creating
first the \baa MathMacro, then the \foo MathMacro with a \baa
MathMacro inside. I think we have to exclude this case, i.e. a
recursive macro should go into an ERT as well.
Feel free to add this as comment to the patch.
Andre'
Re: [patch] Math macros not imported, Bug #21
Am 22.05.2007 um 20:39 schrieb Andre Poenitz:
On Tue, May 22, 2007 at 08:49:31AM +0100, José Matos wrote:
On Tuesday 22 May 2007 7:08:55 am Stefan Schimanski wrote:
I backported my fix to trunk as proposed by Uwe. The patch is
attached to the bug report: http://bugzilla.lyx.org/show_bug.cgi?
id=21
I would like to hear what André has to say about this patch. :-)
I know that something like that might work in theory, I do not
see anything obviously wrong with the patch (we talk about
http://bugzilla.lyx.org/attachment.cgi?id=1715action=view, aren't
we),
but I have no time to verify it works in practice.
I'd assume that Stefan tested his patch extensively and given that
tex2lyx is not infallible in general I would think it might do more
good
than potential harm, even that late in the release cycle.
I tested it with the examples shown in the other mail, and a big
thesis of a colleague.
I don't think the import feature can break that much, but I fear that
people start using macros in lyx then. Not sure that is a good thing,
only with a big yellow warning window and two Are you sure you want
that? and Are you sure you are sure? message boxes before. So I
cannot decide if the patch is a good thing after all. People who know
the flaws and traps will also be able to convert ERTs manually
anywhere. The others shouldn't use them IMO. Opinions?
Am 22.05.2007 um 20:50 schrieb Andre Poenitz:
A recursive macro like \def\foo#1{\def\baa{#1}} is parsed, creating
first the \baa MathMacro, then the \foo MathMacro with a \baa
MathMacro inside. I think we have to exclude this case, i.e. a
recursive macro should go into an ERT as well.
Feel free to add this as comment to the patch.
No idea how often recursive macros are used. But I will add a trivial
check for that, just looking for \def/\newcommand and so on textually.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Re: [patch] Math macros not imported, Bug #21
First, I like your patch and give an OK.
FYI, I tried with these examples:
5 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
6 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
What is the difference?
Only for information: Why can't this and 5 and 6 not be imported into a
MathMacro?:
11 \def\foo A#1B{(#1)} $\foo 1{23}345$
12 \def\foo#1..#2{(#1|#2)} $\foo 1{23}345$
13 \def\foo#1#3{(#1|#2)} $\foo 1{23}345$
14 \def\foo#1#1{(#1|#2)} $\foo 1{23}345$
A recursive macro like \def\foo#1{\def\baa{#1}} is parsed, creating first the \baa MathMacro,
then the \foo MathMacro with a \baa MathMacro inside. I think we have to exclude this case, i.e. a
recursive macro should go into an ERT as well.
Why do you think it should be excluded? Currently I can create recursive MathMacros I only have to
assure the correct definition order.
---
Btw. while you are working on this stuff: I pointed out in bug 1394
http://bugzilla.lyx.org/show_bug.cgi?id=1394
that it is annoying that the definitions aren't placed to the document preamble. There should at
least be an option to put the definitions t the preamble, there is no reason why this is not allowed.
regards Uwe
[patch] Math macros not imported, Bug #21
I backported my fix to trunk as proposed by Uwe. The patch is attached to the bug report: http://bugzilla.lyx.org/show_bug.cgi?id=21 Stefan PGP.sig Description: Signierter Teil der Nachricht
Re: [patch] Math macros not imported, Bug #21
I'm sure this would be most welcome to people who exchange LyX files with pure LaTeX users. Stefan Schimanski wrote: > I backported my fix to trunk as proposed by Uwe. The patch is attached > to the bug report: http://bugzilla.lyx.org/show_bug.cgi?id=21 > > Stefan -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [patch] Math macros not imported, Bug #21
On Tuesday 22 May 2007 7:08:55 am Stefan Schimanski wrote: > I backported my fix to trunk as proposed by Uwe. The patch is > attached to the bug report: http://bugzilla.lyx.org/show_bug.cgi?id=21 I would like to hear what André has to say about this patch. :-) > Stefan -- José Abílio
Re: [patch] Math macros not imported, Bug #21
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> I backported my fix to trunk as proposed by Uwe. The patch is
Stefan> attached to the bug report:
Stefan> http://bugzilla.lyx.org/show_bug.cgi?id=21
What do you do with definition more complicated than
\def\foo#1{\bar{#1}}
like for example
\def\foo(#1,#2){\bar{#1}{#2}}
?
These should be detected and transformed to ERT.
JMarc
Re: [patch] Math macros not imported, Bug #21
Am 22.05.2007 um 12:31 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> I backported my fix to trunk as proposed by Uwe. The patch is
Stefan> attached to the bug report:
Stefan> http://bugzilla.lyx.org/show_bug.cgi?id=21
What do you do with definition more complicated than
\def\foo#1{\bar{#1}}
like for example
\def\foo(#1,#2){\bar{#1}{#2}}
?
These should be detected and transformed to ERT.
They are. Look at the while loop. It looks for the { character. As
long as only proper #n arguments come, the macro is assumed to be
compatible (i.e. simple == true). If he sees something else simple is
set to false and later only an ERT is created, no MathMacro.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Re: [patch] Math macros not imported, Bug #21
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
>> These should be detected and transformed to ERT.
Stefan> They are. Look at the while loop. It looks for the {
Stefan> character. As long as only proper #n arguments come, the macro
Stefan> is assumed to be compatible (i.e. simple == true). If he sees
Stefan> something else simple is set to false and later only an ERT is
Stefan> created, no MathMacro.
OK, I misunderstood the code. This is very good.
JMarc
Re: [patch] Math macros not imported, Bug #21
FYI, I tried with these examples:
1 \newcommand{\foo}{42} $\foo 1{23}345$
2 \newcommand{\foo}[1]{(#1)} $\foo 1{23}345$
3 \newcommand{\foo}[1]{(#1|#1)} $\foo 1{23}345$
4 \newcommand{\foo}[2]{(#1|#2)} $\foo 1{23}345$
5 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
6 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
7 \def\foo{42} $\foo 1{23}345$
8 \def\foo#1{(#1)} $\foo 1{23}345$
9 \def\foo #1{(#1)} $\foo 1{23}345$
10 \def\foo#1#2{(#1|#2)} $\foo 1{23}345$
11 \def\foo A#1B{(#1)} $\foo 1{23}345$
12 \def\foo#1..#2{(#1|#2)} $\foo 1{23}345$
13 \def\foo#1#3{(#1|#2)} $\foo 1{23}345$
14 \def\foo#1#1{(#1|#2)} $\foo 1{23}345$
They work fine, i.e. 1,2,3,4,7,8,9,10 are converted into MathMacros.
A recursive macro like \def\foo#1{\def\baa{#1}} is parsed, creating
first the \baa MathMacro, then the \foo MathMacro with a \baa
MathMacro inside. I think we have to exclude this case, i.e. a
recursive macro should go into an ERT as well.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Re: [patch] Math macros not imported, Bug #21
On Tue, May 22, 2007 at 08:49:31AM +0100, José Matos wrote: > On Tuesday 22 May 2007 7:08:55 am Stefan Schimanski wrote: > > I backported my fix to trunk as proposed by Uwe. The patch is > > attached to the bug report: http://bugzilla.lyx.org/show_bug.cgi?id=21 > > I would like to hear what André has to say about this patch. :-) I know that something like that might work in theory, I do not see anything obviously wrong with the patch (we talk about http://bugzilla.lyx.org/attachment.cgi?id=1715=view, aren't we), but I have no time to verify it works in practice. I'd assume that Stefan tested his patch extensively and given that tex2lyx is not infallible in general I would think it might do more good than potential harm, even that late in the release cycle. Andre'
Re: [patch] Math macros not imported, Bug #21
On Tue, May 22, 2007 at 01:58:42PM +0200, Stefan Schimanski wrote:
> FYI, I tried with these examples:
>
> 1 \newcommand{\foo}{42} $\foo 1{23}345$
> 2 \newcommand{\foo}[1]{(#1)} $\foo 1{23}345$
> 3 \newcommand{\foo}[1]{(#1|#1)} $\foo 1{23}345$
> 4 \newcommand{\foo}[2]{(#1|#2)} $\foo 1{23}345$
> 5 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
> 6 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
> 7 \def\foo{42} $\foo 1{23}345$
> 8 \def\foo#1{(#1)} $\foo 1{23}345$
> 9 \def\foo #1{(#1)} $\foo 1{23}345$
> 10 \def\foo#1#2{(#1|#2)} $\foo 1{23}345$
> 11 \def\foo A#1B{(#1)} $\foo 1{23}345$
> 12 \def\foo#1..#2{(#1|#2)} $\foo 1{23}345$
> 13 \def\foo#1#3{(#1|#2)} $\foo 1{23}345$
> 14 \def\foo#1#1{(#1|#2)} $\foo 1{23}345$
>
> They work fine, i.e. 1,2,3,4,7,8,9,10 are converted into MathMacros.
>
> A recursive macro like \def\foo#1{\def\baa{#1}} is parsed, creating
> first the \baa MathMacro, then the \foo MathMacro with a \baa
> MathMacro inside. I think we have to exclude this case, i.e. a
> recursive macro should go into an ERT as well.
Feel free to add this as comment to the patch.
Andre'
Re: [patch] Math macros not imported, Bug #21
Am 22.05.2007 um 20:39 schrieb Andre Poenitz:
On Tue, May 22, 2007 at 08:49:31AM +0100, José Matos wrote:
On Tuesday 22 May 2007 7:08:55 am Stefan Schimanski wrote:
I backported my fix to trunk as proposed by Uwe. The patch is
attached to the bug report: http://bugzilla.lyx.org/show_bug.cgi?
id=21
I would like to hear what André has to say about this patch. :-)
I know that something like that might work in theory, I do not
see anything obviously wrong with the patch (we talk about
http://bugzilla.lyx.org/attachment.cgi?id=1715=view, aren't
we),
but I have no time to verify it works in practice.
I'd assume that Stefan tested his patch extensively and given that
tex2lyx is not infallible in general I would think it might do more
good
than potential harm, even that late in the release cycle.
I tested it with the examples shown in the other mail, and a big
thesis of a colleague.
I don't think the import feature can break that much, but I fear that
people start using macros in lyx then. Not sure that is a good thing,
only with a big yellow warning window and two "Are you sure you want
that?" and "Are you sure you are sure?" message boxes before. So I
cannot decide if the patch is a good thing after all. People who know
the flaws and traps will also be able to convert ERTs manually
anywhere. The others shouldn't use them IMO. Opinions?
Am 22.05.2007 um 20:50 schrieb Andre Poenitz:
A recursive macro like \def\foo#1{\def\baa{#1}} is parsed, creating
first the \baa MathMacro, then the \foo MathMacro with a \baa
MathMacro inside. I think we have to exclude this case, i.e. a
recursive macro should go into an ERT as well.
Feel free to add this as comment to the patch.
No idea how often recursive macros are used. But I will add a trivial
check for that, just looking for \def/\newcommand and so on textually.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Re: [patch] Math macros not imported, Bug #21
First, I like your patch and give an OK.
> FYI, I tried with these examples:
> 5 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
> 6 \newcommand{\foo}[2][\frac{1}{2}]{(#1|#2)} $\foo 1{23}345$
What is the difference?
Only for information: Why can't this and 5 and 6 not be imported into a
MathMacro?:
> 11 \def\foo A#1B{(#1)} $\foo 1{23}345$
> 12 \def\foo#1..#2{(#1|#2)} $\foo 1{23}345$
> 13 \def\foo#1#3{(#1|#2)} $\foo 1{23}345$
> 14 \def\foo#1#1{(#1|#2)} $\foo 1{23}345$
>
> A recursive macro like \def\foo#1{\def\baa{#1}} is parsed, creating first the \baa MathMacro,
then > the \foo MathMacro with a \baa MathMacro inside. I think we have to exclude this case, i.e. a
> recursive macro should go into an ERT as well.
Why do you think it should be excluded? Currently I can create recursive MathMacros I only have to
assure the correct definition order.
---
Btw. while you are working on this stuff: I pointed out in bug 1394
http://bugzilla.lyx.org/show_bug.cgi?id=1394
that it is annoying that the definitions aren't placed to the document preamble. There should at
least be an option to put the definitions t the preamble, there is no reason why this is not allowed.
regards Uwe
