On Thursday, 6 June 2024 18:01:42 BST Jürgen Spitzmüller wrote:
> Am Dienstag, dem 04.06.2024 um 12:16 +0100 schrieb John Robert Hudson:
> > Sorry, having installed 2.4, I am still getting the error message in
> > the LaTeX
> > log:
> >
> > Package natbib Warnin
Am Dienstag, dem 04.06.2024 um 12:16 +0100 schrieb John Robert Hudson:
> Sorry, having installed 2.4, I am still getting the error message in
> the LaTeX
> log:
>
> Package natbib Warning: There were undefined citations.
>
> Package bibtopic Warning: Please (re)run
Sorry, having installed 2.4, I am still getting the error message in the LaTeX
log:
Package natbib Warning: There were undefined citations.
Package bibtopic Warning: Please (re)run BibTeX on the file(s):
(bibtopic)Vol_25_2.2
(bibtopic)Vol_25_2.3
(bibtopic
Am Dienstag, dem 06.02.2024 um 20:31 + schrieb John Robert Hudson:
> Using RC~1 and today RC-2 with Multiple bibliographies per section
> set, I get
> a LyX warning that there are undefined citations in all but the first
> section.
> Looking at the LaTeX log, I find:
>
Using RC~1 and today RC-2 with Multiple bibliographies per section set, I get
a LyX warning that there are undefined citations in all but the first section.
Looking at the LaTeX log, I find:
Package natbib Warning: There were undefined citations.
Package bibtopic Warning: Please (re)run BibTeX
From 81d11d01d7cac03645fc29cdca34ba762a536fb7 Mon Sep 17 00:00:00 2001
From: John R Hudson
Date: Fri, 23 Dec 2022 20:58:43 +
Subject: [PATCH] Insert entries for APA with NatBiB, Fancy Colored Boxes and
Graphic Boxes to Chapter 4: Modules of Additional.lyx
---
lib/doc/Additional.lyx | 582
t;>> Author: Juergen Spitzmueller
> >>> Date: Tue May 7 14:48:39 2019 +0200
> >>>
> >>> Enable optional \cite* arguments in biblatex-natbib
> >> This is a candidate for stable, Riki.
> > Riki? I think this is safe enough for 2.3.3.
>
> OK then.
>
Thanks, done.
Jürgen
>
> Riki
>
>
>
gt;>> Enable optional \cite* arguments in biblatex-natbib
>> This is a candidate for stable, Riki.
> Riki? I think this is safe enough for 2.3.3.
OK then.
Riki
Am Dienstag, den 07.05.2019, 14:51 +0200 schrieb Jürgen Spitzmüller:
> > commit 6a4199ed233e5a9fe7fa0fbfd0266cd29560951b
> > Author: Juergen Spitzmueller
> > Date: Tue May 7 14:48:39 2019 +0200
> >
> > Enable optional \cite* arguments in biblatex-natbib
>
> commit 6a4199ed233e5a9fe7fa0fbfd0266cd29560951b
> Author: Juergen Spitzmueller
> Date: Tue May 7 14:48:39 2019 +0200
>
> Enable optional \cite* arguments in biblatex-natbib
>
This is a candidate for stable, Riki.
Jürgen
> ---
> lib/citeengines/biblatex-
uthor: Juergen Spitzmueller <sp...@lyx.org>
> > > Date: Fri Jan 13 18:23:42 2017 +0100
> > >
> > > Basic support for natbib & jurabib options
> > >
> > > This re-uses the options line edit introduced for biblatex.
> >
&g
Jan 13 18:23:42 2017 +0100
> >
> > Basic support for natbib & jurabib options
> >
> > This re-uses the options line edit introduced for biblatex.
>
> I believe this commit causes several ctests to fail. A git bisect of
> the
> ctest "elsarticle_lyx
On Fri, Jan 13, 2017 at 06:24:32PM +0100, Juergen Spitzmueller wrote:
> commit fc546b7dcc793a77b44c2f3e3abc780d768a18ed
> Author: Juergen Spitzmueller <sp...@lyx.org>
> Date: Fri Jan 13 18:23:42 2017 +0100
>
> Basic support for natbib & jurabib options
>
&g
:
The first time I View DVI after enabling or disabling natbib, I get
LaTeX errors. The second time I do a View DVI, the problem goes
away.
Do other people notice this bug in 1.5.0svn? This bug is easy to work
around, but can be worrying if you don't know you can just redo View
DVI to fix
:
> The first time I "View DVI" after enabling or disabling natbib, I get
> LaTeX errors. The second time I do a "View DVI", the problem goes
> away.
>
> Do other people notice this bug in 1.5.0svn? This bug is easy to work
> around, but can be worrying if you do
The first time I View DVI after enabling or disabling natbib, I get
LaTeX errors. The second time I do a View DVI, the problem goes
away.
Do other people notice this bug in 1.5.0svn? This bug is easy to work
around, but can be worrying if you don't know you can just redo View
DVI to fix result
The first time I "View DVI" after enabling or disabling natbib, I get
LaTeX errors. The second time I do a "View DVI", the problem goes
away.
Do other people notice this bug in 1.5.0svn? This bug is easy to work
around, but can be worrying if you don't know you can just re
Jürgen Spitzmüller wrote:
I found a small glitch in the backport that resulted in LyX not exporting the
correct natbib cite commands, but always \cite instead. Trunk is correct in
this regard.
I think Martin's backport was not at fault here. Trunk is correct
because I extended Martin's
Abdelrazak Younes wrote:
I think Martin's backport was not at fault here. Trunk is correct
because I extended Martin's cite_engine patch. Look at rev 17537 below.
Then trunk was buggy as well before that commit.
Maybe you should backport the rest of it?
Don't know. The one bug I was aware
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I think Martin's backport was not at fault here. Trunk is correct
because I extended Martin's cite_engine patch. Look at rev 17537 below.
Then trunk was buggy as well before that commit.
Yes.
Maybe you should backport the rest of it?
Abdelrazak Younes wrote:
Don't know. The one bug I was aware of is fixed now, and the fix looks
very clear to me. I'm not sure we need the rest of you changes for
branch.
Your call.
I'll keep it in mind, in case there are further problems. I'm testing it
rather instensely ATM on a real
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I think Martin's backport was not at fault here. Trunk is correct
because I extended Martin's cite_engine patch. Look at rev 17537 below.
Then trunk was buggy as well before that commit.
Maybe you should backport the rest of it?
Don't
Jürgen Spitzmüller wrote:
I found a small glitch in the backport that resulted in LyX not exporting the
correct natbib cite commands, but always \cite instead. Trunk is correct in
this regard.
I think Martin's backport was not at fault here. Trunk is correct
because I extended Martin's
Abdelrazak Younes wrote:
> I think Martin's backport was not at fault here. Trunk is correct
> because I extended Martin's cite_engine patch. Look at rev 17537 below.
Then trunk was buggy as well before that commit.
> Maybe you should backport the rest of it?
Don't know. The one bug I was
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I think Martin's backport was not at fault here. Trunk is correct
because I extended Martin's cite_engine patch. Look at rev 17537 below.
Then trunk was buggy as well before that commit.
Yes.
Maybe you should backport the rest of it?
Abdelrazak Younes wrote:
> > Don't know. The one bug I was aware of is fixed now, and the fix looks
> > very clear to me. I'm not sure we need the rest of you changes for
> > branch.
>
> Your call.
I'll keep it in mind, in case there are further problems. I'm testing it
rather instensely ATM on
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I think Martin's backport was not at fault here. Trunk is correct
because I extended Martin's cite_engine patch. Look at rev 17537 below.
Then trunk was buggy as well before that commit.
Maybe you should backport the rest of it?
Don't
I found a small glitch in the backport that resulted in LyX not exporting the
correct natbib cite commands, but always \cite instead. Trunk is correct in
this regard.
Patch against 1.4svn attached. OK?
Jürgen
Index: src/insets/insetcite.C
Jürgen == Jürgen Spitzmüller [EMAIL PROTECTED] writes:
Jürgen I found a small glitch in the backport that resulted in LyX
Jürgen not exporting the correct natbib cite commands, but always
Jürgen \cite instead. Trunk is correct in this regard.
Jürgen Patch against 1.4svn attached. OK?
Yes
I found a small glitch in the backport that resulted in LyX not exporting the
correct natbib cite commands, but always \cite instead. Trunk is correct in
this regard.
Patch against 1.4svn attached. OK?
Jürgen
Index: src/insets/insetcite.C
>>>>> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
Jürgen> I found a small glitch in the backport that resulted in LyX
Jürgen> not exporting the correct natbib cite commands, but always
Jürgen> \cite instead. Trunk is correct in this regard
or another.
Jürgen
Martin That would be like the attached... but note that I don't think
Martin that is right. I agree that numeric should be handled, but
Martin what happens here is that, also when natbib is pre-loaded by
Martin the document class, the _user_ is allowed to choose
happens here is that, also when natbib is pre-loaded by
Martin the document class, the _user_ is allowed to choose between
Martin numeric and author-year. I don't think that is right.
I have no idea on the actual logic, but nevertheless:
- biblio::CiteEngine const cite_engine
hout having a closer look at the patch, my opinion is that
> > >> Martin's approach is good (and necessary) in general. However, it
> > >> should enclose numerical citations in one way or another.
> > >>
> > >> Jürgen
> >
> > Martin> That would be
ral. However, it
> > > >> should enclose numerical citations in one way or another.
> > > >>
> > > >> Jürgen
> > >
> > > Martin> That would be like the attached... but note that I don't think
> > > Martin> tha
Jürgen == Jürgen Spitzmüller [EMAIL PROTECTED] writes:
Jürgen Jean-Marc, this patch is what I committed to trunk yesterday.
Jürgen I'd like to have it in 1.4 as well. O.K.?
Yes.
JMarc
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
Jürgen> Jean-Marc, this patch is what I committed to trunk yesterday.
Jürgen> I'd like to have it in 1.4 as well. O.K.?
Yes.
JMarc
, make sure to view files with the same application as
the Finder uses.
+- The natbib labels weren't always displayed correctly when opening
+ a document. This is fixed.
+
* Build/installation:
- Allow autoconf 2.60 and 2.61 for building.
Index: src/insets/ChangeLog
, make sure to view files with the same application as
the Finder uses.
+- The natbib labels weren't always displayed correctly when opening
+ a document. This is fixed.
+
* Build/installation:
- Allow autoconf 2.60 and 2.61 for building.
Index: src/insets/ChangeLog
Georg Baum wrote:
Here comes the long promised patch as discussed with Jean-Marc and Jürgen.
Jürgen, if that is OK with you I'll commit it.
Yes, please.
Jürgen
too.
It is in now. I did not change status.14x because this should be
conssidered as part of the natbib speedup patch.
Georg
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg It is in now. I did not change status.14x because this should
Georg be conssidered as part of the natbib speedup patch.
Very good.
JMarc
Georg Baum wrote:
> Here comes the long promised patch as discussed with Jean-Marc and Jürgen.
> Jürgen, if that is OK with you I'll commit it.
Yes, please.
Jürgen
with you I'll commit it.
>
> And if Jürgen is OK with it, it is OK for 1.4 too.
It is in now. I did not change status.14x because this should be
conssidered as part of the natbib speedup patch.
Georg
>>>>> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> It is in now. I did not change status.14x because this should
Georg> be conssidered as part of the natbib speedup patch.
Very good.
JMarc
Here comes the long promised patch as discussed with Jean-Marc and Jürgen.
Jürgen, if that is OK with you I'll commit it.
Georg
Log:
Prevent automatic opening of child docs because of natbib labels
* src/insets/insetinclude.h
(updateBibfilesCache): adjust comment
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg Here comes the long promised patch as discussed with Jean-Marc
Georg and Jürgen. Jürgen, if that is OK with you I'll commit it.
And if Jürgen is OK with it, it is OK for 1.4 too.
JMarc
Here comes the long promised patch as discussed with Jean-Marc and Jürgen.
Jürgen, if that is OK with you I'll commit it.
Georg
Log:
Prevent automatic opening of child docs because of natbib labels
* src/insets/insetinclude.h
(updateBibfilesCache): adjust comment
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Here comes the long promised patch as discussed with Jean-Marc
Georg> and Jürgen. Jürgen, if that is OK with you I'll commit it.
And if Jürgen is OK with it, it is OK for 1.4 too.
JMarc
Lars Gullik Bjønnes wrote:
| Where else?
At the very least the BufferView.
I don't understand. I think it's a buffer property. Each buffer has its own
bibfiles cache. And if we had (eventually) multiple views of the same buffer,
then all views should share the same bibfiles cache.
Jürgen
Juergen Spitzmueller [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| | Where else?
|
| At the very least the BufferView.
|
| I don't understand. I think it's a buffer property. Each buffer has its own
| bibfiles cache. And if we had (eventually) multiple views of the same buffer,
|
Lars Gullik Bjønnes wrote:
| I don't understand. I think it's a buffer property. Each buffer has its
| own bibfiles cache. And if we had (eventually) multiple views of the same
| buffer, then all views should share the same bibfiles cache.
The cache of bibfiles a buffer property? How? why?
Lars Gullik Bjønnes wrote:
> | Where else?
>
> At the very least the BufferView.
I don't understand. I think it's a buffer property. Each buffer has its own
bibfiles cache. And if we had (eventually) multiple views of the same buffer,
then all views should share the same bibfiles cache.
Jürgen
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > | Where else?
| >
| > At the very least the BufferView.
|
| I don't understand. I think it's a buffer property. Each buffer has its own
| bibfiles cache. And if we had (eventually) multiple views of the same
Lars Gullik Bjønnes wrote:
> | I don't understand. I think it's a buffer property. Each buffer has its
> | own bibfiles cache. And if we had (eventually) multiple views of the same
> | buffer, then all views should share the same bibfiles cache.
>
> The cache of bibfiles a buffer property? How?
Juergen Spitzmueller [EMAIL PROTECTED] writes:
| Right. And buffer is the wrong place for it.
|
| Where else?
At the very least the BufferView.
--
Lgb
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| > Right. And buffer is the wrong place for it.
|
| Where else?
At the very least the BufferView.
--
Lgb
Bennett Helm wrote:
I would say put it in trunk when you think it is tested enough.
I've been testing it (on Mac) and find nice speed improvements, with
no apparent problems. Well done!
OK, I'll put it in then.
Jürgen
| + /// update of natbib labels.
| + static std::vectorstd::string bibfilesCache_;
|
| If don't think that a static cache will work. That means basically that
| you have one cache for all buffers. If that is really what you want it
| can be achieved more easily by a global cache
this.
bibfilesCache_.insert(bibfilesCache_.end(),
bibfiles.begin(),
bibfiles.end());
or something.
I'll try it.
| + /// a cache for the bibfiles, needed for appropriate
| + /// update of natbib labels.
| + static std
Am Samstag, 15. April 2006 10:41 schrieb Juergen Spitzmueller:
Lars Gullik Bjønnes wrote:
Why is std::copy needed?
It was the first solution that came to my mind.
std::vector::assign or std::vector::insert should be able to do this.
Yes.
Right. And buffer is the wrong place for it.
Georg Baum wrote:
After a second thought I believe that a global cache would indeed work.
The only difference to a per-buffer cache would be that the files are
scanned again if any bibfile, not only a bibfile sued by the buffer has
changed. That could lead to unnecessary recreation of the
Am Samstag, 15. April 2006 16:08 schrieb Juergen Spitzmueller:
Georg Baum wrote:
If you are going to do that I would make the cache a static member of
InsetBibtex, and provide a static get method for it.
Would that work if we have several bibtex insets (i.e. bibtopic)?
Depends on how it
Georg Baum wrote:
The current solution is better, but a bit more code. I prefer it too, I
only outlined the above because Lars seemed to agree with the global
cache.
O.K.
Note that I wrote the message before you committed the current solution.
It spent some hours in a black hole and came
Bennett Helm wrote:
> > I would say put it in trunk when you think it is tested enough.
>
> I've been testing it (on Mac) and find nice speed improvements, with
> no apparent problems. Well done!
OK, I'll put it in then.
Jürgen
bibfiles.end());
or something.
| > + /// a cache for the bibfiles, needed for appropriate
| > + /// update of natbib labels.
| > + static std::vector bibfilesCache_;
|
| If don't think that a static cache will work. That means basically that
| you h
:assign or std::vector::insert should be able to do this.
>
> bibfilesCache_.insert(bibfilesCache_.end(),
> bibfiles.begin(),
> bibfiles.end());
>
> or something.
I'll try it.
> | > + /// a cache for the
Am Samstag, 15. April 2006 10:41 schrieb Juergen Spitzmueller:
> Lars Gullik Bjønnes wrote:
> > Why is std::copy needed?
It was the first solution that came to my mind.
> > std::vector::assign or std::vector::insert should be able to do this.
Yes.
> > Right. And buffer is the wrong place for
Georg Baum wrote:
> After a second thought I believe that a global cache would indeed work.
> The only difference to a per-buffer cache would be that the files are
> scanned again if any bibfile, not only a bibfile sued by the buffer has
> changed. That could lead to unnecessary recreation of the
Am Samstag, 15. April 2006 16:08 schrieb Juergen Spitzmueller:
> Georg Baum wrote:
> > If you are going to do that I would make the cache a static member of
> > InsetBibtex, and provide a static get method for it.
>
> Would that work if we have several bibtex insets (i.e. bibtopic)?
Depends on
Georg Baum wrote:
> The current solution is better, but a bit more code. I prefer it too, I
> only outlined the above because Lars seemed to agree with the global
> cache.
O.K.
> Note that I wrote the message before you committed the current solution.
> It spent some hours in a black hole and
.
StableDocIterator cursor_;
StableDocIterator anchor_;
+ /// a cache for the bibfiles, needed for appropriate
+ /// update of natbib labels.
+ static std::vectorstd::string bibfilesCache_;
If don't think that a static cache will work. That means basically that
you
Georg Baum wrote:
The right approach in general, but I think it needs some tweaking.
I'm all fine with your changes. They seem to work well for all cases I'm aware
of (the textcases of my fix), consider some things that I have forgotten
(especially wrt child documents) and improve the code.
I
Am Freitag, 14. April 2006 17:28 schrieb Juergen Spitzmueller:
I'm all fine with your changes. They seem to work well for all cases I'm
aware
of (the textcases of my fix), consider some things that I have forgotten
(especially wrt child documents) and improve the code.
Good to hear that it
On Apr 14, 2006, at 2:31 PM, Georg Baum wrote:
Am Freitag, 14. April 2006 17:28 schrieb Juergen Spitzmueller:
I'm all fine with your changes. They seem to work well for all
cases I'm
aware
of (the textcases of my fix), consider some things that I have
forgotten
(especially wrt child
cache with all bibfiles in use
> + std::vector const Buffer::getBibfilesCache() const;
Why don't you return a const reference? The extra Buffer:: qualification
will not work with gcc 4.1 and newer.
> ///
> void getLabelList(std::vector &) const;
>
> @@ -352,6 +357,9 @
Georg Baum wrote:
> The right approach in general, but I think it needs some tweaking.
I'm all fine with your changes. They seem to work well for all cases I'm aware
of (the textcases of my fix), consider some things that I have forgotten
(especially wrt child documents) and improve the code.
Am Freitag, 14. April 2006 17:28 schrieb Juergen Spitzmueller:
> I'm all fine with your changes. They seem to work well for all cases I'm
aware
> of (the textcases of my fix), consider some things that I have forgotten
> (especially wrt child documents) and improve the code.
Good to hear that
On Apr 14, 2006, at 2:31 PM, Georg Baum wrote:
Am Freitag, 14. April 2006 17:28 schrieb Juergen Spitzmueller:
I'm all fine with your changes. They seem to work well for all
cases I'm
aware
of (the textcases of my fix), consider some things that I have
forgotten
(especially wrt child
After some time of investigation and thanks to two delayed flights I came up
with the following solution that fixes the natbib slowness problem for me and
makes LyX 1.4 usable again.
What it does is:
- store the timestamp of any bibfile in the buffer
- in insetcite, store the timestamp
Juergen Spitzmueller wrote:
What it does is:
- store the timestamp of any bibfile in the buffer
- in insetcite, store the timestamp of the files at the time when the
bibliographies were scanned for the last time
- now only scan the files again if the timestamp of a file has changed or
if a
After some time of investigation and thanks to two delayed flights I came up
with the following solution that fixes the natbib slowness problem for me and
makes LyX 1.4 usable again.
What it does is:
- store the timestamp of any bibfile in the buffer
- in insetcite, store the timestamp
Juergen Spitzmueller wrote:
> What it does is:
> - store the timestamp of any bibfile in the buffer
> - in insetcite, store the timestamp of the files at the time when the
> bibliographies were scanned for the last time
> - now only scan the files again if the timestamp of a file has changed or
>
If you enable natbib in the document settings, no \usepackage{natbib}
header/preamble is included in the TeX document until you actually insert
an citation reference. This causes problems/errors when you have a
reference list but yet no references. I think the usepackage should be put
If you enable natbib in the document settings, no "\usepackage{natbib}"
header/preamble is included in the TeX document until you actually insert
an citation reference. This causes problems/errors when you have a
reference list but yet no references. I think the usepackage sho
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen A small but very annoying bug with natbib/qt: every time a
Juergen new entry is added to the selected browser, the style
Juergen choice is reset to the first combo item. The fix is to store
Juergen the position. This is a backport
Jean-Marc Lasgouttes wrote:
Juergen Please consider applying. Thanks, Juergen.
Feel free to apply it.
Thanks, done.
Juergen.
>>>>> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> A small but very annoying bug with natbib/qt: every time a
Juergen> new entry is added to the "selected" browser, the style
Juergen> choice is reset to the first com
Jean-Marc Lasgouttes wrote:
> Juergen> Please consider applying. Thanks, Juergen.
>
> Feel free to apply it.
Thanks, done.
Juergen.
A small but very annoying bug with natbib/qt: every time a new entry is added
to the selected browser, the style choice is reset to the first combo item.
The fix is to store the position.
This is a backport of a fix already in 1.4
Please consider applying.
Thanks,
Juergen.
Index: src/frontends
A small but very annoying bug with natbib/qt: every time a new entry is added
to the "selected" browser, the style choice is reset to the first combo item.
The fix is to store the position.
This is a backport of a fix already in 1.4
Please consider applying.
Thanks,
Juergen.
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Fixes the mess in syntax.default. -- Angus
This one does not look right:
+\citealt[][{}
Once this is fixed, you can apply it to 1.3.x.
JMarc
Jean-Marc Lasgouttes wrote:
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus Fixes the mess in syntax.default. -- Angus
This one does not look right:
+\citealt[][{}
Once this is fixed, you can apply it to 1.3.x.
JMarc
What would I do without you? ;-)
--
Angus
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus What would I do without you? ;-)
Apply patches faster :)
JMarc
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Fixes the mess in syntax.default. -- Angus
This one does not look right:
+\citealt[][{}
Once this is fixed, you can apply it to 1.3.x.
JMarc
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> Fixes the mess in syntax.default. -- Angus
>
> This one does not look right:
> +\citealt[][{}
>
> Once this is fixed, you can apply it to 1.3.x.
>
> JMarc
What would I do without you? ;-)
--
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> What would I do without you? ;-)
Apply patches faster :)
JMarc
this part:
+% Natbib citations can usually have two optional args, but LyX currently
+% supports only one.
+\citet[]{}
+\Citet[]{}
+\citet*[]{}
+\Citet*[]{}
+%\citet[][]{}
+%\Citet[][]{}
+%\citet*[][]{}
+%\Citet*[][]{}
+
+\citealt[][]{}
+\Citealt[][]{}
+\citealt*[][]{}
+\Citealt*[][]{}
+%\citealt
as LyX's.
I do not understand this part:
+% Natbib citations can usually have two optional args, but LyX
currently +% supports only one.
+\citet[]{}
+%\citet[][]{}
+
+\citealt[][]{}
+%\citealt[][{}
In the first group, you comment out the versions with two [] groups
On Mon, Feb 10, 2003 at 03:54:16PM +, Angus Leeming wrote:
Yes it has. I simply copied existing code. I also do not propose to
fix that as my aim is to improve the LyX-LaTeX-LyX round trip, not
to be able to import arbitrary TeX. If you want that, talk to André
about tex2lyx.
As you
1 - 100 of 471 matches
Mail list logo
