Re: Threading Mail
csj wrote: On Saturday 29 December 2001 06:55, Erik Steffl wrote: i find the tabs rather confusing. but then again, my desktop is simply four xterms (10 desktops thereof), and i usually don't need more... I suppose you're talking about programs that require user interaction (foreground processes). Aside from the hassle of manually opening 10 different tabs, can you cite an instance where having ten instant shell sessions is actually useful? he says 10 desktops, not tabs. That's the detail I decided to pass over. 10 desktops seems indecent. I can't see what applications you would run in 10 desktops that can't be done in 2 desktops and 10 (powershell/konsole) tabs. Personally I want the CLI stuff to go with other CLI stuff and the X stuff with other X stuff. of course, it COULD be also done in one desktop. some people don't like tabs that much, e.g. me (for xterm -like programs, for some other programs they make perfect sense). I use about 3 - 4 desktops on my home machine and about 4 - 7 on my work machine (on average). Usually I keep related apps on one desktop, so that I can see relevant things at one time. When you use tabs you cannot see any two (or more) of those at one time. the other problem is that when you use tabs you cannot use window manger level menus and keyboard shortcuts to switch between them (i.e. if you have ten xterms you can switch between any of them using WM's methods, but if you have two xterms with 5 tabs each you cannot switch between any shell prompt using WM, you have two methods to switch between shell prompts that you have to combine). I don't really make much fuss about whether it's GUI or CLI program, I keep together programs that are related based on task that I use them to acomplish (e.g. I might have version control system GUI, few gvim windows and few xterms that I want to keep together because they are all related to one task... I don't see a reason to group unrelated xterms together... but that's just me with my particular task that I use computer for. you might use different methods to acomplish similar or entirely different tasks... what I'm trying to say is that his 'desktops' and your 'tabs' are not technical details but suggest quite different way of working with system... you don't see much value in his (or mine) destops just like he doesn't see much value in the tabs... (not to say that one way of working with system is better then another, it probably depends on personal preference and the kind of tasks you tend to use computer for). erik
Re: Threading Mail
also sprach Steve Cooper [EMAIL PROTECTED] [2001.12.29.0507 +0100]: Also consider multi-gnome-terminal. It's a Debian Unstable package that's _much_ lighter weight than konsole and cleaner (IMO) than powershell. It also has the excellent feature of allowing you to invoke URLs without using a helper program like urlview. Anything that smells like a URL gets underlined, and ctrl-clicking invokes the configured Gnome url handler. that sounds really nice. unfortunately, i am a purist and don't want no gnomelibs on this machine. and i so rarely work with urls... but thanks! -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] * michaelw does the buildd shuffle -- #debian pgpMmP2iied6s.pgp Description: PGP signature
Re: Threading Mail
On Saturday 29 December 2001 06:55, Erik Steffl wrote: i find the tabs rather confusing. but then again, my desktop is simply four xterms (10 desktops thereof), and i usually don't need more... I suppose you're talking about programs that require user interaction (foreground processes). Aside from the hassle of manually opening 10 different tabs, can you cite an instance where having ten instant shell sessions is actually useful? he says 10 desktops, not tabs. That's the detail I decided to pass over. 10 desktops seems indecent. I can't see what applications you would run in 10 desktops that can't be done in 2 desktops and 10 (powershell/konsole) tabs. Personally I want the CLI stuff to go with other CLI stuff and the X stuff with other X stuff. -- Sir Isaac Newton: If I have seen further, it is by standing on the shoulders of giants.
Re: Threading Mail
also sprach csj [EMAIL PROTECTED] [2001.12.29.2003 +0100]: That's the detail I decided to pass over. 10 desktops seems indecent. I can't see what applications you would run in 10 desktops that can't be done in 2 desktops and 10 (powershell/konsole) tabs. Personally I want the CLI stuff to go with other CLI stuff and the X stuff with other X stuff. i don't even see a point why we're arguing this, but here comes my explanation... i administer about 17 servers worldwide these days. all from my laptop. granted, 12 of them don't really need much work, but the other five, i work with on pretty much a daily/hourly basis... and if it's just using them. so i love having my windowmaker boot up, give me - 2*80x25 + 1*80x50 on desktop 1 with local shells - two 80x50 copies of mutt (one at =inbox, one at =sent) on desktop 2 - two 80x50 w3m-ssl to my groupware account on desktop 3 - four 80x25 terms sporting slrn, w3m/slashdot, w3m/kuro5hin, and a regular shell on desktop 4 - copies of the first desktop on desktops 5-9, each ssh logging into the 5 servers at stake (rsa authentication, thank god). - finally, desktop 10 presents me with opera. the advantages? aside from relatively long windowmaker start times, which allow for coffee to be fetched,--- well, i need to type very little for the everyday tasks, i know precisely where to find what, i never get lost in windows, and i'd argue that i am fast! -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] if you want to build a ship, don't drum up people together to collect wood, and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. -- antoine de saint exupery pgpyBhkdY9s20.pgp Description: PGP signature
Re: Threading Mail
On Thursday 27 December 2001 07:37, Brian Nelson wrote: Besides, I hate managing windows. I don't want a bunch of terms running mutt just so I can see more than one email at a time. Just one window should do, thank you. That shouldn't be a problem with KDE's Konsole or PowerShell. From the powershell package description: PowerShell is a GNOME/Gtk+ based terminal emulator which supports many terminals in a single window (limited only by available RAM). Each terminal is given a notebook tab which makes switching between terminals easy. From the konsole package description: Konsole is an X terminal emulation which provides a command-line interface (CLI) while using the graphical K Desktop Environment. Konsole helps to better organize user's desktop by containing multiple sessions in a single window (a less cluttered desktop). -- Humanity's future is in the stars. Support a manned mission to Mars!
Re: Threading Mail
also sprach csj [EMAIL PROTECTED] [2001.12.28.0807 +0100]: From the powershell package description: PowerShell is a GNOME/Gtk+ based terminal emulator which supports many terminals in a single window (limited only by available RAM). Each terminal is given a notebook tab which makes switching between terminals easy. if powershell or KDE could (maybe now they can, not last time i checked) be spawned such that you'd have, say, four tabs with four command lines executed therein, it would be worth the consideration... i find the tabs rather confusing. but then again, my desktop is simply four xterms (10 desktops thereof), and i usually don't need more... -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] no micro$oft components were used in the creation or posting of this email. therefore, it is 100% virus free and does not use html by default (yuck!). pgpKHoVniHcAW.pgp Description: PGP signature
Re: Threading Mail
On Saturday 29 December 2001 03:58, martin f krafft wrote: also sprach csj [EMAIL PROTECTED] [2001.12.28.0807 +0100]: From the powershell package description: PowerShell is a GNOME/Gtk+ based terminal emulator which supports many terminals in a single window (limited only by available RAM). Each terminal is given a notebook tab which makes switching between terminals easy. if powershell or KDE could (maybe now they can, not last time i checked) be spawned such that you'd have, say, four tabs with four command lines executed therein, it would be worth the consideration... i find the tabs rather confusing. but then again, my desktop is simply four xterms (10 desktops thereof), and i usually don't need more... I suppose you're talking about programs that require user interaction (foreground processes). Aside from the hassle of manually opening 10 different tabs, can you cite an instance where having ten instant shell sessions is actually useful? -- Sir Isaac Newton: If I have seen further, it is by standing on the shoulders of giants.
Re: Threading Mail
also sprach csj [EMAIL PROTECTED] [2001.12.28.2228 +0100]: I suppose you're talking about programs that require user interaction (foreground processes). Aside from the hassle of manually opening 10 different tabs, can you cite an instance where having ten instant shell sessions is actually useful? well, how about 3 mutt sessions, one on =sent, one on =read, and one on =inbox, in addition to an slrn instance, w3m-ssl on my groupware account, two terminals, and three ssh sessions into other machines? i love to start out the day like that... and if you have that scripted (or the like), you get used to where what is, you don't have to worry about logging in anymore, it certainly saves keystrokes, and it's convenient. of the approx. 30 shell windows that windowmaker produces during startup, i surely never use them all. but i consider it a great asset not to have to worry about overlapping windows, and to have *a lot* of scratch space for whatever i need to do. i was just thinking that a powershell that would open e.g. three mutt instances as described above would possibly make for an interesting MUA ;) - now if you could sync your GPG passphrase across rather than having to type that thrice, who'd need anything else? -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] i did not know. but i sensed it as truth. -chaim potok pgpe6KS0tkMaV.pgp Description: PGP signature
Re: Threading Mail
csj wrote: On Saturday 29 December 2001 03:58, martin f krafft wrote: also sprach csj [EMAIL PROTECTED] [2001.12.28.0807 +0100]: From the powershell package description: PowerShell is a GNOME/Gtk+ based terminal emulator which supports many terminals in a single window (limited only by available RAM). Each terminal is given a notebook tab which makes switching between terminals easy. if powershell or KDE could (maybe now they can, not last time i checked) be spawned such that you'd have, say, four tabs with four command lines executed therein, it would be worth the consideration... i find the tabs rather confusing. but then again, my desktop is simply four xterms (10 desktops thereof), and i usually don't need more... I suppose you're talking about programs that require user interaction (foreground processes). Aside from the hassle of manually opening 10 different tabs, can you cite an instance where having ten instant shell sessions is actually useful? he says 10 desktops, not tabs. usually I open quite a few xterms as well, e.g. one for running program (and do msic interactive stuff), few for editing sources (those might be gvim windows instead), one for watching output from the program (tail -f logfile), one or two for manpages or other docs etc... and of course, the same thing often happens on multiple desktops (main program, one or two small programs to try something out etc.) erik
Re: Threading Mail
On Fri, Dec 28, 2001 at 08:58:54PM +0100, martin f krafft decreed: also sprach csj [EMAIL PROTECTED] [2001.12.28.0807 +0100]: From the powershell package description: PowerShell is a GNOME/Gtk+ based terminal emulator which supports many terminals in a single window (limited only by available RAM). Each terminal is given a notebook tab which makes switching between terminals easy. if powershell or KDE could (maybe now they can, not last time i checked) be spawned such that you'd have, say, four tabs with four command lines executed therein, it would be worth the consideration... i find the tabs rather confusing. but then again, my desktop is simply four xterms (10 desktops thereof), and i usually don't need more... [snip] ---end quoted text--- Also consider multi-gnome-terminal. It's a Debian Unstable package that's _much_ lighter weight than konsole and cleaner (IMO) than powershell. It also has the excellent feature of allowing you to invoke URLs without using a helper program like urlview. Anything that smells like a URL gets underlined, and ctrl-clicking invokes the configured Gnome url handler. Cheers, Steve -- \_O \_O \_O ~~~ Steve Cooper Redmond, WA
Re: Threading Mail
John Hasler wrote: erik writes: email storage - where the email is stored. traditionaly this is just files, mostly mbox or maildir. that's what is replaced by IMAP. that way you have no email in /var/spool/mail/username or ~/mbox or wherever your email currently is, the email is stored by IMAP (you don't care where) But I care very much where. In particular, I care very much that my mail _not_ remain on my ISP's server any longer than necessary. Trouble is, that's where it would have to remain in order for IMAP to do me any good. I have IMAP on my local computer. of course, it is a lot more useful since I have dsl (IMAP over SSL from anywhere (here there's internet)). but even if I only had dial-up it would make sense, if nothing else to make it easier to try different email clients. and the 'you do not care where' was meant from the position of email client, I am pretty sure that you personally care, the point is that it's independent (in some cases, if there is administrator on site, you might actually not care). where the email actually is depends on IMAP server and your settings - cyrus stores it in completely inaccessible area, uw-imap considers everytyhing in ~ to be email (that's kinda funny), luckily you can limit it to e.g. ~/mail (using client settings, or uw-imap compile time settings) etc. erik
Threading Mail
I ran apt-get install mutt in hopes of setting up a mail box with threading for this list. There does not seem to be any POP3 connection in the application as downloaded. Any suggestions? Tom George
Re: Threading Mail
On Wed, Dec 26, 2001 at 02:09:24PM -0500, Thomas H. George,,, wrote: | I ran apt-get install mutt in hopes of setting up a mail box with | threading for this list. There does not seem to be any POP3 connection | in the application as downloaded. Any suggestions? www.mutt.org There is a good manual there (or 'man muttrc' for just the reference section). You need to set pop_host, pop_user, and pop_pass (or something like that). I recommend just using fetchmail intstead and having exim or procmail sort the mail into folders for you. The advantage of using fetchmail+exim/procmail is that you can switch mailers all you want and are not dependent on a given mailer's POP/IMAP and filter/sort capabilities. All they need is the ability to read a local folder. Also note the set sort=threads option. I highly recommend mutt, it's what I use :-). -D -- GUIs normally make it simple to accomplish simple actions and impossible to accomplish complex actions. --Doug Gwyn (22/Jun/91 in comp.unix.wizards)
Re: Threading Mail
on Wed, Dec 26, 2001 at 02:09:24PM -0500, Thomas H. George,,, ([EMAIL PROTECTED]) wrote: I ran apt-get install mutt in hopes of setting up a mail box with threading for this list. There does not seem to be any POP3 connection in the application as downloaded. Any suggestions? $ apt-cache show fetchmail $ sudo apt-get install fetchmail fetchmailconf $ fetchmailconf $ fetchmail Peace. -- Karsten M. Self kmself@ix.netcom.comhttp://kmself.home.netcom.com/ What part of Gestalt don't you understand? Home of the brave http://gestalt-system.sourceforge.net/Land of the free We freed Dmitry! Boycott Adobe! Repeal the DMCA! http://www.freesklyarov.org Geek for Hire http://kmself.home.netcom.com/resume.html pgpcgRg6KyyKI.pgp Description: PGP signature
Re: Threading Mail
On Wed, Dec 26, 2001 at 03:00:53PM -0500, dman wrote: On Wed, Dec 26, 2001 at 02:09:24PM -0500, Thomas H. George,,, wrote: | I ran apt-get install mutt in hopes of setting up a mail box with | threading for this list. There does not seem to be any POP3 connection | in the application as downloaded. Any suggestions? www.mutt.org There is a good manual there (or 'man muttrc' for just the reference section). You need to set pop_host, pop_user, and pop_pass (or something like that). I use mutt to get my mail in and exim to provide the mail transport. The relevant portion of my .muttrc set pop_user = set pop_pass = set pop_delete = set pop_host = set pop_checkinterval=60 set pop_port = 110 set pop_last = no Fill in your details. Sam -- (Sam Varghese) http://www.gnubies.com The dogs bark but the caravan passes. - ancient Arab proverb
Re: Threading Mail
also sprach dman [EMAIL PROTECTED] [2001.12.26.2100 +0100]: I recommend just using fetchmail intstead and having exim or procmail sort the mail into folders for you. The advantage of using fetchmail+exim/procmail is that you can switch mailers all you want and are not dependent on a given mailer's POP/IMAP and filter/sort capabilities. All they need is the ability to read a local folder. yes, but you also need to learn a lot more software. while mutt already has quite a learning curve, fetchmail may be easy, exim moderate, but procmail (especially the debugging) can be quite a drag. easier if you can just rely on mutt... ...and, once you used mutt and you are comfortable with it, you ain't gonna switch ever ;) -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] as i was going up the stair i met a man who wasn't there. he wasn't there again today. i wish, i wish he'd stay away. --hughes mearns pgpFj1G0KpuEv.pgp Description: PGP signature
Re: Threading Mail
martin f krafft [EMAIL PROTECTED] writes: also sprach dman [EMAIL PROTECTED] [2001.12.26.2100 +0100]: I recommend just using fetchmail intstead and having exim or procmail sort the mail into folders for you. The advantage of using fetchmail+exim/procmail is that you can switch mailers all you want and are not dependent on a given mailer's POP/IMAP and filter/sort capabilities. All they need is the ability to read a local folder. yes, but you also need to learn a lot more software. while mutt already has quite a learning curve, fetchmail may be easy, exim moderate, but procmail (especially the debugging) can be quite a drag. easier if you can just rely on mutt... ...and, once you used mutt and you are comfortable with it, you ain't gonna switch ever ;) Not true! I switched from mutt to gnus. It's IMAP support was too weak for me, and I didn't like the single window nature of it (you can't compose a message and read other mail at the same time). Mutt's ok. It does the important things right, but otherwise is rather mediocre. -- Brian Nelson [EMAIL PROTECTED] [EMAIL PROTECTED] http://bignachos.com
Re: Threading Mail
also sprach Brian Nelson [EMAIL PROTECTED] [2001.12.26.2221 +0100]: Not true! I switched from mutt to gnus. It's IMAP support was too weak for me, yes, IMAP is not a strength. but then again, an IMAP client isn't really a MUA on the same scale of interpretation that mutt without IMAP is one... and I didn't like the single window nature of it (you can't compose a message and read other mail at the same time). but you can happily spawn two hundred separate instances and point them wherever you like... it works just fine i find, it's lightweight, and it's fast... then again, i've never used anything else... Mutt's ok. It does the important things right, but otherwise is rather mediocre. it's a MUA that already features a POP3 client and some IMAP. that's overkill. when you see a MUA as a mailer that doesn't simply communicate with the real backend through IMAP, then it's the best thing out there... IMHO. let's not start a flame war ;) -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] yesterday it worked. today it is not working. windoze is like that. pgpVL0ilmwQXP.pgp Description: PGP signature
Re: Threading Mail
on Wed, 26 Dec 2001 11:18:07PM +0100, marTin insinuated: and I didn't like the single window nature of it (you can't compose a message and read other mail at the same time). but you can happily spawn two hundred separate instances and point them wherever you like... it works just fine i find, it's lightweight, and it's fast... then again, i've never used anything else... as a devoted pine user for years, and eudora for more before that, i concur that mutt rocks. and you *can* (as martin points out) compose and read at the same time, all of which stay happily-synchonized with '$' if need be. /nori [EMAIL PROTECTED]-- -http://www.sccs.swarthmore.edu/~nori/jnl/daily.html
Re: Threading Mail
Nori Heikkinen [EMAIL PROTECTED] writes: on Wed, 26 Dec 2001 11:18:07PM +0100, marTin insinuated: and I didn't like the single window nature of it (you can't compose a message and read other mail at the same time). but you can happily spawn two hundred separate instances and point them wherever you like... it works just fine i find, it's lightweight, and it's fast... then again, i've never used anything else... as a devoted pine user for years, and eudora for more before that, i concur that mutt rocks. and you *can* (as martin points out) compose and read at the same time, all of which stay happily-synchonized with '$' if need be. That requires a whole lot more effort than I'd like, though. For example, suppose I'm replying to a thread, but some of the previous postings have been snipped and I want to check the parent of the thread. In order to do this in mutt, I'd have to open a new term and launch mutt, go to the correct mailbox, search through all the mail I've already read (can't sync with $ if I've already started composing), find the correct thread, and finally read the parent post. However, in an environment with multiple buffers (aka emacs), I can seamlessly switch to the index buffer and immediately read the parent of the thread, and then jump right back to the compose buffer. Besides, I hate managing windows. I don't want a bunch of terms running mutt just so I can see more than one email at a time. Just one window should do, thank you. I don't dislike mutt. It's ok, and it gets the job done. I just don't think it's the holy grail of email readers, as many seem to believe. I can't help but think it's overrated. -- Brian Nelson [EMAIL PROTECTED] [EMAIL PROTECTED] http://bignachos.com
Re: Threading Mail
also sprach Brian Nelson [EMAIL PROTECTED] [2001.12.27.0037 +0100]: as a devoted pine user for years, and eudora for more before that, i concur that mutt rocks. and you *can* (as martin points out) compose and read at the same time, all of which stay happily-synchonized with '$' if need be. That requires a whole lot more effort than I'd like, though. For example, suppose I'm replying to a thread, but some of the previous postings have been snipped and I want to check the parent of the thread. In order to do this in mutt, I'd have to open a new term and launch mutt, go to the correct mailbox, search through all the mail I've already read (can't sync with $ if I've already started composing), find the correct thread, and finally read the parent post. also a valid point. However, in an environment with multiple buffers (aka emacs), I can seamlessly switch to the index buffer and immediately read the parent of the thread, and then jump right back to the compose buffer. well, you are doing every MUA and everything else unfair justice by comparing it to the emacs operating system ;^ (noo, this isn't flame-bait!) I don't dislike mutt. It's ok, and it gets the job done. I just don't think it's the holy grail of email readers, as many seem to believe. I can't help but think it's overrated. true. and if you tell me that gnus (it was gnus that you use, right) can do - proper list management, incl. follow-up-to and others - macros and keybinding - hooks - ldap integration - gpg integration - maildirs - colors and control thereof - proper locking and the ability to read the same mailbox locally and over an ssh connection (e.g. pine can't do that) - lots of random configuration options to please the playful - full control over the headers sent then i'd love to give gnus a serious look... ps: mr. bignachos, you do know that your domain has troubles, right? fishbowl:~/etc/mutt host -t mx bignachos.com bignachos.com MX 10 h00a0cc56d269.ne.mediaone.net bignachos.com MX 20 . !!! bignachos.com MX host . has illegal name use '@' instead of the '.' to refer to bignachos.com itself. now you are making the root servers be your MX. you do have four messages waiting in my postfix queue... embryo postfix/smtp[1774]: warning: malformed domain name in resource data of MX record for bignachos.com: embryo postfix/smtp[1774]: D81AA116EB: to=[EMAIL PROTECTED], relay=none, delay=2, status=deferred (bignachos.com: Malformed name server reply) embryo:~# mailq -Queue ID- --Size-- Arrival Time -Sender/Recipient--- E2D6511722 2829 Mon Dec 24 17:36:38 [EMAIL PROTECTED] (bignachos.com: Malformed name server reply) [EMAIL PROTECTED] D81AA116EB 2742 Mon Dec 24 14:55:24 [EMAIL PROTECTED] (bignachos.com: Malformed name server reply) [EMAIL PROTECTED] 8551711723 2495 Mon Dec 24 18:08:17 [EMAIL PROTECTED] (bignachos.com: Malformed name server reply) [EMAIL PROTECTED] 22C2B11724 2305 Mon Dec 24 18:10:25 [EMAIL PROTECTED] (bignachos.com: Malformed name server reply) [EMAIL PROTECTED] -- 10 Kbytes in 4 Requests. cheers, -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] * michaelw does the buildd shuffle -- #debian pgpg8EaoQf0bJ.pgp Description: PGP signature
Re: Threading Mail
On Wed, Dec 26, 2001 at 09:58:11PM +0100, martin f krafft wrote: | also sprach dman [EMAIL PROTECTED] [2001.12.26.2100 +0100]: | I recommend just using fetchmail intstead and having exim or procmail | sort the mail into folders for you. The advantage of using | fetchmail+exim/procmail is that you can switch mailers all you want | and are not dependent on a given mailer's POP/IMAP and filter/sort | capabilities. All they need is the ability to read a local folder. | | yes, but you also need to learn a lot more software. while mutt | already has quite a learning curve, fetchmail may be easy, exim | moderate, but procmail (especially the debugging) can be quite a drag. | easier if you can just rely on mutt... Well, fetchmail is easy enough -- you just write down what your mail account information is. exim can be used in place of procmail (I'm using it now) as it has filter capability. Have you gotten mutt to automatically put list mail in its own folder? -D -- He who belongs to God hears what God says. The reason you do not hear is that you do not belong to God. John 8:47
Re: Threading Mail
On Wed, Dec 26, 2001 at 04:21:53PM -0500, Brian Nelson wrote: | Not true! I switched from mutt to gnus. It's IMAP support was too weak | for me, IMAP in mutt is actually somewhat controversial. The author doesn't really like it (mutt is _just_ a MUA), but there would be too much wailing and gnashing of teeth if it was removed. Its present existence is under the guise of just another folder format. | and I didn't like the single window nature of it (you can't compose | a message and read other mail at the same time). This is the one significant issue I have with it. -D -- Bugs come in through open windows. Keep Windows shut!
Re: Threading Mail
also sprach dman [EMAIL PROTECTED] [2001.12.27.0154 +0100]: Well, fetchmail is easy enough -- you just write down what your mail account information is. exim can be used in place of procmail (I'm using it now) as it has filter capability. Have you gotten mutt to automatically put list mail in its own folder? nope. i use procmail. would use exim because i love the syntax, but i am addicted to postfix... -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] 1-800-psych hello, welcome to the psychiatric hotline. if you are paranoid-delusional, we know who you are and what you want. just stay on the line so we can trace the call. pgpT1u8oxfrhE.pgp Description: PGP signature
Re: Threading Mail
martin f krafft [EMAIL PROTECTED] writes: also sprach Brian Nelson [EMAIL PROTECTED] [2001.12.27.0037 +0100]: as a devoted pine user for years, and eudora for more before that, i concur that mutt rocks. and you *can* (as martin points out) compose and read at the same time, all of which stay happily-synchonized with '$' if need be. That requires a whole lot more effort than I'd like, though. For example, suppose I'm replying to a thread, but some of the previous postings have been snipped and I want to check the parent of the thread. In order to do this in mutt, I'd have to open a new term and launch mutt, go to the correct mailbox, search through all the mail I've already read (can't sync with $ if I've already started composing), find the correct thread, and finally read the parent post. also a valid point. However, in an environment with multiple buffers (aka emacs), I can seamlessly switch to the index buffer and immediately read the parent of the thread, and then jump right back to the compose buffer. well, you are doing every MUA and everything else unfair justice by comparing it to the emacs operating system ;^ (noo, this isn't flame-bait!) I don't dislike mutt. It's ok, and it gets the job done. I just don't think it's the holy grail of email readers, as many seem to believe. I can't help but think it's overrated. true. and if you tell me that gnus (it was gnus that you use, right) can do - proper list management, incl. follow-up-to and others - macros and keybinding - hooks - ldap integration - gpg integration - maildirs - colors and control thereof - proper locking and the ability to read the same mailbox locally and over an ssh connection (e.g. pine can't do that) - lots of random configuration options to please the playful - full control over the headers sent then i'd love to give gnus a serious look... I'm not sure what you mean by that ssh one, but gnus does do the others. It does have some drawbacks though, such as: - configuration requires elisp hacking, is rather awkward and confusing, and takes a long time to get right - no vi(m), unless viper-mode is adequate - no multitasking (the emacs session is useless while checking mail/news) - it likes to render HTML mail with w3 by default, which looks awful and is slw - occasionally locks up emacs for me It's not perfect, but it usually does what I want. There are tons of neat little built-in functions. For example, if some turd doesn't wrap their lines, just type W w and it's fixed. -- Brian Nelson [EMAIL PROTECTED] [EMAIL PROTECTED] http://bignachos.com
Re: Threading Mail
also sprach Brian Nelson [EMAIL PROTECTED] [2001.12.27.0208 +0100]: - no vi(m), unless viper-mode is adequate mh. i forgot it's emacs... -- martin; (greetings from the heart of the sun.) \ echo mailto: !#^.*|tr * mailto:; [EMAIL PROTECTED] sum quod eris. pgpqKwm87eUmt.pgp Description: PGP signature
Re: Threading Mail
dman wrote: On Wed, Dec 26, 2001 at 04:21:53PM -0500, Brian Nelson wrote: | Not true! I switched from mutt to gnus. It's IMAP support was too weak | for me, IMAP in mutt is actually somewhat controversial. The author doesn't really like it (mutt is _just_ a MUA), but there would be too much isn't it even more important for it to be a IMAP client? any other way of working with email makes it a little bit more then MUA (or little bit more then is neccessary). mail storage - separate tool (IMAP) mail filtering - separate tool (sieve, procmail) unix philosophy... as long as they all work together... IMO mutt is already trying too be too many things at once (granted, they are all email related:-) erik
Re: Threading Mail
On Wed, Dec 26, 2001 at 05:23:49PM -0800, Erik Steffl wrote: | dman wrote: | | On Wed, Dec 26, 2001 at 04:21:53PM -0500, Brian Nelson wrote: | | | Not true! I switched from mutt to gnus. It's IMAP support was too weak | | for me, | | IMAP in mutt is actually somewhat controversial. The author doesn't | really like it (mutt is _just_ a MUA), but there would be too much | | isn't it even more important for it to be a IMAP client? any other way | of working with email makes it a little bit more then MUA (or little bit | more then is neccessary). I don't get what you are saying here. Mutt doesn't really need IMAP since fetchmail already takes care of it. | mail storage - separate tool (IMAP) Right -- fetchmail. However, as I said, too many people would complain too loudly if the current IMAP code in mutt was removed. | mail filtering - separate tool (sieve, procmail) I don't see 'sieve' anywhere in apt-cache search. I did read the RFC though. | unix philosophy... as long as they all work together... Yep. | IMO mutt is already trying too be too many things at once (granted, | they are all email related:-) Which things (aside from POP and IMAP)? -D -- How to shoot yourself in the foot with Java: You find that Microsoft and Sun have released imcompatible class libraries both implementing Gun objects. You then find that although there are plenty of feet objects implemented in the past in many other languages, you cannot get access to one. But seeing as Java is so cool, you dont care and go around shooting anything else you can find. (written by Mark Hammond)
Re: Threading Mail
dman wrote: On Wed, Dec 26, 2001 at 05:23:49PM -0800, Erik Steffl wrote: | dman wrote: | | On Wed, Dec 26, 2001 at 04:21:53PM -0500, Brian Nelson wrote: | | | Not true! I switched from mutt to gnus. It's IMAP support was too weak | | for me, | | IMAP in mutt is actually somewhat controversial. The author doesn't | really like it (mutt is _just_ a MUA), but there would be too much | | isn't it even more important for it to be a IMAP client? any other way | of working with email makes it a little bit more then MUA (or little bit | more then is neccessary). I don't get what you are saying here. Mutt doesn't really need IMAP since fetchmail already takes care of it. no, IMAP is not equivalent of POP3. Instead of accessing email stored in one or another format in files MUA accesses IMAP for all its email storage needs. Instead of reading the file it asks IMAP server for a message. etc... that way you can access the same mail account using different tools (even at same time) and never worry about technicalities of file locking, about which format they use and how well they support it etc. (because all tools access email only via IMAP server) | mail storage - separate tool (IMAP) Right -- fetchmail. However, as I said, too many people would complain too loudly if the current IMAP code in mutt was removed. email storage - where the email is stored. traditionaly this is just files, mostly mbox or maildir. that's what is replaced by IMAP. that way you have no email in /var/spool/mail/username or ~/mbox or wherever your email currently is, the email is stored by IMAP (you don't care where) and you just ask IMAP to performa various operations on mail. btw some IMAP servers implemente mail storage in a way that makes physical email really inaccessible to you (cyrus), other basically consider you ~ a big bunch of mbox/maildir files (uw-imap, it's useful to limit it's namespace to e.g. just ~/mail, otherwise you see everything as mail, slightly confusing) | mail filtering - separate tool (sieve, procmail) I don't see 'sieve' anywhere in apt-cache search. I did read the RFC though. it's part of cyrus (maybe some other IMAP servers as well, not sure if there's a standalone implementation). You can, of course, continue to use procmail with IMAP server. | unix philosophy... as long as they all work together... Yep. | IMO mutt is already trying too be too many things at once (granted, | they are all email related:-) Which things (aside from POP and IMAP)? it also filters email. then it has this way of 'processing' email - scoring, doing various things between swtiching folders etc. not saying it shouldn't be there but I would rather see a separate tools for 'post-processing' email, independent of MUA (it would be sort of automatic MUA, something what sed is to vi). btw IMAP is not one of those 'too much' that I had in mind, IMAP is eesential, but not as download protocol (i.e. using it as if it were POP3) but as real IMAP (that's how it's implemented, you see IMAP folders as normal (sort of) folders. this is how my system works: out - postfix - cyrus deliver - sieve - IMAP (cyrus) - MUAs out - fetchmail - postfix - see above MUAs - postfix - out that way I can use any IMAP MUAs (and still have email filtered the same way), I can read my email from various places (mostly from one of my home computers or from work), don't have to worry whether I closed one MUA before opening another one (file locking funnies) etc. also much less chances for screweup due to unstable MUAs (I change programs that have user interface lot more often then programs that work in behind, I guess that's true for most people). it's email paradise! if you don't have your email set that way you owe it to yourself to try it (you don't have to use the same components, of course) erik
Re: Threading Mail
erik writes: email storage - where the email is stored. traditionaly this is just files, mostly mbox or maildir. that's what is replaced by IMAP. that way you have no email in /var/spool/mail/username or ~/mbox or wherever your email currently is, the email is stored by IMAP (you don't care where) But I care very much where. In particular, I care very much that my mail _not_ remain on my ISP's server any longer than necessary. Trouble is, that's where it would have to remain in order for IMAP to do me any good. -- John Hasler [EMAIL PROTECTED] (John Hasler) Dancing Horse Hill Elmwood, WI
Re: Threading Mail
On Wed, Dec 26, 2001 at 09:58:11PM +0100, martin f krafft wrote: also sprach dman [EMAIL PROTECTED] [2001.12.26.2100 +0100]: I recommend just using fetchmail intstead and having exim or procmail sort the mail into folders for you. The advantage of using fetchmail+exim/procmail is that you can switch mailers all you want and are not dependent on a given mailer's POP/IMAP and filter/sort capabilities. All they need is the ability to read a local folder. yes, but you also need to learn a lot more software. while mutt already has quite a learning curve, fetchmail may be easy, exim moderate, but procmail (especially the debugging) can be quite a drag. easier if you can just rely on mutt... try : $prompt less /usr/doc/procmail/QuickStart Worked for me. Up and running in 5 minutes.
