[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs contributions, C and Lisp

From: Eli Zaretskii
Subject: Re: Emacs contributions, C and Lisp
Date: Thu, 27 Feb 2014 22:23:18 +0200

> From: Dmitry Gutov <address@hidden>
> Cc: Óscar Fuentes <address@hidden>,  address@hidden
> Date: Thu, 27 Feb 2014 21:06:32 +0200
> Eli Zaretskii <address@hidden> writes:
> >> > 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.
> It shows only 'bar' to me (and another, broken option, which probably
> means the package I tried - company-clang - doesn't handle the output
> well enough).

That's what I saw, yes.

> I believe it's the correct result, though. 'char' is the more specific
> overload, so the compiler should choose it.

??? Are you saying that the one shown as completion without that
additional line was incorrect?  If it was correct then, it is still
correct after the addition, surely.

> > How many Emacs completion packages that use clang did you try? There's
> > only one that I could find
> You certainly haven't tried hard. I personally gave you links to several
> in this very thread.

Not for C++, AFAICT.

> The statement about a "defective refactoring tool" is one most
> developers would agree.

"Most" as in 2?

> A good refactoring tool is one you can apply to a large codebase and
> then calmly sleep at night without hand-checking every transformation
> that it did.

Where did you find good refactoring tools for C++?

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

Yeah, right.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]