GNU bug report logs -
#23484
25.1.50; undo doesn't work properly in xref-query-replace-in-results
Previous Next
Full log
View this message in rfc822 format
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.
This bug report was last modified 9 years and 36 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.