The danger of macros (was Re: ^R / ^D and threads)
On Tue, Nov 11, 2003 at 11:00:19PM -0500, David Yitzchak Cohen wrote:
> On Tue, Nov 11, 2003 at 02:26:21PM -0600, David Champion wrote:
> > * On 2003.11.11, in <20031111191357.GB29225@xxxxxxxxxxxxxxx>,
> > * "Will Yardley" <william+mutt@xxxxxxxxxxxxxxx> wrote:
> > > Because I use a trash folder, and I don't like to have messages in there
> > > that are still marked as "new".
> > Maybe rebind it to tag-thread, then tag-prefix mark them read, then
> > tag-prefix delete?
> You mean to bind it to untag-pattern ~T, then the above? ...or better,
> warn about any ~Ts, and then do the above?
>
> Clearly, working around side effects is not fun. The whole "resolve
> to next message after an action" thing is crap, IMHO, since the same
> functionality can be achieved easily by combining actions in a macro.
> Requiring macros to be used to _avoid_ side effects of what should be
> simple commands is really bad style, IMHO. It makes everything a lot
> more complicated than it ought to be :-(
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".
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/)
Cheers,
Allister
--
Allister MacLeod <amacleod@xxxxxxxx> | http://amacleod.is-a-geek.org/
Elen síla lúmenn'omentielvo.