Re: Emacs contributions, C and Lisp

[Dmitry Gutov]

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

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

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

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

You both might want to step back from generailzations.

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

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.

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