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

[Dmitry Gutov]

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.