Re: [Mailman-Developers] Feature Request - Interactive HTML Digests
On 2/20/2010 4:12 AM, Tanstaafl wrote: By the way - why is it that TB3's new 'Reply-To-List' feature isn't working for this list? I still have to 'Reply All' then delete the senders address... Works for me. This is a Reply-list to your message with TB 3.0.1. There was a Reply-list bug in 3.0, but that only affected messages with a List-Post: with multiple URLs which is not the case here. -- Mark Sapiro m...@msapiro.netThe highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Feature Request - Interactive HTML Digests
On Feb 19, 2010, at 04:42 PM, Tanstaafl wrote: Currently, the MIME digest is a plain text message, and I don't see any way to reply to an individual message, much less preserve the message subject I'm replying to - unless you mean I'm supposed to actually open the message I want to reply to in a separate window, then click Reply? I've only ever seen this in one MUA, VM-in-Emacs. That MUA had a very cool feature that allowed you to burst MIME digests (and I think RFC 1153 digests). You'd be presented with a virtual folder containing just the messages in the digest. This was really cool because you could save and reply to individual messages just as if they arrived individually. I'd love to have this in more mail readers. My personal feeling is that if things can be done in a way that works reasonably in MUAs that don't support the features, then it might be feasable, but if something works with one MUA and is a disaster in another, it is better not done. I hope you aren't suggesting that Mailman should limit its features to the 'least common denominator'... I don't see anything wrong with *optionally* supporting advanced features of modern mail clients. As I mentioned in my previous message, I'm totally fine with an HTML digest that text-based MUA users can ignore. But it should work reasonably well across the field of HTML supporting MUAs, and shouldn't be disastrous on any of them. Or put it another way: if there are RFCs for this, follow them. If there aren't, act as if there were by writing something RFC like in the wiki that we can at least point to as a best practices document that MUA authors could follow. -Barry signature.asc Description: PGP signature ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Feature Request - Interactive HTML Digests
On 2/20/2010 4:09 AM, Tanstaafl wrote:
On 2010-02-20 1:23 AM, Stephen J. Turnbull wrote:
Tanstaafl writes:
Personally, I usually set all of my lists to plain text anyway, so this
wouldn't be an issue for any lists I host/maintain, but yes, I guess I
can see how that might introduce another level of complexity to this
request, but maybe such messages could be encapsulated somehow, since
the features I'm talking about all have to do with interacting with the
*headers* of each message, not the body/content.
Actually, you are not talking about interacting with message headers at
all. You are talking about an HTML document which contains some
rendering of message headers and contents and some buttons which may or
may not do what you want them to depending on the specific MUA that you
use to view this HTML document.
Further, your buttons would invoke something like
mailto:l...@example.com?subject=re:%20The%20SubjectIn-Reply-To=message-idReferences=message-id1%0A%20message-id2%0A%20message-idbody=somebody%20wrote:%0Aline%20of%20text%0Asecond%20line%0A
which is an RFC 2368 compliant mailto URL, at least if the 'body'
contains only 7-bit characters, but it is not really intended to be used
in this way, and I have no idea how many MUAs support it, particularly
if the body= part were long, and what it would look like if the original
message were not just plain text.
If you want things like quoting only selected text, the digest would not
only need to be an HTML page, but an HTML page with javascript. Would
you use an MUA that executed javascript in HTML email? Even Microsoft
eventually figured out that automatically running executables in email
was a really bad idea, no matter what useful things could be done with it.
So, again, the main question is if it could use just enough HTML
formatting to make the features I outlined work for the majority of
modern email clients, while still maintaining readability for those that
may not be able to make use of the interactive features. If it can, then
I think this would be an awesome option for those of us who subscribe to
a whole bunch of email lists. I subscribe to most as individual messages
only because interacting with the list via a Digest message is very
frustrating and requires lots of copying and pasting, and still breaks
threading etc because of the missing headers.
I actually find interacting with the MIME format digest where I have the
ability to open any specific message of interest and reply to it (even
quoting only selected text if the MUA supports it) to be fairly
painless, and it doesn't break threading.
Reply List is not offerred for a reply to a message from the
MIME digest, because there is no List-Post: header in the
individual message parts
I'm curious why? If I had received the message individually, there
would have been, so why not include them in messages in the digest?
I suspect this probably could be handled by the existing configuration
options in almost all cases.
Cool... so, do I need to send a new email to make this Feature Request
official? ;)
No. Just put
MIME_DIGEST_KEEP_HEADERS.append('List-Post')
in mm_cfg.py.
--
Mark Sapiro m...@msapiro.netThe highway is for gamblers,
San Francisco Bay Area, Californiabetter use your sense - B. Dylan
___
Mailman-Developers mailing list
Mailman-Developers@python.org
http://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Feature Request - Interactive HTML Digests
On 2/20/2010 10:53 AM, Stephen J. Turnbull wrote: Tanstaafl writes: Exactly. Special HTML and lowest common denominator HTML don't mix. (Yes, that's mere word play, but in this case the parallel happens to work.) Well... I only meant special in the sense of the use case... not the HTML code that would be needed. My users expect to be able to view the messages in a digest as an email folder. That's the most important digest feature for them; I wouldn't have had a clue what you're talking about here, but maybe you're talking about the Vi-in-Emacs feature Barry mentioned? If so, that's fine - I'm not suggesting that the current digest offerings be changed in any way, shape or form, so implementation of this feature request wouldn't affect your users in the slightest. they do not want to have to page through messages they don't care about to get to the ones they do care about, Nor do I, but I don't use Vi-in-Emacs, so my feature request is to allow a way for people who don't use it to be able to use digests but not have to page through messages they don't care about to get to the ones they do, and easily interact with them without breaking threading for everyone else. Oh - and if you aren't talking about Vi-in-Emacs, no offense was intended, and I'd really like to know what you meant by 'view the messages in a digest in an email folder'... :) and they expect to use their normal MUA commands, not HTML fragment addresses in links, to navigate. See above. No one would force anyone to choose this new digest version. Really? I haven't had a problem like that for 15 years. (But then, I've exclusively used Emacs-based MUAs for 25 years, which might have something to do with it.) Ya think? ;) I think you should post a bug report (weirdly enough) to the Mailman project on Launchpad.net. There's also a wiki page for Mailman 3 (I forget the address exactly but it's linked from http://www.list.org/) that you could update. Thanks, I'll do one of those tomorrow (gotta run now)... You don't have to do it yourself, but if that doesn't get done by somebody, experience shows that the request tends to get lost. I know - I've really been making a nuisance of myself on the Mozilla Bugzilla for that very reason... -- Best regards, Charles ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Feature Request - Interactive HTML Digests
Tanstaafl writes: On 2/20/2010 10:53 AM, Stephen J. Turnbull wrote: My users expect to be able to view the messages in a digest as an email folder. That's the most important digest feature for them; I wouldn't have had a clue what you're talking about here, but maybe you're talking about the Vi-in-Emacs feature Barry mentioned? VM. Yes. Also Gnus does this the same way. I believe pretty much all of the major Emacs MUAs do it this way. Online manual (older version): http://www.wonderworks.com/vm/user-manual/ Current development: http://www.nongnu.org/viewmail/ they do not want to have to page through messages they don't care about to get to the ones they do care about, Nor do I, but I don't use Vi-in-Emacs, so my feature request is to allow a way for people who don't use it to be able to use digests but not have to page through messages they don't care about to get to the ones they do, and easily interact with them without breaking threading for everyone else. How do you propose to get that effect though? HTML is not designed to make it easy! I'd really like to know what you meant by 'view the messages in a digest in an email folder'... :) Here's my MUA reading a digest in my main mail folder INBOX: http://turnbull.sk.tsukuba.ac.jp/outgoing/INBOX.png and here's my MUA reading the messages in the digest: http://turnbull.sk.tsukuba.ac.jp/outgoing/AUCTeX.png If the players didn't have numbers on their jerseys, I bet it would take you a minute to figure out Who's on First. See above. No one would force anyone to choose this new digest version. That's not the point. The point is that in my experience these are minimum requirements for a digest view, and I don't see how you plan to implement that in portable HTML unless you make *really* draconian restrictions on what formats people are allowed to post in. I think you should post a bug report (weirdly enough) to the Mailman project on Launchpad.net. Thanks, I'll do one of those tomorrow (gotta run now)... It looks like somebody has borrowed Guido's time machine and the feature (ie, List-Post in each message in digest) is already implemented. But it's not default yet, so you could ask for that. ;-) ___ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
