Re: Emacs contributions, C and Lisp

[Eli Zaretskii]

> From: Óscar Fuentes <address@hidden>
> Date: Thu, 27 Feb 2014 20:08:30 +0100
> 
> Eli Zaretskii <address@hidden> 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.

What happened to the other one?  It is still in the source.

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

Well, I disagree, and I guess we will have to leave this at that.

> Right now only Clang fits the bill

No, it doesn't, not as long as there are no decent production-quality
Emacs packages that use it.

> Are you serious?

Yes.

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

Yes!

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

See above: that it is slow.

> Sorry, but this looks more like handwaving than real argumentation.

And you didn't?

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

I hope because you want Emacs to become a better programming editor.

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

But since they aren't available, we have nothing to compare to, and so
saying that CEDET or ECB are inadequate without that feature doesn't
have any real basis.  It's just propaganda.

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

And you evidently don't understand the concept of analogy.

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

They don't exist, first and foremost.  There's nothing to reject.