From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: tags-loop-continue Date: Thu, 21 Jan 2016 08:15:17 +0300 Message-ID: <56A06965.7050501@yandex.ru> References: <83wprimto9.fsf@gnu.org> <56916C10.6050004@yandex.ru> <83oacumqmj.fsf@gnu.org> <56917246.1010800@yandex.ru> <5691795E.9010008@yandex.ru> <83lh7ym725.fsf@gnu.org> <5691D768.3020908@yandex.ru> <83bn8tmnvq.fsf@gnu.org> <56928356.2000609@yandex.ru> <8360z1mkfc.fsf@gnu.org> <5696EE9D.2090708@yandex.ru> <838u3si22k.fsf@gnu.org> <5697C7A8.6060601@yandex.ru> <83wprcgjxk.fsf@gnu.org> <5697DA3B.3070706@yandex.ru> <83io2wggh8.fsf@gnu.org> <5697EC73.6040302@yandex.ru> <83fuy0gf2j.fsf@gnu.org> <5697F3C9.5040702@yandex.ru> <83bn8ogd8c.fsf@gnu.org> <56980073.7050604@yandex.ru> <838u3rhpzk.fsf@gnu.org> <569D3ADC.5060803@yandex.ru> <83si1sa47q.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453353340 15185 80.91.229.3 (21 Jan 2016 05:15:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Jan 2016 05:15:40 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jan 21 06:15:39 2016 Return-path: Envelope-to: ged-emacs-devel@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 1aM7at-0004zY-7g for ged-emacs-devel@m.gmane.org; Thu, 21 Jan 2016 06:15:39 +0100 Original-Received: from localhost ([::1]:46034 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aM7ar-0004Pk-Vv for ged-emacs-devel@m.gmane.org; Thu, 21 Jan 2016 00:15:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aM7ad-0004Nh-63 for emacs-devel@gnu.org; Thu, 21 Jan 2016 00:15:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aM7aZ-000332-VA for emacs-devel@gnu.org; Thu, 21 Jan 2016 00:15:23 -0500 Original-Received: from mail-lf0-x230.google.com ([2a00:1450:4010:c07::230]:35976) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aM7aZ-00032q-Mh; Thu, 21 Jan 2016 00:15:19 -0500 Original-Received: by mail-lf0-x230.google.com with SMTP id h129so19668088lfh.3; Wed, 20 Jan 2016 21:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=REECnlBvnDPn+GqO94hHjzXLVxaFadLNGbtXmacOF/g=; b=ph2ap6a5OP1hq8Wc6mV8rCCzFzQ0Y0+Nbgc3RhFL0/se73IGC9MrCLZHI71Tl2x16F tZ0EWAHQc5yCE49WpKV/qCHSjJFbBnej0zrQRUOM3ecwYXSyLCDNPpzDvU1g6GKWJJHh Yahe7wa+ufxixsaudZRlYdzNmd62u/QQQ5sxHfkthmHKiym6Tvlsh8bwQT4RVCClFJrw pXFnTAKmRF80Ts8aiFR8eaDs7nS1VGChwMBM2qocIt6wdwWRyxZonyeWA8LU+M+e81L/ H1iw7vbdaWNk33sBE5ZHZw5cepGvLwuQzGmbsPd25WizLF2Y1gEDiWjg0FHRzt+2vUPw paoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=REECnlBvnDPn+GqO94hHjzXLVxaFadLNGbtXmacOF/g=; b=dB25b/zWEAyhDLyvaUMqTkD+1vm3DGszoHNRM6NOzC8f3CKCmsigE9PSSTF1f6Tb4B VABTGygGtOwxfFmvA+DOqTOrO4FtPRq4Xo0axwhMRF1DHG2qvtbT54YApdqEmKAXeK78 6XLki190SlObU1KNgpLRuk2E0vjJy3a81LVzDeFea8JSKtaVHDitsrC6WAgLvz7lSuC2 B6aD2VKBVLbC/EqsZb2C1gK2sUeLyvIwj3oadrtfWS8NREoAcY6LINRsDmyzBhrgzY7g vgDUpVmvAeKbueWPcVqwfPDGre6vqyFb/p8Yce0oeqzCpoWdzWvvSe+ZRalMJY3zMdbA Qcsw== X-Gm-Message-State: ALoCoQnuaqwSH8xnCAy9isznPd+fCf+BtLWy6oZMMyEDt4sI4Qh3H5iAEkofyx1hUbxWcaLhSQXo9O00yeEH3/HnLRxvmyKCVg== X-Received: by 10.25.154.207 with SMTP id c198mr15405661lfe.32.1453353318741; Wed, 20 Jan 2016 21:15:18 -0800 (PST) Original-Received: from [192.168.1.190] ([178.252.127.222]) by smtp.googlemail.com with ESMTPSA id f74sm5228546lfb.7.2016.01.20.21.15.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 21:15:17 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 In-Reply-To: <83si1sa47q.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:198489 Archived-At: On 01/20/2016 02:19 PM, Eli Zaretskii wrote: (I'll get to the performance issues later.) > With 'Q' (dired-find-regexp-and-replace) losing *xref* is a lot > easier: as you walk through the matches, the window which displayed > *xref* suddenly switches to display one of the files with matches > instead of showing *xref*. I think that window should not be reused > for showing matches (perhaps through some display-buffer magic). I never thought that the *xref* buffer is important for dired-find-regexp-and-replace, and even considered creating a modified version of xref-query-replace that wouldn't require that buffer. But indeed, it seems important for continuing the replace operation. > Even worse, there seems to be no way of continuing with the > query-replace operation once it is interrupted for some reason. It > happened to me when I tried to resize the window (because I wanted to > see less of the *xref* buffer) -- Emacs exited the query-replace > command, and I couldn't find a way to continue it where I left off, > even after switching to the *xref* buffer. I think there should be a > way, perhaps with '.' and/or RET, to continue the query-replace from > the match on the current line in *xref*, otherwise people will > complain. I think we can do something like this: as the user agrees to replacements, we disable/mark/hide corresponding entries in the xref buffer. So if the user aborts the replace process, the *xref* buffer only contains the entries they haven't gotten around to. (Or the skipped ones too? That might be harder to implement). Then, pressing `r' again will continue where they left off. > I wouldn't obsolete them just yet. We may wish letting users who will > be unhappy with the new UI to have a way to get the old behavior back, > until the new UI is improved enough to satisfy users. But we can > certainly document the new commands instead of the old ones in the > manual. We've obsoleted find-tag and friends, though. Is that really a problem?