Re: accept/reject all changes & undo

[Jean-Marc Lasgouttes]

> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:

Andre> On Mon, Jan 22, 2007 at 10:32:38AM +0100, Jean-Marc Lasgouttes
Andre> wrote:
>> In the case of Replace All, for example, each replace action would
>> be one entry, but the required memory would be much less than the
>> whole document.

Andre> Unless you replace 'e' by 'x' which will most likely record
Andre> each paragraph several times. But in general it sounds sane,
Andre> it's just out undo storage being too crude...

There are ways to avoid this particular problem:
http://www.amazon.com/Disparition-French-Language-Georges-Perec/dp/207071523X/ref=pd_sim_b_1/104-3543398-4830316

Another more useful idea is to collapse successive undo entries with
the same paragraph.

JMarc

Re: accept/reject all changes & undo

[Andre Poenitz]

On Mon, Jan 22, 2007 at 10:32:38AM +0100, Jean-Marc Lasgouttes wrote:
> In the case of Replace All, for example, each replace action would be
> one entry, but the required memory would be much less than the whole
> document.

Unless you replace 'e' by 'x' which will most likely record each
paragraph several times. But in general it sounds sane, it's just out
undo storage being too crude...

Andre'

Re: accept/reject all changes & undo

[Jean-Marc Lasgouttes]

> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:

Andre> ++locked_undo_

Andre> --locked_undo_

Andre> woudl scale better in the long run. What when blocked undos
Andre> should becme part of an even larger blob?

Actually I think now that this is not the correct way forward. I
rather see some thing like a startUndoGroup/endUndoGroup pair of
commands (with ++ and -- as you propose) and a change to the undo
structure to a stack of stacks. This will allow to group a series of
undo operations as a single action. When outside of an undo group,
there would be only one action per substack.

In the case of Replace All, for example, each replace action would be
one entry, but the required memory would be much less than the whole
document.

This solution would fix two problems:

- the fact that in some cases one action leads to several undo steps.
  This would be fixed if lyxFunc::dispatch had a pair of
  startUndo/endUndo calls, ensuring that all changes due to an lfun
  lead to a single undo operation.

- when a global operation is done on the buffer, only individual
  changes are kept.

JMarc

Re: accept/reject all changes & undo

[Andre Poenitz]

On Mon, Jan 15, 2007 at 10:27:16AM +0100, Jean-Marc Lasgouttes wrote:
> In undo.C we would have
> 
> void lockUndo()
> {
> BOOST_ASSERT(!locked_undo_);
> locked_undo_ = true;
> }

++locked_undo_

> void unlockUndo()
> {
> BOOST_ASSERT(locked_undo_);
> locked_undo_ = false;
> }

--locked_undo_

woudl scale better in the long run. What when blocked undos should becme
part of an even larger blob?


Andre'

Re: accept/reject all changes & undo

[Jean-Marc Lasgouttes]

> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:

Michael> 1. Select the complete document; accept the complete
Michael> selection (i.e. document) in one step Pros: simple to
Michael> implement Cons: may be slow; may be memory-consuming (depends
Michael> on how undo is implemented); the cursor is set to the
Michael> beginning of the document

This is indeed memory consuming, I do not think it is slow. You should
probably try it out.

Michael> 2. Optimize 1: Find the first and last paragraph that
Michael> contains a change; select this part of the document; accept
Michael> the selection

This could be tried if version 1 is not acceptable.

Michael> Undo/redo gurus: Is there a better approach? Is there some
Michael> kind of undo grouping concept that can be used in this case?

Well I have thoughts about an undo blocking mechanism that would work
like

//the real undo we want to apply
recordUndo(something);
lockUndo();
//call here methods that have there own undo calls
...
unlockUndo();


In undo.C we would have

void lockUndo()
{
BOOST_ASSERT(!locked_undo_);
locked_undo_ = true;
}

void unlockUndo()
{
BOOST_ASSERT(locked_undo_);
locked_undo_ = false;
}

and in doRecordUndo

if (locked_undo_)
break;


This would be useful in cases where undo is called too many times for
our taste. However, it would not help in your particular case.

JMarc

accept/reject all changes & undo

[Michael Gerz]

Hi,

invoking "accept/reject all changes" accidentally can be a nightmare, 
because you have to run "undo" as often as there are different changes 
in the document.


The technical reason for this is that these LFUNs iteratively look for 
the next change in the document and accept/reject each of them individually.


Unfortunately, I am not familiar with LyX's undo/redo mechanism. Two 
solutions come to my mind:


1. Select the complete document; accept the complete selection (i.e. 
document) in one step

Pros: simple to implement
Cons: may be slow; may be memory-consuming (depends on how undo is 
implemented); the cursor is set to the beginning of the document


2. Optimize 1: Find the first and last paragraph that contains a 
change; select this part of the document; accept the selection


Undo/redo gurus: Is there a better approach? Is there some kind of undo 
grouping concept that can be used in this case?


Any help is greatly appreciated!

Regards,
Michael