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'
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
| ---
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
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 the
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 to
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.
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
| ---
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
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
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...
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
Hmmm...
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
>
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
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
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
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 this
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
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
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, this case 6
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. Actually,
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
> "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
> "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
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, skip out of
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 determine whether the
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 would be almost
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 that caching
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
> "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,
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
> "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 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>
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
> >
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
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 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 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, here's a fresh patch.
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 this
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 same way as
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
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
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>
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 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
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 OK, here's a
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
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
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 not
apply
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
> "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
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 intrusive indeed.
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
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 the
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 change needsUpdate
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 days though.
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 functionality (I
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
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 needsUpdate (and
The patch did not apply well to todays CVS.
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:
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
> "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
> "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
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
> "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 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
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
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
The patch did not apply well to todays CVS.
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:
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 return value
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 updates for no
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?
No, the value is
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 what you mean:
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?
I do not
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?
JMarc
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. Thanks.
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?
Martin See
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 to lyxfunc. Same
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 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
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 results in the cursor
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,
> "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
> "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
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?
Martin> See attached. Same functionality.
I realize that I am not sure of
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>
> "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?
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.
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>
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
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
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
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: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,
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_
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:55:45 -
1 - 100 of 116 matches
Mail list logo
