[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xref-query-replace

From: Dmitry Gutov
Subject: Re: xref-query-replace
Date: Sun, 10 Jan 2016 19:02:53 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:43.0) Gecko/20100101 Thunderbird/43.0

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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]