Derek Martin wrote: [Tue Oct 28 2008, 03:20:02PM EDT]
> I think, and have always thought, that this is a Bad Thing(tm),
> making parsing Mutt's command line needlessly complicated. It
> seems much more sensible to me that Mutt's command line should
> only allow one type of object to be listed without explicit
> command-line options, i.e. recipients. I think it should be
> mandatory that each attachment one wants to attach should be
> specified after its own -a option. I think that allowing two
> different behaviors for this is confusing, and allowing the
> same behavior for two different types of command-line objects
> is confusing, and allowing both simultaneously is even more
> confusing, both to the user and the programmer. Finally,
> I think that the fact that this is still a problem, and that
> smart people such as Tamo are having difficulty to provide
> a suitable solution, is evidence enough in support of my point.
> :)
Yeah, I think the same thing. The changes I made most recently
tried to preserve some backward compatibility while making the
behavior consistent between platforms. I don't know if
preserving that backward compatibility was really the best
choice.
I think the point of the current behavior is to be able to do
things like this:
mutt -a *.jpg -- [EMAIL PROTECTED]
which is relatively difficult to do on the command-line with
individual -a options. Hacks like this come to mind:
eval "mutt $(printf '-a %q' *.jpg) [EMAIL PROTECTED]"
An alternative would be to add an attach-glob option to mutt,
which mutt would then expand internally, for example:
mutt -g \*.jpg [EMAIL PROTECTED]
More ideas? Dissenting opinions?
Aron
