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 18:26:25 -0800 (PST) Message-ID: <2d451986-c125-477b-b10b-bd3fd32af7ea@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> <21bb410f-b6c6-4f70-83ce-41a7d638420a@default> 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 1481941643 31953 195.159.176.226 (17 Dec 2016 02:27:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Dec 2016 02:27:23 +0000 (UTC) Cc: Alan Mackenzie , emacs-devel@gnu.org, Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 17 03:27:17 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 1cI4iP-0006cw-C5 for ged-emacs-devel@m.gmane.org; Sat, 17 Dec 2016 03:27:13 +0100 Original-Received: from localhost ([::1]:35095 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cI4iT-0007si-Ln for ged-emacs-devel@m.gmane.org; Fri, 16 Dec 2016 21:27:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cI4hp-0007jL-87 for emacs-devel@gnu.org; Fri, 16 Dec 2016 21:26:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cI4hm-0006DW-3w for emacs-devel@gnu.org; Fri, 16 Dec 2016 21:26:37 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:38298) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cI4hl-0006Ck-Qw for emacs-devel@gnu.org; Fri, 16 Dec 2016 21:26:34 -0500 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id uBH2QTnk003570 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 17 Dec 2016 02:26:30 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id uBH2QTTF020255 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 17 Dec 2016 02:26:29 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id uBH2QQ16016462; Sat, 17 Dec 2016 02:26:27 GMT In-Reply-To: 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: aserv0022.oracle.com [141.146.126.234] 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:210567 Archived-At: > > Oh, yes; a GIANT change (?) ;-) > > Pretty drastic, huh? It adds the restriction to a ring variable. >=20 > The point is that now any piece of code which uses `widen` will have > to decide whether to widen like the original `widen` or like your > advised C-x n w No. `C-x n w' is not advised. Nor is `widen' advised. Nor redefined in any way. But again, I am not asking that you adopt my code or my approach. The point is that users are not bereft of ways to return to a previous restriction. I answered the "problem" posed by Eli for narrowing in Info. I'm not even asking that you provide or enhance commands in some other way, in order to, as I showed, make it easier for users to return to a previous restriction. I'm asking only that narrowing continue to be usable by both users and Lisp code, in the same way, as a change in buffer limits, rather than, say, a fiddle with overlays.