From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#23179: 25.0.92; Restore `M-,' to continue etags search Date: Sat, 2 Apr 2016 21:46:48 +0200 Message-ID: References: <83io01u1gn.fsf@gnu.org> <83d1q9tx0m.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113d0aa09cacbe052f85c1d3 X-Trace: ger.gmane.org 1459626444 21251 80.91.229.3 (2 Apr 2016 19:47:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Apr 2016 19:47:24 +0000 (UTC) Cc: 23179@debbugs.gnu.org To: Eli Zaretskii , Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 02 21:47:15 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1amRVp-0005me-K0 for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Apr 2016 21:47:13 +0200 Original-Received: from localhost ([::1]:50764 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amRVl-0004gL-PN for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Apr 2016 15:47:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amRVi-0004fg-3w for bug-gnu-emacs@gnu.org; Sat, 02 Apr 2016 15:47:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1amRVe-0001qm-Mt for bug-gnu-emacs@gnu.org; Sat, 02 Apr 2016 15:47:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52014) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1amRVe-0001qi-JC for bug-gnu-emacs@gnu.org; Sat, 02 Apr 2016 15:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1amRVe-00018W-AB for bug-gnu-emacs@gnu.org; Sat, 02 Apr 2016 15:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Apr 2016 19:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23179 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23179-submit@debbugs.gnu.org id=B23179.14596264164088 (code B ref 23179); Sat, 02 Apr 2016 19:47:02 +0000 Original-Received: (at 23179) by debbugs.gnu.org; 2 Apr 2016 19:46:56 +0000 Original-Received: from localhost ([127.0.0.1]:49141 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1amRVY-00013Z-6e for submit@debbugs.gnu.org; Sat, 02 Apr 2016 15:46:56 -0400 Original-Received: from mail-vk0-f53.google.com ([209.85.213.53]:35240) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1amRVW-0000yA-GP for 23179@debbugs.gnu.org; Sat, 02 Apr 2016 15:46:54 -0400 Original-Received: by mail-vk0-f53.google.com with SMTP id e6so139424635vkh.2 for <23179@debbugs.gnu.org>; Sat, 02 Apr 2016 12:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=g+H1LROCItRNAlyOoR0sMSONF88eIvZ9sPH/KHR+/7Y=; b=tjG+gAoD8DlrSLF40ySLZfHM2a/XSeuRyZjQdjdjyvS53ooeWQWWN6fh5AEqaHFIh2 1xIB0dM/CA3PC1UT8yPYjRB6oSoeK+5v5QTpss/3ajm4u3U3hIJEJ2QtiFSdby8PtvWf YoiDK2jZ4BqQUhfAF5jDk0nfEQ1/xM993br/B+sip5JBhCvlOPQTJk/7r98lsjPcG88+ ZhrueaCjK7wIEklvorqlbKxjKGhJ7sELRHMTzZ0YaWFHJEMR5C1O+N8L3ZeTsWNyYFAa 1+bpLM7bc5/OlP20DOfUHb/l3J5rwvZAzhQwFLjc97PKycN8W9dsAnDKymxD34jAzWJ1 zfKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=g+H1LROCItRNAlyOoR0sMSONF88eIvZ9sPH/KHR+/7Y=; b=Um5R1pqMRkf/hKGRXQPU7id2uVugWNFWUy5TQJaXG+nRWNn1rHB7JRL6Yo3/9BD/dD 7hYPuvtW/O09ISd6B/SVQIwPhucgFmrYht7IJZVvkNGACjZaUtfdwl/wHE/O+hBfXkAD GCKOlNWtaEA5yjiM5SitWXgI4ftbAItdTynLpM7E/aMQNcvOlQUdM8qCSH6BR/xnW9Uo B4wdS/p4IWGPsu17qVP1Ua+OeJrtrtHWNdrYLkLRZxI5jELSRzmRhaePA2jOE7xLtQeS LPD/LtPLa0GGSl/twLBqDmCM362JxcmzYVu8yZYEWv0+B/ECcXlJDxq/AADpXF9mX/+D 18/w== X-Gm-Message-State: AD7BkJLUPwjk9X5cbuG1nKhm8IkZ23BGKdhvLdtuR26j//HjTblI2AaPcxz7UiVjNIn23JOjL35qbYSTRVn5zA== X-Received: by 10.159.37.137 with SMTP id 9mr4643465uaf.25.1459626408977; Sat, 02 Apr 2016 12:46:48 -0700 (PDT) Original-Received: by 10.31.214.131 with HTTP; Sat, 2 Apr 2016 12:46:48 -0700 (PDT) In-Reply-To: <83d1q9tx0m.fsf@gnu.org> 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: 208.118.235.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:115888 Archived-At: --001a113d0aa09cacbe052f85c1d3 Content-Type: text/plain; charset=UTF-8 Hi! Eli: > I'm afraid that ship has sailed. We need to find a solution to this > issue without going back. > I can agree with this. The "xref" package is a big step forward, since it supports multiple backends etc. Unfortunately, vital functionality is missing -- searching and query-replace in all included files. Personally, I use `tags-search' at least 20 times per day (often more), and `tags-query-replace' several times each week. I don't think that my use pattern is extreme by any means. I think that we would be making a big mistake if we would release Emacs 25 with an "xref" without searching and query-replace, but with key bindings that, for most tags users, break existing use patterns. Dmitry: > If you want to have an xref-find-regexp as well, we should first understand clearly how it would differ from those two commands. And its specification cannot refer to tags files directly. Today, many people use "tags" as a simple project file. They don't want to redo this process with another tool ("project") and a dired approach might not match a project layout at all. Maybe I'm being naive, but a tags file (and presumably all other xref backends) must represent a list of files. A free text search and query-replace across those files would be very straight forward to specify, wouldn't it? Eli: > But we could have a tags-only command that presented an xref UI, I think. (Its name could be "tags-search" ;-) It would have been neat... Unfortunately, the problem is not launching the command, but rather continue searching past the first match -- since a source buffer, and not the xref UI buffer, will be current. I have given this some thought -- if we decide to really do make a change, maybe we should try to make the xref search command more isearch-like, so that a user could be able to continue an xref search using `C-s' rather than `M-,'. Unfortunately, there is no natural key binding to continue a normal query replace, but we could create something like `xref-query-replace-from-here', to continue query-replacing from the point in the current buffer and then continue with the next file in the file list. -- Anders --001a113d0aa09cacbe052f85c1d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi!

