Re: Emacs contributions, C and Lisp

[David Kastrup <dak@gnu.org>]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

> David Kastrup writes:
>  > "Stephen J. Turnbull" <stephen@xemacs.org> 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.

Really, I addressed this _exhaustively_ in
<URL:https://lists.gnu.org/archive/html/emacs-devel/2014-02/msg00546.html>.
I could basically quote the entire message in reply to your "guess what
I am arguing" but it seems to make awfully little sense.

So perhaps try answering the whole message rather than picking a
half-paragraph and blocking the rest out.

> 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).

See above.

> 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).

See above.

> 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
> annotations.

We already saw where the "I want it all, and now" leads us.  In
particular since "all" is rather ill-defined and very likely tied into a
particular internal representation/focus of GCC.

I repeat (now indeed quoting from the mail you "answered" previously):

    To followup on myself: smart completion is a concrete actual
    application for Emacs within the GNU universe so this discussion is
    less likely to get lost in an abstract showdown.

    It's definitely an issue that can be solved using special-casing.
    It's non-trivial enough to discuss its implications concretely.

> 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.

I have no idea.  But a full syntax tree is not required.  I repeat:

    [...] so the basic question that likely needs solving is "given the
    following source location and the following identifier, what data
    structures and definitions does it refer to".  Resolving identifiers
    based on source location efficiently will require suitable data
    structures, and any daemon answering questions accordingly will have
    to get raw data for building them.

An efficient and compact representation might make use of typical
scoping structures, like Git's archives rely on "delta chain
compression" designed to make use of typical history dependencies
without actually delivering any actually useful relation information.
You want the data structure for answering the "meaning of x at source
location y" question make good use of the typical correlation of
identifier sets between source location y and source location y+dy.

But that does not mean that digging through the whole syntax tree is
going to be what you want.  That's more likely than not too inefficient
to be fun.

At any rate, this is hypothetical, while it would appear that
-fdump-xref isn't.  There seems to be little point in fighting a lot
over it without actually looking what -fdump-xref actually does.

-- 
David Kastrup