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

[Alan Mackenzie]

Hello, Joãa.

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

> That's not for you to decide whether electric-pair-mode, an optional
> minor mode with a well-defined contract, is broken.  Its main goal is to
> work the same is all modes, as any global minor mode.

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.

As always, your "solution" to this is for CC Mode to be broken, rather
than fixing the problems in your own bailiwick.

Our goals are not the same.  Mine is to preserve the integrity of CC
Mode and keep it working, yours is to make electric-*-mode universal.
It might be that your goal is unattainable.  My suggestion is that you
leave CC Mode in peace, and investigate ways you can change e-p/l-m so
that they can become truly universal.  I've already made some
suggestions for this.

[ .... ]

> > Automatically pairing a less-than sign with a greater-than sign is
> > stupid, certainly in CC Mode

> It's not "stupid" if you tweak electric-pair-inhibit-predicate to don't
> do it in certain syntactic context.  But this isn't the point of this
> test!  The point is that modes react to electric-pair-pairs, a
> customization variable.  You broke that for '<' and '>'.  I am unable to
> do use this electric-pair-mode feature, after your "not stupid at all"
> change.

> > It would quickly become intolerably annoying to the user.  The only
> > contexts where it would be sensible are in a template declaration, or in
> > a #include directive.  Only the major mode can determine these things.

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.

[ .... ]

> >> Fix this and all the other ones.  Incidentally, most of the test
> >> failures are inside strings and comments, so maybe they are easy fixes.

> > OK, I'll have a look at strings and comments.  Why does
> > electric-pair-mode operate inside literals?  Is this really the Right
> > Thing?

> It's the default behaviour, but you can customize
> electric-pair-inhibit-predicate and electric-pair-skip-self with M-x
> customize, or advice-add or somesuch if you don't like it personally.

The default in CC Mode has always been that electric actions aren't done
inside strings and comments, and in some other cases.  I'm currently
considering whether electric-pair-mode should be an exception.

> "The Right Thing" is that is works the same way in all modes and follows
> the customization variables consistently.

No, the Right Thing is whatever is best for the user in the current
major mode, taking into account configuration settings.

> >> > The false assumption that these tests make is that they can rely on
> >> > certain settings in post-self-insert-hook.  Any major mode is at liberty
> >> > to bind or set this hook, and as pointed out above, CC Mode _must_ bind
> >> > this to nil in c-electric-brace, etc..  Would you please amend these
> >> > tests to take this into account.

> > This is a critical point, which you have declined to address.  Would you
> > please answer the point in your next post.

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

> They're also "at liberty" to change say buffer-undo-list or
> post-command-hook, or what do I know.  But that doesn't mean it's a
> good idea.  It's not.

buffer-undo-list is frequently bound to t.  Good idea, or not, sometimes
setting or binding these hook variables is the only way to get a result.

> >> > And I ask you, have you tried using c-auto-newline?  It is easy to set
> >> > up (a single line in your c-mode-common-hook, or interactively C-c C-a).
> >> > The CC Mode style system takes care of the rest of the setup most of the
> >> > time.  If not, why not?
> >> I prefer electric-layout-mode since I also use it for other languages.
> >> Is this not a valid reason?  Can not I _have_ this preference?
> > You didn't answer the question.  Have you tried it?

> Yes, of course.  It worked ok as long as you don't use
> electric-pair-mode.  When I turned it on, things broke, so I switched to
> electric-layout-mode.  Which is exactly what happened to Beatrix, but
> she decided to report a bug instead.  And now she and everybody, even
> those who *don't* use c-auto-newline, get a doubly broken
> electric-pair-mode in CC-mode.  Gee thanks for that, what an
> accomplishment!

Despite your histrionics, electric-pair-mode and CC Mode work well
together.  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).

> > 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.  I understand the mechanisms which give rise to the
incompatibility.  I urge you to try and understand these, too.

[ .... ]

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

> > 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
major mode get information back about what this function has done?

[ .... ]

> Don't you think it's silly to be copying implementation details from
> elec-pair.el into your beloved cc mode files just to support it.
> Wouldn't you rather delete code like this?

>     ;; Emulate `electric-pair-mode'.
>     (when (and (boundp 'electric-pair-mode)
>              electric-pair-mode)
>       (let ((size (buffer-size))
>           (c-in-electric-pair-functionality t)
>           post-self-insert-hook)
>       (electric-pair-post-self-insert-function)
>       (setq got-pair-} (and at-eol
>                             (eq (c-last-command-char) ?{)
>                             (eq (char-after) ?}))
>             electric-pair-deletion (< (buffer-size) size))))

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.

[ .... ]

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

> You didn't even give me a change to explain how I would use that
> function, how can you know?  Let me try one last time:

> If you make that function, or some other configurable abstraction, we
> can modify it so that:

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

No.

> Now explain exactly how and for whom this breaks things, in the present
> or in the future.

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.

[ .... ]

> Are you going to make users learn Emacs Lisp understand cc-mode's
> sources?  That's the pinnacle of cruelty.

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.

> João

-- 
Alan Mackenzie (Nuremberg, Germany).