From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#21871: Emacs Lisp Mode (at least): spurious parens in column 0 don't get bold red highlighting. Date: Tue, 17 May 2016 09:02:42 +0000 Message-ID: <20160517090242.GA2250@acm.fritz.box> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1463475808 20873 80.91.229.3 (17 May 2016 09:03:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 May 2016 09:03:28 +0000 (UTC) Cc: 21871@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue May 17 11:03:17 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b2auI-0003rs-Mf for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 May 2016 11:03:14 +0200 Original-Received: from localhost ([::1]:49381 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2auI-0006a8-2c for geb-bug-gnu-emacs@m.gmane.org; Tue, 17 May 2016 05:03:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2auD-0006WN-RZ for bug-gnu-emacs@gnu.org; Tue, 17 May 2016 05:03:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b2au6-0004rN-Ny for bug-gnu-emacs@gnu.org; Tue, 17 May 2016 05:03:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:42353) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2au6-0004rC-KA for bug-gnu-emacs@gnu.org; Tue, 17 May 2016 05:03:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b2au6-0004jR-8t for bug-gnu-emacs@gnu.org; Tue, 17 May 2016 05:03:02 -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, 17 May 2016 09:03:02 +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.146347576818169 (code B ref 21871); Tue, 17 May 2016 09:03:02 +0000 Original-Received: (at 21871) by debbugs.gnu.org; 17 May 2016 09:02:48 +0000 Original-Received: from localhost ([127.0.0.1]:54690 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2ats-0004iy-2b for submit@debbugs.gnu.org; Tue, 17 May 2016 05:02:48 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:41953) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2atq-0004iq-1p for 21871@debbugs.gnu.org; Tue, 17 May 2016 05:02:46 -0400 Original-Received: (qmail 56925 invoked by uid 3782); 17 May 2016 09:02:44 -0000 Original-Received: from acm.muc.de (p548C7AFA.dip0.t-ipconnect.de [84.140.122.250]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 17 May 2016 11:02:43 +0200 Original-Received: (qmail 5271 invoked by uid 1000); 17 May 2016 09:02:42 -0000 Content-Disposition: inline In-Reply-To: <37a9ca07-1ffc-b872-4cf0-719f97177e35@yandex.ru> User-Agent: Mutt/1.5.24 (2015-08-30) 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: 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:118347 Archived-At: Hello, Dmitry. 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. > > We can't make our font-locking dependent upon > > what its value was at some time in the past. If open-paren-... belongs > > anywhere, it's in the form just beyond the end of your patch's text. > I don't think so. I don't mind taking its comparison out altogether, but > then the predicate will become very simple. Again, do you understand that comparison, and why all the components of that `and' form are there? > > Do you understand the consequences of taking out the check on > > syntax-begin-function? (I certainly don't.) It would be good if Stefan > > could express a view, here. > Point is, there is no way to simply alter the check that it would accept > the current situation with syntax-begin-function, but still keep it > meaningful. If we accept the value nil (which it is emacs-lisp-mode > now), we should accept any syntax-begin-function, I think. -- Alan Mackenzie (Nuremberg, Germany).