Re: A better mutt? (Was Re: catchup command?)
Bya godzina 12:44:04 w sobota 23 wrzesie, gdy do autobusu wsiad kanar i wrzasn:"David Champion!!! Bilecik do kontroli!!!" A on(a) na to: A few years ago, I was tired of my frustrations with MH, elm, and Columbia mm, and I hated Pine. [...] I was in the planning stages, and had written a tiny amount of core code, when I found mutt. Mutt is an excellent mailer, good enough to resolve almost all my issues with the mailers I've used over the years. But there is one major problem that none of well known text-based (of coures that is not the matter of UI) mailreaders does not solve. Spooling. When i use either mutt, pine or simple mail first i have to set up sendmail/postfix/qmail which does spooling job. When nobody else use this computer it is a bit pointless to set up mailserver. IMHO spooling should be done before anything else will be thought about (what a grammar construction ;). Walking further, the pop3 support should give ability to plug in procmail somewhere to sort messages. That would be The-Mutt-of-My-Dreams ;) BTW. Anyone knows any other than 'serialmail' way to use qmail over dialup (dynamic IP) Best wishes... -- |/ |_, _ .- --,2:480/135@fido[EMAIL PROTECTED] |__ |_|. | \ |_|. ._' /_. 101:1000/135@unholy ... nothing is impossible in my powerful mind.
Re: A better mutt? (Was Re: catchup command?)
Lukasz Stelmach proclaimed on mutt-users that: But there is one major problem that none of well known text-based (of coures that is not the matter of UI) mailreaders does not solve. Spooling. When i use either mutt, pine or simple mail first i have to Masqmail / Nullmailer are your friends. (what a grammar construction ;). Walking further, the pop3 support should give ability to plug in procmail somewhere to sort messages. You mean a built in filtering interface? Instead, bundling a sample procmailrc template (and linking to Era Eriksson's Procmail mini ^H^H^H^H bronto FAQ at http://www.iki.fi/~era/procmail ..) should do the trick. Also http://www.spambouncer.org or http://www.waltdnes.org if you want to do something more fancy, like say spam filtering, with procmail. That would be The-Mutt-of-My-Dreams ;) I'm already fantastising about mutt, you know ;) -- Suresh Ramasubramanian + Wallopus Malletus Indigenensis mallet @ cluestick.org + Lumber Cartel of India, tinlcI Honesty is for the most part less profitable than dishonesty. -- Plato
Re: A better mutt? (Was Re: catchup command?)
On Sat, Sep 23, 2000 at 05:39:59PM +0300, Mikko H?nninen wrote: Jens Askengren [EMAIL PROTECTED] wrote on Sat, 23 Sep 2000: Last time I asked about this, I was told to check out "Balsa". (Which I haven't yet done, though it's on my list of things to do any decade now...) There are a lot of GUI clients out there for X11. But unfortunately, most of them seem to implement ease of use at the cost of limited functionality. Well, I was led to understand that Balsa is, or at least started out as, "Mutt with a GUI". I remember seeing a reference to "libmutt" somewhere. There's a lot of the latest mutt which isn't in Balsa. I've been looking for an X MUA for a long time but I always end up returning to mutt for various reasons. The main reason I've been looking for a GUI client is to ease handling of folder hierarchies. However none of the X MUAs is as complete as mutt and certainly none is as stable as mutt. -- Chris Green ([EMAIL PROTECTED])
Re: A better mutt? (Was Re: catchup command?)
On Sun, Sep 24, 2000 at 06:06:05PM +0200, Lukasz Stelmach wrote: BTW. Anyone knows any other than 'serialmail' way to use qmail over dialup (dynamic IP) Yes, there's a patch written by a qmail user that I used to use which makes qmail via a dial-up connection *much* easier. It's called the 'holdremote' patch, go take a look at:- http://www.mimir.com/~leveret/qmail.html -- Chris Green ([EMAIL PROTECTED])
Re: A better mutt? (Was Re: catchup command?)
Bya godzina 12:46:39 w poniedziaek 25 wrzesie, gdy do autobusu wsiad kanar i wrzasn:"Suresh Ramasubramanian!!! Bilecik do kontroli!!!" A on(a) na to: (what a grammar construction ;). Walking further, the pop3 support should give ability to plug in procmail somewhere to sort messages. You mean a built in filtering interface? No. Not a built in, just a "hole" to plug procmail in. Instead of writing downloaded mail to a mailbox, pass it to an external command. That is all i need. HANDON -- |/ |_, _ .- --,2:480/135@fido[EMAIL PROTECTED] |__ |_|. | \ |_|. ._' /_. 101:1000/135@unholy ... nothing is impossible in my powerful mind.
Re: catchup command?
On Sat, Sep 23, 2000 at 01:33:36 -0700, Peter Jaques wrote: i'm looking for some command that will mark all messages in a current mailbox as being read, without having to actually read them. sort of like ^R but for an entire mailbox ( not dependent on threading). is there a such? Tag all messages, mark the tagged messages read, and finally untag them. Can be bound to macro if you like, for example: macro index R "T~Aenter;WN;t" "Mark all messages read" -- Byrial http://home.worldonline.dk/~byrial/
Re: catchup command?
On 2000.09.23, in [EMAIL PROTECTED], "Byrial Jensen" [EMAIL PROTECTED] wrote: Tag all messages, mark the tagged messages read, and finally untag them. Can be bound to macro if you like, for example: macro index R "T~Aenter;WN;t" "Mark all messages read" This is correct, of course, and what I gave is not. I should learn not to reply with unproven answers at 4:00 in the morning. :) -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago
Re: A better mutt? (Was Re: catchup command?)
Jens Askengren [EMAIL PROTECTED] wrote on Sat, 23 Sep 2000: Yes, I'm suggesting that mutt needs a GUI. Last time I asked about this, I was told to check out "Balsa". (Which I haven't yet done, though it's on my list of things to do any decade now...) Regards, Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / Money isn't everything. There's also world domination.
Re: A better mutt? (Was Re: catchup command?)
On Sat, Sep 23, 2000 at 04:02:44PM +0300, Mikko Hänninen wrote: Jens Askengren [EMAIL PROTECTED] wrote on Sat, 23 Sep 2000: Yes, I'm suggesting that mutt needs a GUI. Last time I asked about this, I was told to check out "Balsa". (Which I haven't yet done, though it's on my list of things to do any decade now...) There are a lot of GUI clients out there for X11. But unfortunately, most of them seem to implement ease of use at the cost of limited functionality. -Jens PGP signature
Re: A better mutt? (Was Re: catchup command?)
Jens -- ...and then Jens Askengren said... % % Yes, I'm suggesting that mutt needs a GUI. I know that some of you might Gaack! *sputter* *wheeze* cough cough 'scuse me % want to edit your .procmailrc after reading this post. Please do so, but % read this first =) Hey, if this is any indication, I can't wait to see what you come up with next! ;-) Seriously, while a GUI-enabled mutt does sound interesting, it also sounds like a radical change in the development track... and my fear is that, once such a change were made, the text-only mutt would suffer if not go away entirely. That would really suck for me, for instance, since I do my mail over an ssh vt100 connection (and pround of it! :-) Could what you suggest be accomplished or approximated through a few macros here and there combined with multiple term windows running mutt under a windowing system? Think about it... You could have each of these windows open with your desired functions, and your 'm'ail and 'r'eply kes could be bound to macros which kick off a new window and a new mutt doing the reply, leaving the existing "parent" mutt window there to watch the mailbox while you compose. Just a thought... Probably easier and faster to design up than (though, certainly, not as simple or polished as) an integrated GUI-based mutt and, hey, you could get to say it's all yours! :-) HTH HAND :-D -- David T-G * It's easier to fight for one's principles (play) [EMAIL PROTECTED] * than to live up to them. -- fortune cookie (work) [EMAIL PROTECTED] http://www.bigfoot.com/~davidtg/Shpx gur Pbzzhavpngvbaf Qrprapl Npg! The "new millennium" starts at the beginning of 2001. There was no year 0. Note: If bigfoot.com gives you fits, try sector13.org in its place. *sigh* PGP signature
Re: A better mutt? (Was Re: catchup command?)
Jens Askengren [EMAIL PROTECTED] wrote on Sat, 23 Sep 2000: Last time I asked about this, I was told to check out "Balsa". (Which I haven't yet done, though it's on my list of things to do any decade now...) There are a lot of GUI clients out there for X11. But unfortunately, most of them seem to implement ease of use at the cost of limited functionality. Well, I was led to understand that Balsa is, or at least started out as, "Mutt with a GUI". I remember seeing a reference to "libmutt" somewhere. So it was not just "another X GUI MUA" suggested to me. But, not having really looked at the program myself, I can't really say if this is true or not. I'm just re-typing what I remember hearing before. :-) Mikko -- // Mikko Hänninen, aka. Wizzu // [EMAIL PROTECTED] // http://www.iki.fi/wiz/ // The Corrs list maintainer // net.freak // DALnet IRC operator / // Interests: roleplaying, Linux, the Net, fantasy scifi, the Corrs / unzip ; strip ; touch ; finger ; mount ; gasp ; yes ; umount ; sleep
Re: A better mutt? (Was Re: catchup command?)
On 2000.09.23, in [EMAIL PROTECTED], "Jens Askengren" [EMAIL PROTECTED] wrote: A GUI-mutt could be implemented by separating mutt into a backend and several frontends (curses, X11, etc). The frontend could be selected at compiletime, or loaded as a plugin/dll/.so-lib at runtime. Given the same .muttrc, the different frontends should feel and act the same. A few years ago, I was tired of my frustrations with MH, elm, and Columbia mm, and I hated Pine. Although I didn't really want to use a GUI, I had occasional uses for one, and knew others like having them, too. I had an idea then of producing a mailer founded on a small core, with modules to provide the front-ends, the mailbox interfaces, and script-language bindings. One DSO for an X frontend, one DSO for a curses frontend, one for an MH-like stateless system. One for CGI or mod_perl, maybe. A DSO for IMAP, one for MH, one for mbox, one for NNTP. A DSO for perl, a DSO for python. I wanted to provide interfaces suitable to implement all these, in such a ways that they could be used concurrently (although some UI combinations would be hard to make sense of). I was in the planning stages, and had written a tiny amount of core code, when I found mutt. I've been happily procrastinating ever since. (I don't really have that kind of time, anyway.) Mutt is an excellent mailer, good enough to resolve almost all my issues with the mailers I've used over the years. But I still like my original plan, and I still want to see it done, just because I feel that it's the right approach to a mailer's design. In some ways, it's easiest now if it's done on Mutt, but that's a LOT of code-mashing and munging. I don't know whether it's worth it anymore. But I think that kind of design is a REALLY good idea. And, in that light, there's absolutely no reason to bar a GUI front-end, even though I personally don't have much use for one. Additionally, a GUI-mutt could have a frame based addressbook, a .muttrc-wizzard, etc. Yes, but another interface could too. That ought not to be dependent on a GUI, although it might be most comfortable in a GUI. That ought to be an available interface to any willing UI. What do you think? If such an idea has a chance to go into the mutt-sources, I would like to contribute to a GTK-frontend. I guess you know what I think now. :) Yes, yes, yes, but I don't really know whether it's feasible, and I certainly don't know whether the mutt group is interested in this kind of fundamental change. -- -D.[EMAIL PROTECTED]NSITUniversity of Chicago PGP signature
Re: A better mutt? (Was Re: catchup command?)
Well, a GUI does have some advantages: - One can read HTML-mail... OK, people should not be sending html, but really a lot of (Microsoft)-users, do. It would be quite nice to view the layout they intended with fonts inline images. - The resolution is usally much more, so you can have more text on the screen. - You can have multiple windows. Of course it shouldn't be dumb like ms-programs, but more like gVIM. Everything works the same, but it has some advantages. I'm not sure if it is possible to share most of the code between an console and GTK-version, but it may be considered to try a GTK-version. Additionally, a GUI-mutt could have a frame based addressbook, a .muttrc-wizzard, etc. What do you think? If such an idea has a chance to go into the mutt-sources, I would like to contribute to a GTK-frontend. -Jens -- Wouter Verheijen [EMAIL PROTECTED] PGP signature
Re: A better mutt? (Was Re: catchup command?)
Jens Askengren [EMAIL PROTECTED] wrote on Sat, 23 Sep 2000: Yes, I'm suggesting that mutt needs a GUI. Not to nitpick, but no. mutt does not need a GUI. It'd probably be more accurate to say that you -want- a GUI for mutt. To this day, mutt is easily the most powerful, configurable, fast mailer that I've used. And for me, being a keyboard oriented dude, mutt's interface is perfect as is. Having extra windows pop up will only slow me down as I switch back and forth between windows. When I hit 'r', I want to start typing.. not have to worry about making sure focus is on the new window -- and when I dismiss the new window, I don't want to have to make sure focus goes back to my 'index' window. I realize not everyone works this way, which is fine. =) I prefer to have one window per app, if that. Currently I have two different mutt sessions (one personal, one work based that fetchmail feeds), an epic (irc) session, tf session (mush/mud client), and two shells all in one 'screen' session. Makes it easy for me to toggle between them without having to reach away from the keyboard. Also allows me to access all this stuff from work/home/friends house without having to lose state at all. So, a rather long-winded response, I know... but I just wanted to contend that mutt does not require a front end. - Myrddin
