[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] Conflict between "mime" command and attach

From: Ken Hornstein
Subject: Re: [Nmh-workers] Conflict between "mime" command and attach
Date: Sat, 07 Dec 2013 13:48:15 -0500

>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? :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]