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: Sat, 18 Jan 2014 21:37:31 -0500 Message-ID: References: <87fvqtg02v.fsf@flea.lifelogs.com> <87eh58j0x3.fsf@flea.lifelogs.com> <878uvg4ul2.fsf@yandex.ru> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1390099065 5232 80.91.229.3 (19 Jan 2014 02:37:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 02:37:45 +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 03:37:51 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 1W4iGk-0001gx-Ik for ged-emacs-devel@m.gmane.org; Sun, 19 Jan 2014 03:37:50 +0100 Original-Received: from localhost ([::1]:44928 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4iGk-0006TW-2I for ged-emacs-devel@m.gmane.org; Sat, 18 Jan 2014 21:37:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53777) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4iGZ-0006Sp-Nb for emacs-devel@gnu.org; Sat, 18 Jan 2014 21:37:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W4iGS-00010l-DT for emacs-devel@gnu.org; Sat, 18 Jan 2014 21:37:39 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:11379) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W4iGS-00010a-9Q for emacs-devel@gnu.org; Sat, 18 Jan 2014 21:37:32 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFMCplR/2dsb2JhbABEvw4Xc4IeAQEEAScvIwULCw4mEhQYDSQuh3AGwS2RCgOIYZwZgV6DFQ X-IPAS-Result: Av8EABK/CFFMCplR/2dsb2JhbABEvw4Xc4IeAQEEAScvIwULCw4mEhQYDSQuh3AGwS2RCgOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="45287920" Original-Received: from 76-10-153-81.dsl.teksavvy.com (HELO pastel.home) ([76.10.153.81]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 18 Jan 2014 21:37:31 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 6D2C0603BA; Sat, 18 Jan 2014 21:37:31 -0500 (EST) In-Reply-To: <52DA8C17.4080707@yandex.ru> (Dmitry Gutov's message of "Sat, 18 Jan 2014 16:13:43 +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:168712 Archived-At: >> Whenever you bump into such problems, do report them. I'll take a look >> at the above two. > Thank you. Another one that I've noticed is `message-completion-function'. OK. Could you make a bug report listing these (3 so far) problematic functions, and explaining (as much as you can remember) what kind of problem they cause? [ Don't waste too much time trying to remember what problem they cause: if you remember, great, but if not, it might be obvious when I look at it anyway. ] That will help me not forget. > Note the option of returning `t', it doesn't fit the proposed name > (-prefix-length). Ah, I see in the rest of your answer than this is all about "not waiting". So, yes, the name should rather be :company-immediate or something like that. It could also be "integer or t". And indeed, the integer case is probably not needed. > So yes, a new property might be appropriate, but with different semantics. Right. >> From a more CAPF-centric point of view, in the case of Semantic, another >> option is to return as prefix not "ch" but "fr->ch", and then specify >> a boundary between "fr->" and "ch". > Maybe. But the notion of completion boundaries is unrelated to idle > completion, and the latter is the sole purpose of that return value. Indeed, sorry. I had not understood the purpose. Apparently the docstring's reference to `company-minimum-prefix-length' wasn't sufficient for me to figure it out ;-) >> That's easy to solve: turn company-clang into its CAPF equivalent, then >> place it within completion-at-point-functions after the Semantic one. > Which body of code would contain that clang-completion-function, and perform > the adding? How 'bout company-clang.el at first? Could later be renamed to capf-clang.el, or cc-clang.el, or ... ? > Would that hook addition be global, Since company-clang is added globally to company-backends, yes, I'd expect company-capf-clang to be added to the global part of completion-at-point-functions as well. > forcing clang-completion-function to include a major-mode check > (hitherto unseen behavior in CAPF functions, AFAIK), Don't know if it's already seen or not, but I don't see why it'd be a problem. > Anyway, as I see it, none of the options would provide a smooth transition > from company-clang being included in company-backends. The users will have > to install a package, enable a minor mode, or do something equivalent. I really don't see why it's hard: - change company-clang.el so that it supports the "CAPF protocol" rather than the "company-backend protocol". - actually make it support both protocols (with the help of company-capf to translate from the CAPF protocol to the other). - in company.el (add-hook 'completion-at-point-function 'company-capf-clang) and add company-clang to company-backends if Emacs is too old to use company-capf. > Guess a simpler solution would be to keep company-clang as-is, but move it > behind company-capf. But moving it to CAPF means that it becomes useful/usable not only for Company for also for good ol' competion-at-point. Stefan