Re: [PATCH] Second try at tighter preamble

Jürgen Spitzmüller juer...@spitzmueller.org writes: Knowing that, shall I still apply to branch (and add some release-note warnings)? Hm, I'm not sure, actually. What would have been your decision? Since nobody ever complained over the extra stuff in the preamble, I propose to skip

Re: [PATCH] Second try at tighter preamble

Jean-Marc Lasgouttes wrote: Since nobody ever complained over the extra stuff in the preamble, I propose to skip it for branch. If someone does complain, we can apply it :) OK. Jürgen

Re: [PATCH] Second try at tighter preamble

Jürgen Spitzmüller writes: > Jean-Marc Lasgouttes wrote: >> This patch is in trunk. What about branch? (it is only 'optimization', >> so it is as you prefer, Juergen. > > Go ahead. I was about to do it, and now I have doubts. This patch will break documents where people

Re: [PATCH] Second try at tighter preamble

Jean-Marc Lasgouttes wrote: > I was about to do it, and now I have doubts. This patch will break > documents where people though it is clever to put some stuff in a Note > just to trigger the validate machinery (maybe because they use ERT that > does not trigger validate, or something). In the

Re: [PATCH] Second try at tighter preamble

Jürgen Spitzmüller <juer...@spitzmueller.org> writes: >> Knowing that, shall I still apply to branch (and add some release-note >> warnings)? > > Hm, I'm not sure, actually. What would have been your decision? Since nobody ever complained over the extra stuff in the pre

Re: [PATCH] Second try at tighter preamble

Jean-Marc Lasgouttes wrote: > Since nobody ever complained over the extra stuff in the preamble, I > propose to skip it for branch. If someone does complain, we can apply it > > :) OK. Jürgen

Re: [PATCH] Second try at tighter preamble

Jean-Marc Lasgouttes lasgout...@lyx.org writes: Jean-Marc Lasgouttes lasgout...@lyx.org writes: LyX isn't (currently) aware of what's being output and what isn't being output, at least not in this respect. So when it sees an endnote, it adds the package. What about this patch? Since my

Re: [PATCH] Second try at tighter preamble

