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

[João Távora]

Richard Stallman <address@hidden> writes:

> When you state disagreement with someone, please don't use a harsh
> tone.  We are all working together here.  So let's be kind to each
> other.

Hello Richard,

Richard, I fully understand that.  But I must remind you, at this point,
that it was Alan who used the words "stupid", "histrionic", "in denial",
"silly" and "low quality" to characterize my position.  Earlier I myself
used the term "atrocity" to characterize his, but I later abandoned this
language, because these are not objective ways to characterize someone's
viewpoint.

I will of course accept that insults aren't the only way to be harsh, so
I must now proceed to explain why I behaved so.  Alan repeatedly
misstates a "fact" without providing evidence.  This is very
exasperating.

Because saying that itself requires justification, I must present my it
as abbreviated as I can: Alan says that the Emacs minor modes
'electric-pair-mode' (hereafter abbreviated e-p-m) and
'electric-layout-mode' (abbrev. e-l-m) are incompatible with cc-mode.
This is strictly true _now_, at the current state of the Emacs source
tree, but it was _not_ so before Alan's change 223e7b8787 of pushed in
2019-01-15.

In fact, I presented a short section of code (which I should like to
improve and install in the future), which demonstrates this.  But Alan
refuses to acknowledge it.  (a variation on this snippet is still
installed in the Emacs source tree under test/lisp/electric-tests.el but
it is not activated to the user, while an updated version of the snippet
I sent to Alan is attached after my signature).

I encouraged Alan to roll back the code to before his change and try
that very simple piece of code.  With it, he could either directly point
to a misbehaviour I'm not aware of, thereby partly justfying his claim.
In that purely hypothetical case I could either fix the misbehaviour or
accept that there is indeed a fundamental incompatibility and give up.

But Alan consistently refuses to do, leaving me with no evidence of his
claim.  Instead, Alan points to bug#33794.  In that bug, a user states
the following:

   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33794#1

   > When using cc-mode, turning on electric-pair-mode causes the
   > auto-newline minor mode to stop inserting newlines where expected.
   > [...]

She mentions a true, never disputed, incompatibility in the combination
'cc-mode', 'e-p-m', and 'auto-newline' (the latter also known as
'c-auto-newline'), which is notably not the same combination as cc-mode,
e-p-m, and e-l-m.  If you read through that bug, you will read efforts
from my part to encourage the user to try e-l-m *instead* of
'c-auto-newline', paired with efforts to improve 'e-l-m' so that the
user's wishes can be fulfilled.  Those efforts are reviewed by Stefan
Monnier, installes in Emacs' e-l-m (not touching any of cc-mode) and
after some confusion those efforts succeed and the user eventually
understands she has an alternative in the combination cc-mode, e-p-m and
e-l-m:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=33794#83

  Beatrix>> Things such as c-toggle-auto-newline, for example, almost seem in 
this
  >> case that they might be better delegated to electric-layout-mode,
  >> with cc-mode specifying different electric-layout constraints for
  >> its different formatting styles. It seems this is close to what
  >> João was suggesting?
  > 
  JT> Yes, that is precisely what I am suggesting.  I am happy that this
  JT> point made it across.

At this point, the incompatibility between the original combination
cc-mode, e-p-m, and auto-newline remained, and Alan decided, quite
legitimately, to address it: there is no reason why the original bug
reported shouldn't be fixed.

However, he chose a way of doing so that denies the alternative I had
provided earlier (additionally, it opened many other new bugs in simpler
usage combinations that he is only now addressing).  At first, I thought
it was an oversight.  After complaining of the new bugs, I suggested
further alternatives so that *both* combinations can be available to the
user.

I presented actual, very simple, working code that does this.  Code that
would even very slightly reduce the line-of-count count in C++ mode.
But Alan rejects this: he wants the keep the current status quo that his
combination works but the alternative I presented earlier user doesn't,
effectively shutting the user out of using 'electric-layout-mode' in
CC-mode, something he deems "silly".

There are, of course, technical ways around this blockade, but they are,
at the moment, too technical for users to try.  More importantly, they
didn't need to exist at all if Alan just didn't needlessly block e-l-m.

I would like to think that you, Richard, of all people, are sensitive to
one of the issues here, which is about shutting out users out of
software.

Perhaps you have learned in your life to argue this less harshly, and
more effectively, than I did.

Best,
João

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

(defun electric-layout-brace-for-c-style-du-jour (inserted)
  (when (and (derived-mode-p 'c-mode 'c++-mode)
             (memq inserted '(?{ ?})))
    (save-excursion
      ;; seem to need this extra call before the one we're interested in
      (backward-char) (c-point-syntax) (forward-char)
      (backward-char)
      (c-brace-newlines (c-point-syntax)))))

(electric-pair-mode 1) (electric-layout-mode 1)