From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#21871: Emacs Lisp Mode (at least): spurious parens in column 0 don't get bold red highlighting. Date: Mon, 16 May 2016 16:18:54 +0300 Message-ID: <37a9ca07-1ffc-b872-4cf0-719f97177e35@yandex.ru> References: <20151110163034.GH2626@acm.fritz.box> <20151112185424.38599.qmail@mail.muc.de> <414b75b8-bb45-4640-4742-9f88b9ff5e75@yandex.ru> <20160516102002.GB2317@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1463404836 19130 80.91.229.3 (16 May 2016 13:20:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 May 2016 13:20:36 +0000 (UTC) Cc: 21871@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon May 16 15:20:25 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 1b2IRP-0007f4-84 for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 May 2016 15:20:11 +0200 Original-Received: from localhost ([::1]:43833 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2IRO-0005Dc-LE for geb-bug-gnu-emacs@m.gmane.org; Mon, 16 May 2016 09:20:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55554) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2IRL-0005Az-UK for bug-gnu-emacs@gnu.org; Mon, 16 May 2016 09:20:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b2IRG-00037U-KT for bug-gnu-emacs@gnu.org; Mon, 16 May 2016 09:20:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41047) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b2IRG-00037M-G6 for bug-gnu-emacs@gnu.org; Mon, 16 May 2016 09:20:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b2IRG-0004CZ-7b for bug-gnu-emacs@gnu.org; Mon, 16 May 2016 09:20:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 May 2016 13:20: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.146340474416078 (code B ref 21871); Mon, 16 May 2016 13:20:02 +0000 Original-Received: (at 21871) by debbugs.gnu.org; 16 May 2016 13:19:04 +0000 Original-Received: from localhost ([127.0.0.1]:53384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2IQK-0004BG-DQ for submit@debbugs.gnu.org; Mon, 16 May 2016 09:19:04 -0400 Original-Received: from mail-wm0-f43.google.com ([74.125.82.43]:38899) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b2IQI-0004Ak-I7 for 21871@debbugs.gnu.org; Mon, 16 May 2016 09:19:02 -0400 Original-Received: by mail-wm0-f43.google.com with SMTP id g17so135703306wme.1 for <21871@debbugs.gnu.org>; Mon, 16 May 2016 06:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=FFWN9N/blOPaybWjsKhJymDsSaHU5iqYVTDg7YPfTwc=; b=dBAgxXksVDBN9xeMXLV5kIwZ2ZWDSATWvmnWjQsUIFJ/32/6RYYcrROaydptGBBgOA GYq7nn0IhDrGVRvyNpmfvaELOIUMWeC8YbNr+L1pF0RZ8AxY8jf1f+T0EHgu+vVsX+tB Pru0ZAc4S6s9niOhVV/PX7tj2u1BbBWGBDqBtcfS27zJ45iiYxHJpZy0AH+a8Wu2MmJg zlLj7emjsn2jt14A8w+FC6zLPT++sdlqL3b1McIBQ1Wqs9YIp3/0naJNVi4PnLMIORS5 E/WDwqDIoO+wIfyNaBL8uMQfXeIAjuXucVm1yCB/f36JbjXKOJpdyzYq80sFZJsw4Hhj 2swg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=FFWN9N/blOPaybWjsKhJymDsSaHU5iqYVTDg7YPfTwc=; b=QP2TjjQfoi/cmAlSvhfWBYBlsfpRov8t1Ej9NtFvF2hXjxTD0tdryYVga8VwNRGVhL xDt2NPPhZmWWxqNbGcxw6bDNqvyvQeMFZR3jayWT+pdPVld1LU6Z00QpRpWytp6IS/PD xIg1DCvZE61T+vq/gAMHRR8ANWsZubdAK3A6smELsPCo86G8vHsZm7JRyfajB8WYlPi4 R07gSbO3jUvW6g6bdy7VWo+dWOcGCagdnGLmlcoHCchiMabGgyznrP2UDcj2++0Tzlts RLjFBYV70MlXMk+cisJctp4qGLkvHx6FsWIulnQf7HENonzuXlkcc/nwrfqnHlWxk9q9 QRRQ== X-Gm-Message-State: AOPr4FUZ8h9fhFCKXTc7ofaMrgxnUs3XqVwhGaIXMUZrhLjdGJcY2/R6hfpsrM9Qe8gJYA== X-Received: by 10.28.27.17 with SMTP id b17mr17693209wmb.19.1463404736887; Mon, 16 May 2016 06:18:56 -0700 (PDT) Original-Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by smtp.googlemail.com with ESMTPSA id xz3sm16423482wjb.10.2016.05.16.06.18.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 16 May 2016 06:18:56 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1 In-Reply-To: <20160516102002.GB2317@acm.fritz.box> 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:118282 Archived-At: 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. Any relevant operation can use syntax-ppss. >> 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. > 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? >> font-lock doesn't get confused by something looking like a defun inside >> a docstring (try it; I wasn't able to get it highlight something wrong). > > You might be getting confused, here. No, I'm not. I'm addressing a comment inside font-lock-compile-keywords, which is trying to justify highlighting parens in the first column. > 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. > 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. > 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. It seems the current code was designed with only Lisp modes in mind. >> 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. 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. 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. > 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. > 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.