From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Apropos 54f297904e0c: Temporarily comment out CC Mode from tests which are incompatible with it. Date: Sat, 19 Jan 2019 17:45:05 +0000 Message-ID: <20190119174505.GA4749@ACM> References: <20190117164350.GA18314@ACM> <20190118175437.GA4095@ACM> <20190118225303.GB4095@ACM> <87fttppc7o.fsf@gmail.com> <20190119110729.GA4644@ACM> <875zukpxe2.fsf@gmail.com> NNTP-Posting-Host: ciao.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ciao.gmane.org 1547920598 110017 195.159.176.228 (19 Jan 2019 17:56:38 GMT) X-Complaints-To: usenet@ciao.gmane.org NNTP-Posting-Date: Sat, 19 Jan 2019 17:56:38 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 19 18:56:36 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1gkurD-000SXn-No for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 18:56:35 +0100 Original-Received: from localhost ([127.0.0.1]:58379 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkurM-0003ud-Qq for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 12:56:44 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55376) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkurF-0003uW-N1 for emacs-devel@gnu.org; Sat, 19 Jan 2019 12:56:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gkurE-0007DC-8Y for emacs-devel@gnu.org; Sat, 19 Jan 2019 12:56:37 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:36981 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gkurD-00077t-UV for emacs-devel@gnu.org; Sat, 19 Jan 2019 12:56:36 -0500 Original-Received: (qmail 50402 invoked by uid 3782); 19 Jan 2019 17:56:30 -0000 Original-Received: from acm.muc.de (p4FE1551A.dip0.t-ipconnect.de [79.225.85.26]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 19 Jan 2019 18:56:29 +0100 Original-Received: (qmail 5320 invoked by uid 1000); 19 Jan 2019 17:45:05 -0000 Content-Disposition: inline In-Reply-To: <875zukpxe2.fsf@gmail.com> X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:232491 Archived-At: Hello, Joća. On Sat, Jan 19, 2019 at 13:52:53 +0000, Joćo Tįvora wrote: > Alan Mackenzie 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).