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 11:07:29 +0000 Message-ID: <20190119110729.GA4644@ACM> References: <20190117164350.GA18314@ACM> <20190118175437.GA4095@ACM> <20190118225303.GB4095@ACM> <87fttppc7o.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1547896615 22026 195.159.176.226 (19 Jan 2019 11:16:55 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 19 Jan 2019 11:16:55 +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 12:16:51 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gkocM-0005dO-DV for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 12:16:50 +0100 Original-Received: from localhost ([127.0.0.1]:54380 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkoeT-0001UQ-BL for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 06:19:01 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkoeK-0001UK-KT for emacs-devel@gnu.org; Sat, 19 Jan 2019 06:18:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gkoeJ-0007dd-2v for emacs-devel@gnu.org; Sat, 19 Jan 2019 06:18:52 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:38303 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gkoeI-0007dJ-O5 for emacs-devel@gnu.org; Sat, 19 Jan 2019 06:18:51 -0500 Original-Received: (qmail 71255 invoked by uid 3782); 19 Jan 2019 11:18:48 -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 12:18:47 +0100 Original-Received: (qmail 4665 invoked by uid 1000); 19 Jan 2019 11:07:29 -0000 Content-Disposition: inline In-Reply-To: <87fttppc7o.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:232485 Archived-At: Hello, Joćo. On Sat, Jan 19, 2019 at 03:18:03 +0000, Joćo Tįvora wrote: > Alan Mackenzie 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).