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:49 -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> > <<83oa0c8f7r.fsf@gnu.org>> 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 1481905484 7913 195.159.176.226 (16 Dec 2016 16:24:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Dec 2016 16:24:44 +0000 (UTC) Cc: acm@muc.de, emacs-devel@gnu.org, monnier@iro.umontreal.ca, dgutov@yandex.ru To: Eli Zaretskii , Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 16 17:24:40 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 1cHvJF-0001BQ-EH for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 17:24:37 +0100 Original-Received: from localhost ([::1]:33091 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHvJJ-00084F-I8 for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 11:24:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50716) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cHvHf-00076Q-0w for emacs-devel@gnu.org; Fri, 16 Dec 2016 11:23:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cHvHe-00047t-5o for emacs-devel@gnu.org; Fri, 16 Dec 2016 11:22:59 -0500 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:28478) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cHvHa-00040N-9b; Fri, 16 Dec 2016 11:22:54 -0500 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uBGGMqGF016244 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Dec 2016 16:22:52 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id uBGGMpYZ015361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 16 Dec 2016 16:22:52 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id uBGGMp9n028494; Fri, 16 Dec 2016 16:22:51 GMT In-Reply-To: <<83oa0c8f7r.fsf@gnu.org>> 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: 141.146.126.69 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:210528 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. >=20 > Narrowing is used for both of these effects. Both what effects? The only effect of narrowing is to, in effect, change what `point-min' and `point-max' amount to. It just restricts the effective buffer limits; nothing more. When I said it is not used to "hide buffer contents" I meant that it is not used ONLY to hide buffer contents from a user's eyes. The rest of that paragraph makes that clear. It was a response to the claim that narrowing is ONLY for hiding buffer contents. Certainly, hiding text from a user's eyes is one effect, and so one use, of narrowing. But it is not the point of narrowing; its full effect. There are other ways to hide text from a user's eyes, but they do not substitute for what narrowing does. > One clear example of the former is Info mode, where the buffer > is always narrowed to the current node. Nope. That's an example of just what I said: Narrowing does more than just hide text from a user's eyes - and the use of narrowing by Info relies on that "more". A displayed node is a narrowed portion of the buffer, and much about "nodeness" and operations on a node are related to that narrowing. Try widening and then just making the text outside the node invisible, and see how far you get with Info. Could Info have been implemented differently, so as not to use narrowing? Sure. Could it have used text invisibility to get the job done? Maybe, but only if it were taught to not only hide invisible text but to also ignore it for other purposes. Text property `invisible' does not do what narrowing does. You can add it to text, to hide it, but then you need to teach code to ignore it for certain operations. Which operations? To replace narrowing, all operations that work off of the buffer limits.