[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tags-loop-continue
From: |
Dmitry Gutov |
Subject: |
Re: tags-loop-continue |
Date: |
Thu, 21 Jan 2016 08:15:17 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:44.0) Gecko/20100101 Thunderbird/44.0 |
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?
- Re: tags-loop-continue, (continued)
- Re: tags-loop-continue, Dmitry Gutov, 2016/01/21
- Re: tags-loop-continue, Eli Zaretskii, 2016/01/22
- Re: tags-loop-continue, Dmitry Gutov, 2016/01/22
- Re: tags-loop-continue, Eli Zaretskii, 2016/01/22
- Re: tags-loop-continue, John Wiegley, 2016/01/22
- Re: tags-loop-continue, Dmitry Gutov, 2016/01/22
- next-error-function integration in xref removed, Dmitry Gutov, 2016/01/23
- Re: tags-loop-continue, John Wiegley, 2016/01/21
- Re: tags-loop-continue, Dmitry Gutov, 2016/01/21
- Re: tags-loop-continue, John Wiegley, 2016/01/22
- Re: tags-loop-continue,
Dmitry Gutov <=
- Re: tags-loop-continue, Eli Zaretskii, 2016/01/21
- xref and displaying locations in appropriate window or frame, Dmitry Gutov, 2016/01/23
- Re: xref and displaying locations in appropriate window or frame, martin rudalics, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame, Dmitry Gutov, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame, martin rudalics, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame, martin rudalics, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame, Dmitry Gutov, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame, martin rudalics, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame, Dmitry Gutov, 2016/01/24
- Re: xref and displaying locations in appropriate window or frame, martin rudalics, 2016/01/25