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 "#", then it's a content-type.
Then we wouldn't need to default to -nodirectives. Directives
are arcane enough that I think collisions with non-directive
text are unlikely. But maybe those who have been using them for
the last decade should comment on that :-)
So, I fit that bill. Here's the evolution of my thinking:
- 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 use mhbuild directives, and I use them enough that I remember the syntax.
But it's a fair amount of typing. E.g.:
#application/pdf {attachment} /path/to/file
Also, no auto-complete! It works and you get exact control over the
MIME content, but it sucks.
- Attach is, FOR THE GENERAL case, much nicer. Does the right thing and
I can forget about the details.
It's not the pseudo-header, it's the mhbuild directives. "attach"
users can't view/modify them now. This would be a benefit, and
though I have cured myself of the urge to look at them, I would if
I could.
Well, that's what I was thinking with #attach; that would give you the
benefits of attach (picking the MIME type and automatically adding
the right disposition).
If we're going to address that, I think we should step back and
consider whether some other approach would make sense. I don't
think adding more directive types just to simplify the user
interface is a good idea.
Well, I'm not completely wedded to this idea; that's why I asked for
feedback. What do you think we should do instead?
At the cost of arcane-ness, which would increase the likelihood
of confusion of text with an mhbuild directive.
More arcane than the existing syntax? :-)
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers