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 17:30:21 -0800 (PST) Message-ID: <21bb410f-b6c6-4f70-83ce-41a7d638420a@default> References: <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> <20161216192558.GA3858@acm.fritz.box> <9a6f6794-69c1-6165-871c-f9695905cb81@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 1481938244 24380 195.159.176.226 (17 Dec 2016 01:30:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Dec 2016 01:30:44 +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 Sat Dec 17 02:30: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 1cI3pe-0005EG-Mp for ged-emacs-devel@m.gmane.org; Sat, 17 Dec 2016 02:30:38 +0100 Original-Received: from localhost ([::1]:34993 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cI3ph-0008NK-IY for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 20:30:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cI3pb-0008I1-9i for emacs-devel@gnu.org; Fri, 16 Dec 2016 20:30:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cI3pX-0000CA-8h for emacs-devel@gnu.org; Fri, 16 Dec 2016 20:30:35 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:27869) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cI3pW-0000BZ-VJ for emacs-devel@gnu.org; Fri, 16 Dec 2016 20:30:31 -0500 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uBH1UQMG002576 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 17 Dec 2016 01:30:27 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uBH1UOXo026282 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Dec 2016 01:30:25 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id uBH1UMMZ022344; Sat, 17 Dec 2016 01:30:23 GMT In-Reply-To: <9a6f6794-69c1-6165-871c-f9695905cb81@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: userv0022.oracle.com [156.151.31.74] 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:210565 Archived-At: > > Not a problem for me. And doesn't have to be a problem for > > vanilla Emacs users either, if the proper commands are added. >=20 > You're actually proposing a change to the current narrowing-widening UI > and API. That should indicate that the current one is insufficient, or, > has problems. I didn't propose anything. The point is that it is not a big deal to remember two positions and return the buffer limits to them later. > I'm not in any hurry to adopt it, though, because it doesn't solve any > multi-mode problems. Not by itself, at least. I'm not asking you to adopt it. I'm asking you not to replace narrowing, as changing buffer limits, to something else, based on overlays or whatever. I'm asking you not to reserve narrowing for Lisp and give users some ersatz for it. Users and Lisp are not two different universes. > > In my case: > > 1. `C-x n n' to "focus on reading" a paragraph in the node. > > 2. `C-x n x' to return to the full node (not all of Info). > > End of story. >=20 > What happens if you press `C-x n x' once more? If you have other restrictions in the ring, then it picks up the previous one. And so on, until it gets to the beginning, and then it wraps around to the last one. So if you have only one restriction, as in just #1 then #2, above, then repeating `C-x n x' gets you back to #1: the paragraph. IOW, it's like any other ring in Emacs. > In any case, you've introduced "a different kind of narrowing" yourself. > Your `C-x n n' command does something else than just call narrow-to-regio= n. Oh, yes; a GIANT change (?) ;-) (defadvice narrow-to-region (before zz-add-zone activate) "Push the region limits to the current `zz-izones-var'. You can use `C-x n x' to widen to a previous buffer restriction. This is a destructive operation. The list structure of the variable value can be modified." (when (or (interactive-p) zz-add-zone-anyway-p) (let ((start (ad-get-arg 0)) (end (ad-get-arg 1))) (unless start (setq start (region-beginning))) ; Needed for Emacs 20= . (unless end (setq end (region-end))) (zz-add-zone start end nil nil nil 'MSG)))) Pretty drastic, huh? It adds the restriction to a ring variable.