From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Contributing LLVM.org patches to gud.el Date: Tue, 10 Feb 2015 17:41:25 +0100 Message-ID: <874mqtsoqy.fsf@fencepost.gnu.org> References: <87mw4rxkzv.fsf@fencepost.gnu.org> <87y4oavxcy.fsf@fencepost.gnu.org> <87d25juy8m.fsf@fencepost.gnu.org> <83iofa8lu2.fsf@gnu.org> <87wq3qrvjz.fsf@fencepost.gnu.org> <83386d92ox.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1423586551 4525 80.91.229.3 (10 Feb 2015 16:42:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Feb 2015 16:42:31 +0000 (UTC) Cc: eller.helmut@gmail.com, monnier@iro.umontreal.ca, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 10 17:42:29 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YLDtL-0006mK-D4 for ged-emacs-devel@m.gmane.org; Tue, 10 Feb 2015 17:42:27 +0100 Original-Received: from localhost ([::1]:40639 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLDtK-0005Se-Sv for ged-emacs-devel@m.gmane.org; Tue, 10 Feb 2015 11:42:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39293) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLDsX-0004pk-R8 for emacs-devel@gnu.org; Tue, 10 Feb 2015 11:41:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLDsT-000194-A3 for emacs-devel@gnu.org; Tue, 10 Feb 2015 11:41:37 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:60011) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLDsT-00018y-7l for emacs-devel@gnu.org; Tue, 10 Feb 2015 11:41:33 -0500 Original-Received: from localhost ([127.0.0.1]:38947 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLDsM-0001b8-98; Tue, 10 Feb 2015 11:41:26 -0500 Original-Received: by lola (Postfix, from userid 1000) id BF6B7E0514; Tue, 10 Feb 2015 17:41:25 +0100 (CET) In-Reply-To: <83386d92ox.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 10 Feb 2015 18:00:30 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:182819 Archived-At: Eli Zaretskii writes: >> From: David Kastrup >> 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