On 2/1/21 3:25 AM, Stephen J. Turnbull wrote:
Richard Damon writes:
It is one of the 'Markdown' codes for a horizontal rule
But 72 of them? Don't most people use about 5?
But if they are using it AS the horizontal rule in a plain text document, it could easily be that long.
will occasionally end up with a line like that when documenting an electrical signal that is always low (at least for a given example).
OK, that's very plausible, and an excellent example. It will almost never happen to me (and that instance was in 1997 or so ;-), but for you it could be an ongoing, if occasional, annoyance. Not cool. As I said, I could see it quite likely AS a horizontal ruler in a 'plain text' document (like an RFC)
that would make the definition not match the existing practice, so list settings would need to be edited.
True, for those folks who have edited their footers. For the rest, they get it with the upgrade, as the IETF list did. We can mitigate that, with some risk of guessing wrong. But it's not a huge consequence if we do guess wrong, I think.
Also, the question comes does the separator require and exact number of underscores
Yes. I think 72 is the sweet spot, or maybe 70 with a trailing space.
My guess is 72 is likely getting into the the increased chance of false positive range, being about the width of a 'standard' page.
Something more like 40 or so, longer than for real Markdown, but narrower than for a real Horizontal Ruler might be safer.
Adding the trailing space would really be needed to truly drop the false positive range.
(and the frustrations of having the wrong number)
I doubt anybody would notice. :-) Again, we can mitigate. We separate the footer from the separator. I think we already do that in Mailman 3.
If you have time, please keep trying to poke holes in my ideas. Whether to revert in Mailman 2 is entirely up to Mark, but Mailman 3 is still up for discussion.
I think the biggest issue is that common tools are unlikely to adopt the new standard quickly, especially any optional trimming. This says that many tools that currently would be trimming the footer (if it had the signature code in front of it) wouldn't trim the footer unless it was preceded by a signature (and many email clients/users DON'T setup the proper signature code by default). This says that to try and switch to this method begins with a loss in automatic trimming of the footer.
The big problem is going to be convincing the industry that the advantages of a new separator for mailing lists is worth the effort for MUAs to support the new seperator code.
Steve
Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-leave@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3
Security Policy: https://wiki.list.org/x/QIA9
-- Richard Damon