Re: progmodes/project.el and search paths

[Eric Ludlam <ericludlam@gmail.com>]

On 08/14/2015 06:30 PM, Dmitry Gutov wrote:
> On 08/14/2015 02:52 PM, Eric Ludlam wrote:
>
>> 2) Parsers don't check types, etc as they go, and are flexible about the
>> symbols they accept.
>>
>> This means you can get irrational tags.  This is for a combination of
>> handling incomplete code, speed (less to do) and because most folks just
>> go an run their compiler at some point anyway.
>
> Doesn't that mean that code completion at the end of a chain of calls 
> can be inaccurate (with e.g. lots of false positives), even if code is 
> otherwise valid?

While the parser generally ignores data types, it does record the 
declarations.  When smart completion is invoked, only the types 
currently relevant are resolved in order to make the completions 
accurate.  Thus:

Parsing phase: Just record the data as declared, don't check.

Completion phase: Look up data types as needed for symbols in the 
completion string.

If point of fact, Semantic's tagging parser doesn't parse the bodies of 
functions, and just skips over them.  The body is only parsed if a 
completion is needed since the symbols within are locally scoped and 
don't affect other tags.

On a side note, I've had a lot of complaints that completion was too 
pedantic, and if it can't find a pedantic answer, perhaps it could let 
loose a little and find a vaguely close answer.

>>
>>> In summary; Semantic can extract useful data out of pretty badly 
>>> trashed
>>> code, and track your changes while you edit in a robust way.
>>
>> It seems I stand corrected, thanks. However, it would be interesting 
>> to do a comparison on some real file, against a widely used compiler, 
>> such as Clang.
>>

That would be interesting.  What would the goal be?  There are lots of 
things Semantic doesn't do, nor was intended for.   Like many Emacs 
tools, the Semantic parser is a bit liberal in the assumptions it makes 
to get a good enough answer.

Eric