Re: Emacs contributions, C and Lisp

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Wed, 26 Feb 2014 23:34:53 +0100
> 
> 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.  IMO, showing more candidates than strictly
necessary is a lesser evil than showing less than necessary.

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

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

> >> > ECB also supports mart completion.
> >> 
> >> For C++? Not really.
> >
> > How do you know?  When did you last try?
> 
> A few hours ago, as described on this very same sub-thread. See above,
> you can see a test case where it fails and you discussed it. Apart from
> that, I try it every year or so. What makes you think that I'm talking
> about CEDET without having experience with it?

I didn't think that, I just asked a question when did you try last.
This kind of stuff needs to be checked frequently, otherwise the
information becomes stale and thus misleading.

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

> > 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?  Perhaps CEDET developers can do
something with your bug reports, and then you will find a year from
now that things did change.

> IIRC last time I seriously tried CEDET (a year ago) it was fast enough
> (although it missed/confused most symbols) on my projects, which are on
> the tens of thousands of lines (whithout external libraries). There was
> a perceivable lag on each completion request while working on a
> destktop-class machine. Other C++ projects which I tinker with are two
> orders of magnitude larger than that.

A year ago my machine was 4 times slower than what I have on my
desktop now.

> >> > 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.
> 
> What are you talking about? What relevance has on this discussion my
> knowledge of available tools for Emacs?

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.

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

> >> > Only if you need to be 110% accurate,
> >> 
> >> Since 100% is perfect, why should I wish more? ;-)
> >
> > I don't know, you tell me.
> 
> I detect a tendency to hyperbole and all-or-nothing argumentation on
> your messages. In this case, my emphasis on accurate results is
> represented by you as a 110% requirement. This is not constructive.

I agree it is not constructive to raise the bar too high.  But isn't
that what you are doing in this thread?  Why not start with some
moderate requirements, and then move forward?  Not everyone works on
projects in hundreds of thousands of lines of code.

> >> 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?
> 
> A tool that fails on some cases is defective

Then you will surely call Emacs "defective", because most if its
heuristics are not perfect.

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