Jean-Marc Lasgouttes wrote: This patch is in trunk. What about branch? (it is only 'optimization', so it is as you prefer, Juergen. Go ahead. Jürgen

Re: [PATCH] Second try at tighter preamble

Jean-Marc Lasgouttes writes: > Jean-Marc Lasgouttes writes: > >>> LyX isn't (currently) aware of what's being output and what isn't >>> being output, at least not in this respect. So when it sees an >>> endnote, it adds the package. >> >> What about this

Re: [PATCH] Second try at tighter preamble

Jean-Marc Lasgouttes wrote: > This patch is in trunk. What about branch? (it is only 'optimization', > so it is as you prefer, Juergen. Go ahead. Jürgen

Re: [PATCH] Second try at tighter preamble

Jean-Marc Lasgouttes lasgout...@lyx.org writes: Since my first patch had to be reverted, here is my second go at it. I propose to apply it to trunk and then to 1.6.2, but I am not in a hurry. I also took this opportunity to use InsetCollapsable::validate instead of InsetText::validate in 3

Re: [PATCH] Second try at tighter preamble

Jean-Marc Lasgouttes writes: > Since my first patch had to be reverted, here is my second go at it. > I propose to apply it to trunk and then to 1.6.2, but I am not in a > hurry. > > I also took this opportunity to use InsetCollapsable::validate instead > of

[PATCH] Second try at tighter preamble (was: Re: Modules loading preamble lines unnecessarily)

Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: LyX isn't (currently) aware of what's being output and what isn't being output, at least not in this respect. So when it sees an endnote, it adds the package. What about this patch? Since my first patch had to be reverted, here is my second go

[PATCH] Second try at tighter preamble (was: Re: Modules loading preamble lines unnecessarily)

Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: >> LyX isn't (currently) aware of what's being output and what isn't >> being output, at least not in this respect. So when it sees an >> endnote, it adds the package. > > What about this patch? Since my first patch had to be reverted, here is my

Re: Modules loading preamble lines unnecessarily

{endnotes} line get added to the preamble. However, if you add an endnote within a LyX Note (and nowhere else in the document), the endnote will not appear in the LaTeX output, and yet the \usepackage{endnotes} line is added to the preamble anyway -- unnecessarily. Should this not happen

Re: Modules loading preamble lines unnecessarily

: you have to add an endnote, and only then does the \usepackage{endnotes} line get added to the preamble. However, if you add an endnote within a LyX Note (and nowhere else in the document), the endnote will not appear in the LaTeX output, and yet the \usepackage{endnotes} line is added

Re: Modules loading preamble lines unnecessarily

doesn't change anything yet: you have to add an endnote, and only then does the \usepackage{endnotes} line get added to the preamble. However, if you add an endnote within a LyX Note (and nowhere else in the document), the endnote will not appear in the LaTeX output, and yet the \usepackage

Re: Modules loading preamble lines unnecessarily

LyX isn't (currently) aware of what's being output and what isn't being output, at least not in this respect. So when it sees an endnote, it adds the package. What about this patch? JMarc nopreamble.diff Description: Binary data

Re: Modules loading preamble lines unnecessarily

Jean-Marc Lasgouttes wrote: LyX isn't (currently) aware of what's being output and what isn't being output, at least not in this respect. So when it sees an endnote, it adds the package. What about this patch? Looks simple enough. rh

Re: Modules loading preamble lines unnecessarily

What about this patch? Looks simple enough. I'll apply it when I can build. Juergen, is it OK for branch? JMarc

Re: Modules loading preamble lines unnecessarily

Jean-Marc Lasgouttes wrote: I'll apply it when I can build. Juergen, is it OK for branch? Yes, looks good. Jürgen

Re: Modules loading preamble lines unnecessarily

{endnotes} line get added to the preamble. However, if you add an endnote within a LyX Note (and nowhere else in the document), the endnote will not appear in the LaTeX output, and yet the \usepackage{endnotes} line is added to the preamble anyway -- unnecessarily. Should this not happen

Re: Modules loading preamble lines unnecessarily

ding the endnotes module doesn't change anything yet: >> you have to add an endnote, and only then does the >> \usepackage{endnotes} line get added to the preamble. >> >> However, if you add an endnote within a LyX Note (and nowhere else in >> the document), the en

Re: Modules loading preamble lines unnecessarily

dnotes module doesn't change anything yet: you have to add an endnote, and only then does the \usepackage{endnotes} line get added to the preamble. However, if you add an endnote within a LyX Note (and nowhere else in the document), the endnote will not appear in the LaTeX output, and yet the \usep

Re: Modules loading preamble lines unnecessarily

LyX isn't (currently) aware of what's being output and what isn't being output, at least not in this respect. So when it sees an endnote, it adds the package. What about this patch? JMarc nopreamble.diff Description: Binary data

Re: Modules loading preamble lines unnecessarily

Jean-Marc Lasgouttes wrote: LyX isn't (currently) aware of what's being output and what isn't being output, at least not in this respect. So when it sees an endnote, it adds the package. What about this patch? Looks simple enough. rh

Re: Modules loading preamble lines unnecessarily

What about this patch? Looks simple enough. I'll apply it when I can build. Juergen, is it OK for branch? JMarc

Re: Modules loading preamble lines unnecessarily

Jean-Marc Lasgouttes wrote: > I'll apply it when I can build. Juergen, is it OK for branch? Yes, looks good. Jürgen

Modules loading preamble lines unnecessarily

to the preamble. However, if you add an endnote within a LyX Note (and nowhere else in the document), the endnote will not appear in the LaTeX output, and yet the \usepackage{endnotes} line is added to the preamble anyway -- unnecessarily. Should this not happen? Bennett

Modules loading preamble lines unnecessarily

to the preamble. However, if you add an endnote within a LyX Note (and nowhere else in the document), the endnote will not appear in the LaTeX output, and yet the \usepackage{endnotes} line is added to the preamble anyway -- unnecessarily. Should this not happen? Bennett

Re: [patch] Easy access to lyx generated preamble

Vincent van Ravesteijn - TNW wrote: Hi, I added a small feature that I think is useful. It adds a tab to the Document-Settings-Latex Preamble module, which shows the preamble that will be generated by LyX (see attached image). I did this, because when I want to see the preamble of a large

Re: [patch] Easy access to lyx generated preamble

Vincent van Ravesteijn - TNW wrote: Hi, I added a small feature that I think is useful. It adds a tab to the Document->Settings->Latex Preamble module, which shows the preamble that will be generated by LyX (see attached image). I did this, because when I want to see the preamble of a

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr wrote: The logic was not clear. There is no need to treat jurabib different than japanese etc. I corrected this and tested that it works as expected: http://www.lyx.org/trac/changeset/25707 If this for a certain reason not correct, please shout. If you verified that no problems

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

If you verified that no problems occur with the now even earlier loading of babel, OK. babel is loaded now at the same position as before when jurabib was used and that's what you wanted. I can see no drawback here since the other packages we load automatically with LyX are independent of

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr wrote: > The logic was not clear. There is no need to treat jurabib different than > japanese etc. I corrected this and tested that it works as expected: > http://www.lyx.org/trac/changeset/25707 > > If this for a certain reason not correct, please shout. If you verified that no

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

> If you verified that no problems occur with the now even earlier loading of > babel, OK. babel is loaded now at the same position as before when jurabib was used and that's what you wanted. I can see no drawback here since the other packages we load automatically with LyX are independent of

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

fixed at revision 25632: http://www.lyx.org/trac/changeset/25632 The logic was not clear. There is no need to treat jurabib different than japanese etc. I corrected this and tested that it works as expected: http://www.lyx.org/trac/changeset/25707 If this for a certain reason not correct,

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

fixed at revision 25632: http://www.lyx.org/trac/changeset/25632 The logic was not clear. There is no need to treat jurabib different than japanese etc. I corrected this and tested that it works as expected: http://www.lyx.org/trac/changeset/25707 If this for a certain reason not correct,

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

I guess we don't get to a consensus in this point. That's not correct. The answer of Georg convinced me. I wasn't aware that including files is currently not in every case possible and thus not acceptable. To please do the changes you porposed to handle babel well. That means: - restore lyX

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

When you present a case where this is really needed, I can and will agree with the solutions you proposed. chapterbib.sty. Besides this discussion, the documentation of this package doesn't state this. So you should send the package author a note that the babel support gets fixed. (Donald

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr [EMAIL PROTECTED] writes: Besides this discussion, the documentation of this package doesn't state this. So you should send the package author a note that the babel support gets fixed. (Donald will surely do this quickly.) I read: 11. If you use Babel, load chapterbib before

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr wrote: That's not correct. The answer of Georg convinced me. I'm glad to see this. I wasn't aware that including files is currently not in every case possible and thus not acceptable. To please do the changes you porposed to handle babel well. That means: - restore lyX 1.5's

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

> I guess we don't get to a consensus in this point. That's not correct. The answer of Georg convinced me. I wasn't aware that including files is currently not in every case possible and thus not acceptable. To please do the changes you porposed to handle babel well. That means: - restore

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

>> When you present a case where this is really needed, I can and will >> agree with the solutions you proposed. > > chapterbib.sty. Besides this discussion, the documentation of this package doesn't state this. So you should send the package author a note that the babel support gets fixed.

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr <[EMAIL PROTECTED]> writes: > Besides this discussion, the documentation of this package doesn't > state this. So you should send the package author a note that the > babel support gets fixed. (Donald will surely do this quickly.) I read: 11. If you use Babel, load chapterbib before

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr wrote: > That's not correct. The answer of Georg convinced me. I'm glad to see this. > I wasn't aware that > including files is currently not in every case possible and thus not > acceptable. To please do the changes you porposed to handle babel well. > That means: > > - restore lyX

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

I use for example in all my German documents commands to translate the word Index to Stichwort- und Befehlsverzeichnis or similar. Therefore I have a a babel call in my preamble in 1.5 documents. You don't need this babel call. You can use \AtBeginDocument, and it will work both

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr [EMAIL PROTECTED] writes: I checked http://www.ctan.org/tex-archive/macros/latex/contrib/cite/ but can't find any hint about this there. If the package author didn't say anything about babel and it makes problems, that the package author should be informed to fix the babel support

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr [EMAIL PROTECTED] writes: Loading a package before babel is not possible anymore. When you present a case where this is really needed, I can and will agree with the solutions you proposed. chapterbib.sty. Not that I use it personally. It seems that cite.sty has been updated to

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr wrote: and thus we wouldn't have this discussion. To repeat my self, we don't have any problem, except of people that loaded babel manually in the preamble. Yes, this is the only problem bug 5024 talks about. But it is an important one. No. It is not acceptable that users who do

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr wrote:   You don't need this babel call. You can use \AtBeginDocument, and it will work both with and without hyperref. But why do we have the problem then? When people would have used \AtBeginDocument, they wouldn't had a manual babel call in their preamble and thus we wouldn't

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

>> I use for example in all my German >> documents commands to translate the word "Index" to Stichwort- und >> Befehlsverzeichnis" or similar. Therefore I have a a babel call in my >> preamble in 1.5 documents. > > You don't need this babel call. Y

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr <[EMAIL PROTECTED]> writes: > I checked http://www.ctan.org/tex-archive/macros/latex/contrib/cite/ > but can't find any hint about this there. If the package author didn't > say anything about babel and it makes problems, that the package > author should be informed to fix the babel

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr <[EMAIL PROTECTED]> writes: >> Loading a package before babel is not possible anymore. > > When you present a case where this is really needed, I can and will > agree with the solutions you proposed. chapterbib.sty. Not that I use it personally. It seems that cite.sty has been updated

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr wrote: > and thus we wouldn't have this discussion. To repeat my self, we don't > have any problem, except of people that loaded babel manually in the > preamble. Yes, this is the only problem bug 5024 talks about. But it is an important one. > > No. It is not accept

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr wrote: >  > You don't need this babel call. You can use \AtBeginDocument, and it > will work > both with and without hyperref. > > But why do we have the problem then? When people would have used > \AtBeginDocument, they wouldn't had a manual babel call in their p

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

OK, so the problems would be fixed if we would assure that babel is always loaded before hyperref, as Georg suggested, and change the vietnamese support, as you suggested in the comment. But how will you do that? In LyX 1.5 we load babel after the user preamble, but hyperref must be loaded

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr wrote: But how will you do that? In LyX 1.5 we load babel after the user preamble, but hyperref must be loaded before the user preamble and babel before hyperref. And that's what we currently have and works well. That's easy. Something like this (plus the Vietnamese change): Index

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Jürgen Spitzmüller wrote: +       if (use_babel features.isRequired(hyperref)) { Actually, this needs to be: +if (use_babel !features.isRequired(jurabib) + features.isRequired(hyperref)) { Jürgen

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

That's easy. Something like this (plus the Vietnamese change): That's not that easy as this could break the document compilation. So when hyperref is used, we load babel before the user preamble without hyperref behind it. So you have to adapt your preamble when you turn on/off hyperref

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr wrote: That's not that easy as this could break the document compilation. So when hyperref is used, we load babel before the user preamble without hyperref behind it. So you have to adapt your preamble when you turn on/off hyperref. This is extremely tricky as this affects many LaTeX

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

That's not that easy as this could break the document compilation. So when hyperref is used, we load babel before the user preamble without hyperref behind it. So you have to adapt your preamble when you turn on/off hyperref. This is extremely tricky as this affects many LaTeX-packages

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

preamble in 1.5 documents. You don't need this babel call. You can use \AtBeginDocument, and it will work both with and without hyperref. In LyX 1.6 now have to add or delete it every time I use the PDF properties of LyX 1.6 or not. In my opinion this is not acceptable to change the document

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

OK, so the problems would be fixed if we would assure that babel is always loaded before hyperref, as Georg suggested, and change the vietnamese support, as you suggested in the comment. But how will you do that? In LyX 1.5 we load babel after the user preamble, but hyperref must be loaded

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr wrote: > But how will you do that? In LyX 1.5 we load babel after the user preamble, > but hyperref must be loaded before the user preamble and babel before > hyperref. And that's what we currently have and works well. That's easy. Something like this (plus the Vietname

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Jürgen Spitzmüller wrote: > +       if (use_babel && features.isRequired("hyperref")) { Actually, this needs to be: +if (use_babel && !features.isRequired("jurabib") +&& features.isRequired("hyperref")) { Jürgen

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

> That's easy. Something like this (plus the Vietnamese change): That's not that easy as this could break the document compilation. So when hyperref is used, we load babel before the user preamble without hyperref behind it. So you have to adapt your preamble when you turn on/off hyper

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

Uwe Stöhr wrote: > That's not that easy as this could break the document compilation. So when > hyperref is used, we load babel before the user preamble without hyperref > behind it. So you have to adapt your preamble when you turn on/off > hyperref. This is extremely tricky as this

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

>> That's not that easy as this could break the document compilation. So when >> hyperref is used, we load babel before the user preamble without hyperref >> behind it. So you have to adapt your preamble when you turn on/off >> hyperref. This is extremely tricky as

Re: [Bug 5024] TeX error of LyX 1.5 documents when babel was loaded manually in preamble

efore I have a a babel call in my > preamble in 1.5 documents. You don't need this babel call. You can use \AtBeginDocument, and it will work both with and without hyperref. > In LyX 1.6 now have to add or delete it every > time I use the PDF properties of LyX 1.6 or not. In my opinio

Re: a bug in LyX 1.5.2 - when branches are active, the encoding is wrong, also a question regarding branching the preamble

Michal Skrzypek wrote: I wanted to report something relatively harmless, but strange. I am currently using LyX 1.5.2 (XP SP2, Polish version). I apologize that I cannot check this with the current version, but for now I cannot upgrade/test it due to time constraints, as I am nearing the

Re: a bug in LyX 1.5.2 - when branches are active, the encoding is wrong, also a question regarding branching the preamble

Michal Skrzypek wrote: > I wanted to report something relatively harmless, but strange. I am > currently using LyX 1.5.2 (XP SP2, Polish version). I apologize that I > cannot check this with the current version, but for now I cannot > upgrade/test it due to time constraints, as I am nearing the

OK to revert in lyx2lyx to ERT/document preamble?

://bugzilla.lyx.org/show_bug.cgi?id=4612 So we have to decide if we revert new stuff to preamble and ERT code or not. In case we don't we should really release LyX 1.6svn as LyX 2.0. What are your opinions about the the lyx2lyx reversions to ERT/preamble code? regards Uwe

Re: OK to revert in lyx2lyx to ERT/document preamble?

Take for example the PDF Options in the document settings: Everything you insert here is lost when reverting to lyX 1.5 format. I reported this as http://bugzilla.lyx.org/show_bug.cgi?id=4612 except hyperresf stuff, what are the other? So we have to decide if we revert new stuff to preamble

Re: OK to revert in lyx2lyx to ERT/document preamble?

2. In particular case of hyperref once you implement conversion from 1.6 to 1.5 preamble it has logical implication to be able to take these changes back in the direction of 1.5 - 1.6. No, this direction is of course not possible and not needed. Important is that the output

Re: OK to revert in lyx2lyx to ERT/document preamble?

, lyx2lyx then takes care of the conversion to prior formats. In the case of hyperref, we would convert it to preamble code and this is in general left untouched by lyx2lyx (also ERT) and thus works with every LyX format. 2. In particular case of hyperref once you implement conversion from

Re: OK to revert in lyx2lyx to ERT/document preamble?

my scenario was different though: 1. user1 edit file + set hyperref in 1.6. send file to user2 for revision. 2. user2 edit file in 1.5. hyperref gets in preamble. user2 send revision back. 3. user1 open file and doesnt see hyperref set and setup it again. This is indeed possible

OK to revert in lyx2lyx to ERT/document preamble?

://bugzilla.lyx.org/show_bug.cgi?id=4612 So we have to decide if we revert new stuff to preamble and ERT code or not. In case we don't we should really release LyX 1.6svn as LyX 2.0. What are your opinions about the the lyx2lyx reversions to ERT/preamble code? regards Uwe

Re: OK to revert in lyx2lyx to ERT/document preamble?

rt new stuff to preamble and ERT code or > not. In case we don't we should really release LyX 1.6svn as LyX 2.0. i would save 2.0 for xml transition. > What are your opinions about the the lyx2lyx reversions to ERT/preamble > code? i dont think this is needed for the following reasons: 1.

Re: OK to revert in lyx2lyx to ERT/document preamble?

> > 2. In particular case of hyperref > >once you implement conversion from 1.6 to 1.5 preamble it has logical > >implication to be able to take these changes back in the direction of > >1.5 -> 1.6. > > No, this direction is of course not possi

Re: OK to revert in lyx2lyx to ERT/document preamble?

n we have a conversion routine to LyX 1.5, lyx2lyx then takes care of the conversion to prior formats. In the case of hyperref, we would convert it to preamble code and this is in general left untouched by lyx2lyx (also ERT) and thus works with every LyX format. > 2. In particular case of

Re: OK to revert in lyx2lyx to ERT/document preamble?

> my scenario was different though: > 1. user1 edit file + set hyperref in 1.6. send file to user2 for revision. > 2. user2 edit file in 1.5. hyperref gets in preamble. user2 send revision back. > 3. user1 open file and doesnt see hyperref set and setup it again. This is ind

[patch] Preamble snippets in charstyles

FuncStatus.h #include Cursor.h #include gettext.h -#include LaTeXFeatures.h #include Color.h #include Lexer.h #include Text.h @@ -242,14 +241,6 @@ } -void InsetCharStyle::validate(LaTeXFeatures features) const -{ - // Force inclusion of preamble snippet in layout file - features.require

Re: [patch] Preamble snippets in charstyles

On Wednesday 22 August 2007 18:38:01 Martin Vermeer wrote: We're getting closer and closer to really useful customizable insets ;-) Goes in if nobody sees a problem. OK. - Martin -- José Abílio

[patch] Preamble snippets in charstyles

le.cpp (working copy) @@ -22,7 +22,6 @@ #include "FuncStatus.h" #include "Cursor.h" #include "gettext.h" -#include "LaTeXFeatures.h" #include "Color.h" #include "Lexer.h" #include "Text.h" @@ -242,14 +241,6 @@ } -void InsetChar

Re: [patch] Preamble snippets in charstyles

On Wednesday 22 August 2007 18:38:01 Martin Vermeer wrote: > We're getting closer and closer to really useful customizable insets ;-) > > Goes in if nobody sees a problem. OK. > - Martin -- José Abílio

bug in encoding of preamble?

I don't know if this is a bug or not, but when renaming the list of tables (which I misuse as a Japanese version of the toc) from the preamble, the name comes out as raw euc-jp. If I do the same from an ERT in the document, it works as expected. \def\listtablename{目次} Maybe it is because

bug in encoding of preamble?

I don't know if this is a bug or not, but when renaming the list of tables (which I misuse as a Japanese version of the toc) from the preamble, the name comes out as raw euc-jp. If I do the same from an ERT in the document, it works as expected. \def\listtablename{目次} Maybe it is because

Re: [Updated Patch] bug 3201: restore cursor position in preamble

Abdelrazak Younes wrote: Juergen Spitzmueller wrote: Abdelrazak Younes wrote: This patch does that and a bit more. It ensures that the coords are saved and restored in any case (closeEvent and buffer switching). It also does move the preamble related code in apply() and updateParam

Re: [Updated Patch] bug 3201: restore cursor position in preamble

Abdelrazak Younes wrote: Jose, Jurgen, what should I do with this patch? If you tested it well enough, it is ok for me. Jürgen

Re: [Updated Patch] bug 3201: restore cursor position in preamble

On Monday 14 May 2007 10:26:34 Jürgen Spitzmüller wrote: If you tested it well enough, it is ok for me. OK. Jürgen -- José Abílio

Re: [Updated Patch] bug 3201: restore cursor position in preamble

José Matos wrote: On Monday 14 May 2007 10:26:34 Jürgen Spitzmüller wrote: If you tested it well enough, it is ok for me. OK. Done. Abdel.

Re: [Updated Patch] bug 3201: restore cursor position in preamble

Abdelrazak Younes wrote: Juergen Spitzmueller wrote: Abdelrazak Younes wrote: This patch does that and a bit more. It ensures that the coords are saved and restored in any case (closeEvent and buffer switching). It also does move the preamble related code in apply() and updateParam

Re: [Updated Patch] bug 3201: restore cursor position in preamble

Abdelrazak Younes wrote: > Jose, Jurgen, what should I do with this patch? If you tested it well enough, it is ok for me. Jürgen

Re: [Updated Patch] bug 3201: restore cursor position in preamble

On Monday 14 May 2007 10:26:34 Jürgen Spitzmüller wrote: > If you tested it well enough, it is ok for me. OK. > Jürgen -- José Abílio

Re: [Updated Patch] bug 3201: restore cursor position in preamble

José Matos wrote: On Monday 14 May 2007 10:26:34 Jürgen Spitzmüller wrote: If you tested it well enough, it is ok for me. OK. Done. Abdel.

Re: Why BufferParam::preamble is a std::string?

On Friday 04 May 2007 16:15:12 Abdelrazak Younes wrote: The preamble is part of the LyX file right? So it is susceptible to contain non latin unicode characters. Do we a bug number and a user report for that one? ;-) What would it be different between latin and non latin unicode? I

Re: Why BufferParam::preamble is a std::string?

On Friday 04 May 2007 16:15:12 Abdelrazak Younes wrote: > The preamble is part of the LyX file right? So it is susceptible to > contain non latin unicode characters. Do we a bug number and a user report for that one? ;-) What would it be different between latin and non latin unicode

[Updated Patch] bug 3201: restore cursor position in preamble

Juergen Spitzmueller wrote: Abdelrazak Younes wrote: This patch does that and a bit more. It ensures that the coords are saved and restored in any case (closeEvent and buffer switching). It also does move the preamble related code in apply() and updateParam() in the new PreambleModule class

Why BufferParam::preamble is a std::string?

The preamble is part of the LyX file right? So it is susceptible to contain non latin unicode characters. Shouldn't we transform that to docstring? Abdel.

<    1   2   3   4   5   6   7   8   9   >