On Mon, Dec 11 2023, Sandra Snan wrote:
> This hook is run after `notmuch reply` has been successfully called
> with the headers from the original message.
> ---
> emacs/notmuch-mua.el | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/emacs/notmuch-mua.el
This hook is run after `notmuch reply` has been successfully called
with the headers from the original message.
---
emacs/notmuch-mua.el | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index e4b7e9d1..b6c6585d 10064
I missed the other notes. I'll do a v3 renaming to
notmuch-mua-reply-functions.
The reason I need message-id is because I need to call notmuch
again to get other headers beyond what's included in the sexp,
including autocrypt.
But the suggestion to jam the entire sexp is good. I did that for
This hook is run after `notmuch reply` has been successfully called
with the headers from the original message.
---
emacs/notmuch-mua.el | 7 +++
1 file changed, 7 insertions(+)
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index e4b7e9d1..08d3dd6d 100644
--- a/emacs/notmuch-mua.el
Tomi Ollila writes:
>
> another thing what should be the parameters passed, and why. this change
> adds (just) message-id but no reasoning (nor documentation) there...
>
I wonder if we should pass the whole (parsed) original message, for
maximum flexibility?
__
On Mon, Dec 11 2023, David Bremner wrote:
> Sandra Snan writes:
>
>
>> +(defvar in-notmuch-mua-reply-functions nil
>> + "Functions to run after `notmuch-reply' was called successfully
>> +without erroring. The functions get the message-id as a string
>> +argument.")
>> +
>
> Overall this looks r
Sandra Snan writes:
> +(defvar in-notmuch-mua-reply-functions nil
> + "Functions to run after `notmuch-reply' was called successfully
> +without erroring. The functions get the message-id as a string
> +argument.")
> +
Overall this looks reasonable to me, but I'm not sure about the
name. Since
Giovanni Biscuolo writes:
> A previous running generation is using emacs 29.1 with company 0.9.13.
>
> It seems an incompatibility with company 0.10.2, no?
>
Seems likely. I have 0.10.0 running OK here.
If you are feeling motivated, you could try bisecting between 10.0 and 10.2
Hi David,
thank you for your quick reply!
David Bremner writes:
> Giovanni Biscuolo writes:
>
>> Hello,
>>
>> I recently upgraded my emacs applications, I'm using Guix as package
>> manager on Debian.
>>
>
> What versions of emacs and company are you using?
Uh, sorry for not reporting it befo
