Re: xref-query-replace

[Dmitry Gutov]

On 01/10/2016 06:52 PM, Eli Zaretskii wrote:

> By "false positives" do you mean matches to text that isn't really a
> reference to 'foo'?  This command is interactive, so the user can
> reject irrelevant matches and accept only the relevant ones.  So I see
> this issue as a less important one.  We could even display a warning
> about potential false matches when the command is invoked in such a
> buffer.

All that, just to make sure the user isn't confused by the command not 
being applicable in that kind of xref buffer? The they will remain 
subtly confused in other respects.

Also note how you've skipped the more complex case: when the 
identifier-to-search is fully qualified (i.e. not a string that usually 
occurs in a buffer).

> By contrast, having a command inexplicably fail in a buffer that looks
> and feels exactly like another one, where the command does work, is a
> worse problem, IMO.  If you insist on leaving things as they are, be
> prepared for bug reports.

At least they'll see that this buffer is different somehow. And if we 
didn't manage to explain it better, well, maybe a user will have a 
better idea for naming things.

> > To put it differently, neither etags, nor find-func.el provide the necessary 
> > information to create xrefs with match boundary information.
>
> The boundary information just makes the matches more accurate, but it
> doesn't invalidate them, AFAIU.

I don't mean "symbol boundary".

"boundary information" = match starts at position 11 and ends at 21

Etags doesn't provide that.

> >      I just don't see what kind of collective name would be possble.
> >
> > Well, I wouldn't ask if I managed to come up with one. I don't see another way 
> > to resolve the issue, however.
>
> Then I guess it will remain unresolved.  Too bad.

In my head, I call them something like "general xrefs" vs. "matches 
xrefs". The latter contain the boundary information.