unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: "João Távora" <joaotavora@gmail.com>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: Apropos 54f297904e0c: Temporarily comment out CC Mode from tests which are incompatible with it.
Date: Fri, 18 Jan 2019 22:53:03 +0000	[thread overview]
Message-ID: <20190118225303.GB4095@ACM> (raw)
In-Reply-To: <jjbfttpzqon.fsf@gmail.com>

Hello, João.

I'm answering you with a top post (with no bottom) because our exchange
has become so voluminous.

Firstly I insist that you respect my maintainership of CC Mode; that I
understand it better than you, I know its history, its tradeoffs, its
problems.  And that things like your patch of yesterday, which was
grossly disrespectful, will not be repeated.

In my turn, I will not mess with the electric-... functions.  If you
prefer, I will also not mess with electric-tests.el.  I did not realise
you felt proprietorial over it.

And I request you to tone down your aggressiveness.  The aggressiveness
is entirely on the side of electric-....  I merely want CC Mode to
continue working as it has done for several decades.  You are
continually attacking it.  CC Mode and I are under constant siege, but
just want to be left in peace.  Yet I get from you continually "change
CC Mode this way, introduce c-self-insert-command, change CC Mode the
other way", on and on and on, ceaselessly.  All for your convenience.

c-electric-brace and friends depend for their proper working on knowing
or controlling every character that is inserted into or deleted from the
buffer.  When random functionality (from the point of view of
c-electric-brace) is added to self-insert-command, these functions
cannot work.  That is why it is essential to bind post-self-insert-hook
to nil in c-electric-brace.  It is why c-electric-brace is incompatible
with the (ab)use of post-self-insert-hook by certain electric-...
functions.

I insist you respect the need for the correct functioning of
c-electric-brace and friends.  And that you cease false insinuations
such as c-auto-newline being merely a "corner case" - it is an integral
part of CC Mode's functionality, and it will remain supported, and it
will remain.

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

You want electric-layout etc., to be the same for every major mode?
Then please create interfaces to them which are usable by every mode,
including CC Mode (see above).

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.  You suggest that I should put in the hard work of extracting
recipes from your tests myself.  Sorry, that's a lot of work and I've
got other things to do.  The successful uses of electric-pair-mode I
reported earlier were on the Emacs after my patch but without your
patch.  As far as I'm concerned, electric-pair-mode works just fine in
CC Mode, until I see a coherent recipe that breaks it.  Then I will fix
it.

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.

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

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.

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.

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2019-01-18 22:53 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-17 14:57 Apropos 54f297904e0c: Temporarily comment out CC Mode from tests which are incompatible with it João Távora
2019-01-17 16:43 ` Alan Mackenzie
2019-01-17 17:57   ` João Távora
2019-01-17 18:55     ` João Távora
2019-01-18 17:54     ` Alan Mackenzie
2019-01-18 19:55       ` João Távora
2019-01-18 22:53         ` Alan Mackenzie [this message]
2019-01-19  3:18           ` João Távora
2019-01-19 11:07             ` Alan Mackenzie
2019-01-19 13:52               ` João Távora
2019-01-19 17:45                 ` Alan Mackenzie
2019-01-19 19:15                   ` João Távora
2019-01-19 20:58                     ` Alan Mackenzie
2019-01-19 23:18                       ` João Távora
2019-01-21 18:04                       ` Stefan Monnier
2019-01-21 20:45                         ` Alan Mackenzie
2019-01-21 21:46                           ` Stefan Monnier
2019-01-21 22:41                             ` João Távora
2019-01-19 22:37                     ` Drew Adams
2019-01-20 19:05                 ` Richard Stallman
2019-01-20 21:18                   ` João Távora
2019-01-21 20:59                     ` Richard Stallman
2019-01-21 21:49                       ` João Távora
2019-01-18 21:06       ` Stefan Monnier
2019-01-19  3:25         ` João Távora
2019-01-18 22:47       ` Michael Albinus
2019-01-19 20:18       ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190118225303.GB4095@ACM \
    --to=acm@muc.de \
    --cc=emacs-devel@gnu.org \
    --cc=joaotavora@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).