[Top][All Lists]

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

Re: Contributing LLVM.org patches to gud.el

From: David Kastrup
Subject: Re: Contributing LLVM.org patches to gud.el
Date: Tue, 10 Feb 2015 17:41:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: David Kastrup <address@hidden>

>> As far as I remember, company-mode had working code for LLVM-based
>> completion.
> So?  It's working code, isn't it?  Anyone can use it, can't they?

The difference between a package being in ELPA and having to be
installed manually significantly changes its adoption and audience.

>> And we are currently just seeing a veto on integration of
>> working initial LLDB support into gud.el.
> Maybe I need new glasses, but I see no veto.

Maybe you need new glasses.

> A request to hold on is not a veto.

It's not a _final_ veto.  But it is vetoing inclusion for now.

> And, FWIW, from my POV supporting LLDB is not an important issue,
> certainly nowhere as important as making Emacs more like modern IDEs.

Uh, there is a connection.  Because modern IDEs tend to have useful
program information when debugging instead of (optimized out).

> When LLDB gets anywhere near GDB in functionality and usability, let
> alone surpasses it, maybe then I might get interested.

Seems you missed where people stated that its willingness to talk about
values that can only be deduced by cooperation with the compiler was
making a crucial difference in usability over gdb.

At any rate, you seem to be _totally_ on the other side of Richard on
this one.  You want to start thinking about LLDB when it is getting more
useful than GDB, he wants to stop people from thinking about LLDB when
it is getting more useful than GDB.

> For now, it's a niche debugger, not unlike dbx.  Why should we care so
> much if LLDB support will land today, next week, or next year?  We
> shouldn't burn so much energy on even discussing it.

Well, GNU does not turn on a dime.  So there is nothing wrong with
thinking ahead.

>> > Free Software is about freedom of developers as well.
>> Not at its core.
> Yes, at its core: the freedom to change the code requires a developer
> who can actually do that.


You'll find that wherever conflicts of interest between users and
programmers are considered, Richard puts the users' interests first.

David Kastrup

reply via email to

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