From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#21594: 25.0.50; (elisp): node `Variable Definitions' is not reachable by `i variable definition' Date: Fri, 2 Aug 2019 08:21:21 -0700 (PDT) Message-ID: <16b71b1a-ed2e-4fda-8b59-d4cb13e83080@default> References: <<>> <<<87v9vgg0vv.fsf@mouse.gnus.org>>> <<<83k1bwhepu.fsf@gnu.org>>> <<02aef894-7fda-4061-943e-24115490c85e@default>> <<83d0hogj3i.fsf@gnu.org>> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="96007"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 21594@debbugs.gnu.org, larsi@gnus.org To: Eli Zaretskii , Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Aug 02 17:22:11 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1htZNh-000OgX-4n for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Aug 2019 17:22:09 +0200 Original-Received: from localhost ([::1]:35698 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htZNg-0002Zk-7c for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Aug 2019 11:22:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50499) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1htZNb-0002ZW-82 for bug-gnu-emacs@gnu.org; Fri, 02 Aug 2019 11:22:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1htZNa-0007uT-4z for bug-gnu-emacs@gnu.org; Fri, 02 Aug 2019 11:22:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48779) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1htZNa-0007uL-1I for bug-gnu-emacs@gnu.org; Fri, 02 Aug 2019 11:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1htZNZ-0005OZ-So for bug-gnu-emacs@gnu.org; Fri, 02 Aug 2019 11:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Aug 2019 15:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21594 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 21594-submit@debbugs.gnu.org id=B21594.156475929320704 (code B ref 21594); Fri, 02 Aug 2019 15:22:01 +0000 Original-Received: (at 21594) by debbugs.gnu.org; 2 Aug 2019 15:21:33 +0000 Original-Received: from localhost ([127.0.0.1]:57600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1htZN7-0005Nq-74 for submit@debbugs.gnu.org; Fri, 02 Aug 2019 11:21:33 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:53256) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1htZN5-0005Nc-IE for 21594@debbugs.gnu.org; Fri, 02 Aug 2019 11:21:32 -0400 Original-Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x72F99jM158225; Fri, 2 Aug 2019 15:21:24 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-2018-07-02; bh=fT4cOMCTZoaWa+BKdTwd5KdF3YsWx0DvZwRU3t3/Buc=; b=haKHD5S7ExY0yzVMvhMDi7djy6n70EtC7ErQBaKg9Z0XlRTRIl7RyGJouDV/BTiJOLu0 BPnGDpKJdgSPHsbNAz7DLLGl7Dfiw/PSvSvtXKxTcvABQ1eVqfR2rwPAJNAoHmD3piQ4 LTL55BCJ/l9bLPNGRiCBOhPqlcEb8cTFPvSXn5x/ayFYY+/aMa3udFO9V43kyokp1RwW 2+DdRSybOxKjkMZsCQYX1bMko2a37YXkAZWpqQ+GIklP086fUNh32bKEWEuidTGqqNm7 gDcz9mdtJ4OULsQcy1pEUEjRP9JaCSkdRmdZy/5G+Ak6osiyZfL5ZCAcLq9rlZy+LDnL UA== Original-Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2u0f8rjuaq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 02 Aug 2019 15:21:24 +0000 Original-Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x72F7VBu021896; Fri, 2 Aug 2019 15:21:23 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 2u49huc8wr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 02 Aug 2019 15:21:23 +0000 Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x72FLMuY023506; Fri, 2 Aug 2019 15:21:22 GMT In-Reply-To: <<83d0hogj3i.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4873.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9337 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908020156 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9337 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1908020156 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:164366 Archived-At: > > Use `g' with completion and you get to the > > wrong node for the same input. >=20 > My point is exactly that this is a wrong analogy. When one uses 'g', > one needs to know the node's name in advance, not use that name as a > means for searching for some specific subject. The latter is done > via 'i'. No, it is not either-or. `g' - especially given better completion, e.g. substring completion - is a useful way to jump to a node. Especially for a node you might know exists, but whose exact name you might not recall. You do _not_ "need to know the node's name in advance". Just as you don't need to know the exact name of a function or variable when you use apropos commands. When you type some input, `g' completion shows you node-name matches. Let's say you're quite familiar with node `Some Terms'. You remember that it's about terms and terminology. You might even recall that the node name involves "term". `i term' won't get you there. In the Index there are many matches for "term" (24 with substring matching, 20 with prefix matching). And none of those entries take you to node `Some Terms'. (You'll find `Some Terms' listed in the Index, but it's not an index entry. It's listed only as the node name for entry `typographic conventions'.) But `g term' will get you there (if you have substring completion) - instantly. That's just one example. And it shouldn't be necessary to provide it. It should be obvious that matching node names as a way to get to nodes can be handy. (And the lesson of that example, for this bug, is not to suggest that we should have an index entry that includes "term" in this sense of the word. Whether that might help is irrelevant here.) The point is that `g' is also a way to get around, and it does not require that you know an exact node name. `i' is what it is. It remains one of the best ways to locate something. It's not the only way, and it's not invariably the best way. Other ways include Isearch and `g'. A hammer is a great tool, but it's not the only one. > > It's that `g' is also useful, and node > > names should be helpful, not misleading. >=20 > They are, but by definition much less so than 'i'. _This_ node name is particularly misleading, unhelpful. This report is not for an abstract debate about `i' versus `g'. Defending `i' is irrelevant here. I agree with you about its general utility. This bug is about one particular node name that's not helpful. It's about fixing this name, getting one that is more useful, less misleading. Is there a good reason not to fix this node name? I haven't seen any put forward, so far. Instead of insisting on a false all-or-nothing choice between `i' and `g', why don't we just fix this particular node name? Reason?