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's handling of line numbers [from bug#5042] Date: Sun, 18 Apr 2010 09:41:32 -0700 Message-ID: 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" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1271608943 19573 80.91.229.12 (18 Apr 2010 16:42:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 18 Apr 2010 16:42:23 +0000 (UTC) Cc: 'Juri Linkov' , 'Eli Zaretskii' , monnier@iro.umontreal.ca, mark.lillibridge@hp.com, emacs-devel@gnu.org To: "'Juanma Barranquero'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 18 18:42:21 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 1O3XZc-0004No-Me for ged-emacs-devel@m.gmane.org; Sun, 18 Apr 2010 18:42:21 +0200 Original-Received: from localhost ([127.0.0.1]:53814 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3XZb-0002St-Vs for ged-emacs-devel@m.gmane.org; Sun, 18 Apr 2010 12:42:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O3XZW-0002SQ-Ti for emacs-devel@gnu.org; Sun, 18 Apr 2010 12:42:14 -0400 Original-Received: from [140.186.70.92] (port=54829 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O3XZU-0002QX-MX for emacs-devel@gnu.org; Sun, 18 Apr 2010 12:42:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O3XZT-0000oG-0G for emacs-devel@gnu.org; Sun, 18 Apr 2010 12:42:12 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:38956) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O3XZS-0000o6-NW; Sun, 18 Apr 2010 12:42:10 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3IGg6Yh018399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 18 Apr 2010 16:42:07 GMT Original-Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o3IGJjbR012249; Sun, 18 Apr 2010 16:42:05 GMT Original-Received: from abhmt013.oracle.com by acsmt353.oracle.com with ESMTP id 169070151271608878; Sun, 18 Apr 2010 09:41:18 -0700 Original-Received: from dradamslap1 (/10.175.221.180) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 18 Apr 2010 09:41:18 -0700 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acre//o/8C4zFjyCR1SGSzmd/bLb8AAE0GcA In-Reply-To: X-Auth-Type: Internal IP X-Source-IP: acsinet15.oracle.com [141.146.126.227] X-CT-RefId: str=0001.0A090203.4BCB365F.0189:SCFMA922111,ss=1,fgs=0 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:123843 Archived-At: Juri> user commands (with the prefix map `C-x n') should not Juri> widen or narrow the Info buffer outside of the current Juri> Info node. Only some low-level functions should be Juri> allowed to do this. > > > > 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, My post replied not to your proposal but to Juri's statement (which you clipped, but I've put back, for context). And Juri did propose removing that possibility. He said that users should not be able to use a command to widen or narrow the buffer outside of the current node. In the bug #5839 thread, Eli argues that users should be able to do that, and I agree. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5839 > > 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. IMO Juri did, by saying that user narrowing and widening commands should not go beyond the current Info node.