On Wed, Sep 10, 2003 at 08:10:20PM +0200, Lars Gullik Bjønnes wrote:
> Pseudo functions has irritated me for a long, long time, so I thought
> I should see how easy it would be to get rid of them. My thought was
> that it would be easier now, since we have this FuncRequest thingie.
>
> Enclosed is
Lars Gullik Bjønnes wrote:
> We (you ) should take a look at Sutters variant as well:
> He calls the creature a ValuePtr.
Absolutely reasonable. I don't have Sutter's books here however (at work). If
you could post the code I'll look at it next week.
> (I'll come back to actuall impl.)
Good. So
Angus Leeming <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
>> I need some guidance here... My feeling is to add 'create_ptr' and
>> 'destroy_ptr' template parameters to copied_ptr...
>
| I remembered tha boost::shared_ptr has a Deleter template parameter., so I am
| not talking crap here.
>
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| this patch only works for newer gcc compilers with libstdc++-v3
>
| I'll post compilation timings later.
With patch:
real17m50.102s
user15m44.400s
sys 1m0.390s
Without patch:
real17m28.825s
user15m21.450s
sys 0m58.940s
In
Angus Leeming wrote:
> I need some guidance here... My feeling is to add 'create_ptr' and
> 'destroy_ptr' template parameters to copied_ptr...
I remembered tha boost::shared_ptr has a Deleter template parameter., so I am
not talking crap here.
We would need a Creator parameter too. Something lik
Angus Leeming wrote:
> Hmmm
>
> class BufferParams {
> public:
> AuthorList & authors();
> private:
> /** Use the Pimpl idiom to hide those member variables that
> would otherwise drag in other header files.
> */
> class Impl;
> lyx::support::c
Lars Gullik Bjønnes wrote:
> this patch only works for newer gcc compilers with libstdc++-v3
Even though it results in little or no change to either compile time or build
size (just guessing ;-) it's a bold attempt. Now can we just face facts: a
string manipulation tool is going to depend on st
Lars Gullik Bjønnes wrote:
> Enclosed is a patch that gets rid of the peudo stuff, but it is not
> really functional, but shows what kind of changes that will be needed.
>
> Espesially work on the toolbar and the Menubar is needed. (that is the
> non-functional bits.)
>
> So if others think this
[EMAIL PROTECTED] (Lars Gullik Bjønnes) writes:
| #ifdef __GLIBCPP__
>
| #include
>
| #endif
My preliminary results show that we gain close to nothing by doing
this.
--
Lgb
Pseudo functions has irritated me for a long, long time, so I thought
I should see how easy it would be to get rid of them. My thought was
that it would be easier now, since we have this FuncRequest thingie.
Enclosed is a patch that gets rid of the peudo stuff, but it is not
really functional, but
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Sep 10, 2003 at 05:52:27PM +, Angus Leeming wrote:
>> And Responder #3.
>> Summary: investigate writing your own string_fwd.h header file.
>
| Lars?
>
| Would you be ok with something like
>
| lstringfwd.h
>
| #ifndef LSTRINGFWD_H
| #define
Angus Leeming <[EMAIL PROTECTED]> writes:
| Personally, if compile-time overhead was a read problem,
| would rather implement a custom header for
| each platform I am using...
This looks like a much better solution to me.
(this might actually be something that we can get into boost...)
So,
On Wednesday 10 September 2003 5:12 pm, Andre Poenitz wrote:
> On Wed, Sep 10, 2003 at 05:52:27PM +, Angus Leeming wrote:
> > And Responder #3.
> > Summary: investigate writing your own string_fwd.h header file.
>
> Lars?
>
> Would you be ok with something like
>
> lstringfwd.h
Call it 'suppor
On Wed, Sep 10, 2003 at 06:06:11PM +, Angus Leeming wrote:
> What we should do is put some hard numbers to all this. The only
> reason to go down this route at all is to reduce compile times,
> right?
Yes...
> If that is the case, then it is enough to just 'suck it and see' and
> post back th
On Wed, Sep 10, 2003 at 05:52:27PM +, Angus Leeming wrote:
> And Responder #3.
> Summary: investigate writing your own string_fwd.h header file.
Lars?
Would you be ok with something like
lstringfwd.h
#ifndef LSTRINGFWD_H
#define LSTRINGFWD_H
#if __GNUCC__ > 3
# include "bits/stringf
On Wednesday 10 September 2003 5:01 pm, Andre Poenitz wrote:
> On Wed, Sep 10, 2003 at 05:39:31PM +, Angus Leeming wrote:
> > There are two issues.
> >
> > (a) No virtual destructor. This means you can't safely call delete on
> > a pointer to string when the object pointed to is in fact a
>
Angus Leeming <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
>> Note that if this is done one of the main remaining reasons to stick to
>> 'STRCONV' and --with-included-strings (namely smaller binaries) might go
>> away, so this in fact could lead to nicer code.
>
| This is what two people had
On Wed, Sep 10, 2003 at 05:39:31PM +, Angus Leeming wrote:
> There are two issues.
>
> (a) No virtual destructor. This means you can't safely call delete on
> a pointer to string when the object pointed to is in fact a
> derived_from_string.
>
> (b) It isn't designed for polymorphism
And Responder #3.
Summary: investigate writing your own string_fwd.h header file.
Angus
,--- Forwarded message (begin)
Subject: Re: class String : public std::string {};
From: Ivan Vecerina <[EMAIL PROTECTED]>
Date: Wed, 10 Sep 2003 16:43:55 +
Hi Angus,
| Could someo
Andre Poenitz wrote:
> Note that if this is done one of the main remaining reasons to stick to
> 'STRCONV' and --with-included-strings (namely smaller binaries) might go
> away, so this in fact could lead to nicer code.
This is what two people had to say on the matter on comp.lang.c++
In a nutshel
On Wed, Sep 10, 2003 at 05:52:08PM +0200, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | We know you oppose it. But I suspect that your opposition is based
> | on feelings of "Better the Devil you know than the one you don't".
>
> That might very well be the case. I
On Wed, Sep 10, 2003 at 05:55:27PM +0200, Jean-Marc Lasgouttes wrote:
> Ronald Florence also has a patch to make the display of \int or \prod
> correct with the latex-xft-fonts stuff and Qt/Mac. I'd really like to
> understand what is so special with those characters, but my
> experiments with ftm
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | We know you oppose it. But I suspect that your opposition is based
> | on feelings of "Better the Devil you know than the one you don't".
>
> That might very well be the case. I am feeling all jittery when
> thinking ab
On Wed, Sep 10, 2003 at 04:18:02PM +, Angus Leeming wrote:
> Kayvan A. Sylvan wrote:
> >> Do you make all targets, xforms, qt, gtk when making distdir? I get as far
> >> as this before it bombs because I don't have things set up for gtk:
> >>
> >
> > Thanks!
> >
> > I only build for xforms a
Difference since monday is that I have added a couple of mac os files,
mostly. However, I have several open problems.
John pointed to bug 1384. Unless somebody investigates and proposes a
patch, I am going to pass for now on this one.
I have a tentative patch to improve math font support on Disp
Angus Leeming <[EMAIL PROTECTED]> writes:
| We know you oppose it. But I suspect that your opposition is based
| on feelings of "Better the Devil you know than the one you don't".
That might very well be the case. I am feeling all jittery when
thinking about this.
| Attached is a _working_ test
Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Jean-Marc Lasgouttes wrote:
>>> Angus> (You could propose 'class lyxstring : public std::string {};'
>>> Angus> if you like. You'd have to define the constructors but that'd
>>> Angus> be all. After you propose it, Lars
Angus Leeming <[EMAIL PROTECTED]> writes:
| Kayvan A. Sylvan wrote:
>>> Do you make all targets, xforms, qt, gtk when making distdir? I get as far
>>> as this before it bombs because I don't have things set up for gtk:
>>>
>>
>> Thanks!
>>
>> I only build for xforms and qt.
>
| So, what is the
Kayvan A. Sylvan wrote:
>> Do you make all targets, xforms, qt, gtk when making distdir? I get as far
>> as this before it bombs because I don't have things set up for gtk:
>>
>
> Thanks!
>
> I only build for xforms and qt.
So, what is the command you use? I configure only for xforms and qt and
Angus Leeming <[EMAIL PROTECTED]> writes:
| Jean-Marc Lasgouttes wrote:
>> Angus> (You could propose 'class lyxstring : public std::string {};'
>> Angus> if you like. You'd have to define the constructors but that'd
>> Angus> be all. After you propose it, Lars will throw it out. Again,
>> Angus> t
Kuba Ober wrote:
>> Yup, your SOH is restored ;-)
>
> And the reason for that "SOH is restored" comment I believe is that
> boost::filesystem knows nada about kpathsea (a.k.a. TeX magic). Thus it
> doesn't need to be used to find a file being stored by name only. And IIRC
> the consensus (Lars-exc
Jean-Marc Lasgouttes wrote:
> Angus> (You could propose 'class lyxstring : public std::string {};'
> Angus> if you like. You'd have to define the constructors but that'd
> Angus> be all. After you propose it, Lars will throw it out. Again,
> Angus> the reasons why won't be clear.)
>
> I have to ad
> "Uwe" == Uwe Wolfram <[EMAIL PROTECTED]> writes:
Uwe> Hi Jean-Marc, I'm a little bit reluctant to subscribe to the
Uwe> developer maillist as an ordinary user just for this:
Hi Uwe,
Sorry for taking so long to answer... I cc'd the developpers list,
since I am not sure what to do.
Uwe> Wit
Andre Poenitz wrote:
> On Wed, Sep 10, 2003 at 11:59:59AM +, Angus Leeming wrote:
>> Andre Poenitz wrote:
>> > But not nice (read UGLY). In fact I neither like the template idea and
>> > certainly not the macro.
>> >
>> > [OTOH, enums are rarely nice...]
>> >
>> > [And if you keep pushing on
On Wed, Sep 10, 2003 at 12:12:19AM +, Angus Leeming wrote:
> Kayvan A. Sylvan wrote:
>
> > This looks like another "make dist" issue.
> >
> > make[1]: Entering directory `/home/kayvan/src/lyx/src'
> > make[1]: *** No rule to make target `ParagraphList.h', needed by `distdir'.
> >
>
> Sheesh
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Lars Gullik Bj?nnes wrote:
>>
>> As you see, not different at all... except that use of
>> lyx::support::abort will not change if ::abort is put in the std
>> namespace. (or anywhere else...)
>
| The patch below makes CVS compile on my FreeBSD system.
>
|
Lars Gullik Bj?nnes wrote:
>
> As you see, not different at all... except that use of
> lyx::support::abort will not change if ::abort is put in the std
> namespace. (or anywhere else...)
The patch below makes CVS compile on my FreeBSD system.
OK?
R.
Index: src/boost.C
===
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Lars Gullik Bj?nnes wrote:
>> Rob Lahaye <[EMAIL PROTECTED]> writes:
>>
>> | Unless you tell me in more detail what your abort-preference
>> | actually implies.
>>
>> the "problem" with using assert is that it depends on defines: NDEBUG
>> in particular.
Lars Gullik Bj?nnes wrote:
> Rob Lahaye <[EMAIL PROTECTED]> writes:
>
> | Unless you tell me in more detail what your abort-preference
> | actually implies.
>
> the "problem" with using assert is that it depends on defines: NDEBUG
> in particular.
>
> And what we really want anyway is a plain
On piątek 05 wrzesień 2003 06:37 am, Angus Leeming wrote:
> Lars Gullik Bjønnes wrote:
> > Angus Leeming <[EMAIL PROTECTED]> writes:
> > | On Friday 05 September 2003 8:36 am, Martin Vermeer wrote:
> >>> > Attached is a rewrite of the BibTeX inset so that it derives direct
> >>> > from InsetOld rat
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Unless you tell me in more detail what your abort-preference
| actually implies.
the "problem" with using assert is that it depends on defines: NDEBUG
in particular.
And what we really want anyway is a plain abort at this point.
So to just abort is just
Angus Leeming wrote:
> Rob Lahaye wrote:
>
>>No I don't, because I have no idea what I'm doing.
>>Well, if you insist:
>>
>>ChangeLog:
>>Add a "()" inbetween "params" and ".getLyXTextClass()".
>>
>>Sorry, but that's all I can say; "why and how this has become an error
>>and such-and-such is the f
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> You mean because of those default assignments, like:
Yes.
Angus> Question: is the default assignment really helpful here?
Angus> Probably not.
You may be right.
Angus> (You could propose 'class lyxstring : public std::string {}
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Ah well. It is all becoming academic, as I've run out of time
Angus> to play with LyX. You'll just have to keep the inter-twined
Angus> header files and painful recompilation when you change any
Angus> header file in the src directo
Lars Gullik Bj?nnes wrote:
> Rob Lahaye <[EMAIL PROTECTED]> writes:
>Rob Lahaye <[EMAIL PROTECTED]> writes:
>
>
>| Should instead a "#include " be added at the top of this file?
>
>Either that or we should use lyx::support::abort instead.
>(I'll probably prefere that.)
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Lars Gullik Bj?nnes wrote:
>> Rob Lahaye <[EMAIL PROTECTED]> writes:
>>
>> | Lars Gullik Bj?nnes wrote:
>>
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Should instead a "#include " be added at the top of this file?
Either that or we
Lars Gullik Bj?nnes wrote:
> Rob Lahaye <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bj?nnes wrote:
>
>>>Rob Lahaye <[EMAIL PROTECTED]> writes:
>>>
>>>
>>>| Should instead a "#include " be added at the top of this file?
>>>
>>>Either that or we should use lyx::support::abort instead.
>>>(I'll p
On Wed, Sep 10, 2003 at 12:04:48PM +, Angus Leeming wrote:
> > So this mean that if std::string derived from basic_string instead of
> > being a typedef, it would be forward-declarable?? Why isn't this done?
>
> That's right it would. I don't know.
>
> (You could propose 'class lyxstring : pu
On Wed, Sep 10, 2003 at 11:59:59AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > But not nice (read UGLY). In fact I neither like the template idea and
> > certainly not the macro.
> >
> > [OTOH, enums are rarely nice...]
> >
> > [And if you keep pushing on that I'll see the day when we'
Jean-Marc Lasgouttes wrote:
>> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> On Wednesday 10 September 2003 10:17 am, Jean-Marc Lasgouttes
> Angus> wrote:
>>> The difference is whether one has to include std_string.h and
>>> boost/scoped_ptr.hpp. I'd be surprised if this was
On Wed, Sep 10, 2003 at 12:47:57PM +0200, Jean-Marc Lasgouttes wrote:
> Angus> You aren't. Class EnumLColor is not a template. It derives from
> Angus> a template instantiation. That's the trick. (And it works. See
> Angus> the forward declaration of function 'compare' in the sample
> Angus> code.)
Andre Poenitz wrote:
> But not nice (read UGLY). In fact I neither like the template idea and
> certainly not the macro.
>
> [OTOH, enums are rarely nice...]
>
> [And if you keep pushing on that I'll see the day when we'll have the
> template but not the macros getting nice obfuscated code...]
T
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> On Wednesday 10 September 2003 10:17 am, Jean-Marc Lasgouttes
Angus> wrote:
>>> The difference is whether one has to include std_string.h and
>>> boost/scoped_ptr
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> When I want to leave the inset
That would be leave and close, which is a bit different.
We probably need a INSET_OPEN and INSET_CLOSE (since toggling is not
very useful scripting-wise).
This is an example where scripts and us
On Wed, Sep 10, 2003 at 12:13:30PM +0200, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> Andre> On Wed, Sep 10, 2003 at 10:51:24AM +0200, Jean-Marc Lasgouttes
> Andre> wrote:
> >> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
> >>
> Andre
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> On Wednesday 10 September 2003 10:17 am, Jean-Marc Lasgouttes
Angus> wrote:
>> The difference is whether one has to include std_string.h and
>> boost/scoped_ptr.hpp. I'd be surprised if this was negligible
>> (especially the second
On Wed, Sep 10, 2003 at 11:00:44AM +, Angus Leeming wrote:
> On Wednesday 10 September 2003 9:03 am, Andre Poenitz wrote:
> > > Why not just just move the LColor::color enum out of the LColor class?
> > > This would be much easier...
> > >
> > > We could just define a LColorTag enum in its own
Hmmm
class BufferParams {
public:
AuthorList & authors();
private:
/** Use the Pimpl idiom to hide those member variables that would otherwise
drag in other header files.
*/
class Impl;
lyx::support::cow_ptr pimpl_;
};
AuthorList & BufferParams
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Lars Gullik Bj?nnes wrote:
>> Rob Lahaye <[EMAIL PROTECTED]> writes:
>>
>>
>> | Should instead a "#include " be added at the top of this file?
>>
>> Either that or we should use lyx::support::abort instead.
>> (I'll probably prefere that.)
>
| Either way
On Wednesday 10 September 2003 10:17 am, Jean-Marc Lasgouttes wrote:
> The difference is whether one has to include std_string.h and
> boost/scoped_ptr.hpp. I'd be surprised if this was negligible
> (especially the second one).
There are no #includes in EnumWrapper.h. I don't understand your point
Lars Gullik Bj?nnes wrote:
> Rob Lahaye <[EMAIL PROTECTED]> writes:
>
>
> | Should instead a "#include " be added at the top of this file?
>
> Either that or we should use lyx::support::abort instead.
> (I'll probably prefere that.)
Either way.
As it is now, CVS doesn't compile :(.
R.
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> How would that help? enums cannot be forward declared, so any
Angus> header file declaring a function that is passed an enum must
Angus> #include the header file that defines the enum. It makes not a
Angus> jot of difference whether
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Wed, Sep 10, 2003 at 10:51:24AM +0200, Jean-Marc Lasgouttes
Andre> wrote:
>> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
Andre> I think LFUN_INSET_TOGGLE toggles the inset to the right if
Andre> there is one or
Angus Leeming <[EMAIL PROTECTED]> writes:
| On Wednesday 10 September 2003 9:03 am, Andre Poenitz wrote:
>> > Why not just just move the LColor::color enum out of the LColor class?
>> > This would be much easier...
>> >
>> > We could just define a LColorTag enum in its own header file, and have
>>
Rob Lahaye wrote:
> ChangeLog:
> Add a "()" inbetween "params" and ".getLyXTextClass()".
>
> Sorry, but that's all I can say; "why and how this has become an error
> and such-and-such is the fix" should better go in the ChangeLog.
> Who knows this?
Angus has replaced direct access to some variab
Rob Lahaye wrote:
> No I don't, because I have no idea what I'm doing.
> Well, if you insist:
>
> ChangeLog:
> Add a "()" inbetween "params" and ".getLyXTextClass()".
>
> Sorry, but that's all I can say; "why and how this has become an error
> and such-and-such is the fix" should better go in the
On Wednesday 10 September 2003 9:03 am, Andre Poenitz wrote:
> > Why not just just move the LColor::color enum out of the LColor class?
> > This would be much easier...
> >
> > We could just define a LColorTag enum in its own header file, and have
> > LColor operate on LColorTag instead of LColor::
Alfredo Braunstein wrote:
> Rob Lahaye wrote:
>
>
>>Yes that helps.
>>Path below does the trick. Someone willing to apply
>
>
> If you add a ChangeLog entry I can apply it.
No I don't, because I have no idea what I'm doing.
Well, if you insist:
ChangeLog:
Add a "()" inbetween "pa
Rob Lahaye wrote:
> Yes that helps.
> Path below does the trick. Someone willing to apply
If you add a ChangeLog entry I can apply it.
Alfredo
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Lars Gullik Bj?nnes wrote:
>> Rob Lahaye <[EMAIL PROTECTED]> writes:
>>
>> | Index: src/boost.C
>> | ===
>> | RCS file: /cvs/lyx/lyx-devel/src/boost.C,v
>> | retrieving revision 1.4
>> | diff
Martin Vermeer wrote:
>
> Probably. Try if replacing params by params() helps.
Yes that helps.
Path below does the trick. Someone willing to apply
Cheers,
Rob.
Index: src/frontends/gtk/GToolbar.C
===
RCS file: /cvs/lyx/lyx-dev
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Sep 04, 2003 at 02:43:12PM +0200, Lars Gullik Bjønnes wrote:
>> Kuba Ober <[EMAIL PROTECTED]> writes:
>>
>> | On czwartek 04 wrzesieñ 2003 09:25 am, Angus Leeming wrote:
>> >> On my 2.7GHz machine the link step now takes 1:27 (xforms), 1:36 (qt)
Lars Gullik Bj?nnes wrote:
> Rob Lahaye <[EMAIL PROTECTED]> writes:
>
> | Index: src/boost.C
> | ===
> | RCS file: /cvs/lyx/lyx-devel/src/boost.C,v
> | retrieving revision 1.4
> | diff -u -r1.4 boost.C
> | --- src/boost.C 2003/09
On Thu, Sep 04, 2003 at 02:43:12PM +0200, Lars Gullik Bjønnes wrote:
> Kuba Ober <[EMAIL PROTECTED]> writes:
>
> | On czwartek 04 wrzesieñ 2003 09:25 am, Angus Leeming wrote:
> >> On my 2.7GHz machine the link step now takes 1:27 (xforms), 1:36 (qt). This
> >> is making it somewhat painful to code
On Wed, Sep 10, 2003 at 11:11:20AM +0200, Lars Gullik Bjønnes wrote:
> | PS: When I think about it, if the 'basic storage unit' would be a 'Row'
> | not a 'Paragraph', we had a 'natural way' to identify these two
> | positions. But I am not sure this won't hurt anywhere else...
>
> Then you would
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Sep 10, 2003 at 10:42:02AM +0200, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> | On Thu, Sep 04, 2003 at 01:27:20PM +0100, John Levon wrote:
>> >> On Thu, Sep 04, 2003 at 02:23:52PM +0200, Lars Gullik Bj?nnes wro
On Wed, Sep 10, 2003 at 10:51:24AM +0200, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> Andre> I think LFUN_INSET_TOGGLE toggles the inset to the right if
> Andre> there is one or the inset containing the current cursor if
> Andre> there is no inset t
On Wed, Sep 10, 2003 at 10:49:57AM +0200, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> One of the major reasons that we have to #include header files
> Angus> in header files is because we cannot forward declare enums.
> Angus> Witness the fac
On Wed, Sep 10, 2003 at 10:42:02AM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Thu, Sep 04, 2003 at 01:27:20PM +0100, John Levon wrote:
> >> On Thu, Sep 04, 2003 at 02:23:52PM +0200, Lars Gullik Bj?nnes wrote:
> >>
> >> > Just answer my questions in stea
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> On Fri, Sep 05, 2003 at 06:01:12PM +0200, Asger Kunuk Alstrup
Andre> wrote:
>> On Fri, 5 Sep 2003, Angus Leeming wrote:
>>
>> > support/textutils.h cannot currently be compiled stand-alone. To
>> do so would > require a > #include
Rob Lahaye <[EMAIL PROTECTED]> writes:
| Index: src/boost.C
| ===
| RCS file: /cvs/lyx/lyx-devel/src/boost.C,v
| retrieving revision 1.4
| diff -u -r1.4 boost.C
| --- src/boost.C 2003/09/09 17:25:17 1.4
| +++ src/boost.C
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> I think LFUN_INSET_TOGGLE toggles the inset to the right if
Andre> there is one or the inset containing the current cursor if
Andre> there is no inset to the right.
Andre> Which, of course, are two different things and probablyu sh
On Wed, Sep 10, 2003 at 10:37:38AM +0200, Andre' Poenitz wrote:
> On Tue, Sep 09, 2003 at 04:21:04PM +, Angus Leeming wrote:
> > This patch is a 'pragmatic pimpl-ing' of BufferParams. It moves into Impl only
> > those member variables that currently drag in header files into
> > bufferparams.
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> One of the major reasons that we have to #include header files
Angus> in header files is because we cannot forward declare enums.
Angus> Witness the fact that LColor.h has the greatest number of
Angus> dependencies in the entire pro
Angus Leeming <[EMAIL PROTECTED]> writes:
| Next little shell script is designed to remove those nasty 'using namespace'
| directives that Lars shoved in when introducing namespace lyx::support. (No
| I'm not blaming anyone.)
>
| It currently removes 'em all and then parses the error messages:
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Sep 04, 2003 at 01:27:20PM +0100, John Levon wrote:
>> On Thu, Sep 04, 2003 at 02:23:52PM +0200, Lars Gullik Bj?nnes wrote:
>>
>> > Just answer my questions in stead.
>> > In a text editor "End" is needed, but does it _really_ make sense in
>> >
On Tue, Sep 09, 2003 at 04:21:04PM +, Angus Leeming wrote:
> This patch is a 'pragmatic pimpl-ing' of BufferParams. It moves into Impl only
> those member variables that currently drag in header files into
> bufferparams.h.
>
> I had two choices when implementing it.
> * Explicitly define a
On Tue, Sep 09, 2003 at 01:13:09PM +0200, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
> | Moves bufferparams.h, lyxvc.h, texrow.h out of buffer.h.
> | Ok to go in?
> >
> | You'll see that the patch adds #include "bufferparams.h" to lots of .C files.
> | Looking at buf
On Tuesday 09 September 2003 23:52, Kayvan A. Sylvan wrote:
> My prior committee chair (for Cub Scouts) needs an update
> to an old document, except I can't read it with the lyx from CVS.
You know how to get my attention. ;-) I work also with Cub Scouts. :-)
As Angus I don't have any problem c
On Fri, Sep 05, 2003 at 06:01:12PM +0200, Asger Kunuk Alstrup wrote:
> On Fri, 5 Sep 2003, Angus Leeming wrote:
>
> > support/textutils.h cannot currently be compiled stand-alone. To do so would
> > require a
> > #include "paragraph.h".
> >
> > inline
> > bool IsInsetChar(char c)
> > {
> >
On Thu, Sep 04, 2003 at 01:27:20PM +0100, John Levon wrote:
> On Thu, Sep 04, 2003 at 02:23:52PM +0200, Lars Gullik Bj?nnes wrote:
>
> > Just answer my questions in stead.
> > In a text editor "End" is needed, but does it _really_ make sense in
> > LyX?
>
> Absolutely. It's basic navigation.
>
>
On Wed, Sep 03, 2003 at 12:07:58PM +0200, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> Unfortunately, it appears that the code in toggleInset no
> Angus> longer moves the cursor. Hence the request for your expertise
> Angus> ;-)
>
> toggleIns
On Wed, Sep 03, 2003 at 12:55:37PM +0300, Martin Vermeer wrote:
> On Wed, Sep 03, 2003 at 11:23:38AM +0200, Jean-Marc Lasgouttes spake thusly:
>
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> >
> > >> Sigh. Jean Marc's code. Ask him how it is supposed to work. (He is
> > >> n
On Wed, Sep 10, 2003 at 03:42:18PM +0900, Rob Lahaye spake thusly:
>
>
> GToolbar.C: In member function `void GToolbar::onLayoutSelected()':
> GToolbar.C:163: error: request for member `getLyXTextClass' in `
> this->GToolbar::view_->LyXView::buffer() const()->params', which is of
> non-
94 matches
Mail list logo
