From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#21871: Emacs Lisp Mode (at least): spurious parens in column 0 don't get bold red highlighting. Date: Sat, 02 Sep 2017 16:19:02 +0300 Message-ID: <83fuc5z1a1.fsf@gnu.org> References: <20151110163034.GH2626@acm.fritz.box> <20151112185424.38599.qmail@mail.muc.de> <414b75b8-bb45-4640-4742-9f88b9ff5e75@yandex.ru> <20160516102002.GB2317@acm.fritz.box> <37a9ca07-1ffc-b872-4cf0-719f97177e35@yandex.ru> <20160517090242.GA2250@acm.fritz.box> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1504358432 14624 195.159.176.226 (2 Sep 2017 13:20:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Sep 2017 13:20:32 +0000 (UTC) Cc: 21871@debbugs.gnu.org, dgutov@yandex.ru To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 02 15:20:18 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1do8LN-0002qt-Kh for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Sep 2017 15:20:13 +0200 Original-Received: from localhost ([::1]:47439 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1do8LT-0008O2-3O for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Sep 2017 09:20:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34200) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1do8LH-0008H2-2E for bug-gnu-emacs@gnu.org; Sat, 02 Sep 2017 09:20:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1do8LC-000076-4r for bug-gnu-emacs@gnu.org; Sat, 02 Sep 2017 09:20:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33185) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1do8LC-00006v-0V for bug-gnu-emacs@gnu.org; Sat, 02 Sep 2017 09:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1do8LB-0004WG-O7 for bug-gnu-emacs@gnu.org; Sat, 02 Sep 2017 09:20:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Sep 2017 13:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21871 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21871-submit@debbugs.gnu.org id=B21871.150435838217341 (code B ref 21871); Sat, 02 Sep 2017 13:20:01 +0000 Original-Received: (at 21871) by debbugs.gnu.org; 2 Sep 2017 13:19:42 +0000 Original-Received: from localhost ([127.0.0.1]:41866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1do8Kr-0004Vd-Ha for submit@debbugs.gnu.org; Sat, 02 Sep 2017 09:19:41 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43087) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1do8Kq-0004VO-Pf for 21871@debbugs.gnu.org; Sat, 02 Sep 2017 09:19:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1do8Kg-0007td-Kc for 21871@debbugs.gnu.org; Sat, 02 Sep 2017 09:19:35 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1do8KV-0007hN-Vd; Sat, 02 Sep 2017 09:19:20 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2148 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1do8KU-0007sh-8A; Sat, 02 Sep 2017 09:19:19 -0400 In-reply-to: <20160517090242.GA2250@acm.fritz.box> (message from Alan Mackenzie on Tue, 17 May 2016 09:02:42 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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: 208.118.235.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:136481 Archived-At: unblock 24655 by 21871 thanks > Date: Tue, 17 May 2016 09:02:42 +0000 > From: Alan Mackenzie > Cc: 21871@debbugs.gnu.org > > On Mon, May 16, 2016 at 04:18:54PM +0300, Dmitry Gutov wrote: > > On 05/16/2016 01:20 PM, Alan Mackenzie wrote: > > > > Note this convention is still active. > > > The "convention" may be in place, but the underlying reasons for it are > > much weaker these days. > > The convention is still needed, in particular in CC Mode. We tried to > do without it for some time, and got complaints (from Martin Rudalics) > about its speed. > > > Any relevant operation can use syntax-ppss. > > No, it can't. Anything which uses back_comment can't. That includes > scan-lists, backward-list, and so on, which are very widely used, > including in beginning-of-defun. > > Or are you proposing to rewrite vast swathes of Emacs, expunging all > (backward) uses of scan-lists, etc.? > > > >> We don't have to scan back to the beginning of the buffer, we can use > > >> syntax-ppss (and it's more reliable with bug#16247 fixed). > > > > Sorry, this isn't true. The scanning back to BOB is done at the C > > > level, in function back_comment. > > > What I wrote is true: font-lock rules can use syntax-ppss, and often do. > > Up to a point, you may be right. Any time anybody uses > beginning-of-defun, etc., this scanning from BOB may happen. > > Also, syntax-ppss will deliver the wrong value if font-lock-syntax-table > is non-nil and syntax-ppss is also used outside of font-lock. This is > (one of) the problems with syntax-ppss - it ploughs on blindly, > regardless of changes to the syntax table, text-properties, etc. But it > sort of works most of the time. > > > > syntax-ppss isn't suitable for use > > > here (Stefan's view, not merely mine), because syntax-ppss doesn't react > > > to changes in the syntax table, and suchlike. > > > Here where? > > In back_comment. > > [ .... ] > > > > The scanning back to BOB which is slow doesn't just happen in font > > > lock; it can (and does) happen anywhere. > > > Only in certain places, where the programmer didn't think to use the > > cache provided by syntax-ppss. > > This is simply false. See above. > > > > It's just font lock's job to warn the user about this, so > > > that she can correct it by adding in a backslash, for example. > > > And it's the job of the programmer to avoid this problem altogether, > > which is not too hard. > > This is also false. People have been struggling with the problem for > years, if not decades. > > > > Things do get confused, for example see bug #22884, where there was an > > > open paren in column zero in our own C sources. > > > Even if bug#22884 is somewhat related, it's actually irrelevant is the > > current discussion because c-mode uses a non-default > > beginning-of-defun-function. Which means font-lock-compile-keywords > > won't add highlighting to 0-column parens in c-mode anyway. > > Sadly true. It ought to, though. I can't see the connection between a > major mode determining its own BOD, and whether or not it wants parens > in column zero in strings and comments to get warning face. > > > It seems the current code was designed with only Lisp modes in mind. > > Not at all. Read the manual. > > > >> M-x beginning-of-defun does get confused, though. If *that* is problem > > >> what we want to detect, ..... > > > > Not particularly. We want the user to be warned about things > > > potentially going wrong in back_comment, and anything which calls it. > > > I don't see any reason to believe that the original author of this code > > was concerned with back_comment specifically. > > No, with things which call it, including scan-lists, beginning-of-defun, > etc. > > > > No. open-paren-in-column-0-is-defun-start is a variable that the user > > > can change at any time. > > > I don't think it is, or should be, true. The major mode knows better > > whether it can know where a defun starts, or not. > > open-paren-in-... is a customisable option. It is up to the user > whether she wants the speed of o-p-i-c-0-i-d-s set at t, or the accuracy > of it set at nil. > > > E.g. js-mode and elisp-byte-code-mode set it to nil. If the user changes > > that value in one of these modes, nothing good will happen. > > Set it to nil or bind it to nil? This may be a misuse of the variable > by these modes. More than a year later, it doesn't sound like this is bothering anyone else, and Stefan still didn't chime in to tell what he thinks. So I'm removing the Emacs 26.1 blocking status from this bug. Thanks.