Re: The danger of macros (was Re: ^R / ^D and threads)
On Tue, Nov 11, 2003 at 11:31:42PM -0500, David Yitzchak Cohen wrote:
> On Tue, Nov 11, 2003 at 11:25:24PM -0500, Allister MacLeod wrote:
> > Good point about the danger of assuming that nothing is tagged yet in
> > your macro. Having only "toggle" versions of some commands/functions
> > exacerbates this problem yet further. Yet another reason mutt-guile
> > strikes me as a good idea. (http://amacleod.is-a-geek.org/mutt-guile/)
> If the underlying language weren't Scheme, I'd probably be running it
> by now. I tend to prefer the approach of turning Mutt into a user-level
Just for reference, hat would be your most favoritest mutt extension
language? The design of mutt-guile so far should make it relatively
easy to add different ones, e.g. Python.
> 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.
> 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?
> 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 :^)
Ciao,
Allister
--
Allister MacLeod <amacleod@xxxxxxxx> | http://amacleod.is-a-geek.org/
Elen síla lúmenn'omentielvo.