bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations

[Dmitry Gutov]

On 7/3/18 6:43 PM, João Távora wrote:

> No, no error. Stays put. So no worse.

If it doesn't find the qualified symbol name somewhere else verbatim.

> We could avoid that (particulary far fetched) case (and the string case) 
> by checking syntax.

I wouldn't say it's far-fetched. More importantly, it adds a non-obvious 
condition on how symbol names should be presented in the completion 
table. Even if this gun doesn't shoot most of the time.

Maybe it's not in a docstring, but in some macro definition, or passed 
verbatim in some other language construct. Maybe it's part of some other 
definition name (separate definitions for methods in C++ come to mind).

> Oh, I must have misgrepped then. Excuse my ignorance, but are these 
> grep-like tools? If so, they shouldn't ever suffer from the "outdated" 
> malaise, right?

Well, the grep results buffer can (and often does) live after the user 
has opened one of the search results and made a change there.

It can certainly become outdated if the user has added or deleted a 
couple of lines there.

> I guess a new xref-hinted-location subclass would be the way to go, if 
> not too much work.  But still think we should do something by default 
> that will do just as bad on the worst case.
"won't do"? I'm unclear on your meaning here.

I'm not sure we really need a subclass if a new optional field would 
work just as well. It might be shorter implementation-wise, too.