Re: Emacs contributions, C and Lisp

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 26 Feb 2014 21:17:07 +0100
> 
> 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.

I suggest to try (I did).  Maybe then you will be less radical in your
judgment of having N+1 candidates when only N are strictly needed.

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

I see nothing wrong with doing the simplest thing, if it gives
reasonable results.  This is an engineering discipline, not an exact
science; compromises are our bread and butter.  I'm sure you are well
aware of that.

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

There's a thing called "extensions", you know.  The Emacs 23 display
engine was abysmally inadequate for bidirectional scripts, and yet
relatively minor changes extended it to be adequate.  I say "minor"
because the basic design of the display engine remains intact.

So I don't quite understand why you decided (without trying) that none
of the existing solutions can be extended to fit the bill.  Are you
seriously claiming that clang is the _only_ way to go?  I hope not.

> > ECB also supports mart completion.
> 
> For C++? Not really.

How do you know?  When did you last try?  If not recently, perhaps it
got better since then?  Did you attempt to analyze what is missing and
how hard would it be to add that?

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

Who said it was slow _today_?  I found complaints from 2009, are you
really going to claim they are still relevant, without checking out?

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

Then perhaps the assertiveness of your opinions should be on par with
how much you know.

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

Statistics doesn't understand anything about the underlying phenomena,
and yet it is able to produce very useful results.  IOW, we don't need
to understand C++, we just need to be able to do certain jobs.
Understanding (parts of) it is the means to an end, and that's all.

> >> 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? ;-)

I don't know, you tell me.

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

"Defective" is a far cry from "non-strict requirements", don't you
think?

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

To what end?