[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#23484: 25.1.50; undo doesn't work properly in xref-query-replace-in-

From: Dmitry Gutov
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]