Jürgen Spitzmüller schrieb:
Why not the linebreak? For my taste, that line is too long.
Alright, I also added the line break :-)
AFAIK, \newcommand only allows one optional argument. However, this
doesn't hurt IMHO because LyX will always sets all three arguments.
It's possible, but i
Michael Gerz wrote:
> > It looks o.k., although I would probably have written it as:
> >
> > "\\newcommand\\lyxinserted[3]{\\changestart#3\\changeend}\n"
> > "\\newcommand\\lyxdeleted[3]{%\n"
> > "\\changestart\\overstrikeon#3\\overstrikeoff\\changeend}\n"
>
> Ok, I removed the {}'s.
Why not the l
Michael Gerz wrote:
> Unfortunately, the patch produces some artifacts with dvipost. See file
> cttest.lyx. When exporting to DVI, the text inside the box is not
> aligned with the outer text. If you deactivate change tracking output,
> everything is fine.
But this is not related to your patch, i
Hi,
this patch fixes two problems with end-of-par handling. I tested it
successfully and rigorously.
I already committed it to speed up development. If you think that
something is wrong, I will revert the patch instantly.
Michael
Index: text.C
===
Michael Gerz schrieb:
attached please find a simple patch that improves CT in LyX 1.4.
Essentially, the patch consists of three parts:
1. The change bar is smarter (reduced width, more margin)
2. "next change" is introduced
3. accept/reject change is de-activated in non-CT mode
Here comes an up
Jean-Marc Lasgouttes schrieb:
Therefore I think you should remove accept/reject change from the
menu: they will cause more confusion than anything else. The result is
that the shortcuts for accept/reject all changes will be weird, but we
are not going to remake all translations.
I tested accep
Jean-Marc Lasgouttes wrote:
> This points out why I really really should not accept seemingly
> trivial patches that come out of nowhere a few days before release :)
Indeed. It seems that emails from you with subjects "Towards LyX 1.4.x
[status update #x]" generate these patches.
People, if you h
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> Jean-Marc Lasgouttes schrieb: Jean-Marc, attached please find
Michael> a simple patch that improves CT in LyX 1.4. Essentially, the
Michael> patch consists of three parts:
>> Michael, as I told you yesterday, I think we should s
Jean-Marc Lasgouttes schrieb:
Michael> Jean-Marc, attached please find a simple patch that improves
Michael> CT in LyX 1.4. Essentially, the patch consists of three
Michael> parts:
Michael, as I told you yesterday, I think we should skip this patch
for 1.4.3.
Did you? I remember you said you l
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> Jean-Marc, attached please find a simple patch that improves
Michael> CT in LyX 1.4. Essentially, the patch consists of three
Michael> parts:
Michael, as I told you yesterday, I think we should skip this patch
for 1.4.3. Also, a
Jean-Marc,
attached please find a simple patch that improves CT in LyX 1.4.
Essentially, the patch consists of three parts:
1. The change bar is smarter (reduced width, more margin)
The code changes are trivial and please your eyes :-)
2. "next change" is introduced
This feature makes i
On Mon, Mar 13, 2006 at 08:45:26AM +0100, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > So I propose to remove the line
> >
> > setChange(0, Change::INSERTED);
>
> But then you have to check if bug 1827 doesn't come back.
>
> Jürgen
I have the line deleted, and bug 1827 (according to t
On Mon, 2006-03-13 at 20:26 +0100, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > No it is not. The attached is (cursed evo interface!)
>
> Yes, that's better :-)
> Works for me, from a quick test.
Do you think it is tested enough to go into 1.5?
Attached the version with relevant comme
On Sat, 2006-03-11 at 19:11 +0200, Martin Vermeer wrote:
> On Sat, Mar 11, 2006 at 11:51:39AM +0100, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> >
> > Martin> A large part of the backspace method was factored out into
> > Martin> backspacePos0. So
On Mon, Mar 13, 2006 at 07:29:02PM +0100, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > - if (start == end || !par_.isChanged(start, end - 1))
> > + if (start == end || !par_.isChanged(start, end))
>
> Are you sure this is the right patch?
No it is not. The attached is (curs
Martin Vermeer wrote:
> - if (start == end || !par_.isChanged(start, end - 1))
> + if (start == end || !par_.isChanged(start, end))
Are you sure this is the right patch?
Jürgen
Martin Vermeer wrote:
> No it is not. The attached is (cursed evo interface!)
Yes, that's better :-)
Works for me, from a quick test.
Jürgen
On Mon, 2006-03-13 at 12:22 +0200, Martin Vermeer wrote:
> On Mon, 2006-03-13 at 10:55 +0200, Martin Vermeer wrote:
> > On Mon, 2006-03-13 at 09:18 +0100, Juergen Spitzmueller wrote:
> > > Juergen Spitzmueller wrote:
> > > > Martin Vermeer wrote:
> > > > > So I propose to remove the line
> > > > >
On Mon, 2006-03-13 at 10:55 +0200, Martin Vermeer wrote:
> On Mon, 2006-03-13 at 09:18 +0100, Juergen Spitzmueller wrote:
> > Juergen Spitzmueller wrote:
> > > Martin Vermeer wrote:
> > > > So I propose to remove the line
> > > >
> > > > setChange(0, Change::INSERTED);
> > >
> > > But then you have
On Mon, 2006-03-13 at 09:18 +0100, Juergen Spitzmueller wrote:
> Juergen Spitzmueller wrote:
> > Martin Vermeer wrote:
> > > So I propose to remove the line
> > >
> > > setChange(0, Change::INSERTED);
> >
> > But then you have to check if bug 1827 doesn't come back.
>
> It probably could even be r
Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > So I propose to remove the line
> >
> > setChange(0, Change::INSERTED);
>
> But then you have to check if bug 1827 doesn't come back.
It probably could even be removed (I don't like it either).
However, while testing if bug 1823 will be revi
Am Montag, 13. März 2006 08:40 schrieb Martin Vermeer:
> Would it be possible to simply disable DESM/DEPM when CT is on, so the
> one cannot subvert the other? Would save us a lot of heartache.
I think it would already help much if DESM/DEPM would only remove INSERTED
blanks, leave DELETED ones a
Martin Vermeer wrote:
> So I propose to remove the line
>
> setChange(0, Change::INSERTED);
But then you have to check if bug 1827 doesn't come back.
Jürgen
On Mon, 2006-03-13 at 08:13 +0100, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > What was the original reason for introducing it?
> > Can we get rid of it?
>
> It's not my doing. It's this:
>
> Log message:
> (Johnathan Burchill): change tracker fixes (bug 1827)
>
> Bugs:
> htt
Martin Vermeer wrote:
> What was the original reason for introducing it?
> Can we get rid of it?
It's not my doing. It's this:
Log message:
(Johnathan Burchill): change tracker fixes (bug 1827)
Bugs:
http://bugzilla.lyx.org/show_bug.cgi?id=1827
But in general, change tracking and DESM/D
On Mon, 2006-03-13 at 08:52 +0200, Martin Vermeer wrote:
> This fixes the non-existent change bar in case only the paragraph break
> has been changed. From a bug report by Jürgen (under bugzilla 880, but
> see also 1254-1255), thanks.
Jürgen, about the routine stripLeadingSpaces in paragraph.C: co
This fixes the non-existent change bar in case only the paragraph break
has been changed. From a bug report by Jürgen (under bugzilla 880, but
see also 1254-1255), thanks.
If I hear no objections this goes in presently.
- Martin
Index: rowpainter.C
===
On Sat, Mar 11, 2006 at 11:51:39AM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> A large part of the backspace method was factored out into
> Martin> backspacePos0. Some 50+ lines, that changes indent and show up
> Martin> as insertio
On Sat, Mar 11, 2006 at 11:51:39AM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> A large part of the backspace method was factored out into
> Martin> backspacePos0. Some 50+ lines, that changes indent and show up
> Martin> as insertio
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> A large part of the backspace method was factored out into
Martin> backspacePos0. Some 50+ lines, that changes indent and show up
Martin> as insertions/deletions in the patch. Out of total 203- and
Martin> 256+.
If it is the sam
On Fri, Mar 10, 2006 at 10:30:11PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> Martin> It is smaller now with 2212 split out. Much of the bigness is
> Martin> an optical illusion though, see what happened around
> Martin> backspacePos
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> > Maybe something like > + BOOST_ASSERT(pos < size() || pos ==
>> size() && tracking());
Martin> Actually no. Due to the changes in the rest of the patch,
Martin> erase is called with pos == size(), but with tracking off it
Martin> d
On Fri, Mar 10, 2006 at 04:47:29PM +0200, Martin Vermeer wrote:
> On Fri, 2006-03-10 at 15:03 +0100, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> >bool Paragraph::Pimpl::erase(pos_type pos)
> >{
> > - BOOST_ASSERT(pos < size());
> >
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> Maybe something like + BOOST_ASSERT(pos < size() || pos == size()
>> && tracking());
Martin> Sharper test, you mean?
Yes, to remain as sharp as it used to be without CT.
JMarc
On Fri, Mar 10, 2006 at 03:49:39PM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> >> It seems OK to me (in trunk). I think 2212 should committed
> >> separately in both trunk and branch.
>
> Martin> I'll prepare a separate patch first.
I co
On Fri, 2006-03-10 at 16:47 +0200, Martin Vermeer wrote:
> On Fri, 2006-03-10 at 15:03 +0100, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> > Also, are you confident that you understand why eraseSelectionHelper
> > is much smaller now?
>
> Par
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> It seems OK to me (in trunk). I think 2212 should committed
>> separately in both trunk and branch.
Martin> I'll prepare a separate patch first.
I tested the one in the bug under qt and xforms and it seems to work.
What is not nice
On Fri, 2006-03-10 at 15:03 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Attached the patch with fixed Cut behaviour in C&P (see bug
> Martin> ): behaves correctly for arbitrary combinations of
> Martin> unchanged, inserted and d
On Fri, 2006-03-10 at 14:56 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> Martin> Attached the change tracking patch (multi-paragraph i.e. 880)
> Martin> but fixes 2212 (skip over first change) as well.
>
> Martin> Lars, others: OK to com
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Attached the patch with fixed Cut behaviour in C&P (see bug
Martin> ): behaves correctly for arbitrary combinations of
Martin> unchanged, inserted and deleted text or paragraph breaks
Martin> within the cut area. The eraseSel
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> On Tue, 2006-03-07 at 14:06 +0100, Jean-Marc Lasgouttes wrote:
>> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>>
Martin> Could you please re-list them? It isn't clear to me which ones
Martin> you are referring t
On Tue, Mar 07, 2006 at 05:06:26PM +0200, Martin Vermeer wrote:
> On Tue, 2006-03-07 at 14:06 +0100, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> >
> > Martin> Could you please re-list them? It isn't clear to me which ones
> > Martin> you are refer
On Tue, 2006-03-07 at 14:06 +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Could you please re-list them? It isn't clear to me which ones
> Martin> you are referring to here.
>
> I have to leave now, but it would be something like 880
On Thu, Jul 21, 2005 at 04:12:01PM +0100, John Levon wrote:
> non-editable. Andre, please look it over
>
> Index: lyxfunc.C
> ===
> RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
> retrieving revision 1.663
> diff -u -a -p
On Thu, Jul 21, 2005 at 04:46:32PM +0100, John Levon wrote:
> On Thu, Jul 21, 2005 at 05:31:33PM +0200, Jean-Marc Lasgouttes wrote:
>
> > Why don't you add the editable() stuff directly to InsetBase? Both
> > math and normal insets derive from that these days.
>
> There's a nasty comment saying I
On Thu, Jul 21, 2005 at 05:56:57PM +0200, Jean-Marc Lasgouttes wrote:
> John> There's a nasty comment saying I'm not allowed to add data
> John> members
>
> Indeed :) What kind of support do you want to obtain anyway? You do
> not plan to support change tracking _inside_ insets, I guess?
Sure I
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Thu, Jul 21, 2005 at 05:31:33PM +0200, Jean-Marc Lasgouttes
John> wrote:
>> Why don't you add the editable() stuff directly to InsetBase? Both
>> math and normal insets derive from that these days.
John> There's a nasty comment sayin
On Thu, Jul 21, 2005 at 05:31:33PM +0200, Jean-Marc Lasgouttes wrote:
> Why don't you add the editable() stuff directly to InsetBase? Both
> math and normal insets derive from that these days.
There's a nasty comment saying I'm not allowed to add data members
regards
john
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> This version includes basic support for making math formulae
John> non-editable. Andre, please look it over
Why don't you add the editable() stuff directly to InsetBase? Both
math and normal insets derive from that these days.
JMarc
This version includes basic support for making math formulae
non-editable. Andre, please look it over
thanks
john
Index: lyxfunc.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxfunc.C,v
retrieving revision 1.663
diff -u -a -
Hi folks,
Working on paragraph breaks for the change tracker is not trivial, so I
decided to tackle bug 1301 (which is marked trivial :) for a change of pace.
Here is a patch and .ui file (attached) that implements Alfredo's and John's
idea of a marker (see "bug" 1301) that reflects whether cha
Johnathan Burchill wrote:
> The simplest way to reproduce it is:
> 2. insert "a".
> 3. track changes.
> 4. cut "a" and paste it at the beginning of the par
> 5. paste "a" at beginning again.
> 6. paste "a" at beginning again ---> problem appears (4 "a"'s all marked
> inserted).
I have committed th
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Juergen Spitzmueller wrote:
>> As to the crash fix: can someone please have a look if this can be applied?
>> (fixes the crash described in bug 1277).
>
| Lars?
| (see http://marc.theaimsgroup.com/?l=lyx-devel&m=110894706811499&w=2 for the
| patc
Juergen Spitzmueller wrote:
> As to the crash fix: can someone please have a look if this can be applied?
> (fixes the crash described in bug 1277).
Lars?
(see http://marc.theaimsgroup.com/?l=lyx-devel&m=110894706811499&w=2 for the
patch).
Jürgen
Johnathan Burchill wrote:
> The simplest way to reproduce it is:
> 2. insert "a".
> 3. track changes.
> 4. cut "a" and paste it at the beginning of the par
> 5. paste "a" at beginning again.
> 6. paste "a" at beginning again ---> problem appears (4 "a"'s all marked
> inserted).
>
> It seems to be a
On Monday 21 February 2005 07:08, you wrote:
> Johnathan Burchill wrote:
> > I've attached the bug fix. There's no point in providing the
> > break-paragraph patch until it's fully functional. If you want to play
> > with it, see my first attachment in this thread. Whether or not you want
> > to im
Johnathan Burchill wrote:
> I've attached the bug fix. There's no point in providing the
> break-paragraph patch until it's fully functional. If you want to play with
> it, see my first attachment in this thread. Whether or not you want to
> implement the functionality in 1.4.0, I'll work on it in
Lars Gullik Bjønnes wrote:
>Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
>
>| Lars Gullik Bjønnes wrote:
>>
>>> I am very happy to see bugs fixed. but I am a bit wary of adding
>>> functionality at this stage.
>>
>| It's a bug fix really. The unability to break paragraphs is a severe (and
>|
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
>
>> I am very happy to see bugs fixed. but I am a bit wary of adding
>> functionality at this stage.
>
| It's a bug fix really. The unability to break paragraphs is a severe (and
| the biggest remaining AFAICS) limitat
On Tue, Feb 15, 2005 at 03:21:22PM +0100, Juergen Spitzmueller wrote:
> > I am very happy to see bugs fixed. but I am a bit wary of adding
> > functionality at this stage.
>
> It's a bug fix really. The unability to break paragraphs is a severe (and
> the biggest remaining AFAICS) limitation of
Lars Gullik Bjønnes wrote:
> I am very happy to see bugs fixed. but I am a bit wary of adding
> functionality at this stage.
It's a bug fix really. The unability to break paragraphs is a severe (and
the biggest remaining AFAICS) limitation of the change tracker (see bug
880).
> Are you able to
Johnathan Burchill <[EMAIL PROTECTED]> writes:
| Hi folks,
>
| Please find attached three files: a change-tracking patch, and a new inset
| declaration and implementation.
>
| Use -p0 from the top-level source dir for applying the patch.
| insetnewparagraph.{C,h} need to be placed in src/insets/
Johnathan Burchill wrote:
> This patch addresses bug#1277, and adds functionality to ct.
> The bug-fix addresses pasting while change-tracking. The main modification
> is the "Change" parameter that has been added to moveItem().
>
> The new functionality is to let the user break a paragraph within
Hi folks,
Please find attached three files: a change-tracking patch, and a new inset
declaration and implementation.
Use -p0 from the top-level source dir for applying the patch.
insetnewparagraph.{C,h} need to be placed in src/insets/.
This patch addresses bug#1277, and adds functionality to
On Thu, Jan 27, 2005 at 05:13:07PM +0100, Juergen Spitzmueller wrote:
> Angus Leeming wrote:
> > Oh, if the file is meant to change only at predetermined times, then a
> > single line added to lyx_cb.C's Reconfigure would do the trick:
> >
> > LatexFeatures::getAvailable();
> >
> > no?
> >
> >
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Jose' Matos wrote:
>> That us premature optimization Jürgen. :-)
>>
>> It is easier to simply clear the list since the effect is the same, there
>> is no need to consider the different cases. The code then becomes easier to
>> understand by anyo
Jose' Matos wrote:
> When I wrote that my wrist watch still showed 27, I have since then fixed
> it. I see you want a fight...
No. But I think there are quite a lot of good opportunities ATM.
Jürgen
On Friday 28 January 2005 10:22, Juergen Spitzmueller wrote:
>
> P.S.: Isn't it Friday today?
When I wrote that my wrist watch still showed 27, I have since then fixed
it. I see you want a fight...
--
José Abílio
Jose' Matos wrote:
> That us premature optimization Jürgen. :-)
>
> It is easier to simply clear the list since the effect is the same, there
> is no need to consider the different cases. The code then becomes easier to
> understand by anyone. :-)
Really? OK, then I change that.
Jürgen
P.S.: I
On Friday 28 January 2005 08:52, Juergen Spitzmueller wrote:
>
> while in case (1) it is not necessary to clear the list (because it is
> already empty) it is necessary in (2). That's the reason why I added the
> check (to avoid redundant clearing in case 1, which is the more common
> one).
That
Lars Gullik Bjønnes wrote:
> Any particualr reason not to just clear it?
>
> // Make sure that we are clean
> packages_.clear();
Currently, getAvailable is called from two places:
(1) LaTeXFeatures::isAvailable
if (packages_.empty())
getAvailable();
(when LyX checks
Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
>> Oh, if the file is meant to change only at predetermined times, then a
>> single line added to lyx_cb.C's Reconfigure would do the trick:
>>
>> LatexFeatures::getAvailable();
>>
>> no?
>>
>> But you're probably right. N
Angus Leeming wrote:
> Oh, if the file is meant to change only at predetermined times, then a
> single line added to lyx_cb.C's Reconfigure would do the trick:
>
> LatexFeatures::getAvailable();
>
> no?
>
> But you're probably right. Not worth it. At the moment.
I did it nevertheless. Patch at
Angus Leeming wrote:
> Oh, if the file is meant to change only at predetermined times, then a
> single line added to lyx_cb.C's Reconfigure would do the trick:
>
> LatexFeatures::getAvailable();
>
> no?
Ah, yes, probably. Maybe I'll have a look after my return (weekend).
Regards,
Jürgen
Juergen Spitzmueller wrote:
> Angus Leeming wrote:
>> What you could do is "watch" packages.lst and read it again when it
>> changes. See RenderMonitoredPreview (src/insets/render_preview.[Ch]).
>>
>> Basically, you'd store a
>> // Check the file every 2 secs
>> lyx::support::FileMonitor monitor_(
Angus Leeming wrote:
> What you could do is "watch" packages.lst and read it again when it
> changes. See RenderMonitoredPreview (src/insets/render_preview.[Ch]).
>
> Basically, you'd store a
> // Check the file every 2 secs
> lyx::support::FileMonitor monitor_(std::string(), 2000);
>
> Onc
Juergen Spitzmueller wrote:
> Angus Leeming wrote:
>> ..and what's a PackagesList? Is the compiler looking for
>>
>> LaTeXFeatures::PackagesList LaTeXFeatures::packages_;
>>
>> perhaps?
>
> Umm. Thank you both.
> The static list works now. The only drawback (vs. non-static) is that you
> have to
Angus Leeming wrote:
> ..and what's a PackagesList? Is the compiler looking for
>
> LaTeXFeatures::PackagesList LaTeXFeatures::packages_;
>
> perhaps?
Umm. Thank you both.
The static list works now. The only drawback (vs. non-static) is that you have
to restart LyX to get packages.lst reparse
Juergen Spitzmueller wrote:
> * format incremented to 240.
> * new bufferparam:
> \output_changes {true|false}
> (should the change tracking marks be visible in the output or not?)
> * lyx2lyx should just delete the param in 239.
Here is the patch. Untested, but should work ;-)
Georg? output_ch
Juergen Spitzmueller wrote:
> I might be totally blind, but I cannot get it to compile.
...and what's a PackagesList? Is the compiler looking for
LaTeXFeatures::PackagesList LaTeXFeatures::packages_;
perhaps?
--
Angus
Juergen Spitzmueller wrote:
>> PackagesList LaTeXFeatures::packages_;
Try
LaTeXFeatures::PackagesList LaTeXFeatures::packages_;
because PackagesList is a type defined inside the class LaTeXFeatures.
Georg
Angus Leeming wrote:
> It isn't static in the patch you posted.
Sure isn't ;-)
> Anyway, this is what you need:
>
> LaTeXFeatures.h
>
> class LaTeXFeatures {
> ...
> static PackagesList packages_;
> };
>
> LaTeXFeatures.C (immediately below the #includes):
>
> PackagesList LaTeXFeatures
Georg Baum wrote:
> I can do that this evening if I know what you wrote in development/FORMAT.
> I guess it is only the new parameter in the header?
Yes. Here's what I wrote:
* format incremented to 240.
* new bufferparam:
\output_changes {true|false}
(sho
Juergen Spitzmueller wrote:
> Jean-Marc Lasgouttes wrote:
>> When you do that
>> -int const LYX_FORMAT = 239;
>> +int const LYX_FORMAT = 240;
>> don't forget to update development/FORMAT
>
> Sure (already done). I'll need someone to adapt lyx2lyx, though.
I can do that this evening if I know wha
Jean-Marc Lasgouttes wrote:
> When you do that
> -int const LYX_FORMAT = 239;
> +int const LYX_FORMAT = 240;
> don't forget to update development/FORMAT
Sure (already done). I'll need someone to adapt lyx2lyx, though.
Jürgen
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> Done. Updated patch (without the getAvailable() changes)
Juergen> attached.
When you do that
-int const LYX_FORMAT = 239;
+int const LYX_FORMAT = 240;
don't forget to update development/FORMAT
JMarc
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> It isn't static in the patch you posted. Anyway, this is what
Angus> you need:
Angus> LaTeXFeatures.h
Angus> class LaTeXFeatures { ... static PackagesList packages_; };
Angus> LaTeXFeatures.C (immediately below the #includes):
A
Juergen Spitzmueller wrote:
>> I am not sure putting this list in LaTeXFeatures like that is the best
>> solution, since packages.lst will be parsed everytime one exports to
>> latex... You may want to turn packages_ into a static variable and
>> make getPackage static too.
>
> I tried this, but t
Jean-Marc Lasgouttes wrote:
> > "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
> The patch looks good. A few remarks:
>
> + case LFUN_OUTPUT_CHANGES: {
> + LaTeXFeatures features(*buf, buf->params(), false);
> + if (!features.isAvailable("dvipost"))
>
> "Juergen" == Juergen Spitzmueller <[EMAIL PROTECTED]> writes:
Juergen> The attached patch fixes some real problems with the output
Juergen> of change tracked documents and implements a possibility to
Juergen> check whether a (required) package is installed.
Good idea.
Juergen> - If dvipost
The attached patch fixes some real problems with the output of change tracked
documents and implements a possibility to check whether a (required) package
is installed.
The problems, which always occur when a user is in change tracking mode (also
cf. bug 1031):
- If dvipost is not installed, e
Allan Rae <[EMAIL PROTECTED]> writes:
| Does GCC really have long living branches with multiple merges from
| the trunk into the branch?
yes.
| If so, they must know something a lot of others don't.
perhaps.
The crucial things is to tag HAED and branch, so that you have
something to merge agai
On 4 Dec 2002, Lars Gullik Bjønnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
>
> | On Wed, 4 Dec 2002, John Levon wrote:
> |
> | [...]
> | > With all that administration, I'm even less inclined to do so then.
> | >
> | > CVS is worse at handling conflicts in such cases than patch is
> |
> | B
Allan Rae <[EMAIL PROTECTED]> writes:
| On Wed, 4 Dec 2002, John Levon wrote:
|
| [...]
| > With all that administration, I'm even less inclined to do so then.
| >
| > CVS is worse at handling conflicts in such cases than patch is
|
| But at least CVS allows others to keep up to date with your w
On Wed, 4 Dec 2002, John Levon wrote:
[...]
> With all that administration, I'm even less inclined to do so then.
>
> CVS is worse at handling conflicts in such cases than patch is
But at least CVS allows others to keep up to date with your work and
fiddle along with you. All you need to do is w
On Wed, Dec 04, 2002 at 12:07:07PM +1000, Allan Rae wrote:
> Then you should do as many other CVS-based projects do (gdb for
> example) and start a new branch every so often and roll your
> patch (branch to original trunk point) forward.
>
> I've found that merging the trunk into the branch works
On Sat, 30 Nov 2002, John Levon wrote:
> On Sat, Nov 30, 2002 at 11:39:49PM +0100, Lars Gullik Bjønnes wrote:
>
> > | I intend to soon when I find a merging guide that works as advertised
> > | (neither of Lars' do)
> >
> > sure they do...
> > (what is not working?)
>
> Trying to merge up trunk c
On Sat, Nov 30, 2002 at 11:39:49PM +0100, Lars Gullik Bjønnes wrote:
> | I intend to soon when I find a merging guide that works as advertised
> | (neither of Lars' do)
>
> sure they do...
> (what is not working?)
Trying to merge up trunk changes to the branch, it didn't work
properly.
http://
John Levon <[EMAIL PROTECTED]> writes:
| On Sat, Nov 30, 2002 at 01:34:53PM +0200, Dekel Tsur wrote:
|
| > How about creating a branch for it ?
|
| I intend to soon when I find a merging guide that works as advertised
| (neither of Lars' do)
sure they do...
(what is not working?)
--
L
On Sat, Nov 30, 2002 at 01:34:53PM +0200, Dekel Tsur wrote:
> How about creating a branch for it ?
I intend to soon when I find a merging guide that works as advertised
(neither of Lars' do)
regards
john
--
"Trolls like content too."
- Bob Abooey, /.
1 - 100 of 102 matches
Mail list logo
