From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexander Adolf Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: company-eudc Date: Wed, 05 May 2021 21:47:49 +0200 Message-ID: References: <2aaed91801ff892a269a315c50064d99@condition-alpha.com> <7aa6ec1a1a879a5db7972a652b2dcfb2@condition-alpha.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30986"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 05 21:49:28 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1leNWR-0007yi-7x for ged-emacs-devel@m.gmane-mx.org; Wed, 05 May 2021 21:49:27 +0200 Original-Received: from localhost ([::1]:35058 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1leNWQ-0002WM-Aw for ged-emacs-devel@m.gmane-mx.org; Wed, 05 May 2021 15:49:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49680) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1leNV1-0001DV-Ed for emacs-devel@gnu.org; Wed, 05 May 2021 15:47:59 -0400 Original-Received: from smtprelay03.ispgateway.de ([80.67.31.30]:62991) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1leNUy-0004KB-IE for emacs-devel@gnu.org; Wed, 05 May 2021 15:47:59 -0400 Original-Received: from [46.244.216.63] (helo=condition-alpha.com) by smtprelay03.ispgateway.de with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.3) (envelope-from ) id 1leNUs-0003qK-DP; Wed, 05 May 2021 21:47:50 +0200 In-Reply-To: X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Received-SPF: pass client-ip=80.67.31.30; envelope-from=alexander.adolf@condition-alpha.com; helo=smtprelay03.ispgateway.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:268928 Archived-At: Stefan Monnier writes: >>> [...] >>> I like this functionality, but: >>> - Why not add this directly to the EUDC code in Emacs itself? >> I did propose it to the company maintainers, but it didn't fall on >> fertile ground there. > > Hmm... not sure I understand. I was proposing to add it to the EUDC > code in Emacs (e.g. `eudc.el`), not to the Company package. EUDC does not contain any adapters/back-ends for other packages. And it would have seemed odd to me, if a basic package contained code to adapt itself to another package, which builds on top of itself. >>> - Why make it a Company backend instead of a CAPF function (since >>> Company knows how to use CAPF functions as well)? >>> [...] >> That's one of the next things on my to-do list. ;-) > > I think it would make a lot of sense to add such a CAPF directly to > `eudc.el`, and then to hook it into `message.el`. Agreed; that's the plan (adding a new function to EUDC, which in turn can be added to `completion-at-point-functions`). > I must admit, I don't know where `company-eudc-expand-inline` would end > up in that scenario, tho :-( > [...] Indeed; `company-eudc-expand-inline` is to cater for the particularity of EUDC queries potentially taking very long. I have yet to research whether CAPF has a similar function to start completion with a single, specific back-end only, and which can be bound to a key. A `let` statement shadowing `completion-at-point-functions` could be a (slightly hacky though) way of achieving this. Another issue to solve (showing off my lack of knowledge of CAPF here) is providing the EUDC suggestions in suitable message header fields only. I'll need to scratch my head a bit more over these, and possibly further things, I guess. Cheers, --alexander