Re: tags-loop-continue

[Eli Zaretskii]

> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Mon, 18 Jan 2016 22:19:56 +0300
> 
> On 01/14/2016 11:21 PM, Eli Zaretskii wrote:
> > A new command, I think.  One step at a time.
> 
> > It should be dired-do-SOMETHING, for consistency with others.
> 
> > Or maybe have a minor variant bound to 'Q' that would also ask for a
> > replacement, like query-replace?
> 
> Added both commands. Please check them out.

Thanks, I took a look at the two commands.  They look good overall,
IMO, but I have a few comments.

First, they both take a long time to display the first match.  I
understand that's because you run Grep to collect all the matches, but
can't you let Grep run asynchronously, display the first match as soon
as it comes in, and then update the list as the rest arrive?  You
don't need to present the matches in any particular order, so it
sounds like waiting for all of them is not required.

I think this initial delay will be quite long in large directories (I
tried with Emacs's 'src' directory, which is not very large, and my
disk is SSD, but it still took annoyingly long).  I'm guessing we will
get a lot of complains from users of these two commands who were
accustomed to a much faster startup.

My other problem is with the "disappearing *xref* buffer" phenomenon:
it is too easy to lose it, and not so easy to get it back.  With 'A'
(dired-do-find-regexp) it's enough to type RET on a line in the *xref*
buffer in order to have its window deleted; the only way to get it
back AFAICT is to manually switch to that buffer, which means the user
must remember its name.  You cannot continue the search without
switching back to *xref* first.  So I think RET should not delete the
window in this case.  Maybe it should never delete the window, in
other users of xref, I'm not sure.  At least in this case, unlike with
xref-find-definition, it is much more probable that the user _will_
want to go to the next match, so it makes less sense IMO to delete the
window.

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).

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.

> If they're considered good enough, I think we can re-obsolete 
> tags-loop-continue, and obsolete dired-do-search and 
> dired-do-query-replace-regexp as well.

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.

Thanks.