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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: João Távora <joaotavora <at> gmail.com>
Cc: 32034 <at> debbugs.gnu.org
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Date: Wed, 4 Jul 2018 15:58:53 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.