Signature delimiter
Reported by Charlie Clark | September 17th, 2019 @ 09:09 AM
E-mail signatures should always be be preceded by --\n so that the mail client knows that they're there. MailMate currently doesn't include the delimiter and including it manually in the signature means that any preceding line will be formatted as a heading.
I suggest that signatures should automatically include the delimiter and that the signature should be formatted separately from the e-mail body, ie. not like this:
Charlie
new MailMate user
Comments and changes to this ticket
-
Seamus November 21st, 2019 @ 02:06 PM
I have been experiencing some odd behaviour with signatures and have now worked out it is related to the above issue. In my case I proceeded my plain text signature with --\n and also had a html variant, and composed with markdown format selected by default.
When composing a new email (and before typing), the preview panel would show the plain text version of the signature converted to HTML (presumably due to it having some markdown foramting). As soon as I type on line 1, the signature changes to the correct HTML version. It can flip between the two when editing text in the lines just before the signature, or changing between markdown and plain text, but can't quite figure out exactly when or why, but is easily repeatable. When composing an email I frequently end up having to turn on/off signatures or edit some text near the signature to get the right one to appear in the preview.
Removing the unintentional markdown formatting from the plain text version of the signature seems to fix the issue.
The behaviour I would expect is for the HTML version to always be there in the preview/HTML version of the email, regardless of any markdown formatting in the plain text version.
-
Benedikt February 21st, 2020 @ 10:32 AM
In addition to this request I'd like to suggest, not only automatically to include two dashes followed by whitespace character (“-- “) for signatures (Usenet Signature Convention), but also to automatically remove these signatures when replying. Currently this does not seem to be the case.
-
Benedikt January 22nd, 2021 @ 01:36 PM
I'd like to know, if this request/ticket is something, that might be accepted?
-
benny January 22nd, 2021 @ 02:10 PM
- State changed from “new” to “accepted”
@Seamus: I never really looked into this, but I think this issue might no longer be a problem? (In the test releases: Hold down ⌥ when clicking “Check Now” in the Software Update preferences pane.)
@Benedikt: What you describe is essentially how I would like it to work, that is, forcing the use of
--in plain text signatures, but I have to be careful because I can promise you that some users will not like this. It will likely have to be an opt-in feature. Something like: “[v] Automatically add standard signature separator”.Stripping signatures will likely only work well if it is somewhat heuristic. The main reason I haven't implemented it is that I then also needed some way for the user to “cancel” it when it behaves in an unexpected way.
I'm putting this in the accepted state, but I'm not promising anything soon. (Maybe a hidden preference for auto-delimiter-insertion would be a reasonable first step.)
-
Benedikt January 26th, 2021 @ 07:46 AM
Thank you, benny. Starting with a hidden preference for auto-delimiter-insertion sounds good - if there is a need, I can help to test the new feature.
-
Seamus January 26th, 2021 @ 06:07 PM
@benny thanks, it is partially fixed by the previous update that forces use of an html signature if there is one. But with a plain text only signature, the “—“ still gets interpreted as markdown both in signature and any body text immediately above. Easy to avoid with an empty line break before, and then avoiding other markdown in signature, or just including an HTML signature.
Perhaps an option to ‘use markdown in signature’ would help resolve?
-
Charlie Clark January 27th, 2021 @ 09:46 AM
The use of -- is part of the RFC. Most e-mail clients know how to handle this and often don't display them so I'd suggest following this by default but providing the option to disable it.
-
Benedikt February 1st, 2022 @ 08:51 PM
- State changed from “accepted” to “new”
Benny, do you have any news on this request?
-
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
Mac OS X email client.
benny