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

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

[Utkarsh Singh]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

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.

Thank you,
Utkarsh Singh
-- 
Utkarsh Singh
https://utkarshsingh.xyz/

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch --]
[-- Type: text/x-patch, Size: 2912 bytes --]

From fdc88b81fef763f7d7dcdc899aa8e90482c574fa Mon Sep 17 00:00:00 2001
From: Utkarsh Singh <utkarsh190601@gmail.com>
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
 			      (format "Address (%s matches): " num-options)
 			      options
-			      orig)))))
+			      orig
+			      beg
+			      end)))))
       (if chosen
 	  (progn
 	    (push chosen notmuch-address-history)
-- 
2.35.1


[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

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

[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 <utkarsh190601@gmail.com>
> 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
>  			      (format "Address (%s matches): " num-options)
>  			      options
> -			      orig)))))
> +			      orig
> +			      beg
> +			      end)))))
>        (if chosen
>  	  (progn
>  	    (push chosen notmuch-address-history)
> -- 
> 2.35.1

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

[Alexander Adolf]

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.


Cheers,

  --alexander

emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion)

[Alexander Adolf]

Alexander Adolf <alexander.adolf@condition-alpha.com> writes:

> [...]
> 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 have further ventured into this, and am attempting to disable all
company-related stuff in notmuch-address.el, and instead go through
completion-at-point-functions, and use corfu as the completion UI.

To achieve this, I have set notmuch-address-use-company to nil, and
notmuch-address-command to 'as-is.

The latter setting (notmuch-address-command 'as-is) evokes an error:
"Wrong type argument: stringp, as-is". The backtrace led me to marvel at
the function notmuch-address-options (in notmuch-address.el). There, in
case notmuch-address-command is not equal to 'internal, control is
passed to notmuch--process-lines, which in turn uses 'as-is (a symbol)
as the name of an external program to call. The name of that command is
expected to be a string, and hence the "wrong type argument" error.

The docstring for notmuch-address-command does not really state any
other effects of 'as-is besides preventing modification of
message-completion-alist (which is what I want, and to keep using the
internal mechanism). The defcustom option for 'as-is is cunningly
labelled "Use default or third-party mechanism", which doesn't tell me
much more either.

Am I misreading notmuch-address.el and/or the docs?

In case not, how can I prevent modification of message-completion-alist
by notmuch, and still have notmuch use the 'internal mechanism for
generating address completion candidates?


Many thanks in advance and cheers,

  --alexander

Re: emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion)

[Tomi Ollila]

On Mon, Feb 21 2022, Alexander Adolf wrote:

> Alexander Adolf <alexander.adolf@condition-alpha.com> writes:
>
>> [...]
>> 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 have further ventured into this, and am attempting to disable all
> company-related stuff in notmuch-address.el, and instead go through
> completion-at-point-functions, and use corfu as the completion UI.
>
> To achieve this, I have set notmuch-address-use-company to nil, and
> notmuch-address-command to 'as-is.
>
> The latter setting (notmuch-address-command 'as-is) evokes an error:
> "Wrong type argument: stringp, as-is". The backtrace led me to marvel at
> the function notmuch-address-options (in notmuch-address.el). There, in
> case notmuch-address-command is not equal to 'internal, control is
> passed to notmuch--process-lines, which in turn uses 'as-is (a symbol)
> as the name of an external program to call. The name of that command is
> expected to be a string, and hence the "wrong type argument" error.
>
> The docstring for notmuch-address-command does not really state any
> other effects of 'as-is besides preventing modification of
> message-completion-alist (which is what I want, and to keep using the
> internal mechanism). The defcustom option for 'as-is is cunningly
> labelled "Use default or third-party mechanism", which doesn't tell me
> much more either.
>
> Am I misreading notmuch-address.el and/or the docs?

You are probably reading the code right. Probably all the combinations
notmuch-address variables can be set are not (throughly;) tested.

> In case not, how can I prevent modification of message-completion-alist
> by notmuch, and still have notmuch use the 'internal mechanism for
> generating address completion candidates?

My guess would be some elisp is required...

>
> Many thanks in advance and cheers,

>
>   --alexander

cheers, 

Tomi

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

[Utkarsh Singh]

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/

Re: emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion)

[Alexander Adolf]

Tomi, apologies for the delay in getting back to you. I'm moving office,
so had a couple of other chores for having fun with. ;-)

Tomi Ollila <tomi.ollila@iki.fi> writes:

> [...]
>> In case not, how can I prevent modification of message-completion-alist
>> by notmuch, and still have notmuch use the 'internal mechanism for
>> generating address completion candidates?
>
> My guess would be some elisp is required...
> [...]

That's a very good first guess. Always. ;-D

