Paul Fox p...@foxharp.boston.ma.us writes:
so it turns out that if you attach a mail message to your draft, using:
Attach: /home/pgf/Mail/inbox/1982
It would be nice to automatically inline text and images. However, we
should also provide a UI to override the default.
One idea, from
It would be nice to automatically inline text and images. However, we
should also provide a UI to override the default.
I think we agreed that there should be a configuration file entry that
let you override the default, but I think everyone agreed that the default
disposition of attachment was
Ken wrote:
No. What if the filename contains a space or comma? Right now that works
fine. And yes, I do attach filenames with spaces. This doesn't work with
the attach command (sigh), but that's on my list to fix.
It works if you quote the space just as you would at a shell
prompt. The
No. What if the filename contains a space or comma? Right now that works
fine. And yes, I do attach filenames with spaces. This doesn't work with
the attach command (sigh), but that's on my list to fix.
It works if you quote the space just as you would at a shell
prompt. The attach
attach /tmp/foo bar.pdf does not result in an error, but the resulting
draft contains:
Attach: /tmp/foo
Whoops, let me amend that. When creating a test file I created _two_ files,
/tmp/foo and bar.pdf. So I removed /tmp/foo and bar.pdf, and I then tried
it again. I get:
What now? attach
Ken wrote:
What now? attach /tmp/foo bar.pdf
ls: /tmp/foo: No such file or directory
I guess
What now? attach /tmp/foo\ bar.pdf
works, but is non-intuitive to me.
What about this for $200? attach '/tmp/foo bar.pdf'
David
___
Nmh-workers
What about this for $200? attach '/tmp/foo bar.pdf'
That works! But I realize I now remember my real problem; tab-completion
via readline() fills in /tmp/foo bar.pdf without any shell quoting; I
think we need to be smarter there.
--Ken
___
What about this for $200? attach '/tmp/foo bar.pdf'
That works! But I realize I now remember my real problem; tab-completion
via readline() fills in /tmp/foo bar.pdf without any shell quoting; I
think we need to be smarter there.
And now that I think about it ... why does double-quotes not work
Ken wrote:
What about this for $200? attach '/tmp/foo bar.pdf'
That works! But I realize I now remember my real problem; tab-completion
via readline() fills in /tmp/foo bar.pdf without any shell quoting; I
think we need to be smarter there.
If you insert a single quote before hitting tab,
If you insert a single quote before hitting tab, readline will
quote the entire string.
Right, but I think we all agree that is terrible that you have to
know to do that.
I think there's a limit on how much we want to do here. Our
quoting support is already messy enough.
So, I took a look at
ralph wrote:
Are you aware of `forw -mime'?
yes, i am, but i did forget about it yesterday. i didn't, however,
know about the #forw mhbuild directive -- i had never looked at how
forw -mime works before today. no Content-Disposition header is
generated by #forw.
=--
paul
ralph wrote:
Are you aware of `forw -mime'?
yes, i am, but i did forget about it yesterday. i didn't, however,
know about the #forw mhbuild directive -- i had never looked at how
forw -mime works before today. no Content-Disposition header is
generated by #forw.
Just to provide some
so it turns out that if you attach a mail message to your draft, using:
Attach: /home/pgf/Mail/inbox/1982
then mhbuild will generate this:
Content-Type: message/rfc822; name=1982
Content-Description: 1982
Content-Disposition: attachment; filename=1982
which is fine. except that
many possibilities come to mind -- politely ask gmail to fix their
email infrastructure, augment Attach: with Inline:, make Attach:
always generate C-D: inline for some content types, never use
Attach: for email messages, go back to using raw mhbuild
directives for everything, etc.
Personally, I
ken wrote:
many possibilities come to mind -- politely ask gmail to fix their
email infrastructure, augment Attach: with Inline:, make Attach:
always generate C-D: inline for some content types, never use
Attach: for email messages, go back to using raw mhbuild
directives for
it's a shame to have to foist the decision as to which to use (Attach
or Inline) onto the user.
Well, at a fundamental level we pretty much have to foist that decision
to the user, right? Unless we hardcode a list of types.
perhaps a list of types which should be
inlined by default would be
it's a shame to have to foist the decision as to which to use (Attach
or Inline) onto the user.
Attachments are just that -- attachments. If you specify a disposition of
attachment (which we do), you can't complain about gmail doing what you
told it.
The Attach: header is just a simple
lyndon wrote:
it's a shame to have to foist the decision as to which to use (Attach
or Inline) onto the user.
Attachments are just that -- attachments.
kind of by definition. what client MUAs _do_ with those attachments
is a question of semantics. and what gmail did (i.e., nothing)
On Wed, May 14, 2014 at 3:27 PM, Paul Fox wrote:
If you specify a disposition of
attachment (which we do), you can't complain about gmail doing what you
told it.
au contraire. i can certainly complain, which is what i did. and now
we're talking about how to fix it.
Since the
kind of by definition. what client MUAs _do_ with those attachments
is a question of semantics. and what gmail did (i.e., nothing) surprised
me.
RFC 2183 is unambigious:
2.1 The Inline Disposition Type
A bodypart should be marked `inline' if it is intended to be
displayed
earl wrote:
On Wed, May 14, 2014 at 3:27 PM, Paul Fox wrote:
If you specify a disposition of
attachment (which we do), you can't complain about gmail doing what you
told it.
au contraire. i can certainly complain, which is what i did. and now
we're talking about how
lyndon wrote:
kind of by definition. what client MUAs _do_ with those attachments
is a question of semantics. and what gmail did (i.e., nothing) surprised
me.
RFC 2183 is unambigious:
2.1 The Inline Disposition Type
A bodypart should be marked `inline' if it is
i'm just a user. i used the most convenient method of forwarding an
entire mail message that nmh provides -- the method that i've been
encouraged to switch to over writing build directives, and i didn't
get the results i expected. sounds like maybe someone else had a
similar surprise with
Hi Paul,
i used the most convenient method of forwarding an entire mail message
that nmh provides -- the method that i've been encouraged to switch to
over writing build directives
Are you aware of `forw -mime'?
Cheers, Ralph.
___
Nmh-workers
Jon wrote:
Cool. Thanks. BTW, would it make sense to have a -v option on al
at whatnow where -v would mean verbose and show the mime type, etc?
That way the hard core among us could check and fall back to mhbuild
if they didn't like the way that it looked.
Done:
attach [-v [-a 0|1|2]]
David Levine levin...@acm.org writes:
Norm wrote:
I don't know that whatnow's attach ever gave me a blank
Nmh-Attachment header. What you are probably referring to
was my request that send silently remove any such
headers. I asked for that so that users could put them in
their templates to
Ralph Corderoy wrote:
David Levine levin...@acm.org writes:
Note that whatnow's attach will continue to allow attachment of
directories because it expands those out to their contents. It
doesn't check what the contents are, though. That's why we needed
to add this check.
I
Norm wrote:
David Levine levin...@acm.org writes:
Norm wrote:
I don't know that whatnow's attach ever gave me a blank
Nmh-Attachment header. What you are probably referring to
was my request that send silently remove any such
headers. I asked for that so that users could put them in
Oliver wrote:
Ralph Corderoy wrote:
David Levine levin...@acm.org writes:
Note that whatnow's attach will continue to allow attachment of
directories because it expands those out to their contents. It
doesn't check what the contents are, though. That's why we needed
to add
David Levine wrote:
Note that the current attach -r is an undocumented relic of the
implementation, because whatnow passes the -r to ls. Maybe it
shouldn't even be allowed. The whatnow documentation specifically
says attach files.
attach clearly passes any option you like to ls. And note
Hi David,
Maybe this is another argument for adding -d to the ls command. But
-d conflates not descending into directories with not dereferencing
symbolic links, so the display (alist) will show links.
That too is probably wanted? If I attach foo that's a symlink to bar by
naming foo then I
I'll skip all of the messages to which I'm responding since you've seen 'em
anyway.
Sorry that my quick and dirty hack is falling to pieces on you. Still works
fine for me, but that's probably 'cause I just attach file and don't try
to do anything else fancy.
My intent was that everything
Oliver wrote:
David Levine wrote:
Note that the current attach -r is an undocumented relic of the
implementation, because whatnow passes the -r to ls. Maybe it
shouldn't even be allowed. The whatnow documentation specifically
says attach files.
attach clearly passes any option you
Jon wrote:
Sorry that my quick and dirty hack is falling to pieces on you.
Still works fine for me, but that's probably 'cause I just attach
file and don't try to do anything else fancy.
Agreed. And I certainly wouldn't say it's falling to
pieces. I just view this as a chance to clean
David Levine writes:
Jon wrote:
Sorry that my quick and dirty hack is falling to pieces on you.
Still works fine for me, but that's probably 'cause I just attach
file and don't try to do anything else fancy.
Agreed. And I certainly wouldn't say it's falling to
pieces. I just view
David Levine wrote:
Does POSIX ls support -- ?
Yes. POSIX basically requires it for all utilities. See Guideline 10,
section 12.2. It works on the oldest systems I can currently log into
and I'm fairly sure I've used it since a long time ago. glob(3) would
probably still be a more robust
Hi David,
Does POSIX ls support -- ?
Absolutely.
http://pubs.opengroup.org/onlinepubs/009695399/utilities/ls.html refers
to
http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_02
which says
Guideline 10:
The argument -- should be accepted as a
Oliver wrote:
David Levine wrote:
Does POSIX ls support -- ?
Yes. POSIX basically requires it for all utilities. See Guideline 10,
section 12.2. It works on the oldest systems I can currently log into
and I'm fairly sure I've used it since a long time ago. glob(3) would
probably still be
Date:Tue, 18 Jul 2006 08:57:26 -0700
From:Jon Steinhart [EMAIL PROTECTED]
Message-ID: [EMAIL PROTECTED]
| I see no reason to allow messages to be converted and viewed except maybe
| for debugging. I realize that many on this mailing list are mail geeks.
I may or
Joel Reicher [EMAIL PROTECTED] writes:
This is part of the all power to the user idea...
I'm very curious. Where did you get that phrase?
Norman Shapiro
798 Barron Avenue
Palo Alto CA 94306-3109
(650) 565-8215
[EMAIL PROTECTED]
Joel Reicher [EMAIL PROTECTED] writes:
Joel Reicher [EMAIL PROTECTED] writes:
This is part of the all power to the user idea...
I'm very curious. Where did you get that phrase?
I have a copy of the Rand Note by you, Anderson, Bikson, and Kantar. :)
Oh :-)
Norman Shapiro
798
Based on the recent emails, I am thinking about a small modification
to sendfile() in whatnowsbr.c. This change would be to skip the test
for automimeproc if attach (in Whatnow(), would have to be made global)
is set.
This change would keep things from getting confused if someone has
Based on the recent emails, I am thinking about a small modification
to sendfile() in whatnowsbr.c. This change would be to skip the test
for automimeproc if attach (in Whatnow(), would have to be made global)
is set.
I'm not entirely sure what you mean in code terms, but I'd much prefer it
43 matches
Mail list logo
