Re: Emacs contributions, C and Lisp

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

Eli Zaretskii <eliz@gnu.org> writes:

>> >> > 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.
>> 
>> Adding an overload to just make an specific case work on certain
>> completion package is unacceptable, to say it mildly.
>
> I don't know what exactly you tried, and why did you decide I was
> doing unacceptable things, but what I actually tried was clang.  After
> adding the above line, it only shows one candidate, whereas I think it
> should have shown 2.

No. After adding your overload, there is just one candidate, namely,
the one that exactly matches its argument type: char.

> IMO, showing more candidates than strictly
> necessary is a lesser evil than showing less than necessary.

If this was an attempt of pointing to a defect on Clang, you failed, and
it is not surprising, because Clang uses the same machinery for deciding
the correct overload when it is acting as a compiler as when it is asked
for completion candidates. Surely, if Clang failed to give the correct
answer for the completion case, it would be a very broken C++ compiler
too.

>> > So I don't quite understand why you decided (without trying) that none
>> > of the existing solutions can be extended to fit the bill.
>> 
>> How do you know that I didn't tried?
>
> Because you continue saying that nothing but clang is, or can be, good
> enough.

I'm saying that a compiler infraestructure, with the correct interfaces,
makes any other approach look as a hack, for the reason stated on my
previous paragraph. Right now only Clang fits the bill (possibly GCC
too, modulo API convenience) but more compilers could qualify on the
future.

>> > Are you seriously claiming that clang is the _only_ way to go? I hope
>> > not.
>> 
>> On terms of reduced effort, it is the easiest way by far.
>
> What basis do you have for this assertion?  How many Emacs completion
> packages that use clang did you try?  There's only one that I could
> find, and it has the following disclosure, which speaks for itself:
>
>   Note that this minor mode isn't meant for serious use: it is meant
>   to help experiment with code completion based on Clang.
>
> Given such a small sample, I don't see how can anyone publish claims
> such as yours.

What are you trying to say with this? Does Clang's usefulness depend on
whether or not an Emacs package exists?

[snip]

>> > If not recently, perhaps it got better since then?
>> 
>> Surely it got better, but not enough, as demonstrated two messages ago.
>
> Nothing of the kind was demonstrated 2 messages ago.

Are you serious? It failed on a case that could come from the first day
of a course on C++ fundamentals. No complex expression type deduction,
no template metaprogramming, no namespace resolution... it's C++ coming
from the 1980s.

Eli, are you a C++ programmer? Do you code in C++ on a regular basis?

If you answer "no" to any of those questions, we'll better stop this
discussion here and now.

>> > Did you attempt to analyze what is missing and
>> > how hard would it be to add that?
>> 
>> I'm no compiler expert, but as stated multiple times by now, for
>> expecting CEDET to work on modern C++ code bases the required effort is
>> *huge*. And that's suppossing you are a compiler writer with experience
>> implementing C++ front-ends.
>
> I think you have a different application in mind.  In any case,
> reiterating your opinion doesn't make it more credible, unless you back
> that up by some specific evidence or data.
>
>> > Who said it was slow _today_?  I found complaints from 2009, are you
>> > really going to claim they are still relevant, without checking out?
>> 
>> Again, why do you assume that I didn't tried?
>
> How about publishing your data, then?

Which data? That CEDET doesn't know about overloads? They are very aware
of that, as one of the maintainers acknowledged on this thread.

> Perhaps CEDET developers can do
> something with your bug reports, and then you will find a year from
> now that things did change.

Sorry, but this looks more like handwaving than real argumentation. I'm
not the one who decided to work on a Elisp-based C++ code analysis tool.
I'm the one who thinks that that enterprise has a limited range of
applicability and there are other approaches with are much more
promising. Why should I invest my time on CEDET?

[snip]

> This discussion _is_ about Emacs!  It is not about parsing C++ for any
> other purpose, or refactoring by other tools.  Of course, knowledge of
> available tools for Emacs is extremely relevant.

If the tools were available, this discussion wouldn't arise.

>> > 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.
>> 
>> A C++ source code analysis tool has no need to understand C++?
>
> Just enough to do its job, but no more.
>
> As another example, look at etags: it doesn't understand any language
> it supports, and yet it generally does a very good job in finding the
> identifiers.

It is obvious that you don't understand the problem (well, it was
obvious since the first time you suggested to implement the required
functionality on Elisp all the way down). What Etags does is absolutely
trivial compared to the required analysis for smart code completion, not
to mention refactoring.

[snip]

>> A tool that fails on some cases is defective
>
> Then you will surely call Emacs "defective", because most if its
> heuristics are not perfect.

Here you go with all-or-nothing again. I can use Emacs for hours without
facing any glitch. My experience with CEDET C++ code completion is that
failure is the most likely outcome. Worse: while using it I need to
direct my attention to checking that what CEDET suggests makes sense
(when it manages to suggest something) and that makes me less productive
even on the cases where CEDET gives the right answer.

>> "cannot" is fundamentally different from "not allowed", if you are
>> looking for the less-resistance path.
>
> Why would we be looking for the less-resistance path?  It's not like
> clang-using packages are queuing up for inclusion,

Surely they will not queue for inclusion, because they all were rejected
in advance.

> it actually sounds
> like they don't even exist yet.  A perfect time for looking elsewhere
> and finding a solution that will do its job reasonably well.

No, a solution that fits RMS decision. Not to be confused with "doing
the job well".