From: Utkarsh Singh <utkarsh190601@gmail.com>
To: Alexander Adolf <alexander.adolf@condition-alpha.com>,
Tomi Ollila <tomi.ollila@iki.fi>,
Notmuch mailing list <notmuch@notmuchmail.org>
Subject: Re: [PATCH] emacs: Add more front ends for address completion
Date: Mon, 28 Feb 2022 14:31:48 +0530 [thread overview]
Message-ID: <87wnhfjrer.fsf@gmail.com> (raw)
In-Reply-To: <115f4649ac25dff4073a32dba70e6db7@condition-alpha.com>
Hello Alexander,
On 2022-02-12, 17:09 +0100, Alexander Adolf <alexander.adolf@condition-alpha.com> wrote:
> Tomi Ollila <tomi.ollila@iki.fi> 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/
next prev parent reply other threads:[~2022-02-28 9:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 14:38 [PATCH] emacs: Add more front ends for address completion Utkarsh Singh
2022-02-09 21:59 ` Tomi Ollila
2022-02-12 16:09 ` Alexander Adolf
2022-02-21 22:20 ` emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion) Alexander Adolf
2022-02-22 22:04 ` Tomi Ollila
2022-02-28 21:19 ` Alexander Adolf
2022-03-01 17:51 ` Alexander Adolf
2022-02-28 9:01 ` Utkarsh Singh [this message]
2022-03-06 7:28 ` [PATCH] emacs: Add more front ends for address completion Utkarsh Singh
2022-03-07 22:14 ` Alexander Adolf
[not found] ` <87k0d4n8tr.fsf@gmail.com>
[not found] ` <c6c39f1b36844a9160e81f2f23cb8458@condition-alpha.com>
2022-03-09 1:06 ` Utkarsh Singh
2022-03-11 17:50 ` Alexander Adolf
2022-03-13 3:51 ` Utkarsh Singh
2022-03-15 12:37 ` Alexander Adolf
2022-03-17 4:56 ` Utkarsh Singh
2022-03-20 10:49 ` David Bremner
2022-04-06 12:19 ` Utkarsh Singh
2022-04-06 18:23 ` David Bremner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://notmuchmail.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wnhfjrer.fsf@gmail.com \
--to=utkarsh190601@gmail.com \
--cc=alexander.adolf@condition-alpha.com \
--cc=notmuch@notmuchmail.org \
--cc=tomi.ollila@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).