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

[João Távora]

Alan Mackenzie <address@hidden> writes:

> I did not "destroy" any behaviour.  The behaviour you referred to was
> broken, and has been for a long time, ever since its introduction.  It
> can be fixed.

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.

> problem, which had nasty side effects which weren't considered at the
> time.  In particular, it broke CC Mode, even though it took time for that
> to become apparent.

post-self-insert-hook can be used for lots of things, not only
electric-pair-mode and electric-layout-mode.  From requesting
completions from LSP servers[1] to emulating typewriter sounds[2].
Don't break these things, even if they sound useless to you.

[1] 
https://github.com/joaotavora/eglot/commit/444a8c3b3ec29eceeda26b72493a60c44a9bd951
[2] https://stackoverflow.com/questions/11206140/typewriter-sounds-for-emacs

>> No. It was about c-auto-newline's interaction with electric-pair-mode.
>> It would much better that she disable electric-pair-mode completely when
>> working with c-auto-newline.
> So telling users to change their work habits is a solution to bugs?  I
> think not.

Presumably Beatrix just wants to pair braces automatically and insert
newlines.  There are alternatives in Emacs for that.

>> Your change makes <>> instead.
>
> Yes.  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.

Excuse me but this is just wrong.  It's just wrong.  Users and programs
can use whatever code to "determine" these things, including cc-mode's
code.  That code is plugged into electric-pair-inhibit-predicate and
that's it!

>> 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 Right Thing" is that is works the same way in all modes and follows
the customization variables consistently.

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

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

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

>> > I do not attack electric-layout-mode.  I merely note that it would be
>> > less good (if it could work) than CC Mode's own features in the context
>> > of CC Mode.  For example, c-auto-newline handles different braces
>> > differently, depending on their syntactic context.  electric-layout-mode
>> > does not.  electric-layout-mode is not needed in CC Mode.
>> For now I just want braces to generate newlines.
> That's just your personal use case.  For those using the BSD styles, for
> example, they want a newline after a function opening brace, but not
> after a substatement brace.  electric-layout-mode can't do this.

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?

    (setq electric-layout-rules '(electric-layout-for-c-style-du-jour))

    (defun electric-layout-for-c-style-du-jour (inserted)
      (when (and (derived-mode-p 'c-mode 'c++-mode)
                 (memq inserted '(?{ ?})))
        (save-excursion
          (backward-char)
          (c-brace-newlines (c-point-syntax)))))

    (electric-layout-mode 1)

It might need a tweak or two to deal with functions that return
before|after lists, but nothing special.  For braces it is actually
useful already.

> 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.  But the interface *is*
cc-mode.  You get this wrong.  You have a distored notion of
minor-modes.  The point is that you don't do anything deliberately
destroying them, and they work in your mode, and you don't have to worry
about reimplementing their functionality.  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 becoming a salad in there, and it doesn't have to!

> Also that strategy would fragment CC Mode's functionality, making it
> less easy to understand and more difficult to maintain.

Really? Refactoring things into functions so they can be used by other
things is bad?  So why did you come up with c-brace-newlines, may I ask?
I suppose I shouldn't even draw your attention to it because now i fear
you're going to take it apart and obfuscate its behaviour out of spite,
just to make my job harder.

> Why do you have this stubborn desire for electric-l-m in CC Mode?

Because I like minor modes that work consistently across all of Emacs.
I've told you this a million times already.

>> > You say that things you've had working since Emacs 24.4 are now not
>> > working.  Do you mean electric-layout-mode?  If so, that "working" was
>> > an illusion, not reality.  I hope I've said enough to explain why that
>> > minor mode can't work in CC Mode, and that a better alternative exists.
> No answer?

This is ridiculous.  You say it doesn't work.  I show that it works.
You don't try it or verify for yourself.  GOTO ridiculous.

>> Fine, revert it.  Can you give me one good objective reason why adding
>
>> (defun c-self-insert-command (arg)
>>    (let (post-self-insert-hook)
>>       (self-insert-command arg)))
>
>> isn't a better solution, if still temporary?
>
> It doesn't really do much

This is completely true.

> it doesn't help much, it's a matter of taste.

This is completely false.

> It seems your intention is to modify that function in a way which will
> break c-electric-thing.

What's c-electric-thing?  I don't want to break anything for anyone.
Explain clearly what would be broken for whom.  Explain that exactly, I
beg you.

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

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

>> It'll save some lines off your original change and enable me, the
>> tests, and other users to just override it with add-function or
>> advice-add or something.
> I will not encourage users to break CC Mode.  If that is what some users
> really want to do, they have access to the source code.

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

João