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

[João Távora]

Hello Alan

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?  It's like wanting me to accept I'm swedish.

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.  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.  *Then* we can discuss sanely.

> 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?
The goal is that he/she can program that into electric-pair-pairs and
electric-pair-inhibit-predicate.

But if you want to set electric-pair-inhibit-predicate yourself in the
major-mode, that's perfectly OK.  Just make sure to play along with any
the user's settings, i.e. by using something like 'add-function
:after-until' where you inhibit when you detect a specific inhibition of
pairing).  The only place I can think of (right now) where < shouldn't
be paired to >, i.e. where pairing should be inhibited, is in syntactic
positions where < can be an operator or part of an operator.  No idea if
cc-mode has facilities to detect syntactic context, given C++ parsing is
notoriously difficult.

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

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

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

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

What incompatibility?  Where?  When?  How?  I can't understand something
that you don't specify.  It's like I asked you to understand that your
code has too much weltschmerz.  Where is the incompatibility with
electric-layout-mode (before your nefarious change, that is)?

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

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

Make an exception for c-auto-newline if you want, i.e. if c-auto-newline
is t, do whatever you want, like nixing post-self-insert-hook just
there.  Let c-auto-newline, if t, have prevalence over
electric-layout-mode, crushing its insolent attacks upon your beloved
domain.  You won't hear me complain.

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

>> What's c-electric-thing?  I don't want to break anything for anyone.
>
> You want to break c-electric-brace in preference to fixing
> electric-layout-mode and electric-pair-mode.
>
>> Explain clearly what would be broken for whom.  Explain that exactly, I
>> beg you.
>
> By advising that function you want to introduce, it would unfix the
> working of c-auto-newline and bug #33794.  Breakage.

No it wouldn't.  Not it that advice that c-auto-newline into account.

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

> If they want to do silly things with CC Mode, then they must get to
> grips with the source.  Plenty of people have done this.

Don't be arrogant.

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.