david wrote:
it's now the primary UI for attachments. why not make it a rich UI?
Those aren't insurmountable, but somehow mhbuild feels like the wrong
place to be processing shell globbing. We have enough higher level tools
to do that (you can do it from the attach command,
Right:
What now? ls *.txt
bar.txt baz.txt foo.txt
What now? at *.txt
What now? li
To:
Attach: /tmp/bar.txt
Attach: /tmp/baz.txt
Attach: /tmp/foo.txt
--------
Paul, is there really a need to support shell globbing of Attach:
pseudoheaders?
no, i suppose not. i had forgotten that whatnow went through the shell.
And let me note that the whatnow command is passed through the user's
shell. I rely on bash-isms, e.g., "at foo{4..7}.pdf", all the time.
perhaps what's needed instead is a confirmation step at whatnow, to
confirm that what's been attached is what was intended.
There already is an al(ist):
What now? alist
bar.txt
baz.txt
foo.txt
interesting that it dropped your /tmp prefix. i've reproduced that --
i'd say it's a bug. if anything, alist should be reporting absolute
paths, to ensure no discrepancy between the pathname relative to whatnow's
cwd versus the cwd of the editor when the user may have created their
Attach header. (this has bitten me in the past, when using mhbuild
directives.)
And you can also view (and edit) the message after running mhbuild
("mime" at the whatnow prompt) on it.
okay. i think i'm convinced. thanks.
paul
----------------------
paul fox, pgf@foxharp.boston.ma.us (arlington, ma, where it's 46.9 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers