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 th
Hi David,
> - 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.
It would also mean I could "attach", then "edit" to look at it, perhaps
embellish, then "mime" to process it, then "edit" a
>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".
Th
> >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 -au
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
t
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.
>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
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 list
> >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 recognize
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
Illumos is alive and well and the dust is settling quickly.
That's the unified fork of the last OpenSolaris X86 and
rumors of its death are grossly premature.
And frankly, if I could take as much money as Real Solaris still
takes in the Enterprise space, I'd think hard about being dead.
-mo
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.
Think
I wrote:
> Valdis wrote:
>
> > Verdict: elinks is introducing the 3 blanks.
>
> Thanks, I'll install elinks and see what I can do to handle it.
The test relies on diff -b to compare the text lines.
Two problems here:
1) POSIX diff only has -b (not -w), and it says that a line with
no space
Hi David,
> The test relies on diff -b to compare the text lines.
> Two problems here:
>
> 1) POSIX diff only has -b (not -w), and it says that a line with no
> space is different than the otherwise same line with leading space.
sed 's/^/ /' on both files beforehand would make -b happy? Expecte
Hi David,
> uniq >"$actual"
BTW, the comment says that's there to squash adjacent blank lines but it
would obviously do more than that. This bit of awk does a `cat -s'.
awk '!length && e {next} {e = !length} 1'
It's possible in sed too. ;-)
Cheers, Ralph.
___
Ralph wrote:
> sed 's/^/ /' on both files beforehand would make -b happy? Expected can
> be done once, actual each time...
That works.
> > 2) elinks inserts some non-breakable spaces (U+00A0), and GNU diff
> > doesn't recognize them as whitespace (my LANG is en_US.UTF-8).
>
> Here, this elinks
I wrote:
> I put in that awk magic.
Ah, but it busts on Solaris:
awk: syntax error near line 1
awk: bailing out near line 1
At least we know where the problem is. What's your sed
equivalent of cat -s?
David
___
Nmh-workers mailing list
Nmh-work
Date:Sat, 07 Dec 2013 21:35:28 -0500
From:David Levine
Message-ID: <750-1386470128.376...@r5-r.w77m.eywx>
| Ah, but it busts on Solaris:
| What's your sed equivalent of cat -s?
Sed would be a bit messier, but you really don't need it, just
slightly "less concise
Hi!
> > > Verdict: elinks is introducing the 3 blanks.
Forgive me for maybe being silly due to ignorance of Nmh internals, but
'elinks -dump' introducing leading whitespace might perhaps be remedied by
> elinks -eval 'set document.browse.margin_width = 0' -dump [...]
- ? Just a humble tho
21 matches
Mail list logo
