On Thu, Sep 09, 1999 at 12:10:18AM -0500, Jeremy Blosser blurted:
> Fairlight [[EMAIL PROTECTED]] wrote:
> > On Wed, Sep 08, 1999 at 11:00:14PM -0500, Jeremy Blosser blurted:
> > > There is, ssmtp:
> > > ftp://metalab.unc.edu/pub/Linux/system/mail/mta/ssmtp-2.33.tar.gz
> >
> > Cool...*makes notes for other users down the line*
>
> As we speak I'm redoing http://www.mutt.org/links.html to have a better
> topical structure, this will include an expanded (but of course still
> incomplete) section of lins to other programs one can use with Mutt to get
> a full Un*x mail system set up.
Cool. You know...if I could just make a suggestion, since I think you
maintain part or all of the manual... The html version...I know it's extra
work, but it would be -really- cool in my opinion if the last 2 sections,
config commands and config variables (especially variables) gave each of
the commands their own hiperlink...maybe just make 2 sub-indexes that each
go to so the main one stays brief and to the point. I find www.exim.org's
commandline listings invaluable in that format and have found myself
wishing many times in the last few weeks that mutt's were layed out
similarly.
> > <snip>
> > > It does not exist, because implementing these things in Mutt would require
> > > making Mutt a minimalist MTA, and Mutt is not an MTA, it is an MUA. Better
> > > to leave this functinality in another (user specified) program.
> >
> > Erm....two comments, diametrically opposed:
> >
> > 1) That philosophy is a good one, but implimenting POP3 and IMAP flies in
> > the face of it, making Mutt a minimalist MDA, in addition to an MUA.
> > Not a complaint, but an observation. Technically, either both should
> > be supported minimally, or neither, IMHO.
>
> POP3: Yes, and this is why removing it from Mutt is a perennial(sp) debate.
Heh. Okay...I'm new to it, so I haven't been around for those debates. :)
> IMAP: Not quite the same, since even though IMAP is often remote, at the
> core it's just another popular mailbox/folder format such as mbox, Maildir,
> etc. It's proper for Mutt as a mail reader to support it. The primary
> purpose/action is not transferring the mail (indeed, you usually don't
> really "download" it), it's reading/browsing/composing it.
Not being familiar with IMAP myself, I've simply heard it described as an
alternative to POP3 (apparently by someone who was fairly clueless).
I never had a reason to drop POP3, and so never reasearched IMAP. Thanks for
the clarification.
> > 2) I'm glad at least that the design goals are to keep things trim and to
> > the point...I hate bloat like Communicator, et al that want to be
> > everything. Relating back to #1, I'd rather see POP/IMAP stripped
> > out if it came to a choice, but since it's already there... :)
>
> Well, there is always './configure --disable-pop --disable-imap' (which is
> the default, anyway).
Wasn't complaining...in fact, I enable pop (but disable imap), since
sometimes it's nice when you're waiting on tech support email to just hit G
instead of waking up fetchmail in another window or a shellout (I suppose it
could be macro'd/bound...). Was just noting that in general, I notice
y'all take great lengths to not let things get bloated, and wondered how it
came to be in there to begin with. :) Maybe that's like waking up a
dragon best left sleeping though. :)
Speaking of macro/binding...I looked through the docs today and saw "push"
...one of my mailboxes on one system is one I'll scan for topics and
usually delete all, which comes to a series of keystrokes: "D.*\n" ...I
tried something like: bind index ^x 'push "D.*\n"' ...and about 5
variations on it, to no avail...I keep getting:
push "D.*\n": no such function in map
What about push or bind am I not understanding correctly?
mark->
--
Fairlight-> ||| [EMAIL PROTECTED] | Fairlight Consulting
__/\__ ||| "I'm talking for free... | http://www.fairlite.com
<__<>__> ||| It's a New Religion..." | [EMAIL PROTECTED]
\/ ||| PGP Public Key available via finger @iglou, or Key servers
