[Mailman-Developers] Re: Mailman => Mailmisery
Oh... please... just stop, I'm so sick of the PC crap, and that is the last thing that MailMAN or any other FREE (as in LIBERTY) project needs to be worried about. On 7/30/2023 4:06 AM, thomasa...@gmail.com wrote > Hi there, > > Mailman is so old-fashioned as name and man dominated in respect to the > gender discussions. It is time to rename it to Mail-Miss, MailMom or > Mail-Woman for a while?. > > Better neutral: (MailHuman or even:) Mailpeople. > > If you de-attach from the "postman" and "running man" probably a "Mailmatch" > or best: "Mailme" would fit. (Also Mailmoon and Mailmood are possible). > > Words That Start With M | Britannica Dictionary > https://www.britannica.com/dictionary/eb/3000-words/alpha/m > > Otherwise add a star to the Mailman* to indicate it stands for men, women and > divers people delivering mail, and give a press release. > > Otherwise it might be a mailmisery. > > Thanks for a change with the next update release. > Regards Tom > ___ > Mailman-Developers mailing list -- mailman-developers@python.org > To unsubscribe send an email to mailman-developers-le...@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 > ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@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
[Mailman-Developers] Re: Creating new Variables in the Database
On 5/15/2019, 4:56:22 PM, Mark Sapiro wrote: > I've seen lots of sites, mostly having to do with purchasing or donating > money that warn you that clicking whatever more than once will result in > a duplicate charge. > > If you really think this is a bug in HyperKitty rather than a bug in > your browser or just user error, how do you suggest we fix it. I've always wondered about this. It seems to me that code could be written to put the interface in somce kind of state where it wouldn't accept another click once a successful click > transaction had been initiated. Maybe there are technical reasons this isn't as easy as it sounds like it would be? ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@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
Re: [Mailman-Developers] RELEASED: GNU Mailman (core) 3.0b5
On 1/7/2015 2:13 AM, Paul Wise pa...@bonedaddy.net wrote: On Wed, Jan 7, 2015 at 3:09 PM, Tanstaafl wrote: Not for those wanting to avoid systemd. systemd is optional and easy to avoid in Debian. Until it isn't, and that is the overriding concern, and with very good reason considering the relatively short track record that systemd has. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman (core) 3.0b5
On 1/7/2015 4:21 AM, Geoff Shang ge...@quitelikely.com wrote: On Tue, 6 Jan 2015, Tanstaafl wrote: On 12/30/2014 2:39 PM, Barry Warsaw ba...@list.org wrote: * A release, which remains on Python 2.7 * B release, which is only compatible with Python 3.4 So, wheezy admins will be left out in the cold. Wheezy has Python 2.7. And 3.2... and that is the problem. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman (core) 3.0b5
On 1/7/2015 10:37 AM, Barry Warsaw ba...@list.org wrote: Let me ask again: if you have to install MM3 from source anyway (and probably many of its dependencies), why is it also a problem to install Python 3.4 from source? Maybe I missed that question (sorry, currently out of the country)... Good point, hadn't considered it... Sorry for the noise... ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman (core) 3.0b5
On 1/6/2015 8:36 PM, Paul Wise pa...@bonedaddy.net wrote: On Wed, Jan 7, 2015 at 1:48 AM, Tanstaafl wrote: So, wheezy admins will be left out in the cold. I expect Debian jessie will become Debian stable soon enough. Not for those wanting to avoid systemd. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] RELEASED: GNU Mailman (core) 3.0b5
On 12/30/2014 2:39 PM, Barry Warsaw ba...@list.org wrote: * A release, which remains on Python 2.7 * B release, which is only compatible with Python 3.4 So, wheezy admins will be left out in the cold. Bummer... :( ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Python 3
On 12/26/2014 4:25 PM, Barry Warsaw ba...@list.org wrote: On Dec 26, 2014, at 08:48 PM, Geoff Shang wrote: FWIW, Debian Jessy (aka Testing/Frozen?) has Python 3.4.2. Yep, Jessie will have 3.4, and Ubuntu has had it since Trusty Tahr (14.04 LTS). I don't know about other distros. First, Jessie is not even released yet, wheezy is the current stable, and still has a long lifecycle remaining. Second, I (for one, but there are many other debian admins maintaining servers who feel the same) will not be upgrading my wheezy install to jessie due to the ongoing systemd debacle. Locking them out would be a mistake, imo. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Fixing DMARC problems with .invalid munge
On 5/21/2014 12:14 PM, Ian Eiloart i...@sussex.ac.uk wrote: And, it’s not abusive if appropriate SPF checks are done first: obviously, you don’t do the callout if you get an SPF fail. A callout with an SPF pass isn’t abusive: if the domain sent me an email, then it should be able to handle a callout. You are wrong. Minimizing the use of SAV is always best if you are going to use it, but you should only use it with sites that you have an understanding and agreement in place where they formally tell you its ok. Anything else is, indeed, abusive, regardless of your personal opinion on the matter. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSOC 2014: CI tool for the Mailman suite and postorius improvements
On 4/30/2014 10:11 AM, Barry Warsaw ba...@list.org wrote: Thanks for giving me opportunity to work with mailman community this summer. I'm an undergraduate student from Manipal Institute Of Technology, India and i'll be working on project CI tool for the Mailman suite and postorius improvements. I would love to get feedback and suggestions from the community regarding my project which involves: 1. CI tool for Mailman Suite (mailman core, postorius, hyperkitty) 2. The UI Testing Framework for Postorius I am in process of discussing the best possible implementation for this project with my mentors and advice from the community for the same will be very helpful. One of the things I think is critical for the core, is testing it against supported the two supported db backends, SQLite and PostgreSQL. ? Not fully supporting the most popular (mysql/mariadb)? ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] GSoC 2014 : Proposal for the Mailman CLI project
On 4/27/2014 11:03 AM, Stephen J. Turnbull step...@xemacs.org wrote: When you get ~250 wanted mails (many of them list, of course) and ~1000 spams (that get past the 6-sigma if this filter thinks it's spam, throw it away! filter) a day, automatic processing is really important. ? Anyone who gets ~1000 spams per day that actually make it through whatever anti-spam tools you are employing, then you need different/better anti-spam tools. ___ Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
Re: [Mailman-Developers] Mailman 2.1.15 final released.
On 2012-06-15 1:04 PM, Mark Sapiro m...@msapiro.net wrote: Python 2.4 is the minimum supported, but Python 2.6 is recommended. This release should work with Python 2.7, but has not been tested with that version. I'm curious about why 2.7 isn't officially supported (current stable is already at 3.2.x)? I've been running 2.1.14 with 2.7 (now at 2.7.3) since it went stable (I'm on gentoo) with zero problems... but am I asking for trouble? ___ 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] Mailman 2.1.15 final released.
On 2012-06-15 4:28 PM, Mark Sapiro m...@msapiro.net wrote: Tanstaafl wrote: I've been running 2.1.14 with 2.7 (now at 2.7.3) since it went stable (I'm on gentoo) with zero problems... but am I asking for trouble? I don't think so. Ok, thanks - and as always, thanks very much for mailman! I'm really looking forward to the 3.0 release... ___ 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] [HyperKitty] Rating of posts
On 2012-06-06 3:24 PM, Pierre-Yves Chibon pin...@pingoured.fr wrote: On Wed, 2012-06-06 at 00:43 -0400, Aamir Khan wrote: In this case each upvote/downvote will be saved as a separate row in database. Your suggestions? I actually would like to ask you to think at a broader level. Could you provide us a database schema on how it would look ? You would have a user table, I assume, the tables for the archives and I would like you to consider in your design ratings but also the category and tags assigned to the emails. I would also like to see a way for each user to be able to rate other *users*, not just their individual posts... An example with this list: I would rate Mark Sapiro as '5' (or whatever was designated as 'highest value'), so whenever I sort answers to any particular questions, Marks answers should appear at the top of the results before anyone else's (even if someone else's post had a higher rating than Marks for a particular thread) - then would come the individual posts from other users (who I hadn't yet rated)... Hope that made sense... ___ 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] GSOC - Archives UI for mailman: Use cases
On 2011-04-12 12:29 PM, Dushyant Bansal wrote: Handling Top/Bottom Posting /By default, the quoted text can either be all hidden or all displayed. It might also be good to only hide the quoted text when it is at the end of the message, as when it is in the middle, the user is likely to want to see it for context. / -On mailing lists, people generally use 'inline posting' to reply. One level of inline posting is helpful to see the context, but if it goes beyond one level then, it might be a good idea to hide the old quoted text. As long as it is togglable, this is a great idea... I've been using the QuoteCollapse extension in Thunderbird for a long time and it works great... doesn't handle all use cases (like broken MUA's that don't use proper quote characters), but for the most part works very well... ___ 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] MM3 nntp support?
No response? Tanstaafl wrote: Hello, Back in December Barry had mentioned that he was exploring adding nntp (and IMAP) support to the archives, but didn't clarify much further... and I googled quite a bit, and these 2 or 3 posts on the subject is all I could find.: Re: [Mailman-Users] NNTP server for local newsgroups ? John Fitzsimons Tue, 22 Dec 2009 14:44:10 -0800 On Mon, 21 Dec 2009 22:13:15 -0500, Barry Warsaw wrote: On Dec 21, 2009, at 7:36 PM, John Fitzsimons wrote: Hi Barry, In another thread we were talking about Mailman to web forum options. As Mailman can manage NNTP I wondered whether anyone here had come across an NNTP server for local (not usenet) newsgroups ? Yes. I intend to explore using Twisted in Mailman 3 to provide NNTP and IMAP access to Mailman archives. My question is - would this (hopefully? please!?) also include posting support from a newsreader, so that nntp users could also interact with the list discussion(s) using their preferred newsreader? Or was this for reading only? Thanks, 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
[Mailman-Developers] MM3 nntp support?
Hello, Back in December Barry had mentioned that he was exploring adding nntp (and IMAP) support to the archives, but didn't clarify much further... and I googled quite a bit, and these 2 or 3 posts on the subject is all I could find.: Re: [Mailman-Users] NNTP server for local newsgroups ? John Fitzsimons Tue, 22 Dec 2009 14:44:10 -0800 On Mon, 21 Dec 2009 22:13:15 -0500, Barry Warsaw wrote: On Dec 21, 2009, at 7:36 PM, John Fitzsimons wrote: Hi Barry, In another thread we were talking about Mailman to web forum options. As Mailman can manage NNTP I wondered whether anyone here had come across an NNTP server for local (not usenet) newsgroups ? Yes. I intend to explore using Twisted in Mailman 3 to provide NNTP and IMAP access to Mailman archives. My question is - would this (hopefully? please!?) also include posting support from a newsreader, so that nntp users could also interact with the list discussion(s) using their preferred newsreader? Or was this for reading only? Thanks, 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] Mailman user interface: draft of a mega drop-down navigation
On 2010-06-24 12:09 PM, Barry Warsaw wrote: On Jun 24, 2010, at 11:37 AM, Terri Oda wrote: I also reiterate that we need a search option for finding admin options. There's just too many for average list administrators (who probably use this part of the interface once a month or less) to remember the hierarchy. Most people nowadays seem to be heavily reliant upon search. +1 Searching on variable name and description at the least (which we should probably improve too ;). How about also including a checkbox option (unchecked by default) to 'include online Knowledgebase/FAQ in seach results' (separated from hits in the Admin intrfce itself)? Or would that be overkill? ___ 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 2010-02-24 7:44 PM, Mark Sapiro wrote: I think possibly a better approach might be to take the present MIME format digest and convert the 'contents' part to an HTML part Sounds like you're talking about 'encapsulating' it to me... ;) sorry couldn't resist... where clicking on a message subject would cause the MUA to open that message in a separate window/tab from where it can be viewed in it's full richness and replied to. I don't offhand know if such a thing can be done or if so, what MUAs might support it. Hmmm... I actually really like this suggestion, especially if it might be [much?] easier to implement. Worth exploring at least. But, instead of clicking on the subject - which wouldn't be very intuitive to me - I'd prefer just a single 'Open to Reply' link, which would open the message as you described. Then, as you said, it would be up to the MUA features to do the heavy lifting. This would be perfectly acceptable to me, especially if it is an order of magnitude easier to accomplish. Too bad it isn't possible to keep the individual messages as attachments and work with them that way... Hmmm... another brain-dead suggestion... keep the messages fully intact as attachments, but also convert/dump the plain-text content into the Digest body for purposes of scrolling between messages and the message summary at the top? Yes, it would increase the size of the digest - but text is small, so maybe it wouldn't be all that bad? Then the link would be either 'Open to Reply', or, if the original message was other than text/plain, the link could change to 'Open to Reply/View in Original Format'. I think this thread would be better off if you would concentrate on the features you want and let those who might implement them figure out how or if they can be provided. Ok, I'll try... sorry for wasting all of you guys' time... -- 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
On 2010-02-23 4:52 AM, Stephen J. Turnbull wrote: Tanstaafl writes: Stephen J. Turnbull wrote: Simple HTML simply doesn't lend itself to encapsulating structured documents, except with devices like frames. All I mean by 'simple' is simple enough that most mail clients capable of rendering HTML email won't have a problem with it, and the fact is, most can render fairly complex HTML. My turn to *sigh*. I *know* what you mean. I am telling you that in my opinion it will require quite a bit of effort to write a program (or Mailman function) to create HTML that does the job for a wide enough selection of MUAs. You also seem to be missing the fact that I've already said I didn't expect (hoped? maybe) that *all* of these features would be implementable, and certainly not immediately. I didn't actually come out and say it, but what I was asking for was just the framework... So how about this... 1. Create the new Digest format, but only add the very-most-basic features that can easily be added... like, for example, make the messages in the message summary hyperlinks that scroll down to the message, and add 'back to top' links at the top/bottom of each message. If some basic Reply mailto links could be added that maybe simply grabbed the subject, that would be a bonus, but not necessary. Maybe it would also be possible to mimic the google 'threaded' digest feature, where each thread is grouped in the digest (based on the date of the first post), *but* only the first post of the thread has an entry in the message summary at the top, with a [##] in parenthesis denoting how many messages exist for that thread. This keeps the message summary much shorter and more manageable, especially for high volume lists. Also, maybe peeking at the message source for one of the Yahoo and Google Digests could make this easier... 2. Make it template based, so as to be easily modifiable by the MM admin. This way, if some HTML magician comes along and likes the concept, they could not only easily do so, but could also easily contribute their changes to the community once they have been confirmed to work in most MUAs that render HTML emails. Obviously, there would also have to be a back-end function that manipulates the individual messages that the MM admin can also play with, but I don't see this as a real problem as long as that function only affects the hmtl digest, and doesn't mess with any other MM functions or does nothing more than read in the individual messages for manipulation for the digest. I'm not going to work on it myself, because I don't think the benefit (to others)/cost (to me) ratio is anywhere near high enough. That's mostly because I see supporting this feature as an unending time sink for the next 5 years, because HTML is just not intended to be used for this purpose. I'd argue that HTML support in mail clients will only get better over time, making adding new features easier and more manageable... So far, I think Mark agrees. Well, I wouldn't presume to speak for Mark, but I the more complex features, like the Reply links and not breaking threading I'm not going to work on it myself, because I don't think the benefit (to others)/cost (to me) ratio is anywhere near high enough. That's mostly because I see supporting this feature as an unending time sink for the next 5 years, because HTML is just not intended to be used for this purpose. Well, no offense, but by that argument, we'd all still be in flintstones vehicles, because the concept of 'the wheel' was never intended to be used in an internal combustion engine - until it was. ;) -- 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
On 2010-02-20 11:31 AM, Mark Sapiro wrote: 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. Yes, that works (except the Reply-To_List, which I think will be fixed by changing the default soon?), but I'm curious (maybe I'm missing something obvious?)... In a digest with lots (hundreds) of messages with long threads, how do you know which individual/attached message to open so you can then Reply as desired? Or... do you use EMACS too? :( -- 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
On 2010-02-22 12:15 PM, Mark Sapiro wrote: What does encapsulation mean to you? In the context of this discussion, a way of 'wrapping up' the individual messages in such a way as to be able to be both manipulated by the html code, and to control how they are displayed/presented. Thus, you are reduced to something like HTMLizing the current plain text digest with links to all it's scrubbed attachments and HTML parts. This would be acceptable for lists that accept plain text only, but I'm not sure it would work well for other lists. Honestly, I'd be fine with this new HTML digest being limited to only plain-text based lists, at least at least and until some python/html guru came up with the code to make it work reasonably well for HTML based lists too. As I have mentioned in other posts in this thread, the 'reply*' buttons are doable with mailto: links provided you don't want any special features like quoting selected text. The mailto: could include a body= fragment that was a quoting of the entire (plain text) message being replied to, but if you want to quote selected text, you'd have to select the text and then use the MUA's 'reply-list' button to generate the reply, but then you don't have the proper subject or the in-reply-to and references for threading. Anything else requires javascript behind the button. Wow - I must have missed the significance of it when you said it... if you are actually saying that grabbing the in-reply-to references would be doable, then this would be more than enough to make me happy. :) Grabbing the subject would be an even bigger bonus. ;) But no, quoting selected text is a very distant second to the Reply buttons, and something I'd be ok with never being implemented... Defaulting to keep the List-Post header in the MIME digest messages is easy enough. I can do that if no one comes up with a good reason why not. Barry mentioned List-Post for other lists/umbrellas, but CookHeaders already removes those. Thanks a lot Mark, Stephen and Barry for taking the time to respond to what must be - to you - a very ignorance-based discussion from my side. -- 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
On 2010-02-20 11:31 AM, Mark Sapiro wrote:
On 2/20/2010 4:09 AM, Tanstaafl wrote:
On 2010-02-20 1:23 AM, Stephen J. Turnbull wrote:
Tanstaafl writes:
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.
Actually, I was talking about (though admittedly wasn't very clear)
whether or not MM3 could work some magic when building the digest to
make this work.
Meaning, MM has the individual, fully intact messages, including the
full headers - so I was thinking that *maybe* (I'm not saying it can be
done, I'm asking the question) it could work some kind of magic through
some scripting on the backend, to build an HTML digest with embedded
links that could somehow invoke *the MUAs* Reply functions, but feeding
the MUA what is necessary to make it *think* it is replying to the
individual message rather than the digest.
But maybe its just not possible...
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.
Ok, agreed about the JS, but again I was thinking this could be left to
the mail client - if *it* is capable of quoting only selected text, then
it would 'just work'... I mean, it works now in TB3, so...
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.
Ok, but this doesn't work for me right now with the mailman-users list,
apparently because the List headers aren't there?
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
No. Just put
MIME_DIGEST_KEEP_HEADERS.append('List-Post')
in mm_cfg.py.
But I can't do that for lists that aren't under my control...
My question was about where to add a feature request to:
1. make this a configurable option in the GUI, and
2. make it enabled by default with a similar 'strongly recommended'
comment next to it like it is with the same setting for individual
messages.
Although I can't think of any, apparently I'm missing something else and
there is one or more good reason[s] I haven't thought of to do this,
otherwise it would already be the default?
Anyway, thanks for taking the time to consider this and respond as you
all have...
--
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
On 2010-02-22 9:13 AM, Stephen J. Turnbull wrote: Tanstaafl writes: That's not the point. The point is that in my experience these are minimum requirements for a digest view, Sorry, maybe I'm dense but I don't know what you mean by 'these' when you said 'these are minimum requirements'... and reading the previous messages wasn't helpful either... Navigation, navigation, and navigation. Ok... but again (how many times have I said this now??), the current MIME and plain text digest versions will continue to work as they currently do. Someone would have to explicitly choose this new digest, and only someone who had a compatible mail client would/should be doing so - and would find out quickly enough that their mail client isn't compatible if that was the case. So, you can still navigate your digests the way you always have. What this feature request would do is enable those of us who use non EMACS based GUI mail clients to have an effective way to interact with digest messages too. Those parts are basically trivial, yes. The problem is messages that are originally HTML mail, and perhaps attachments. Ok, I can see that attachments is one thing I hadn't considered... I don't know how those could be handled... Mark had said that this request would require that the digest be one big inline HTML message - but maybe this could be handled by the 'encapsulation' process. Again, I'm asking questions, and please remember these questions are coming from a non-programmer, so if they are self-evidently stupid from a programmers point of view - well, that's why. The thing is that the users I'm used to don't want to change interfaces ... sigh See above comment re: navigation... Being that I'm not a programmer, maybe I just don't know enough about what can and can't be done, but my thinking was that the headers of each message could somehow be 'encapsulated' and hidden (ie, not 'rendered') in the generated 'Interactive HTML Digest' in such a way that would allow the more complex 'special features' in this request to work. Headers are not a problem; Mailman already does filter out many uninteresting headers in the plain text digest. The problem is if the message itself is structured, such as in HTML, or containing attachments. Yes, but the headers don't have are a separate MIME part that don't have any HTML formatting, right? So, any back-end code that worked its magic on the headers (which is where all of the information is that would allow Replies to not break threading is contained) would work on HTML messages too, right? Or, if not, what am I missing? Simple HTML simply doesn't lend itself to encapsulating structured documents, except with devices like frames. All I mean by 'simple' is simple enough that most mail clients capable of rendering HTML email won't have a problem with it, and the fact is, most can render fairly complex HTML. 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. ;-) H... is there an option somewhere to enable it? I don't see anything in the Digest Options for any of the lists I manage... No. Mark explained how to get that, you need to access the command line interface and change the list config to add the List-Post header to the keep list. I think that rather than have an option it might as well be the default to keep it. Agreed... -- 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
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
