Re: An idea: combine-change-calls

[Stefan Monnier]

>> That's weird: shouldn't the inhibit-modification-hooks already play this 
>> role?
> I don't think so.  i-m-h is purely to do with whether the hooks should
> be run now.  That has nothing to do with how items should be added to
> the undo list.

Ah, I see what you mean.
[ tho I think in practice, there'll be no difference:
  the code which binds inhibit-modification-hooks in the context will
  already want to deal with the fact that the undo entries would normally
  not be run within such a inhibit-modification-hooks, so it'll usually
  bind buffer-undo-list to t or do something related.  ]

> I'm not sure.  I think it's in re-undoing.

Yes, that would be expected, indeed.

> As you've already guessed, I would be in favour of removing that code
> from `undo' that we don't see what it's for.

As I said, it's orthogonal to the current discussion (it affects many
more cases).  And I personally have no opinion on whether this behavior
should be considered as a bug or a feature.

> I think it's almost time to commit this to master.

Agreed.

> I propose that combine-change-calls{-1,} go into subr.el, beside
> combine-after-change-calls, and undo--wrap-and-run-primitive-undo go
> into simple.el, beside the rest of the undo stuff.

I don't have an opinion on which file it should go to, but
undo--wrap-and-run-primitive-undo belongs with the rest, so it'd make
a lot more sense to keep them all three together.

> I will introduce the variable comment-combine-change-calls in
> newcomment.el, and modify {,un}comment-region to test it, and if set, to
> use c-c-c.

I'm not sure we even need such a variable (tho I'd put the
combine-change-calls around comment-region-default, so it doesn't
affect other settings of comment-region-function).

> I will document c-c-c in the Elisp manual on page "Change Hooks".

Thanks.


        Stefan