Re: [PATCH] emacs: Add more front ends for address completion

2022-04-06 Thread David Bremner
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

2022-04-06 Thread Utkarsh Singh
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

2022-03-20 Thread David Bremner
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

2022-03-16 Thread Utkarsh Singh
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

2022-03-15 Thread Alexander Adolf
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

2022-03-12 Thread Utkarsh Singh
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

2022-03-11 Thread Alexander Adolf
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

2022-03-08 Thread Utkarsh Singh
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

2022-03-07 Thread Alexander Adolf
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

2022-03-05 Thread Utkarsh Singh
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

2022-02-28 Thread Utkarsh Singh
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

2022-02-12 Thread Tomi Ollila
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

2022-02-12 Thread Alexander Adolf
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

2022-02-10 Thread Utkarsh Singh
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

2022-02-10 Thread Tomi Ollila
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

2022-02-09 Thread Utkarsh Singh


 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

2022-02-09 Thread Tomi Ollila
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
>