On Tue, Nov 11, 2003 at 11:25:24PM -0500, Allister MacLeod wrote: > I agree. It's much easier to compose "mark" and "next" into a macro > than it is to second-guess and defeat half of the work of > "mark-then-next". Of course, no one likes to write in assembly > language all the time. Perhaps a good solution would be to have > atomic actions, and convenient default aliases for macros that could > be used as arguments to "bind". Personally, I like the idea of a new "define" command that lets you define a new function in terms of other functions. (Since functions take no arguments, implementation should be rather trivial.) Many of the common actions can be predefined in the default muttrc. This way, you get all the power of atomic actions, and all the convenience of bloatware, along with a default bloatsuite :-) > 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 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.) 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 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. - Dave -- Uncle Cosmo, why do they call this a word processor? It's simple, Skyler. You've seen what food processors do to food, right? Please visit this link: http://rotter.net/israel
Attachment:
pgpSDaWHiE4Tn.pgp
Description: PGP signature