From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juanma Barranquero Newsgroups: gmane.emacs.devel Subject: Re: Emacs's handling of line numbers [from bug#5042] Date: Sun, 18 Apr 2010 05:49:54 +0200 Message-ID: References: <837ho6czb6.fsf@gnu.org> <8339yucbsg.fsf@gnu.org> <83wrw5bxkc.fsf@gnu.org> <83tyr9bgid.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1271562627 30206 80.91.229.12 (18 Apr 2010 03:50:27 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 18 Apr 2010 03:50:27 +0000 (UTC) Cc: monnier@iro.umontreal.ca, mark.lillibridge@hp.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 18 05:50:25 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O3LWb-0000e9-1E for ged-emacs-devel@m.gmane.org; Sun, 18 Apr 2010 05:50:25 +0200 Original-Received: from localhost ([127.0.0.1]:37300 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3LWa-00085c-FZ for ged-emacs-devel@m.gmane.org; Sat, 17 Apr 2010 23:50:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O3LWU-00084C-NS for emacs-devel@gnu.org; Sat, 17 Apr 2010 23:50:18 -0400 Original-Received: from [140.186.70.92] (port=35971 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3LWT-00083T-Hs for emacs-devel@gnu.org; Sat, 17 Apr 2010 23:50:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O3LWS-0002DA-CL for emacs-devel@gnu.org; Sat, 17 Apr 2010 23:50:17 -0400 Original-Received: from mail-bw0-f225.google.com ([209.85.218.225]:33314) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O3LWS-0002D4-7K; Sat, 17 Apr 2010 23:50:16 -0400 Original-Received: by bwz25 with SMTP id 25so3694840bwz.8 for ; Sat, 17 Apr 2010 20:50:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=IzjxE4hCQ0rW/aW2R03GVhjByDfUlWq0JKkKEMngCNI=; b=ZCWwk5EH6SFDBtE4vsQ+bp7JF5lcpgBTc4rNRQEpsOg8aEfqpgKTXVDPDQ6U2uI87v clcuMQaZrke9+3iX6Hre5dysQlaS6MIkE4wBs9x1rI035aRDOcgDE8qJWpDn2WOMHQUH 9jTbIgt1uIr/c/GYbagGtVp3F4gxlKL70O038= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=wtfsD9RVxFFS/gaBoV9eWVo1KSdktIMd9ngiEYwcpAewYEX3aSWGiTLgPzFwxg77xY zt96rk2TQoQ+rryjZUr6lElhcAH14wCj0y8WH/GnI2w3CIvFpIjepxyfbM/qGlD6V7dL X1nCjdHfwj4xzVBFpKSlofdmfKSKU/5bOrUwA= Original-Received: by 10.204.81.29 with HTTP; Sat, 17 Apr 2010 20:49:54 -0700 (PDT) In-Reply-To: <83tyr9bgid.fsf@gnu.org> Original-Received: by 10.204.4.153 with SMTP id 25mr3137016bkr.77.1271562614129; Sat, 17 Apr 2010 20:50:14 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:123828 Archived-At: On Sun, Apr 18, 2010 at 05:12, Eli Zaretskii wrote: > I don't see why. =C2=A0Both use-cases limit commands to a portion of a > buffer. =C2=A0What's the difference between these two classes of narrowin= g, > and how would distinguishing between them be useful? For the same reason that the narrowing stack that Drew proposes could be useful: if I'm reading an Info node, my narrowing/widening shouldn't interfere with the use of narrowing by Info-mode, because that's just an artifact of its implementation. Being able to do M-x widen in an Info node and seeing the whole buffer is IMO a "bug" because it destroys the abstraction. On the same vein, if I were implementing a package that needed to show/hide portions of the buffer, I would likely prefer the user not to be able to break the abstraction just by accidentally doing M-x widen. Juanma