Angus Leeming wrote:
> The problem appears to be caused by the fact that the inset is inside
> a minipage inside a float. Previews are generated when the buffer is
> loaded by this code in graphics/Previews.C:
>
> void Previews::generateBufferPreviews(Buffer const & buffer) const
> {
> Pr
On Tue, Sep 16, 2003 at 09:49:52PM +, Angus Leeming spake thusly:
> Martin Vermeer wrote:
> > H... is it possible that lang_ is being accessed after the
> > containing class Messages::Pimpl has been destroyed?
>
> If so, I guess that this is the kludge. Thereafter we'd have to
> ascerta
John Levon <[EMAIL PROTECTED]> writes:
| p.s. when do we start looking at actual regressions ?
You say "we" as if we have to do this all of us together.
I look at regressions when I see them.
--
Lgb
On Tue, Sep 16, 2003 at 10:26:51PM +, Angus Leeming wrote:
> string InsetInclude::Params::masterFilename_;
It was absurdly buggy until relatively recently. It's still buggy AFAIK.
> as it is now, or should it be a cached variable that is updated?
cached IMO.
> So, my feeling is tha
On Tue, Sep 16, 2003 at 05:43:10PM -0300, Garst R. Reese wrote:
> In principle, I think the code clean-up is a *good thing* , but
> eventually the speed has to return and the other regressions have to be
> attended to.
I absolutely agree with every part of this statement.
But I do not know who i
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| I think it will make us happy (because cleaner code) but I am not sure
| it will buy us much else. So it depends on how you prefer to spend
| your time ;)
It will prepare for further dispatch work.
So I'll continue on this then.
--
Lgb
The attached file expands to a directory preview_test
$ ls preview_test
boxcount.tex preview_test.lyx snapshot_t=40.tex
This lyx file demonstrates a couple of bugs in current cvs.
1. Try and open the dialog for the first include inset (boxcount.tex).
Either with or without previews turned on,
I thought that the general design rule was that insets should not know
about the buffer that 'owns' them? So, things like:
string InsetInclude::Params::masterFilename_;
are just plain wrong by design? Moreover, the implementation is
currently broken. Witness not just the comment in clon
Martin Vermeer wrote:
> H... is it possible that lang_ is being accessed after the
> containing class Messages::Pimpl has been destroyed?
If so, I guess that this is the kludge. Thereafter we'd have to
ascertain _why_?
string const Messages::get(string const & msg) const
{
return pim
John Levon wrote:
>
> On Tue, Sep 16, 2003 at 11:35:01AM +0200, Andre Poenitz wrote:
>
> > BTW: I've never ever changed between buffers of UserGuide size, so
> > even if Lars' worries were justified, it wouldn't matter in my LyX
> > usage.
>
> I suggest you try doing it for a while, on some olde
On Mon, Sep 15, 2003 at 09:56:22PM +, Angus Leeming spake thusly:
...
> What does valgrind say if you run lyx through that?
==10981==Address 0x421B6530 is 0 bytes inside a block of size 4 free'd
==10981==at 0x40028DF2: __builtin_delete (in
/home/mv/valgrind/lib/valgrind/vgskin_memc
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Would work, but I _really_ don't see the benefit compared to
Andre> the current working solution
The really interesting part is not with sections (which I did not
complain about) but rather chapters. We have somehow to switch from
On Tue, Sep 16, 2003 at 06:37:19PM +0200, Jean-Marc Lasgouttes wrote:
> My problem is, how do I do that? I do not have access to such
> information in mathed... So what would be a good place?
lyx_gui::is_qt_mac()
I really don't have any better ideas than that.
regards
john
--
Khendon's Law:
I
See attached. It appears that the metrics info is incorrect.
--
Angus<>
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Pseudo functions has irritated me for a long, long time, so I
Lars> thought I should see how easy it would be to get rid of them. My
Lars> thought was that it would be easier now, since we have this
Lars> FuncRequest thingie.
Y
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Sat, Sep 13, 2003 at 11:22:06PM +0200, Jean-Marc Lasgouttes
John> wrote:
>> I am not surprised, since it converts the metrics in weird ways. If
>> you happen to have tools to looks at tt fonts metrics, could you
>> try to see if the f
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Sep 16, 2003 at 05:04:32PM +0200, Lars Gullik Bjønnes wrote:
>> Be careful now remember that the standard dictates different
>> return values for [] (not quite sure about at)
>>
>> test_[] depending on const or not.
>>
>> A lot safer to put
On Tue, Sep 16, 2003 at 04:46:09PM +, Angus Leeming spake thusly:
>
> Martin Vermeer wrote:
> > Angus, I find that I have to add #include "lyxfont.h" to paragraph.C
> > to get it to compile.
>
> Really? How odd. What is the error?
> Anyway, I have committed the fix.
>
> --
> Angus
This:
Martin Vermeer wrote:
> Angus, I find that I have to add #include "lyxfont.h" to paragraph.C
> to get it to compile.
Really? How odd. What is the error?
Anyway, I have committed the fix.
--
Angus
On Tue, Sep 16, 2003 at 05:04:32PM +0200, Lars Gullik Bjønnes wrote:
> Be careful now remember that the standard dictates different
> return values for [] (not quite sure about at)
>
> test_[] depending on const or not.
>
> A lot safer to put an assert there and just use [] instead of at.
As
On Tue, Sep 16, 2003 at 03:57:02PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> > if not, I'd like to replace this with an inlined
> >
> > Paragraph::value_type Paragraph::getChar(pos_type pos) const
> > {
> > text_.at(pos);
> > }
> >
> > or even
On Tue, Sep 16, 2003 at 09:33:37AM +, Angus Leeming spake thusly:
...
> Good. I have changed the setXYZ member functions of LyXFont to return void
> (from LyXFont &), as André suggested and am recompiling. I'll commit once
> I've proved that all is still Ok.
Angus, I find that I have to a
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Does this Assert and the error message trigger often nowadays?
>
| Paragraph::value_type Paragraph::getChar(pos_type pos) const
| {
| // This is in the critical path!
| pos_type const siz = text_.size();
>
|
Angus Leeming <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>
>> if not, I'd like to replace this with an inlined
>>
>> Paragraph::value_type Paragraph::getChar(pos_type pos) const
>> {
>> text_.at(pos);
>> }
>>
>> or even
>>
>> Paragraph::va
Andre Poenitz wrote:
> if not, I'd like to replace this with an inlined
>
> Paragraph::value_type Paragraph::getChar(pos_type pos) const
> {
> text_.at(pos);
> }
>
> or even
>
> Paragraph::value_type Paragraph::getChar(pos_type pos) const
>
On Tue, Sep 16, 2003 at 04:52:16PM +0200, Andre Poenitz wrote:
> Does this Assert and the error message trigger often nowadays?
It's pretty easy to trigger but not as common as it was.
> for a 6% (or 9%) speedup...
Let's do that before release.
regards
john
--
Khendon's Law:
If the same point
Does this Assert and the error message trigger often nowadays?
Paragraph::value_type Paragraph::getChar(pos_type pos) const
{
// This is in the critical path!
pos_type const siz = text_.size();
BOOST_ASSERT(pos <= siz);
Dear all,
Georg Baum has prepared a patch that goes someway (maybe all the way) towards
squashing Bug 546 "Subdocuments lose BiBTex database entered in master doc".
The patch is against 13x and looks reasonable to me. However, what do I know?
Regards,
Angus
-- Forwarded Message
On Tue, Sep 16, 2003 at 02:58:06PM +, Angus Leeming wrote:
> Perhaps add a comment explaining to the interested observer why
> text_ is to be found in paragraph.h, not in the pimpl...
Ok.
> Incidentally, do we have any style guide about how to write inline
> code? I was under the impression
Andre Poenitz wrote:
>
> Saves exactly 20% for buffer switching and a bit more for UserGuide loading.
Well done, André!
Perhaps add a comment explaining to the interested observer why text_ is to be
found in paragraph.h, not in the pimpl...
Incidentally, do we have any style guide about how t
all except 'inset' anyway.
--
AngusIndex: src/insets/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/ChangeLog,v
retrieving revision 1.831
diff -u -p -r1.831 ChangeLog
--- src/insets/ChangeLog 16 Sep 2003 13:43:30
Saves exactly 20% for buffer switching and a bit more for UserGuide loading.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: paragraph.C
=
On Tue, Sep 16, 2003 at 01:31:32PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > With the attached patch I get a new profile:
> > I.e. the 8.5% for Paragraph::Pimpl::getChar are gone as well as 1.5% of
> > the Paragraph::getChar.
> >
> > Not bad for 'no change', isn't it?
>
> Not bad ind
Andre Poenitz wrote:
> With the attached patch I get a new profile:
> I.e. the 8.5% for Paragraph::Pimpl::getChar are gone as well as 1.5% of
> the Paragraph::getChar.
>
> Not bad for 'no change', isn't it?
Not bad indeed, but I don't think that the change to paragraph_pimpl.h is to
be applauded
On Tue, Sep 16, 2003 at 02:13:43PM +0200, Andre' Poenitz wrote:
> On Tue, Sep 16, 2003 at 02:05:50PM +0200, Alfredo Braunstein wrote:
> > Andre Poenitz wrote:
> >
> > > Each sample counts as 0.01 seconds.
> > > time calls ms/call name
> > > 14.12 7900 0.06 LyXText::updateRowP
On Tue, Sep 16, 2003 at 01:11:28PM +0100, John Levon wrote:
> On Tue, Sep 16, 2003 at 01:55:20PM +0200, Andre Poenitz wrote:
>
> > BTW: Are you really keeping different 'buffers of moderate size' within
> > a single LyX instance?
> >
> > And change the active buffer frequently?
>
> This is /exac
On Tue, Sep 16, 2003 at 02:05:50PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > Each sample counts as 0.01 seconds.
> > time calls ms/call name
> > 14.12 7900 0.06 LyXText::updateRowPositions()
> > 11.47 14792136 0.00 Paragraph::getChar(int) const
> >
On Tue, Sep 16, 2003 at 01:55:20PM +0200, Andre Poenitz wrote:
> BTW: Are you really keeping different 'buffers of moderate size' within
> a single LyX instance?
>
> And change the active buffer frequently?
This is /exactly/ what people writing Ph.D's do, one doc per chapter.
regards
john
--
K
Andre Poenitz wrote:
> Each sample counts as 0.01 seconds.
> time calls ms/call name
> 14.12 7900 0.06 LyXText::updateRowPositions()
> 11.47 14792136 0.00 Paragraph::getChar(int) const
> 8.53 14792136 0.00 Paragraph::Pimpl::getChar(int) const
> 8.245309
On Tue, Sep 16, 2003 at 01:08:56PM +, Angus Leeming wrote:
> It was mentioned last week that it would be a good idea to move IsInsetChar
> out of textutils.h. This patch does that.
Good.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they de
It was mentioned last week that it would be a good idea to move IsInsetChar
out of textutils.h. This patch does that.
--
AngusIndex: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.
On Tue, Sep 16, 2003 at 02:02:47PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > As the second buffer is already broken into rows, there is not really a
> > need for a rebreak on buffer change, is there?
>
> I've though about this. It would work now, but will break down when we ha
Andre Poenitz wrote:
> As the second buffer is already broken into rows, there is not really a
> need for a rebreak on buffer change, is there?
I've though about this. It would work now, but will break down when we have
multiple bvs for the same buffer. (don't know if it worth considering,
though
On Tue, Sep 16, 2003 at 01:56:40PM +0200, Alfredo Braunstein wrote:
> John Levon wrote:
>
> > Current-ish, maybe I need to update again ? I'll do so ...
>
> No... it's only that it's is like this from about one month ago (textcache
> removal is *not* in yet).
>
> > Then post some profiles of wh
On Tue, Sep 16, 2003 at 01:47:32PM +0200, Alfredo Braunstein wrote:
> John Levon wrote:
>
> > What's expected ? Waiting two seconds to switch between moderately sized
> > documents ? That's what I'm seeing, and I would not call it acceptable.
>
> That's current cvs? We need new ideas...
As the s
John Levon wrote:
> Current-ish, maybe I need to update again ? I'll do so ...
No... it's only that it's is like this from about one month ago (textcache
removal is *not* in yet).
> Then post some profiles of where time is spent
The problem that we have now is that rebreak caching is not as ea
> "John" == John Levon <[EMAIL PROTECTED]> writes:
John> On Tue, Sep 16, 2003 at 11:00:15AM +0200, Andre Poenitz wrote:
>> But I think we could have a small steps conversion along the
>> following lines:
John> That sounds like a really nice plan.
Indeed.
JMarc
Andre Poenitz wrote:
>> It is pointless to register an InsetXYZ_Handler before any InsetXYZ has
>> been created. At least as far as the dispatch scheme is concerned. So put
>> the init() call in the inset constructor.
>
> Are you sure we are talking about the same scheme?
>
> How would I have a
On Tue, Sep 16, 2003 at 12:44:22PM +0100, John Levon wrote:
> On Tue, Sep 16, 2003 at 11:02:42AM +0200, Andre Poenitz wrote:
>
> > On Tue, Sep 16, 2003 at 10:56:42AM +0200, Alfredo Braunstein wrote:
> > > As said before (on the wrong list) there's no performance difference with
> > > current cvs (
On Tue, Sep 16, 2003 at 01:47:32PM +0200, Alfredo Braunstein wrote:
> > What's expected ? Waiting two seconds to switch between moderately sized
> > documents ? That's what I'm seeing, and I would not call it acceptable.
>
> That's current cvs? We need new ideas...
Current-ish, maybe I need to u
On Tue, Sep 16, 2003 at 12:23:09PM +, Angus Leeming wrote:
> Andre Poenitz wrote:
>
> > On Tue, Sep 16, 2003 at 12:50:22PM +0200, Lars Gullik Bjønnes wrote:
> >> Right. And what I am saying then is you this dummy should be avoided
> >> and explicit call of init should be done instead.
> >
> >
On Tue, Sep 16, 2003 at 11:00:15AM +0200, Andre Poenitz wrote:
> But I think we could have a small steps conversion along the following
> lines:
That sounds like a really nice plan.
regards
john
--
Khendon's Law:
If the same point is made twice by the same person, the thread is over.
John Levon wrote:
> What's expected ? Waiting two seconds to switch between moderately sized
> documents ? That's what I'm seeing, and I would not call it acceptable.
That's current cvs? We need new ideas...
Alfredo
On Tue, Sep 16, 2003 at 11:35:01AM +0200, Andre Poenitz wrote:
> BTW: I've never ever changed between buffers of UserGuide size, so
> even if Lars' worries were justified, it wouldn't matter in my LyX
> usage.
I suggest you try doing it for a while, on some older hardware ...
john, who remembers
On Tue, Sep 16, 2003 at 11:02:42AM +0200, Andre Poenitz wrote:
> On Tue, Sep 16, 2003 at 10:56:42AM +0200, Alfredo Braunstein wrote:
> > As said before (on the wrong list) there's no performance difference with
> > current cvs (because a bug in there). But a current full rebreak on buffer
> > swit
Andre Poenitz wrote:
> On Tue, Sep 16, 2003 at 12:50:22PM +0200, Lars Gullik Bjønnes wrote:
>> Right. And what I am saying then is you this dummy should be avoided
>> and explicit call of init should be done instead.
>
> While this is feasible its removes one of the main advantages of this
> sche
Attached is a list of the current dependencies on each file in the source
tree. It all looks a little less horrific than it did when I started. F.ex.,
there were 278 dependencies on LColor.h, down now to 68.
--
Angus<>
stats_cvs.gz
Description: GNU Zip compressed data
On Tue, Sep 16, 2003 at 12:50:22PM +0200, Lars Gullik Bjønnes wrote:
> Right. And what I am saying then is you this dummy should be avoided
> and explicit call of init should be done instead.
While this is feasible its removes one of the main advantages of this
scheme: A total decoupling of 'core'
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Sep 16, 2003 at 12:32:36PM +0200, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | On Tue, Sep 16, 2003 at 12:20:58PM +0200, Alfredo Braunstein wrote:
>> >> > I think you could try to convert the math dispatch to y
On Tue, Sep 16, 2003 at 12:33:39PM +0200, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > On Tue, Sep 16, 2003 at 12:20:58PM +0200, Alfredo Braunstein wrote:
> >> > I think you could try to convert the math dispatch to your scheme
> >> > without affecting the rest of LyX. This would give so
On Tue, Sep 16, 2003 at 12:32:36PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Tue, Sep 16, 2003 at 12:20:58PM +0200, Alfredo Braunstein wrote:
> >> > I think you could try to convert the math dispatch to your scheme
> >> > without affecting the rest of L
Andre Poenitz wrote:
> On Tue, Sep 16, 2003 at 12:20:58PM +0200, Alfredo Braunstein wrote:
>> > I think you could try to convert the math dispatch to your scheme
>> > without affecting the rest of LyX. This would give some reference
>> > implementation of the scheme without duplicated work...
>>
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Sep 16, 2003 at 12:20:58PM +0200, Alfredo Braunstein wrote:
>> > I think you could try to convert the math dispatch to your scheme
>> > without affecting the rest of LyX. This would give some reference
>> > implementation of the scheme without du
On Tue, Sep 16, 2003 at 12:20:58PM +0200, Alfredo Braunstein wrote:
> > I think you could try to convert the math dispatch to your scheme
> > without affecting the rest of LyX. This would give some reference
> > implementation of the scheme without duplicated work...
>
> I was thinking... how abou
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Sep 16, 2003 at 11:45:41AM +0200, Lars Gullik Bjønnes wrote:
>> This is what I am not sure about... I also have a idea of a "distpatch
>> domain" so that we can register lfuns, and not have gigantic static
>> switches as we have today.
>
| I thin
Andre Poenitz wrote:
> On Tue, Sep 16, 2003 at 11:45:41AM +0200, Lars Gullik Bjønnes wrote:
>> This is what I am not sure about... I also have a idea of a "distpatch
>> domain" so that we can register lfuns, and not have gigantic static
>> switches as we have today.
>
> I think you could try to c
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Huh?
you removed the sentence where I expand on this...
| But that's what we have now and that's what makes most sense: The
| innermost inset should have the first chance to handle some event,
| than its parent and so on.
>
| Are you suggesting somethi
On Tue, Sep 16, 2003 at 11:45:41AM +0200, Lars Gullik Bjønnes wrote:
> This is what I am not sure about... I also have a idea of a "distpatch
> domain" so that we can register lfuns, and not have gigantic static
> switches as we have today.
I think you could try to convert the math dispatch to you
On Tue, Sep 16, 2003 at 11:45:41AM +0200, Lars Gullik Bjønnes wrote:
> >> My take on this is that we should always enter the "distpatch-tree"
> >> from the same point.
> >
> | Exactly. But there are two entry points: current cursor and (x,y)
> | coordinate.
>
> Yes, but they should use the same en
Angus Leeming <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>
>>> And I am trying to get rid of the big switch.
>>
>> How should that work?
>>
>> [Note that individual LFUN handler functions are a pain in the ass. I
>> had this once working in mathed and it required much more typing,
>> rec
Andre Poenitz wrote:
>> And I am trying to get rid of the big switch.
>
> How should that work?
>
> [Note that individual LFUN handler functions are a pain in the ass. I
> had this once working in mathed and it required much more typing,
> recompilation time and general hand holding than the big
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Sep 16, 2003 at 11:11:56AM +0200, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | 5. use buildCursor().dispatch() instead of getLyXText()->dispatch() in
>> | the default branch of BufferView::Pimpl::dispatch() [Th
Exactly the same idea as in the lyxfont patch. Private member variable
background_color_ is now stored as an int, not as an LColor::color. Assessor
functions ensure that the change is invisible to the outside world.
This change enables us to move #include "LColor.h" out of inset.h, resulting
in
On Tue, Sep 16, 2003 at 11:31:46AM +0200, Andre' Poenitz wrote:
> That's the GlobalCursor::dispatch, which goes from the leave
Which is spelt 'leaf' in most places...
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T
On Tue, Sep 16, 2003 at 11:17:11AM +0200, Alfredo Braunstein wrote:
> And now that I think better this whole bussiness on having or not a full
> rebreak is misleading, as the LyXText doesn't hold the rowlist anymore.
> So I think there's nothing to test, but I can be wrong.
>
> What do you think?
On Tue, Sep 16, 2003 at 11:11:56AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | 5. use buildCursor().dispatch() instead of getLyXText()->dispatch() in
> | the default branch of BufferView::Pimpl::dispatch() [That's the fun part
> | but should not be that hard
Alfredo Braunstein wrote:
> Lars Gullik Bjønnes wrote:
>
>> I'd like some more people just to try this before you apply it.
>> (So that we know if your claim about todays hardware and old hardware
>> acceptable.)
>
> So people can just try current cvs (has a full rebreak on buffer switching
> fr
On Tue, Sep 16, 2003 at 10:05:39AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > Opinions?
>
> It seems you've thought hard about how to do this
Well, it irked me for quite a while...
> What's happening on the job front?
Nothing.
But I have to admit I did not try too hard so far.
Are
Andre Poenitz <[EMAIL PROTECTED]> writes:
| 5. use buildCursor().dispatch() instead of getLyXText()->dispatch() in
| the default branch of BufferView::Pimpl::dispatch() [That's the fun part
| but should not be that hard]
Well... I have my own plans for distpatch...
My take on this is that we sho
Lars Gullik Bjønnes wrote:
> I'd like some more people just to try this before you apply it.
> (So that we know if your claim about todays hardware and old hardware
> acceptable.)
So people can just try current cvs (has a full rebreak on buffer switching
from 15 aug if cvs annotate is correct).
Andre Poenitz wrote:
> Opinions?
It seems you've thought hard about how to do this and your track record in
refactoring code is impressive. I think you should feel free.
What's happening on the job front?
--
Angus
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| As said before (on the wrong list) there's no performance difference with
| current cvs (because a bug in there). But a current full rebreak on buffer
| switching is almost unnoticeable on today's hardware and acceptable on old
| one IMHO.
I'd like
On Tue, Sep 16, 2003 at 10:56:42AM +0200, Alfredo Braunstein wrote:
> As said before (on the wrong list) there's no performance difference with
> current cvs (because a bug in there). But a current full rebreak on buffer
> switching is almost unnoticeable on today's hardware and acceptable on old
>
I think the remaining two big obstacles on the path to something that
could be called 'a fairly clean core design' are inset locking ('IL')
and the 'distributed' cursor ('DC').
The currently 'distributed' cursor (i.e. one 'slice' of a (virtual)
global cursor per LyXText plus some optional MathCur
Andre Poenitz wrote:
> On Tue, Sep 16, 2003 at 10:19:07AM +0200, Alfredo Braunstein wrote:
>> This patch avoids doing a full rebreak on buffer switching, which is the
>> reason for the existence of the TextCache.
>> The removed full rebreak is unneeded: it is done in every case (except
>> from buf
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | I have shown a reduction in dependencies on LColor.h of 60 object
> | files. Does that count?
>
> Dependencies are nice... but when you begin to confront typesafety it
> is not so nice anymore.
Agreed.
>>> But I am a
On Mon, Sep 15, 2003 at 09:56:22PM +, Angus Leeming spake thusly:
...
> Ok, it looks to me like that 'lang_' member variable has been corrupted.
> Do you have LANG and LC_ALL environment variables set? Here I have
> $ echo "LANG=\"$LANG\" LC_ALL=\"$LC_ALL\""
> LANG="en_US" LC_ALL=""
>
> What
Andre Poenitz wrote:
> On Tue, Sep 16, 2003 at 09:04:39AM +, Angus Leeming wrote:
>> > But I am a bit ambivalent as well. Also things like this typically
>> > make ripple effects in the rest of the code as well: You will have to
>> > change a lot of other "Color" to int as well, or add casts.
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
| Lars> Leave some temporary support stuff. ditch rest.
>
| Lars> I'll apply this shortly unless I get objections.
>
| Why do you keep the configure option?
Only because Andre want
Angus Leeming <[EMAIL PROTECTED]> writes:
| I have shown a reduction in dependencies on LColor.h of 60 object
| files. Does that count?
Dependencies are nice... but when you begin to confront typesafety it
is not so nice anymore.
>> But I am a bit ambivalent as well. Also things like this typica
On Tue, Sep 16, 2003 at 09:04:39AM +, Angus Leeming wrote:
> > But I am a bit ambivalent as well. Also things like this typically
> > make ripple effects in the rest of the code as well: You will have to
> > change a lot of other "Color" to int as well, or add casts.
>
> Not true. I am talking
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Leave some temporary support stuff. ditch rest.
Lars> I'll apply this shortly unless I get objections.
Why do you keep the configure option?
JMarc
Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Mon, Sep 15, 2003 at 10:31:08PM +, Angus Leeming wrote:
>>> If a pimpl-ing of LyXFont would have unacceptable performance
>>> implications, we could nonetheless get that #include "LColor.h" out of
>>> the lyxfont.
On Tue, Sep 16, 2003 at 09:50:54AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Tue, Sep 16, 2003 at 02:13:46AM +0200, Lars Gullik Bjønnes wrote:
> >> This patch is needed to compile with gcc 3.4 (CVS).
> >
> | Is this 'namespace lyx::support::os = os;' re
Rob Lahaye wrote:
> Compiling current CVS:
> [...]
> In file included from GScreen.C:14:
> GScreen.h: In member function `virtual WorkArea& GScreen::workarea() const':
> GScreen.h:42: error: could not convert `this->GScreen::owner_' to
> `WorkArea&' In file included from GScreen.C:16:
> GWorkArea.h
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Mon, Sep 15, 2003 at 10:31:08PM +, Angus Leeming wrote:
>> If a pimpl-ing of LyXFont would have unacceptable performance
>> implications, we could nonetheless get that #include "LColor.h" out of
>> the lyxfont.h header file by storing 'color' as a
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Sep 16, 2003 at 02:13:46AM +0200, Lars Gullik Bjønnes wrote:
>> This patch is needed to compile with gcc 3.4 (CVS).
>
| Is this 'namespace lyx::support::os = os;' required by the language?
What is required is to _not_ use:
using lyx::suppo
On Tue, Sep 16, 2003 at 02:13:46AM +0200, Lars Gullik Bjønnes wrote:
> This patch is needed to compile with gcc 3.4 (CVS).
Is this 'namespace lyx::support::os = os;' required by the language?
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they des
On Mon, Sep 15, 2003 at 10:31:08PM +, Angus Leeming wrote:
> If a pimpl-ing of LyXFont would have unacceptable performance
> implications, we could nonetheless get that #include "LColor.h" out of
> the lyxfont.h header file by storing 'color' as an int.
>
> Is such a strategy acceptable?
Com
99 matches
Mail list logo
