* [PATCH] emacs: Add more front ends for address completion
@ 2022-02-08 14:38 Utkarsh Singh
2022-02-09 21:59 ` Tomi Ollila
0 siblings, 1 reply; 18+ messages in thread
From: Utkarsh Singh @ 2022-02-08 14:38 UTC (permalink / raw)
To: Notmuch mailing list
[-- 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 --]
^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH] emacs: Add more front ends for address completion
2022-02-08 14:38 [PATCH] emacs: Add more front ends for address completion Utkarsh Singh
@ 2022-02-09 21:59 ` Tomi Ollila
2022-02-12 16:09 ` Alexander Adolf
0 siblings, 1 reply; 18+ messages in thread
From: Tomi Ollila @ 2022-02-09 21:59 UTC (permalink / raw)
To: Utkarsh Singh, Notmuch mailing list
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] emacs: Add more front ends for address completion
2022-02-09 21:59 ` Tomi Ollila
@ 2022-02-12 16:09 ` Alexander Adolf
2022-02-21 22:20 ` emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion) Alexander Adolf
2022-02-28 9:01 ` [PATCH] emacs: Add more front ends for address completion Utkarsh Singh
0 siblings, 2 replies; 18+ messages in thread
From: Alexander Adolf @ 2022-02-12 16:09 UTC (permalink / raw)
To: Tomi Ollila, Utkarsh Singh, Notmuch mailing list
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion)
2022-02-12 16:09 ` Alexander Adolf
@ 2022-02-21 22:20 ` Alexander Adolf
2022-02-22 22:04 ` Tomi Ollila
2022-02-28 9:01 ` [PATCH] emacs: Add more front ends for address completion Utkarsh Singh
1 sibling, 1 reply; 18+ messages in thread
From: Alexander Adolf @ 2022-02-21 22:20 UTC (permalink / raw)
To: Tomi Ollila, Utkarsh Singh, Notmuch mailing list
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion)
2022-02-21 22:20 ` emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion) Alexander Adolf
@ 2022-02-22 22:04 ` Tomi Ollila
2022-02-28 21:19 ` Alexander Adolf
0 siblings, 1 reply; 18+ messages in thread
From: Tomi Ollila @ 2022-02-22 22:04 UTC (permalink / raw)
To: Alexander Adolf, Utkarsh Singh, Notmuch mailing list
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion)
2022-02-22 22:04 ` Tomi Ollila
@ 2022-02-28 21:19 ` Alexander Adolf
2022-03-01 17:51 ` Alexander Adolf
0 siblings, 1 reply; 18+ messages in thread
From: Alexander Adolf @ 2022-02-28 21:19 UTC (permalink / raw)
To: Tomi Ollila, Utkarsh Singh, Notmuch mailing list
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
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion)
2022-02-28 21:19 ` Alexander Adolf
@ 2022-03-01 17:51 ` Alexander Adolf
0 siblings, 0 replies; 18+ messages in thread
From: Alexander Adolf @ 2022-03-01 17:51 UTC (permalink / raw)
To: Tomi Ollila, Utkarsh Singh, Notmuch mailing list
[-- 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 --]
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] emacs: Add more front ends for address completion
2022-02-12 16:09 ` Alexander Adolf
2022-02-21 22:20 ` emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion) Alexander Adolf
@ 2022-02-28 9:01 ` Utkarsh Singh
2022-03-06 7:28 ` Utkarsh Singh
1 sibling, 1 reply; 18+ messages in thread
From: Utkarsh Singh @ 2022-02-28 9:01 UTC (permalink / raw)
To: Alexander Adolf, Tomi Ollila, Notmuch mailing list
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/
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-04-06 18:23 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-08 14:38 [PATCH] emacs: Add more front ends for address completion Utkarsh Singh
2022-02-09 21:59 ` Tomi Ollila
2022-02-12 16:09 ` Alexander Adolf
2022-02-21 22:20 ` emacs: notmuch-address-command 'as-is throws error (was: [PATCH] emacs: Add more front ends for address completion) Alexander Adolf
2022-02-22 22:04 ` Tomi Ollila
2022-02-28 21:19 ` Alexander Adolf
2022-03-01 17:51 ` Alexander Adolf
2022-02-28 9:01 ` [PATCH] emacs: Add more front ends for address completion Utkarsh Singh
2022-03-06 7:28 ` Utkarsh Singh
2022-03-07 22:14 ` Alexander Adolf
[not found] ` <87k0d4n8tr.fsf@gmail.com>
[not found] ` <c6c39f1b36844a9160e81f2f23cb8458@condition-alpha.com>
2022-03-09 1:06 ` Utkarsh Singh
2022-03-11 17:50 ` Alexander Adolf
2022-03-13 3:51 ` Utkarsh Singh
2022-03-15 12:37 ` Alexander Adolf
2022-03-17 4:56 ` Utkarsh Singh
2022-03-20 10:49 ` David Bremner
2022-04-06 12:19 ` Utkarsh Singh
2022-04-06 18:23 ` David Bremner
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).