From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: [Emacs-diffs] widen-limits c331b66: Implement buffer-widen-limits functionality Date: Thu, 24 Mar 2016 07:31:46 -0700 (PDT) Message-ID: References: <20160322022539.16038.77264@vcs.savannah.gnu.org> <8737riqouj.fsf@gmail.com> <221845e0-b194-433e-bfbc-105272ae5752@default> <87twjyp21k.fsf@gmail.com> <56F242E0.7060004@online.de> <877fgtpfrw.fsf@gmail.com> <56F293E7.2000703@online.de> <87a8lpnusg.fsf@gmail.com> <56F2CEDA.6060004@online.de> <87fuvgn3md.fsf@gmail.com> <87poukha9x.fsf@gmail.com> <6363ed53-2385-4bd2-9c3a-d2f41bfec4ff@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1458829946 28354 80.91.229.3 (24 Mar 2016 14:32:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Mar 2016 14:32:26 +0000 (UTC) Cc: Eli Zaretskii , =?iso-8859-1?B?QW5kcmVhcyBS9mhsZXI=?= , emacs-devel@gnu.org To: Dmitry Gutov , Vitalie Spinu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 24 15:32:13 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aj6J3-0001sr-C2 for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2016 15:32:13 +0100 Original-Received: from localhost ([::1]:50713 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj6J2-0004IK-EL for ged-emacs-devel@m.gmane.org; Thu, 24 Mar 2016 10:32:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51618) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj6Ix-0004Hi-6C for emacs-devel@gnu.org; Thu, 24 Mar 2016 10:32:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aj6Ir-0008Tb-CA for emacs-devel@gnu.org; Thu, 24 Mar 2016 10:32:07 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:42286) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aj6Ik-0008Qz-7U; Thu, 24 Mar 2016 10:31:54 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2OEVnmI013441 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 24 Mar 2016 14:31:49 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.13.8) with ESMTP id u2OEVmVW012058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Mar 2016 14:31:48 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 u2OEVmd8000512; Thu, 24 Mar 2016 14:31:48 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.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] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:202175 Archived-At: > > One could argue that the surprise is your fault. ;-) You asked > > to widen to the full buffer, and that's what you got. Presumably, > > if you ask for that then you want the whole buffer (whatever that > > might be), and in this context presumably you know what that whole > > buffer is (an Info file). If not, you shouldn't be using `C-x n w'. >=20 > Just how, then, should a user undo the result of narrow-to-region, which > is a user-level operation? Even if it's one that's disabled by default. Good question. Depends what you mean by "undo" it. Depends what the user wants. In vanilla Emacs, so far, `C-x n w' undoes a buffer restriction, restoring the full buffer. That's clear. But if you mean something other than that as "undo" then you need to specify just what that other is. FWIW, my library `zones.el' has this very question at heart, and it provides some other useful meanings of "undo" for narrowing. I have no problem with vanilla Emacs adding additional ones. What I question is co-opting `widen' to redefine it so that it performs only one particular sort of new kind of "undo" for narrowing. Instead, please consider any forms of "undo" for narrowing, other than widening to the full buffer, to be changes to a different narrowing. As long as the result is a buffer restriction (a narrowing), such a change is still narrowing. FWIW, zones.el provides for multiple narrowings, and "undoing" from one to another. The first title in the doc for this is "Problem: Narrowing is Fine-Grained, But Widening Is Not". So I think I understand the use of having other kinds of undo, besides just `C-x n w'. (https://www.emacswiki.org/emacs/MultipleNarrowings) The Emacs world is a wider place than what you have in mind for one form of widening, whatever that might be. Your form can line up with any number of others - they are all narrowings (buffer restrictions), and I doubt that any one of them should be privileged to be considered "the hard" widening.