From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Date: Wed, 3 Jul 2019 10:58:04 +0000 Message-ID: <20190703105804.GA11238@ACM> References: <20190702131632.GA30597@ACM> <20190702160410.GB30597@ACM> <20190702182811.GC30597@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="32981"; mail-complaints-to="usenet@blaine.gmane.org" 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 Wed Jul 03 12:58:54 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 esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hicyT-0008OK-Fr for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2019 12:58:53 +0200 Original-Received: from localhost ([::1]:34846 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hicyS-00076n-3g for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2019 06:58:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58998) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hicxr-00076h-Qd for emacs-devel@gnu.org; Wed, 03 Jul 2019 06:58:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hicxq-0007F4-BY for emacs-devel@gnu.org; Wed, 03 Jul 2019 06:58:15 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:30281 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hicxq-0007BO-1q for emacs-devel@gnu.org; Wed, 03 Jul 2019 06:58:14 -0400 Original-Received: (qmail 7703 invoked by uid 3782); 3 Jul 2019 10:58:05 -0000 Original-Received: from acm.muc.de (p4FE15C0A.dip0.t-ipconnect.de [79.225.92.10]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 03 Jul 2019 12:58:04 +0200 Original-Received: (qmail 11455 invoked by uid 1000); 3 Jul 2019 10:58:04 -0000 Content-Disposition: inline In-Reply-To: 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.23 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:238323 Archived-At: Hello, João. On Wed, Jul 03, 2019 at 10:28:11 +0100, João Távora wrote: > On Tue, Jul 2, 2019 at 7:28 PM Alan Mackenzie wrote: > > I didn't know about the former, and as for the bug, it is a different > > bug with differenct causes from #36423. > If you say so... I stopped cross-posting, you probably should, too. You've hijacked this bug report for your own purposes. That is not a gentlemanly thing to do. Why could you not have started your own thread? Are you going to attend to bug #36474, which was the proper topic of this thread? Or would you like me to? > > > > This isn't true. > > > What "isn't true"? Have those features broken or not? > > They may well be broken. CC Mode hasn't broken them. They made > > invalid assumptions, which turned out to be unjustified. > C-M-u (up-list) made an invalid assumption? No. You made an invalid assumption in trying to use it. > > > They worked before the fe06f643b commit and don't work after the > > > commit. It sounds quite unrefutable to me. > > I don't know what you're talking about. > > I've just tried these in a multiline string in C++ Mode. Both up-list > > and forward-sexp work just fine. I don't know what you're doing. > Start emacs -Q, open a buffer with a double quote followed by some > newlines and then another another double quote. Now put the buffer in > C++ mode and type C-M-u from between the quotes. Ah, I see. You said you'd done this from a multiline string. What you have constructed is not a multiline string, it is two invalid string delimiters unconnected with eachother with extraneous matter between them. > Instead of up-listing to the first quote, you get an error. Now put > point on the starting quote and try C-M-f. Again, error. It works for me. It moves to the end of the initial invalid string. > But only in Emacs 27/cc-mode, probably starting from fe06f64b (that's > a git commit hash). I'm fully aware it's a git commit hash. Funnily enough, I don't memorise such hashes, so if you wish to draw my attention to some commit, please have the decency to give me its date, and the summary line of its commit message, instead of expecting me to do your work to make your point. > Now repeat this experiment. Let me make a little ASCII table: > WORKS DOESN'T > emacs 27/c++mode X > emacs 26.1/c++-mode X > emacs 27/js-mode X > emacs 27/ruby-mode X > emacs 27/(many) X > Do you know what I'm talking about now? Yes, I do. Now try the following. In your C++ buffer, make a comment, and put an open parenthesis inside it. After the comment put a matching close paren. From the opening paren try C-M-f. Guess what? You get an error, just like you do in your case with the broken strings. > Now, you might not care for this consistency, but I personally did. CC Mode has always put a strong emphasis on correctness and accuracy. You're complaining that a dubious trick borne of incorrectness no longer works. I don't think you have a strong position to complain. > I've always had my methods of navigating code with unterminated strings, > with _or without_ electric-pair mode and your cc-mode changes broke > this workflow. I think, perhaps, you encounter such broken strings extremely rarely, and you're making a big song and dance over a relatively minor matter. > > > lsp-mode, etc. These normally call the compiler directly on the > > > source code and highlight those and many other errors. > > Irrelevant. > > > On the other hand, if what you want is the red annotation, are you > > > absolutely sure there isn't a better way to get it? > > No, I'm not. That's why I invited you to come up with a better way, if > > you can. > I gave your one exactly one paragraph ago, which you called dismissed as > "irrelevant". *shrug*. *shrug* as much as you like. You know full well what I meant when I asked you to suggest an alternative. So please stop being so damned evasive and answer the point: can you suggest some other mechanism by which CC Mode can create the required font-locking? If you can, and it's workable, we all win. > > > I'll be "mulling this over". There are potentially many other points > > > of breakage > > "Potentially" many? So far, there is precisely one, in > > electric-pair--unbalanced-strings-p. > What about d37d30cef5bbbdf8d17315835126d76d4681b22a? Is that the same > problem? Maybe, I don't know. Certainly the broken C-M-u and C-M-f, > aren't the same problem. C-M-u and C-M-f aren't broken. You just have unreasonable expectations of them. > > No, you'd be cleaning up your code, to conform with the reality that in > > 2019 major modes use syntax-table text properties. Features from CC > > Mode have a habit of migrating to the Emacs core. > It's not "my" code and I won't be bullied into making changes I don't > agree with. If anybody's the bully around here, it's not me. I found a minor bug in electric-pair-mode, diagnosed it, and reported it. Then I found myself engulfed in your immoderate tirade, trying to bully me into a major restructuring of CC Mode so as to suit your somewhat unreasonable wishes. As far as I can make out, you are the maintainer of electric-pair-mode, and you seem to be refusing to fix a bug, not even a difficult bug. Are you going to fix bug #36474 or not? > Things worked fine until you added a feature in June 2018 that broke > them. You refuse to even let the user disable that feature or > consider alternatives. That's simply not reasonable to me. Like you declining even to look at bug #36474? Correctness in CC Mode is not an optional feature - it goes to the heart of the mode. > > > Also, in the meantime, for a user that is bothered by this bug, > > > I'd recomend to put something like this in his/her .emacs file: > > > (defun c-unescaped-nls-in-string-p (&optional quote-pos) t) > > It's free software, but that's a stupid thing to do. > I'd ask you to actually give an argument instead of an insult, but I've > been on this hamster wheel before, so never mind. It works quite well. Making random changes to the innards of a program tends to break things. Will that do you instead? > -- > João Távora -- Alan Mackenzie (Nuremberg, Germany).