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
>
>
>
>> 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
> > > 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.
> >
> > I believe this c
> > 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_lyx22" lead me to this comm
On Fri, Jan 13, 2017 at 06:24:32PM +0100, Juergen Spitzmueller wrote:
> commit fc546b7dcc793a77b44c2f3e3abc780d768a18ed
> Author: Juergen Spitzmueller
> Date: Fri Jan 13 18:23:42 2017 +0100
>
> Basic support for natbib & jurabib options
>
> This re-u
e-Dansted wrote:
> 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 wor
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 ju
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 kno
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
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:
> 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:
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 Mar
>>>>> "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
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
y) in general. 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
> > >
thout 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> 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
OS X, 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
>>>>> "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
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 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
> "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 co
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
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:
> | 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:
| > Right. And buffer is the wrong place for it.
|
| Where else?
At the very least the BufferView.
--
Lgb
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 cam
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 h
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 l
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
gn 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 fo
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
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
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 docum
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 i
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
;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 @@ private:
> /// it's BufferView, this should be FIXED in future.
>
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
> i
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 of the
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
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
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> What would I do without you? ;-)
Apply patches faster :)
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? ;-)
--
A
> "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
Fixes the mess in syntax.default.
--
Angus
? build-qt
? build-xforms
? relyx-accents.diff
? relyx-natbib-test.lyx
? relyx-natbib-test.tex
? relyx-natbib.diff
? relyx-starredmath-test.tex
? relyx-starredmath.diff
? relyx-table-test.tex
? relyx-table.diff
Index: status.13x
On Mon, Feb 10, 2003 at 04:08:40PM +, John Levon wrote:
> I suppose you don't mean something as simple as this
I think I mean it. Works well.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
On Mon, Feb 10, 2003 at 04:08:40PM +, John Levon wrote:
> > Could anybody please set up the Make machinery for a new directory
> > src/tex2lyx and a binary target tex2lyx somewhere?
>
> I suppose you don't mean something as simple as this
I think I mean something as simple as that.
Simplicit
Andre Poenitz wrote:
> 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
>> A
On Mon, Feb 10, 2003 at 04:59:08PM +0100, Andre Poenitz wrote:
> Could anybody please set up the Make machinery for a new directory
> src/tex2lyx and a binary target tex2lyx somewhere?
I suppose you don't mean something as simple as this
Index: config/configure.ac
=
>>>>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>> What if I have \usepackage{amsmath, natbib}? My reading of the
>> regexp suggests that it will not work. To be fair, it seems that
>> all the preamble reading code has this flaw, isn&#
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 y
gt; out Angus> with. The reLyX support for this package is now exactly
> the Angus> same 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[][]{}
&
is now exactly the
Angus> same 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[]{}
+\citet*[]{}
+\Citet*[]{}
+%\citet[][]{}
+%\Citet[][]{}
+%\citet*[][]{}
+%\Citet*[][]{}
+
ap, useful for entering Polish on a QWERTY keyboard
+- enable reLyX to handle natbib citations
+
** Bug fixes
- fix bug where opening the tabular dialog would mark the document as
@@ -41,4 +43,4 @@ What's new
- fix strerror() build problem with some gcc/glibc versions [bug #874]
-ly
The following entry breaks LyX's natbib support (the citation style choice
gets disabled). And yes, this is a real example from my real work.
Regards,
Jürgen.
@Article{stk:ausstatter01,
Author = {s.t.k.},
Title = {Aus.statter [sic!]},
Journal= {Frankf
On Fri, Jul 19, 2002 at 01:05:25PM +0100, Angus Leeming wrote:
> André has been doing some work on integrating such insetcommand insets into
> the mathed way of doing things. This would give you a much more powerful
> parser of such things for free. Perhaps you might like to ask him for further
On Friday 19 July 2002 1:28 pm, Edwin Leuven wrote:
> How easy/difficult would it be to have the "text before" option working
> with natbib?
>
> I think that it would be nice to have this in 1.3...
A hack is easy. Output to the LyX file something like "before |++| a
How easy/difficult would it be to have the "text before" option working with
natbib?
I think that it would be nice to have this in 1.3...
Ed.
On Wed, Jul 17, 2002 at 03:29:09PM -0600, Hai-Ru Chang wrote:
> Hello,
> Can you add \citep and \citet of natbib as options in your cite reference
> popup panel. Thanks!
\citep and \citet are already supported in lyx 1.2.0
(you need to enable the "Use natbib" but
Hello,
Can you add \citep and \citet of natbib as options in your cite reference
popup panel. Thanks!
Dr. Hai-Ru Chang
Duane Physics #D322
311-UCB
Program in Atmospheric and Oceanic Sciences
Boulder, CO 80303
Tel: 303-492-0544
On Monday 10 June 2002 9:40 am, R. Lahaye wrote:
> Juergen Spitzmueller writes:
> > R. Lahaye wrote:
> > > Hmmm, if LyX by its own is able to decide whether it needs natbib, then
> > > why do we need a manual checkbox for "use natbib"? Why not using n
o ascertain
> whether we need a \usepackage{natbib}."
>
> So I understood that LyX can determine whether it needs natbib or not.
> If indeed so, there's no need to bother the user to select it manually.
Angus means that LyX inserts \usepackage{natbib} only if the user inserts a
Juergen Spitzmueller writes:
>
> R. Lahaye wrote:
> > Hmmm, if LyX by its own is able to decide whether it needs natbib, then why
> > do we need a manual checkbox for "use natbib"? Why not using natbib
> > automagically when needed?
>
> And how should
R. Lahaye wrote:
> Hmmm, if LyX by its own is able to decide whether it needs natbib, then why
> do we need a manual checkbox for "use natbib"? Why not using natbib
> automagically when needed?
And how should LyX decide this?
Juergen.
Angus Leeming writes:
> On Saturday 08 June 2002 5:29 pm, Juergen Spitzmueller wrote:
> >
> > Despite enabling "use natbib" in Document, \usepackage{natbib} is inserted
> > to the preamble only if the user has inserted a citation inset.
>
> It is intended in
On Sunday 09 June 2002 2:25 pm, you wrote:
> Angus Leeming wrote:
> >>I wonder if this is intended, and why:
> >>
> >>Despite enabling "use natbib" in Document, \usepackage{natbib} is
> >> inserted to the preamble only if the user has inserted
Angus Leeming wrote:
>>I wonder if this is intended, and why:
>>
>>Despite enabling "use natbib" in Document, \usepackage{natbib} is inserted
>>to the preamble only if the user has inserted a citation inset.
>>This has bugged me while I wanted to crea
On Saturday 08 June 2002 5:29 pm, Juergen Spitzmueller wrote:
> Hi,
>
> I wonder if this is intended, and why:
>
> Despite enabling "use natbib" in Document, \usepackage{natbib} is inserted
> to the preamble only if the user has inserted a citation inset.
> This
Hi,
I wonder if this is intended, and why:
Despite enabling "use natbib" in Document, \usepackage{natbib} is inserted to
the preamble only if the user has inserted a citation inset.
This has bugged me while I wanted to create a list of the whole database with
a nifty \nocite*
I adm
Angus Leeming wrote:
> You mean like this? (It appears that great thought can be shared ;-)
Yes. Very good work (only the citation insets don't reflect it quite well here
yet).
> You might say that LyX is "better" than LaTeX here ;-)
Ah, well. Maybe on fridays (BTW: I've counted two smileys).
On Friday 26 April 2002 2:47 pm, Juergen Spitzmueller wrote:
> Juergen Spitzmueller wrote:
> > Here is my proposal.
>
> Having written this, I think about using the key instead of "No Author".
> This would be even more WYSIWYG and more informative perhaps. What do you
> think?
>
> Juergen.
You me
Juergen Spitzmueller wrote:
> Here is my proposal.
Having written this, I think about using the key instead of "No Author". This
would be even more WYSIWYG and more informative perhaps. What do you think?
Juergen.
Angus Leeming wrote:
> Cæsar is dead; let him lie!
OK. I'm not interested in tyrants anyway.
> Why don't we do it as natbib does it. (How does it deal with entries that
> have neither an author/editor nor a year?)
Natbib tries to be clever here: if there's no autho
>title = "The Programming of Computer Art",
>year = "1987",
> }
>
> @UNPUBLISHED{unpublished-minimal,
>author = "Ulrich {\"{U}}nderwood and Ned {\~N}et and Paul {\={P}}ot",
>title = "Lower Bounds for Wishful Research R
Since Caesar has been killed, there are problems with some special kind of
entries: those who cannot be parsed correctly by biblio.C. The citation style
choice is empty in that case and I cannot chose a style.
I have collected a few of those entries, some are from xampl.bib
Just one example: If
atch itself is trivial, but you might be
> > > able to address my question about how "ProvidesNatbib 1" in the layout
> > > file might automatically turn on the GUI support provided by clicking
> > > on "Use Natbib".
> >
> > Mike, I _thi
my question about how "ProvidesNatbib 1" in the layout file might
> > automatically turn on the GUI support provided by clicking on "Use
> > Natbib".
>
> Mike, I _think_ that all you need to do is modify InsetCitation::validate
I'll give this a try, perhaps tomorrow.
ombardment...
>
> No problem. As a return favor, could you look at the ProvidesNatbib patch
> I sent out Friday? The patch itself is trivial, but you might be able to
> address my question about how "ProvidesNatbib 1" in the layout file might
> automatically turn on the GUI sup
On Tuesday 23 April 2002 9:19 am, Lars Gullik Bjønnes wrote:
> Silence is not approval.
> I want to hear J-M's opinion, since he has look at this case
> earlier...
Fair enough. I just wanted to trigger some response.
Jean-Marc, the patch I submitted yesterday contained a bug that lead to the
oc
the patch is fine, although I've
>> > > modified it to work with numerical natbib citations and to cache the
>> > > label.
>> > >
>> > > Attached are my re-workings.
>> >
>> > [snip]
>> >
>> > I have tested
On Monday 22 April 2002 10:35 am, Angus Leeming wrote:
> On Tuesday 16 April 2002 10:31 am, Angus Leeming wrote:
> > On Monday 15 April 2002 4:40 pm, Angus Leeming wrote:
> > > I think that the screen label part of the patch is fine, although I've
> > > modified
On Tuesday 16 April 2002 10:31 am, Angus Leeming wrote:
> On Monday 15 April 2002 4:40 pm, Angus Leeming wrote:
> > I think that the screen label part of the patch is fine, although I've
> > modified it to work with numerical natbib citations and to cache the
> > label.
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> 3. Most importantly, I want to
Angus> minimise the footprint of any changes I'm making. The current
Angus> patch affects the citation inset only and either works or
Angus> doesn't work.
That makes sense.
Angus> Having said all th
On Tuesday 16 April 2002 1:26 pm, Edwin Leuven wrote:
> > All works very well here, but I'd like some volunteer testers please. No
> > testers, no apply...
>
> applied patch but compile breaks down...
I think that this is saying that Buffer::getBibkeyList() is non-const so a
Buffer const * can't
> All works very well here, but I'd like some volunteer testers please. No
> testers, no apply...
applied patch but compile breaks down...
g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../../boost -isystem
/usr/X11R6/include -g -O -fno-exceptions -W -Wall -c insetcite.C -MT
insetci
On Tuesday 16 April 2002 12:58 pm, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> I have tested this patch pretty thoroughly myself and have
> Angus> decided that it's only real shortcoming is that it results in
> Angus> VERY slow loading of a b
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I have tested this patch pretty thoroughly myself and have
Angus> decided that it's only real shortcoming is that it results in
Angus> VERY slow loading of a buffer. This occurs because we reload
Angus> Buffer::getBibkeyList from a
On Monday 15 April 2002 4:40 pm, Angus Leeming wrote:
> I think that the screen label part of the patch is fine, although I've
> modified it to work with numerical natbib citations and to cache the label.
>
> Attached are my re-workings.
[snip]
I have tested this patch pretty
On Sunday 14 April 2002 5:17 pm, Herbert Voss wrote:
> a diff which
> - gives wysiwyg natbib labels and standard behaviour
> without natbib.
> - supports the "before" input textfield in the gui
> - fixes another bug with familyName in biblio.C
>
>
> the cita
1 - 100 of 249 matches
Mail list logo
