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.devel Subject: RE: master fe939b3 1/2: Fix reference to `tags-loop-continue' in doc string Date: Mon, 5 Aug 2019 08:05:49 -0700 (PDT) Message-ID: <068382bf-e781-4bd7-9a1d-df4857a6db0e@default> References: <20190801195403.16246.49802@vcs0.savannah.gnu.org> <20190801195406.087AF20CC8@vcs0.savannah.gnu.org> <87ef23allc.fsf@mouse.gnus.org> <877e7vpgmt.fsf@mouse.gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="211834"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Dmitry Gutov , Robert Pluim , Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 05 17:06:42 2019 Return-path: Envelope-to: ged-emacs-devel@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 1hueZM-000sxc-Kv for ged-emacs-devel@m.gmane.org; Mon, 05 Aug 2019 17:06:40 +0200 Original-Received: from localhost ([::1]:54648 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hueZL-0006YX-Mh for ged-emacs-devel@m.gmane.org; Mon, 05 Aug 2019 11:06:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43187) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hueYf-0006YF-E8 for emacs-devel@gnu.org; Mon, 05 Aug 2019 11:05:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hueYe-0001K9-85 for emacs-devel@gnu.org; Mon, 05 Aug 2019 11:05:57 -0400 Original-Received: from userp2120.oracle.com ([156.151.31.85]:47174) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hueYd-0001JA-Vs for emacs-devel@gnu.org; Mon, 05 Aug 2019 11:05:56 -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 x75F3xv2132772; Mon, 5 Aug 2019 15:05:52 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=WtdXPrAajgGeR4DjuIKYwIELcFOVzJvAkB0tpCHfHgo=; b=YAgAC27/t/PTcrJong7ow2ZXe9EvH1NrCCxsi3l+sYBN6qfguawqAVkNt9Zc/2XFC4jE oxhfx6ojaD2lTCFq1ZyWcRc6olGkF78SDum4E3zoY0yCkWdgdDdFMcBGIJy1kOJa1cPw Of29HX9+ohRUsbCyACekMB88cxC2Odyj6MddPK/uacqr7iaKpE/aTLjEX6HHa6zRD69r X8fVABCMmQsPEUfxOkGnhmb3a3mtjSCch+PnB2fheJfwIX9KKCdSkX2XpKYj/3/VI+Xc XXPVsiieZjA/ppJnd9ZK1Wuz7RCNi/LeXKO7KIHriGv75nHJFmyJ6yYjQQrUQVwkNo4J 9w== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2u52wqysn0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 05 Aug 2019 15:05:52 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x75F2fO5060895; Mon, 5 Aug 2019 15:05:51 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3020.oracle.com with ESMTP id 2u51kmhdnk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 05 Aug 2019 15:05:51 +0000 Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x75F5oTF014423; Mon, 5 Aug 2019 15:05:50 GMT In-Reply-To: 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=9340 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 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-1908050168 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9340 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=18 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-1908050168 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 156.151.31.85 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:239191 Archived-At: > > It begs the question why xrefs replaced a 'do the next thing' type > > binding with a 'go back' type binding in the first place. >=20 > Because it's more useful. The xref UI presents you with all matches > right away, and you choose before visiting, so you don't really need > the "go next" binding 98% of the time. I would say "also useful" and "differently useful", or "sometimes more useful" - not "more useful". Is `occur' (show all matches, let you get directly to any, in any order) more useful than incremental search? Or do you use them both, for different things, in different contexts? I use them both. FWIW, I was the first to provide a way to get occur-like behavior during completion (in Icicles), to let you search or search-&-replace without needing to visit each matching occurrence, in turn. So I fully recognize the advantages of direct access to search/find hits over the more exhaustive approach of visit-each-in-order. But I also recognize that a single tool - even a good, flexible one - is not necessarily the best tool for all jobs. It was fine to add `xref' to the tool kit. Great. It was not so fine (IMHO) to have it take over the longstanding keys used for the existing `do the next thing' commands (e.g., `dired-do-search', `dired-do-query-replace'). Addition, not replacement, would have been TRT. And yes, I think it was done precipitously, in addition to not being necessary. "xrefs replaced a 'do the next thing' type binding with a 'go back' type binding" > > xref-pop-marker-stack should use a different > > binding, and M-, should be fileloop-continue, > > but the xref one has existed for 5 years now. >=20 > Exactly. That ship has sailed. The bindings were repurposed, and perhaps it's too late to back out that mistake. But why is it too late to rehabilitate the `do the next thing' commands and their doc, and give them key bindings once again? Why promote only `xref', essentially deprecating the others? Why not promote (document, bind, etc.) both approaches? We don't denigrate Isearch just because we have `occur'. Why was it good to _replace_ the `do the next' commands with `xref'? > If you are still not convinced, please go > ahead and look up the older discussions for > our reasoning. I read it all at the time, argued against repurposing those longstanding keys at the time, and I'm still not convinced that Emacs did the right thing in this regard. I'm convinced of the utility of `xref' (and I always was). I'm not convinced that the existing commands/keys had to be sacrificed in order to promote what you see as "more useful" (even perhaps as best for all uses).