On Wednesday 09 May 2007 13:13:53 hzluo wrote:
Who can I ask for help if I have tex2lyx problems?
Thanks in advance :)
Ask to this mailing list. :-)
--
José Abílio
On Wednesday 09 May 2007 13:13:53 hzluo wrote:
> Who can I ask for help if I have tex2lyx problems?
> Thanks in advance :)
Ask to this mailing list. :-)
--
José Abílio
On Tue, May 08, 2007 at 06:26:00PM -0400, hzluo wrote:
Attached files are to enable relyx on the fly,
i.e., when a latex syntaxed string is pasted
into lyx, it is converted to lyx.
Nice idea.
Currently the patch can only detect \cite{...}
command embeded in a string. But it can be extended
Andre Poenitz wrote:
On Tue, May 08, 2007 at 06:26:00PM -0400, hzluo wrote:
Any comment is welcome!
This won't go into the upcoming 1.5.0 but is a pretty nice thing to have
in early 1.6 (i.e. in a few weeks time).
Christmas is still months away...
Abdel.
hzluo wrote:
Any comment is welcome! If you are interested,
I can extend it to support more latex syntax.
If possible, call tex2lyx and read the result
out is also an option. But it may be a little
bit slow.
I think we should try to integrate text2lyx (maybe as a library)
instead.But as
hzluo == hzluo [EMAIL PROTECTED] writes:
hzluo Attached files are to enable relyx on the fly, i.e., when a
hzluo latex syntaxed string is pasted into lyx, it is converted to
hzluo lyx.
hzluo Currently the patch can only detect \cite{...} command embeded
hzluo in a string. But it can be
This won't go into the upcoming 1.5.0 but is a pretty nice thing to have
in early 1.6 (i.e. in a few weeks time).
Yes, I also do not expect it will be in 1.5.0.
Until then it'd be nice if the patch could made a bit more similar to
the rest of lyx on the 'cosmetic' side: I.e.
On Tue, May 08, 2007 at 06:26:00PM -0400, hzluo wrote:
> Attached files are to enable relyx on the fly,
> i.e., when a latex syntaxed string is pasted
> into lyx, it is converted to lyx.
Nice idea.
> Currently the patch can only detect \cite{...}
> command embeded in a string. But it can be
Andre Poenitz wrote:
On Tue, May 08, 2007 at 06:26:00PM -0400, hzluo wrote:
Any comment is welcome!
This won't go into the upcoming 1.5.0 but is a pretty nice thing to have
in early 1.6 (i.e. in a few weeks time).
Christmas is still months away...
Abdel.
hzluo wrote:
> Any comment is welcome! If you are interested,
> I can extend it to support more latex syntax.
> If possible, call tex2lyx and read the result
> out is also an option. But it may be a little
> bit slow.
I think we should try to integrate text2lyx (maybe as a library)
instead.But
> "hzluo" == hzluo <[EMAIL PROTECTED]> writes:
hzluo> Attached files are to enable relyx on the fly, i.e., when a
hzluo> latex syntaxed string is pasted into lyx, it is converted to
hzluo> lyx.
hzluo> Currently the patch can only detect \cite{...} command embeded
hzluo> in a string. But it
This won't go into the upcoming 1.5.0 but is a pretty nice thing to have
in early 1.6 (i.e. in a few weeks time).
Yes, I also do not expect it will be in 1.5.0.
Until then it'd be nice if the patch could made a bit more similar to
the rest of lyx on the 'cosmetic' side: I.e.
Attached files are to enable relyx on the fly,
i.e., when a latex syntaxed string is pasted
into lyx, it is converted to lyx.
Currently the patch can only detect \cite{...}
command embeded in a string. But it can be extended
to support more latex syntax.
Test:
paste a string like:
blabla bla
Attached files are to enable relyx on the fly,
i.e., when a latex syntaxed string is pasted
into lyx, it is converted to lyx.
Currently the patch can only detect \cite{...}
command embeded in a string. But it can be extended
to support more latex syntax.
Test:
paste a string like:
blabla bla
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Ok, JMarc. I dug deep enough to understand how it works and
Angus have developed a gruding admiration for it. I append
^^^grudging? (I had to look up the word in
the
On Tuesday 11 February 2003 1:38 pm, Jean-Marc Lasgouttes wrote:
You have convinced me. But now I have another doubt: you take great
length to handle \)*, because this is what is pointed out in bug 9.
But as far as I can see, this is a rather rare occurence, not more
likely than for example
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus All fair points. As I said yesterday, I will not rewrite the
Angus TeX.pm parser; it is a can or worms that will make a horrible
Angus mess if split open.
Yes, it does not need more special casing added here and there...
Angus Let's bin
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Ok, JMarc. I dug deep enough to understand how it works and
Angus> have developed a gruding admiration for it. I append
^^^grudging? (I had to look up the word in
On Tuesday 11 February 2003 1:38 pm, Jean-Marc Lasgouttes wrote:
> You have convinced me. But now I have another doubt: you take great
> length to handle \)*, because this is what is pointed out in bug 9.
> But as far as I can see, this is a rather rare occurence, not more
> likely than for
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> All fair points. As I said yesterday, I will not rewrite the
Angus> TeX.pm parser; it is a can or worms that will make a horrible
Angus> mess if split open.
Yes, it does not need more special casing added here and there...
Angus>
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus This patch enables reLyX to handle \(...\)* correctly and not
Angus generate a pile of crap. I attach a test case so the
Angus inquisitive can try out reLyX both with and without the patch.
Can you explain a bit how this macro is used? Is
Jean-Marc Lasgouttes wrote:
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus This patch enables reLyX to handle \(...\)* correctly and not
Angus generate a pile of crap. I attach a test case so the
Angus inquisitive can try out reLyX both with and without the
patch.
Can you
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Not convincingly. I have been looking at this code hard over
Angus the w/e in an effort to understand it. I'll get back to you
Angus when I do. Mean while, throw the patch away.
OK.
Angus Here, however is my current state of knowledge
On Monday 10 February 2003 3:53 pm, Jean-Marc Lasgouttes wrote:
Is there a list of macros somewhere that accept an optional *?
Angus See lib/reLyX/syntax.default. Macros are defined explicitly as
Angus \section \section*
So they are considered as diffrent macros, right?
Yes. The
Jean-Marc Lasgouttes wrote:
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Not convincingly. I have been looking at this code hard over
Angus the w/e in an effort to understand it. I'll get back to you
Angus when I do. Mean while, throw the patch away.
OK.
Angus Here, however
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> This patch enables reLyX to handle \(...\)* correctly and not
Angus> generate a pile of crap. I attach a test case so the
Angus> inquisitive can try out reLyX both with and without the patch.
Can you explain a bit how this macro
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> This patch enables reLyX to handle \(...\)* correctly and not
> Angus> generate a pile of crap. I attach a test case so the
> Angus> inquisitive can try out reLyX both with and without the
> patch.
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Not convincingly. I have been looking at this code hard over
Angus> the w/e in an effort to understand it. I'll get back to you
Angus> when I do. Mean while, throw the patch away.
OK.
Angus> Here, however is my current state of
On Monday 10 February 2003 3:53 pm, Jean-Marc Lasgouttes wrote:
> >> Is there a list of macros somewhere that accept an optional *?
>
> Angus> See lib/reLyX/syntax.default. Macros are defined explicitly as
> Angus> \section \section*
>
> So they are considered as diffrent macros, right?
Yes. The
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> Not convincingly. I have been looking at this code hard over
> Angus> the w/e in an effort to understand it. I'll get back to you
> Angus> when I do. Mean while, throw the patch away.
>
> OK.
>
>
This patch enables reLyX to handle \(...\)* correctly and not generate a
pile of crap. I attach a test case so the inquisitive can try out reLyX
both with and without the patch.
The last time I applied this, I wasn't careful enough and broke reLyX in
other respects. I have been more careful
This patch enables reLyX to handle \(...\)* correctly and not generate a
pile of crap. I attach a test case so the inquisitive can try out reLyX
both with and without the patch.
The last time I applied this, I wasn't careful enough and broke reLyX in
other respects. I have been more careful
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
|
| | Can some of you relyx people have a look at case 638 and see if this
| | patch has any relevance?
| |
| | It kindo seems that it fixes things, but I won't apply anything until
| | I have
On Tuesday 21 January 2003 09:19, Lars Gullik Bjønnes wrote:
This patch became a bit larger than intended, due to ws changes.
I noticed that, it was the reason why I didn't look to it before. :-)
This is the cut down version.
| @@ -1400,7 +1400,8 @@ sub ConvertToLayout {
| print
José Matos [EMAIL PROTECTED] writes:
| I am not a reLyX people :-), but I see the logic of your change and I say go
| with it. To be on the safe side you need Kayvan's opinion. :-)
Some more testing on tex files is also needed.
--
Lgb
Juergen Spitzmueller wrote:
This does still loop on my test file (export -- reimport the attached LyX
file).
If I change the order in the reLyXed lyx file:
\layout Enumerate
+ \begin_deeper
\begin_float tab
- \begin_deeper
\layout Standard
\align center
\LyXTable
...
then lyx reads the file
Lars Gullik Bjønnes wrote:
This is the cut down version.
| @@ -1400,7 +1400,8 @@ sub ConvertToLayout {
| print \nChanging $dummy $name to layout $layout if $debug_on;
|
| # Nest if the layout stack has more than just Standard in it
| -if ($#{$CurrentLayoutStack} 0) {
| +
[EMAIL PROTECTED] (Juergen Spitzmueller) writes:
| Juergen Spitzmueller wrote:
| This does still loop on my test file (export -- reimport the attached LyX
| file).
|
| If I change the order in the reLyXed lyx file:
|
| \layout Enumerate
| + \begin_deeper
| \begin_float tab
| - \begin_deeper
|
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
|
| | Can some of you relyx people have a look at case 638 and see if this
| | patch has any relevance?
| |
| | It kindo seems that it fixes things, but I won't apply anything until
| | I have
On Tuesday 21 January 2003 09:19, Lars Gullik Bjønnes wrote:
>
> This patch became a bit larger than intended, due to ws changes.
I noticed that, it was the reason why I didn't look to it before. :-)
> This is the cut down version.
>
> | @@ -1400,7 +1400,8 @@ sub ConvertToLayout {
> |
José Matos <[EMAIL PROTECTED]> writes:
| I am not a reLyX people :-), but I see the logic of your change and I say go
| with it. To be on the safe side you need Kayvan's opinion. :-)
Some more testing on tex files is also needed.
--
Lgb
Juergen Spitzmueller wrote:
> This does still loop on my test file (export -- reimport the attached LyX
> file).
If I change the order in the reLyXed lyx file:
\layout Enumerate
+ \begin_deeper
\begin_float tab
- \begin_deeper
\layout Standard
\align center
\LyXTable
...
then lyx reads the file
Lars Gullik Bjønnes wrote:
> This is the cut down version.
>
> | @@ -1400,7 +1400,8 @@ sub ConvertToLayout {
> | print "\nChanging $dummy $name to layout $layout" if $debug_on;
> |
> | # Nest if the layout stack has more than just "Standard" in it
> | -if ($#{$CurrentLayoutStack} >
[EMAIL PROTECTED] (Juergen Spitzmueller) writes:
| Juergen Spitzmueller wrote:
| > This does still loop on my test file (export -- reimport the attached LyX
| > file).
|
| If I change the order in the reLyXed lyx file:
|
| \layout Enumerate
| + \begin_deeper
| \begin_float tab
| - \begin_deeper
Can some of you relyx people have a look at case 638 and see if this
patch has any relevance?
It kindo seems that it fixes things, but I won't apply anything until
I have confirmations.
--
Lgb
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Can some of you relyx people have a look at case 638 and see if this
| patch has any relevance?
|
| It kindo seems that it fixes things, but I won't apply anything until
| I have confirmations.
? relyx.diff
Index: BasicLyX.pm
Can some of you relyx people have a look at case 638 and see if this
patch has any relevance?
It kindo seems that it fixes things, but I won't apply anything until
I have confirmations.
--
Lgb
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| Can some of you relyx people have a look at case 638 and see if this
| patch has any relevance?
|
| It kindo seems that it fixes things, but I won't apply anything until
| I have confirmations.
? relyx.diff
Index: BasicLyX.pm
On Thu, Jan 16, 2003 at 02:40:08AM +0100, Michael Schmitt wrote:
Index: lib/lyx2lyx/lyxconvert_218.py
===
RCS file: /cvs/lyx/lyx-devel/lib/lyx2lyx/lyxconvert_218.py,v
retrieving revision 1.28
diff -u -r1.28 lyxconvert_218.py
---
On Fri, 17 Jan 2003, Dekel Tsur wrote:
On Thu, Jan 16, 2003 at 02:40:08AM +0100, Michael Schmitt wrote:
Index: lib/lyx2lyx/lyxconvert_218.py
===
RCS file: /cvs/lyx/lyx-devel/lib/lyx2lyx/lyxconvert_218.py,v
retrieving
On Thu, Jan 16, 2003 at 02:40:08AM +0100, Michael Schmitt wrote:
> Index: lib/lyx2lyx/lyxconvert_218.py
> ===
> RCS file: /cvs/lyx/lyx-devel/lib/lyx2lyx/lyxconvert_218.py,v
> retrieving revision 1.28
> diff -u -r1.28 lyxconvert_218.py
On Fri, 17 Jan 2003, Dekel Tsur wrote:
> On Thu, Jan 16, 2003 at 02:40:08AM +0100, Michael Schmitt wrote:
> > Index: lib/lyx2lyx/lyxconvert_218.py
> > ===
> > RCS file: /cvs/lyx/lyx-devel/lib/lyx2lyx/lyxconvert_218.py,v
> >
Hi,
below please find two patches for lyx2lyx and reLyX. I have already
posted the patch for reLyX but I am not sure whether I used plain text
when sending the email.
The following two bugs are fixed:
- lyx2lyx does not translate listoffigures/listoftables correctly
- reLyX fails if there
Hi,
below please find two patches for lyx2lyx and reLyX. I have already
posted the patch for reLyX but I am not sure whether I used plain text
when sending the email.
The following two bugs are fixed:
- lyx2lyx does not translate listoffigures/listoftables correctly
- reLyX fails if there
On Wed, Nov 01, 2000 at 03:35:07PM +0100, Yves Bastide wrote:
reLyX cannot handle document class names with non `word' characters
(not in [A-Za-z_]), such as article-hermes. This patch therefore replaces
\w by \S (non blank) in the regular expression.
Good point.
Note this is not
"Amir" == Amir Karger [EMAIL PROTECTED] writes:
Amir Sure, I suppose. New patch below. Jean-Marc, could you apply?
Done.
JMarc
On Wed, Nov 01, 2000 at 03:35:07PM +0100, Yves Bastide wrote:
>
> reLyX cannot handle document class names with non `word' characters
> (not in [A-Za-z_]), such as article-hermes. This patch therefore replaces
> \w by \S (non blank) in the regular expression.
Good point.
> Note this is not
> "Amir" == Amir Karger <[EMAIL PROTECTED]> writes:
Amir> Sure, I suppose. New patch below. Jean-Marc, could you apply?
Done.
JMarc
My last patch for today (-:
reLyX cannot handle document class names with non `word' characters
(not in [A-Za-z_]), such as article-hermes. This patch therefore replaces
\w by \S (non blank) in the regular expression.
Note this is not foolproof, either: perhaps better would be \s*(\S+)\s* or
My last patch for today (-:
reLyX cannot handle document class names with non `word' characters
(not in [A-Za-z_]), such as article-hermes. This patch therefore replaces
\w by \S (non blank) in the regular expression.
Note this is not foolproof, either: perhaps better would be \s*(\S+)\s* or
60 matches
Mail list logo
