Re: return reciepts
On Sat, Jul 03, 2010 at 12:12:38AM +0200, Rado S wrote: Your original request just sounds like reversing the default from mostly no r-r, with manual exceptions to mosty _DO_ r-r, with manual exceptions, it actually requires you still to make a manual choice... That is not at all what I want. The default is NOT to request reciepts, and that won't change. But in some cases I do want to request them --- and that without having to add header lines manually, which is inconvenient and too easy to forget. Let me add that you just got me to the idea that a simple yes/no for a combination of recipients won't suffice: It would have to be always/once/no/never, meaning that for the combination of recipients in question, the requesting of reciepts would either always be enabled or for that particular message only or no reciept for the particular message will be requested or reciepts are never requested. No doubt that the kind of support for reciepts I have in mind could be used otherwise, but how someone makes use of a feature is always up to them. It's a common feature in many MUAs, so mutt could as well support it --- or there could already be a solution. You've been given technical details elsewhere. I once thought it would make things easier for me and worked with it myself, until I realized it didn't improve anything really, just added more overhead for the sender creating and the recipient dealing with it. That's the way it is now, I agree. It is why I'm looking for a better solution that avoids these disadvantages. Wasted effort compared to an editor macro to add some line like please acknowledge receipt and respond ASAP. What makes you think that the recipient would bother to write an answer? It would involve even more overhead for them to manually write and send a response than it is to use a feature of their MUA that reduces the overhead to just pressing a single key --- or doesn't involve any overhead at all for them because they have chosen to always automatically send reciepts when requested. Practice has shown that it is not best practice. Because of poor support, maybe :)
Re: return reciepts
* lee l...@yun.yagibdah.de [07-03-10 09:13]: On Sat, Jul 03, 2010 at 12:12:38AM +0200, Rado S wrote: Practice has shown that it is not best practice. Because of poor support, maybe :) Or, more likely, requests for features that most do *not* want presented in a haughty manner which would require coding and where work-a-rounds have been presented. -- Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://counter.li.org
Re: What map is default for .maildir?
On Fri, Jul 02, 2010 at 04:23:18PM +0200, lee wrote: On Thu, Jul 01, 2010 at 01:33:09PM -0800, rog...@sdf.org wrote: In another shell within GNU Screen, I successfully did a stuff command to refresh the Mutt display using one of it's key bindings every 60 seconds: screen -X at Mutt stuff $'echo refresh key' Not sure what you mean, Ctrl-l doesn't work for you? No, CTRL-L does not work at all. I must use TAB or 'c' key to refresh the folder list (while in browse map) to show new emails. However, once I navigate into sub folder, Mutt then auto refreshes and shows when I have new email, but only for that folder - of course. As I recall now, the GNU Screen stuff command I used, more then likely echo'ed the terminal value of the TAB key into the Mutt screen tab. It performed quite lovely, but the cleaner method would be to hack/patch Mutt with appropriate C coding. -- Roger http://rogerx.freeshell.org/
Inline PGP encoding in Enigmail
Hello everyone. There is a thread currently going over in the Enigmail mailing list that draws on Evolution's design and the choice made to use PGP/MIME encoding, as opposed to inline, for sending. It also touches on Mutt and its choice with respect to that same decision. http://mozdev.org/pipermail/enigmail/2010-July/thread.html Subject: [Enigmail] Request for PGP/MIME as default setting It may be of interest to those knowledgeable. Some are saying that it was a bad decision to use inline encoding. I do not take that position and maintain that mime encoding is superior. PS Sorry for posting to dev and users. I wasn't sure which group this was more appropriate for. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com signature.asc Description: This is a digitally signed message part
