Re: tags-loop-continue

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 21 Jan 2016 08:15:17 +0300
> 
> > 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.

I think having the *xref* buffer visible is _the_ reason we could get
rid of tags-loop-continue.

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

No, I think all the matches that the user saw already, whether she
accepted the replacement or not, should be marked in some way, so that
continuing the replacement goes to the first unseen one.

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

Yes, but that was long ago, while these two commands are going to be
replaced just now.  Besides, they are Dired commands, not etags
commands.  So I think it does make a difference.  In any case, this is
not a terribly important point, it's easy to obsolete and it's also
easy to unobsolete later if we change our minds.  We can defer the
decision for later.

Thanks.