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 19:15:25 +0000 Message-ID: <87k1j0sble.fsf@gmail.com> References: <20190117164350.GA18314@ACM> <20190118175437.GA4095@ACM> <20190118225303.GB4095@ACM> <87fttppc7o.fsf@gmail.com> <20190119110729.GA4644@ACM> <875zukpxe2.fsf@gmail.com> <20190119174505.GA4749@ACM> NNTP-Posting-Host: ciao.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ciao.gmane.org 1547925340 126341 195.159.176.228 (19 Jan 2019 19:15:40 GMT) X-Complaints-To: usenet@ciao.gmane.org NNTP-Posting-Date: Sat, 19 Jan 2019 19:15:40 +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 20:15:38 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 1gkw5h-000WoU-EG for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 20:15:37 +0100 Original-Received: from localhost ([127.0.0.1]:58990 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkw5q-0006aV-AB for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 14:15:46 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39725) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkw5j-0006Ze-LS for emacs-devel@gnu.org; Sat, 19 Jan 2019 14:15:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gkw5i-0001ql-Es for emacs-devel@gnu.org; Sat, 19 Jan 2019 14:15:39 -0500 Original-Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:42809) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gkw5e-0001bV-IT for emacs-devel@gnu.org; Sat, 19 Jan 2019 14:15:35 -0500 Original-Received: by mail-wr1-x435.google.com with SMTP id q18so18845145wrx.9 for ; Sat, 19 Jan 2019 11:15:31 -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=hJVFaf9tovIQGP06JfEBHd/V++zbnRX3CMPEsK4XSvU=; b=qo7oJjSfCNtsJHrxWD8cfiYnegQwkjY1klB4ElW0e8y4ldzTP7coe/bBVClW0E/cph U4G9qoZQIlsYjUBfPXdLYsmdnFVIl6zfuLIxkOzMfuTNZIhthvqN9pYmk8kqiSfWaazR /Hfu/HFIwBMMlRJ02n1f2jLy9EMmsdE6CXBCfK9HjoJ4WoE4PwnYrhzMDdH0FnXDJGe3 nhJup6Gj7NXKdEhwnG7oH43V640T+mXh6vGYoS6cYN+sWA+YngC5+FgbzH6kW4WVazK6 RAtbHrSojs/3YlLbmICQ5MNKU5zqeQL7DoBDJjWgSvljEcVZeqjzHW87YZW+2pR6eYFd sBGw== 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=hJVFaf9tovIQGP06JfEBHd/V++zbnRX3CMPEsK4XSvU=; b=Q+SQjNuiC/E0PbubmFDhHx5hnpbA41E6UiCj00pMOBUMaeNG6qhTvH/S/4ADE8AIqd oUmrKzc6Of50+P9uBBLk3yoDo2pKwduZB7bR5RUpAFmfnPfsnGWwvjmPJ8/b4uFmdM+n U2nAOBdDMwsgrbGMTUJqCu9mz+kPZEad9V6FjKUY8bGPYpvKMFnUlQlbzTnekJaRYCTs P29Dov5w5ep6AbKBQWiB6rE1MS137PditvVvBGqGMvZ2o3GXGpEf9r9y+qD/AmSBrlqS HHqaxW0F0bqSUwspxg/ND5TWE8vX9TMQhUYIw77ial6JymidZ9M8XkdWju0ZJE9/HHXB xbkQ== X-Gm-Message-State: AJcUukfcPMs9fJM3nQVJbXt9CrcBOhhX0qelKKC8xFcrqHZVNUBcRi+F ILwSCt4qLd026+NMLXci/UCKWjoI X-Google-Smtp-Source: ALg8bN4nXNUa6JHnneoG245nfaU6nRI3ddL2OUW9uaGgi87ivdtapRdmYJkyANDTL44EkOUyNuiG+Q== X-Received: by 2002:a5d:6684:: with SMTP id l4mr23163823wru.154.1547925328958; Sat, 19 Jan 2019 11:15:28 -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 j8sm116846353wmd.0.2019.01.19.11.15.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 19 Jan 2019 11:15:27 -0800 (PST) In-Reply-To: <20190119174505.GA4749@ACM> (Alan Mackenzie's message of "Sat, 19 Jan 2019 17:45:05 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::435 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:232495 Archived-At: Hello Alan Alan Mackenzie writes: > 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. How can I accept a something that you explain, but don't provide evidence of? It's like wanting me to accept I'm swedish. What you say: cc-mode + e-p-m + e-l-m =3D> incompatible is certainly true *now*. But it was't until you pushed that change. There is code in electric-pair-tests.el that shows this. Spend a little less time handwaving and rewind the code back to before you pushed the change. Then present an Emacs -Q recipe showing whatever you mean that I'm "in denial" about. *Then* we can discuss sanely. > 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. It would pass those, but what if the user wants those for templates too? The goal is that he/she can program that into electric-pair-pairs and electric-pair-inhibit-predicate. But if you want to set electric-pair-inhibit-predicate yourself in the major-mode, that's perfectly OK. Just make sure to play along with any the user's settings, i.e. by using something like 'add-function :after-until' where you inhibit when you detect a specific inhibition of pairing). The only place I can think of (right now) where < shouldn't be paired to >, i.e. where pairing should be inhibited, is in syntactic positions where < can be an operator or part of an operator. No idea if cc-mode has facilities to detect syntactic context, given C++ parsing is notoriously difficult. >> 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. *In your opinion*. Which, I'm very sorry to break it to you, is now irrelevant, because nevertheless it made it into Emacs's C core long ago, and people want to use it. And they do, and it has worked until now. > Despite your histrionics, electric-pair-mode and CC Mode work well > together. No, they don't Alan. Pairing inside comments and literals is failing. And there's still the lost pairing behaviour in unterminated string literals. All of these things used to work before you started messing with them around June. > 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). I gave you 85 defects. They are all in "usable" form. Fix them all, repeat '(when electric-pair-mode' everywhere. >> > You can have that preference, but given the incompatibility, it won't >> > get you anywhere.=20 >> I return the challenge. Have you tried electric-layout-mode before >> making these claims? > No, I don't need to. Really, you don't have like 2 minutes to spare to try out 8 lines of elisp? > I understand the mechanisms which give rise to the > incompatibility. I urge you to try and understand these, too. What incompatibility? Where? When? How? I can't understand something that you don't specify. It's like I asked you to understand that your code has too much weltschmerz. Where is the incompatibility with electric-layout-mode (before your nefarious change, that is)? >> 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. You crack me up Alan, you really have a bellic conception of software design. In what ways does it attack CC Mode? What with bananas and pointy sticks? >> > 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 It doesn't need to, my friend! That's the beauty of it. Just call self-insert-command like you always did! And don't worry about it. Make an exception for c-auto-newline if you want, i.e. if c-auto-newline is t, do whatever you want, like nixing post-self-insert-hook just there. Let c-auto-newline, if t, have prevalence over electric-layout-mode, crushing its insolent attacks upon your beloved domain. You won't hear me complain. > 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. You requested that I redesign it around some other thing than post-self-insert-hook. I can't do that. It was like that when I picked it up. >> 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. No it wouldn't. Not it that advice that c-auto-newline into account. >> * If c-auto-newline is on is works exactly like you want it; >> * Otherwise it works like it did before 223e7b87872d4a010ae1c9a6f09a9c15= aee46692 > > No. See above. > 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. Low quality programming? From the man who is ad-hoc reimplementing electric-pair-mode? > 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. Don't be arrogant. Jo=C3=A3o PS: do whatever you want now. Revert my commit, if you want. I'll remove the C++ tests. It's not worth to insist on any of this anymore. I have a lot of work coming up myself. I give up.