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 20:58:33 +0000 Message-ID: <20190119205833.GB4749@ACM> References: <20190117164350.GA18314@ACM> <20190118175437.GA4095@ACM> <20190118225303.GB4095@ACM> <87fttppc7o.fsf@gmail.com> <20190119110729.GA4644@ACM> <875zukpxe2.fsf@gmail.com> <20190119174505.GA4749@ACM> <87k1j0sble.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 1547932207 257997 195.159.176.228 (19 Jan 2019 21:10:07 GMT) X-Complaints-To: usenet@ciao.gmane.org NNTP-Posting-Date: Sat, 19 Jan 2019 21:10:07 +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 22:10:04 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 1gkxsR-00151j-2f for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 22:10:03 +0100 Original-Received: from localhost ([127.0.0.1]:59884 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkxsZ-0008HW-Kl for ged-emacs-devel@m.gmane.org; Sat, 19 Jan 2019 16:10:11 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33001) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gkxsT-0008FP-6E for emacs-devel@gnu.org; Sat, 19 Jan 2019 16:10:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gkxsR-0004IK-8b for emacs-devel@gnu.org; Sat, 19 Jan 2019 16:10:05 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:43133 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gkxsP-0004Dd-C6 for emacs-devel@gnu.org; Sat, 19 Jan 2019 16:10:03 -0500 Original-Received: (qmail 59583 invoked by uid 3782); 19 Jan 2019 21:09:57 -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 22:09:56 +0100 Original-Received: (qmail 6604 invoked by uid 1000); 19 Jan 2019 20:58:33 -0000 Content-Disposition: inline In-Reply-To: <87k1j0sble.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:232498 Archived-At: Hello, Joćo, On Sat, Jan 19, 2019 at 19:15:25 +0000, Joćo Tįvora wrote: > 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? If I said the sky was blue would you say "where's your evidence?"? It is a fact that c-electric-brace controls, and must control, each change to the buffer which is done. This is self evident from reading the source code. Please read the source code for c-electric-brace and its immediate sub-functions, understand it (it's not hard), and then come back to me with any questions you may have. It is a fact that electric-layout-mode and electric-pair-mode are allowed to run from post-self-insert-hook, that they make buffer changes which are outside the control of c-electric-brace. This is also self evident. To keep control of buffer changes, and thus function correctly, c-electric-brace must thus prevent the uncontrolled changes referred to in the previous paragraph. This is simple logical reasoning from the previous two paragraphs. If these uncontrolled buffer changes are prevented, electric-layout-mode and electric-pair-mode do not work. I think this is obvious enough not to need justification. If these uncontrolled buffer changes are allowed to take place, c-electric-brace doesn't work properly. Evidence for this, if any be needed, is in the scenario in bug #33794. The two previous paragraphs indicate the incompatibility between c-electric-brace, and electric-layout/pair-mode. What part of this argument gives you difficulty? Which link in the chain of reasoning do you not accept? > What you say: cc-mode + e-p-m + e-l-m => incompatible is certainly true > *now*. But it was't until you pushed that change. Bug #33794 demonstrated the incompatibility. > 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. Bug #33794 is the recipe you require. > *Then* we can discuss sanely. I think it's worth pointing out that whilst you made a lot of noise on the thread for #33794, you never characterised the cause of the bug, and you didn't solve the bug either. I invite you now to say what, at an abstract level, you think is the cause of bug #33794. > > 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? My offer was to implement e-p-m for template delimiters, too. > The goal is that he/she can program that into electric-pair-pairs and > electric-pair-inhibit-predicate. _Your_ goal, you mean. I suggest that typical users just want electric-pair-mode to work, without all the hassle of having to configure low level things like electric-pair-pairs and having to write a complicated lisp function to control it. > But if you want to set electric-pair-inhibit-predicate yourself in the > major-mode, that's perfectly OK. I have no interest in manipulating electric-pair internals. The test for the syntactic context of the < and > signs would be done by CC Mode, in c-electric-lt-gt. > [ .... ] No idea if cc-mode has facilities to detect syntactic > context, given C++ parsing is notoriously difficult. It does indeed have such facilities. > >> 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. That may be true, but these people are mistaken, and deciding to use this unreliable hook will come back and bite them. Just look at the trouble that e-p/l-m's' decision to use that hook is currently causing us. > 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. A detail, which I can fix. Brace pairing already works in comments and strings. > 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. I'll need to have a look at that. > > 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. They are not in usable form. > >> > 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. > Really, you don't have like 2 minutes to spare to try out 8 lines of > elisp? Not when there's no point, no. > > I understand the mechanisms which give rise to the > > incompatibility. I urge you to try and understand these, too. > What incompatibility? Where? When? How? The incompatibility at the top of this post, which up till now you've refused to accept, yet can't refute. [ .... ] > >> 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? You are attacking CC Mode. I identified you with your electric-layout-mode. That again is obvious, even to you. > >> > 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. Bug #33794. > > 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. I don't think my specific request was in those terms (I may be wrong), but that certainly seems to be what's required. Just because these functions used post-self-insert-hook when you took them over doesn't mean you can't change to something better. [ .... ] > >> * If c-auto-newline is on is works exactly like you want it; > >> * Otherwise it works like it did before 223e7b87872d4a010ae1c9a6f09a9c15aee46692 > > 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? You can't answer the point, so you descend to ad hominem attack. I would have expected something better from you. [ .... ] > Joćo > 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. I think that's the best solution. These tests are, after all, for testing the electric- functions, not CC Mode. -- Alan Mackenzie (Nuremberg, Germany).