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#9917: bug#5042: bug#9917: 24.0.90; Make `goto-line' consistent with the line number from the minibuffer Date: Thu, 24 Sep 2020 10:31:17 -0700 (PDT) Message-ID: <2ba7ee86-bd69-4299-9e40-b8ee79675c99@default> References: <877dspmzo3.fsf@gnus.org> <83zh5l1uqw.fsf@gnu.org> <87wo0osspd.fsf@gnus.org> <87lfh3dtoj.fsf@mail.linkov.net> <878sd1j2rv.fsf@gnus.org> <871ritbs6t.fsf@mail.linkov.net> <87mu1gd422.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14702"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 5042@debbugs.gnu.org, Juri Linkov , 9917@debbugs.gnu.org, monnier@iro.umontreal.ca, dmoncayo@gmail.com, Lars Ingebrigtsen To: Robert Pluim Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 24 19:33:16 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 1kLV7L-0003h7-Oc for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Sep 2020 19:33:15 +0200 Original-Received: from localhost ([::1]:51670 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kLV7K-0003cP-9Q for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 24 Sep 2020 13:33:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51812) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kLV6C-0002mR-Ge for bug-gnu-emacs@gnu.org; Thu, 24 Sep 2020 13:32:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58248) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kLV6A-0008Mj-Oo for bug-gnu-emacs@gnu.org; Thu, 24 Sep 2020 13:32:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kLV6A-0002dI-MJ for bug-gnu-emacs@gnu.org; Thu, 24 Sep 2020 13:32: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, 24 Sep 2020 17:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9917 X-GNU-PR-Package: emacs Original-Received: via spool by 9917-submit@debbugs.gnu.org id=B9917.160096869510048 (code B ref 9917); Thu, 24 Sep 2020 17:32:02 +0000 Original-Received: (at 9917) by debbugs.gnu.org; 24 Sep 2020 17:31:35 +0000 Original-Received: from localhost ([127.0.0.1]:41552 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLV5i-0002bv-Qn for submit@debbugs.gnu.org; Thu, 24 Sep 2020 13:31:35 -0400 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:45784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kLV5f-0002bb-Pt; Thu, 24 Sep 2020 13:31:33 -0400 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 08OHTdSh033199; Thu, 24 Sep 2020 17:31:26 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=Q74jAXA2Bw5fjxJrtSUvCZt9pSvwbHHsb7XRyc6Gxrw=; b=ira3nUWkgcRBQCiSyd0UdCB/BqE7uJMtdbB/tooVH3fcyMFGBfhKeDIrbh2tMCybq4xy 3er5Zde4tseRq/hu9TCW1gjwBGxKnT+ZYTZbzRPpt7wcW+4TYIf4c6jaCMpVJT9UFGkU REof9S1zcKAG56qIOIHXNnKuWn3LNFESlcrXkBXqPXNTIdCRgGZK42nMA1nZ4GoJuLko TiDgkv4y6oZ0cMCTVu9S1t8jlM/wb4qdyLhI+dX6rdLvgHaaDRzHJlm5ohXjoJeHWnqP WGSefrAMEEHf2IasR5SuPKkYntf3H0BVuVjICqrz4HEVg1bAkfmDlm7gxgzh3VNhyu9d GA== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2130.oracle.com with ESMTP id 33qcpu6jg3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 24 Sep 2020 17:31:25 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 08OHQBC1076081; Thu, 24 Sep 2020 17:31:25 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 33r28x9dhp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 24 Sep 2020 17:31:25 +0000 Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 08OHVIxm004980; Thu, 24 Sep 2020 17:31:18 GMT In-Reply-To: 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=9754 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 suspectscore=0 adultscore=0 bulkscore=0 malwarescore=0 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009240129 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9754 signatures=668680 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=999 adultscore=0 bulkscore=0 mlxscore=0 lowpriorityscore=0 priorityscore=1501 phishscore=0 spamscore=0 malwarescore=0 clxscore=1015 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009240129 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:188892 Archived-At: > >> Drew objected to rebinding the keystroke in Info > >> mode, but I think that's probably fine -- nobody is > >> ever going to refer to an absolute line in Info. >=20 > Drew> Why do you think so? >=20 > Drew> The principle is general. Logically, this has > Drew> nothing to do with the mode or context, except if > Drew> the user thinks it does. No such coupling should > Drew> be done automatically (hard-coded). Just give users > Drew> two commands/keys and let them use whichever they > Drew> feel is appropriate in any given mode/context. >=20 > Drew> You're setting a bad precedent by overruling users > Drew> here. `M-g M-g' should do the same thing, wherever. >=20 > If I turn on display-line-numbers-mode in an *info* buffer, or have the > line number displayed in the mode line, those numbers are the narrowed > line numbers. Having M-g M-g go to the absolute line number there > would be very confusing as they don=CA=BCt match the visual information > provided (how many people even know that *info* buffers are narrowed? > They behave like a linked set of buffers). Either Info should be made to NOT use narrowing to simulate what you describe as "a linked set of buffers", or ordinary considerations of narrowing apply. How do you know that an Info buffer is narrowed? Same way as any other buffer: the mode line says "(Info Narrow)". Nothing new here. Someone decided that relative line numbering was appropriate as the default behavior for Info. That's not bad. And yes, if a user is _not aware_ that line numbering is relative, and that the buffer is narrowed, then s?he may mistakenly use `M-g M-g' to go to what s?he thinks is a normal, i.e., absolute line number. Info is between two chairs. It should instead be handled consistently (pick a chair) - either: 1. As an explicitly narrowed buffer, with relative line numbers - and a user would then use the (new) command and key for going to a relative line number. A user would get that the buffer is narrowed, and relative line numbers are appropriate. or 2. As an widened buffer (or with narrowing completely imperceptible by users), with absolute line numbers - and a user would then use good old `goto-line' and its key, `M-g M-g'. Currently, half the indications for users are that Info IS narrowed (by default), which it is, and half of them are that Info is NOT narrowed (which is incorrect). We now have two ways to show line numbers and two keys for going to a line number: relative and absolute. A user is free to show relative but goto absolute, or the opposite, or either of the two same-type combinations - 4 combinations altogether. A user who is used to `M-g M-g' being goto absolute will not expect it to sometimes instead become goto relative behind her back (invisibly). That a user might not know that Info is narrowed is a separate problem, which should maybe be addressed. The fact is that Info IS narrowed (by default). And Emacs tells you so, pretty clearly. If you're aware of that then you're not surprised that Emacs has chosen to show you relative line numbers (by default). But you _will_ be surprised to discover that `M-g M-g' has changed silently. And that there is no longer any key for `goto-line'. What's needed is some better alignment of things. Plus better informing of users of what the state is. As for the goto keys and their commands: they should be kept separate, and both available at all times. I mentioned the possibility of swapping the bindings in the Info setting. I'm not in favor of any such key changes, but certainly it's better to swap (if someone insists that `M-g M-g' needs to become relative), rather than to just give both keys to relative goto. Again, I don't feel strongly about any of this. I do, however, think we're making a mistake by doing what's being done. In particular because it sets a bad precedent. Someone may say that Info is a very special case, and there won't ever be another like it, and we have no plan to change how Info represents nodes (that is, we'll continue to just narrow - it's not a bad approach, even if it's a bit rudimentary), and so therefore it's OK to make this special exception. Will it continue to be regarded as a special case? Or will other modes where someone thinks that the default expectation will be going to relative line numbers also get `M-g M-g' hijacked for relative goto? I unfortunately have to bet on the latter. If we continue to narrow to Info nodes, and if we think that the mode-line indication isn't strong enough, here's a suggestion: My library zones.el has a Boolean option, `zz-narrowing-use-fringe-flag', to highlight the fringe when the buffer is narrowed. It's then pretty obvious when you narrow a buffer. But until a user has done that, and noticed the effect, s?he might not get it when just going to a buffer, like Info, that's already narrowed. Another possibility is to highlight `Narrow' in the mode line, at least for Info.