Martin Vermeer <[EMAIL PROTECTED]> writes:
| On Mon, Oct 10, 2005 at 07:17:54PM +0200, Lars Gullik Bjønnes wrote:
| > Martin Vermeer <[EMAIL PROTECTED]> writes:
|
| ...
|
| > After these tiny changes, ok.
|
| Ah, but this has been in since last week... OK, I'll make the changes.
Hmm... seemed
On Mon, Oct 10, 2005 at 07:17:54PM +0200, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> | + int y0 = text->getPar(pit).ascent() - offset_ref_;
>
> If y0 never changes after this point, make it const.
But it does (outside the patch):
1357 // Grey at th
On Mon, Oct 10, 2005 at 07:17:54PM +0200, Lars Gullik Bjønnes wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> After these tiny changes, ok.
Ah, but this has been in since last week... OK, I'll make the changes.
- Martin
pgpW6QVdKy4mn.pgp
Description: PGP signature
Martin Vermeer <[EMAIL PROTECTED]> writes:
| Index: BufferView_pimpl.C
| ===
| RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
| retrieving revision 1.595
| diff -u -p -r1.595 BufferView_pimpl.C
| --- BufferView_pi
On Sat, Oct 08, 2005 at 03:23:30PM +0100, John Levon wrote:
> On Fri, Oct 07, 2005 at 09:28:02PM +0200, Andre Poenitz wrote:
>
> > However, I don't think we need to handle 125k pars very often.
>
> However, large paragraphs as a result of the branch inset are to be
> expected.
Good point.
Andre
On Sat, Oct 08, 2005 at 03:23:30PM +0100, John Levon wrote:
> On Fri, Oct 07, 2005 at 09:28:02PM +0200, Andre Poenitz wrote:
>
> > However, I don't think we need to handle 125k pars very often.
>
> However, large paragraphs as a result of the branch inset are to be
> expected.
>
> regards
> john
On Fri, Oct 07, 2005 at 09:28:02PM +0200, Andre Poenitz wrote:
> However, I don't think we need to handle 125k pars very often.
However, large paragraphs as a result of the branch inset are to be
expected.
regards
john
On Thu, Oct 06, 2005 at 12:14:41PM +0200, Helge Hafting wrote:
> The document with a 125k paragraph is fine as long as I
> don't work in the monster paragraph.
This is to be expected. We still have a granularity of one paragraph.
To make working with the monster par feasible we need Martin's singl
Jean-Marc Lasgouttes wrote:
"Helge" == Helge Hafting <[EMAIL PROTECTED]> writes:
Helge> Did that. There seems to be no display errors. Editing
Helge> documents, and resizing the userguide is fine.
Helge> The big file consisting of small paragraphs is still ok to
Helge> edit.
Is
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Precisely. The place would be in redoParagraph, the do...while
Martin> loop on z.
Martin> I wonder if this is enough, or if we should then also look at
Martin> the rendering side of things. Probably.
Yes, I guess this is needed
> "Helge" == Helge Hafting <[EMAIL PROTECTED]> writes:
Helge> I did a simple test, and there is a problem with this patch. It
Helge> keeps printing "case 6" all the time to stderr, there is so
Helge> much printing of this "error message" that my pc reach 100%
Helge> load.
Looking at the code,
Andre Poenitz wrote:
On Sun, Oct 02, 2005 at 01:26:06PM +0200, Andre' Poenitz wrote:
So we should try hard to pass through the critical path just once. I'll
send later today a preliminary patch that folds rowBreakPoint() and
setRowWidth(), i.e. reduces this by a factor of two and gives an o
On Sun, Oct 02, 2005 at 05:59:38PM +0300, Martin Vermeer wrote:
> On Sun, Oct 02, 2005 at 01:26:06PM +0200, Andre Poenitz wrote:
>
> ...
>
> > So we should try hard to pass through the critical path just once. I'll
> > send later today a preliminary patch that folds rowBreakPoint() and
> > setR
On Mon, 2005-10-03 at 12:16 +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> >> This would mean implementing SingleRow update instead of
> >> SinglePar, right?
>
> Martin> Yes, I think so. How to do it is another matter. I suspect
> Martin> th
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> This would mean implementing SingleRow update instead of
>> SinglePar, right?
Martin> Yes, I think so. How to do it is another matter. I suspect
Martin> that caching row.endpos() internally in lyxtext would be
Martin> enough.
This
On Mon, 2005-10-03 at 11:38 +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Yes... as it happens I was today thinking along similar lines.
> Martin> But wouldn't it be enough to just cache, e.g., the pos of row
> Martin> end, to determi
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Yes... as it happens I was today thinking along similar lines.
Martin> But wouldn't it be enough to just cache, e.g., the pos of row
Martin> end, to determine whether the current row content changes or
Martin> not, and if not, sk
On Thu, Sep 29, 2005 at 07:59:33PM +0300, Martin Vermeer wrote:
> On Thu, 2005-09-29 at 14:09 +0200, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> >
> > Martin> Here's a better one even. Now also delete and backspace are
> > Martin> treated in the s
On Sun, Oct 02, 2005 at 06:33:56PM +0300, Martin Vermeer wrote:
> On Fri, Sep 30, 2005 at 10:00:22AM +0200, Jean-Marc Lasgouttes wrote:
> > I'll try it out. Note though that the patches to ChangeLogs do not
> > apply because of a unicode<=>latin1 conversion.
>
> I suspect I found the reason for
On Fri, Sep 30, 2005 at 10:00:22AM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> On Thu, Sep 29, 2005 at 09:00:47PM +0200, Helge Hafting wrote:
> >> The patch did not apply well to todays CVS.
> >>
> >> Helge Hafting
>
> Martin> OK,
On Sun, Oct 02, 2005 at 01:26:06PM +0200, Andre Poenitz wrote:
...
> So we should try hard to pass through the critical path just once. I'll
> send later today a preliminary patch that folds rowBreakPoint() and
> setRowWidth(), i.e. reduces this by a factor of two and gives an overall
> gain of
On Sun, Oct 02, 2005 at 01:26:06PM +0200, Andre' Poenitz wrote:
> So we should try hard to pass through the critical path just once. I'll
> send later today a preliminary patch that folds rowBreakPoint() and
> setRowWidth(), i.e. reduces this by a factor of two and gives an overall
> gain of 8-12%
On Tue, Sep 27, 2005 at 05:51:47PM +0300, Martin Vermeer wrote:
> Sort of. But how would you do that? And how would you achieve this while
> preserving one-paragraph update where that is what you want? I sort of
> see what you are hinting at, but I have no idea how to do it.
The whole update mac
On Fri, 30 Sep 2005 10:00:22 +0200 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> On Thu, Sep 29, 2005 at 09:00:47PM +0200, Helge Hafting wrote:
> >> The patch did not apply well to todays CVS.
> >>
> >> Helge Hafting
>
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> On Thu, Sep 29, 2005 at 09:00:47PM +0200, Helge Hafting wrote:
>> The patch did not apply well to todays CVS.
>>
>> Helge Hafting
Martin> OK, here's a fresh patch.
I'll try it out. Note though that the patches to ChangeLogs do
This one applied fine, and works fine too.
My big file with normal paragraphs is a joy to edit,
typing in stuff as well as erasing.
My big file consisting of a single paragraph is "useable",
I have to type garbage in order to be a line ahead of lyx.
Helge Hafting
On Thu, Sep 29, 2005 at 09:00:47PM +0200, Helge Hafting wrote:
> The patch did not apply well to todays CVS.
>
> Helge Hafting
OK, here's a fresh patch.
- Martin
Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/
The patch did not apply well to todays CVS.
Helge Hafting
On Thu, 2005-09-29 at 14:09 +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Here's a better one even. Now also delete and backspace are
> Martin> treated in the same way as selfinsert.
>
> A question: could it be possible to change nee
On Sep 28, 2005, at 3:12 PM, Bennett Helm wrote:
On Sep 28, 2005, at 2:55 PM, Martin Vermeer wrote:
Cannot reproduce, with the patch. If you select right-to-left, cut
and
undo, the cursor will be where it was at the moment of cut, to the
left
of the restored text. If yuo select left-to-rig
On Sep 29, 2005, at 5:19 AM, Martin Vermeer wrote:
On Wed, 2005-09-28 at 16:25 +0200, Jean-Marc Lasgouttes wrote:
"Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Slowly grasping it... perhaps you'll like the attached more.
Martin> Note: no change to lyxfunc. Same functionalit
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> For example, when a LFUN requires SinglePar, the code would test
>> whether the metrics have changed to decide what to do.
>>
>> It is not that I am unhappy with the patch...
Martin> OK, I'll think some more. Will be gone for three
On Thu, Sep 29, 2005 at 02:09:55PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Here's a better one even. Now also delete and backspace are
> Martin> treated in the same way as selfinsert.
>
> A question: could it be possible to cha
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Here's a better one even. Now also delete and backspace are
Martin> treated in the same way as selfinsert.
A question: could it be possible to change needsUpdate (and thus
cur.result()) to be of type Update::flag and pass all th
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Both, i.e., we have the speed-up, but not the refresh problems
Martin> that Bennett noticed.
But what you recommend is your latest patch, right?
JMarc
On Wed, 2005-09-28 at 16:25 +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Slowly grasping it... perhaps you'll like the attached more.
> Martin> Note: no change to lyxfunc. Same functionality (I checked)
>
> This looks much less intr
On Sep 28, 2005, at 2:55 PM, Martin Vermeer wrote:
On Wed, Sep 28, 2005 at 02:39:29PM -0400, Bennett Helm wrote:
On Sep 28, 2005, at 2:29 PM, Juergen Spitzmueller wrote:
Martin Vermeer wrote:
1. Undo oddities:
(a) Cut ... paste ... undo works well for undoing the paste;
however,
undoing
On Wed, Sep 28, 2005 at 02:39:29PM -0400, Bennett Helm wrote:
> On Sep 28, 2005, at 2:29 PM, Juergen Spitzmueller wrote:
>
> >Martin Vermeer wrote:
> >
> >>>1. Undo oddities:
> >>>
> >>>(a) Cut ... paste ... undo works well for undoing the paste;
> >>>however,
> >>>undoing again to undo the cut
On Sep 28, 2005, at 2:29 PM, Juergen Spitzmueller wrote:
Martin Vermeer wrote:
1. Undo oddities:
(a) Cut ... paste ... undo works well for undoing the paste;
however,
undoing again to undo the cut results in the cursor appearing in
front of the text that was restored; it should be after it
Martin Vermeer wrote:
> > 1. Undo oddities:
> >
> > (a) Cut ... paste ... undo works well for undoing the paste; however,
> > undoing again to undo the cut results in the cursor appearing in
> > front of the text that was restored; it should be after it.
could you sketch a scenario? I couldn't
On Wed, Sep 28, 2005 at 11:19:27AM -0400, Bennett Helm wrote:
> On Sep 28, 2005, at 10:25 AM, Jean-Marc Lasgouttes wrote:
>
> >>"Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> >>
> >
> >Martin> Slowly grasping it... perhaps you'll like the attached more.
> >Martin> Note: no change
On Wed, Sep 28, 2005 at 03:39:01PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Alternatively, should we really try to interpret every boolean
> Martin> that gets returned somewhere as a sign that the screen needs
> Martin> updating?
On Sep 28, 2005, at 10:25 AM, Jean-Marc Lasgouttes wrote:
"Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Slowly grasping it... perhaps you'll like the attached more.
Martin> Note: no change to lyxfunc. Same functionality (I checked)
This looks much less intrusive indeed. Than
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Slowly grasping it... perhaps you'll like the attached more.
Martin> Note: no change to lyxfunc. Same functionality (I checked)
This looks much less intrusive indeed. Thanks.
Could people test this? Bennett, Helge, everyone?
J
On Wed, Sep 28, 2005 at 11:28:33AM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Alternatively, should we really try to interpret every boolean
> Martin> that gets returned somewhere as a sign that the screen needs
> Martin> updating?
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Alternatively, should we really try to interpret every boolean
Martin> that gets returned somewhere as a sign that the screen needs
Martin> updating?
Martin> See attached. Same functionality.
I realize that I am not sure of wh
On Wed, Sep 28, 2005 at 11:15:30AM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> As I understand it, the idea is that if a paragraph up motion
> Martin> takes the cursor off-screen, needsUpdate should become true.
> Martin> Right?
>
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Alternatively, should we really try to interpret every boolean
Martin> that gets returned somewhere as a sign that the screen needs
Martin> updating?
I do not like how this is basically removing Andre's effort of
avoiding update
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> As I understand it, the idea is that if a paragraph up motion
Martin> takes the cursor off-screen, needsUpdate should become true.
Martin> Right?
No, the value is the return value from LyXText::setCursor, which in
turn is the re
On Tue, Sep 27, 2005 at 06:33:25PM +0300, Martin Vermeer wrote:
> On Tue, Sep 27, 2005 at 04:58:22PM +0200, Jean-Marc Lasgouttes wrote:
> > > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
...
> > I do not know how to fix it, so I'll ask questions instead :)
> >
> > case LFUN_UP
On Tue, Sep 27, 2005 at 04:58:22PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Sort of. But how would you do that? And how would you achieve
> Martin> this while preserving one-paragraph update where that is what
> Martin> you want?
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Sort of. But how would you do that? And how would you achieve
Martin> this while preserving one-paragraph update where that is what
Martin> you want? I sort of see what you are hinting at, but I have no
Martin> idea how to do it.
On Tue, Sep 27, 2005 at 04:16:09PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Actually this code didn't work at all, i.e., these arguments
> Martin> could have been whatever and we wouldn't even have noticed.
> Martin> Now we do, a
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Actually this code didn't work at all, i.e., these arguments
Martin> could have been whatever and we wouldn't even have noticed.
Martin> Now we do, and this is the way to get the intended speedup.
OK.
>> Here we have case of as
On Tue, 2005-09-27 at 11:39 +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Lars?
>
> Martin> Attached a _real_ patch... cursed webmail.
>
> It would be nice to have a ChangeLog to be able to understand what is
> going on. For example
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Lars?
Martin> Attached a _real_ patch... cursed webmail.
It would be nice to have a ChangeLog to be able to understand what is
going on. For example, when I see the first chunk:
--- BufferView_pimpl.C15 Sep 2005 13:5
On Sun, 2005-09-25 at 20:36 +0300, Martin Vermeer wrote:
> Attached the summary of the speedup work over last week. It is a somewhat
> intrusive patch, but it got some good testing and I believe we caught all
> the side effects ;-)
>
> Lars, can this go in?
>
> - Martin
Lars?
Attached a _real_
Attached the summary of the speedup work over last week. It is a somewhat
intrusive patch, but it got some good testing and I believe we caught all
the side effects ;-)
Lars, can this go in?
- Martin
Index: BufferView_pimpl.C
===
58 matches
Mail list logo
