Reusing descriptive sender name when replying

Reusing descriptive sender name when replying

[inasprecali]

Hello, I have a question which is specifically about the Emacs
frontend, but which could be about notmuch in general.  For your
information, I’m using notmuch 0.31.4 and GNU Emacs 27.1.

When pressing "r" to reply to a message, invoking the function
"notmuch-show-reply-sender", the "From:" address used in the reply
is automatically deduced from the message I’m currently replying
to (looking at the code, it looks like it uses the
notmuch-reply(1) command).  While the address itself is correct,
the "real", descriptive name (the one used before the actual mail
address in angled brackets, apologies if this is not the right
terminology) seems to be always taken from the user.name setting
in the .notmuch-config file, if any.  If it is not set, a
descriptive name is not used at all and the address alone is used.

For example, if we have a message with the following headers:

From: Foo <foo@foo.org>
To: Bar <bar@bar.org>

the function notmuch-show-reply-sender generates these headers,
assuming that user.name in .notmuch-config is not set:

From: bar@bar.org
To: Foo <foo@foo.org>

If user.name is set in the main notmuch configuration file, let’s
say to "Baz", I get these initial headers:

From: Baz <bar@bar.org>
To: Foo <foo@foo.org>

My question is: is it possible to automatically reuse the same
"descriptive" name in the From: header?  I’d like the following to
be automatically generated just by looking at the original message
to be replied to, using the same examples as before.  The To:
header already reuses the same name, as expected.

From: Bar <bar@bar.org>
To: Foo <foo@foo.org>

Thank you for your time.\r

Re: Reusing descriptive sender name when replying

[David Bremner]

inasprecali <inasprecali@disroot.org> writes:

> Hello, I have a question which is specifically about the Emacs
> frontend, but which could be about notmuch in general.  For your
> information, I’m using notmuch 0.31.4 and GNU Emacs 27.1.
>
> When pressing "r" to reply to a message, invoking the function
> "notmuch-show-reply-sender", the "From:" address used in the reply
> is automatically deduced from the message I’m currently replying
> to (looking at the code, it looks like it uses the
> notmuch-reply(1) command).  While the address itself is correct,
> the "real", descriptive name (the one used before the actual mail
> address in angled brackets, apologies if this is not the right
> terminology) seems to be always taken from the user.name setting
> in the .notmuch-config file, if any.  If it is not set, a
> descriptive name is not used at all and the address alone is used.

I think the two options supported out of the box are setting user.name
and setting notmuch-identities in emacs. The latter should let you
choose via completing-read at composition time. Otherwise there are more
complex options available via addons like gnus-alias [1] or
message-templ [2].

> My question is: is it possible to automatically reuse the same
> "descriptive" name in the From: header?  I’d like the following to
> be automatically generated just by looking at the original message
> to be replied to, using the same examples as before.  The To:
> header already reuses the same name, as expected.
>
> From: Bar <bar@bar.org>
> To: Foo <foo@foo.org>

I'm curious about your use case. Do you have a large number of values of
"Foo", conveniently provided by the senders of your messages?

At the moment I'm feeling a bit negative about putting more tweaks into
notmuch-reply; it seems like everybody wants something different but
small, and those kind of customizations are better done in the emacs
layer. OTOH I've changed my mind before about this kind of thing.

[1] https://github.com/hexmode/gnus-alias
[2] https://git.tethera.net/message-templ.git/\r

Re: Reusing descriptive sender name when replying

[inasprecali]

Thank you for the reply.

I don’t think I have explained myself properly.  What I would like
to have is to automatically have my descriptive name (the one
before the actual address in angled brackets) be filled in the
From: header when replying.  Right now, the only workarounds I
know of are using a prefix argument or just typing it manually
(which defeats the point of automatic detection in the first
place).  I used a prefix argument to compose this very reply.

> I think the two options supported out of the box are setting
> user.name and setting notmuch-identities in emacs. The latter
> should let you choose via completing-read at composition time.

user.name seems to only support a single, "global" name" and
notmuch-identities allows me to choose the name only if using a
prefix argument.  Without it, notmuch only fills in the address,
but not the descriptive name.  Setting the
notmuch-always-prompt-for-sender variable to t does not help,
since its description says (as of 0.31.4):

```
Documentation:
Always prompt for the From: address when composing or forwarding a message.

This is not taken into account when replying to a message, because in that case
the From: header is already filled in by notmuch.
```

