>>>>> "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 asking for updates in two different ways,
>> haven't we?
Martin> What do you mean?
text3.C, line 469
case LFUN_UP_PARAGRAPH:
if (!cur.mark())
cur.clearSelection();
needsUpdate = cursorUpParagraph(cur);
finishChange(cur, false);
break;
and then text3.C, line 1531, end of LyXText::dispatch
if (!needsUpdate
&& &oldTopSlice.inset() == &cur.inset()
&& oldTopSlice.idx() == cur.idx()
&& !sel
&& !cur.selection())
cur.noUpdate();
else
cur.needsUpdate();
So, if needsUpdate is true, we set cur.result().update() to true. And
then, in lyxfunc.C, line 1547, end of LyXFunc::dispatch
default: {
view()->cursor().dispatch(cmd);
update |= view()->cursor().result().update();
if (!view()->cursor().result().dispatched())
update |= view()->dispatch(cmd);
break;
}
So the cur.result().update() value is used to see whether we want to
update the screen. So basically, since you update explicitely, you are
interfering with the existing mechanism that Andre put in place.
Also, this is related to the NoUpdate LyXAction flag that is set here:
{ LFUN_UP_PARAGRAPH, "paragraph-up", ReadOnly | NoUpdate},
What I feel basically is that your scheme should be integrated with
the DispatchResult stuff, maybe by changing the bool update() to a
more complicated flag, and that BufferView::update should not be
invoked explicitely in LyXText::dispatch.
Do I make sense to you?
JMarc
