[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Undo discard prompt (was: [T. V. Raman] read-only modes should be us

From: T. V. Raman
Subject: Re: Undo discard prompt (was: [T. V. Raman] read-only modes should be using buffer-disable-undo?)
Date: Sun, 23 Jan 2005 09:05:56 -0800

Great summary -- thanks!
Let's treat that dialog as a debugging tool for now, create a
customization switch that controls it,
and promise ourselves to run with that switch turned  on at least half
the time to spot places where bad undo  management is happening.

Also, it might be useful to create a robust with-buffer-undo-disabled
macro that authors can wrap around their code at points where they
dont care about undo. 
We could then potentially control bad undo behavior by initially
wrapping badly behaved code with that macro through an appropriately
defined advice fragment, and once that that is tested, cleanly migrate
the macro call into the offending package and drop the advice
>>>>> "Luc" == Luc Teirlinck <address@hidden> writes:

    Luc> Stefan Monnier wrote:
    >> however the recent updates in simple.el that cause the yes/no
    >> dialog to ask about discarding undo information does pop up in
    >> shell-mode ---

    Luc>    BTW, I just wanted to say that since this undo-discard
    Luc> prompt was introduced I've bumped into it also in "normal"
    Luc> circumstances (just manual buffer editing) and have found it
    Luc> to be just really annoying (half the time it occurred in the
    Luc> middle of some kbd-macro and breaks the sequence of steps).

    Luc> It seems strange that you would routinely accumulate one
    Luc> large single undo entry in the process of manual buffer
    Luc> editing.  Are you sure that there is no inappropriate undo
    Luc> management involved somewhere?  Are keyboard macros what
    Luc> causes the problem?

    Luc>    I vote to replace the prompt with a warning.

    Luc>    Or even to just revert to the 21.3 behavior (I haven't
    Luc> actually seen anyone really complain about that good ol'
    Luc> behavior.  What was wrong with it?).

    Luc> I believe that we should at the very least offer a
    Luc> customizable option to silently discard the undo entry
    Luc> without querying.

    Luc> The prompt has turned out to be a great debugging tool, but
    Luc> it indeed can be a real nuisance.  For CVS users it is OK,
    Luc> because they can always report the incident.  Up till now,
    Luc> all such incidents really where due to very bad undo
    Luc> management.  This gets taken care of and the user can update
    Luc> his CVS.  End of problem.  Right now, 21.4 users that run
    Luc> into the problem will be stuck with it and if they encounter
    Luc> the popup routinely during normal editing, it could indeed be
    Luc> sufficient a nuisance that they might decide to stick with
    Luc> 21.3, unless we provide some way to disable the popups.

    Luc> In as far as what was wrong with previous behavior:

    Luc> If I understood correctly there first was a problem with
    Luc> Emacs crashing as a result of running out of memory due to
    Luc> one single undo entry growing completely out of control.  (If
    Luc> I understood correctly, there are situations where Emacs can
    Luc> crash due to memory overflow, in spite of the safeguards to
    Luc> prevent that.)  It was then decided to discard the last undo
    Luc> entry when it grew too large.  But then somebody complained
    Luc> about not being able to undo the last command in spite of the
    Luc> guarantees given in the documentation that you can always at
    Luc> least undo one single command.  If I understood correctly,
    Luc> the only really safe thing to do when confronted with the
    Luc> prompt is answer "Yes", because otherwise you risk a crash,
    Luc> after which you can not undo the last command anyway.
    Luc> Currently, the prompt does not warn about that.

    Luc> Sincerely,

    Luc> Luc.

Best Regards,

Email:  address@hidden
WWW:    http://emacspeak.sf.net/raman/
AIM:    TVRaman
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc

reply via email to

[Prev in Thread] Current Thread [Next in Thread]