Ken wrote:
Jon wrote:
My opinion is that having special characters in the body is bad,
like crossing the beams. It was a good hack at the time but should
be put out of our misery. I think that all MIME composition should
be done via headers.
...
It's fine for 90% of what people
resurrecting an old thread, but a continuing issue...
ken wrote:
- I use to run with automimeproc set. But that's lousy; if you include C
code in your text, it fails. Totally non-obvious and I always forget it.
It got to be such a problem that I turned it off.
i don't recall us ever
i don't recall us ever discussing the possibility of making the '#'
character that introduces mhbuild directives configurable by the user.
for instance, if the leading character were '}', i don't think i would
ever have a conflict with real text.
interpretation of those directives is strictly
ken wrote:
part text/plain1020
i don't recall us ever discussing the possibility of making the '#'
character that introduces mhbuild directives configurable by the user.
for instance, if the leading character were '}', i don't think i would
ever have a conflict
Paul Fox writes:
ken wrote:
part text/plain1020
i don't recall us ever discussing the possibility of making the '#'
character that introduces mhbuild directives configurable by the user.
for instance, if the leading character were '}', i don't think i would
There used to be some leakage; for example, the old attach
implementation would parse the Nmh-Attachment headers and then create
mhbuild directives. I am not sure there is any leakage now. But
I am not in love with the idea of changing the leading character,
because that opens the box
My opinion is that having special characters in the body is bad, like crossing
the beams. It was a good hack at the time but should be put out of our misery.
I think that all MIME composition should be done via headers. Y'all have done
a bunch of work on my original attachment stuff. In what
jon wrote:
part text/plain1607
Paul Fox writes:
ken wrote:
part text/plain1020
i don't recall us ever discussing the possibility of making the '#'
character that introduces mhbuild directives configurable by the user.
for
for me? it's new-fangled, and i don't trust it. ;-)
Geez Paul, we only had like a huge discussion about this back in
December :-/
seriously, it's just not how i've been doing attachments for the last
15 years. my current mechanism [1] trivially lets me attach either
files or MH messages (e.g.
ralph wrote:
part text/plain 307
Hi Paul,
for instance, if the leading character were '}', i don't think i would
ever have a conflict with real text.
C source code?
doh!
i originally thought of ')', and ']', and extrapolated incorrectly
to any righthand
On Apr 14, 2014, at 3:33 PM, Ralph Corderoy ra...@inputplus.co.uk wrote:
C source code?
Cheers, Ralph.
i think this mailing list thread is going into my fortunes file ;-)
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Right now a user can sit down, compose a message that happens to contain
8-bit characters, and send it out ... and nmh will happily blast it out,
with no MIME headers at all. This is super-wrong. And it's not a
theoretical problem either:
Hi Rickard,
This is a very treacherous source of embarassment, because you may for
some time be unaware of the peculiar appearance of your outgoing
e-mail. I for one don't need my MUA to make me look stupid, I usually
manage unaided.
You know of the workaround where you alter your initial
Hi!
You know of the workaround where you alter your initial drafts to have
hard-coded
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
headers, altered to suit?
Maybe I was half aware of the possibility of such a workaround,
Hi Ken,
Well, let me make this alternate proposal:
- attach adds Nmh-Attachment headers as per usual. Maybe we'll add
something like: attaching foo.pdf to message as application/pdf so
the user can see what MIME type is being used (really, that's all I
care about).
- You can add or not
ralph wrote:
Hi Ken,
Well, let me make this alternate proposal:
- attach adds Nmh-Attachment headers as per usual. Maybe we'll add
something like: attaching foo.pdf to message as application/pdf so
the user can see what MIME type is being used (really, that's all I
care
Hi Paul,
- If you try to attach after a mime, you get an error.
- send runs mhbuild -auto -nodirectives. -auto means, don't
error out if there's a MIME-Version header, just don't process
the draft. -nodirectives means don't process directives.
But ... Nmh-Attachment
Paul F. wrote:
i'm having trouble with the next two points:
- If you try to attach after a mime, you get an error.
- send runs mhbuild -auto -nodirectives. -auto means, don't
error out if there's a MIME-Version header, just don't process the
draft. -nodirectives means
ralph wrote:
Hi Paul,
- If you try to attach after a mime, you get an error.
- send runs mhbuild -auto -nodirectives. -auto means, don't
error out if there's a MIME-Version header, just don't process
the draft. -nodirectives means don't process directives.
Ralph Corderoy writes:
Hi Ken,
Well, let me make this alternate proposal:
- attach adds Nmh-Attachment headers as per usual. Maybe we'll add
something like: attaching foo.pdf to message as application/pdf so
the user can see what MIME type is being used (really, that's all I
care
Hi Paul,
Because the mhbuild step can only turn a non-MIME email into a MIME
one; it can't handle being given a MIME email as input.
that's what i thought. but if that's so, then how does the last bit:
But ... Nmh-Attachment headers are still processed.
work?
They can only be put
Hi Jon,
So my opinion is to live with it for now. If you're happy with
attach, then use it. If you want to use mhbuild, go ahead. Just
don't use both.
A decent point. I think Ken's go to make *some* changes to cope with
always running mhbuild even though I've manually'd mime'd earlier.
ralph wrote:
Hi Paul,
Because the mhbuild step can only turn a non-MIME email into a MIME
one; it can't handle being given a MIME email as input.
that's what i thought. but if that's so, then how does the last bit:
But ... Nmh-Attachment headers are still processed.
Hi Paul,
They can only be put there by attach which refuses to do so if
mime has already been run. It knows this by seeing MIME-Version
is present.
that's not true. Nmh-Attachment headers can be inserted manually as
well, bypassing that attach error check.
Thus my quotes around
Jon wrote:
So my opinion is to live with it for now. If you're happy with
attach, then use it. If you want to use mhbuild, go ahead. Just
don't use both. Save your energy for a coding effort with a greater
value proposition.
The movtivation behind all this is to always produce MIME
Wow, I take a day off to get some Christmas stuff done, and this discussion
explodes. To summarize a bunch of emails ...
Paul Fox wrote:
if mhbuild -auto -nodirectives can still process Nmh-Attachment
directives at this point, then why can't attach after a mime still
work? couldn't running
I will note one thing: I discovered recently that mutt supports an
Attach header, which does exactly what you'd expect it to do. So there
is prior art here.
--Ken
Humph! Have to check the logs, I thought that I was the prior art. Humbug.
My mistake; I believe you were first. My key
You pointed out,
http://lists.nongnu.org/archive/html/nmh-workers/2013-12/msg00038.html,
the two paths, starting with mbuild-directives and attach-headers, take
a long time to converge and interfere. mime runs mhbuild, job done.
attach puts in the header which is seen late-on by post(8), and only
On Dec 12, 2013, at 12:56 PM, Ken Hornstein k...@pobox.com wrote:
How about if `#' was configurable and could be multiple characters? And
that could further be overridden on a per-message basis by an
nmh-header?
Hmm ... that just strikes me as too complicated. I mean, it just feels
like
How does that look? More code rework, but it feels better. Also, with this
I think it actually accomplishes what you want (attach + inspection).
One additional thing ... I'd like to get rid of the ability of specifing
the header name and just go with Nmh-Attachment. I realize that's an
Whew! Now that that's out of the way, I'll stick my neck out on what I'd like
to see...
The worst part to me (since attach was added) in nmh is reading MIME messages.
o I'd like to eliminate mhlist, mhstore, and mhshow from the ui.
I can kind of get behind some of that ... those are obvious
Ken Hornstein writes:
How does that look? More code rework, but it feels better. Also, with this
I think it actually accomplishes what you want (attach + inspection).
One additional thing ... I'd like to get rid of the ability of specifing
the header name and just go with Nmh-Attachment.
Jon Steinhart j...@fourwinds.com writes:
Ken Hornstein writes:
I will note one thing: I discovered recently that mutt supports an
Attach header, which does exactly what you'd expect it to do. So there
is prior art here.
--Ken
Humph! Have to check the logs, I thought that I was the
+1 to jon's proposal below. but this is probably enmh (even newer mail
handler), not nmh. because to support it we'll have to bite a
long-avoided architectural bullet and put all of the logic in a callable
library, of which the command line tools are wrappers around option
parsing and the
Hi Jon,
The attach thing is interesting to me socially because even you
mhbuild-lovers are using attach
Minor point: I don't use attach, never have, as I can't see the MIME
that will be sent. :-)
Cheers, Ralph.
___
Nmh-workers mailing list
Ralph Corderoy writes:
Hi Jon,
The attach thing is interesting to me socially because even you
mhbuild-lovers are using attach
Minor point: I don't use attach, never have, as I can't see the MIME
that will be sent. :-)
Cheers, Ralph.
I stand corrected.
Ken wrote:
Well, let me make this alternate proposal:
- attach adds Nmh-Attachment headers as per usual. Maybe we'll add
something like: attaching foo.pdf to message as application/pdf so
the user can see what MIME type is being used (really, that's all
I care about).
- You can
ralph wrote:
Hi Jon,
The attach thing is interesting to me socially because even you
mhbuild-lovers are using attach
Minor point: I don't use attach, never have, as I can't see the MIME
that will be sent. :-)
i've never used it either. partly it's because i didn't know
One question: would it make sense to put the entire mhbuild
directive in the Nmh-Attachment header instead of just the
path? Users could then edit it as they wish.
I feel the answer is no. I would like to give users the option to add
their own Nmh-Attachment headers; if that's just a filename,
Paul F. wrote:
mainly it's because attach removes attachment from the flow of
composition -- i have to remember to attach _after_ i've written out
my draft, which to me is the ready to send point. i forget to
include the attachment often enough as it is -- i much prefer adding
an attachment
Ken wrote:
One question: would it make sense to put the entire mhbuild
directive in the Nmh-Attachment header instead of just the
path? Users could then edit it as they wish.
I feel the answer is no. I would like to give users the option to
add their own Nmh-Attachment headers; if
[...]
I wasn't suggesting that any of this be done now. I was suggesting a path to a
better ui so that folks can bicker about it and eventually agree on something
that we could work towards.
That's fair ... I was just looking at it from a ok, these things you want,
how exactly could they be
Ken Hornstein writes:
It depends on priorities: I'd rather be able to customize
an attachment than manually insert a simple Nmh-Attachment
header (I think that's the option you mention). I've never
done that.
It's just that when I hear the word customize, I ask the question:
If you want
+1 to jon's proposal below. but this is probably enmh (even newer mail
handler), not nmh. because to support it we'll have to bite a
long-avoided architectural bullet and put all of the logic in a callable
library, of which the command line tools are wrappers around option
parsing and the
Paul Fox writes:
jon wrote:
Ken Hornstein writes:
It depends on priorities: I'd rather be able to customize
an attachment than manually insert a simple Nmh-Attachment
header (I think that's the option you mention). I've never
done that.
It's just that when I hear the
As with my attach addition which is way more contentious now than it
was when I implemented it, my proposal on side is compatible with the
existing ui. It would look the same if you didn't turn on any of the
new options. Could even leave mhlist et. al. in place for any who
love 'em. It's true
Actually, I sent out a ton of email on it. Starting on 8/13/00. I still
have the emails if they were lost due to the change. For example:
I stand corrected! I did look in the archives on mhonarc.org (the most
complete copy I could find), but there's a gap between 1999-04 and
2002-06.
--Ken
david wrote:
Ken wrote:
Can the people who want to have attach append mhbuild directives
explain what their thinking is, specifically why they think their
approach is preferrable? I went back and looked at the thread very
carefully, and none of the proponents of this approach
Paul wrote:
that's an interesting point, and i just realized that it's one reason
i've never been comfortable with attach. my editor supports enough
filename completion that when inserting the mhbuild directive (via a
helper script), i can be sure that the filename is spelled correctly
and
Hi Ken,
The reason this is cropping up now is that we want to get to the point
where a MIME headers are always generated (I assume this is
non-controversial).
Looks down. Mumbles No. Scuffs foot.
Using the tools we have, this means running mhbuild. This was never
designed to be run all
Ralph Corderoy writes:
Hi Ken,
The reason this is cropping up now is that we want to get to the point
where a MIME headers are always generated (I assume this is
non-controversial).
Looks down. Mumbles No. Scuffs foot.
No, I don't always want MIME headers. I'm old-fashioned and
Hi Jon,
No, sorry, when I said edit I was referring to a whatnow-entry to
put me back in vi so I can read-only peruse the outcome of mime.
My intent is always to have mime do the work; if something's not
right I go back to pre-mime and fix it because mhbuild could
always do want I want
Ralph Corderoy writes:
Hi Jon,
No, sorry, when I said edit I was referring to a whatnow-entry to
put me back in vi so I can read-only peruse the outcome of mime.
My intent is always to have mime do the work; if something's not
right I go back to pre-mime and fix it because mhbuild
david wrote:
Paul wrote:
that's an interesting point, and i just realized that it's one reason
i've never been comfortable with attach. my editor supports enough
filename completion that when inserting the mhbuild directive (via a
helper script), i can be sure that the filename
What I like about attach is that it just does the right thing and I don't
have to know how it does it internally. It would be really nice if the
same were true with other parts of the ui. The nmh MIME support comes
across to me as a wart. No offense intended, it's a really useful wart and
I use
To deal with the false directives when using attach:
WhatNow could look for any lines that begin with # during
the first call to attach, and warn or refuse. Those who
use # for replied-to text would have to find something else.
Or we could get more sophisticated, back to the challenging
aspect
Ken Hornstein writes:
Gave this a bit more thought. What *exactly* is the issue? Is it a lack of
confidence that attach will do the *right thing* and the desire to check and
change it if desired?
No, I read it as people are suggesting to solve the mime/attach conflict
to change attach to
Ken wrote:
Can the people who want to have attach append mhbuild directives
explain what their thinking is, specifically why they think their
approach is preferrable? I went back and looked at the thread very
carefully, and none of the proponents of this approach really covered
why they
Ken wrote:
[Ralph wrote:]
If attach instead appended an mhbuild directive to the draft, would
that make the path after that simpler?
No.
My feeling is that if you put a mhbuild directive in the draft,
you're prepared to deal with any issues arising from it. But I
don't think it's
Why wouldn't that be reasonable? The logic would be simpler:
In WhatNow?
- If you run mime, run mhbuild on the draft.
- If you attach, add the appropriate mhbuild directive. Do not do
this if there is a MIME-Version header.
In post(8):
- Run mhbuild -auto -nodirectives.
The problem here
Why wouldn't that be reasonable? The logic would be simpler:
In WhatNow?
- If you run mime, run mhbuild on the draft.
- If you attach, add the appropriate mhbuild directive. Do not do
this if there is a MIME-Version header.
In post(8):
- Run mhbuild -auto -nodirectives.
The
As the guy who created this mess in the first place, I appreciate the work
that y'all are doing 'cause I unfortunately don't have time right now.
I take the blame for attach beinging incompatible with mhbuild because it
uses mhbuild internally. The problem is that attach has to deal with drafts
Hi Ken,
It would also mean I could attach, then edit to look at it,
perhaps embellish, then mime to process it, then edit again to
check things over before I send
You can do this now; if you attach, you can edit the draft and adjust
the pseudo-header that attach adds.
It does not allow
I think it'd be worth trying to solve that. Could we look for
false mhbuild directives and escape them if not already escaped?
I think it would be challenging; the code that does that is the regular
MIME parsing code. Also, the syntax is that if it's not something that
is recognized after the
You can do this now; if you attach, you can edit the draft and adjust
the pseudo-header that attach adds.
It does not allow me to look at it post-mime, as mhbuild directives
do.
I guess my feeling is that attach is for people who don't want to look
at the content post-mime. But that's what
Gave this a bit more thought. What *exactly* is the issue? Is it a lack of
confidence that attach will do the *right thing* and the desire to check and
change it if desired?
If so, I have two fairly simple suggestions:
1. Add a -check option to the whatnow attach command that generates a
I think it'd be worth trying to solve that. Could we look for
false mhbuild directives and escape them if not already escaped?
I think it would be challenging; the code that does that is the regular
MIME parsing code. Also, the syntax is that if it's not something that
is recognized after
Jon wrote:
Gave this a bit more thought. What *exactly* is the issue?
I'll take a shot, but Ken can probably do better: we want
nmh to always produce mime messages without getting confused
by text that isn't a mhbuild directive but looks like it,
while still supporting attach.
Is it a lack
Hi Ken,
But it's a fair amount of typing. E.g.:
#application/pdf {attachment} /path/to/file
Also, no auto-complete!
Don't know what editor you're using, but in vim I
!!ls /s^I/lo^I/pa^I/to/f^I
on a blank line to get auto-complete on /some/long/path/to/file.
Cheers, Ralph.
Me again,
But it's a fair amount of typing. E.g.:
#application/pdf {attachment} /path/to/file
Also, no auto-complete!
Don't know what editor you're using, but in vim I
!!ls /s^I/lo^I/pa^I/to/f^I
on a blank line to get auto-complete on /some/long/path/to/file.
Thinking it
Hi Ken,
The way that attach works is that when you mark a file to be attached,
it ends up with a special header in the message. post(8) sees this
header and constructs mhbuild directives and runs it for you. That
works fine.
The way the mime command works is that it just runs mhbuild for
If attach instead appended an mhbuild directive to the draft, would
that make the path after that simpler?
No.
My feeling is that if you put a mhbuild directive in the draft, you're
prepared to deal with any issues arising from it. But I don't think it's
reasonable to use attach and have it put
The final piece to making MIME encoding happen by default to simply run
it at send(1) time (really post(8)). But as always, there's a slight wrinkle.
Right now we have two basic ways of doing attaching files; you can use
the attach command at the What now? prompt, or put in mhbuild(1) directives
73 matches
Mail list logo
