Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] Signatures (non-crypto) #81

Closed
xxxserxxx opened this issue Apr 26, 2021 · 7 comments
Closed

[feature request] Signatures (non-crypto) #81

xxxserxxx opened this issue Apr 26, 2021 · 7 comments

Comments

@xxxserxxx
Copy link
Contributor

xxxserxxx commented Apr 26, 2021

I would like to be able to specify a file in the config that bower would append to the email template; this would allow a user to specify a (non-cryto) inline signature.

Such a feature might look like an addition to bower.conf:

signature = ~/.sig

and if this option is set, bower would append this file to the file created by create_temp_message_file() before opening the editor.

Edit 2021-04-30

I'm getting this behavior by having my editor command set to append the sig file:

kak -e 'set buffer filetype mail; exec "gJ|cat ~/.sig<ret>"; exec "<a-;>O<esc>"'

The same could be done with vim too, obviously. This would be an acceptable work-around except for the fact that any invokation of the editor appends the file, meaning if a composition is closed and then edited again before sending, the sig will be added again.

Although not in the original request, what I'd like to have is how Astroid mail handles signatures. Like Bower, there's some built-in support for markdown -> HTML support. Astroid has a configuration option to append one signature for plain-text messages, or a second when the user toggles HTML messages.

@wangp
Copy link
Owner

wangp commented May 1, 2021

I've implemented this on the signature branch. I don't know what else would need to be done for markdown, but it's not something I would use so I don't think I will do anything.

@xxxserxxx
Copy link
Contributor Author

Thanks, I'll check it out!

Despite my patch, I don't code in Mercury, otherwise I'd be submitting more patches (and fewer feature requests). I surveyed Mercury a year or two ago for feel and decided it wasn't my cuppa, and anything more complex than the most trivial copying of a pattern (as I did with the spam patch) is beyond my Mercury knowledge.

@xxxserxxx
Copy link
Contributor Author

xxxserxxx commented May 2, 2021

It works well, thank you!

One question: when replying to a message, after the quoted section there's a line in the message that says (in plain text)

Non-text part: text/html

Is that intended? e.g.:

> blah, bla, blah

Non-text part: text/html

--- SER

@wangp
Copy link
Owner

wangp commented May 3, 2021

That used to be generated by notmuch reply but now we generate the reply template ourselves, so we could possibly not generate those lines. They don't seem especially helpful to me.

@xxxserxxx
Copy link
Contributor Author

They would, normally, be part of the multipart metadata, but without a MIME separator it's interpreted as part of the message body. I didn't see them before the sig change -- was templatization part of that?

@wangp
Copy link
Owner

wangp commented May 4, 2021

They would, normally, be part of the multipart metadata, but without a MIME separator it's interpreted as part of the message body. I didn't see them before the sig change -- was templatization part of that?

I think you've confused two different things, at least I'm not sure what you're referring to. We started constructing our own reply templates about a year ago in order to support #28, and I simply mimicked the notmuch reply output.

I've merged the signature change.

@xxxserxxx
Copy link
Contributor Author

I think you've confused two different things

Probably. I was talking about the fact that, when replying, I'm getting an inline Non-text part: text/html in the message body just before the signature.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants