> "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 documen
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
paragrap
> "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
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_ =
> "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
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 t