From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: forward-comment and syntax-ppss Date: Mon, 19 Dec 2016 08:12:16 -0500 Message-ID: References: <83fd1db0-7362-6117-c5cd-715398c0dea4@gmail.com> <20161207220447.GA4503@acm.fritz.box> <20161208201517.GB3120@acm.fritz.box> <20161209190747.GC2203@acm.fritz.box> <5a70902f-882e-f616-74b2-df6eb81fc70c@yandex.ru> <20161211101715.GA14084@acm.fritz.box> <51c0554f-40d0-37a5-b134-17058343aa3f@yandex.ru> <20161216200630.GB3858@acm.fritz.box> <83r3576lxs.fsf@gnu.org> <838tre7gqt.fsf@gnu.org> <9e3a5f1b-2bd6-4223-bcb0-790be47d52ab@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1482153204 21527 195.159.176.226 (19 Dec 2016 13:13:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Dec 2016 13:13:24 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 19 14:13:17 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cIxkj-0004RC-G2 for ged-emacs-devel@m.gmane.org; Mon, 19 Dec 2016 14:13:17 +0100 Original-Received: from localhost ([::1]:45357 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cIxkn-0004DQ-RX for ged-emacs-devel@m.gmane.org; Mon, 19 Dec 2016 08:13:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cIxjp-0004AX-Qj for emacs-devel@gnu.org; Mon, 19 Dec 2016 08:12:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cIxjm-0001nK-KT for emacs-devel@gnu.org; Mon, 19 Dec 2016 08:12:21 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:32756) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cIxjm-0001n4-DV for emacs-devel@gnu.org; Mon, 19 Dec 2016 08:12:18 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BuEQAu3EVY/+J3oWxdGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUhHiXMAGUVoIIGYYDBAICghFAFAECAQEBAQEBAWIohGkGViMQCw4mEhQYDSSJAq0Ui0QBAQEHAiWLGYQlhgQFj3yKapsahjqQToFBHzd4Ew6FcyCGcYI8AQEB X-IPAS-Result: A0BuEQAu3EVY/+J3oWxdGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUhHiXMAGUVoIIGYYDBAICghFAFAECAQEBAQEBAWIohGkGViMQCw4mEhQYDSSJAq0Ui0QBAQEHAiWLGYQlhgQFj3yKapsahjqQToFBHzd4Ew6FcyCGcYI8AQEB X-IronPort-AV: E=Sophos;i="5.33,749,1477972800"; d="scan'208";a="283149701" Original-Received: from 108-161-119-226.dsl.teksavvy.com (HELO pastel.home) ([108.161.119.226]) by smtp.teksavvy.com with ESMTP; 19 Dec 2016 08:12:16 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 7DC8864FEA; Mon, 19 Dec 2016 08:12:16 -0500 (EST) In-Reply-To: <9e3a5f1b-2bd6-4223-bcb0-790be47d52ab@yandex.ru> (Dmitry Gutov's message of "Mon, 19 Dec 2016 04:31:28 +0200") 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.21 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" Xref: news.gmane.org gmane.emacs.devel:210627 Archived-At: > - Likewise for M-x imenu and any similar facilities. Keep widening to the > commands, or some high level code that is not major > mode-specific. font-lock-default-fontify-region is a counter-example of > sorts, but it works for mmm-mode because of font-lock-dont-widen. But that means any command which somewhere internally uses syntax-ppss would need to widen? So any change which introduces a new call to syntax-ppss would imply revising all callers of this code and all callers of those callers (etc...) to make sure they widen? What if they don't want to widen because they're commands which *should* limit themselves to the narrowed region? That seems to presume that narrowing is only used for multi-mode kind of contexts, which currently is the exception rather than the rule. I think the core of the problem is the use of narrowing for widely different purposes, so indeed we should decide that some of those uses are simply inappropriate and provided something else for those uses. But I think the case "user-level narrow for Q&R" is hard to replace reliably, so I'd rather keep narrowing for *that* purpose, and try to introduce something else for the other uses (e.g. for multi-mode). Stefan