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

[Stefan Monnier]

> 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.

self-insert-command is a command more than a function, so code that
calls it should expect it to do "whatever happens when the user hits
the corresponding key", more or less.  Given all the things
self-insert-command does, there's very little you can rely on.
If you need to know more precisely what happens, then `insert` is
usually a better option.

>> 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.

I'm sure some users of Emacs have used abbrevs or auto-fill-functions in
very funny ways which break your code's assumptions.  Just because you
haven't heard from them doesn't mean the problem doesn't exist.

>> 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.

You mean the c-cleanup-list, I guess.  Indeed, before c-electric-brace
can be turned into an alias for self-insert-command, we'd need to add
another post-self-insert-hook which implements the
c-cleanup-list feature.

AFAICT from the docstring, it's the only thing still missing.

>> 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?

At the very least mine.

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

That's orthogonal.

To give you a similarly general goal, my own goal is to make it so that
any feature which makes sense in many major mode be implemented once and
then used in the relevant major modes, rather than being implemented
independently for those major modes.

This is both for uniformity between major modes, and because it both
simplifies and improves many major modes (which would otherwise either
not provide the feature or only in very primitive ways).

And those maintainers like you who did go to the trouble of being early
implementers of the feature suffer through the pain of having to adapt
their code once the generic version of the feature becomes available.
Sometimes even at the cost of having the new feature working slightly
worse in some corner cases.

But many of them are quite happy to be able to drop their old code and
get rid of that responsibility (i.e. bug reports about regressions can
be redirected to Emacs maintainers).


        Stefan