[Top][All Lists]

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

Re: Emacs contributions, C and Lisp

From: Stephen J. Turnbull
Subject: Re: Emacs contributions, C and Lisp
Date: Wed, 26 Feb 2014 19:52:40 +0900

David Kastrup writes:
 > "Stephen J. Turnbull" <address@hidden> writes:
 > > David Kastrup writes:

 > >  > In this particular case, the "annotated syntax tree" question in
 > >  > particular is mostly uninteresting since we are talking about
 > >  > characterizing identifiers.  It is "mostly" uninteresting since the
 > >  > resolution of an identifier depends on scopes,

 > > Nice try, but I don't think you can deprecate the value of the
 > > information GCC is not allowed to emit that easily.

 > > Emacs's treatment should depend on types and usage [...]

 > Most of your reply has already been addressed in the parts you did not
 > quote.

OK.  I guess what you are arguing is that you can throw away the tree
and keep only the local annotations.  All I'm saying is that you need
those local annotations, and you need "position in program"
information.  However, a conventional xref table is not going to be
enough because you need the scope (which is required to restrict the
list of completions).  Even if your xref table provides enough
information to determine scopes properly, you'll end up rebuilding
something very close to a syntax tree to associate those scopes with
each potential use of an identifier (and thus the most accurate list
of potential completions at each point in the buffer).

IOW, my point is not really that you can't throw away the annotations;
it's that you don't want to throw away either the syntax tree or the

OTOH, it will be interesting to see if the Ada -fdump-xref feature is
actually good enough to handle the insanity of C++ without a full
syntax-tree.  Óscar's argument that you really need the whole syntax
tree to achieve accuracy in C++ seems pretty plausible to me (although
I don't think completion is a compelling application -- we already do
pretty well).

reply via email to

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