And it’s still a workaround, because I have to choose the sending
identity "manually".

> I'm curious about your use case. Do you have a large number of
> values of "Foo", conveniently provided by the senders of your
> messages?

No, it’s the exact opposite.  I have multiple identities which I
use to send messages with, with different descriptive names.  In
my example, I’d like the name "Bar" to be automatically filled in,
but at the moment it is not.  The From: header in the new reply is
the problem.

> At the moment I'm feeling a bit negative about putting more
> tweaks into notmuch-reply; it seems like everybody wants
> something different but small, and those kind of customizations
> are better done in the emacs layer. OTOH I've changed my mind
> before about this kind of thing.

I don’t doubt that different people have different needs and
desires, but having multiple identities each with their respective
"real" name does not seem like such an exotic scenario in my
opinion (and since notmuch itself supports multiple addresses out
of the box, I’d say it agrees with me).  notmuch-reply can already
fill in the correct address in the From: header anyway, I don’t
think it would be very difficult to add the descriptive name as
well.  Could you please point me towards the specific code which
notmuch-reply uses to obtain the address to use in the From:
header?\r

Re: Reusing descriptive sender name when replying

[Dan Čermák]

inasprecali <inasprecali@disroot.org> writes:

> Thank you for the reply.
>
> I don’t think I have explained myself properly.  What I would like
> to have is to automatically have my descriptive name (the one
> before the actual address in angled brackets) be filled in the
> From: header when replying.  Right now, the only workarounds I
> know of are using a prefix argument or just typing it manually
> (which defeats the point of automatic detection in the first
> place).  I used a prefix argument to compose this very reply.

I'd suggest to take a look at gnus-alias then.


Cheers,

Dan\r

Re: Reusing descriptive sender name when replying

[David Bremner]

inasprecali <inasprecali@disroot.org> writes:


> Could you please point me towards the specific code which
> notmuch-reply uses to obtain the address to use in the From:
> header?

Have a look at the function create_reply_message.

As I hinted in my last message, I'm not very enthusiastic about
upstreaming more features in notmuch-reply.c. Everything you need should
be available in emacs since we pass the original message headers (and
body) back from the CLI.

Re: Reusing descriptive sender name when replying

[Alexander Adolf]

inasprecali <inasprecali@disroot.org> writes:

> [...]
> Setting the notmuch-always-prompt-for-sender variable to t does not
> help, since its description says (as of 0.31.4): [...]

The documentation of notmuch-always-prompt-for-sender describes that
behaviour rather clearly:
---------------------------- Begin Quote -----------------------------
Always prompt for the From: address when composing or forwarding a message.

This is not taken into account when replying to a message, because in that case
the From: header is already filled in by notmuch.
----------------------------- End Quote ------------------------------
So will not have an effect for replies. Which seems to make sense to me,
as that way the reply then comes from the account that the other guy
sent his message to in the first place.

Are you suing any text completion package in emacs (e.g. company)?
Notmuch provides completion candidates for email addresses, too. Thus,
when I'm unhappy with the from address in the message composition
buffer, I just move the cursor to the beginning of the "From:" field,
type C-k to clear it, and start typing my name. The text completion
automatically pops up a list of candidate addresses (including names)
from the notmuch database. Depending on the completion package you are
using, you may have to trigger completion manually, though. Still not
great, but it works even if you forget to add the prefix to the command.

How about this (off the top of my head):
notmuch-always-prompt-for-sender could admittedly be seen as a bit of a
misnomer, since it prompts always, except when it's a reply (i.e. not
really always). A new variable could perhaps be added (say,
notmuch-always-prompt-for-sender-reply) that changes the behaviour. When
both, notmuch-always-prompt-for-sender and this new variable are set to
t, then the user is also prompted for the sender address when replying.
If the new variable defaulted to nil, the change would even be backwards
compatible (i.e. no change of behaviour for existing emacs
configurations).

On rare occasions I have a similar use-case as you. If someone sends
email to a generic email address (e.g. sales@example.com), I want to
reply with my personal address to give it a more personal touch. This
doesn't occur often for me, so I have been able to live with manually
updating the "From:" field in the composition window (with support from
a text completion package as described). I have thus never felt the need
for a more automated solution like you are asking for, but have some
sympathy for you request. But then I'm not a developer, so it'll be for
others to decide.


Hoping to have helped,

  --alexander