From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= 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 03:18:03 +0000 Message-ID: <87fttppc7o.fsf@gmail.com> References: <20190117164350.GA18314@ACM> <20190118175437.GA4095@ACM> <20190118225303.GB4095@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1547867810 1032 195.159.176.226 (19 Jan 2019 03:16:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 19 Jan 2019 03:16:50 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 19 04:16:46 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 1gkh7k-000092-8j for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 04:16:44 +0100 Original-Received: from localhost ([127.0.0.1]:50599 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkh9r-00081X-CP for ged-emacs-devel@m.gmane.org; Fri, 18 Jan 2019 22:18:55 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:43439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkh9k-0007zl-0g for emacs-devel@gnu.org; Fri, 18 Jan 2019 22:18:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gkh9i-0006M7-92 for emacs-devel@gnu.org; Fri, 18 Jan 2019 22:18:48 -0500 Original-Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:39058) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gkh9h-0006LA-Uc for emacs-devel@gnu.org; Fri, 18 Jan 2019 22:18:46 -0500 Original-Received: by mail-wr1-x433.google.com with SMTP id t27so17333611wra.6 for ; Fri, 18 Jan 2019 19:18:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=qWcxCgwJq8e7wdH2MHhnv7shHBY2b8apSqbLVdDsWdc=; b=DxcIVbpwwkt3fvF4osD3CeBAFs1idUxpP1c4JuwmWmu9FF9eJ4yHkDOx/4SxX79NtN xG2D3UBOsP4R4zYv7HIqbNUCxZL1nEZngaTg6eMxA6zXI1kgSCj575zrn7RfmiHAdZNV SeXHxMxxKHYV9hjMqJkF9qsQWOQVMBRuuM3Q9Zev5dq6chHSxDpP6Z2NWiyTRY/Tjtey gpos2ZCHYoH/JI/W1wzmLiv6VYChUk0V/hriIpbFO7sSYpZ9ZRdLceW5RS94QE33q+rB Jo1PIlqFvSTXfhu22J+lx5SLg1ayY3fbvvViagBDnGTCLMWI4/48Kol108HCdNj2rBdQ ndfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=qWcxCgwJq8e7wdH2MHhnv7shHBY2b8apSqbLVdDsWdc=; b=ePMrc8ii+MKZkX+68IyGRJU+kyjJ3C3rUGe+P0YBH6S3aXPV2l2mnwErgNqXZKmU80 zKPZvqbvr4Gu6yokO0XoY7jNq099aqj85E3IXguvb4fQ8GMjyu8p4vmxLB3zXfmeIWSs 87ZVK/oTn2Hg1aEe8Ono+ugTezkh9CcXSGCV4RnqrS8p7ZX9DaT1w55NJu3Ur6bbfVKU F1s1EjTdTzQc9L605np5rM4h6JGXHbvxtH/2UiQWoVDRftY1yibf/rQ9zc9aSyRpHnAS 8N0CtiSGQ4qKu8velvn82adakXVnEyCVOLJEZ3Ig2XHIrNoES3/X9LrOag/3rn8xQNvs Cp+Q== X-Gm-Message-State: AJcUukfRHznzqUgEBa/pndQT/7bjM7VVMSYam5y3TDXFbl+j2dUc6f2H UBbpRHSajayuOL1aqL9GNkWeGx9d X-Google-Smtp-Source: ALg8bN7DDQ5whFLby4Ymcb4CBqiyCi/ZIvTfRNiwNMuIiQOOgrGE17WoRxM/cKHB72/JY92J5RgBeA== X-Received: by 2002:a5d:6487:: with SMTP id r7mr19423917wru.263.1547867923947; Fri, 18 Jan 2019 19:18:43 -0800 (PST) Original-Received: from lolita.yourcompany.com (188.139.62.94.rev.vodafone.pt. [94.62.139.188]) by smtp.gmail.com with ESMTPSA id v6sm49218628wrd.88.2019.01.18.19.18.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 18 Jan 2019 19:18:42 -0800 (PST) In-Reply-To: <20190118225303.GB4095@ACM> (Alan Mackenzie's message of "Fri, 18 Jan 2019 22:53:03 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::433 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:232468 Archived-At: Hi Alan Alan Mackenzie writes: > I'm answering you with a top post (with no bottom) because our exchange > has become so voluminous. In my understanding, it's because I made specific questions that you decline to answer. > 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. It's not about the file 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! > 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. So I take a firm stance. If I don't speak now, this "temporary" thing will be like the other "temporary workaround" from 6 month ago. > 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. For the last half-decade it has worked consistently with electric-pair-mode. Then you get a bug report about electric-pair-mode and a part of cc-mode and decide to fix. Alright. You do it by nixing electric-pair-mode's much more substantially in other parts. And you do this in the face of evidence that there are alternatives in Emacs. > 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. 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! > 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. I don't ask that cease supporting it! You're completely misrepresenting me. Keep it for those who find no problem with it, for whatever older version of Emacs you want to support, by all means keep it, I mean it no harm. > 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. electric-layout-mode would have been an alternative to getting int main () turned into int main () { =20=20=20=20 } That's all it was about. You decided to fix this by reimplementing electric-pair-mode inside cc-cmds.el. You failed Alan, there are many cases that you missed. And even if you didn't, you are using internal functions of elec-pair.el that may change in the future. > 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). It is _already_ usable by CC Mode: it does not (yet) use the c-style-vars, but that's a detail that some users don't care about. But it will use them soon. There is code in this list and in the Emacs repo that demonstrates this. What can I do to explain this better show the actual code that makes this happen. Try it! > 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! > 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 electric-pair-angle-brackets-everywhere-at-point-2-in-c++-mode is a test defined in =E2=80=98electric-tests.el=E2=80=99. =20=20=20=20 Electricity test in a =E2=80=98c++-mode=E2=80=99 buffer. =20=20=20=20 Start with point at 2 in a 2-char-long buffer like this one: =20=20=20=20 |<>| (buffer start and end are denoted by =E2=80=98|=E2=80=99) =20=20=20=20 Now call this: =20=20=20=20 (lambda nil (electric-pair-mode 1)) =20=20=20=20 =20=20=20=20 Ensure the following bindings: =20=20=20=20 =E2=80=99((electric-pair-pairs (60 . 62))) =20=20=20=20 Now press the key for: > =20=20=20=20 The buffer=E2=80=99s contents should stay: =20=20=20=20 |<>| =20=20=20=20 , and point should be at 3. Your change makes <>> instead. Fix this and all the other ones. Incidentally, most of the test failures are inside strings and comments, so maybe they are easy fixes. > 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 prefer electric-layout-mode since I also use it for other languages. Is this not a valid reason? Can not I _have_ this preference? Am I allowed, not definitely hating it, and not even dreaming of asking you to change it, to *not particularly enjoy* the CC Mode style system? > 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 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. If I ever become interested in inserting newlines for other delimiter types, I can code it myself with and consult the style vars (or you could add functions such as c-brace-newlines that make it even easier for me). For the moment, though, I am not personally interested in that. > 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. 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'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. Then pack the two or three other occasions where you call electric-pair-mode directly into functions so that they can also be overriden. Surely you are not worried about the runtime cost of calling a single function on a keypress. If you agree to this I can show you a patch -- no "sarcastic" variables involved. 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. Goodbye Alan, Jo=C3=A3o ;;; foo.el --- The one and only. Makes electric.el great again, tests and a= ll. -*- lexical-binding: t; -*- ;; Copyright (C) 2019 Joao Tavora ;;; Code: (defvar foo--saved-post-self-insert-hook nil) (defvar foo--saved-electric-pair-mode nil) (defvar foo--recover-self-insert-command nil) (defun foo--save-self-insert-command (oldfun &rest args) (let* ((foo--saved-post-self-insert-hook post-self-insert-hook) (foo--saved-electric-pair-mode electric-pair-mode) (foo--recover-self-insert-command t) (electric-pair-mode nil)) (apply oldfun args))) (advice-add 'c-electric-brace :around #'foo--save-self-insert-command) (advice-add 'c-electric-lt-gt :around #'foo--save-self-insert-command) (advice-add 'c-electric-paren :around #'foo--save-self-insert-command) (advice-add 'self-insert-command :around (lambda (oldfun &rest args) (if foo--recover-self-insert-command (let* ((post-self-insert-hook foo--saved-post-self-insert-hook) (electric-pair-mode foo--saved-electric-pair-mode) (foo--recover-self-insert-command nil)) (apply oldfun args)) (apply oldfun args))) '((name . foo--recover-self-insert-command))) (provide 'foo) ;;; foo.el ends here