From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: forward-comment and syntax-ppss Date: Fri, 16 Dec 2016 08:22:47 -0800 (PST) Message-ID: <9c16a23c-252a-40a7-bdcc-479b1113e4cb@default> 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> <54c62db5-08e9-38bd-e6f7-c571039d376a@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1481905387 20150 195.159.176.226 (16 Dec 2016 16:23:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2016 16:23:07 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Dmitry Gutov , Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 16 17:23:03 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 1cHvHh-00045z-28 for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 17:23:01 +0100 Original-Received: from localhost ([::1]:33087 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHvHl-00076b-CC for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 11:23:05 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50681) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHvHc-00075u-Fv for emacs-devel@gnu.org; Fri, 16 Dec 2016 11:22:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHvHZ-00040U-BH for emacs-devel@gnu.org; Fri, 16 Dec 2016 11:22:56 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:31027) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cHvHZ-0003ze-1K for emacs-devel@gnu.org; Fri, 16 Dec 2016 11:22:53 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uBGGMpbC019082 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Dec 2016 16:22:51 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id uBGGMogC015275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Dec 2016 16:22:50 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uBGGMnBv011032; Fri, 16 Dec 2016 16:22:49 GMT In-Reply-To: <54c62db5-08e9-38bd-e6f7-c571039d376a@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] [fuzzy] X-Received-From: 156.151.31.81 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:210526 Archived-At: > > That's not the point of narrowing, even if it is one effect. > > It's used to make some buffer contents inaccessible to certain > > (many, typical, ordinary) operations. It is not just you who > > does not see parts of the buffer; it is also Emacs features > > that do not perceive them. >=20 > Why should some facilities ignore narrowing, then? E.g. > font-lock and indentation, which have traditionally done so. I said "certain...operations". You said "some facilities". I did not say that _every_ operation/facility needs or takes advantage of such text inaccessibility. Those that instead want to ignore narrowing do so. No problem. That narrowing restricts the buffer limits is its effect. Code can use that effect to any purpose it wants. If some code deals with a narrowed buffer and it doesn't really want to - if it instead really wants to pretend it is not restricted, it's free to do that. Not hard to do. I think you're referring to contexts where some code narrows the buffer (presumably for a good reason), and some other code has to deal with that narrowed buffer even though it does not want to. That's a question of designing the two bits of code. The latter bit is working with what the former bit dishes out. It has choices for how to deal with it, one of which is to `save-restriction', then `widen' and do its ignore-the-restriction thing. See my reply to Cl=C3=A9ment for the case of reusing code that is broken because it does not expect `point-min' to refer to a buffer-restriction limit. > > No one has given an example of how narrowing makes > > things hard "for many other facilities" - or even > > for one facility. >=20 > You haven't been paying attention. Prove it. See above. I don't see a problem with narrowing. I do see that some code might mistakenly think that the current buffer limits are the full buffer limits, i.e., that it might mistakenly use `point-min' when it should use 1. That's not the fault of narrowing or a problem introduced by narrowing. It's a misunderstanding of what `point-min' is about. There is also the problem of someone mistakenly reusing code that _rightfully_ uses `point-min' (because it wants the restriction limit, not 1). That's not the fault of the reused code or of narrowing. That's the fault of the reuser. Some code is wrong. People make mistakes when coding, and not thinking that a buffer might be narrowed is one possible mistake. And not realizing that some code one reuses intentionally acts differently when the buffer is narrowed is another possible mistake. Buffer restriction is the _general_ case. An unrestricted buffer is a special "restriction" case, even if it is the more usual case. Maybe we need to beef up the doc of `point-min', to emphasize that it is the lower _buffer-restriction_ limit. And maybe some users need to better document their functions, to make it clear when they respect a narrowed buffer (as the Isearch doc makes clear, for instance).