[Top][All Lists]

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

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

From: Dmitry Gutov
Subject: bug#32034: 26.1; [PACTH] better xref-location-marker for imperfect file locations
Date: Wed, 4 Jul 2018 15:58:53 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

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.

reply via email to

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