From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 8dafacd: * lisp/emacs-lisp/syntax.el (syntax-ppss-table): New var Date: Tue, 19 Jan 2016 09:30:39 -0500 Message-ID: References: <20160116200607.22534.62936@vcs.savannah.gnu.org> <569B734D.2030202@yandex.ru> <569D4EDE.6080605@yandex.ru> <569D9087.2060803@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1453213860 28896 80.91.229.3 (19 Jan 2016 14:31:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 19 Jan 2016 14:31:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 19 15:30:51 2016 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 1aLXJ4-0006ZS-4q for ged-emacs-devel@m.gmane.org; Tue, 19 Jan 2016 15:30:50 +0100 Original-Received: from localhost ([::1]:37318 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLXJ3-00048a-A1 for ged-emacs-devel@m.gmane.org; Tue, 19 Jan 2016 09:30:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLXIy-00044d-6q for emacs-devel@gnu.org; Tue, 19 Jan 2016 09:30:45 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aLXIu-00024p-9U for emacs-devel@gnu.org; Tue, 19 Jan 2016 09:30:44 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:13096) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aLXIu-00024i-5K for emacs-devel@gnu.org; Tue, 19 Jan 2016 09:30:40 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A2FgA731xV/++PWxdcgxCEAoVVwwsEAgKBPDwRAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBAQcBAQEBHos6hQUHhC0FjDCoVCOBZlWBWyCCeAEBAQ X-IPAS-Result: A0A2FgA731xV/++PWxdcgxCEAoVVwwsEAgKBPDwRAQEBAQEBAYEKQQWDXQEBAwFWIwULCw4mEhQYDSSINwjPIwEBAQcBAQEBHos6hQUHhC0FjDCoVCOBZlWBWyCCeAEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="190274460" Original-Received: from 23-91-143-239.cpe.pppoe.ca (HELO pastel.home) ([23.91.143.239]) by ironport2-out.teksavvy.com with ESMTP; 19 Jan 2016 09:30:39 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 14FA15FF67; Tue, 19 Jan 2016 09:30:39 -0500 (EST) In-Reply-To: <569D9087.2060803@yandex.ru> (Dmitry Gutov's message of "Tue, 19 Jan 2016 04:25:27 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:198356 Archived-At: >>> Doesn't paren-matching code call syntax-ppss anyway? >> Not that I know, no. > electric-pair-syntax-info calls syntax-ppss. Yes, but again that's only to figure out if we're inside a string/comment, so I think it's fine. > Are current-syntax-table and syntax-ppss-table allowed to differ more > than that? In the one current use case, they differ significantly, yes. >>> But up-list uses the return value of syntax-ppss, so it will be affected by >>> syntax-ppss-table? >> syntax-ppss is indeed used, but only to decide if we're strings or >> comments, so it should be OK. > Never for its 9th element? AFAICT no (even though it could, indeed). >>> It doesn't seem easy to reason about. >> Indeed, it's not. > So, I'm wondering if we could postpone introducing a new variable, and > implement the same thing in nxml-mode somehow in a different way. I think syntax-ppss-table is "the right way" in that it is the place where we can define the "low-level, strict, formal syntax". This new variable makes it possible to use with-syntax-table safely with any random syntax table which happens to parse things the way we currently need it. There are indeed potential problems with interactions with other functions, but I expect that the right fix for them would be to be more careful about whether they use the output of syntax-ppss (and hence the proper syntax of the major mode) or if they use something else (e.g. forward-sexp) to get a more dwimish behavior. Stefan