Date:Sun, 07 Jul 2019 19:39:47 -0700
From:"Ronald F. Guilmette"
Message-ID: <42579.1562553...@segfault.tristatelogic.com>
| I confess I have and did explicitly set within my personal .login file
| thusly:
|
|setenv LANG en_US.UTF-8
That should be fine
In message <13507.1562541...@jinx.noi.kre.to>, you wrote:
>Date:Sun, 07 Jul 2019 12:56:13 -0700
>From:"Ronald F. Guilmette"
>Message-ID: <41320.1562529...@segfault.tristatelogic.com>
>
> | But to answer Ralph's inquiry...
> |
> |
> | LANG=en_US.UTF-8
> |
Date:Sun, 07 Jul 2019 21:43:37 -0400
From:David Levine
Message-ID: <9828-1562550217.965...@xegg.pdiv.zhwy>
| That looks like the output of locale(1) rather than variable
| assignments.
Ah yes - even though that's what Ralph asked for, I didn't bother
to imagine
Date:Sun, 07 Jul 2019 12:56:13 -0700
From:"Ronald F. Guilmette"
Message-ID: <41320.1562529...@segfault.tristatelogic.com>
| But to answer Ralph's inquiry...
|
|
| LANG=en_US.UTF-8
| LC_CTYPE="en_US.UTF-8"
| LC_COLLATE="en_US.UTF-8"
|
Ralph writes:
> What if mhfixmsg could also append a new text/plain after the existing
> one, i.e. with a rank that's `better quality'. (Assuming RFCs allow two
> multipart/alternative with the same MIME type.)
That's a good idea. (My read of RFC 2045 is that it is allowed.)
Though in this
In message <20190707172213.aeaff21...@orac.inputplus.co.uk>,
Ralph Corderoy wrote:
>> > Here is what I have set. is this what you are talking about? Or do
>> > I need to fiddle sonmething else entirely?
>> >
>> > % env | fgrep LOCALE
>> > XTERM_LOCALE=en_US.UTF-8
>>
>> Yeah, that's
Hi Ken,
> > Here is what I have set. is this what you are talking about? Or do
> > I need to fiddle sonmething else entirely?
> >
> > % env | fgrep LOCALE
> > XTERM_LOCALE=en_US.UTF-8
>
> Yeah, that's correct.
Is it? That's only xterm(1)'s locale. I think rfg should show us the
output of
Hi,
rfg wrote:
> I have trouble believe that in this day and age, when we have had
> REALLY widespread use of HTML for around a couple of decades now, that
> there are still -zero- tools tyat can quicky render HTML into plain
> text without mucking it up somehow.
I found
Hi David,
rfg wrote:
> > All these in combination you end with a reasonable reply to HTML
> > emails. The downside is that you don't get to keep the original
> > email unless you make a copy of it and it's fairly hacky.
>
> Thanks for all the tips, but this is a non-starter for me. I need to
>
On Wed, Jul 3, 2019, 3:33 PM Ronald F. Guilmette
wrote:
>
> To answer your question, no, I have not reinstalled NMH, and I'm not even
> sure if that would be a Good Idea at this point or not.
>
Maybe give this a quick try?
repl -filter mhl.replywithoutbody -convertargs text/html ''
In message <20190703205641.363657e...@pb-smtp21.pobox.com>,
Ken Hornstein wrote:
>I think that should be pretty straightforward, with the exception we don't
>have any internal tools to show just ONE Received: line.
Perhaps this will end up being my one and only contribution
to the project.
>I'm sure that building the port will crate a situation in which
>thinks -could- all work well. But I still have all of these
>mucked-up personal configuration files, both ~/.mh_profile and
>also several sub-configuration files underneath my Mail/ directory.
>(I wish that all this stuff could be
Thanks again Ken.
I'm sure that building the port will crate a situation in which
thinks -could- all work well. But I still have all of these
mucked-up personal configuration files, both ~/.mh_profile and
also several sub-configuration files underneath my Mail/ directory.
(I wish that all this
>To answer your question, no, I have not reinstalled NMH, and I'm not even
>sure if that would be a Good Idea at this point or not.
Well, it might be! See below ...
>I need to make clear also that on FreeBSD one has a choice of installing
>a particular thing as a pre-built binary "package" ro
In message <20190703182013.00a75153...@pb-smtp2.pobox.com>,
Ken Hornstein wrote:
>So, circling back to this ...
>
>Ronald, I was communicating with Cy Schubert, the maintainer of the FreeBSD
>nmh port, and he said to me, "Hey, did you realize that we DO all of the
>stuff to make replyfilter
So, circling back to this ...
Ronald, I was communicating with Cy Schubert, the maintainer of the FreeBSD
nmh port, and he said to me, "Hey, did you realize that we DO all of the
stuff to make replyfilter work if you enable that option?" And when I
looked at the port Makefile I realized he was
Alright, now that I have some more free time ...
>>Ok, these things are not hard.
>
>Speak for yourself! My little pea brain is still trying to grok all
>this.
Well, I meant that I think all of the TOOLS are there and mostly stuff
should work with a little help.
>>I don't know if the package
Ken writes:
> The most COMMON cause of
> this is putting in a blank line, but other things that do not look like
> message headers also can cause this.
In this case, it's this line:
repl -filter mhl.replywithoutbody -convertargs text/html '' -convertargs
text/plain ''
There's no colon after
> repl: no blank lines are permitted in .mh_profile
>
>Can you (or anyone) explain that to me? There are, and were, *no* blank
>lines in my ~/.mh_profile file!
Sigh. See my reply to Conrad's question about this, here:
https://lists.nongnu.org/archive/html/nmh-workers/2019-06/msg00132.html
In message <2180-1561898527.224...@mszx.gafd.XHR7>,
David Levine wrote:
>rfg wrote:
>
>> Anyway, this is most definitely NOT working. Look at this, which I cut
>> and pasted from my xterm window when I tried to do a repl:
>
>Does this work better?
>
> repl -filter mhl.replywithoutbody
> Then enter mime at the "What now?" prompt if you want to edit the draft.
Or to skip that step,
repl -filter mhl.replywithoutbody -convertargs text/html '' -convertargs
text/plain '' -editor mhbuild
David
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Focusing on just ONE thing, since I just woke up ...
>Anyway, this is most definitely NOT working. Look at this, which I cut
>and pasted from my xterm window when I tried to do a repl:
>
>https://pastebin.com/raw/KzuXRg04
>
>I don't think that this is or was the intended effect.
Did you
rfg wrote:
> Anyway, this is most definitely NOT working. Look at this, which I cut
> and pasted from my xterm window when I tried to do a repl:
Does this work better?
repl -filter mhl.replywithoutbody -convertargs text/html '' -convertargs
text/plain ''
Then enter mime at the "What now?"
In message <20190628144427.4845f70...@pb-smtp20.pobox.com>,
Ken Hornstein wrote:
>Ok, these things are not hard.
Speak for yourself! My little pea brain is still trying to grok all this.
>First, delete the entries for showproc and showmimeproc; the defaults
>for these programs are fine (they
- replfilter depends on 'par', which users may not have installed,
>
>FreeBSD comes with a tool called "fmt" pre-installed, so I guess I need
>to use that in place of par, yes?
You could, or you could install par from FreeBSD ports (I double-checked
and it is in there).
>OK, so where do I
In message <20190628004843.96a946c...@pb-smtp20.pobox.com>,
Ken Hornstein wrote:
>>> - replfilter depends on 'par', which users may not have installed,
FreeBSD comes with a tool called "fmt" pre-installed, so I guess I need
to use that in place of par, yes?
OK, so where do I make that
Catching up on my emails...
In message <7376.1561672209@localhost>,
Michael Richardson wrote:
>Ronald F. Guilmette wrote:
>> Quite simply, all I would wish for would be something that would
> -properly-
>> convert -both- HTMLized emails -and- "Content-Transfer-Encoding: base64"
>
>Apologies if I offended, unintentionally.
Not offended at all; I am more lamenting that we didn't do better.
>>If you are building from source, _if_ you have one of the common
>>text-based HTML browsers available (I use w3m, but we also support lynx
>>and elinks), then show(1) does the right
spaceman via nmh-workers wrote:
> mhfixmsg does this pretty well I think, you just have to use it in
> your procmail rules.
mhfixmsg doesn't have to be invoked from procmail. I do that so that
I can easily grep my messages, but that's certainly not required.
I use the aliases in
ct: Re: [nmh-workers] Formatting HTML to Text: netrik.
>
> In message ,
> Conrad Hughes wrote:
>
> > - replfilter depends on 'par', which users may not have installed, but
>
> U... I don't have that either. What is it and where do I get it?
>
> >Finally, I'd almo
In message ,
Conrad Hughes wrote:
> - replfilter depends on 'par', which users may not have installed, but
U... I don't have that either. What is it and where do I get it?
>Finally, I'd almost be inclined to have nmh-without-replfilter display a
>message about replfilter, for example
In message <20190627232032.737b9159...@pb-smtp1.pobox.com>,
Ken Hornstein wrote:
>>I had just sort-of jury-rigged my own very local and very idiosyncratic
>>mechanism for dealing with the problem/issue some years ago, and I have
>>been just trying to struggle along with it for all this time
> - replfilter depends on 'par', which users may not have installed, but
>the failure mode in its absence is suboptimal: the quoted text is
>absent, and the error shown on the command line is something like
>
> Pipe reader process exited with 72057594037927935
>
>.. could well be
Ken> As for repl(1), we've shipped with replyfilter in $(DOCDIR)/contrib
Ken> since 1.5 (released in 2012), and I use it on every message.
Just to say thanks for your patience on this: has been bugging me for a
while, and finally just sitting down and unpacking replfilter made a
huge difference.
>I had just sort-of jury-rigged my own very local and very idiosyncratic
>mechanism for dealing with the problem/issue some years ago, and I have
>been just trying to struggle along with it for all this time because
>I just haven't had the time to find a proper fix... which I've always
>assumed is
Ronald F. Guilmette wrote:
> Quite simply, all I would wish for would be something that would
-properly-
> convert -both- HTMLized emails -and- "Content-Transfer-Encoding: base64"
> emails (like this one I'm responding to) into good old fashioned ascii,
> at least for purposes
In message <20190627202344.7389f...@enterprise.home.antispaceman.com>,
spaceman wrote:
>All these in combination you end with a reasonable reply to HTML emails.
>The downside is that you don't get to keep the original email unless you
>make a copy of it and it's fairly hacky.
Thanks for all
Hi,
Ronald F. Guilmette wrote:
> Quite simply, all I would wish for would be something that would -properly-
> convert -both- HTMLized emails -and- "Content-Transfer-Encoding: base64"
> emails (like this one I'm responding to) into good old fashioned ascii,
> at least for purposes of the "show"
In message <20190627125114.70a3921...@orac.inputplus.co.uk>,
Ralph Corderoy wrote:
>Revisiting once again the issue of nice text from horrible HTML emails...
And here, all this time, I thought that it was just me! I assumed
that I had just failed to read the documentation well enough or long
Ralph Corderoy wrote in <20190627125114.70a3921...@orac.inputplus.co.uk>:
|Revisiting once again the issue of nice text from horrible HTML emails,
|I found another textual web browser, like lynx(1), etc., but
|http://netrik.sourceforge.net/ uses colour in its --dump output.
|It doesn't list
Hi,
Revisiting once again the issue of nice text from horrible HTML emails,
I found another textual web browser, like lynx(1), etc., but
http://netrik.sourceforge.net/ uses colour in its --dump output.
It doesn't list the URL destinations though, e.g. the noisy `[42]' that
links prefixes to the
41 matches
Mail list logo
