Re: Emacs contributions, C and Lisp

[Óscar Fuentes]

Eli Zaretskii <address@hidden> writes:

>> Nobody can parse C++ reliably.  GCC has given up on trying to teach
>> Bison (aka LALR(1) and then some) how to parse C++ and has implemented
>> its own hand-written parser.
>
> I understand the potential difficulties, but since we only need a
> relatively small part of parsing,

Why do we need a small part of parsing? For implementing C++ smart
completion on a reliable way, you need semantic analysis. Furthermore,
people here are talking too much about completion, but there are other
features that require whole-program semantic analysis and hence are out
of reach of the approaches mentioned here based on gcc spitting
not-quite-comprehensive information.

> perhaps it's worth trying first?  If
> push comes to shove, what was implemented in GCC can be reimplemented
> in Emacs Lisp, no?

Right now the available systems for smart code completion are annoyingly
slow. They are implemented on C/C++. It is reasonable to expect from a
Elisp-based solution to be unbearably slow, not to mention the
complexity.

Why reinvent the wheel?

> Though I have hard time believing that we will
> need to go that far.
>
>> If you want to be able to reliably follow references to their
>> _corresponding_ definition, it's almost inavoidable to ask some compiler
>> for its opinion just what fully qualified function/operator is to be
>> considered to correspond to the source.
>
> I don't understand why, sorry.  Are we still talking about smart
> completion, i.e. displaying candidate expansions of text at or near
> point?  Or are we talking about something else?

Dunno about David, but I say "yes", for smart completion you need way
more than quick & dirty parsing.