Re: xref-query-replace

[Eli Zaretskii]

> Cc: address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Sun, 10 Jan 2016 06:54:34 +0300
> 
>     I don't understand the importance of the length, but the definition of
> 
> Knowing the length lets us determine the boundaries of the match inside the 
> file. This information is gathered at the time the xref instance in 
> constructed.
> 
>     a method points to a specific source line, exactly like a reference.
>     So whatever you gather from a reference could be done with a
>     definition, no?
> 
> What will I do with the source line, then? Suppose TAGS file contains an 
> entry for the method "foo" pointing to the line
> 
>   def self.foo
> 
> And the backend returns it as one of the results for the definition of "foo". 
> How will we determine the bounds of the match? (search-forward "foo")? What 
> if the line looks line this?
> 
>   def self.foo(bar); @foo = bar; self.another_foo(@foo); end
> 
> We'll get false positives this way.

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.

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.

> 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.

>         If we define a collective term for such xref functions, we could 
> mention
>         it in their docstrings.
> 
>     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.