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
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
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
> "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
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
> "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_ = false;
}
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 cursor is
> "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 them
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
12 matches
Mail list logo
