Am Freitag, 5. Mai 2006 15:07 schrieb Juergen Spitzmueller:
> It won't be worse than now, will it? I mean, the labels will work, but
they
> will display the citation key instead of the pretty natbib label. I
think I
> could live with that.
OK, then I'll do the simplified version.
Georg
Georg Baum wrote:
> What other features did you have in mind? I don't use natbib, but I use
> child documents a lot, and rely on the fact that crossreferences and
> citations work.
> I can't really tell whether incorrect natbib labels are a problem or not,
> but have a bad feeling. What do natbib u
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> What other features did you have in mind? I don't use natbib,
Georg> but I use child documents a lot, and rely on the fact that
Georg> crossreferences and citations work. I can't really tell whether
Georg> incorrect natbib labels are a
Jean-Marc Lasgouttes wrote:
> I would propose to follow the easy route and not try to load the
> buffer. In this case, the labels will not be correct when the bibtex
> inset is not found, but this is something that happens for other
> features with compound documents anyway. Let's keep things simp
Juergen Spitzmueller wrote:
> Georg Baum wrote:
>> The insetinclude changes are needed because it is possible that the
>> bibliography is in an included file.
>
> I wonder how often this happens in reality.
Probably not often, but I have that, and it might happen more often when we
have proper s
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> The insetinclude changes are needed because it is possible that
Georg> the bibliography is in an included file. Therefore we need to
Georg> load the included file when we fill the bib file cache.
I would propose to follow the easy ro
Georg Baum wrote:
> The insetinclude changes are needed because it is possible that the
> bibliography is in an included file.
I wonder how often this happens in reality.
> Therefore we need to load the included
> file when we fill the bib file cache.
> What is maybe not needed is the call of u
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Is that a plan?
Bo> I was doing a small trick, and now I need to clean up the whole
Bo> process. :-)
This is the whole point of the development process :)
JMarc
1. could become lyx_gui::create_view
2. can go back to lyx_main.C
3. can remain in lyx_gui::start
4. can go back to lyx_main.C
This will clean up the code, and then allow you to do session stuff
properly on top of that (and even to make it work for xforms and gtk).
Is that a plan?
I was do
Juergen Spitzmueller wrote:
> Jean-Marc Lasgouttes wrote:
>> Juergen, if seems to me that the following code
>> +void InsetInclude::updateBibfilesCache(Buffer const & buffer)
>> +{
>> + if (loadIfNeeded(buffer, params_)) {
>> [...]
>> + }
>> +}
>> +
>> +std::vector const &
>> +InsetInclude
Jean-Marc Lasgouttes wrote:
> Juergen, if seems to me that the following code
> +void InsetInclude::updateBibfilesCache(Buffer const & buffer)
> +{
> + if (loadIfNeeded(buffer, params_)) {
> [...]
> + }
> +}
> +
> +std::vector const &
> +InsetInclude::getBibfilesCache(Buff
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> Yes. I simply put the lastopenedfiles to the command line. That
Bo> was the easiest solution.
OK, here is the good solution. We need first a cleanup patch: if you
look at lyx_gui::start, you will find it is in 4 parts in all
frontends
1. crea
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
Bo> I do not get it. Files opened through session are indeed "files
Bo> opened via command-line or File->Open", just that they are opened
Bo> last time, and are *already* in the lastfiles list. Re-adding
Bo> these filenames will not change anything
On 5/2/06, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote:
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Because they are already there if they need to.
Bo> That is fine. Adding them the second time will not change
Bo> anything.
No, the list is a list of files opened via command-line or
It is simpler and easier to read IMO. If it works as intended and if
other agree, I think it could even go to 1.4, since it is reasonable
behaviour.
There is one glitch:
1. open a file.lyx, the file is clean
2. replace file.lyx by another file, say 'cp file1.lyx file.lyx',
2. re-open file.lyx,
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> There is a revert to file problem. It is not wise to check if it is
>> loading time for this though. I guess we can look at the status of
>> the existing file, if it has no changes, just switch to it.
Bo> What I meant was attached. I am not qui
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Because they are already there if they need to.
Bo> That is fine. Adding them the second time will not change
Bo> anything.
No, the list is a list of files opened via command-line or File>Open.
Session stuff should not interfere with that. Keep
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> Could you provide a 1.4 version so that I take a look?
Juergen> attached.
Juergen, if seems to me that the following code
+void InsetInclude::updateBibfilesCache(Buffer const & buffer)
Because they are already there if they need to.
That is fine. Adding them the second time will not change anything.
For example, if you use Help>Intro, the Intro file will not be
added to recent files. If
it is kept open, your patch means the file will be added at restart.
This is wrong.
Thi
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> >> There was the fact that document got added to the recently
>> loaded >> list, if I remember. I think this is related to the way
>> you add >> these files to the 'files' vector. It may be better (if
>> possible) >> to load them directly.
>> l
Jean-Marc Lasgouttes wrote:
> This looks good, and since both Georg and yourself have tested it, it
> can go in.
It's in.
Jürgen
> JMarc
There is a revert to file problem. It is not wise to check if it is
loading time for this though. I guess we can look at the status of the
existing file, if it has no changes, just switch to it.
What I meant was attached. I am not quite sure if the logic is
correct, otherwise, if should be used
>> There was the fact that document got added to the recently loaded
>> list, if I remember. I think this is related to the way you add
>> these files to the 'files' vector. It may be better (if possible)
>> to load them directly.
lastopenedfiles they should be loaded with second argument false
Abdelrazak Younes wrote:
My list of patches should comprise all bug fixes that haven't been
applied yet.
Yep, but you kind of defeat my whole argumentation as to why we need
1.5.0 now. Bad guy!
Abdel.
Sorry :-)
Michael
Michael Gerz a écrit :
Abdelrazak Younes wrote:
Tracing down all the bugs that got fixed in 1.5 is something that
needs to be done. For example, the cursor jumping problem on inset, is
it in Juergen?
My list of patches should comprise all bug fixes that haven't been
applied yet.
Yep, but
Abdelrazak Younes wrote:
Tracing down all the bugs that got fixed in 1.5 is something that
needs to be done. For example, the cursor jumping problem on inset, is
it in Juergen?
My list of patches should comprise all bug fixes that haven't been
applied yet.
Michael
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> On Fri, Apr 28, 2006 at 03:50:44PM +0200, Jean-Marc Lasgouttes
Enrico> wrote:
>> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>>
Enrico> If you mean cygwin in general, then you are practically
Enrico> forci
On Fri, Apr 28, 2006 at 03:50:44PM +0200, Jean-Marc Lasgouttes wrote:
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> Enrico> If you mean cygwin in general, then you are practically
> Enrico> forcing me to maintain my own 1.4 branch as I care about it.
>
> Not cygwin in gene
Jean-Marc Lasgouttes wrote:
>> "Georg" == Georg Baum
>> <[EMAIL PROTECTED]>
>> writes:
>
> Georg> I think this patch is still needed. Even if this is currently
> Georg> not implemented, there is a valid reason to automatically open
> Georg> child documents: Fill the TOC menu with sect
Jean-Marc Lasgouttes a écrit :
"Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Bo Peng wrote:
I have never used this feature and I assumed that this behavior is
designed to be so from day one. The patch has been committed, and
can be partly reverted once this is fixed. (Georg complain
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Bo Peng wrote:
>> I have never used this feature and I assumed that this behavior is
>> designed to be so from day one. The patch has been committed, and
>> can be partly reverted once this is fixed. (Georg complained that
>> he can no
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> There was the fact that document got added to the recently loaded
>> list, if I remember. I think this is related to the way you add
>> these files to the 'files' vector. It may be better (if possible)
>> to load them directly.
Bo> Sorry, I do
Bo Peng wrote:
> I have never used this feature and I assumed that this behavior is
> designed to be so from day one. The patch has been committed, and can
> be partly reverted once this is fixed. (Georg complained that he can
> not use session because of this.)
I think this patch is still needed
but no configuration should be lost).
There lastfiles are gone after an upgration? I would say that is nothing.
Bo
Bo Peng wrote:
>> > Abdel> - Bo's session management
>> >
>> > I am not sure about this one, since it seems that all problems have
>> > not been solved yet, and making a complete patch for 1.4 will probably
>> > be too difficult.
>
> Please specify which ones have not been fixed. There is only on
There was the fact that document got added to the recently loaded
list, if I remember. I think this is related to the way you add these
files to the 'files' vector. It may be better (if possible) to load
them directly.
Sorry, I do not get it. Are you talking about lastfiles (recently
opened file
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> > Abdel> - Bo's session management
>> >
>> > I am not sure about this one, since it seems that all problems
>> have > not been solved yet, and making a complete patch for 1.4
>> will probably > be too difficult.
Bo> Please specify which ones ha
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
>> Could you provide a 1.4 version so that I take a look?
Juergen> attached.
This looks good, and since both Georg and yourself have tested it, it
can go in.
JMarc
> Abdel> - Bo's session management
>
> I am not sure about this one, since it seems that all problems have
> not been solved yet, and making a complete patch for 1.4 will probably
> be too difficult.
Please specify which ones have not been fixed. There is only one: save
cursor stack, on my agend
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> If you mean cygwin in general, then you are practically
Enrico> forcing me to maintain my own 1.4 branch as I care about it.
Not cygwin in general, I am not _that_ mean... To be more precise:
what new stuff do you need in 1.4
Jean-Marc Lasgouttes wrote:
> Could you provide a 1.4 version so that I take a look?
attached.
Jürgen
> JMarc
Index: src/insets/insetbibtex.C
===
--- src/insets/insetbibtex.C (Revision 13775)
+++ src/insets/insetbibtex.C (Arbeitskop
Abdelrazak Younes wrote:
> Tracing down all the bugs that got fixed in 1.5 is something that needs
> to be done. For example, the cursor jumping problem on inset, is it in
> Juergen?
Yes.
Jürgen
On Fri, Apr 28, 2006 at 01:39:41PM +0200, Jean-Marc Lasgouttes wrote:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> Abdel> - Enrico and Georg: improved Cygwin Support
> >>> Which part of that is or is not in 1.4.x?
> >> I'll let Enrico and/or Georg answer that.
>
> Georg> IIRC m
Jean-Marc Lasgouttes a écrit :
Abdelrazak> So we could rename 1.5.0 as 1.4.2 and be done with the
Abdelrazak> backporting as there seems to be no format change.
No, because all the patches that have gone into 1.5 because they are
'obviously right' need to be evaluated. The day we release 1.5.0pr
On Fri, Apr 28, 2006 at 12:13:44PM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes a écrit :
> >>"Abdel" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >Abdel> - Enrico and Georg: improved Cygwin Support
> >
> >Which part of that is or is not in 1.4.x?
>
> I'll let Enrico and/or G
> "John" == John Spray <[EMAIL PROTECTED]> writes:
John> I was kind of hoping for unicode to happen before I did much
John> more work on the gtk frontend, since otherwise I would have to
John> go through doing loads of encoding conversion crack, just to
John> take it out again when we go unico
On Fri, 2006-04-28 at 12:13 +0200, Abdelrazak Younes wrote:
> > IMO, the one thing that could make the release of 1.5 without unicode
> > worth it would be the inclusion of the qt4 and gtk frontends if they
> > are 100% ready.
I was kind of hoping for unicode to happen before I did much more work
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Abdel> - Enrico and Georg: improved Cygwin Support
>>> Which part of that is or is not in 1.4.x?
>> I'll let Enrico and/or Georg answer that.
Georg> IIRC most (if not all) is not in 1.4. I must admit that I am a
Georg> bit tired doing 1.4
Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes a écrit :
>>> "Abdel" == Abdelrazak Younes <[EMAIL PROTECTED]>
>>> writes:
>>
>> Abdel> - Enrico and Georg: improved Cygwin Support
>>
>> Which part of that is or is not in 1.4.x?
>
> I'll let Enrico and/or Georg answer that.
IIRC most (i
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Tracing down all the bugs that got fixed in 1.5 is
Abdelrazak> something that needs to be done.
Michael does it.
Abdelrazak> For example, the cursor jumping problem on inset, is it in
Abdelrazak> Juergen?
This one
Jean-Marc Lasgouttes a écrit :
"Abdel" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdel> So what about listing some of the 1.5svn new
Abdel> feature/optimization and see if there's enough to justify a
Abdel> release, of the top of my head, they are:
Abdel> - Martin's outline work
Abdel>
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Jean-Marc Lasgouttes wrote:
Abdel> - Juergen's optimisation work on Natbib (is it in yet?)
>> This will go in 1.4.x once it is well tested, because it is a
>> really bad bug.
Juergen> IMO it's ready. I use it in my dail
Jean-Marc Lasgouttes wrote:
> Abdel> - Juergen's optimisation work on Natbib (is it in yet?)
>
> This will go in 1.4.x once it is well tested, because it is a really
> bad bug.
IMO it's ready. I use it in my daily work and did not discover any problem.
Jürgen
Abdelrazak Younes wrote:
> - Juergen's optimisation work on Natbib (is it in yet?)
It's in trunk, yes. Not yet in 1.4.x, though.
Jürgen
> "Abdel" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdel> So what about listing some of the 1.5svn new
Abdel> feature/optimization and see if there's enough to justify a
Abdel> release, of the top of my head, they are:
Abdel> - Martin's outline work
Abdel> - Edwin's paragraph moving
Georg Baum a écrit :
Andre Poenitz wrote:
I thought there had been file format changes which we want to avoid in
subminor releases.
No file format changes have happened yet.
So what about listing some of the 1.5svn new feature/optimization and
see if there's enough to justify a release, of
56 matches
Mail list logo
