From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs's handling of line numbers [from bug#5042] Date: Sun, 18 Apr 2010 16:14:15 +0200 Organization: Organization?!? Message-ID: <8739yshmq0.fsf@lola.goethe.zz> References: <8339yucbsg.fsf@gnu.org> <83wrw5bxkc.fsf@gnu.org> <83tyr9bgid.fsf@gnu.org> <87aat1b2sr.fsf@mail.jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1271600086 23705 80.91.229.12 (18 Apr 2010 14:14:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 18 Apr 2010 14:14:46 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 18 16:14:44 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 1O3VGm-0003rQ-KH for ged-emacs-devel@m.gmane.org; Sun, 18 Apr 2010 16:14:44 +0200 Original-Received: from localhost ([127.0.0.1]:38492 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3VGl-0002J7-Tj for ged-emacs-devel@m.gmane.org; Sun, 18 Apr 2010 10:14:43 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O3VGg-0002J1-I5 for emacs-devel@gnu.org; Sun, 18 Apr 2010 10:14:38 -0400 Original-Received: from [140.186.70.92] (port=54685 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3VGf-0002Ir-9C for emacs-devel@gnu.org; Sun, 18 Apr 2010 10:14:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O3VGd-0007yV-GX for emacs-devel@gnu.org; Sun, 18 Apr 2010 10:14:37 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:52961) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O3VGd-0007y3-6Q for emacs-devel@gnu.org; Sun, 18 Apr 2010 10:14:35 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1O3VGb-0003nX-PT for emacs-devel@gnu.org; Sun, 18 Apr 2010 16:14:33 +0200 Original-Received: from p5b2c3527.dip.t-dialin.net ([91.44.53.39]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Apr 2010 16:14:33 +0200 Original-Received: from dak by p5b2c3527.dip.t-dialin.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Apr 2010 16:14:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ connect(): No such file or directory Original-Lines: 27 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: p5b2c3527.dip.t-dialin.net X-Face: 2FEFf>]>q>2iw=B6, xrUubRI>pR&Ml9=ao@P@i)L:\urd*t9M~y1^:+Y]'C0~{mAl`oQuAl \!3KEIp?*w`|bL5qr,H)LFO6Q=qx~iH4DN; i"; /yuIsqbLLCh/!U#X[S~(5eZ41to5f%E@'ELIi$t^ Vc\LWP@J5p^rst0+('>Er0=^1{]M9!p?&:\z]|;&=NP3AhB!B_bi^]Pfkw User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.92 (gnu/linux) Cancel-Lock: sha1:eXVUBFRyvyRGgVndSaIVQKDtNBQ= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:123842 Archived-At: Juanma Barranquero writes: > On Sun, Apr 18, 2010 at 15:44, Drew Adams wrote: > >> That's going too far, IMO. As Eli will perhaps point out (see bug >> #5839), there are reasons that some users will want to widen Info >> buffers. > > What I proposed is not removing that possibility, just making user n/w > and program n/w two different facilities; one is a user commodity, and > the other is (low or medium)-level infrastructure for elisp libraries. > That the two are conflated is the result of library auhors not having > other equally easy way to show selected parts of a buffer, I guess. > >> More generally, we should not remove `widen' as a command, even if in >> only some contexts. Likewise, `narrow'. What we should do is provide >> more user control (not less), possibly by creating a >> `widen-one-level' command as I suggested earlier. > > No one has been proposing less user control. Maybe clone-indirect-buffer should have a way to clone just a partial buffer. In that manner, info nodes and tar subfiles could get a proper "unnarrowed" buffer of their own. -- David Kastrup