Re: Apropos 54f297904e0c: Temporarily comment out CC Mode from tests which are incompatible with it.

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Mon, Jan 21, 2019 at 13:04:57 -0500, Stefan Monnier wrote:
> > If I said the sky was blue would you say "where's your evidence?"?

> > It is a fact that c-electric-brace controls, and must control, each
> > change to the buffer which is done.

> Not only I don't think that this is true, but I don't even know exactly
> what it means (IOW, yes it's probably true for some interpretation of
> it, but not for others).

> > This is self evident from reading the source code.

> I don't see this evidence.

Look in c-do-brace-electrics in an up to date (i.e. within the last few
days) version of cc-cmds.el.  This function is called from several
places in c-electric-brace.

About 60% the way through is the "brace-else-brace" cleanup.  It works
by scanning the buffer for a particular pattern.  If arbitrary changes
(i.e. those not controlled by the major mode) have been made to the
buffer, the pattern might not be found when it should be.  For example.

This was precisely the cause of bug #33794.  The user typed "{", but
unknown to c-electric-brace, self-insert-command randomly inserted "{}".
This extra "}" prevented auto-newline from working.

With the advent of post-self-insert-hook, it is clear that calling
self-insert-command from a function can lead to arbitrary buffer
changes.  To prevent this, c-electric-brace and friends bind
post-self-insert to nil.  Another way to proceed would be your recent
suggestion of using insert rather than self-insert-command.

It is thus clear that the use of post-self-insert-hook is incompatible
with Lisp code which calls self-insert-command, since that use
effectively makes that function undefined.  The way this hook is
typically used is much more like advice (which modifies a function's
function) than a traditional hook (where the hook performs things
incidental to what triggers it, leaving the triggering event untouched).

> > Please read the source code for c-electric-brace and its immediate
> > sub-functions, understand it (it's not hard), and then come back to me
> > with any questions you may have.

> expand-abbrev also can be extensive changes during self-insert-command,
> and so can the auto-fill-function.

In practice, they haven't done so.  If they did, then using insert would
solve the problem.

> > It is a fact that electric-layout-mode and electric-pair-mode are
> > allowed to run from post-self-insert-hook, that they make buffer changes
> > which are outside the control of c-electric-brace.

> If you use electric-layout-mode and electric-pair-mode, then all that's
> left for c-electric-brace is to call self-insert-command.

No.  There's more to it than that.

> And indeed, I hope in the future that the { and } bindings will simply
> be removed from CC-mode.

Maybe in the medium future, when the pertinent generic functions are in
all Emacs versions supported by CC Mode (assuming that XEmacs support
will cease quite soon).

These generic functions have some way to go before they match the
functionality of CC Mode's own features.

> I understand that there's a transition needed between these two and this
> intermediate state can require more work, but it's important to keep the
> long term goal in mind when designing the current solution.

Whose long term goal?  My goal, both long and short term, is to keep CC
Mode working properly.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).