From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?ISO-8859-15?Q?Andreas_R=F6hler?= Newsgroups: gmane.emacs.devel Subject: Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch Date: Thu, 20 Feb 2014 22:28:33 +0100 Message-ID: <53067381.2060904@online.de> References: <87r47bi1e5.fsf@yandex.ru> <52F96284.50507@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1392931487 26104 80.91.229.3 (20 Feb 2014 21:24:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Feb 2014 21:24:47 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 20 22:24:54 2014 Return-path: Envelope-to: ged-emacs-devel@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 1WGb6z-00046J-Qf for ged-emacs-devel@m.gmane.org; Thu, 20 Feb 2014 22:24:54 +0100 Original-Received: from localhost ([::1]:40680 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGb6z-0000M2-0J for ged-emacs-devel@m.gmane.org; Thu, 20 Feb 2014 16:24:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33014) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGb6p-0000BR-VK for emacs-devel@gnu.org; Thu, 20 Feb 2014 16:24:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WGb6c-0008Vv-DY for emacs-devel@gnu.org; Thu, 20 Feb 2014 16:24:43 -0500 Original-Received: from moutng.kundenserver.de ([212.227.17.8]:57537) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WGb6c-0008Vr-3Z for emacs-devel@gnu.org; Thu, 20 Feb 2014 16:24:30 -0500 Original-Received: from purzel.sitgens (brln-4dba194c.pool.mediaWays.net [77.186.25.76]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0McWQK-1WY7zQ0sYi-00Hc6Y; Thu, 20 Feb 2014 22:24:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-Provags-ID: V02:K0:F4kMgc5+nW0na9JRFn5svwltj8usO2rA0Hjnq7sBWOD dV+T7j67GDydu0UxQuLMQseAse4COUFY2C3FbYVxJwgvJfB6E/ 5/zI0jmcAV4fBlgTQwPu+h5bBV63pCRKVc8gr2EsHUfsMXQqC2 X860IRWjAn16UfZWvpQrFJ3LfZt3eSsySK+E9aVum4SvLhLkx5 34j/UO6XKF4IdLaqgQZqbc4zstEiRc4wL4seEMxbFzkt53Oj7q ViSWS2I1IJIaczCpxfgY5TScOPvD5A4NXVyq3wTzu/7QGtpNg0 TFuDpDAQflMrX/QW1+cFLB4N62ILVeWSlAlr+vxhiy1oor68aT Etn2HoFO5O7FV0aq96IM= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.17.8 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169793 Archived-At: Am 12.02.2014 02:30, schrieb Stefan Monnier: >>> IIRC the reason was so that (syntax-ppss) called from a place like >>> a "column-0 just before an open paren" can correctly indicate if this >>> open paren is within a string/comment while at the same time parsing the >>> subsequent text assuming that this open paren was outside of any >>> string/comment. >> Why? That sounds confusing. > > That's the point: it makes it possible to find those sources of > confusion and highlight them. > > E.g. I had some font-lock code which would highlight an > open-paren-in-column-0-in-string/comment with the `warning' face. > So such an "incorrect" open paren would still cause incorrect > highlighting, but the `warning' face on it would provide the clue as to > what was the source of the problem. > >> I would've bound `syntax-ppss-last` and `syntax-ppss-cache` to nil around >> the region and let it be forced to call the syntax-begin-function. > > Right, but that largely defeats the purpose of syntax-ppss (which is to > use caching to speed up (parse-partial-sexp (point-min) (point))). > > [ ... ] Wouldn't it be cleaner to forget about syntax-ppss here and resort to (parse-partial-sexp BEGINNING-of-Subsection point) ? BTW org-babel deals with a lot of modes nicely. Why not port the code from there?