Re: How do you survive without notmuch?
On 11.04.16 11:11, Derek Martin wrote: > On Mon, Apr 11, 2016 at 10:13:06PM +1000, Erik Christiansen wrote: > > In the latter half of several decades of software development, I took to > > heart "Unix _is_ the IDE". Similarly, there's no need for mutt to do > > more than be a good MUA, as perfectly good search capability pre-exists. > > But you must see the flaw with this approach: It requires every user > to make efforts to integrate their own solution for searching for > their mail--a task that seems (to me) very obviously part of what > any typical user would want to do, as part of handling their mail. As > such, doesn't it make sense that the MUA have good searching > capabilities built in? Doing so saves a MASSIVE amount of work, in > man-hours. Whether that's an attempt at humour, or just late for April 1, eludes me. The flaw with the postulating paragraph is that there is no need for integration of "own solution for searching". That is already provided by Unix - for free, as is. As a consequence, the theory that there might be "a MASSIVE amount of work" is purest fantasy. I have done _no_ substantial work, as 'perfectly good search capability pre-exists'. > This is where the Unix Philosophy falls down, IMO. And don't get me > wrong--I'm a fan. But no solution is the right solution for every > problem. Compatible cooperating utilities always beat competing and often conflicting monoliths, in my several decades of experience. The flexibility of combining coherent capabilities to construct an application-specific solution cannot be matched by a user-restricting monolith with a limited set of fixed actions. Your own words make that case for me. No monolith "is the right solution for every problem." That is why a swarm of well-understood smaller combinable utilities is always more flexible, and better able to handle a large variety of problems. The really big benefit of the Unix approach is that the same utility know-how can be applied to every problem, as it is only the mix of utilities used, and their parameters, which vary. With the monolithic approach, the user has to learn a different set of levers to wrangle for every monolith allowed on his system. That can be a massive amount of trial-and-error climbing of learning curve - a completely unnecessary waste of time. Erik -- The ultimate barrier is one's viewpoint. - Terry Pratchett, "The Dark Side of the Sun"
Re: How do you survive without notmuch?
On Tue, Apr 12, 2016 at 05:28:08PM +1000, Erik Christiansen wrote: > > But you must see the flaw with this approach: It requires every user > > to make efforts to integrate their own solution for searching for > > their mail > > Whether that's an attempt at humour, or just late for April 1, eludes > me. The flaw with the postulating paragraph is that there is no need > for integration of "own solution for searching". That is already > provided by Unix - for free, as is. Your solution is to use grep. How well does that work if your mail is stored on an imap server which you don't have shell access to, or in any sort of a server where the mail store is in a database which you again, do not have access to, even if you happen to have shell access to that machine? In this case, the ONLY place to put the search functionality is in the mail client. > Compatible cooperating utilities always beat competing and often > conflicting monoliths, in my several decades of experience. I think I just proved otherwise. The other benefit that a monolith can provide is consistency of interface. That reduces learning curve even further. Of course you can write a monolith that fails at this, but the point would be to NOT do that. ;-) > Your own words make that case for me. No monolith "is the right solution > for every problem." That does not prove your case; it does nothing to prove that a monolith is not better IN THIS SPECIFIC CASE. :) > The really big benefit of the Unix approach is that the same utility > know-how can be applied to every problem, as it is only the mix of > utilities used, and their parameters, which vary. The downside is that typical users don't want to learn all those tools, and by and large have no reason to. They use the web and e-mail, and very little else. All those Unix tools come into play exactly zero if their mail client already has reasonable search capabilities. This is fine for you and me; we have lots of reasons to know those tools. But we have had at least a few non-technical users asking questions about how to do things on mutt-users over the years, and I have to think there are more who don't post or even subscribe. Your solution forces those people to learn a pile of tools they likely otherwise have no use for. That's a monumental wasted effort, if you ask me. Frankly, I love Mutt, and I'm plenty technical; but I'd still prefer to see it become WAY easier to learn and use, even if I know how to dance around all the issues that it presents me by not solving them itself. -- 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. pgpMNk_pRNII2.pgp Description: PGP signature
Re: associating sig and other properties with "From:" drop-down in mutt
Hi, what you could try is to associate various identitys with send-hooks in this way: send-hook . "source identity_a0" # default config send-hook "~f identity_a1" "source a1" # the a1 identity send-hook "~f identity_a2" "source a2" # the a2 identity and so on... where "~f identity_a1" is one of your email identities and a1, a2 set the various identity parameters, signatures, headers and stuff in seperate files. Don't forget some parameters you'll have to set to zero, for example: ignore * for the headers. Don't know if this will work but if successfull post the results. All the best. On Mon, 11.04.16, tech-lists wrote: Hello list, In my .muttrc I have a section that begins like this: ### macro compose v "^Uidentity_" "Select from" ### after this I have various addresses: alias identity_a0 my-preferred-email-address alias identity_a1 my-work-email-address This setup works well, allowing me to set the From: from a drop-down before I send. What I'd like is, for each From: also associate a sig and other characteristics, like whether by default the email should be gpg-signed, what other headers it wants. Is there an elegant way to do this? I don't want "being able to select the other address" to change, hopefully that can remain as-is. What I want is the *consequences of that selection* to change, so that on selection it's not just the "From:" that changes, but the other stuff as well. Many thanks, -- J. All the best, -- Wim
Re: associating sig and other properties with "From:" drop-down in mutt
On Tue, Apr 12, 2016 at 10:56:29PM +0200, Wim wrote: Hi, what you could try is to associate various identitys with send-hooks in this way: send-hook . "source identity_a0" # default config send-hook "~f identity_a1" "source a1" # the a1 identity send-hook "~f identity_a2" "source a2" # the a2 identity and so on... where "~f identity_a1" is one of your email identities and a1, a2 set the various identity parameters, signatures, headers and stuff in seperate files. Don't forget some parameters you'll have to set to zero, for example: ignore * for the headers. Don't know if this will work but if successfull post the results. Thanks, I'll try that. My overriding concern is that it'll still give the nifty drop-down-to-select. -- J.
