From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: company-eudc Date: Wed, 05 May 2021 16:36:03 -0400 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="37402"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alexander Adolf Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 05 22:40:42 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 1leOK2-0009dg-Br for ged-emacs-devel@m.gmane-mx.org; Wed, 05 May 2021 22:40:42 +0200 Original-Received: from localhost ([::1]:40506 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1leOK1-0002Rs-Ej for ged-emacs-devel@m.gmane-mx.org; Wed, 05 May 2021 16:40:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60120) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1leOFk-00085o-0R for emacs-devel@gnu.org; Wed, 05 May 2021 16:36:16 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57891) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1leOFd-0000AN-8u for emacs-devel@gnu.org; Wed, 05 May 2021 16:36:15 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AE1E91001FB; Wed, 5 May 2021 16:36:06 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0571A10019F; Wed, 5 May 2021 16:36:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1620246965; bh=O2lGZmz1aNWP4HdL1Z5IXUFjM8CX7n8TS3ATaTaZdx8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=aDuIVSUZPY9SMo5atTt+R/4AVV7/Cc7VaKfuVhBIJ2YsewFelSfim/Yu4uARikA9Y oXD+883j27CJPfRuzjSEPLQwX9Rfo3c+k/B62T4cf2Wa1K6an2BTjPtfDOqBeERrR/ juIFStXUGRJitFDx9zI9w9IULVF7chD62DFZk9PQqH7Hl3Tuz0Bi6Nmq6gG0vODxvn V1kY6tHs9GEW3GnvF49x431EprpI1tEd349aK81j9AOv5r7QV42ylD9kp40CQxjJyv i0GxQxxtr+V6njb7wQdyEVq6rITBNoa46GwL7o0WYUfz/Oh9+UBeD5QS8BTrvAn3GT 0K5C0tQQAD30w== Original-Received: from alfajor (76-10-140-76.dsl.teksavvy.com [76.10.140.76]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BFF33120319; Wed, 5 May 2021 16:36:04 -0400 (EDT) In-Reply-To: (Alexander Adolf's message of "Wed, 05 May 2021 21:47:49 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=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:268932 Archived-At: > 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. The "completion backends" used to be distributed with the Company package, because that's what you need to do to get things started, but fundamentally Company is a piece of infrastructure, and every backend belongs with the package for which it provides completions rather than with Company. >>>> - 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`). See below for a 100% untested first step. >> 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. CAPF is only a backend, whereas "start completion" presumes a command and that would inevitably be part of the UI. > A `let` statement shadowing `completion-at-point-functions` could be > a (slightly hacky though) way of achieving this. Yes, that would be the natural way to do that, but the question is what to put within this let-binding: you can either call `company-begin-backend` or `completion-at-point`, or `corfu-`, or `auto-complete-`, depending on the favorite UI of this user. > 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 think the patch below shows how this is done (I don't have an EUDC setup here to test the code, sorry). Should we add the company-specific code for now in `eudc.el` and then work to replace it with a CAPF backend (bringing it to feature-parity with the Company code will probably take some time and potentially changes elsewhere, which is why I suggest to install the Company code now even though the intention is to make it redundant). Stefan diff --git a/company-eudc.el b/company-eudc.el index 52dd21ce08..f89626225c 100644 --- a/company-eudc.el +++ b/company-eudc.el @@ -102,6 +102,36 @@ For the semantics of COMMAND, ARG, and IGNORED see `company-backends'." (`sorted t) (`ignore-case t))) +(defvar eudc-completion-table + ;; FIXME: This belongs in `eudc.el'. + (completion-table-dynamic + (lambda (prefix) + ;; FIXME: completion tables can only do "prefix completion" so the + ;; `split-string' below won't give the intended result. + ;; The intended behavior is normally instead provided by + ;; a `completion-style' such as `orderless' which would call this + ;; completion tables several times (once per "word"). + ;; A possible other solution is to use the "backend" (aka "passthrough") + ;; completion style which lets the completion table provide its own + ;; completion style. + (eudc-query-with-words (split-string prefix "[ \t]+"))))) + +(defun message-eudc-capf () + ;; FIXME: This belongs in `message.el' and is probably redundant there + ;; because there's already code doing that for other + ;; completion tables (bbdb, ecomplete, ...). + (let ((end (point)) + (start (save-excursion + (if (re-search-backward "\\([:,]\\|^\\)[ \t]*" + (point-at-bol) 'move) + (goto-char (match-end 0))) + (point)))) + (when (let ((case-fold-search t)) + (looking-back + "^\\([^ :]*-\\)?\\(To\\|B?Cc\\|From\\|Reply-to\\):.*? *\\([^,;]*\\)" + (line-beginning-position))) + (list start end eudc-completion-table)))) + ;;;###autoload (defun company-eudc-activate-autocomplete () "Provide `company-eudc' completions under company mode control.