From: Dmitry Gutov <dgutov@yandex.ru>
To: Juri Linkov <juri@linkov.net>
Cc: 23484@debbugs.gnu.org
Subject: bug#23484: 25.1.50; undo doesn't work properly in xref-query-replace-in-results
Date: Sun, 15 May 2016 00:13:15 +0300 [thread overview]
Message-ID: <b9945af0-5f6e-fa47-5cf2-c9ae48041fb7@yandex.ru> (raw)
In-Reply-To: <87shxkz7yu.fsf@mail.linkov.net>
On 05/14/2016 11:34 PM, Juri Linkov wrote:
> By default .* tries to match whole lines.
If you have a rectangular region, shouldn't replacing .* with whatever
only touch the parts of each line within that rectangle?
That's what region-noncontiguous-p means.
> For partial matches you need
> to use a combination of goto-line and BOUND arg of re-search-forward.
Either you are referring to the current implementation of
xref--query-replace-1, or I don't know what else you want me to do.
> But I still don't see a case where a search regexp used to find matches
> in the *xref* buffer can't be re-used in xref-query-replace-in-results.
I have mentioned xref-find-references several times in the recent
messages alone. An like I said, several times, an xref backend is
allowed to implement it with something more complex than using a plain
regexp search.
In fact, if the current directory has a CScope or Global index
generated, and the relevant program is installed,
xref-collect-references *will* use something different than a regexp search.
> I tried ‘xref-find-definitions’ with a string identifier, then typed ‘r’
>
> Then I thought that maybe you meant the case of ‘xref-find-apropos’
Replacing the results of xref-find-definitions or xref-find-apropos
would be a useless nonsense (all usages of the function(s) or
variable(s) in question would be left intact). This is one of a few
reasons why it isn't supported.
> It's difficult to find a solution without a real use case.
If my explanations are too complicated, can't you just take it on faith
that the only data the replacement command can use here is a list of
pairs of markers?
> Maybe undo could use a search function too. And with using
> a search function should also avoid the need to disable
> query-replace-lazy-highlight in xref--query-replace-1.
Not sure how one follows from the other, but great.
> But it seems there is no hurry in fixing undo because undo of replacements
> is a new feature existing only in master, not in the release branch.
Sure. I never implied that this bug is a blocker for 25.1.
> If you are looking for a solution for the next release, I recommend
> to not expose .* in the minibuffer to the users - that causes too many
> problems.
Since one release will happen in the meantime, we'll probably hear about
this from the users anyway. But this is orthogonal to the solution for
the current problem.
> Either leave the initial FROM regexp empty, so the user types
> an explicit string,
So they'll always *have to* type something? This is very impractical,
which is definitely worse than just being confusing.
> or don't ask FROM at all,
...and implicitly use `.*' as FROM.
I think I've replied to this suggestion twice already.
> using the same regexp
> provided to find matches in the *xref* buffer, thus removing all tricks
> with isearch-filter-predicate/replace-re-search-function, i.e. since the
> .* replacement is not a release-ready feature, just continue its development
> in master.
FFS, no. This is not feasible.
prev parent reply other threads:[~2016-05-14 21:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-08 19:06 bug#23484: 25.1.50; undo doesn't work properly in xref-query-replace-in-results Dmitry Gutov
2016-05-08 20:19 ` Juri Linkov
2016-05-08 20:26 ` Dmitry Gutov
2016-05-09 20:01 ` Juri Linkov
2016-05-09 20:10 ` Dmitry Gutov
2016-05-09 20:19 ` Dmitry Gutov
2016-05-10 21:34 ` Juri Linkov
2016-05-10 22:03 ` Dmitry Gutov
2016-05-11 20:48 ` Juri Linkov
2016-05-11 21:11 ` Dmitry Gutov
2016-05-12 20:57 ` Juri Linkov
2016-05-12 22:01 ` Dmitry Gutov
2016-05-14 20:34 ` Juri Linkov
2016-05-14 21:13 ` Dmitry Gutov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9945af0-5f6e-fa47-5cf2-c9ae48041fb7@yandex.ru \
--to=dgutov@yandex.ru \
--cc=23484@debbugs.gnu.org \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).