Re: xref-query-replace

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> 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.