From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#5042: bug#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer Date: Thu, 29 Oct 2020 09:44:18 -0700 (PDT) Message-ID: References: <877dspmzo3.fsf@gnus.org> <83zh5l1uqw.fsf@gnu.org> <87wo0osspd.fsf@gnus.org> <87lfh3dtoj.fsf@mail.linkov.net> <878sd1j2rv.fsf@gnus.org> <878sbps834.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12118"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 5042@debbugs.gnu.org, 9917@debbugs.gnu.org, monnier@iro.umontreal.ca, dmoncayo@gmail.com To: Juri Linkov , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 29 17:45:43 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kYB3X-00031A-F0 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 29 Oct 2020 17:45:43 +0100 Original-Received: from localhost ([::1]:51622 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kYB3W-000528-DL for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 29 Oct 2020 12:45:42 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57656) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kYB2y-0004zq-2l for bug-gnu-emacs@gnu.org; Thu, 29 Oct 2020 12:45:08 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43248) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kYB2s-0007Ve-GJ for bug-gnu-emacs@gnu.org; Thu, 29 Oct 2020 12:45:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kYB2s-0001DR-F9 for bug-gnu-emacs@gnu.org; Thu, 29 Oct 2020 12:45:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Oct 2020 16:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5042 X-GNU-PR-Package: emacs Original-Received: via spool by 5042-submit@debbugs.gnu.org id=B5042.16039898824619 (code B ref 5042); Thu, 29 Oct 2020 16:45:02 +0000 Original-Received: (at 5042) by debbugs.gnu.org; 29 Oct 2020 16:44:42 +0000 Original-Received: from localhost ([127.0.0.1]:54790 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYB2Y-0001CP-2N for submit@debbugs.gnu.org; Thu, 29 Oct 2020 12:44:42 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:37738) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kYB2W-0001CA-DU; Thu, 29 Oct 2020 12:44:41 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09TGcuSU014206; Thu, 29 Oct 2020 16:44:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=pPzWn+T9EqJctoOiEh/p/5jR+G8S8K2jGndrSfETOG0=; b=v2IKAhisco4deEEa4h26HD+O2ek86p6SV30bLpzBPmRfEsdO9nD/mpRG7zB4bWaP+Swp JuYXfdhm9qMvbbJjqonsSw+wrmoAWYYKUeM5bUkKKXOHops9PBAJ2fPJFZ4vGW2rFVEw 00n/BpnNDIbRDmJntFgnOzEFzndkwTknXaNZf7izcAko2602Ahi7hcnhCx0t0lk9FkPM mWn+Ys7IcjcGn8m3x7OtVeB0TMqaUUhhvXf0oBRv0KFaaTdVKCheS+HG0WmNx2uDzDuV RjesBsS4xcqSNIT8XHtFctSwOGuRkmZD1o0eIjzMoAJO3IeLQDtNiyKPg2mB8H/2bclN Hg== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2120.oracle.com with ESMTP id 34dgm4bgta-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 29 Oct 2020 16:44:34 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09TGfTOd017520; Thu, 29 Oct 2020 16:44:34 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 34cx6yp5ck-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 Oct 2020 16:44:34 +0000 Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 09TGiNAP022236; Thu, 29 Oct 2020 16:44:23 GMT In-Reply-To: <878sbps834.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5056.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9788 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 spamscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010290115 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9788 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 impostorscore=0 adultscore=0 bulkscore=0 spamscore=0 phishscore=0 mlxlogscore=999 suspectscore=0 clxscore=1011 mlxscore=0 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010290115 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:191969 Archived-At: > >>> So a new command and keystroke seems warranted. How about... > >>> `M-g M-v'? (The mnemonic is "goto visual line".) > >> > >> Or to add a new key to narrow-map 'C-x n' where a new key could be: > >> > >> C-x n g go to narrowed line > > > > Perhaps both? The keystroke makes sense in both contexts -- as a > > variation on `M-g M-g', and in the group of narrowing keystroke. >=20 > I've added a more localized key binding 'C-x n g', > but still not sure about the global 'M-g' key bindings. > Here are some possible variants: >=20 > 1. Bind 'M-g v' to goto-line-relative, while leaving 'M-g g' > bound to goto-line that currently uses absolute line numbers > (btw, this fact should be mentioned in its docstring); >=20 > 2. Re-bind 'M-g g' to goto-line-relative as many asked to do > with the reasoning that 'M-g g' should use by default the > same numbering scheme as is displayed by display-line-numbers-mode; >=20 > 3. Leave the existing 'M-g g' bound to goto-line, but allow changing > the numbering scheme using a prefix arg and a user option. > Or another idea: maybe it should depend on whether > display-line-numbers-mode is enabled or not? > When display-line-numbers-mode is enabled, then use > relative line numbers that are displayed on the left side (WYSIWYG). FWIW, I think this belongs on `M-g', and not on `C-x n' (and not on both). The aim of the command is to go to a line. IIUC, it's not a command that is essentially an action on the buffer restriction (narrowing). Users will think of this as a goto-line action, and they will look for it on a key related to going to a line number. As others have pointed out, some users won't even recognize that Info shows a node by narrowing the overall buffer (the manual). They won't look for the key on `C-x n' (and they shouldn't). Functions that act on relative, instead of absolute, file names are still basically about file names or files, and their names and keys generally reflect that. Similarly here - this about going to a relative line number. Why a user would most likely want to do that in Info (answer: because it's narrowed) is secondary, and can almost remain unremarked. ___ Which brings us back perhaps to _swapping_ relative and absolute whenever the buffer is narrowed - the Info case is just a special case of that. What about doing that (advertising it prominently)? By default (add an option, to let users choose), when the buffer is narrowed the regular absolute goto-line key goes to a relative line number, and the regular goto-relative line key goes to an absolute line number. That would mentally cement the natural relation between relative line numbering and narrowed buffer. But by _swapping_ (and certainly not letting one of the behaviors grab both keys, as was suggested here), users always have both behaviors available on keys (including in Info). Yes, such swapping would be perhaps a first for Emacs. But I think it would end up being pretty natural, even expected.