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 03:18:03 +0000, João Távora wrote:
> Alan Mackenzie <address@hidden> writes:

> It's not about the file [electric-tests.el] at all!  I am not
> "proprietorial" over a computer file.  Many people have added tests to
> that file.  It's about the behaviour that you destroyed.  The file is
> guarding that behviour!  That's what automated tests are for!

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.

I'm now going to ask you to consider things at a more abstract level.
electric-thing's abuse of post-self-insert-hook is fundamentally flawed.
It usurps control of the buffer contents from the current major mode.  It
is an inversion of control.  It is the tail wagging the dog.

Instead of continually harrassing me to break CC Mode, why don't you just
fix this flaw in electric-thing?  I suggest gathering pertinent
information in a before-change or after-change function (or both), and
evaluating it in, say, a post-command-hook function.  Or something like
that.  post-self-insert-hook was a cheap and easy "solution" to a
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.

> > And I request you to tone down your aggressiveness.

> Alan, I am being assertive, not aggressive.  If I don't speak now, it's
> much harder down the line to convince you of the wrong path you're
> taking it.

It's you who's "going down a path", not me.  I'm staying where I am,
keeping CC Mode working.  And let me be quite emphatic.  It's going to
stay working in all use cases, not just the ones you use.

[ .... ]

> You could very well have left CC Mode untouched for all I care, and just
> tell Beatrix she could find any other alternative.  This alternative
> exists Alan, I've given you actual evidence, not vapourware!

My way is to fix reported bugs, rather than telling bug reporters to take
a running jump.  Your "evidence" of alternatives is mainly hand waving
and harrassment to break CC Mode.  You refuse to understand the
incompatibility of c-electric-brace etc. with electric-thing's abuse of
post-self-insert-command.

[ .... ]

> > Beatrix Klebe's bug was about c-auto-newline.  It was not about
> > electric-layout-mode.  It is now fixed.

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

[ .... ]

> > I'm not happy with your response to my request for recipes which show
> > how CC Mode supposedly doesn't work with electric-pair-mode.  That
> > around 80 tests fail shows nothing - (at least some of) the tests are
> > broken.

> I suggested that you read the names of the failed tests and then
> type

>   M-x ert-describe-test RET name-of-failed-test RET

> to understand what the behaviour is that used to work and now doesn't.

> I'm sorry If I sound exasperated but I've told you this already 3 times
> in the past to no avail!

Telling eachother things 3 times over is unfortunately a characteristic
of this exchange.  :-(

> > You suggest that I should put in the hard work of extracting
> > recipes from your tests myself.

> No! The tests have generated docstrings! Use M-x ert-describe-test.
> What's the difference between what it types out in the screen and what I
> can write here?

> Here's another failure:

> M-x ert-describe-test RET 
> electric-pair-angle-brackets-everywhere-at-point-2-in-c++-mode

[ Description of use of electric-pair-mode on a > snipped. ]

> Your change makes <>> instead.

Yes.  Automatically pairing a less-than sign with a greater-than sign is
stupid, certainly in CC Mode, and likely in most other programming modes.
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.

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

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

> > 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?  You can have that
preference, but given the incompatibility, it won't get you anywhere.
Fix electric-layout-mode and then you should be able to.

[ .... ]

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

> That's very easy to achieve with electric-layout-mode. For braces you
> can just add a function that calls (c-brace-newlines (c-point-syntax))
> to electric-layout-rules and proceeds accordingly.  I have already
> shown a draft of this function that works pretty well.  Have you tried
> it?  That will read the current style vars and do the right thing.

No, I haven't tried it.  There is no usable interface with
electric-layout-mode for CC Mode.  Also that strategy would fragment CC
Mode's functionality, making it less easy to understand and more
difficult to maintain.  Why do you have this stubborn desire for
electric-l-m in CC Mode?

[ .... ]

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

> > Sometime in the next few days, I'm going to revert your patch to
> > cc-cmds.el. I earnestly request you to modify electric-tests.el to
> > take account of this.

> 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, it doesn't help much, it's a matter of taste.
It seems your intention is to modify that function in a way which will
break c-electric-thing.

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

[ .... ]

> If you don't, and you still insist on this, I honestly give up.  I'll
> have to resort to some crazy ad-hoc solution that does the same, just to
> stay out of the precious cc-cmds.el file. I can advise the
> c-electric-whatever functions to save the variables
> post-self-insert-hook and electric-pair-mode, set electric-pair-mode to
> nil, and then advise self-insert-command to recover them.  This could be
> put in some package in Emacs (see below my sig).  It would be silly: but
> you would make it for a completely needless reasons, the only way.

If you like, yes, but it seems likely to lead to problems in the future.
Why don't you just fix electric-layout-mode and electric-pair-mode?

> Goodbye Alan,
> João

-- 
Alan Mackenzie (Nuremberg, Germany).