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.bugs,gmane.emacs.devel Subject: bug#36474: Algorithm in electric-pair--unbalanced-strings-p unsuitable for CC Mode Date: Tue, 2 Jul 2019 18:28:11 +0000 Message-ID: <20190702182811.GC30597@ACM> References: <20190702131632.GA30597@ACM> <20190702160410.GB30597@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="8369"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: spacibba@aol.com, emacs-devel , 36474@debbugs.gnu.org To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Jul 02 22:17:35 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1hiPDa-0001C8-N5 for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Jul 2019 22:17:34 +0200 Original-Received: from localhost ([::1]:56940 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiP3n-0004nJ-GQ for geb-bug-gnu-emacs@m.gmane.org; Tue, 02 Jul 2019 16:07:27 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58411) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hiNWa-0000yS-9P for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 14:29:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hiNWY-0005rq-0A for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 14:29:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39101) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hiNWX-0005rD-QO for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 14:29:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hiNWX-0000qw-K2 for bug-gnu-emacs@gnu.org; Tue, 02 Jul 2019 14:29:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 02 Jul 2019 18:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36474 X-GNU-PR-Package: emacs Original-Received: via spool by 36474-submit@debbugs.gnu.org id=B36474.15620921023231 (code B ref 36474); Tue, 02 Jul 2019 18:29:01 +0000 Original-Received: (at 36474) by debbugs.gnu.org; 2 Jul 2019 18:28:22 +0000 Original-Received: from localhost ([127.0.0.1]:47922 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hiNVs-0000q1-0D for submit@debbugs.gnu.org; Tue, 02 Jul 2019 14:28:20 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:52775 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1hiNVq-0000pr-1G for 36474@debbugs.gnu.org; Tue, 02 Jul 2019 14:28:18 -0400 Original-Received: (qmail 66150 invoked by uid 3782); 2 Jul 2019 18:28:11 -0000 Original-Received: from acm.muc.de (p4FE15D94.dip0.t-ipconnect.de [79.225.93.148]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 02 Jul 2019 20:28:11 +0200 Original-Received: (qmail 21605 invoked by uid 1000); 2 Jul 2019 18:28:11 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:161987 gmane.emacs.devel:238304 Archived-At: Hello, João. On Tue, Jul 02, 2019 at 18:22:34 +0100, João Távora wrote: > On Tue, Jul 2, 2019 at 5:04 PM Alan Mackenzie wrote: > > > [did you mean to copy bug-gnu-emacs@gnu.org, or emacs-devel@gnu.org? > > > I'm assuming the latter and correcting] > > No, it's a bug, therefore I submitted a bug report. > You should use the X-Debbugs-CC feature then (and why not continue > in the existing bug 36423?) I didn't know about the former, and as for the bug, it is a different bug with differenct causes from #36423. > Anyway, I insist this matter be brought to emacs-devel because it's a > followup to a discussion that started there but never reached a > suitable conclusion. For that reason, and because I provide a > workaround for the bug at the end of this message, I'm cross-posting > this one mail to both the bug list and emacs-devel. > > > The arguments _against_ NL-terminated strings is that they (1) break > > > longstanding features such as sexp-based navigation (e.g. `up-list` > > > and friends) for modes such say, `js-mode` and (2) break features > > > that expect this to work, most notably electric-pair-mode. > > 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. > 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. > > If those other feature no longer work with an up to date Emacs, they > > should be fixed. > I've stated this repeatedly in the life of this discussion: it's not > just about electric-pair-mode. If you try to M-x up-list from a > multi-line string in emacs 26.1 it works just as well in js-mode and > c++-mode. In emacs master it does not in c++-mode. Same with > forward-sexp on the starting delimiter, etc. 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. > > The fontification that CC Mode does is natural and helpful, and users > > haven't complained about it (except when there've been bugs). > Yes, users haven't complained except when users have complained. > > There have certainly been no complaints about using > > font-lock-warning-face for the invalid string delimiters, and > > font-lock-string-face for valid ones. > That's because providing this annotation is perfectly fine. The problem > is providing it _at the expense of other features_. If other features are broken (and your list of other broken features, so far, is empty), they should be fixed. > And _that's_ what they've complained about: an average user has no > obvious way of telling that the particular implementation of the red > annotation thingy is guilty of breaking his C-M-u or his > electric-pair-mode. That's groundless disparagement. C-M-u works, and electric-pair-mode is broken because it's broken. In one place it's using scan-sexps to move forward over whitespace, totally oblivious to the possibility of syntax-table text properties (which have been in use since Emacs-21). That's broken code. > He/she might even judge the latter more vital than said red thingy > , an annotation which he/she will get by other means if using > very popular packages such as flycheck, or flymake, or eglot, or > 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. > And if you are, are you also absolutely sure you need to put it in the > code and and not provide an easy way to turn it off? It's a core feature of the mode, not an option. > > For this, I think we would both rather that you amend elec-pair.el rather > > than me. > 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. I thought I was doing you a favour by diagnosing the trouble. If I'd known I'd get the reaction from you I've just got, I wouldn't have bothered. > that would need such an indirection, and doing that to serve just a > particular cc-mode quirk doesn't sound priority to me. 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. > In the meantime, let others chime in. > 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 had something more elaborate in my setup but just this > seems to fix it in my testing. > There is a also a very promising variable, c-multiline-string-start-char, > that I think would be a good candidate for customizing this, .... It is not a customisation variable. It is a language definition variable. > .... but I haven't messed with it enough. Just setting it from .emacs > doesn't do the trick. Perhaps in a mode hook? Or, alternatively, actually fix the problems which have been festering for years or decades, and are just now revealing themselves. Thus far, there's exactly one such problem in electric-pair--unbalanced-strings-p. > -- > João Távora -- Alan Mackenzie (Nuremberg, Germany).