In Xforms version:
Tools->Tex Information
Double click on e.g. hebtech.cls, will pop up the Show File dialog with
"LyX: LyX: hebtech.cls" in the title.
This patch removes the redundant "LyX: ". Please apply.
Regards,
Rob.
Index: src/frontends/xforms/FormShowFile.C
==
Andre Poenitz wrote:
> On Sat, Aug 16, 2003 at 12:51:20AM +0200, Alfredo Braunstein wrote:
>> Alfredo Braunstein wrote:
>>
>> Here's a patch with both changes + some minor cosmetic stuff
>
> Now we have a similar problem when "going up" (hitting the ceiling
> brings you back to the bottom, but t
On Fri, Aug 22, 2003 at 08:57:24AM +0200, Andre Poenitz spake thusly:
> On Fri, Aug 22, 2003 at 12:12:23AM +0300, Martin Vermeer wrote:
> > On Thu, Aug 21, 2003 at 05:01:11PM +0100, John Levon spake thusly:
> > >
> > > On Thu, Aug 21, 2003 at 06:34:37PM +0300, Martin Vermeer wrote:
> > >
> > > >
On Fri, Aug 22, 2003 at 10:58:39AM +0200, Andre Poenitz wrote:
...
> [Well, my main objection is 'cosmetics'. I find
>
> row.some_funny_fill(row.some_funny_fill() + other);
>
> artificially obfuscated compared to
>
> row.some_funny_fill += other;
>
> With the latter I see 'no fuzz, just add
On Thu, Aug 21, 2003 at 08:20:20PM +0100, John Levon wrote:
>
> "How do I include source listings in a doc" has to be the number one
> question asked on the IRC channel. We really don't have a good solution
> yet, but we do have a rather old patch done by Herbert :
>
> http://bugzilla.lyx.org/sho
Lars,
can you check it? I would like to close bug #1007.
http://bugzilla.lyx.org/show_bug.cgi?id=1007
Thanks, Michael
Index: boost/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/boost/ChangeLog,v
retrieving revision 1.38
diff -a -u -
Ping... Ping... (Please apply. It's harmless)
Michael
Index: po/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/po/ChangeLog,v
retrieving revision 1.169
diff -a -u -r1.169 ChangeLog
--- po/ChangeLog2003/08/18 12:57:23 1.169
+++
On Fri, Aug 22, 2003 at 01:17:14PM +0100, John Levon wrote:
> On Fri, Aug 22, 2003 at 09:46:47AM +0200, Andre Poenitz wrote:
>
> > This also contains a new 'LyXRow::end_' member to indicate the
>
> At last !
The problem is that +/- 1 black magic in rowBreakPoint (or wherever).
Have a look at is
On Tuesday 19 August 2003 12:41 pm, Andre Poenitz wrote:
> On Tue, Aug 19, 2003 at 01:23:33PM +, Angus Leeming wrote:
> > Happy with this André?
>
> Add Alejandro to
>
> math_support.[Ch]
>
> and to the .C of
>
> math_binaryopinset
> math_charinset
> math_decorationinset
> math_deliminset
On Fri, Aug 22, 2003 at 09:46:47AM +0200, Andre Poenitz wrote:
> This also contains a new 'LyXRow::end_' member to indicate the
At last !
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Aug 22, 2003 at 12:19:39PM +0200, Lars Gullik Bjønnes wrote:
>> They should be, that they are not is probably a bug in gcc.
>
| They are not defined as inline, how should gcc inline them?
:-)
Accessors are allowed to be defined inline.
--
long awaited...
Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.424
diff -u -p -r1.424 text.C
--- text.C 22 Aug 2003 09:40:53 - 1.424
+++ text.C 22 Aug 2003 11:44:59
>> Andre Poenitz wrote:
>> >> They should be, that they are not is probably a bug in gcc.
>> > They are not defined as inline, how should gcc inline them?
>>
>> My understanding is that anything appearing in the class declaration is
>> automatically flagged for inlining.
>
> Heck, look at lyxrow.
On Fri, Aug 22, 2003 at 11:53:48AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> >> They should be, that they are not is probably a bug in gcc.
> > They are not defined as inline, how should gcc inline them?
>
> My understanding is that anything appearing in the class declaration is
> auto
Andre Poenitz wrote:
>> They should be, that they are not is probably a bug in gcc.
> They are not defined as inline, how should gcc inline them?
My understanding is that anything appearing in the class declaration is
automatically flagged for inlining.
--
Angus
On Fri, Aug 22, 2003 at 12:19:39PM +0200, Lars Gullik Bjønnes wrote:
> They should be, that they are not is probably a bug in gcc.
They are not defined as inline, how should gcc inline them?
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they dese
On Fri, Aug 22, 2003 at 12:19:02PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | And that's the patch.
> >
> | It's just 16 bytes per row extra, so it should not hurt badly.
> >
> | Note that the new LyXRow members are public, and in fact I think that's
> | wh
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Fri, Aug 22, 2003 at 09:55:31AM +0100, José Abílio Oliveira Matos wrote:
>> On Fri, Aug 22, 2003 at 10:39:03AM +0200, Andre Poenitz wrote:
>> >
>> > And that's the patch.
>> >
>> > It's just 16 bytes per row extra, so it should not hurt badly.
>> >
Andre Poenitz <[EMAIL PROTECTED]> writes:
| And that's the patch.
>
| It's just 16 bytes per row extra, so it should not hurt badly.
>
| Note that the new LyXRow members are public, and in fact I think that's
| what the others should be, too.
>
| We currently waste around ~4% time when scrolling t
On Fri, Aug 22, 2003 at 05:52:20AM -0300, Garst R. Reese wrote:
> Andre Poenitz wrote:
> >
> > And that's the patch.
> >
> > It's just 16 bytes per row extra, so it should not hurt badly.
> >
> I think you guys should buy Juergen V's laptop to test with.
We are trading memory for better code an
On Fri, Aug 22, 2003 at 09:51:43AM +, Angus Leeming wrote:
> José Abílio Oliveira Matos wrote:
>
> > On Fri, Aug 22, 2003 at 10:39:03AM +0200, Andre Poenitz wrote:
> >>
> >> And that's the patch.
> >>
> >> It's just 16 bytes per row extra, so it should not hurt badly.
> >>
> >> Note that th
Andre Poenitz wrote:
>
> And that's the patch.
>
> It's just 16 bytes per row extra, so it should not hurt badly.
>
I think you guys should buy Juergen V's laptop to test with.
Garst
On Fri, Aug 22, 2003 at 09:55:31AM +0100, José Abílio Oliveira Matos wrote:
> On Fri, Aug 22, 2003 at 10:39:03AM +0200, Andre Poenitz wrote:
> >
> > And that's the patch.
> >
> > It's just 16 bytes per row extra, so it should not hurt badly.
> >
> > Note that the new LyXRow members are public, a
José Abílio Oliveira Matos wrote:
> On Fri, Aug 22, 2003 at 10:39:03AM +0200, Andre Poenitz wrote:
>>
>> And that's the patch.
>>
>> It's just 16 bytes per row extra, so it should not hurt badly.
>>
>> Note that the new LyXRow members are public, and in fact I think that's
>> what the others sh
On Fri, Aug 22, 2003 at 10:39:03AM +0200, Andre Poenitz wrote:
>
> And that's the patch.
>
> It's just 16 bytes per row extra, so it should not hurt badly.
>
> Note that the new LyXRow members are public, and in fact I think that's
> what the others should be, too.
>
> We currently waste around
And that's the patch.
It's just 16 bytes per row extra, so it should not hurt badly.
Note that the new LyXRow members are public, and in fact I think that's
what the others should be, too.
We currently waste around ~4% time when scrolling through the UserGuide
just for these accessor functions.
See attached.
Instead of 'manually inlining' the critical parts, we pass the LyXFont
around (getting the font was the expensive part).
No change in speed.
Btw: I intend to make the fill_ and maybe even the margin data part of
the LyXRow struct, at least for a while, by e.g. calling
'prepareToPr
27 matches
Mail list logo
