GNU bug report logs - #19468
25.0.50; UI inconveniences with M-.

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 19468 <at> debbugs.gnu.org
Subject: bug#19468: 25.0.50; UI inconveniences with M-.
Date: Fri, 01 May 2015 15:57:12 +0300

> Cc: 19468 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 1 May 2015 14:27:40 +0300
> 
> On 05/01/2015 09:45 AM, Eli Zaretskii wrote:
> 
> > I don't see anything language-specific here.  Etags.el has no
> > language-specific knowledge, either (it is delegated to etags.c).
> 
> elis-mode.el does. In this case, it's using find-func.el, which uses the 
> information we have about Elisp environment at runtime.

Sorry, I don't understand what "Elisp environment at runtime" means in
practice, or how it's used to affect what results are returned for a
query.

> The point is on a foo.bar() call in a Java-like language. Or maybe C++.
> 
> bar is present in classes A, B and C.
> 
> If the parser knows the type of foo to be A, the backend employing it 
> can bring us to the one definition. If, however, the backend returns the 
> xrefs for A#foo, B#foo and C#foo, there's no way the UI could 
> distinguish between them.

That's the case where the UI should instruct the back-end what it
needs, because the back-end doesn't know which of these alternatives
is the right one.  If the user wants all bar functions, or maybe those
whose parent class matches some regexp, not just the one from the
class instance at point, then producing only one match would be wrong,
and the UI won't be able to correct that.

Previous Next

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