<<< Date Index >>>     <<< Thread Index >>>

Re: The danger of macros (was Re: ^R / ^D and threads)



Since we are thinking out loud, here goes.

On 12/11/03 00.00, Allister MacLeod wrote:
> On Tue, Nov 11, 2003 at 11:31:42PM -0500, David Yitzchak Cohen wrote:
[snip]
> > fileserver (Plan9-style - I really like a lot of aspects of that system).
> > That way, you can use plain ordinary UNIX commands to fool with your mail.
> > (Imagine cp(1)ing a message from one folder to another, for instance.)
> 
> Hmm..  Sounds powerful and fun, but perhaps a bit less portable than
> mutt (and even mutt+Guile or mutt+Python).  Just off the top of your
> head, do you know how feasible such shenanigans are on Linux?  I think
> it would perhaps take some daemons and hackery, but might be within
> reach.

There is such a thing as a userspace filesystem, although it is not a
standard thing (yet, when you think about it for a while, it makes
good sense). That might be a way to do it, but it would naturally need
some kind of deamon doing the actual work. An portability would be a
bitch.

> > Obviously, you'll want a bunch of utility programs (like formail) to
> > help out with tasks like making replies, etc.  (Another neat option
> > is to simply vi(1) the /reply file within the message.  Note that in
> > Plan9's mail, you can access the MIME parts of a message by accessing
> > files inside it as if it were a directory.  There's no reason why replies
> > can't be implemented the same way.)  However, since we're hooking our mail
> 
> How does the mail system differentiate, when write() is called,
> whether to save as a postponed letter, or to send?  Do you / would you
> just copy the message into an "outbox" directory or something?

Maybe move the reply to "outbox" to queue it for transmission. Then a
new /reply file could automatically be created in its place.

> > up to the UNIX system instead of building our own system just for mail,
> > we gain the ability to write scripts/modules/addons/etc. in ANY language
> > that we have a compiler/interpreter for, provided it can do useful stuff
> > (e.g. fork(2) and exec(2) programs, unlink(2) files, etc.).  Embedding a
> > scripting language doesn't seem like the "right" solution to me.
> 
> Well, yes, I would imagine mutt-guile would really only appeal to
> that breed of kitchen-sinkers who think Emacs is the coolest thing
> since sliced bread.  (And don't use GNUS because they've been using
> mutt for so long.)  The ability to define compound functions and
> powerful macros, as you pointed out, is a hallmark of bloatware.  May
> as well get the bloat over with, I say :^)

Very true, sounds like something to I ought to have a go at (if I can
fit it in with all the other patches ;-)).

/dossen

Attachment: pgpv4oUN2xlBr.pgp
Description: PGP signature