Eli:
I'm afraid that ship = has sailed.=C2=A0 We need to find a solution to this
issue without going back.

I can agree w= ith this.

The "xref" package is a big st= ep forward, since it supports multiple backends etc. Unfortunately, vital f= unctionality is missing -- searching and query-replace in all included file= s. Personally, I use `tags-search' at least 20 times per day (often mor= e), and `tags-query-replace' several times each week. I don't think= that my use pattern is extreme by any means.

I th= ink that we would be making a big mistake if we would release Emacs 25 with= an "xref" without searching and query-replace, but with key bind= ings that, for most tags users, break existing use patterns.

=

Dmitry:
> If you want to have an xref-find-regexp as well, we should first und= erstand clearly how it would differ from those two commands. And its specif= ication cannot refer to tags files directly.

Today, many people use "tags" as a simple project file. They = don't want to redo this process with another tool ("project")= and a dired approach might not match a project layout at all.
=

Maybe I'm being naive, but a tags file (and presumabl= y all other xref backends) must represent a list of files. A free text sear= ch and query-replace across those files would be very straight forward to s= pecify, wouldn't it?
=

Eli:
> But we could have a tags-only command that presented an xref= UI, I=C2=A0think.=C2=A0 (Its name = could be "tags-search" ;-)

It w= ould have been neat... Unfortunately, the problem is not launching the comm= and, but rather continue searching past the first match -- since a source b= uffer, and not the xref UI buffer, will be current.


I have given this some thought -- if we decide to rea= lly do make a change, maybe we should try to make the xref search command m= ore isearch-like, so that a user could be able to continue an xref search u= sing `C-s' rather than `M-,'. Unfortunately, there is no natural ke= y binding to continue a normal query replace, but we could create something= like `xref-query-replace-from-here', to continue query-replacing from = the point in the current buffer and then continue with the next file in the= file list.

=C2=A0 =C2=A0-- Anders

--001a113d0aa09cacbe052f85c1d3--