Re: [PATCH] emacs: Add more front ends for address completion
Utkarsh Singh writes: >> >> Can you be more precise about what you are asking / proposing here? >> Assume I only skimmed the thread. > > Currently, notmuch-address.el, the library used to generate completion > candidates for recipient's addresses in Notmuch's message compostion > mode uses non-standard Emacs API's for in-buffer completion, namely > completing-read and Company. Now these API's makes it difficult to > utilize alternative in-buffer completion UI such as Corfu(1). #'completing-read is of course standard since forever. We might be using it in some strange way, or it might be superceded by better things, but completing-read is not non-standard. > > These are the proposed solutions for the given problem: > > 1. Add completion-at-point to the existing sets of frontend. As noted > by Tomi, this is a "messy" solution as it unnecessarily obfuscate the > user options `notmuch-address-selection-function' and > `notmuch-address-command'. > > 2. Make notmuch-address.el itself a backend for EUDC(2). As stated by > Alexander, this will not only remove any frontend related code from > notmuch-address.el, but will also unify completion condidates for other > sources such as BBDB, LDAP, MacOS Contacts, etc. > As a reviewer / release manager, I care about the amount of code changes. As a user I hope my existing setup will keep working with no, or (less good) minimal changes. Other than that I am open to ideas. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Add more front ends for address completion
Hello David, First of all, apologies for the late reply. It would have been much better if Alexander could himself purposed the solution he is developing. On 2022-03-20, 07:49 -0300, David Bremner wrote: > Utkarsh Singh writes: > >> Thank you for working on this issue. But from now, its up to Notmuch >> maintainers to decide whether or not they want any improvements in >> `notmuch-address.el'. > > Can you be more precise about what you are asking / proposing here? > Assume I only skimmed the thread. Currently, notmuch-address.el, the library used to generate completion candidates for recipient's addresses in Notmuch's message compostion mode uses non-standard Emacs API's for in-buffer completion, namely completing-read and Company. Now these API's makes it difficult to utilize alternative in-buffer completion UI such as Corfu(1). These are the proposed solutions for the given problem: 1. Add completion-at-point to the existing sets of frontend. As noted by Tomi, this is a "messy" solution as it unnecessarily obfuscate the user options `notmuch-address-selection-function' and `notmuch-address-command'. 2. Make notmuch-address.el itself a backend for EUDC(2). As stated by Alexander, this will not only remove any frontend related code from notmuch-address.el, but will also unify completion condidates for other sources such as BBDB, LDAP, MacOS Contacts, etc. Thank you, Utkarsh Singh [1]: https://github.com/minad/vertico [2]: https://www.gnu.org/software/emacs/manual/html_mono/eudc.html -- Utkarsh Singh https://utkarshsingh.xyz/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Add more front ends for address completion
Utkarsh Singh writes: > Thank you for working on this issue. But from now, its up to Notmuch > maintainers to decide whether or not they want any improvements in > `notmuch-address.el'. Can you be more precise about what you are asking / proposing here? Assume I only skimmed the thread. d ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Add more front ends for address completion
On 2022-03-15, 13:37 +0100, Alexander Adolf wrote: > Utkarsh Singh writes: > >> [...] `post-completion': Called after a completion candidate has been inserted into the buffer. The second argument is the candidate. Can be used to modify it, e.g. to expand a snippet. [...] >>> >>> Hm, that sounds like it would functionally be similar to specifying an >>> :exit-function property in completion-extra-properties? >> >> Great! We can definitely work with this. >> [...] > > I'm glad to learn we might be heading in the same direction. AFAIR you > spoke about removing company from notmuch-address.el altogether? That > would be by impetus, too. > > EUDC [1], which is part of core Emacs, has just been given the ability > to combine search results from several sources [2]. > > [1] https://www.gnu.org/software/emacs/manual/html_mono/eudc.html > [2] > https://github.com/emacs-mirror/emacs/commit/0470a4a939772c4bd25123b15f5eadab41f8bee5 > > I have written experimental code to make EUDC contribute to > completion-at-point, and to make notmuch-address contribute to EUDC > search results. This works in principle, and I get combined search > results from notmuch-address, and the macOS Contacts app in a corfu > pop-over UI in header fields of message-mode. It seems you were looking > for something similar? Honestly, I didn't knew about EUDC, but it looks promising. > With this kind of setup, the overall architecture for email address > completion could be like this: > > notmuch-address \ >BBDB | >LDAP > --> EUDC --+ > macOS Contacts | | > ... / V >| > +--<-+ > | > V / completing-read > | | corfu > + --> completion-at-point -->| ... > \ > > This would remove any user interface related code from > notmuch-address.el, an instead convert it into a back-end for EUDC. > > Looking forward to your thoughts, Thank you for working on this issue. But from now, its up to Notmuch maintainers to decide whether or not they want any improvements in `notmuch-address.el'. -- Utkarsh Singh https://utkarshsingh.xyz/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Add more front ends for address completion
Utkarsh Singh writes: > [...] >>> `post-completion': Called after a completion candidate has been >>> inserted >>> into the buffer. The second argument is the candidate. Can be used to >>> modify it, e.g. to expand a snippet. >>> [...] >> >> Hm, that sounds like it would functionally be similar to specifying an >> :exit-function property in completion-extra-properties? > > Great! We can definitely work with this. > [...] I'm glad to learn we might be heading in the same direction. AFAIR you spoke about removing company from notmuch-address.el altogether? That would be by impetus, too. EUDC [1], which is part of core Emacs, has just been given the ability to combine search results from several sources [2]. [1] https://www.gnu.org/software/emacs/manual/html_mono/eudc.html [2] https://github.com/emacs-mirror/emacs/commit/0470a4a939772c4bd25123b15f5eadab41f8bee5 I have written experimental code to make EUDC contribute to completion-at-point, and to make notmuch-address contribute to EUDC search results. This works in principle, and I get combined search results from notmuch-address, and the macOS Contacts app in a corfu pop-over UI in header fields of message-mode. It seems you were looking for something similar? With this kind of setup, the overall architecture for email address completion could be like this: notmuch-address \ BBDB | LDAP > --> EUDC --+ macOS Contacts | | ... / V | +--<-+ | V / completing-read | | corfu + --> completion-at-point -->
Re: [PATCH] emacs: Add more front ends for address completion
On 2022-03-11, 18:50 +0100, Alexander Adolf wrote: > Utkarsh Singh writes: > >> On 2022-03-08, 16:29 +0100, Alexander Adolf >> wrote: >> >>> Utkarsh Singh writes: >>> [...] `notmuch-address-post-completion-functions'. [...] >>> [...] >> Although its a general customization option, here its documentation from >> company.el: >> >> `post-completion': Called after a completion candidate has been inserted >> into the buffer. The second argument is the candidate. Can be used to >> modify it, e.g. to expand a snippet. >> [...] > > Hm, that sounds like it would functionally be similar to specifying an > :exit-function property in completion-extra-properties? Great! We can definitely work with this. > And what could be a use-case for this? Honestly, I don't have a use-case. But the goal here is to use standard Emacs API with least amout of incompatible changes. -- Utkarsh Singh https://utkarshsingh.xyz/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Add more front ends for address completion
Utkarsh Singh writes: > On 2022-03-08, 16:29 +0100, Alexander Adolf > wrote: > >> Utkarsh Singh writes: >> >>> [...] >>> `notmuch-address-post-completion-functions'. >>> [...] >> [...] > Although its a general customization option, here its documentation from > company.el: > > `post-completion': Called after a completion candidate has been inserted > into the buffer. The second argument is the candidate. Can be used to > modify it, e.g. to expand a snippet. > [...] Hm, that sounds like it would functionally be similar to specifying an :exit-function property in completion-extra-properties? And what could be a use-case for this? Many thanks in advance and cheers, --alexander ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Add more front ends for address completion
On 2022-03-08, 16:29 +0100, Alexander Adolf wrote: > Utkarsh Singh writes: > >> [...] >> `notmuch-address-post-completion-functions'. >> [...] > > Showing off my lack of understanding: What are they for, and why do we > need to run something _after_ completion appears to have already > happened? Would we still need them if company were removed from > notmuch-address altogether? Although its a general customization option, here its documentation from company.el: `post-completion': Called after a completion candidate has been inserted into the buffer. The second argument is the candidate. Can be used to modify it, e.g. to expand a snippet. -- Utkarsh Singh https://utkarshsingh.xyz/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Add more front ends for address completion
Utkarsh Singh writes: > [...] > I don't think its possible to modify `notmuch-expand-name' into CAPF > without breaking backward compatibility. > [...] See attached. patch-notmuch-address.el Description: application/emacs-lisp ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Add more front ends for address completion
Hi, On 2022-02-28, 14:31 +0530, Utkarsh Singh wrote: > 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: I don't think its possible to modify `notmuch-expand-name' into CAPF without breaking backward compatibility. But for now, Corfu's users can use the following hook for the desired behaviour: (add-hook 'notmuch-message-mode-hook (lambda () (corfu-mode -1))) -- Utkarsh Singh https://utkarshsingh.xyz/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Add more front ends for address completion
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/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [Utkarsh Singh] Re: [PATCH] emacs: Add more front ends for address completion
On Fri, Feb 11 2022, Utkarsh Singh wrote: > On 2022-02-10, 19:37 +0200, Tomi Ollila wrote: > >> >> When doing in notmuch repo, one can execute ./devel/try-emacs-mua -Q >> >> ... which probably uses the same package database (under $HOME) as any >> other emacs invocation would do -- what is the way to change the location >> of that in order to have chance to have "empty" set of externally installed >> packages, and messing with it would not touch the "default" packages... > > Okay, we can use `package-user-dir', try the following steps: > > 1. Press M-w (`kill-ring-save') to kill/cut the following expression: > > --8<---cut here---start->8--- > (progn > (setq package-user-dir "/tmp/elpa") > (package-initialize) > (package-install 'corfu) > (package-install 'vertico) > > (require 'notmuch) > (require 'corfu) > (require 'vertico) > > (vertico-mode 1) > (corfu-global-mode 1) > (notmuch-mua-new-mail)) > --8<---cut here---end--->8--- > > 2. Now in ./devel/try-emacs-mua -Q, press M-: (`eval-expression'), C-y > (`yank') and finally RET. > > 3. Press TAB to generate address completion, then press RET to select a > address, for eg. "Notmuch mailing list ". > After selection, you will notice that `notmuch-address-expand-name' > insert desired address with trailing whitespaces. Yes, I see trailing whitespace. Also, completion matches only from beginning of the address string. Also, after one completion TAB no longer completes... Tomi > > --8<---cut here---start->8--- > To: Notmuch mailing list > --8<---cut here---end--->8--- > > I apologize as results are not as reproducible as I thought, but you can > still notice that `notmuch-address-expand-name' is not producing the > desired result. > > -- > Utkarsh Singh > https://utkarshsingh.xyz/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Add more front ends for address completion
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 ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [Utkarsh Singh] Re: [PATCH] emacs: Add more front ends for address completion
On 2022-02-10, 19:37 +0200, Tomi Ollila wrote: > On Thu, Feb 10 2022, Utkarsh Singh wrote: > >> Start of forwarded message >> From: Utkarsh Singh >> To: Tomi Ollila >> Subject: Re: [PATCH] emacs: Add more front ends for address completion >> Date: Thu, 10 Feb 2022 08:58:49 +0530 >> >> Hello Tomi, >> >> On 2022-02-09, 23:59 +0200, Tomi Ollila wrote: >> >>> On Tue, Feb 08 2022, Utkarsh Singh wrote: >>> >>>> Hello maintainers, >>>> >>>> Emacs Lisp Package Archive (ELPA) now includes a package called 'corfu', >>>> according to its documentation: >>>> >>>> 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. >>>> >>>> Hence, this patch tries to add support for `completion-in-region' in >>>> `notmuch-address-expand-name'. By default, this behaviour is turned off >>>> so that existing users can enjoy existing completion techniques. >>> >>> The current "default" (i.e. w/o any notmuch emacs mua configuration) is to >>> use completing-read to do the completion. If "company" is available, then >>> company is used by default (w/ all address harvesting and so on...). >>> >>> This is "messy" enough ;( (i.e the notmuch-address-selection-function >>> is called if company mode is not available or notmuch-address-command >>> is a string instead of 'internal or 'as-is (or whatnot, too tired to do >>> deep investigation there ;/) >>> >>> This change, contributes even more "complexity" there. To keep the >>> complexity to the same level would be adding more >>> notmuch-address-selection-functions and have the defcustom there list >>> the options (also probably the name of notmuch-address-selection-function >>> would need to be changed to notmuch-fallback-address-selection-function >>> ;/) >>> >> >> I think, in general, you're right about the complexity and we should try >> minimize it. But this patch was originally derived from a bug I was >> experiencing with `(global-corfu-mode 1)' in `notmuch-message-mode'. > > Is global-corfu-mode changing how completing-read works ? In theory, no! >> Here are the steps to reproduce the bug: >> >> 1. [Install](https://notmuchmail.org/#index7h2) `notmuch`. >> 2. In emacs -Q session, evaluate the following > > When doing in notmuch repo, one can execute ./devel/try-emacs-mua -Q > > ... which probably uses the same package database (under $HOME) as any > other emacs invocation would do -- what is the way to change the location > of that in order to have chance to have "empty" set of externally installed > packages, and messing with it would not touch the "default" packages... Okay, we can use `package-user-dir', try the following steps: 1. Press M-w (`kill-ring-save') to kill/cut the following expression: --8<---cut here---start->8--- (progn (setq package-user-dir "/tmp/elpa") (package-initialize) (package-install 'corfu) (package-install 'vertico) (require 'notmuch) (require 'corfu) (require 'vertico) (vertico-mode 1) (corfu-global-mode 1) (notmuch-mua-new-mail)) --8<---cut here---end--->8--- 2. Now in ./devel/try-emacs-mua -Q, press M-: (`eval-expression'), C-y (`yank') and finally RET. 3. Press TAB to generate address completion, then press RET to select a address, for eg. "Notmuch mailing list ". After selection, you will notice that `notmuch-address-expand-name' insert desired address with trailing whitespaces. --8<---cut here---start->8--- To: Notmuch mailing list --8<---cut here---end--->8--- I apologize as results are not as reproducible as I thought, but you can still notice that `notmuch-address-expand-name' is not producing the desired result. -- Utkarsh Singh https://utkarshsingh.xyz/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [Utkarsh Singh] Re: [PATCH] emacs: Add more front ends for address completion
On Thu, Feb 10 2022, Utkarsh Singh wrote: > Start of forwarded message > From: Utkarsh Singh > To: Tomi Ollila > Subject: Re: [PATCH] emacs: Add more front ends for address completion > Date: Thu, 10 Feb 2022 08:58:49 +0530 > > Hello Tomi, > > On 2022-02-09, 23:59 +0200, Tomi Ollila wrote: > >> On Tue, Feb 08 2022, Utkarsh Singh wrote: >> >>> Hello maintainers, >>> >>> Emacs Lisp Package Archive (ELPA) now includes a package called 'corfu', >>> according to its documentation: >>> >>> 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. >>> >>> Hence, this patch tries to add support for `completion-in-region' in >>> `notmuch-address-expand-name'. By default, this behaviour is turned off >>> so that existing users can enjoy existing completion techniques. >> >> The current "default" (i.e. w/o any notmuch emacs mua configuration) is to >> use completing-read to do the completion. If "company" is available, then >> company is used by default (w/ all address harvesting and so on...). >> >> This is "messy" enough ;( (i.e the notmuch-address-selection-function >> is called if company mode is not available or notmuch-address-command >> is a string instead of 'internal or 'as-is (or whatnot, too tired to do >> deep investigation there ;/) >> >> This change, contributes even more "complexity" there. To keep the >> complexity to the same level would be adding more >> notmuch-address-selection-functions and have the defcustom there list >> the options (also probably the name of notmuch-address-selection-function >> would need to be changed to notmuch-fallback-address-selection-function >> ;/) >> > > I think, in general, you're right about the complexity and we should try > minimize it. But this patch was originally derived from a bug I was > experiencing with `(global-corfu-mode 1)' in `notmuch-message-mode'. Is global-corfu-mode changing how completing-read works ? > Here are the steps to reproduce the bug: > > 1. [Install](https://notmuchmail.org/#index7h2) `notmuch`. > 2. In emacs -Q session, evaluate the following When doing in notmuch repo, one can execute ./devel/try-emacs-mua -Q ... which probably uses the same package database (under $HOME) as any other emacs invocation would do -- what is the way to change the location of that in order to have chance to have "empty" set of externally installed packages, and messing with it would not touch the "default" packages... (so that I can try the steps below) Tomi > > ```elisp > (progn > (add-to-list 'load-path "/usr/share/emacs/site-lisp") ; Notmuch Emacs > interface > (package-initialize) > (package-install 'corfu) > (package-install 'vertico) > > (require 'notmuch) > (require 'corfu) > (require 'vertico) > > (vertico-mode 1) > (corfu-global-mode 1) > (notmuch-mua-new-mail)) > ``` > > 3. Press `TAB` to generate address completion, then press `RET` to > select address of your choice. After selection, you will notice that > `notmuch-address-expand-name` fails to insert desired address, that is, > you will get the following: > > ``` > To: > ``` > > Note: Check the trailing spaces. > >> All this said, I think this is not simple to solve, as this otherwise fine >> change would indicate :/ > > No problem, I'm willing to help the maintainers on this matter. > > -- > Utkarsh Singh > https://utkarshsingh.xyz/ > End of forwarded message > > -- > Utkarsh Singh > https://utkarshsingh.xyz/ > ___ > notmuch mailing list -- notmuch@notmuchmail.org > To unsubscribe send an email to notmuch-le...@notmuchmail.org ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
[Utkarsh Singh] Re: [PATCH] emacs: Add more front ends for address completion
Start of forwarded message From: Utkarsh Singh To: Tomi Ollila Subject: Re: [PATCH] emacs: Add more front ends for address completion Date: Thu, 10 Feb 2022 08:58:49 +0530 Hello Tomi, On 2022-02-09, 23:59 +0200, Tomi Ollila wrote: > On Tue, Feb 08 2022, Utkarsh Singh wrote: > >> Hello maintainers, >> >> Emacs Lisp Package Archive (ELPA) now includes a package called 'corfu', >> according to its documentation: >> >> 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. >> >> Hence, this patch tries to add support for `completion-in-region' in >> `notmuch-address-expand-name'. By default, this behaviour is turned off >> so that existing users can enjoy existing completion techniques. > > The current "default" (i.e. w/o any notmuch emacs mua configuration) is to > use completing-read to do the completion. If "company" is available, then > company is used by default (w/ all address harvesting and so on...). > > This is "messy" enough ;( (i.e the notmuch-address-selection-function > is called if company mode is not available or notmuch-address-command > is a string instead of 'internal or 'as-is (or whatnot, too tired to do > deep investigation there ;/) > > This change, contributes even more "complexity" there. To keep the > complexity to the same level would be adding more > notmuch-address-selection-functions and have the defcustom there list > the options (also probably the name of notmuch-address-selection-function > would need to be changed to notmuch-fallback-address-selection-function > ;/) > I think, in general, you're right about the complexity and we should try minimize it. But this patch was originally derived from a bug I was experiencing with `(global-corfu-mode 1)' in `notmuch-message-mode'. Here are the steps to reproduce the bug: 1. [Install](https://notmuchmail.org/#index7h2) `notmuch`. 2. In emacs -Q session, evaluate the following ```elisp (progn (add-to-list 'load-path "/usr/share/emacs/site-lisp") ; Notmuch Emacs interface (package-initialize) (package-install 'corfu) (package-install 'vertico) (require 'notmuch) (require 'corfu) (require 'vertico) (vertico-mode 1) (corfu-global-mode 1) (notmuch-mua-new-mail)) ``` 3. Press `TAB` to generate address completion, then press `RET` to select address of your choice. After selection, you will notice that `notmuch-address-expand-name` fails to insert desired address, that is, you will get the following: ``` To: ``` Note: Check the trailing spaces. > All this said, I think this is not simple to solve, as this otherwise fine > change would indicate :/ No problem, I'm willing to help the maintainers on this matter. -- Utkarsh Singh https://utkarshsingh.xyz/ End of forwarded message -- Utkarsh Singh https://utkarshsingh.xyz/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] emacs: Add more front ends for address completion
On Tue, Feb 08 2022, Utkarsh Singh wrote: > Hello maintainers, > > Emacs Lisp Package Archive (ELPA) now includes a package called 'corfu', > according to its documentation: > > 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. > > Hence, this patch tries to add support for `completion-in-region' in > `notmuch-address-expand-name'. By default, this behaviour is turned off > so that existing users can enjoy existing completion techniques. The current "default" (i.e. w/o any notmuch emacs mua configuration) is to use completing-read to do the completion. If "company" is available, then company is used by default (w/ all address harvesting and so on...). This is "messy" enough ;( (i.e the notmuch-address-selection-function is called if company mode is not available or notmuch-address-command is a string instead of 'internal or 'as-is (or whatnot, too tired to do deep investigation there ;/) This change, contributes even more "complexity" there. To keep the complexity to the same level would be adding more notmuch-address-selection-functions and have the defcustom there list the options (also probably the name of notmuch-address-selection-function would need to be changed to notmuch-fallback-address-selection-function ;/) Also, if name was notmuch-address-selection-function but its interface changed, current users using their own functions (I am in that list) would get error there (the interface would have to be (defun notmuch-address-selection-function (prompt collection initial-input &optional beg end) to be backward compatible) If name was changed then their own function would not be used -- which is OK, things change and users can read from NEWS how to be compatible again... All this said, I think this is not simple to solve, as this otherwise fine change would indicate :/ Tomi > > Thank you, > Utkarsh Singh > -- > Utkarsh Singh > https://utkarshsingh.xyz/ > From fdc88b81fef763f7d7dcdc899aa8e90482c574fa Mon Sep 17 00:00:00 2001 > From: Utkarsh Singh > Date: Tue, 8 Feb 2022 19:17:26 +0530 > Subject: [PATCH] emacs: Add more front ends for address completion > > Add support for address completion through completion-in-region. > * notmuch-address.el (notmuch-address-use-completion-in-region): > Introduce customizable variable to activate the new front end. > (notmuch-address-selection-function, notmuch-address-expand-name): Use > it. > --- > emacs/notmuch-address.el | 28 ++-- > 1 file changed, 18 insertions(+), 10 deletions(-) > > diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el > index 1a4cdda2..cfb56a3a 100644 > --- a/emacs/notmuch-address.el > +++ b/emacs/notmuch-address.el > @@ -123,10 +123,10 @@ you should make sure it is not somewhere publicly > readable." > (defcustom notmuch-address-selection-function > 'notmuch-address-selection-function >"The function to select address from given list. > > -The function is called with PROMPT, COLLECTION, and INITIAL-INPUT > -as arguments (subset of what `completing-read' can be called > -with). While executed the value of `completion-ignore-case' > -is t. See documentation of function > +The function is called with PROMPT, COLLECTION, INITIAL-INPUT, > +BEG and END as arguments (subset of what `completing-read' can be > +called with). While executed the value of > +`completion-ignore-case' is t. See documentation of function > `notmuch-address-selection-function' to know how address > selection is made by default." >:type 'function > @@ -150,13 +150,19 @@ matching `notmuch-address-completion-headers-regexp'." >:group 'notmuch-send >:group 'notmuch-address) > > +(defcustom notmuch-address-use-completion-in-region nil > + "Use `completion-in-region' for address completion." > + :type 'boolean > + :group 'notmuch-send > + :group 'notmuch-address) > + > ;;; Setup > > -(defun notmuch-address-selection-function (prompt collection initial-input) > - "Call (`completing-read' > - PROMPT COLLECTION nil nil INITIAL-INPUT 'notmuch-address-history)" > - (completing-read > - prompt collection nil nil initial-input 'notmuch-address-history)) > +(defun notmuch-address-selection-function (prompt collection initial-input > beg end) > + (if notmuch-address-use-completion-in-region > + (completion-in-region beg end collection) > +(completing-read > + prompt collection nil nil initial-input 'notmuch-address-history))) > > (defvar notmuch-address-completion-headers-regexp > > "^\\(Resent-\\)?\\(To\\|B?Cc\\|Reply-To\\|From\\|Mail-Followup-To\\|Mail-Copies-To\\):") > @@ -245,7 +251,9 @@ requiring external commands." >(funcall notmuch-address-selection-function >