emacs-devel
[Top][All Lists]
Advanced

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

Re: An idea: combine-change-calls


From: Stefan Monnier
Subject: Re: An idea: combine-change-calls
Date: Sat, 31 Mar 2018 19:38:03 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

> >     (defun wrap-and-run-primitive-undo (beg end list)
> >       (combine-change-calls
> That's a refinement I haven't managed to get around to, yet.

Any difficulty there?
Naively, I'd expect that it's just a matter of:

    (defun undo--wrap-and-run-primitive-undo (beg end list)
      (combine-change-calls
        (while list
          (setq list (primitive-undo 1 list)))))
  
[ and of course, making sure this function is defined after the
  combine-change-calls macro.  ]

>>     (defmacro combine-change-calls (beg end &rest forms)
>>       `(combine-change-calls-function ,beg ,end (lambda () ,@forms)))
> DONE, at least with the name combine-change-calls-1.

Good.

> I don't really like "...-function", since that suggests
> a hook variable.

I'm not too fond of those either for the same reason, although I must
admit to using such names occasionally.

> Not only can, but does.  I spent around 2 hours yesterday waiting for
> this infinite loop to terminate.  ;-(

I'm sure it was just a question of time.

> It is, of course, garbage collection which lops off the element we're
> looking for, particularly when commenting out a large region.

Yes, that should be the most common reason.

> So, I think this exercise is worthwhile.  I have added some doc strings
> to the functions.  I have introduced a variable to hinder a "recursive"
> undo--wrap-and-run-primitive-undo appearing in the undo list.  This
> happened with uncomment-region calling comment-region.

That's weird: shouldn't the inhibit-modification-hooks already play this role?

Oh, wait, I see you don't test inhibit-modification-hooks any more but
you test undo--combining-change-calls instead.  Any particular reason
for this change?

> Sometimes, point ends up at the wrong place after an undo (probably
> because of primitive-undo removing POSITION elements from undo-lists, as
> we've already discussed.)

The code that removes those "position" elements is in `undo`, not in
`primitive-undo`, so what you're describing must come from something
else (unless you're seeing this when *redoing* or *reundoing*).


        Stefan



reply via email to

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