Hello Alexander, On 2022-02-12, 17:09 +0100, Alexander Adolf <alexander.ad...@condition-alpha.com> wrote:
> Tomi Ollila <tomi.oll...@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/ _______________________________________________ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
