emacs-devel
[Top][All Lists]
Advanced

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

Re: disabling undo boundaries


From: Phillip Lord
Subject: Re: disabling undo boundaries
Date: Wed, 27 May 2015 12:46:43 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.0.0.0 (gnu/linux)

Phillip Lord <address@hidden> writes:

> Stefan Monnier <address@hidden> writes:
>> Another approach would be for you to arrange such that your a-f-c uses
>> self-insert-command rather than `insert' when cloning the insertion
>> from a self-insert-command, but that's probably just as hard if not
>> harder.
>
> That doesn't sound great to me either, as I have to behave quite
> differently depending on the last-command.
>
> It seems to me, that you are not adverse to the idea of changing undo.c
> to stop it putting boundaries in. Can I suggest a way forward? I will
> carry on with my hacked Emacs with removed undo-boundaries in undo.c. I
> can add the "undo-boundary to all changed buffers" using
> post-command-hook. This will let me test everything makes sense and
> works as expected, and I don't mind spending the effort, if emacs will
> support it later.
>
> If you are prepared to implement the "add an undo-boundary to every
> buffer thats changed" logic into undo.c/cmd.c, then we can do that once
> the logic works. I would be willing to help with that, but my C
> programming is very poor, and in practice, I'm likely to learn more than
> I actually help.


Actually, I have been thinking about this. What I worry about with this
is that we may be adding the same form of heuristic into undo.c as the
"insert an undo-boundary if the buffer has changed". And once is in the
C layer it is effectively unfixable from lisp. The existing logic does
not seem unsensible, but actually does not work in my (admitted niche)
set of circumstances.

So, it may be that simply removing the existing logic is the right thing
to do!

Phil



reply via email to

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