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: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please. Date: Mon, 13 Jun 2016 08:56:37 -0400 Message-ID: References: <20160607220928.GA5155@acm.fritz.box> <7eeaa57a-698d-bde0-d740-efa8968c7583@yandex.ru> <20160607224829.GC5155@acm.fritz.box> <20160611100750.GB2776@acm.fritz.box> <774fce31-fdea-1b85-fa09-07a901b00ab3@yandex.ru> <20160611195016.GE2776@acm.fritz.box> <411210d6-c6ce-fe24-63c2-27c0d6f9a6fb@yandex.ru> <20160612093425.GA3178@acm.fritz.box> <20160613122803.GA3084@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1465822684 9589 80.91.229.3 (13 Jun 2016 12:58:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 13 Jun 2016 12:58:04 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 13 14:58:03 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 1bCRRF-0007L6-CZ for ged-emacs-devel@m.gmane.org; Mon, 13 Jun 2016 14:57:57 +0200 Original-Received: from localhost ([::1]:56320 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCRRE-0002Wz-Hi for ged-emacs-devel@m.gmane.org; Mon, 13 Jun 2016 08:57:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCROz-0001Qb-GF for emacs-devel@gnu.org; Mon, 13 Jun 2016 08:55:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bCROt-0005Kv-LN for emacs-devel@gnu.org; Mon, 13 Jun 2016 08:55:36 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:57297) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bCROt-0005Kn-50 for emacs-devel@gnu.org; Mon, 13 Jun 2016 08:55:31 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1bCROp-0005QP-Pt for emacs-devel@gnu.org; Mon, 13 Jun 2016 14:55:27 +0200 Original-Received: from 45.72.244.67 ([45.72.244.67]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Jun 2016 14:55:27 +0200 Original-Received: from monnier by 45.72.244.67 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 13 Jun 2016 14:55:27 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 29 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 45.72.244.67 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cancel-Lock: sha1:4+Yx2rw6GP671PtUaWT/XbtdYUg= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:204335 Archived-At: > perverse, here. widen and narrow-to-region are enormously useful, and > it is their simplicity, in large part, which makes them so useful. You The problem with them is simple: when a package encounters the buffer narrowed it has no idea why it's been narrowed, and hence can't know whether it can/should widen or not, nor how. Info buffers are the typical example: - Normally they're narrowed to a "node" and most packages should leave the narrowing untouched (including font-lock, and friends) because really for all intents and purposes the buffer is meant to only hold a node (it's just an implementation detail that in reality the buffer holds many nodes and we switch through them via narrowing). - But of course, if the user comes around and wants to narrow to a subpart of a node, she's free to do so (as she should). - Now, when font-lock comes around and the user has narrowed the buffer, font-lock should temporarily widen the buffer back to the whole node (but not the whole buffer). - Similarly, after narrowing to a sub-part, the if the user wants to unnnarrow, she'll find that `widen` doesn't do what she expects. For this use-case, I could imagine fixing it by providing some kind of undo facility for narrowing. -- Stefan