[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: xref-query-replace
From: |
Eli Zaretskii |
Subject: |
Re: xref-query-replace |
Date: |
Sun, 10 Jan 2016 17:52:35 +0200 |
> 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.
- Re: xref-query-replace, (continued)
- Re: xref-query-replace, Eli Zaretskii, 2016/01/09
- Re: xref-query-replace, Dmitry Gutov, 2016/01/09
- Re: xref-query-replace, Eli Zaretskii, 2016/01/09
- Re: xref-query-replace, Dmitry Gutov, 2016/01/09
- Re: xref-query-replace, Eli Zaretskii, 2016/01/09
- Re: xref-query-replace, Dmitry Gutov, 2016/01/09
- Re: xref-query-replace, Eli Zaretskii, 2016/01/09
- Re: xref-query-replace, Dmitry Gutov, 2016/01/09
- Re: xref-query-replace, Eli Zaretskii, 2016/01/09
- Re: xref-query-replace, Dmitry Gutov, 2016/01/09
- Re: xref-query-replace,
Eli Zaretskii <=
- Re: xref-query-replace, Dmitry Gutov, 2016/01/10
- Re: xref-query-replace, John Wiegley, 2016/01/18
- Re: xref-query-replace, Dmitry Gutov, 2016/01/18
- Re: xref-query-replace, John Wiegley, 2016/01/18
- Re: xref-query-replace, Dmitry Gutov, 2016/01/18