From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch Date: Tue, 11 Feb 2014 01:36:36 +0200 Message-ID: <52F96284.50507@yandex.ru> References: <87r47bi1e5.fsf@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1392075409 26031 80.91.229.3 (10 Feb 2014 23:36:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Feb 2014 23:36:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 11 00:36:57 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 1WD0PI-0005oU-P2 for ged-emacs-devel@m.gmane.org; Tue, 11 Feb 2014 00:36:56 +0100 Original-Received: from localhost ([::1]:58715 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WD0PI-0003gc-ED for ged-emacs-devel@m.gmane.org; Mon, 10 Feb 2014 18:36:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WD0PA-0003aN-GP for emacs-devel@gnu.org; Mon, 10 Feb 2014 18:36:53 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WD0P5-0001uq-50 for emacs-devel@gnu.org; Mon, 10 Feb 2014 18:36:48 -0500 Original-Received: from mail-ea0-x234.google.com ([2a00:1450:4013:c01::234]:62771) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WD0P4-0001uh-TJ for emacs-devel@gnu.org; Mon, 10 Feb 2014 18:36:43 -0500 Original-Received: by mail-ea0-f180.google.com with SMTP id o10so3335216eaj.11 for ; Mon, 10 Feb 2014 15:36:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=dWnLCSPKdzCGL3iWKco1TS9xhQC7a/822Gd1R77Dyos=; b=rfmbLUTX0bQsBkjVyAvTWNZsd2VZoRwQdUs/DkRLtAUwIbr9TrYeTrEJnUGQQb9i3B u7LSkOkUqCe+tvLfEAiIEPAD1mDtTdhydnKeB91a6ReZySJ7ubvJp6wbP4YRibIUyDbJ cWjV4AC20YfMXZii9+Dq60L8VrhuLzv7K+KnCevXHl6z+I5lLUiHhPynaf5Ub9KnuTZA teMlhJXPeJ132/2UeqKH9lfMmHySGrniXYlq2QwULq1Om00foBVzDZhsTbV/p4iiWMQH jABHOgsJxgDthVtq/JLW+1xvVy/eQdqCOISYW3wvmIwfHBh5fAn+Q9NJfg43YdqPCg6n 97Tw== X-Received: by 10.14.94.135 with SMTP id n7mr40105495eef.40.1392075401678; Mon, 10 Feb 2014 15:36:41 -0800 (PST) Original-Received: from [192.168.10.2] (62-36-157.netrun.cytanet.com.cy. [62.228.36.157]) by mx.google.com with ESMTPSA id m1sm60093925een.7.2014.02.10.15.36.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Feb 2014 15:36:40 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c01::234 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:169517 Archived-At: On 10.02.2014 18:18, Stefan Monnier wrote: > 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. >> In mmm-mode, we call the default font-lock-fontify-region function with >> bounds of each subregion as arguments, and we also try to limit >> `syntax-ppss' to these regions, so the `syntax-begin-function' brings >> point to the beginning of the current subregion. > > But there's no guarantee syntax-begin-function will be used at > all, so I'm not sure how important changing this test is. > Is it really sufficient to make syntax-ppss understand mmm's sub-modes? Not exactly. But if it worked the way I expected, it would've been easier for me to fix fontification in subregions when it's affected by a character in the primary region above it when it's "string opener/closer" in the submode's syntax table, but punctuation in the primary mode syntax: https://github.com/purcell/mmm-mode/issues/37 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. Since that didn't work, I now seem to be successfully fooling syntax-ppss by let-binding `syntax-ppss-last' to (beg-of-subregion . nil), and fontification is as expected. Maybe that'll even work for indentation, too. But it seems like `mmm-beginning-of-syntax' is entirely useless now (since its result is discarded most of the time, and when not, it could only bring inconsistency). Because it dates back from 2000, about 10 years prior to the aforementioned revision, maybe it should take priority. Or not, since nobody complained in the 3.5 years since.