Re: Emacs contributions, C and Lisp

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

> Would it be so bad if it showed 2 candidates instead of one?

IMO, yes. The "smart" part of "smart completion" is that only suitable
candidates are shown. Something else just causes confusion and
compile-edit cycles. Also, that example used a method for each class.
Real-world cases are not limited to that.

> And what happens if you add
>
>   B baz(char);
>
> to the above -- will it show 2 candidates or just one?

Dunno. As David Engster explained, CEDET does the simplest thing (take
one of the overloads and ignore the rest.)

> I don't know why you are saying this.  E.g., a "parser armed with some
> ad-hoc heuristics" that we have in ebrowse seems to be able to catch a
> significant subset of C++, certainly of C++ that existed when ebrowse
> was written.  Why couldn't we base this feature on an extended ebrowse
> engine?

Today's C++ common usage would look totally alien to a programmer coming
from the year 2000. Ebrowse is for "C with classes" more than C++. AFAIK
Ebrowse will choke at the first occurrence of a template, for example.
Also its intended usage is quite more modest than the functionality
required for smart completion, not to mention refactoring.

> ECB also supports mart completion.

For C++? Not really. It only works as long as your code is simple
enough, but that's because it implements the simplest cases. I tried it
several times on my code base and the time saved on the cases where it
worked was not enough to compensate for the cases where it didn't,
leaving aside the frustration of the continous wtf!! moments.

>  4 years ago people complained that
> it's slow, but machines became faster since then, so perhaps things
> are not so bad now, and we could use Semantic for this purpose.

If Semantic is slow supporting the easiest, simplest parts of the C++
source code analysis... think about how slow would it be if it
implemented the missing parts, those that make C++ compilers really slow
compared to their C counterparts.

>> Clang provides code completion as a sample of its capabilities.
>> Clang/LLVM in fact is a set of libraries for dealing with C/C++ code.
>> You can use those libraries for code completion and for any other
>> feature that requires accessing/processing information contained on
>> source code: extracting declarations, sanitizing, instrumenting,
>> optimizing, generating object code...
>
> Are there any Emacs packages that support those features?

Dunno. But the point is that now that a tool exists for doing the heavy
lifting, creating an Emacs package for exploiting C++ semantic
information is feasible.

>> One was already mentioned by Stephen Leake: refactoring.
>
> The only Emacs package for this that I could find is proprietary
> (Xrefactory).  Do you happen to know about any free ones?

No. My knowledge is far from exhaustive, though.

>> Actually,
>> anything that requires semantic knowledge of the source code you are
>> working on. You could ask for a listing of places dependent of word
>> size, for instance, or highlight the places where certain idiom is used.
>
> Doesn't ECB already support such features?

I don't think so. It can't do that since its understanding of C++ is
quite limited.

>> IIRC I already told you this a few weeks ago, but I'll repeat: a C++
>> front-end (even without code generation capabilities) requires an
>> immense amount of work from highly specialized people, and then needs
>> improvements as new standards are published.
>
> Only if you need to be 110% accurate,

Since 100% is perfect, why should I wish more? ;-)

> which is certainly a requirement
> for a compiler.  But we don't need such strict requirements for the
> features we are discussing, I think.

A defective refactoring tool can easily cause more work than it saves.
It can introduce subtle bugs, too.

>> >> Why reinvent the wheel?
>> >
>> > Because we cannot get the one that's already invented?
>> 
>> "we cannot" isn't the right expression. "we are not allowed" is the
>> correct description.
>
> I'm trying to keep this part of the thread out of politics and into
> something that could hopefully lead to a working implementation.

I'm not interested on politics either. I just wanted to be accurate :-)