From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark Lillibridge Newsgroups: gmane.emacs.devel Subject: Re: Emacs's handling of line numbers [from bug#5042] Date: Sun, 06 Jun 2010 11:18:22 -0700 Message-ID: References: <837ho6czb6.fsf@gnu.org> <8339yucbsg.fsf@gnu.org> <83wrw5bxkc.fsf@gnu.org> <83tyr9bgid.fsf@gnu.org> <83r5mcbqzo.fsf@gnu.org> Reply-To: mark.lillibridge@hp.com NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1275848348 21268 80.91.229.12 (6 Jun 2010 18:19:08 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 6 Jun 2010 18:19:08 +0000 (UTC) Cc: lekktu@gmail.com, eliz@gnu.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 06 20:19:05 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 1OLKR6-0007Ih-RJ for ged-emacs-devel@m.gmane.org; Sun, 06 Jun 2010 20:19:05 +0200 Original-Received: from localhost ([127.0.0.1]:45694 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OLKR6-0005QS-1Z for ged-emacs-devel@m.gmane.org; Sun, 06 Jun 2010 14:19:04 -0400 Original-Received: from [140.186.70.92] (port=50720 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OLKQz-0005Ox-5H for emacs-devel@gnu.org; Sun, 06 Jun 2010 14:18:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OLKQx-0007UK-TD for emacs-devel@gnu.org; Sun, 06 Jun 2010 14:18:57 -0400 Original-Received: from gundega.hpl.hp.com ([192.6.19.190]:52172) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OLKQx-0007Qd-Hq; Sun, 06 Jun 2010 14:18:55 -0400 Original-Received: from mailhub-pa1.hpl.hp.com (mailhub-pa1.hpl.hp.com [15.25.115.25]) by gundega.hpl.hp.com (8.14.3/8.14.3/HPL-PA Relay) with ESMTP id o56IIOxv012664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 6 Jun 2010 11:18:25 -0700 Original-Received: from ts-rhel4.hpl.hp.com (ts-rhel4.hpl.hp.com [15.25.118.24]) by mailhub-pa1.hpl.hp.com (8.14.3/8.14.3/HPL-PA Hub) with ESMTP id o56IIMPG009986; Sun, 6 Jun 2010 11:18:22 -0700 In-reply-to: (message from Mark Lillibridge on Wed, 21 Apr 2010 19:17:30 -0700) X-Scanned-By: MIMEDefang 2.67 on 15.0.48.190 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:125559 Archived-At: In an attempt to make progress on this bug, I propose the following: * all the relevant proposals require {esc}g to move by the line number shown by linum mode if it were on. (they disagree about which numbering scheme(s) linum should use.) * this means we need to redefine the behavior of {esc}g * {esc}g currently calls goto-line, but a grep through the elisp sources of Emacs shows a lots of calls to goto-line, any of which might be broken by changing the behavior of goto-line * Accordingly, I suggest introducing a new function, goto-numbered-line, which will replace the binding of {esc}g and the edit menu option. * the current documentation for goto-line is: (goto-line line &optional buffer) Goto line, counting from line 1 at beginning of buffer. Normally, move point in the current buffer, and leave mark at the previous position. With just C-u as argument, move point in the most recently selected other buffer, and switch to it. When called from Lisp code, the optional argument buffer specifies a buffer to switch to. If there's a number in the buffer at point, it is the default for line. * I propose documentation for goto-numbered-line as: (goto-numbered-line line &optional buffer) Goto line with line number line; use linum mode to see what line numbers each line is assigned. Normally, move point in the current buffer, and leave mark at the previous position. With just C-u as argument, move point in the most recently selected other buffer, and switch to it. When called from Lisp code, the optional argument buffer specifies a buffer to switch to. If there's a number in the buffer at point, it is the default for line. * for the initial implementation, goto-numbered-line would effectively be a copy of goto-line without the widening function. (This is what linum mode currently does.) Later, if we change how linum assigns line numbers, we can change goto-number-line in parallel. What do people think? This resolves the bug ({esc}g and linum numbering lines differently) without forcing us to make a hard decision on exactly how linum should number lines first. - Mark I (Mark Lillibridge) wrote: > Eli Zaretskii wrote: > > Mark Lillibridge wrote: > > > The issue is that font-lock mode, goto-line, linum mode, and perhaps > > > other features need to treat them differently. These features want to > > > widen to the "application" restriction when processing the current > > > buffer, ignoring any temporary restriction. > > > > But if this is the problem you want to solve, you cannot solve it by > > introducing yet another kind of restriction: there's always a chance > > that a command will want to use the "application" restriction, when > > one is already in place, because, e.g., you have font-lock or whatever > > active. And then you are back at the same problem. > > > > IOW, by introducing 2 kinds of restriction, you don't solve the > > problem, you just push it a bit farther. > > > > Moreover, I'm not sure I see the problem that is grave enough to > > justify this. The 3 examples you mentioned can be solved by > > programming the features to do what you want (I believe font-lock > > already solved it, albeit not too elegantly). I understand now the > > difference between two classes of use of restriction (thanks to all > > who labored to explain that to this old fart), but are there > > _practical_ use-cases where the current situation gets in our way so > > badly that such a new feature would be justified? I wonder. > > Personally, the problem I need fixed is that goto-line and linum > mode number lines inconsistently. Given that linum mode already numbers > the first line of a restriction starting with one and Info mode looks weird > if we start numbering at the beginning of the physical buffer, I think > the minimal change would be to change goto-line to number lines so that > the first line of the current restriction is 1. > > Some wanted an option to control whether line numbers were numbered > from the beginning of the restriction or the beginning of the physical > buffer and some (others?) to solve this problem (which characters really > belong to the (logical) buffer) once and for all.