From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: enabling company-capf support in cfengine.el Date: Sun, 19 Jan 2014 15:19:42 -0500 Message-ID: References: <87fvqtg02v.fsf@flea.lifelogs.com> <87y53ghe94.fsf@flea.lifelogs.com> <87vbyk3497.fsf@yandex.ru> <87haa4gw69.fsf@flea.lifelogs.com> <87txe4usm1.fsf@yandex.ru> <87zjnvg2t2.fsf@flea.lifelogs.com> <87txe364q0.fsf@yandex.ru> <87r497fu0h.fsf@flea.lifelogs.com> <87haa1litl.fsf@yandex.ru> <87y53czx7e.fsf@yandex.ru> <87bo08bivm.fsf_-_@flea.lifelogs.com> <87sitkzahs.fsf@yandex.ru> <52D7DAAB.2070709@yandex.ru> <52D81960.2080408@yandex.ru> <52DA8C17.4080707@yandex.ru> <52DC00E5.3020803@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390162803 31380 80.91.229.3 (19 Jan 2014 20:20:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 20:20:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 19 21:20:09 2014 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 1W4yqh-0003d2-HC for ged-emacs-devel@m.gmane.org; Sun, 19 Jan 2014 21:20:03 +0100 Original-Received: from localhost ([::1]:47532 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4yqe-0008Il-P9 for ged-emacs-devel@m.gmane.org; Sun, 19 Jan 2014 15:20:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49126) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4yqV-0008C8-4I for emacs-devel@gnu.org; Sun, 19 Jan 2014 15:19:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W4yqN-0006vZ-Qp for emacs-devel@gnu.org; Sun, 19 Jan 2014 15:19:51 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:50133) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4yqN-0006vS-NE for emacs-devel@gnu.org; Sun, 19 Jan 2014 15:19:43 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFFFxKGP/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDiGGcGYFegxU X-IPAS-Result: Av4EABK/CFFFxKGP/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDiYSFBgNJIgeBsEtkQoDiGGcGYFegxU X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="45329198" Original-Received: from 69-196-161-143.dsl.teksavvy.com (HELO pastel.home) ([69.196.161.143]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 19 Jan 2014 15:19:42 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 5F69D6026D; Sun, 19 Jan 2014 15:19:42 -0500 (EST) In-Reply-To: <52DC00E5.3020803@yandex.ru> (Dmitry Gutov's message of "Sun, 19 Jan 2014 18:44:21 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:168750 Archived-At: > Sometime ago I've been told that RMS dislikes Clang strongly enough to > oppose inclusion of any code using it in Emacs. AFAIK Clang is Free Software. So, I don't see a valid reason to reject inclusion of company-clang or equivalent into Emacs. If it's in GNU ELPA it's (virtually) in Emacs already anyway (we use the same rules for the two, specifically so we can easily move code from one to the other). > Unless it has changed (or is no longer a major factor), separating the code > from Company won't be particularly valuable. My interest is in making Company into nothing more than an alternative UI. All the backends would be separate and usable as much by Company as by completion-at-point. Most of it (UI and backends) should also get integrated into Emacs. > Clang specifically? That's why I suggested another minor mode. Yes, ultimately clang-completion should be a separate package enabled separately. In any case I don't think any of those issues are serious enough to be a reason not to make the clang backend work via CAPF. >> But moving it to CAPF means that it becomes useful/usable not only for >> Company for also for good ol' competion-at-point. > Would a Company user benefit from this, really? Wrong question: the benefit would be for non-Company users. > As long as (add-hook 'completion-at-point-function 'company-capf-clang) is > only done when company-mode is enabled, there's really not much benefit. Indeed, that's why it should also be done/doable when Company is not being used. Stefan