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: Thu, 15 Dec 2016 18:06:09 -0800 (PST) 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> 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 1481853989 22896 195.159.176.226 (16 Dec 2016 02:06:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2016 02:06:29 +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 03:06:25 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 1cHhui-00051z-Oe for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 03:06:24 +0100 Original-Received: from localhost ([::1]:57885 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHhun-0000Yg-0l for ged-emacs-devel@m.gmane.org; Thu, 15 Dec 2016 21:06:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44262) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHhuh-0000QM-DA for emacs-devel@gnu.org; Thu, 15 Dec 2016 21:06:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHhuc-0005OR-Er for emacs-devel@gnu.org; Thu, 15 Dec 2016 21:06:23 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:48631) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cHhuc-0005Ma-5a for emacs-devel@gnu.org; Thu, 15 Dec 2016 21:06:18 -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 uBG26DZc016013 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Dec 2016 02:06:14 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id uBG26DXt031885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Dec 2016 02:06:13 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uBG26BjE028494; Fri, 16 Dec 2016 02:06:11 GMT In-Reply-To: <51c0554f-40d0-37a5-b134-17058343aa3f@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:210494 Archived-At: > From where I'm standing, the things you use it for (hide > buffer contents) No. Narrowing is not used to "hide buffer contents". 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. > can be implemented in a much better fashion using overlays > with invisibility (in fact, one such implementation exists > already), No. It's not about invisibility. Overlays do not offer anything that comes close to replacing or simulating the effect of narrowing. > which don't introduce the difficulties of changing point-min and > point-max.=20 What difficulties? What's hard about changing those? That's the essential design of narrowing - the entire point of it: change `point-min' and `point-max'. If you're not doing that then you are not in any way giving users (and code) any kind of a replacement for narrowing. And if you are doing that then, well, you're narrowing the buffer. At the base, narrowing is nothing more than binding the meanings/behavior of `point-min' and `point-max'. > Thus, without making things harder for many other facilities. No one has given an example of how narrowing makes things hard "for many other facilities" - or even for one facility.