From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp10.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id iEhMHz8CCGIuHwAAgWs5BA (envelope-from ) for ; Sat, 12 Feb 2022 19:53:51 +0100 Received: from aspmx1.migadu.com ([2001:41d0:2:bcc0::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp10.migadu.com with LMTPS id WIzvFz8CCGKBpwAAG6o9tA (envelope-from ) for ; Sat, 12 Feb 2022 19:53:51 +0100 Received: from mail.notmuchmail.org (yantan.tethera.net [135.181.149.255]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id AE96E389CF for ; Sat, 12 Feb 2022 19:53:50 +0100 (CET) Received: from yantan.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id E78EC5F702; Sat, 12 Feb 2022 18:53:46 +0000 (UTC) X-Greylist: delayed 9830 seconds by postgrey-1.36 at yantan; Sat, 12 Feb 2022 18:53:44 UTC Received: from smtprelay07.ispgateway.de (smtprelay07.ispgateway.de [134.119.228.97]) by mail.notmuchmail.org (Postfix) with ESMTPS id BE0C65F6C3 for ; Sat, 12 Feb 2022 18:53:44 +0000 (UTC) Received: from [46.244.203.178] (helo=condition-alpha.com) by smtprelay07.ispgateway.de with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1nIuy8-0002xu-JK; Sat, 12 Feb 2022 17:09:52 +0100 Message-Id: <115f4649ac25dff4073a32dba70e6db7@condition-alpha.com> From: Alexander Adolf To: Tomi Ollila , Utkarsh Singh , Notmuch mailing list Subject: Re: [PATCH] emacs: Add more front ends for address completion In-Reply-To: References: <87bkzhbez9.fsf@gmail.com> Date: Sat, 12 Feb 2022 17:09:52 +0100 MIME-Version: 1.0 X-Df-Sender: YWxleGFuZGVyLmFkb2xmQGNvbmRpdGlvbi1hbHBoYS5jb20= Message-ID-Hash: F7JFF5GCKA22XMCFAB36ES7RSTPEA4J3 X-Message-ID-Hash: F7JFF5GCKA22XMCFAB36ES7RSTPEA4J3 X-MailFrom: alexander.adolf@condition-alpha.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.3 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_IN X-Migadu-Country: DE ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1644692030; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=feEzVBLev34iFMLenaqS52M8G75vb6aM+VeZa/DUwB0=; b=Pt1n0QYpjJkEdGqOlUH6HQS1OSjqOjUICVd0bbEFw0ZRfE5DUWsJkN0SoISkvszIYOt5QB ldzW5P4kUjwm7SFsqYSLfFl+pU1vYYQwQo5j+It7IxzycJoIa/+20qpfSk+vMvrAiCcIdn qmvRLp7A4aAWxVF790SfSbHicn1lKU9TAhsIF6lwQqeK9ClmF8IeQy7G+Fg2UFR5Ca3l72 NBbGBn/cDVuICsl5Em2CNXHiOolZiWzc7sEG/n+uer9iPoXRxUUZA+zGFwhvWftSTWgzQ2 rg7MSm5AcT89FOt1gkvv7zqMAnspqGWR5OZRDrIETJH464ZT+hKivN40Pk8o7w== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1644692030; a=rsa-sha256; cv=none; b=gE3TJMur7Hw9k2gKz4dnYQXwXnVetBo8VjX/ZZ/A69KKW0scY3jG8ptUmog6HwEYlbnpCo R3bgI2QOOfeBLPrTF2zNoOVHHJHXj1DyFJ2AzeDux+dU606Or8Cpn2q35mjlnZrIRlCbas EL+nCv/4dCgSeN3tO4+XwfnQyadP3tuEzZ61dKnxpvdBm5MZxy2V/YwO9H2yTUXOvlbK0w g159UBsHnjC9w8piE/bAQvYxu+2X/PezIc4FFp4Vuv18lV6sG/qPyD8dTmeVxw72JOyta0 9mm0+vidxpdnaA3b9ArK6ZOCwyCoCpgX4lVFCNpdkRBbLlVXe9wO2S6cJ+0a8A== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 135.181.149.255 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Spam-Score: -3.34 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 135.181.149.255 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: AE96E389CF X-Spam-Score: -3.34 X-Migadu-Scanner: scn0.migadu.com X-TUID: I9RCW797PAEr Tomi Ollila writes: > On Tue, Feb 08 2022, Utkarsh Singh wrote: > >> [...] >> Corfu enhances the default completion in region function with a >> completion overlay. The current candidates are shown in a popup >> below or above the point. Corfu is the minimalistic >> ~completion-in-region~ counterpart of the >> [[https://github.com/minad/vertico][Vertico]] minibuffer UI. >> [...] I, too, have been intrigued by this package, and am currently exploring it with an eye to replacing the company package for me. I have hit the same wall with email address completion in (notmuch) message buffers as the OP. I think there could be a wider question lurking here: apart from supporting those completion systems that the developers use, what could be a reasonable, overall strategy towards handling completion? A loosely related case could be indicative: my humble self has written a new company back-end for EUDC (Emacs Universal Directory Client), so that email addresses from LDAP servers could be offered as completion candidates by email clients such as e.g. notmuch. I proposed it to the company authors. Their response was that they (trying to word it diplomatic here...) would discourage adding any further backends to company. Instead, any new completion sources should hook themselves into completion-at-point-functions, which in turn can be used as a source for candidates by company. In fact, if they re-started company today, they would do things completely differently; they'd create a pure UI front-end, and use completion-at-point-functions as the one and only source; so they said. Sounds a lot like corfu, doesn't it? The completion topic tends to come up on emacs-devel in certain intervals, too. Also there, the same complexity complaints are raised against existing completion systems, and the number of fingers pointing at completion-at-point-functions seems growing. Ok, not surprising, given that it's emacs-devel; but still. Hence, from my personal point of view, moving _all_ completion to go through completion-at-point-functions seems the only reasonable way forward. That would remove any special cases for when company is available from the elisp. Fewer third-party integrations, fewer headaches. I don't think we would loose any functionality, as company can obtain candidates from completion-at-point-functions. I.e. users could continue to use company w/o losing any functionality. Also, there is a sister package to corfu, which is called cape; which is from the same author. It allows you to wrap company back-ends so they can be used in completion-at-point-functions. This seems a decisive tool for the migration to completion-at-point-functions, as it allows users to re-purpose existing company back-ends, until their authors will have migrated them to completion-at-point-functions. Cheers, --alexander