I'm happy to have a go at contributing a patch to enable users to use
completion-at-point for address completion. What would be the least
controversial way forward? I can currently think of two variants.


Variant 1 "minimally invasive surgery":

Adding a new, Boolean custom variable which controls modification of
message-completion-alist. notmuch-address-setup would need to be
modified to make use of it.

Pros: "minimally invasive surgery"

Cons: High entry barrier (the end user needs to define his/her own
      function producing a completion table for email addresses, and
      must hence have a good understanding of how both,
      notmuch-address.el, and completion-at-point work).

      notmuch-address-command 'as-is retains its not too stringently
      defined semantics.


Variant 2 "core Emacs":

Adding a new, choice type custom variable which controls the framework
to use for address completion; possible values are "completing-read
(minibuffer UI)", and "completion-at-point (in-buffer UI)". At the same
time, notmuch-address-use-company and notmuch-address-command 'as-is
would be deprecated. A new function would be added to
notmuch-address.el, which returns a completion table for
completion-at-point. notmuch-address-setup would then need to modified
to add either said new function, or notmuch-address-expand-name to
message-completion-alist, depending on the chosen completion framework
type.

Pros: Uses core Emacs functionality (completing-read, or
      completion-at-point), hence removes dependency on 3rd party
      packages, and thus would make notmuch-address.el (even) more
      future proof.

      High-level configuration option lowers entry barrier for end users
      (no knowledge of notmuch-address.el, or completion-at-point
      required).

Cons: Paves the way for removing company from notmuch-address.el.
      Company can use completion-at-point as a back-end (company-capf),
      so end users can continue to use company if they wish, but need to
      adapt their configuration.



Looking forward to your thoughts,

  --alexander

Re: emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion)

[Alexander Adolf]

[-- Attachment #1: Type: text/plain, Size: 199 bytes --]

Alexander Adolf <alexander.adolf@condition-alpha.com> writes:

> [...]
> Variant 2 "core Emacs":
> [...]

It was not as much work as I had anticipated, and hence here is a first
sketch of the idea:


[-- Attachment #2: patch-notmuch-address.el --]
[-- Type: application/emacs-lisp, Size: 3308 bytes --]

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]


Some further cleanup to remove all company stuff from notmuch-address.el
would still be needed, though.

Looking forward to your thoughts,

  --alexander

[-- Attachment #4: Type: text/plain, Size: 0 bytes --]

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

[Utkarsh Singh]

Hi,

On 2022-02-28, 14:31 +0530, Utkarsh Singh <utkarsh190601@gmail.com> 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/

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

[Alexander Adolf]

[-- Attachment #1: Type: text/plain, Size: 195 bytes --]

Utkarsh Singh <utkarsh190601@gmail.com> writes:

> [...]
> I don't think its possible to modify `notmuch-expand-name' into CAPF
> without breaking backward compatibility.
> [...]

See attached.


[-- Attachment #2: patch-notmuch-address.el --]
[-- Type: application/emacs-lisp, Size: 3447 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

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

[Utkarsh Singh]

On 2022-03-08, 16:29 +0100, Alexander Adolf <alexander.adolf@condition-alpha.com> wrote:

> Utkarsh Singh <utkarsh190601@gmail.com> 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/

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

[Alexander Adolf]

Utkarsh Singh <utkarsh190601@gmail.com> writes:

> On 2022-03-08, 16:29 +0100, Alexander Adolf <alexander.adolf@condition-alpha.com> wrote:
>
>> Utkarsh Singh <utkarsh190601@gmail.com> 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

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

[Utkarsh Singh]

On 2022-03-11, 18:50 +0100, Alexander Adolf <alexander.adolf@condition-alpha.com> wrote:

> Utkarsh Singh <utkarsh190601@gmail.com> writes:
>
>> On 2022-03-08, 16:29 +0100, Alexander Adolf <alexander.adolf@condition-alpha.com> wrote:
>>
>>> Utkarsh Singh <utkarsh190601@gmail.com> 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/

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

[Alexander Adolf]

Utkarsh Singh <utkarsh190601@gmail.com> 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 --> <    company        
                                     |   ...            
                                      \

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,

  --alexander

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

[Utkarsh Singh]

On 2022-03-15, 13:37 +0100, Alexander Adolf <alexander.adolf@condition-alpha.com> wrote:

> Utkarsh Singh <utkarsh190601@gmail.com> 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 --> <    company        
>                                      |   ...            
>                                       \
>
> 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/

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

[David Bremner]

Utkarsh Singh <utkarsh190601@gmail.com> 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

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

[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 <david@tethera.net> wrote:

> Utkarsh Singh <utkarsh190601@gmail.com> 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/

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

[David Bremner]

Utkarsh Singh <utkarsh190601@gmail.com> 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