From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp12.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id AJVCHiqRHGIpCQEAgWs5BA (envelope-from ) for ; Mon, 28 Feb 2022 10:08:58 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp12.migadu.com with LMTPS id uGrgGiqRHGLSxwAAauVa8A (envelope-from ) for ; Mon, 28 Feb 2022 10:08:58 +0100 Received: from mail.notmuchmail.org (yantan.tethera.net [IPv6:2a01:4f9:c011:7a79::1]) (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 11C8627F24 for ; Mon, 28 Feb 2022 10:08:58 +0100 (CET) Received: from yantan.tethera.net (localhost [127.0.0.1]) by mail.notmuchmail.org (Postfix) with ESMTP id E6F355F6C9; Mon, 28 Feb 2022 08:59:54 +0000 (UTC) Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by mail.notmuchmail.org (Postfix) with ESMTPS id CA0D15F6BE for ; Mon, 28 Feb 2022 08:59:52 +0000 (UTC) Received: by mail-pf1-x434.google.com with SMTP id u16so10497027pfg.12 for ; Mon, 28 Feb 2022 00:59:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:subject:in-reply-to:references:date:message-id:mime-version; bh=5ceIx7MIyb6Uc0XlrY9cYWRTZ8ObNizHif6YOzFbWW8=; b=N+dJNuHxcsdnhIHMO6erJ4hOJ8aKre1Ff+sLP+BcHLdhb/xrCgoW8zsP5f46JNyVBx eWBvAncze6ODN/dCCxfzhMbyKAMffDv1AxNoOyndaekBoYsEOhXHJQ8QE+P2j/Pn/sGr n/CCYnynZ6Kd4J+7QC/EiGj+rm+mLt4b7K0ulhH36OgrVPW739UrRaBwrBZS4Y9oMZ2q Rh48FJWTCvoUQ2q2lKoK0HwDtLVJidSGXbvF/2sLt9a2WdCKXT934HJ9Ael6bYI7Em0O rFHS/6IFeuWWDopxyaRGu+18v5WKpzf/JOalwZbGzIgoK/WDJSLMB5FhF+9lLXsmM75V HCCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:in-reply-to:references:date :message-id:mime-version; bh=5ceIx7MIyb6Uc0XlrY9cYWRTZ8ObNizHif6YOzFbWW8=; b=69RRTqJvfjWRFfRIxXEf58kkdubUy189wN+VYs5EbzX9wTZXnV11ltkpW+9HnAIPs7 NrSWbk/acgtb4jRJmRgm8u+2Ukn0xZzLubavFVqAxB9SZe3EFiR2XA7efXF3Wf/sep4D E9QrY/3oxPqeQyLqzueMuJFiDjXQi9bo2YWGLfbWCZpZIMlSjJmQfBjHwqcbtIL4p1sW TfynVOkdDf9LlZGT7U+0eKU8FzDGyyh6ZBzs7xvXCf3iN1dZ5G6w7aKk/DTdBhkXQjiu UYhA6gK2In1yzmShDWnfnWSNTjZmhwBTRbX6ULY5Fuw89McK4oSBLSSImQdI6g+ZRrZd bW2g== X-Gm-Message-State: AOAM533Fy6ZNGLTR0VXZfXKlHipC9WyrNaaZOU+ih6knx5bvIiqoZWHz qb0U5J4t1jbORyaiYwTurf0= X-Google-Smtp-Source: ABdhPJzs6XhVlk7ywBUwLXeAWGA6wLh3nLokq7IEuz/sGyHRqfTc8Vk2mKyHU5GQ486cX7osewSPXg== X-Received: by 2002:a63:1c21:0:b0:374:104c:e4eb with SMTP id c33-20020a631c21000000b00374104ce4ebmr16323882pgc.556.1646038790909; Mon, 28 Feb 2022 00:59:50 -0800 (PST) Received: from localhost ([106.192.227.199]) by smtp.gmail.com with ESMTPSA id x3-20020a17090ad68300b001b8bcd47c35sm16731896pju.6.2022.02.28.00.59.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Feb 2022 00:59:50 -0800 (PST) From: Utkarsh Singh To: Alexander Adolf , Tomi Ollila , Notmuch mailing list Subject: Re: [PATCH] emacs: Add more front ends for address completion In-Reply-To: <115f4649ac25dff4073a32dba70e6db7@condition-alpha.com> References: <87bkzhbez9.fsf@gmail.com> <115f4649ac25dff4073a32dba70e6db7@condition-alpha.com> Date: Mon, 28 Feb 2022 14:31:48 +0530 Message-ID: <87wnhfjrer.fsf@gmail.com> MIME-Version: 1.0 Message-ID-Hash: XIGLKLEASRGIKWJVH6DLOKFXFHNBNG2L X-Message-ID-Hash: XIGLKLEASRGIKWJVH6DLOKFXFHNBNG2L X-MailFrom: utkarsh190601@gmail.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-notmuch.notmuchmail.org-0 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=1646039338; 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:dkim-signature; bh=FQf74upyZHRsuMCXRSlkY4Pm5URVcTxYUYQYJYDRAx4=; b=IQm6F01vHjHWp/CM7gpEMljV8Ig9doYDFb/fbMnB+9aU+PEt+4NKcPmsfDutRpHf7XDHSt yFzscwCehmzZPFYibwGNNfLBzgHVeUUv50Drqq46RzF5XEHbSqXRd6e8lteC4O47VRIifx 7+0YG+ov9+hUyv0wpsyMPEfqQ8oi8pkVEa3Mrp3HpKtKs/HL4wOWcwuLScV+g2t5kDtfsX sH6kCSB2iRBIsCNi311Y46VZOuyT7O4Bkk4xGrNK6KXVoCMQaKUblpX6AXenX5ZDYkbaY4 w/8mXl+3evX5cFDyqvzLBEzXAJ+Xklq8JQdYiAH3J9zUWCxKrmzFu716vssAnQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1646039338; a=rsa-sha256; cv=none; b=tjUGQRARe0rV2aBm5P8vqSKtuEVaSUiG8SVInhUpXICPFucq0zHaXjf+ChXMaTDxbCEVWb GIFkezU3qB7pjUYGjz27GBvinc85F5IXX0XlgjcZMdUnlVECN99Buw1H/QFdrdaHr4KZHZ tZpuKNHebEq/bO40E7fEUpt2IPs81j5rlyAu4jpa97HQosRY/gfU4Fpjv0H66fEVHLKele ANaE1b8E/PZfEhBRsMmUZVf6Z/uXU86dvs6ES6uJjXa4kgaCtOLUbtVJWFc2nZolNSq9Pn EVuPAR7qyOQLIrJPVvkzWJTmy2Lyba5kQdziemVgy7kRbibRaVVwDnrlOo2pHw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=gmail.com header.s=20210112 header.b=N+dJNuHx; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 2a01:4f9:c011:7a79::1 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Spam-Score: 6.16 Authentication-Results: aspmx1.migadu.com; dkim=fail ("body hash did not verify") header.d=gmail.com header.s=20210112 header.b=N+dJNuHx; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 2a01:4f9:c011:7a79::1 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Migadu-Queue-Id: 11C8627F24 X-Spam-Score: 6.16 X-Migadu-Scanner: scn0.migadu.com X-TUID: 1Q7ZLdo0fdFO Hello Alexander, On 2022-02-12, 17:09 +0100, Alexander Adolf wrote: > 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. First of all, apologies for the late reply and thank you for your interest. Currently I'm trying to prepare a patch which will remove all Company specific calls with standard Emacs API. For now, evaluate the following expression to review the user-side changes: (progn (add-to-list 'load-path "/usr/share/emacs/site-lisp") (require 'notmuch) (defun notmuch-address-expand-name () (let* ((end (point)) (beg (save-excursion (re-search-backward "\\(\\`\\|[\n:,]\\)[ \t]*") (goto-char (match-end 0)) (point))) (orig (buffer-substring-no-properties beg end)) (completion-ignore-case t) (options (with-temp-message "Looking for completion candidates..." (notmuch-address-options orig)))) (list beg end options))) (notmuch-mua-new-mail)) -- Utkarsh Singh https://utkarshsingh.xyz/