GNU bug report logs -
#32034
26.1; [PACTH] better xref-location-marker for imperfect file locations
Previous Next
Full log
Message #47 received at 32034 <at> debbugs.gnu.org (full text, mbox):
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.
This bug report was last modified 4 years and 41 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.