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

[Alan Mackenzie]

Hello, João,

On Sat, Jan 19, 2019 at 19:15:25 +0000, João Távora wrote:
> Alan Mackenzie <address@hidden> writes:

> > What you are in denial about, is that CC Mode and
> > electric-{pair,layout}-mode (as currently implemented) are incompatible
> > with each other.  I've explained this to you more times than I can
> > count, but you still refuse to accept it.

> How can I accept a something that you explain, but don't provide
> evidence of?

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.  This is self evident from reading
the source code.  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.

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.  This is also self
evident.

To keep control of buffer changes, and thus function correctly,
c-electric-brace must thus prevent the uncontrolled changes referred to
in the previous paragraph.  This is simple logical reasoning from the
previous two paragraphs.

If these uncontrolled buffer changes are prevented, electric-layout-mode
and electric-pair-mode do not work.  I think this is obvious enough not
to need justification.

If these uncontrolled buffer changes are allowed to take place,
c-electric-brace doesn't work properly.  Evidence for this, if any be
needed, is in the scenario in bug #33794.

The two previous paragraphs indicate the incompatibility between
c-electric-brace, and electric-layout/pair-mode.

What part of this argument gives you difficulty?  Which link in the
chain of reasoning do you not accept?

> What you say: cc-mode + e-p-m + e-l-m => incompatible is certainly true
> *now*.  But it was't until you pushed that change.

Bug #33794 demonstrated the incompatibility.

> There is code in electric-pair-tests.el that shows this.  Spend a
> little less time handwaving and rewind the code back to before you
> pushed the change.  Then present an Emacs -Q recipe showing whatever
> you mean that I'm "in denial" about.

Bug #33794 is the recipe you require.

> *Then* we can discuss sanely.

I think it's worth pointing out that whilst you made a lot of noise on
the thread for #33794, you never characterised the cause of the bug, and
you didn't solve the bug either.

I invite you now to say what, at an abstract level, you think is the
cause of bug #33794.

> > OK, I'll make you a peace offering.  I'll put electric-pair-mode into
> > c-electric-lt-gt in the above contexts, and you will change the test
> > code so that in the C++ version of the < tests, lines start with
> > #include.

> It would pass those, but what if the user wants those for templates too?

My offer was to implement e-p-m for template delimiters, too.

> The goal is that he/she can program that into electric-pair-pairs and
> electric-pair-inhibit-predicate.

_Your_ goal, you mean.  I suggest that typical users just want
electric-pair-mode to work, without all the hassle of having to
configure low level things like electric-pair-pairs and having to write
a complicated lisp function to control it.

> But if you want to set electric-pair-inhibit-predicate yourself in the
> major-mode, that's perfectly OK.

I have no interest in manipulating electric-pair internals.  The test
for the syntactic context of the < and > signs would be done by CC Mode,
in c-electric-lt-gt.

> [ .... ] No idea if cc-mode has facilities to detect syntactic
> context, given C++ parsing is notoriously difficult.

It does indeed have such facilities.

> >> Major modes are "at liberty" to do that, but they break all minor-mode
> >> horizontal to Emacs that rely on this functionality, or have to
> >> reimplement them.
> > Minor modes shouldn't rely on this hook.  It's a mistaken design
> > decision.

> *In your opinion*.  Which, I'm very sorry to break it to you, is now
> irrelevant, because nevertheless it made it into Emacs's C core long
> ago, and people want to use it.

That may be true, but these people are mistaken, and deciding to use
this unreliable hook will come back and bite them.  Just look at the
trouble that e-p/l-m's' decision to use that hook is currently causing
us.

> And they do, and it has worked until now.

> > Despite your histrionics, electric-pair-mode and CC Mode work well
> > together.

> No, they don't Alan.  Pairing inside comments and literals is failing.

A detail, which I can fix.  Brace pairing already works in comments and
strings.

> And there's still the lost pairing behaviour in unterminated string
> literals.  All of these things used to work before you started messing
> with them around June.

I'll need to have a look at that.

> > Certainly the scenario in bug #33794 works well.  You keep slagging it
> > off, but still haven't given a specific defect in a usable form
> > (besides saying that e-p-m doesn't work in literals).

> I gave you 85 defects.  They are all in "usable" form.  Fix them all,
> repeat '(when electric-pair-mode' everywhere.

They are not in usable form.

> >> > You can have that preference, but given the incompatibility, it won't
> >> > get you anywhere. 
> >> I return the challenge.  Have you tried electric-layout-mode before
> >> making these claims?
> > No, I don't need to.

> Really, you don't have like 2 minutes to spare to try out 8 lines of
> elisp?

Not when there's no point, no.

> > I understand the mechanisms which give rise to the
> > incompatibility.  I urge you to try and understand these, too.

> What incompatibility?  Where?  When?  How?

<sigh> The incompatibility at the top of this post, which up till now
you've refused to accept, yet can't refute.

[ .... ]

> >> For the third of fourth time Have you actually *seen* and read the 8
> >> lines of code below that I posted already before?  Have you perhaps
> >> considered spending 5 minutes trying them out?
> > I've seen them, yes, and no I won't be trying them out.  I have no
> > interest in electric-layout-mode, beyond fending off attacks from it on
> > CC Mode.

> You crack me up Alan, you really have a bellic conception of software
> design.  In what ways does it attack CC Mode?  What with bananas and
> pointy sticks?

You are attacking CC Mode.  I identified you with your
electric-layout-mode.  That again is obvious, even to you.

> >> > No, I haven't tried it.  There is no usable interface with
> >> > electric-layout-mode for CC Mode.

> >> I just gave you one, for the second time.

> > No, I mean there's no interface by which CC Mode can trigger the actions
> > of electric-layout-mode.  Except, perhaps, by calling the function on
> > post-self-insert-hook as a function.  But how, in that case, does the

> It doesn't need to, my friend!  That's the beauty of it.  Just call
> self-insert-command like you always did!  And don't worry about it.

Bug #33794.

> > It's not good, but it's the best that's available.  You may recall me
> > requesting you to provide an interface suitable for CC Mode, but you
> > didn't do this.

> You requested that I redesign it around some other thing than
> post-self-insert-hook.  I can't do that.  It was like that when I picked
> it up.

I don't think my specific request was in those terms (I may be wrong),
but that certainly seems to be what's required.  Just because these
functions used post-self-insert-hook when you took them over doesn't
mean you can't change to something better.

[ .... ]

> >> * If c-auto-newline is on is works exactly like you want it;
> >> * Otherwise it works like it did before 
> >> 223e7b87872d4a010ae1c9a6f09a9c15aee46692

> > No.

> See above.

> > It's low quality programming, having the low level details of a function
> > controlled by a flag with no coherent meaning set from outside.  It
> > will, one way or another, break things.

> Low quality programming?  From the man who is ad-hoc reimplementing
> electric-pair-mode?

You can't answer the point, so you descend to ad hominem attack.  I
would have expected something better from you.

[ .... ]

> João

> PS: do whatever you want now.  Revert my commit, if you want.  I'll
> remove the C++ tests.  It's not worth to insist on any of this anymore.
> I have a lot of work coming up myself.  I give up.

I think that's the best solution.  These tests are, after all, for
testing the electric- functions, not CC Mode.

-- 
Alan Mackenzie (Nuremberg, Germany).