Re: How to send a return receipt
On Tue, Oct 16, 2007 at 06:32:00PM EDT, Derek Martin wrote: [..] > Maintaining patches for features that lots of people want is a stupid > waste of work. If the maintainers don't want to maintain the code, > then they probably should stop being maintainers. Please be more specific. What are those "features that lots of people want" and that are absent from mutt? I have used mutt for about three years and I never once had the feeling that anything was missing. Thanks, cga
Re: How to send a return receipt
On Tue, Oct 16, 2007 at 04:08:24PM -0600, Charles Cazabon wrote: > Derek Martin <[EMAIL PROTECTED]> wrote: > > On Tue, Oct 16, 2007 at 09:46:19PM +0200, Rado S wrote: > > > It's not a bug but a feature that not everything that is possible is > > > built-in but must/can be accomplished elsewhere. > > > > I have always, and still do find this argument to be um, less than > > well thought out (to put it extremely mildly). Adding features does > > not inherently add bloat; > > Actually, it does. Every feature, and every line of code generally, incurs > both a development cost, and maintenance costs. This is not the same as bloat. From Merriam Webster: bloat - n. 1 a: one that is bloated b: unwarranted or excessive growth or enlargement Growth is not inherently unwanted or unwarranted or excessive. So, no, it actually doesn't. Clean code added to address the needs of the users is inherently not bloat. > If your pet feature is minimal code, but the developers don't want > to include it because what you're asking is already possible another > way -- just maintain a local patch for it. Every time you want to > upgrade, apply your patch to the fresh code -- voila. You get your > feature, and the developers don't get the development, testing, and > support overhead associated with it. Everyone wins. Yes, I've done > exactly this myself. So have I, and it sucks. Every time I had to update the patch, I couldn't help but think, "the fact that I have to do this is retarded." Patches that don't get added to the code base need to be maintained... even small ones. My patches eventually did make it into mainstream mutt, and as such required far less maintenance, because the code they touch rarely changes significantly, but just enough that creating a new patch was needed fairly frequently. Maintaining patches for features that lots of people want is a stupid waste of work. If the maintainers don't want to maintain the code, then they probably should stop being maintainers. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpNn2dGz8Dtx.pgp Description: PGP signature
Re: How to send a return receipt
Derek Martin <[EMAIL PROTECTED]> wrote: > On Tue, Oct 16, 2007 at 09:46:19PM +0200, Rado S wrote: > > It's not a bug but a feature that not everything that is possible is > > built-in but must/can be accomplished elsewhere. > > I have always, and still do find this argument to be um, less than > well thought out (to put it extremely mildly). Adding features does > not inherently add bloat; Actually, it does. Every feature, and every line of code generally, incurs both a development cost, and maintenance costs. Every feature adds maintenance time for bug testing, developer documentation, end-user documentation, regression testing, developer support, end-user support, etc. It's a fairly significant burden, and it's the best damn reason for rejecting calls for "features" adding little or no new functionality not possible with the existing code, even when the people calling for it say "but it only adds 20 lines of code, that takes like ten minutes". I'm not referring only to mutt here, either. If your pet feature is minimal code, but the developers don't want to include it because what you're asking is already possible another way -- just maintain a local patch for it. Every time you want to upgrade, apply your patch to the fresh code -- voila. You get your feature, and the developers don't get the development, testing, and support overhead associated with it. Everyone wins. Yes, I've done exactly this myself. Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/software/ ---
Re: How to send a return receipt
On Tue, Oct 16, 2007 at 09:46:19PM +0200, Rado S wrote: > =- Patrick Schoenfeld wrote on Tue 16.Oct'07 at 21:24:22 +0200 -= > > > In fact mutt is the only mailer I found not supporting it > > Return-receipts being standard replies with a preformatted content > (nothing special about them), mutt _does_ support them, just not > built-in as you would like it to be so that you don't have to tweak > the config as freely as you must, sorry: _can_. Imagine all that > could be usefully done with external resources built into mutt, it > would become as chunky and bulky as the bad rest. > It's not a bug but a feature that not everything that is possible is > built-in but must/can be accomplished elsewhere. I have always, and still do find this argument to be um, less than well thought out (to put it extremely mildly). Adding features does not inherently add bloat; and in general, if adding a commonly requested feature requires the addition of a bunch of crap code, then the current design of the program (or perhaps the design of the implementation of the new feature) is broken. So if you are balking at implementing a feature for this reason, it's probably a good sign that a rewrite (of something) is needed. If a function is e-mail related, and commonly supported by other mailers, then it seems to me Mutt should have built-in support for it too. Mutt is a Mail USER Agent (not a mail DEVELOPER agent), and it should interoperate with other mailers, and should do everything that users commonly want to do with mail without a lot of fuss. The only things that should require fuss are things that are not commonly wanted by common mail users. And don't forget that just because YOU don't find any value in a feature, that doesn't mean it's not a feature that common users want... Otherwise, mutt will not suck less than the rest. Almost any feature can be passed off to some helper program, but very often doing so is annoyingly clunky and/or inflexible. Very often it's hard for a user to get a helper program which works sanely in his environment. And ultimately, who wants to have to install 100 programs to deal with mail? But this is where the current philosophy is headed... add 100 features, install 100 programs. Linux users are lucky in that most such programs are commonly pre-installed with their distro, and the design philosophy of Mutt generally reflects that fact. But Linux isn't the only game in town, and the "Unix Philosophy" development model is not very scalable in such a context, especially if you have to deploy 1000 Unix workstations that don't come with any of the helper programs you need to make your application work in your environment (and most especially if they need different configurations, preventing one from easily creating, say, a tarball with all the required software). -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpJ5CszzC7yZ.pgp Description: PGP signature
Re: No thread indicator
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Rem P Roberti <[EMAIL PROTECTED]> [10-16-07 16:36]: > I just recently noticed that I no longer have threads indicated in the > the index. I'm not sure how that happened but I would like to fix it. first three places to look 1. egrep thread\|sort ~/.muttrc 2. grep thread\|sort /etc/muttrc 3. man mutt <- search for... thread & sort then return with remaining questions accompanied with results from the first two. gud luk, - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4-svn4472 (GNU/Linux) iD8DBQFHFSjEClSjbQz1U5oRAurKAJ9SLiYqBhvoTCPu9xpsq7LGgVLatACfSIeS 7Z8z1AN9XyVsAX3/WKWoDug= =n38i -END PGP SIGNATURE-
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Tue 16.Oct'07 at 22:26:05 +0200 -=
> Additional the feature (to be comparable) it is a notification
> that the sender asked for a return receipt and it is a
> one-action-thing to confirm this.
> {...}
> You keep talking like it was a simple configuration change, but
> thats not true.
Notify:
color header ^dispo... color1 color2
color index ~h '^dispo...' color3 color4
unignore dispo...
With the help of procmail and mutt's x-label feature you could do
other things, too, based on that Dispo... header.
One action: macro(s).
Simple to me.
> Off course it is possible to workaround the missing builtin
> support. But don't talk about it like it would be anything other
> then a workaround, cause that is what it basically is.
Well, milage varies. Some like mutt for its current nature of
simplicity and flexibility. Obviously not all do, and prefer mutt to
transform into some suit-all-easily beast, which requires some more
code not used by all/ many "classic" mutters. As usual, we never
know the exact numbers and therefore who's right.
> Tell me: Why do you keep telling something thats _untrue_?
It's true ... to me. I can only speak for myself based on what I
know and need (for your task).
> Consider the truth: It would be possible to achieve most of the
> requested feature by writting a script that is spawned when a
> message is displayed, using message-hooks.
No message-hooks needed.
> Its also possible to ask a question in this script.
Not needed either: when you see it, you decide to press the key or
not.
> So we reached the goal, didn't we? Yes, we did, but: We must
> depend upon at least two additional components (a script and an
> interpreter), the question is not well-integrated into mutt and so
> the solution is: error-prone and not as comfortable as it could.
> So it is possible, but it is everything but a configurable option.
So are many other things.
It's just one of many other "mutt must have".
--
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.
No thread indicator
I just recently noticed that I no longer have threads indicated in the the index. I'm not sure how that happened but I would like to fix it. Rem
Re: How to send a return receipt
On Tue, Oct 16, 2007 at 09:46:19PM +0200, Rado S wrote: > Return-receipts being standard replies with a preformatted content > (nothing special about them), mutt _does_ support them, just not Well, the problem is that what you describe is not all. Additional the feature (to be comparable) it is a notification that the sender asked for a return receipt and it is a one-action-thing to confirm this. Off course it is possible to workaround the missing builtin support. But don't talk about it like it would be anything other then a workaround, cause that is what it basically is. > built-in as you would like it to be so that you don't have to tweak > the config as freely as you must, sorry: _can_. Imagine all that You keep talking like it was a simple configuration change, but thats not true. Tell me: Why do you keep telling something thats _untrue_? Consider the truth: It would be possible to achieve most of the requested feature by writting a script that is spawned when a message is displayed, using message-hooks. Its also possible to ask a question in this script. So we reached the goal, didn't we? Yes, we did, but: We must depend upon at least two additional components (a script and an interpreter), the question is not well-integrated into mutt and so the solution is: error-prone and not as comfortable as it could. So it is possible, but it is everything but a configurable option. > It's not a bug but a feature that not everything that is possible is > built-in but must/can be accomplished elsewhere. I agree. But just because it is a feature it is not a feature in *every* case. -Patrick
Re: How to send a return receipt
=- Patrick Schoenfeld wrote on Tue 16.Oct'07 at 21:24:22 +0200 -= > In fact mutt is the only mailer I found not supporting it Return-receipts being standard replies with a preformatted content (nothing special about them), mutt _does_ support them, just not built-in as you would like it to be so that you don't have to tweak the config as freely as you must, sorry: _can_. Imagine all that could be usefully done with external resources built into mutt, it would become as chunky and bulky as the bad rest. It's not a bug but a feature that not everything that is possible is built-in but must/can be accomplished elsewhere. (not counting recent exceptions ;) -- © Rado S. -- You must provide YOUR effort for your goal! EVERY effort counts: at least to show your attitude. You're responsible for ALL you do: you get what you give.
Re: How to send a return receipt
Hi, On Tue, Oct 16, 2007 at 11:18:05AM -0400, Jing Xue wrote: > Well, in the corporate* world where people communicate over Lotus Notes or > Outlook, they tend to use mail receipts a lot. And _because_ they all > communicate over the same MUA that supports the feature, it actually does > work and become useful. Yep. It is as it is: Those users of MUAs that support it (actually we talk about MUAs that take at least 50-60% of the "market share" *¹) actually don't know that there are MUAs that doesn't support it. Its existance is natural for them *and* they often have a real world purpose for it. We *have* a real purpose for it, it *is* useful for us. And note that we are not on the sender but on the receipient side. Regards, Patrick *¹ I'm aware that at least Outlook, Outlook Express, Thunderbird, Balsa, Sylpheed, The Bat!, Eudora and Apple Mail support it. In fact mutt is the only mailer I found not supporting it (but that may just be, because i never worked with elm or alpine)
Re: How to send a return receipt
On Tue, Oct 16, 2007 at 11:18:05AM EDT, Jing Xue wrote: > > Quoting Charles Cazabon <[EMAIL PROTECTED]>: > > >The concept of mail receipts is poorly designed; there is no way to > >implement > >a reliable receipt notification system with SMTP mail. *Many* of the > >better > >mail packages therefore do not implement support for it -- why have a > >feature > >if you *know* it can never work properly? > > I think it's an overstatement to say that "it can never work > properly". It's actually "it _might not_ work properly". It still > serves its purpose when it does work - see below. > > >It's also seen as an invasion of privacy. > > It certainly creates some annoyance on the recipient end. But I don't > see how it is an invasion of privacy as long as the MUA has my consent > before sending a receipt. > > >Mail receipts are essentially one of those features that commercial MUA > >vendors include as a marketing checkbox feature, but which serve little or > >no > >useful purpose in the real world. > > Well, in the corporate* world where people communicate over Lotus > Notes or Outlook, they tend to use mail receipts a lot. And _because_ > they all communicate over the same MUA that supports the feature, it > actually does work and become useful. > > Now _I_ don't use these mail receipts, nor do _I_ like getting them, > because of the annoyance factor. But then I respect it when others > request one - at least before they start abusing it. > > My 2 cents. My #1 worry under these circumstances is that when I do accept to send a receipt I would like to be notified that the recipient actually received (and read) my receipt. Is there any way this can be done with mutt? Or Lotus Notes, Outlook? cga
Re: How to send a return receipt
Quoting Charles Cazabon <[EMAIL PROTECTED]>: The concept of mail receipts is poorly designed; there is no way to implement a reliable receipt notification system with SMTP mail. *Many* of the better mail packages therefore do not implement support for it -- why have a feature if you *know* it can never work properly? I think it's an overstatement to say that "it can never work properly". It's actually "it _might not_ work properly". It still serves its purpose when it does work - see below. It's also seen as an invasion of privacy. It certainly creates some annoyance on the recipient end. But I don't see how it is an invasion of privacy as long as the MUA has my consent before sending a receipt. Mail receipts are essentially one of those features that commercial MUA vendors include as a marketing checkbox feature, but which serve little or no useful purpose in the real world. Well, in the corporate* world where people communicate over Lotus Notes or Outlook, they tend to use mail receipts a lot. And _because_ they all communicate over the same MUA that supports the feature, it actually does work and become useful. Now _I_ don't use these mail receipts, nor do _I_ like getting them, because of the annoyance factor. But then I respect it when others request one - at least before they start abusing it. My 2 cents. -- Jing Xue *: that's real enough for me. YMMV.
utf8 encoding problem, but which part?
hi all my problem isn't clear for me, what it is exactly. I became a mail from russia with koi8-u encoding (in mailheader). My system is debian stable. In muttrc, I defined 'set charset=utf-8', the terminal is mlterm (I tried also xterm with the same result) and locale output (see below) shows good. Now, the mailcontent in mutt is right, but if I reply to this (mails open with vim), then there are strange signs there (but only the not-ascii). Regardless if I set ':set encoding=utf-8' in vim or not, vim don't show this characters correct. I tried also emacs, it display exact the same like vim. Now, I don't know where I should begin to debugging and how. Is this a problem of my system, of my terminal, of mutt or vim? I don't know this. I googled a lot, but because I couldn't define my problem exactly, I search in the darkness. Have you any idea for this? thank you. raphael locale: LANG=de_CH.UTF-8 LANGUAGE=de_CH.UTF-8:de_DE:de:en_GB:en LC_CTYPE="de_CH.UTF-8" LC_NUMERIC="de_CH.UTF-8" LC_TIME="de_CH.UTF-8" LC_COLLATE="de_CH.UTF-8" LC_MONETARY="de_CH.UTF-8" LC_MESSAGES="de_CH.UTF-8" LC_PAPER="de_CH.UTF-8" LC_NAME="de_CH.UTF-8" LC_ADDRESS="de_CH.UTF-8" LC_TELEPHONE="de_CH.UTF-8" LC_MEASUREMENT="de_CH.UTF-8" LC_IDENTIFICATION="de_CH.UTF-8" LC_ALL=
Show next mailbox with unread messages
Hi, Is there a way to get mutt to show me which mailboxes there are unread mail in? That is, not new mail (marked with N), but mail I've already seen, but haven't read (marked with O). -- Jostein
