I think I have to take back the claim that typing is not slow, when the
macros are not defined. Apparently, I tested it in the wrong equation.
In the first equation of appendix C, typing is still dead slow, even
with undefined macros. So probably it's not the fault of your macros!
Sorry for all th
> Is it really slower at the document end than at the beginning? Cannot
> see a big difference here.
In principle I thought that there is such a relation, because in the
first equation of the document, there is no dilatation at all, while at
later parts there is. BUT: I just figured out, that ty
Is it really slower at the document end than at the beginning? Cannot
see a big difference here.
Stefan
Am 18.11.2007 um 15:35 schrieb sebastian guttenberg:
Let's see. There is a hope that the 20% figure was not so precise and
it's more in fact ;-)
I just figured out that typing at the end
> Let's see. There is a hope that the 20% figure was not so precise and
> it's more in fact ;-)
I just figured out that typing at the end of the document is not slow
when I do not define the math-macros at the beginning.
-sebastian
--
This message has been scanned for viruses and
dangerous c
Am 18.11.2007 um 14:02 schrieb sebastian guttenberg:
The macro part takes 20% of the runtime, when writing math at the
document end. I already have ideas how to reduce that. Otherwise
there
are a lot of metrics and draw calls around taking much time. Not sure
if that is related to macros at
> The macro part takes 20% of the runtime, when writing math at the
> document end. I already have ideas how to reduce that. Otherwise there
> are a lot of metrics and draw calls around taking much time. Not sure
> if that is related to macros at all.
Aha. Thanks a lot for the info!
That mea
The macro part takes 20% of the runtime, when writing math at the
document end. I already have ideas how to reduce that. Otherwise there
are a lot of metrics and draw calls around taking much time. Not sure
if that is related to macros at all.
Stefan
Am 16.11.2007 um 13:53 schrieb sebastia
On Fri, Nov 16, 2007 at 03:19:13PM +0200, sebastian guttenberg wrote:
> On Fri, 2007-11-16 at 14:05 +0100, Stefan Schimanski wrote:
> > Thanks!
> >
> > Looks like a perfect document for some profiling to find the
> > bottlenecks.
> >
> > Indeed it's quite slow at the end. Will run a profiler to
fine for
me, I have only problems in the math-environment.
I have a core 2 dual Pentium with 166Mhz.
Is this a known problem? Can it be related to math-macros?
I will attach my file only on request. Please tell me, if I should do
so.
Yes please. Need to see the file.
Stefan
> Complained that it was too big. I guess it's fine now, as Stefan has a
> copy, but for the future it would be good to know, what to do with big
> example files for the mailing list...
you can put them in wiki or bugzilla and give only url.
pavel
On Fri, 2007-11-16 at 14:05 +0100, Stefan Schimanski wrote:
> Thanks!
>
> Looks like a perfect document for some profiling to find the
> bottlenecks.
>
> Indeed it's quite slow at the end. Will run a profiler tonight. Then
> we should know.
>
> Stefan
Thanks Stefan for taking care!
By the w
Thanks!
Looks like a perfect document for some profiling to find the
bottlenecks.
Indeed it's quite slow at the end. Will run a profiler tonight. Then
we should know.
Stefan
Am 16.11.2007 um 13:53 schrieb sebastian guttenberg:
Hi Stefan!
Here it is. (It was also the file, where I had t
t the case in 1.5.2, but I am not sure
as I have seen the bug 4054:
http://bugzilla.lyx.org/show_bug.cgi?id=4054
But reading it, it seems to be different, as it refers to typing
ordinary text (with math in the same paragraph). But this is fine for
me, I have only problems in the math-environment.
I h
ms in the math-environment.
I have a core 2 dual Pentium with 166Mhz.
Is this a known problem? Can it be related to math-macros?
I will attach my file only on request. Please tell me, if I should do
so.
Don't pass --enable-stdlib-debug, this is known to slow down things a
lot. But stay wit
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
True. But most LFUNs in Text::dispatch() do not really belong there.
This is part of your desire to redefine what Text is, if I understand
correctly. In this case, the handling should be moved to InsetText.
Yes, proba
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> True. But most LFUNs in Text::dispatch() do not really belong there.
This is part of your desire to redefine what Text is, if I understand
correctly. In this case, the handling should be moved to InsetText.
JMarc
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Because conceptually Text doesn't know where the cursor is, only
> Cursor itself knows. So Cursor should ask the current paragraph if it
> is a TOC type or not. Absolutely no property of Text is used during
> this decision process. This way, we won't
Andre Poenitz wrote:
On Tue, Nov 06, 2007 at 03:13:35PM +0100, Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Jean-Marc Lasgouttes wrote:
And what about moving this from BufferView (which is for all
highly editable insets == text+math) to Text3.cpp (which is only for
text)?
Like this?
On Tue, Nov 06, 2007 at 03:13:35PM +0100, Abdelrazak Younes wrote:
> Jürgen Spitzmüller wrote:
>> Jean-Marc Lasgouttes wrote:
>>> And what about moving this from BufferView (which is for all
>>> highly editable insets == text+math) to Text3.cpp (which is only for
>>> text)?
>> Like this?
>
>
> +
Jürgen Spitzmüller wrote:
Jean-Marc Lasgouttes wrote:
Yes, but see below.
I've fixed the remaining issues and committed to branch.
For trunk, there's the difference that Outline is a(n anonymous) function of
BufferView.
Abdel, what are your plans? Should this function be moved to text with
Jean-Marc Lasgouttes wrote:
> Yes, but see below.
I've fixed the remaining issues and committed to branch.
For trunk, there's the difference that Outline is a(n anonymous) function of
BufferView.
Abdel, what are your plans? Should this function be moved to text with the
LFUN's or made public?
Jürgen Spitzmüller wrote:
Jean-Marc Lasgouttes wrote:
Are the curly braces needed?
No, but most of the other elements in the switch embrace their content, so I
thought I adapt to that.
I don't care. I'll remove them again.
FYI, they are only needed if you do declaration inside the case.
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> Jean-Marc Lasgouttes wrote:
>> Are the curly braces needed?
>
> No, but most of the other elements in the switch embrace their content, so I
> thought I adapt to that.
Only when they declare a variable.
JMarc
Jean-Marc Lasgouttes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Jürgen Spitzmüller wrote:
Jean-Marc Lasgouttes wrote:
And what about moving this from BufferView (which is for all
highly editable insets == text+math) to Text3.cpp (which is only for text)?
Like this?
+ case L
Jean-Marc Lasgouttes wrote:
> Are the curly braces needed?
No, but most of the other elements in the switch embrace their content, so I
thought I adapt to that.
I don't care. I'll remove them again.
> I think cur.paragraph() is enough since we are in Text.
You're right.
Jürgen
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Jürgen Spitzmüller wrote:
>> Jean-Marc Lasgouttes wrote:
>>> And what about moving this from BufferView (which is for all
>>> highly editable insets == text+math) to Text3.cpp (which is only for text)?
>>
>> Like this?
>
>
> + case LFUN_OUTLINE_U
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> Jean-Marc Lasgouttes wrote:
>> And what about moving this from BufferView (which is for all
>> highly editable insets == text+math) to Text3.cpp (which is only for text)?
>
> Like this?
Yes, but see below.
> + case LFUN_OUTLINE_UP: {
> +
Abdelrazak Younes wrote:
> Can't we put these and (many others) in a new Cursor::getStatus instead?
> Text is used (abused) for many things already.
But not for branch.
Jürgen
Jürgen Spitzmüller wrote:
Jean-Marc Lasgouttes wrote:
And what about moving this from BufferView (which is for all
highly editable insets == text+math) to Text3.cpp (which is only for text)?
Like this?
+ case LFUN_OUTLINE_UP:
+ case LFUN_OUTLINE_DOWN:
+ case LFUN_OUTLINE_I
Jean-Marc Lasgouttes wrote:
> And what about moving this from BufferView (which is for all
> highly editable insets == text+math) to Text3.cpp (which is only for text)?
Like this?
Jürgen
Index: src/BufferView.cpp
===
--- src/BufferVi
Jean-Marc Lasgouttes wrote:
> No, if the lfun is only handled in Text what happens is that
>
> - Cursor::dispatch asks the top slice (mathed) whether it knows about
> outline ==> no
>
> - Cursor::dispatch asks the next slice (text) whether it knows about
> outline ==> yes!
>
> - the outline stu
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> Jean-Marc Lasgouttes wrote:
>> OK then. But I still think that moving the code to Text is better
>> (since the code only works in text).
>
> So you think the lfun should be disabled if the cursor is in mathed, even if
> the formula is part of a sec
Jürgen Spitzmüller wrote:
Jean-Marc Lasgouttes wrote:
OK then. But I still think that moving the code to Text is better
(since the code only works in text).
So you think the lfun should be disabled if the cursor is in mathed, even if
the formula is part of a section?
No, you should enable a
Jean-Marc Lasgouttes wrote:
> OK then. But I still think that moving the code to Text is better
> (since the code only works in text).
So you think the lfun should be disabled if the cursor is in mathed, even if
the formula is part of a section?
Jürgen
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> Jean-Marc Lasgouttes wrote:
>> What happens if you just remove mention of these LFUNS from the mathed
>> getstatus? This should be enough to get everything working.
>
> they are not mentioned in mathed/ anywhere.
Sorry. And what about moving this f
Jean-Marc Lasgouttes wrote:
> What happens if you just remove mention of these LFUNS from the mathed
> getstatus? This should be enough to get everything working.
they are not mentioned in mathed/ anywhere.
> I suspect that your patch does not work for nested math insets.
It does. I have tested
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes:
> Jürgen Spitzmüller wrote:
>> Objections?
>
> It turned out that the attached extension is needed, else LyX still crashes.
> BTW if you wonder why I don't just disable those lfuns for mathed: they work
> if you are in a formula in a section, for ins
Jürgen Spitzmüller wrote:
Objections?
Looks correct.
Abdel.
Jürgen Spitzmüller wrote:
> Objections?
It turned out that the attached extension is needed, else LyX still crashes.
BTW if you wonder why I don't just disable those lfuns for mathed: they work
if you are in a formula in a section, for instance (and they should be
disabled for simple paragraphs,
Objections?
Jürgen
Index: src/BufferView.cpp
===
--- src/BufferView.cpp (Revision 21446)
+++ src/BufferView.cpp (Arbeitskopie)
@@ -645,11 +645,6 @@
case LFUN_FONT_STATE:
case LFUN_LABEL_INSERT:
case LFUN_PARAGRAPH_GOTO:
- // FIX
On Mon, Sep 09, 2002 at 01:23:43PM +0200, Michael Abshoff wrote:
> 1. If you (manually) add a footnote in an eqn-array the resulting
> TeX-Code doesn't do
> the job right. It does display the footnote-symbol, but eats the
> footnote itself.
> The attached file demonstrates that case.
This is a
Hello everybody,
1. If you (manually) add a footnote in an eqn-array the resulting
TeX-Code doesn't do
the job right. It does display the footnote-symbol, but eats the
footnote itself.
The attached file demonstrates that case.
2. Another problem arises from the following TeX-Code (produced b
On Thu, Feb 28, 2002 at 10:35:19AM +0200, Staffan Ringbom wrote:
> Dear developers,
>
> By and large the math-editor is a nice piece.
> I would like to comment on the new math-editor in 1.2.0cvs.
these are now bugs #265, #266, #267
regards
john
--
I am a complete moron for forgetting about e
On Thu, 2002-02-28 at 09:35, Staffan Ringbom wrote:
> Dear developers,
>
> By and large the math-editor is a nice piece.
> I would like to comment on the new math-editor in 1.2.0cvs.
>
> 1. In 1.1.6fix4 I can insert normal text by M-c-m and I can insert
> spacings of suitable length just by p
Dear developers,
By and large the math-editor is a nice piece.
I would like to comment on the new math-editor in 1.2.0cvs.
1. In 1.1.6fix4 I can insert normal text by M-c-m and I can insert
spacings of suitable length just by pressing the spacebar, but I cannot
do these tricks in 1.2.0cvs. I
Dear developers,
By and large the math-editor is a nice piece.
I would like to comment on the new math-editor in 1.2.0cvs.
1. In 1.1.6fix4 I can insert normal text by M-c-m and I can insert
spacings of suitable length just by pressing the spacebar, but I cannot
do these tricks in 1.2.0cvs. I
46 matches
Mail list logo
