Re: is it possible to have two options for viewing html mail?

[Kevin J. McCarthy]

On Sun, Oct 25, 2020 at 09:41:11AM -0700, Kevin J. McCarthy wrote:

On Sun, Oct 25, 2020 at 11:39:13AM +0900, Kenichi Asai wrote:

For docx file, I think I have exactly the same thing:

application/vnd.openxmlformats-officedocument.wordprocessingml.document;open -a 
preview -n -W %s; nametemplate=%s.docx
application/vnd.openxmlformats-officedocument.wordprocessingml.document;textutil
 -stdout -cat txt %s; copiousoutput

but the file is always opened using preview, no matter I press Enter
or m.  Why?  How can I configure so that when I press Enter, textutil
is used but when I enter m, preview is used?


The attachment viewing code is a bit convoluted.  I don't believe 
there is currently a way to do what you want.


In git master, I've just added a new function,  which will 
use a copiousoutput mailcap entry, or else fall back to displaying raw 
text.


I find this behavior more helpful than , which I rarely need, 
so I've bound T to  instead, and Esc-t to .


  bind attach \et view-text
  bind attach T view-pager

I've also added a section in the manual that describes the different 
attachment viewing functions: 



--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: is it possible to have two options for viewing html mail?

[Globe Trotter via Mutt-users]

Thank you for this!This works beautifully for now, and I have made a list of my 
browsers with it: w3m, dillo, midori, firefox and chromium in that order. 





On Sunday, October 25, 2020, 7:57:09 PM CDT, raf  wrote: 





On Sun, Oct 25, 2020 at 11:38:01PM +, Globe Trotter via Mutt-users 
 wrote:

> On Sunday, October 25, 2020, 5:53:20 PM CDT, raf  wrote: 
> 
> On Sun, Oct 25, 2020 at 12:18:26AM +, Globe Trotter via Mutt-users 
>  wrote:
> 
> > On Saturday, 24 October at 22:54, Mutt Users wrote:
> > 
> > >> Lots of people send me mail in HTML format (even though I do not
> > >> like it). I have the following set up in my .mailcap:
> > >> text/html; w3m -I %{charset} -T text/html; copiousoutput
> > >> so it converts things using w3m more or less okay, however, I
> > >> am wondering is it possible to have an option for viewing using
> > >> midori/firefox for the cases where w3m is not enough?
> > 
> > > I've got this in my mailcap:
> > 
> > > text/html; w3m -I %{charset} -T text/html -dump; copiousoutput; print = 
> > > qutebrowser %s; nametemplate=%s.html
> > 
> > > To open an email in w3m press Enter, in qutebrowser p or whatever
> > > print is bound to. You can adapt this for firefox.
> > 
> > > Hope that helps.
> > > Regards Wim
> > 
> > This solution does exactly what I want. I wanted to use midori, so I
> > replaced qutebrowser with midori and it works.
> > 
> > Is it possible to have multiple options? So, in case midori did not
> > cut it, I would use firefox instead?
> > 
> > TIA!
> 
> Rather than invoking actual browsers directly, you
> could write a script that presented you with a list of
> options, and you enter your choice. That way, you could
> have more that two options. If always having to select
> a browser manually is too inefficient, you could
> continue to invoke w3m when viewing html, and invoke
> this menu-based browser chooser when "printing" html.
> 
> cheers,
> raf
> 
> Thanks, where would this option be presented? While I press "p"?

I think that would be best, so that you can decide
whether or not you want to manually select a browser.
By only invoking this script for "printing" the
attachment, you can still access the easier default
behaviour when viewing the attachment. But it probably
means you can't print the attachment, unless you add
that as one of the choices.

> Is the script in mutt or a bash/python/perl/etc script?

It would be a separate script referred to in your .mailcap
file. Here's a sample implementation:

In your ~/.mailcap (or whatever your mailcap_path is set to):

  text/html; w3m -I %{charset} -T text/html -dump; copiousoutput; print = 
select-browser %s; nametemplate=%s.html

Attached is the command select-browser which would need
to be in your $PATH. Note that it doesn't support all
of the % expansions that mailcap(5) supports. It only
handles the %s filename place holder, but that's
probably fine for web browsers. Adding support for all
the others would make its appearance in the mailcap
file a lot uglier.


cheers,
raf

Re: is it possible to have two options for viewing html mail?

[Greg Marks]

> I have the following set up in my .mailcap:
>
>text/html; w3m -I %{charset} -T text/html; copiousoutput
>
> so it converts things using w3m more or less okay, however, I
> am wondering is it possible to have an option for viewing using
> midori/firefox for the cases where w3m is not enough?

In your .muttrc file, you could insert:

   bind attach  view-mailcap
   bind attach  view-mailcap
   macro attach "\ef" "cat > 
$HOME/Mail/mutt_attachment_temporary_file.html ; /usr/bin/firefox 
$HOME/Mail/mutt_attachment_temporary_file.html"

Then, in Mutt, when you open an e-mail, type "v" to go to the attachments
menu, and navigate to the "text/html" entry, hitting "Enter" will display
the message using w3m, whereas hitting "f" will open a copy of
the message in Firefox.  Another good option in the .mailcap file,
in place of the w3m command quoted above, is:

   text/html; /usr/bin/lynx -force-html -localhost -stdin

In my opinion, requiring a two-keystroke combination such as "f"
to open the message in Firefox is a helpful security practice, as
that makes it more difficult to accidentally click on a hyperlink in
a malicious e-mail.

For more options, you could add a similar macro "\em" to open in Midori.

> Lots of people send me mail in HTML format (even though I do not
> like it).

Hopefully, when you quote their messages in your replies to them, it
will include all the raw HTML markup so that they can enjoy it as much
as you did.

Best regards,
Greg Marks


signature.asc
Description: PGP signature

Re: is it possible to have two options for viewing html mail?

[raf]

On Sun, Oct 25, 2020 at 11:38:01PM +, Globe Trotter via Mutt-users 
 wrote:

> On Sunday, October 25, 2020, 5:53:20 PM CDT, raf  wrote: 
> 
> On Sun, Oct 25, 2020 at 12:18:26AM +, Globe Trotter via Mutt-users 
>  wrote:
> 
> > On Saturday, 24 October at 22:54, Mutt Users wrote:
> > 
> > >> Lots of people send me mail in HTML format (even though I do not
> > >> like it). I have the following set up in my .mailcap:
> > >> text/html; w3m -I %{charset} -T text/html; copiousoutput
> > >> so it converts things using w3m more or less okay, however, I
> > >> am wondering is it possible to have an option for viewing using
> > >> midori/firefox for the cases where w3m is not enough?
> > 
> > > I've got this in my mailcap:
> > 
> > > text/html; w3m -I %{charset} -T text/html -dump; copiousoutput; print = 
> > > qutebrowser %s; nametemplate=%s.html
> > 
> > > To open an email in w3m press Enter, in qutebrowser p or whatever
> > > print is bound to. You can adapt this for firefox.
> > 
> > > Hope that helps.
> > > Regards Wim
> > 
> > This solution does exactly what I want. I wanted to use midori, so I
> > replaced qutebrowser with midori and it works.
> > 
> > Is it possible to have multiple options? So, in case midori did not
> > cut it, I would use firefox instead?
> > 
> > TIA!
> 
> Rather than invoking actual browsers directly, you
> could write a script that presented you with a list of
> options, and you enter your choice. That way, you could
> have more that two options. If always having to select
> a browser manually is too inefficient, you could
> continue to invoke w3m when viewing html, and invoke
> this menu-based browser chooser when "printing" html.
> 
> cheers,
> raf
> 
> Thanks, where would this option be presented? While I press "p"?

I think that would be best, so that you can decide
whether or not you want to manually select a browser.
By only invoking this script for "printing" the
attachment, you can still access the easier default
behaviour when viewing the attachment. But it probably
means you can't print the attachment, unless you add
that as one of the choices.

> Is the script in mutt or a bash/python/perl/etc script?

It would be a separate script referred to in your .mailcap
file. Here's a sample implementation:

In your ~/.mailcap (or whatever your mailcap_path is set to):

  text/html; w3m -I %{charset} -T text/html -dump; copiousoutput; print = 
select-browser %s; nametemplate=%s.html

Attached is the command select-browser which would need
to be in your $PATH. Note that it doesn't support all
of the % expansions that mailcap(5) supports. It only
handles the %s filename place holder, but that's
probably fine for web browsers. Adding support for all
the others would make its appearance in the mailcap
file a lot uglier.

cheers,
raf

#!/usr/bin/env perl
use warnings;
use strict;

# select-browser - Let user select a browser manually (via ~/.mailcap entry)

# The order in which browsers are presented to the user
my @order = qw(w3m qutebrowser firefox);

# Browser labels and commands
# Warning: Commands must contain the %s filename place holder.
# Warning: No other mailcap(5) expansions are supported.
# Warning: Doesn't handle filenames containing double quotes.
my %browsers = (
w3m => 'w3m -T text/html -dump "%s"',
qutebrowser => 'qutebrowser "%s"',
firefox => 'firefox "%s"'
);

# Check command line
die "usage: $0 filename.html\n" unless @ARGV;
my $filename = $ARGV[0];

# Prompt the user
$| = 1;
print("Browsers:\n");
printf("  %s: %s\n", $_ + 1, $order[$_]) for (0..$#order);
print("Enter selection: ");
chomp(my $response = );
die("$0: Invalid selection: $response (Must be between 1 and @{[scalar 
@order]})\n")
unless $response =~ /^\d+$/ && $response >= 1 && $response <= @order;

# Execute the selected browser
exec sprintf $browsers{$order[$response - 1]}, $filename;

# vi:set ts=4 sw=4:

Re: is it possible to have two options for viewing html mail?

[Globe Trotter via Mutt-users]

On Sunday, October 25, 2020, 5:53:20 PM CDT, raf  wrote: 





On Sun, Oct 25, 2020 at 12:18:26AM +, Globe Trotter via Mutt-users 
 wrote:


> On Saturday, 24 October at 22:54, Mutt Users wrote:
> 
> >> Lots of people send me mail in HTML format (even though I do not like it). 
> >> I have the following set up in my .mailcap:
> >> text/html; w3m -I %{charset} -T text/html; copiousoutput
> >> so it converts things using w3m more or less okay, however, I am wondering 
> >> is it possible to have an option for viewing using midori/firefox for the 
> >> cases where w3m is not enough?
> 
> 
> > I've got this in my mailcap:
> 
> 
> > text/html; w3m -I %{charset} -T text/html -dump; copiousoutput; print = 
> > qutebrowser %s; nametemplate=%s.html
> 
> > To open an email in w3m press Enter, in qutebrowser p or whatever print is 
> > bound to. You can adapt this for firefox.
> 
> > Hope that helps.
> > Regards Wim
> 
> --
>       |\      _,,,---,,_
> ZZZzz /,`.-'`'    -.  ;-;;,_
>     |,4-  ) )-,_. ,\ (  `'-'
> 
>     '---''(_/--'  `-'\_)
> 
> 
> This solution does exactly what I want. I wanted to use midori, so I replaced 
> qutebrowser with midori and it works. 
> 
> Is it possible to have multiple options? So, in case midori did not cut it, I 
> would use firefox instead?
> 
> TIA!


Rather than invoking actual browsers directly, you
could write a script that presented you with a list of
options, and you enter your choice. That way, you could
have more that two options. If always having to select
a browser manually is too inefficient, you could
continue to invoke w3m when viewing html, and invoke
this menu-based browser chooser when "printing" html.

cheers,
raf




Thanks, where would this option be presented? While I press "p"? Is the script 
in mutt or a bash/python/perl/etc script?

Re: is it possible to have two options for viewing html mail?

[raf]

On Sun, Oct 25, 2020 at 12:18:26AM +, Globe Trotter via Mutt-users 
 wrote:

> On Saturday, 24 October at 22:54, Mutt Users wrote:
> 
> >> Lots of people send me mail in HTML format (even though I do not like it). 
> >> I have the following set up in my .mailcap:
> >> text/html; w3m -I %{charset} -T text/html; copiousoutput
> >> so it converts things using w3m more or less okay, however, I am wondering 
> >> is it possible to have an option for viewing using midori/firefox for the 
> >> cases where w3m is not enough?
> 
> 
> > I've got this in my mailcap:
> 
> 
> > text/html; w3m -I %{charset} -T text/html -dump; copiousoutput; print = 
> > qutebrowser %s; nametemplate=%s.html
> 
> > To open an email in w3m press Enter, in qutebrowser p or whatever print is 
> > bound to. You can adapt this for firefox.
> 
> > Hope that helps.
> > Regards Wim
> 
> --
>       |\      _,,,---,,_
> ZZZzz /,`.-'`'    -.  ;-;;,_
>     |,4-  ) )-,_. ,\ (  `'-'
> 
>     '---''(_/--'  `-'\_)
> 
> 
> This solution does exactly what I want. I wanted to use midori, so I replaced 
> qutebrowser with midori and it works. 
> 
> Is it possible to have multiple options? So, in case midori did not cut it, I 
> would use firefox instead?
> 
> TIA!

Rather than invoking actual browsers directly, you
could write a script that presented you with a list of
options, and you enter your choice. That way, you could
have more that two options. If always having to select
a browser manually is too inefficient, you could
continue to invoke w3m when viewing html, and invoke
this menu-based browser chooser when "printing" html.

cheers,
raf

Re: is it possible to have two options for viewing html mail?

[Kevin J. McCarthy]

On Sun, Oct 25, 2020 at 11:39:13AM +0900, Kenichi Asai wrote:

For docx file, I think I have exactly the same thing:

application/vnd.openxmlformats-officedocument.wordprocessingml.document;open -a 
preview -n -W %s; nametemplate=%s.docx
application/vnd.openxmlformats-officedocument.wordprocessingml.document;textutil
 -stdout -cat txt %s; copiousoutput

but the file is always opened using preview, no matter I press Enter
or m.  Why?  How can I configure so that when I press Enter, textutil
is used but when I enter m, preview is used?


The attachment viewing code is a bit convoluted.  I don't believe there 
is currently a way to do what you want.


text/* is treated specially.  Mutt considers it pager-renderable and 
won't directly use the mailcap file unless invoked via . 
Otherwise it renders the content as if it were auto_view'ed inside the 
message.  (The rendering code in turn uses the copiousoutput flag 
mailcap entries.)


The application/* always uses mailcap whether invoked via  
or .  This will find the first entry and invoke it 
interactively.  The only way to view it in the pager is using auto_view.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: is it possible to have two options for viewing html mail?

[Kenichi Asai]

> text/html;  mutt_bgrun /usr/bin/firefox %s >/dev/null 2>&1; needsterminal
> text/html; elinks -dump ; copiousoutput

This is almost what I am doing.  However, it works for text/html but
not for docx file, apparently.  For text/html, I have:

text/html; open -a safari -n -W %s; nametemplate=%s.html
text/html; w3m -dump -T %t %s; copiousoutput

in .mailcap and it goes beautifully: when I press Enter in the list of
attachments, w3m is used, and when I press m, safari is used.  (As a
related question, why do I obtain this behavior by the above two
lines?  What happens when I press Enter and what happens when I press
m?  I don't quite understand the fine details of mailcap.)

For docx file, I think I have exactly the same thing:

application/vnd.openxmlformats-officedocument.wordprocessingml.document;open -a 
preview -n -W %s; nametemplate=%s.docx
application/vnd.openxmlformats-officedocument.wordprocessingml.document;textutil
 -stdout -cat txt %s; copiousoutput

but the file is always opened using preview, no matter I press Enter
or m.  Why?  How can I configure so that when I press Enter, textutil
is used but when I enter m, preview is used?

# I am using Mutt 1.13.3 (2020-01-12) from homebrew on MacOS 10.12.6.

Sincerely,

-- 
Kenichi Asai

Re: is it possible to have two options for viewing html mail?

[Globe Trotter via Mutt-users]

On Saturday, 24 October at 22:54, Mutt Users wrote:

>> Lots of people send me mail in HTML format (even though I do not like it). I 
>> have the following set up in my .mailcap:
>> text/html; w3m -I %{charset} -T text/html; copiousoutput
>> so it converts things using w3m more or less okay, however, I am wondering 
>> is it possible to have an option for viewing using midori/firefox for the 
>> cases where w3m is not enough?


> I've got this in my mailcap:


> text/html; w3m -I %{charset} -T text/html -dump; copiousoutput; print = 
> qutebrowser %s; nametemplate=%s.html

> To open an email in w3m press Enter, in qutebrowser p or whatever print is 
> bound to. You can adapt this for firefox.

> Hope that helps.
> Regards Wim

--
      |\      _,,,---,,_
ZZZzz /,`.-'`'    -.  ;-;;,_
    |,4-  ) )-,_. ,\ (  `'-'

    '---''(_/--'  `-'\_)


This solution does exactly what I want. I wanted to use midori, so I replaced 
qutebrowser with midori and it works. 

Is it possible to have multiple options? So, in case midori did not cut it, I 
would use firefox instead?

TIA!

Re: is it possible to have two options for viewing html mail?

[Wim]

Hi,

On Saturday, 24 October at 22:54, Mutt Users wrote:

> Lots of people send me mail in HTML format (even though I do not like it). I 
> have the following set up in my .mailcap:
>
> text/html; w3m -I %{charset} -T text/html; copiousoutput
>
> so it converts things using w3m more or less okay, however, I am wondering is 
> it possible to have an option for viewing using midori/firefox for the cases 
> where w3m is not enough?
>
> My thanks in advance!
>

I've got this in my mailcap:


text/html; w3m -I %{charset} -T text/html -dump; copiousoutput; print = 
qutebrowser %s; nametemplate=%s.html

To open an email in w3m press Enter, in qutebrowser p or whatever print
is bound to. You can adapt this for firefox.

Hope that helps.
Regards Wim

--
  |\  _,,,---,,_
ZZZzz /,`.-'`'-.  ;-;;,_
 |,4-  ) )-,_. ,\ (  `'-'
'---''(_/--'  `-'\_)

Re: is it possible to have two options for viewing html mail?

[Cameron Simpson]

On 24Oct2020 20:54, Globe Trotter via Mutt-users  wrote:
>Lots of people send me mail in HTML format (even though I do not like it). I 
>have the following set up in my .mailcap:
>
>text/html; w3m -I %{charset} -T text/html; copiousoutput
>
>so it converts things using w3m more or less okay, however, I am wondering is 
>it possible to have an option for viewing using midori/firefox for the cases 
>where w3m is not enough?

Certainly. You have a few choices (not mutually exclusive).

First up, you could bind a keystroke to feed the current message 
to firefox (or whatever browser).

This page on viewing attachments includes a mailcap entry for using 
mozilla if the $DISPLAY environment variable is set:

https://gitlab.com/muttmua/mutt/-/wikis/MuttFaq/Attachment

You could easily adapt that test to something more manual/on-demand. It 
is written for attachments, so the "%s" in it assumes a filename 
(the attachment).  So does the mailcap entry for displaying messages.

My mailcap entry reads like this:

text/html; exec 2>&1 && env DISPLAY= unhtml %s; copiousoutput

The primary thing in that line is the display command itself: "unhtml". 
That is a personal script which converts the HTML to text. Write your 
own, however trivial - start (of course) with the line from your 
mailcap.

Importantly, my "unhtml" consults some flags to decide how to do the 
render - you could have yours decide to feed the file to firefox instead 
of (or as well as) w3m. Here's my code:

https://hg.sr.ht/~cameron-simpson/css/browse/bin/unhtml?rev=tip

It consults some flags to decide what to run - you can see it will use 
w3m or lynx depending on my mood. You could use a similar approach to 
display via firefox depedning on your mood.

As an example, I have:

set display_filter="mutt-display_filter"

and I use that for rot13 decoding on demand (the on demand being akin to 
your "firefox on demand" wish). So the script is here:


https://hg.sr.ht/~cameron-simpson/css/browse/bin-cs/mutt-display_filter?rev=tip

and if the MUTT_ROT13 flag is set, it passes the text through tr do 
decode it. Associated with are the following mutt lines:

set my_toggle_rot13="$my_push_wait_key=noflag !  
MUTT_ROT13 -e flag MUTT_ROT13$my_pop_wait_key"
macro index \Cx "$my_toggle_rot13" 'toggle MUTT_ROT13'
macro pager \Cx "$my_toggle_rot13" 'toggle 
MUTT_ROT13'

So the ^X keystroke toggles the rot13 mode, which issues a shell command 
to toggle my MUTT_ROT13 flag. If I'm displaying a message (the "pager" 
macro) it exits the pager, toggles the flag, ad reenters the pager.

That might be a starting point.

Cheers,
Cameron Simpson 

Re: is it possible to have two options for viewing html mail?

[Patrick Shanahan]

* mutt users list  [10-24-20 16:54]:
> Lots of people send me mail in HTML format (even though I do not like
> it).  I have the following set up in my .mailcap:
> 
> text/html; w3m -I %{charset} -T text/html; copiousoutput
> 
> so it converts things using w3m more or less okay, however, I am
> wondering is it possible to have an option for viewing using
> midori/firefox for the cases where w3m is not enough?

using mutt, copy the html portion to an xternal file and open that ile
with 

I copy to: mutt.html

macro  attach  ,x  "|rm -f /mnt/ExT4/mutt.html"":unset \
wait_key\n;/mnt/ExT4/mutt.html""|chmod a+r \
/mnt/ExT4/mutt.html"

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode

Re: is it possible to have two options for viewing html mail?

[José María Mateos]

On Sat, Oct 24, 2020 at 08:54:18PM +, Globe Trotter via Mutt-users wrote:

Lots of people send me mail in HTML format (even though I do not like it). I 
have the following set up in my .mailcap:

text/html; w3m -I %{charset} -T text/html; copiousoutput

so it converts things using w3m more or less okay, however, I am wondering is 
it possible to have an option for viewing using midori/firefox for the cases 
where w3m is not enough?


Yes. In .muttrc:

bind attach  view-mailcap # if you want to see html content using 
Return.

Then in your .mailcap:

text/html;  mutt_bgrun /usr/bin/firefox %s >/dev/null 2>&1; needsterminal
text/html; elinks -dump ; copiousoutput

The second link is the equivalent to your w3m (I use elinks). The second 
one is a script I found some time ago. You can get a copy here, for 
example https://github.com/RichiH/mutt_bgrun. It saves the html file in 
a temp folder, runs firefox and deletes the file.


Then, to use this, just go to the list of attachments in the message, 
select the HTML file, press Enter and you should have the message in a 
new firefox tab.


Cheers,

--
José María (Chema) Mateos || https://rinzewind.org

is it possible to have two options for viewing html mail?

[Globe Trotter via Mutt-users]

Lots of people send me mail in HTML format (even though I do not like it). I 
have the following set up in my .mailcap:

text/html; w3m -I %{charset} -T text/html; copiousoutput

so it converts things using w3m more or less okay, however, I am wondering is 
it possible to have an option for viewing using midori/firefox for the cases 
where w3m is not enough?

My thanks in advance!

Re: Alternate html and text plain avoinding message like "your mailreader dont support html-mail"

[Cameron Simpson]

On 08Sep2019 11:18, Marcelo Laia  wrote:
However, some messages have html and a single and sort alternate text 
plain said "your mailreader don't support html message". in this case, I need to hint

"v" and select alternate html and hint enter to read the message.


Yes, I get this rubbish all the time.

There are some alternative to tell mutt to read first text plain only 
if it is

the full message? Ignoring text plain messages if it is short like "your
mailreader don't support html message"?


Not really. How is mutt to determine this? (If you figure out a way to 
test this I'd be interested to hear it; then we could use that test).


I address this problem by keeping a list of the offending message 
authors and sources:


 
 # alternative-order criteria
 message-hook . 'unalternative_order *; alternative_order text/plain text/html'
 # Apple Mail embeds attachments in the HTML part instead of outside the 
multipart/mixed
 message-hook '~h "X-Mailer: Apple Mail" ~X 1-' 'unalternative_order *; 
alternative_order text/html multipart/mixed text/plain'
 # senders who can't seem to master multipart/mixed, and send empty
 # or useless text/plain sections
 # or just badly badly formatted plain text, such as live.com etc
 message-hook '%f htmlers | ~f @no-re...@cc.yahoo-inc.com | ~f @outlook.com | 
~f live.com | ~f @facebookmail.com' 'unalternative_order *; alternative_order 
text/html text/plain'

These rules rule for each message coutesy of "message-hook". In order:

 Scrub thhe alternative_order and set it to prefer text/plain.

 For Apple mail with attachments, prefer the HTML because it seems to 
 put some attachments in only the html half of the multipart/mixed.


 For authors in the "htmlers" group and authors from a list of known 
 incompetent domains (courtesy of their rubbish web mail systems), 
 prefer the html because the plain is useless.


And I just add people to the "htmlers" group as they are discovered.

Cheers,
Cameron Simpson 

Re: Alternate html and text plain avoinding message like "your mailreader dont support html-mail"

[Will Yardley]

On Sun, Sep 08, 2019 at 11:18:08AM -0300, Marcelo Laia wrote:
 
> There are some alternative to tell mutt to read first text plain only
> if it is the full message? Ignoring text plain messages if it is short
> like "your mailreader don't support html message"?

I have seen this happen occasionally (even sometimes with a completely
empty text/plain part). But I don't think it's a reasonable idea to
expect mutt to be able to solve this kind of problem. Something like "if
the size delta between the two parts of the multipart/mixed message is >
N" would be pretty hard logic, and this would probably be the wrong
place to write such logic. You could probably write some kind of custom
helper program if you really needed to, but my guess is that simply
viewing the text/html part manually (as you mentioned) is going to be
the easier thing to do in these rare cases.

You could write the sender and suggest that they implement the
multipart/alternative messages correctly, or else just send text/html
only.

w

Re: Alternate html and text plain avoinding message like "your mailreader dont support html-mail"

[José María Mateos]

On Sun, Sep 08, 2019 at 11:18:08AM -0300, Marcelo Laia wrote:
However, some messages have html and a single and sort alternate text 
plain said "your mailreader don't support html message". in this case, 
I need to hint "v" and select alternate html and hint enter to read the 
message. 


I have seen messages like the one you mention. They are typically 
newsletters and such (anything composed with an e-mail client is 
unlikely to yield that, in my experience, or at least I can't recall if 
I have ever seen one of those).


What I do is to filter all newsletters to their proper folder, and then 
I have this in my muttrc:


auto_view text/html
folder-hook . 'unalternative_order *; alternative_order text/plain text/html'
folder-hook newsletters 'unalternative_order *; alternative_order text/html 
text/plain'

So my folder "newsletters" will see HTML before text, but for the rest 
of the folders, text comes first.


I don't know if this solution is OK for your current workflow / setup, 
but at least it's working quite well for me.


Cheers,

--
José María (Chema) Mateos || https://rinzewind.org/

Re: Alternate html and text plain avoinding message like "your mailreader dont support html-mail"

[Marcelo Laia]

On 08/09/19 at 10:47, Patrick Shanahan wrote:
> * Marcelo Laia  [09-08-19 10:22]:
> 
> I have following for quite some years and do not recall ever seeing "don't
> support html":
> 
> mailcap:
>   text/html; w3m -dump -v -F -T text/html %s; nametemplate=%s.html; 
> needsterminal
>   text/html; w3m -dump %s; nametemplate=%s.html; copiousoutput
> .muttrc:  
>   alternative_order text/plain text/enriched text/html text 
> application/postscript image/*
>   auto_view text/richtext text/html text/x-sgml text/x-vcard text/x-sh \


I try yours and I see: "your mailread don't support html e-mails".

If I change

alternative_order text/plain text/enriched text/html (...)

to

alternative_order text/html text/plain text/enriched (...)

I see the html mails. But, all html text is read first, instead the text plain
message.



-- 
Marcelo

Re: Alternate html and text plain avoinding message like "your mailreader dont support html-mail"

[Patrick Shanahan]

* Marcelo Laia  [09-08-19 10:22]:
> Hi,
> 
> I would like to read multpart (html and alternative text together) text/plain
> first.
> 
> So, I set muttrc as follow:
> 
> .mutt/muttrc
> auto_view text/html
> alternative_order text/plain text/html
> 
> and mailcap as:
> .mutt/mailcap
> text/html; lynx -force_html -assume_charset=gbk -assume_local_charset=gbk /
>  -assume_unrec_charset=gbk -display_charset=utf8 -dump -force_html '%s'; /
>  description="HTML Text"; nametemplate=%s.html; copiousoutput
> 
> This is ok and mutt read text plain first when message have only text plain or
> both, html end text plain.
> 
> However, some messages have html and a single and sort alternate text plain
> said "your mailreader don't support html message". in this case, I need to 
> hint
> "v" and select alternate html and hint enter to read the message.
> 
> If I change muttrc to:
> 
> .mutt/muttrc
> auto_view text/html
> alternative_order text/html text/plain
> 
> mutt will display html text for all multpart mail, ignoring text plain.
> 
> There are some alternative to tell mutt to read first text plain only if it is
> the full message? Ignoring text plain messages if it is short like "your
> mailreader don't support html message"?

I have following for quite some years and do not recall ever seeing "don't
support html":

mailcap:
  text/html; w3m -dump -v -F -T text/html %s; nametemplate=%s.html; 
needsterminal
  text/html; w3m -dump %s; nametemplate=%s.html; copiousoutput
.muttrc:  
  alternative_order text/plain text/enriched text/html text 
application/postscript image/*
  auto_view text/richtext text/html text/x-sgml text/x-vcard text/x-sh \
text/x-csrc application/x-tex \
application/x-dvi applicatoin/x-gzip-dvi application/x-gzip \
application/x-gunzip application/x-cpio application/x-gtar \
application/x-tar application/x-tar-gz application/x-rar-compressed \
application/x-zip-compressed application/zip application/x-csh \
application/x-sh application/x-script application/x-shellscript \
application/x-latex application/x-tex application/x-shar \
application/x-troff application/x-troff-man application/x-troff-me \
application/x-pgp-message application/msword \
application/ms-tnef application/ms-word application/rtf \
application/octet-stream application/x-tcl application/x-perl \
application/x-debian-package message/partial \
application/pdf application/jpeg



-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  @ptilopteri
http://en.opensuse.orgopenSUSE Community Memberfacebook/ptilopteri
Photos: http://wahoo.no-ip.org/piwigo   paka @ IRCnet freenode

Alternate html and text plain avoinding message like "your mailreader dont support html-mail"

[Marcelo Laia]

Hi,

I would like to read multpart (html and alternative text together) text/plain
first.

So, I set muttrc as follow:

.mutt/muttrc
auto_view text/html
alternative_order text/plain text/html

and mailcap as:
.mutt/mailcap
text/html; lynx -force_html -assume_charset=gbk -assume_local_charset=gbk /
 -assume_unrec_charset=gbk -display_charset=utf8 -dump -force_html '%s'; /
 description="HTML Text"; nametemplate=%s.html; copiousoutput

This is ok and mutt read text plain first when message have only text plain or
both, html end text plain.

However, some messages have html and a single and sort alternate text plain
said "your mailreader don't support html message". in this case, I need to hint
"v" and select alternate html and hint enter to read the message.

If I change muttrc to:

.mutt/muttrc
auto_view text/html
alternative_order text/html text/plain

mutt will display html text for all multpart mail, ignoring text plain.

There are some alternative to tell mutt to read first text plain only if it is
the full message? Ignoring text plain messages if it is short like "your
mailreader don't support html message"?

Thank you very much.



-- 
Marcelo

Re: HTML mail which isn't handled correctly by 'auto_view text/html

[Chris Green]

On Thu, Feb 07, 2019 at 07:50:36PM -0600, Derek Martin wrote:
> Chris,
> 
> Based on the excerpt you posted:
> 
> On Tue, Feb 05, 2019 at 10:10:51PM +, Chris Green wrote:
> > ...
> > ...
> > ...
> > Subject: Your order 3179771 is due for delivery by DHL Parcel UK
> > Content-Type: multipart/alternative;
> > 
> > boundary="--boundary_145134_db6b4c85-2751-452f-bf4b-c56010b07587"
> > Message-ID:
> > 
> > Status: RO
> > Content-Length: 20807
> > Lines: 285
> > 
> > Content-Type: text/plain; charset="us-ascii"
> > Content-Transfer-Encoding: quoted-printable
> > 
> > 
> > 
> > 
> > 
> > ...
> > ...
> > ...
> > 
> 
> ...it appears this is a multi-part message, theoretically intended to
> have both an HTML part and a plain text part, where the first part is
> HTML that is idiotically marked as plain text, because their IT folks
> are too lazy/stupid to produce a proper multipart/alternative message.
> I would encourage you to complain to DHL, but I would also expect that
> to be futile, so I won't bother. ;-)
> 
> But the next thing I would recommend is look again at the message
> parts (press v on the message in the index).  There may be an actual
> HTML part that you're not seeing, because your settings prefer the
> plain text (as mine do).  In that case, Mutt is displaying the faux
> plain text, since you quite reasonably told it to, and doing it
> verbatim and not trying to run any conversion on it, since... DHL told
> Mutt it shouldn't need to.
> 
> Probably you can select the HTML and manually display it.  Either that
> or DHL is just really that bad at e-mail. :-(
> 
I'm pretty sure that there was only one part, I saved the message and
opened it with vi[le] and a quick scan through it showed the HTML
header stuff at the top and closing HTML at the end.

I will check more carefully next time I get one though, thanks.

-- 
Chris Green

Re: HTML mail which isn't handled correctly by 'auto_view text/html

[Derek Martin]

Chris,

Based on the excerpt you posted:

On Tue, Feb 05, 2019 at 10:10:51PM +, Chris Green wrote:
> ...
> ...
> ...
> Subject: Your order 3179771 is due for delivery by DHL Parcel UK
> Content-Type: multipart/alternative;
> boundary="--boundary_145134_db6b4c85-2751-452f-bf4b-c56010b07587"
> Message-ID:
> 
> Status: RO
> Content-Length: 20807
> Lines: 285
> 
> Content-Type: text/plain; charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> 
> 
> 
> 
> ...
> ...
> ...
> 

...it appears this is a multi-part message, theoretically intended to
have both an HTML part and a plain text part, where the first part is
HTML that is idiotically marked as plain text, because their IT folks
are too lazy/stupid to produce a proper multipart/alternative message.
I would encourage you to complain to DHL, but I would also expect that
to be futile, so I won't bother. ;-)

But the next thing I would recommend is look again at the message
parts (press v on the message in the index).  There may be an actual
HTML part that you're not seeing, because your settings prefer the
plain text (as mine do).  In that case, Mutt is displaying the faux
plain text, since you quite reasonably told it to, and doing it
verbatim and not trying to run any conversion on it, since... DHL told
Mutt it shouldn't need to.

Probably you can select the HTML and manually display it.  Either that
or DHL is just really that bad at e-mail. :-(

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



pgpwnGuasQq3Z.pgp
Description: PGP signature

Re: HTML mail which isn't handled correctly by 'auto_view text/html

[Chris Green]

On Thu, Feb 07, 2019 at 09:44:25AM +1100, Cameron Simpson wrote:
> On 06Feb2019 13:01, Chris Green  wrote:
> > On Wed, Feb 06, 2019 at 01:00:48PM +1100, Cameron Simpson wrote:
> > > Scenario B:
> > > If DHL really are sending HTML in a standalone text/plain body then
> > > you've got 2 choices.
> > > 
> > > The first is to act when you receive the email; if you're using procmail 
> > > or
> > > something similar to file you email you could match these messages and
> > > modify the Content-Type: header to say "text/html".
> > > 
> > > The alternative is to match the message with mutt, and to set 
> > > display_filter
> > > specially for this message. You could use your normal display_filter and 
> > > use
> > > a message-hook to override it with the command from the mailcap ("lynx
> > > -dump").
> > > 
> > OK, thanks, it's quite rare and, at the moment, only DHL notifications
> > doing this that I actually want to see the content.
> 
> Just further to the display_filter thing: I normally use a display_filter,
> set to a personal script which goes:
> 
>#!/bin/sh
>#
># Mutt display filter, whose behaviour adjusts accoridng to some flags.
>#   - Cameron Simpson  29jan2017
>#
> 
>if flag MUTT_ROT13
>then  tr '[A-Z][a-z]' '[N-Z][A-M][n-z][a-m]'
>else  cat
>fi \
>| if flag MUTT_UNTOPPOST
>  then  untoppost
>  else  cat
>  fi \
>| mutt-highlight
> 
> The mutt-highlight is a sed script which turns *foo* into bold and _foo_
> into underlined. But the important thing here is the if statement: it
> optionally runs the message body through some filters. For example, I've got
> a mutt macro ^X to toggle the MUTT_ROT13 flag and redisplay the message.
> 
> You could adopt such a scheme for your HTML issue (in fact, I'm going to do
> that myself too): have an optional flag to decode the HTML using a pipeline
> flavour of your mailcap unhtml line. Then bind a mutt keystroke to toggle
> the flag and redisplay. My rot13 bindings go:
> 
> set my_toggle_rot13="$my_push_wait_key=noflag ! 
> MUTT_ROT13 
> -e flag MUTT_ROT13$my_pop_wait_key" 
>macro index \Cx "$my_toggle_rot13" 'toggle MUTT_ROT13'
>macro pager \Cx "$my_toggle_rot13" 'toggle 
> MUTT_ROT13'
> 
> Just a thought. Source for any of the above is available.
> 
That's just the sort of thing I was hoping for - "oh, look, there's
some raw HTML...", a couple of keystrokes and it's converted.

I may well come back in a few days and ask to see the source for
untoppost, the rest I can probably fathom out for myself.

Thanks.

-- 
Chris Green

Re: HTML mail which isn't handled correctly by 'auto_view text/html

[Cameron Simpson]

On 06Feb2019 13:01, Chris Green  wrote:

On Wed, Feb 06, 2019 at 01:00:48PM +1100, Cameron Simpson wrote:

Scenario B:
If DHL really are sending HTML in a standalone text/plain body then 
you've got 2 choices.


The first is to act when you receive the email; if you're using procmail or
something similar to file you email you could match these messages and
modify the Content-Type: header to say "text/html".

The alternative is to match the message with mutt, and to set display_filter
specially for this message. You could use your normal display_filter and use
a message-hook to override it with the command from the mailcap ("lynx
-dump").


OK, thanks, it's quite rare and, at the moment, only DHL notifications
doing this that I actually want to see the content.


Just further to the display_filter thing: I normally use a 
display_filter, set to a personal script which goes:


   #!/bin/sh
   #
   # Mutt display filter, whose behaviour adjusts accoridng to some flags.
   #   - Cameron Simpson  29jan2017
   #

   if flag MUTT_ROT13
   then  tr '[A-Z][a-z]' '[N-Z][A-M][n-z][a-m]'
   else  cat
   fi \
   | if flag MUTT_UNTOPPOST
 then  untoppost
 else  cat
 fi \
   | mutt-highlight

The mutt-highlight is a sed script which turns *foo* into bold and _foo_ 
into underlined. But the important thing here is the if statement: it 
optionally runs the message body through some filters. For example, I've 
got a mutt macro ^X to toggle the MUTT_ROT13 flag and redisplay the 
message.


You could adopt such a scheme for your HTML issue (in fact, I'm going to 
do that myself too): have an optional flag to decode the HTML using a 
pipeline flavour of your mailcap unhtml line. Then bind a mutt keystroke 
to toggle the flag and redisplay. My rot13 bindings go:


   set my_toggle_rot13="$my_push_wait_key=noflag !  MUTT_ROT13 -e 
flag MUTT_ROT13$my_pop_wait_key"
   macro index \Cx "$my_toggle_rot13" 'toggle MUTT_ROT13'
   macro pager \Cx "$my_toggle_rot13" 'toggle MUTT_ROT13'

Just a thought. Source for any of the above is available.

Cheers,
Cameron Simpson 

Re: HTML mail which isn't handled correctly by 'auto_view text/html

[Chris Green]

On Wed, Feb 06, 2019 at 01:00:48PM +1100, Cameron Simpson wrote:
> On 05Feb2019 22:10, Chris Green  wrote:
> > I am getting notification E-Mails from DPD which aren't handled
> > correctly by 'auto_view text/html' in my muttrc and 'text/html; lynx
> > -dump %s; copiousoutput; nametemplate=%s.html' in .mailcap.
> > 
> > Presumably it's simply that there is no 'text/html' string in the
> > headers, I just get to see the raw HTML.  In fact there is the
> > following:-
> > 
> >...
> >...
> >...
> >Subject: Your order 3179771 is due for delivery by DHL Parcel UK
> >Content-Type: multipart/alternative;
> >boundary="--boundary_145134_db6b4c85-2751-452f-bf4b-c56010b07587"
> >Message-ID:
> >
> >Status: RO
> >Content-Length: 20807
> >Lines: 285
> > 
> >Content-Type: text/plain; charset="us-ascii"
> >Content-Transfer-Encoding: quoted-printable
> > 
> >
> >
> >
> >
> >...
> >...
> >...
> > 
> > So that would explain it!  Is there any way to manually ask mutt to
> > treat this as text/html?
> 
> Kinda.
> 
> Firstly, is that really the entirely of the relevant headers? No text/html
> or multipart/mixed? DHL are really sending HTML notifications (ugh!)
> identified as text/plain? That is a new low.
> 
Yes!  It's the only message I've ever received (well, I've received a
couple of these from DHL recently) which has done this to me.
Everyone else's HTML (spit) E-Mail gets fed into Lynx correctly.


> (My previous low is the many senders who send multipart/mixed with either
> the HTML duplicated in the text/plain half or outright absent - empty
> text/plain half.)
> 
> So: are DHL sending _only_ an text/plain section or both text/plain and
> text/html? In my experience it is usually the latter.
> 
There's only the HTML, identified as plain!


> Scenario A: Both text/html and text/plain, but the text/plain contains HTML.
> I get this a lot. I have this in my muttrc:
> 
Not this I think.

> 
> Scenario B:
> 
> If DHL really are sending HTML in a standalone text/plain body then you've
> got 2 choices.
> 
> The first is to act when you receive the email; if you're using procmail or
> something similar to file you email you could match these messages and
> modify the Content-Type: header to say "text/html".
> 
> The alternative is to match the message with mutt, and to set display_filter
> specially for this message. You could use your normal display_filter and use
> a message-hook to override it with the command from the mailcap ("lynx
> -dump").
> 
OK, thanks, it's quite rare and, at the moment, only DHL notifications
doing this that I actually want to see the content.

-- 
Chris Green

Re: HTML mail which isn't handled correctly by 'auto_view text/html

[Cameron Simpson]

On 05Feb2019 22:10, Chris Green  wrote:

I am getting notification E-Mails from DPD which aren't handled
correctly by 'auto_view text/html' in my muttrc and 'text/html; lynx
-dump %s; copiousoutput; nametemplate=%s.html' in .mailcap.

Presumably it's simply that there is no 'text/html' string in the
headers, I just get to see the raw HTML.  In fact there is the
following:-

   ...
   ...
   ...
   Subject: Your order 3179771 is due for delivery by DHL Parcel UK
   Content-Type: multipart/alternative;
   boundary="--boundary_145134_db6b4c85-2751-452f-bf4b-c56010b07587"
   Message-ID:
   
   Status: RO
   Content-Length: 20807
   Lines: 285

   Content-Type: text/plain; charset="us-ascii"
   Content-Transfer-Encoding: quoted-printable

   
   
   
   
   ...
   ...
   ...

So that would explain it!  Is there any way to manually ask mutt to
treat this as text/html?


Kinda.

Firstly, is that really the entirely of the relevant headers? No 
text/html or multipart/mixed? DHL are really sending HTML notifications 
(ugh!) identified as text/plain? That is a new low.


(My previous low is the many senders who send multipart/mixed with 
either the HTML duplicated in the text/plain half or outright absent - 
empty text/plain half.)


So: are DHL sending _only_ an text/plain section or both text/plain and 
text/html? In my experience it is usually the latter.


Scenario A: Both text/html and text/plain, but the text/plain contains HTML. I get 
this a lot. I have this in my muttrc:


   
   # alternative-order criteria
   message-hook . 'unalternative_order *; alternative_order text/plain 
text/html'
   # Apple Mail embeds attachments in the HTML part instead of outside 
   # the multipart/mixed

   message-hook '~h "X-Mailer: Apple Mail" ~X 1-' 'unalternative_order *; 
alternative_order text/html multipart/mixed text/plain'
   # senders who can't seem to master multipart/mixed, and send empty 
   # or useless text/plain sections

   # or just badly badly formatted plain text, such as live.com etc
   message-hook '%f htmlers | ~f @no-re...@cc.yahoo-inc.com | ~f @outlook.com | 
~f live.com | ~f @facebookmail.com' 'unalternative_order *; alternative_order 
text/html text/plain'

which uses "alternative_order text/plain text/html" normally, but 
reverses that for some special messages: Apple Mail with attachments, 
and email from known bad domains and senders in my %htmlers mutt group, 
a list of specific know bad authors.


Scenario B:

If DHL really are sending HTML in a standalone text/plain body then 
you've got 2 choices.


The first is to act when you receive the email; if you're using procmail 
or something similar to file you email you could match these messages 
and modify the Content-Type: header to say "text/html".


The alternative is to match the message with mutt, and to set 
display_filter specially for this message. You could use your normal 
display_filter and use a message-hook to override it with the command 
from the mailcap ("lynx -dump").


Cheers,
Cameron Simpson 

HTML mail which isn't handled correctly by 'auto_view text/html

[Chris Green]

I am getting notification E-Mails from DPD which aren't handled
correctly by 'auto_view text/html' in my muttrc and 'text/html; lynx
-dump %s; copiousoutput; nametemplate=%s.html' in .mailcap.

Presumably it's simply that there is no 'text/html' string in the
headers, I just get to see the raw HTML.  In fact there is the
following:-

...
...
...
Subject: Your order 3179771 is due for delivery by DHL Parcel UK
Content-Type: multipart/alternative;
boundary="--boundary_145134_db6b4c85-2751-452f-bf4b-c56010b07587"
Message-ID:

Status: RO
Content-Length: 20807
Lines: 285

Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable





...
...
...

So that would explain it!  Is there any way to manually ask mutt to
treat this as text/html?



-- 
Chris Green

Re: Config Files, and Remaining Confusion with html-mail

[Mark H. Wood]

On Fri, Jan 25, 2013 at 04:43:34PM -0500, Alan McConnell wrote:
 On Fri, Jan 25, 2013 at 12:53:20PM -0700, s. keeling wrote:
  Incoming from Mark H. Wood:
   On Fri, Jan 25, 2013 at 09:28:05AM -0500, Alan McConnell wrote:
First, generically: I feel it is a source of difficulty that
mutt relies on two config files, .muttrc and .mailcap.  Perhaps
   
   .mailcap is a general-purpose configuration file for anything that
   wants to know what you would like done with certain types of content.
   Lots of other tools also use .mailcap and /etc/mailcap.
   
   This is why they are separate.  One belongs to Mutt and the other
   belongs to the world (including Mutt, which can use it).
  
  That was a beautiful exposition.
  LOL  It may seem beautiful to some, but it can't
  help anyone with a practical problem.

Well, generically that is what is going on.

 Mr Wood wrote further:
  You probably need to add ; needsterminal to your .mailcap entry for
  text/html so that Mutt will ask you to hit a key when the external
  program (Iceweasel) is finished.
 sigh  My iceweasel(aka Firefox) runs, and displays in the
 middle of my screen, from the moment my computer is turned
 on in the morning till I use it to talk to my DSL modem
 to shut down my connection in the evening, preparatory to
 shutdown -h now.

Yes, there's an additional wrinkle with Firefox/Iceweasel:  if it is
already running when you invoke it again, the second invocation just
tells the first to do something and then exits.  This makes the race
even *more*, uh, interesting.  The point is to make Mutt wait to
remove the file until some time after your browser is actually
displaying it.  Any time after that, Mutt can be allowed to continue.

Come to think of it, it's the second Iceweasel instance which enables
the race.  That instance just sends a message to the first instance
and then exits.  Mutt, which was waiting on the second instance,
thinks you're done with the temp file and cleans up.  The first
Iceweasel instance, which is the one you want to read with, may not
even have been scheduled yet, and if not then it wouldn't yet have the
file open.  When the main Iceweasel instance tries to obey the
message, the file is already gone.

   For more on .mailcap and how Mutt
  interprets it, see:
http://www.mutt.org/doc/manual/manual-5.html
   I've pored over the whole document, including this
   section.  It is likely my stupidity that makes me
   unable to find in it why the .muttrc and the .mailcap
   are fighting with each other

That's because they arent; Mutt and Iceweasel are fighting with each other.

   Re Race Conditions.  Unless I am mistaken, mutt is
   written as a single, un-threaded process; I believe that
   'me' is (justly) proud of this achievement.  So I do
   not understand how two processes can be involved here.

Mutt is one process.  Iceweasel is another.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
There's an app for that:  your browser


pgpixJTmWMzR_.pgp
Description: PGP signature

Re: Config Files, and Remaining Confusion with html-mail

[Andre Klärner]

On Mon, Jan 28, 2013 at 09:38:14AM -0500, Mark H. Wood wrote:
 On Fri, Jan 25, 2013 at 04:43:34PM -0500, Alan McConnell wrote:
 The point is to make Mutt wait to remove the file until some time after
 your browser is actually displaying it.  Any time after that, Mutt can be
 allowed to continue.
 
 Mutt, which was waiting on the second instance, thinks you're done with
 the temp file and cleans up.  The first Iceweasel instance, which is the
 one you want to read with, may not even have been scheduled yet, and if
 not then it wouldn't yet have the file open.  When the main Iceweasel
 instance tries to obey the message, the file is already gone.

Well, did ever anyone think of using the inotify mechanism (in the linux
kernel) which tells you when specific events have occurred (e.g. file has
been read completely).

If I have time soon I'll try to implement it (inotify's events access and
close_nowrite sound promising).

Regards, Andre

-- 
Andre Klärner


smime.p7s
Description: S/MIME cryptographic signature

Re: Config Files, and Remaining Confusion with html-mail

[David Champion]

* On 25 Jan 2013, Kevin J. McCarthy wrote: 
 I see you posted an email about this back on December 19th too.
 Although I thought Patrick Shanahan explained it clearly then, and just
 now Mark H. Wood did again, I'll take a shot and try to (even) more
 verbosely explain what is going on and why it's causing you a problem.
 [...]

This was a very good explanation, worthy of being a standard answer to
this class of problems.  It should be on the wiki.

-- 
David Champion • d...@bikeshed.us

Re: Config Files, and Remaining Confusion with html-mail

[s. keeling]

Incoming from David Champion:
 
 It should be on the wiki.

Thanks for reminding me about the wiki.


-- 
Any technology distinguishable from magic is insufficiently advanced.
(*) :(){ :|: };:
- -

Re: Config Files, and Remaining Confusion with html-mail

[Alan McConnell]

On Fri, Jan 25, 2013 at 04:10:16PM -0800, Kevin J. McCarthy wrote:
 Alan McConnell wrote:
  Re Race Conditions.  Unless I am mistaken, mutt is
  written as a single, un-threaded process; I believe that
  'me' is (justly) proud of this achievement.  So I do
  not understand how two processes can be involved here.
 
 I see you posted an email about this back on December 19th too.
Indeed I did.  And have, in the meantime, spent quite a
bit of time experimenting, and reading the documentation.

 Although I thought Patrick Shanahan explained it clearly then, and just
Mr Shanahan pointed me at a work-around he had devised.

 now Mark H. Wood did again, I'll take a shot and try to (even) more
 verbosely explain what is going on and why it's causing you a problem.
I thank you for your explanation and your charts.

 There is no completely clean way to fix this, because there is no way to
 know how long the main firefox will need %s to be around.  If you only
 intend to quickly view the file and then close the tab, the best way is
 to have mutt sleep after invoking firefox -new-tab.  Try modifying
 your .mailcap invocation to:
 text/html; firefox -new-tab '%s'  sleep 10; test=
 ^^^
 add this


And I'm especially grateful for this tip.  I have changed my
.mailcap to the following:
text/html; iceweasel -new-tab '%s'  sleep 2; test=test -n $DISPLAY;\
nametemplate=%s.html
# text/html; sensible-browser %s  sleep 2; nametemplate=%s.html
# test=test -n $DISPLAY;
and this seems to work.

So I thank all responders for their responses.

Again, best wishes to all,

Alan

-- 
Alan McConnell :  http://globaltap.com/~alan/
Imagination is the one weapon in the war against reality.
Try to get all of your posthumous medals in advance.

Config Files, and Remaining Confusion with html-mail

[Alan McConnell]

Assembled Wisdom!

First, generically: I feel it is a source of difficulty that
mutt relies on two config files, .muttrc and .mailcap.  Perhaps
one of the experts could give us a short exposition of the
use of each of these files, and what to do when they conflict.
That would help me get my second, personal, issue resolved.

Second(personal issue):  I'm still having problems with
getting my html-mail to open(in a new tab) in my browser,
which is Firefox(Debianers call it iceweasel).  Often,
when I use 'v' on an entry in my mutt display, and then
Arrow down to 3 . . . . [text/html . . . ., and then
press Enter, a new Tab does open in my browser, and I see
the html-mail displayed nicely.  Even then I get, in my
browser-Tab: file:///home/alan/tmp/mutt.html, but there
is no such file in my ~/tmp directory!

But, too often, I get a quick new tab, a tenth of a second
look at the html I want to see, and then mutt thinks better
of it and I get a screen:  
   File not found  Iceweasel can't find the file at
   /home/alan/tmp/mutt.html

The decision which way mutt will go between these two
alternatives is, as far as I can see, quite arbitrary.

  For the record:  I have the following entry in my .muttrc
set tmpdir=~/tmp# where to store temp files
  This works fine when I'm writing my mail.  For instance
  there is now a file in ~/tmp containing this text that
  I'm now working on.


  I also have an entry
# set mailcap_path=/etc/mailcap:/usr/local/share/mailcap
  I uncommented this, but quickly put the comment back on!
  I have a huge /etc/mailcap, which I can't make head or
  tails of.

Bottom line: there is some kind of a fight inside mutt
about opening a tab in my browser;  how can I reconcile
this conflict.  What I'd like of course is:  when I
hit 'v' I'd like that E-mail to be opened in a tab
in my iceweasel/Firefox as best as possible.

TIA for anticipated help!

Alan

-- 
Alan McConnell :  http://globaltap.com/~alan/
No one minds what Jeffreys says . . it is not more than a week ago
that I heard him speak disrespectfully of the Equator.(Sydney Smith)

Re: Config Files, and Remaining Confusion with html-mail

[Mark H. Wood]

On Fri, Jan 25, 2013 at 09:28:05AM -0500, Alan McConnell wrote:
 First, generically: I feel it is a source of difficulty that
 mutt relies on two config files, .muttrc and .mailcap.  Perhaps
 one of the experts could give us a short exposition of the
 use of each of these files, and what to do when they conflict.
 That would help me get my second, personal, issue resolved.

.muttrc is Mutt's configuration.  It is specific to Mutt.

.mailcap is a general-purpose configuration file for anything that
wants to know what you would like done with certain types of content.
Lots of other tools also use .mailcap and /etc/mailcap.

This is why they are separate.  One belongs to Mutt and the other
belongs to the world (including Mutt, which can use it).

 Second(personal issue):  I'm still having problems with
 getting my html-mail to open(in a new tab) in my browser,
 which is Firefox(Debianers call it iceweasel).  Often,
 when I use 'v' on an entry in my mutt display, and then
 Arrow down to 3 . . . . [text/html . . . ., and then
 press Enter, a new Tab does open in my browser, and I see
 the html-mail displayed nicely.  Even then I get, in my
 browser-Tab: file:///home/alan/tmp/mutt.html, but there
 is no such file in my ~/tmp directory!
 
 But, too often, I get a quick new tab, a tenth of a second
 look at the html I want to see, and then mutt thinks better
 of it and I get a screen:  
File not found  Iceweasel can't find the file at
/home/alan/tmp/mutt.html
 
 The decision which way mutt will go between these two
 alternatives is, as far as I can see, quite arbitrary.

You probably need to add ; needsterminal to your .mailcap entry for
text/html so that Mutt will ask you to hit a key when the external
program (Iceweasel) is finished.  For more on .mailcap and how Mutt
interprets it, see:

  http://www.mutt.org/doc/manual/manual-5.html

especially the section Optional Fields.

Background:

This sounds like what is usually called a race condition.  Two
processes are trying to use the same resource without sufficient
coordination.  Some times one process completes first, other times the
other completes first.  This causes differing behavior at different
times.

Here, I expect that Mutt is writing out that temporary file, invoking
Iceweasel, and then cleaning up the temporary file without concerning
itself with whether Iceweasel has had time to start itself and open
the file.  If Iceweasel already has the file open, then Mutt can
delete it now and it will go away when Iceweasel closes it.  Otherwise
Iceweasel goes to open the file it was told to show, and the file is
not there, because it was already deleted by Mutt.

There are at least two ways to cure a race.  The simple one is to get
one process to wait for the other to finish, or at least fully start.
The more complex (but preferred if it is not too difficult) way is to
have the processes tell each other how they're proceeding so that each
can make good decisions.  The simple way here is to get Mutt to wait
until you tell it to proceed.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
There's an app for that:  your browser


pgpomO_goarDy.pgp
Description: PGP signature

Re: Config Files, and Remaining Confusion with html-mail

[Marco Giusti]

On Fri, Jan 25, 2013 at 12:26:11PM -0500, Mark H. Wood wrote:
[cut]
  Second(personal issue):  I'm still having problems with
  getting my html-mail to open(in a new tab) in my browser,
  which is Firefox(Debianers call it iceweasel).  Often,
  when I use 'v' on an entry in my mutt display, and then
  Arrow down to 3 . . . . [text/html . . . ., and then
  press Enter, a new Tab does open in my browser, and I see
  the html-mail displayed nicely.  Even then I get, in my
  browser-Tab: file:///home/alan/tmp/mutt.html, but there
  is no such file in my ~/tmp directory!
  
  But, too often, I get a quick new tab, a tenth of a second
  look at the html I want to see, and then mutt thinks better
  of it and I get a screen:  
 File not found  Iceweasel can't find the file at
 /home/alan/tmp/mutt.html
  
  The decision which way mutt will go between these two
  alternatives is, as far as I can see, quite arbitrary.
 
 You probably need to add ; needsterminal to your .mailcap entry for
 text/html so that Mutt will ask you to hit a key when the external
 program (Iceweasel) is finished.  For more on .mailcap and how Mutt
 interprets it, see:
 
   http://www.mutt.org/doc/manual/manual-5.html
 
 especially the section Optional Fields.
 
 Background:
 
 This sounds like what is usually called a race condition.  Two
 processes are trying to use the same resource without sufficient
 coordination.  Some times one process completes first, other times the
 other completes first.  This causes differing behavior at different
 times.
 
 Here, I expect that Mutt is writing out that temporary file, invoking
 Iceweasel, and then cleaning up the temporary file without concerning
 itself with whether Iceweasel has had time to start itself and open
 the file.  If Iceweasel already has the file open, then Mutt can
 delete it now and it will go away when Iceweasel closes it.  Otherwise
 Iceweasel goes to open the file it was told to show, and the file is
 not there, because it was already deleted by Mutt.
 
 There are at least two ways to cure a race.  The simple one is to get
 one process to wait for the other to finish, or at least fully start.
 The more complex (but preferred if it is not too difficult) way is to
 have the processes tell each other how they're proceeding so that each
 can make good decisions.  The simple way here is to get Mutt to wait
 until you tell it to proceed.

third one, less scientific but it works most of the times: add the
following lines to your ~/.mailcap


text/html; sensible-browser %s  sleep 2; nametemplate=%s.html
text/html; w3m -I %{charset} -T text/html -dump %s; print=w3m -I 
%{charset} -T text/html -dump %s; nametemplate=%s.html; copiousoutput

you can substitute sensible-browser with iceweasel or firefox. I don't
remember why I did not set the test field on the first line:

test=sh -c 'test $DISPLAY'

Re: Config Files, and Remaining Confusion with html-mail

[s. keeling]

Incoming from Mark H. Wood:
 On Fri, Jan 25, 2013 at 09:28:05AM -0500, Alan McConnell wrote:
  First, generically: I feel it is a source of difficulty that
  mutt relies on two config files, .muttrc and .mailcap.  Perhaps
 
 .mailcap is a general-purpose configuration file for anything that
 wants to know what you would like done with certain types of content.
 Lots of other tools also use .mailcap and /etc/mailcap.
 
 This is why they are separate.  One belongs to Mutt and the other
 belongs to the world (including Mutt, which can use it).

That was a beautiful exposition.  I want to mention one addition to
it:

   set mailcap_path=~/mutt/mailcap

Meaning, you can have a ~/.mailcap, *and* you can have a mutt specific
mailcap, if you like that sort of thing.  So if you sometimes read
mail or deal with attachments with a program other than mutt, it'll do
it its way instead of mutt's way, and mutt will do it mutt's way.

Personally, I think reading mail in a GUI is insane (but that's just
me).  Oh yeah:

   # set use_mailcap

Commented out here; not sure what it's for or what it does.  I should
look into that.


-- 
Any technology distinguishable from magic is insufficiently advanced.
(*) :(){ :|: };:
- -

Re: Config Files, and Remaining Confusion with html-mail

[Alan McConnell]

On Fri, Jan 25, 2013 at 12:53:20PM -0700, s. keeling wrote:
 Incoming from Mark H. Wood:
  On Fri, Jan 25, 2013 at 09:28:05AM -0500, Alan McConnell wrote:
   First, generically: I feel it is a source of difficulty that
   mutt relies on two config files, .muttrc and .mailcap.  Perhaps
  
  .mailcap is a general-purpose configuration file for anything that
  wants to know what you would like done with certain types of content.
  Lots of other tools also use .mailcap and /etc/mailcap.
  
  This is why they are separate.  One belongs to Mutt and the other
  belongs to the world (including Mutt, which can use it).
 
 That was a beautiful exposition.
   LOL  It may seem beautiful to some, but it can't
   help anyone with a practical problem.

Mr Wood wrote further:
 You probably need to add ; needsterminal to your .mailcap entry for
 text/html so that Mutt will ask you to hit a key when the external
 program (Iceweasel) is finished.
  sigh  My iceweasel(aka Firefox) runs, and displays in the
  middle of my screen, from the moment my computer is turned
  on in the morning till I use it to talk to my DSL modem
  to shut down my connection in the evening, preparatory to
  shutdown -h now.

  For more on .mailcap and how Mutt
 interprets it, see:
 http://www.mutt.org/doc/manual/manual-5.html
I've pored over the whole document, including this
section.  It is likely my stupidity that makes me
unable to find in it why the .muttrc and the .mailcap
are fighting with each other

Re Race Conditions.  Unless I am mistaken, mutt is
written as a single, un-threaded process; I believe that
'me' is (justly) proud of this achievement.  So I do
not understand how two processes can be involved here.

Let me say once again, as clearly as I can: when the
mutt pager tells me(when I press 'v') that there is a
text/html E-mail there, and I select it, I want a new
tab to open on my browser, and whatever is in that
text/html file?/version? to be displayed in that tab.
This now happens most of the time; I want it to happen
all the time.   I hope that some judicious adjustment
of my .mailcap and my .muttrc can make this happen.

Best wishes,

Alan

-- 
Alan McConnell :  http://globaltap.com/~alan/
No one minds what Jeffreys says . . it is not more than a week ago
that I heard him speak disrespectfully of the Equator.(Sydney Smith)

Re: Config Files, and Remaining Confusion with html-mail

[Kevin J. McCarthy]

Alan McConnell wrote:
 Re Race Conditions.  Unless I am mistaken, mutt is
 written as a single, un-threaded process; I believe that
 'me' is (justly) proud of this achievement.  So I do
 not understand how two processes can be involved here.

I see you posted an email about this back on December 19th too.
Although I thought Patrick Shanahan explained it clearly then, and just
now Mark H. Wood did again, I'll take a shot and try to (even) more
verbosely explain what is going on and why it's causing you a problem.

The normal view attachment process for mutt is:
1. Create temp file
2. Launch viewer process
3. Wait for viewer to exit
4. Delete temp file

Assuming you already have a main firefox window running, when you
invoke firefox -new-tab %s, it does not block.  It simply notifies
your main running firefox process to open a tab pointing to %s and then
exits right away.  There is now a race condition.  Does mutt delete
the temp file before or after your main firefox process creates the new
tab pointing to it?

Here are two (simplified) tables showing the basic ways this can play
out:

   mutt   firefox -new-tabmain firefox
      
1. Create temp file
2. Launch ff -new-tab %s
   3. Notify main firefox
  process to create a
  new tab %s
   4. Exit
5. Creates new tab
   pointing to %s
6. Wait for ff -new-tab
   to exit
7. Delete temp file %s

-or-

   mutt   firefox -new-tabmain firefox
      
1. Create temp file
2. Launch ff -new-tab %s
   3. Notify main firefox
  process to create a
  new tab %s
   4. Exit
5. Wait for ff -new-tab
   to exit
6. Delete temp file %s
7. Creates new tab
   pointing to %s
8. Error - No such
   file

Which one happens depends on which process gets control after step 4:
the main firefox process or mutt.  In the first case, main firefox is
able to find the file and read it in.  In the second case, main firefox
can't open the file, and you get an error message.  In either case,
though, if you go look for the file in /tmp, the file will be gone
because mutt has already deleted it.

There is no completely clean way to fix this, because there is no way to
know how long the main firefox will need %s to be around.  If you only
intend to quickly view the file and then close the tab, the best way is
to have mutt sleep after invoking firefox -new-tab.  Try modifying
your .mailcap invocation to:
text/html; firefox -new-tab '%s'  sleep 10; test=
^^^
add this

The idea is that even if the second scenario happens, mutt will just
sleep instead of deleting the temp file.  Hopefully the main firefox
will have a chance to run and read that file in before the sleep ends
and mutt deletes the file.

Race conditions are complicated, and this explanation is not complete,
but I hope this helps.

-Kevin


signature.asc
Description: Digital signature

Re: Config Files, and Remaining Confusion with html-mail

[s. keeling]

Incoming from Alan McConnell:
 
 sigh  My iceweasel(aka Firefox) runs, and displays in the
 middle of my screen, from the moment my computer is turned

Just a suggestion ... isolate the problem.  Swap out firefox.  In my
~/mutt/mailcap:

   text/html; w3m -I %{charset} -T text/html -dump; copiousoutput

Bon chance.


-- 
Any technology distinguishable from magic is insufficiently advanced.
(*) :(){ :|: };:
- -

Re: Difficulty with html-mail

[Maxim Vuets]

On Wed, Dec 19, 2012 at 09:40:35PM -0600, Jim Graham wrote:
   I 1 no description  [multipa/alternativ, 7bit, 
 13K]
   I 2 ??no description [text/plain, quoted, 
 utf-8, 1.6K]
   I 3 ??no description   [text/html, quoted, 
 utf-8, 11K]

Just curious...are the question marks from your e-mail or from my system?

Hey Jim,

Your assumption is correct---it's from your system. You can check how
the original mail should look like via the following link (assuming your
web-browser handles it correctly) (-:
http://article.gmane.org/gmane.mail.mutt.user/40236

Difficulty with html-mail

[Alan McConnell]

Assembled Wisdom!

No, the difficulty is not just that it existsG, it is how
my mutt occasionally deals with it.

I call up mutt from one of my terms(URxvt) and it displays my
E-mail from /var/spool/mail/alan, as is normal. With many
of my mails I press 'v' to get a display like

  I 1 no description  [multipa/alternativ, 7bit, 13K]
  I 2 ├─no description [text/plain, quoted, utf-8, 1.6K]
  I 3 └─no description   [text/html, quoted, utf-8, 11K]

and use my arrow keys to get to the number 3, '[text/html, . . .'
I then press 'Enter'  and _sometimes_ a tab opens on my browser to
display the interpreted content of the mail.  This is what I want.
But _sometimes_  I get a tab: Problem loading page with a display

File not found
Iceweasel can't find the file at /home/alan/tmp/mutt.html.

And this is true; there is nothing in my ~/tmp directory.
But there is also nothing in my tmp/ directory when the html-mail
opens successfully.  The Tab says:
  file:///home/alan/tmp/mutt.html
but there is nothing of that kind in my ~tmp/.

I suspect that my ~/.mailcap file is not correct.  I was given it
several years ago, and I've never understood it.  I give it here, in
its one-line entirety:

text/html; iceweasel -new-tab '%s'; test=test -n $DISPLAY;nametemplate=%s.html

I am running Debian squeeze; my browser is iceweasel; my mutt is 1.5.20.
I spare you my .muttrc, except to say that it has been pretty constant
for my many years of using mutt and Linux.

TIA for expected help!

Alan

-- 
Alan McConnell :  http://globaltap.com/~alan/
   War is God's way of teaching Americans geography.(Bierce)
   Know thyself.  If you need help, call the C.I.A.

Re: Difficulty with html-mail

[Patrick Shanahan]

* Alan McConnell a...@his.com [12-19-12 16:13]:
 [...] 
 I call up mutt from one of my terms(URxvt) and it displays my
 E-mail from /var/spool/mail/alan, as is normal. With many
 of my mails I press 'v' to get a display like
 
   I 1 no description  [multipa/alternativ, 7bit, 
 13K]
   I 2 ├─no description [text/plain, quoted, utf-8, 
 1.6K]
   I 3 └─no description   [text/html, quoted, utf-8, 
 11K]
 
 and use my arrow keys to get to the number 3, '[text/html, . . .'
 I then press 'Enter'  and _sometimes_ a tab opens on my browser to
 display the interpreted content of the mail.  This is what I want.
 But _sometimes_  I get a tab: Problem loading page with a display
 
 File not found
 Iceweasel can't find the file at /home/alan/tmp/mutt.html.
 
 And this is true; there is nothing in my ~/tmp directory.
 But there is also nothing in my tmp/ directory when the html-mail
 opens successfully.  The Tab says:
   file:///home/alan/tmp/mutt.html
 but there is nothing of that kind in my ~tmp/.
 
 I suspect that my ~/.mailcap file is not correct.  I was given it
 several years ago, and I've never understood it.  I give it here, in
 its one-line entirety:

I suspect your temp file has expired before the browser has a change to
open it, especially since you cannot see it below ~/tmp (I rather use
system tmp, /tmp).

Install a delay/wait state after exporting the file so it does not
disappear to quickly.  I did this myself sometime back but no longer
require it and cannot remember where/how I did it.
-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  HOG # US1244711
http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2
http://en.opensuse.org   openSUSE Community Member
Registered Linux User #207535@ http://linuxcounter.net

Re: Difficulty with html-mail

[Alan McConnell]

Wow, you are quick!

On Wed, Dec 19, 2012 at 04:19:32PM -0500, Patrick Shanahan wrote:
 * Alan McConnell a...@his.com [12-19-12 16:13]:
  [...] 
  File not found
  Iceweasel can't find the file at /home/alan/tmp/mutt.html.
  
  And this is true; there is nothing in my ~/tmp directory.
  But there is also nothing in my tmp/ directory when the html-mail
  opens successfully.  The Tab says:
file:///home/alan/tmp/mutt.html
  but there is nothing of that kind in my ~tmp/.

I am sorry, I miswrote.  My /tmp exists of course, and so
does my ~/tmp, /home/alan/tmp/.  What I meant was: there
is nothing relevant to mutt in it.  I have just checked,
there is a #mutt . . . file in it now, reflecting the
fact that I am editing a reply to you.

 Install a delay/wait state after exporting the file so it does not
 disappear to quickly.  I did this myself sometime back but no longer
 require it and cannot remember where/how I did it.
  LOL  Very reminiscent of how I operate!  one gets involved
  in a difficulty, one fixes it, and then the solution slowly
  oozes out of one's brain. 

Thanks for your reply!

Alan

-- 
Alan McConnell :  http://globaltap.com/~alan/
   War is God's way of teaching Americans geography.(Bierce)
   Know thyself.  If you need help, call the C.I.A.

Re: Difficulty with html-mail

[Patrick Shanahan]

* Alan McConnell a...@his.com [12-19-12 16:32]:
 Wow, you are quick!
 
 On Wed, Dec 19, 2012 at 04:19:32PM -0500, Patrick Shanahan wrote:
  * Alan McConnell a...@his.com [12-19-12 16:13]:
   [...] 
   File not found
   Iceweasel can't find the file at /home/alan/tmp/mutt.html.
 [...]

I have a work-a-round(tm!) that I employ just for viewing html mail
because I have a somewhat convoluted setup.  I maintain a tmux (similar to
screen) session containing a mutt instance from a remote computer where I
maintain my mail and web servers.  Since the tmux session is viewed
locally but the session originates somewhere else, dumping html mail to a
local browser is not a direct operation.  I have a macro to dump the http
portion to a specific file and a local browser set to access that file via
nfs:
 macro   attach  ,x  |rm -f ~/mutt.htmlenter:unset \
   wait_key\n;save-entrykill-line~/mutt.htmlenter

to access:
 browser file:///mnt/nfs/remote-home/mutt.html

You should have no trouble making this work for a local operation.


ps:  Please, I read the list and have *no* need or request for a second
  copy of list mail.  Mutt *does* provide for a list-reply, a function
  missing on many of the lessor clients available on other operating
  systems.

-- 
(paka)Patrick Shanahan   Plainfield, Indiana, USA  HOG # US1244711
http://wahoo.no-ip.orgPhoto Album: http://wahoo.no-ip.org/gallery2
http://en.opensuse.org   openSUSE Community Member
Registered Linux User #207535@ http://linuxcounter.net

Re: Difficulty with html-mail

[Gary Johnson]

On 2012-12-19, Alan McConnell wrote:
 Assembled Wisdom!
 
 No, the difficulty is not just that it existsG, it is how
 my mutt occasionally deals with it.
 
 I call up mutt from one of my terms(URxvt) and it displays my
 E-mail from /var/spool/mail/alan, as is normal. With many
 of my mails I press 'v' to get a display like
 
   I 1 no description  [multipa/alternativ, 7bit, 
 13K]
   I 2 ├─no description [text/plain, quoted, utf-8, 
 1.6K]
   I 3 └─no description   [text/html, quoted, utf-8, 
 11K]
 
 and use my arrow keys to get to the number 3, '[text/html, . . .'
 I then press 'Enter'  and _sometimes_ a tab opens on my browser to
 display the interpreted content of the mail.  This is what I want.
 But _sometimes_  I get a tab: Problem loading page with a display
 
 File not found
 Iceweasel can't find the file at /home/alan/tmp/mutt.html.
 
 And this is true; there is nothing in my ~/tmp directory.
 But there is also nothing in my tmp/ directory when the html-mail
 opens successfully.  The Tab says:
   file:///home/alan/tmp/mutt.html
 but there is nothing of that kind in my ~tmp/.
 
 I suspect that my ~/.mailcap file is not correct.  I was given it
 several years ago, and I've never understood it.  I give it here, in
 its one-line entirety:
 
 text/html; iceweasel -new-tab '%s'; test=test -n 
 $DISPLAY;nametemplate=%s.html

There are some tips on handling that problem here:

http://www.spocom.com/users/gjohnson/mutt/#background

Regards,
Gary

Re: Difficulty with html-mail

[Jim Graham]

On Wed, Dec 19, 2012 at 04:12:55PM -0500, Alan McConnell wrote:
 
 I call up mutt from one of my terms(URxvt) and it displays my
 E-mail from /var/spool/mail/alan, as is normal. With many
 of my mails I press 'v' to get a display like
 
   I 1 no description  [multipa/alternativ, 7bit, 
 13K]
   I 2 ??no description [text/plain, quoted, utf-8, 
 1.6K]
   I 3 ??no description   [text/html, quoted, 
 utf-8, 11K]

Just curious...are the question marks from your e-mail or from my system?
I see these quite frequently with some e-mail (primarily on e-mail
lists), and am wondering what causes that (aside from what I THINK is the
obvious answer, characters that aren't being interpreted properly).

Later,
   --jim

-- 
THE SCORE:  ME:  2  CANCER:  0
73 DE N5IAL (/4)MiSTie #49997   Running Mac OS X Lion 
spooky1...@gmail.com ICBM/Hurricane: 30.44406N 86.59909W

Do not look into waveguide with remaining eye.

Re: New tool for sending HTML mail with Mutt

[Chip Camden]

Quoth Nicolas Williams on Thursday, 09 December 2010:
 On Thu, Dec 09, 2010 at 07:25:11PM +0200, Amit Ramon wrote:
  Nicolas Williams nicolas.willi...@oracle.com [2010-12-08 13:25 -0600]:
  
  On Wed, Dec 08, 2010 at 09:17:02PM +0200, Amit Ramon wrote:
  Chip Camden sterl...@camdensoftware.com [2010-12-08 11:01 -0800]:
  On a related topic, is there any way to get mutt to display RTL for
  certain characters?  The Hebrew characters in your signature, for
  instance, are displayed LTR in my mutt, so they read backwards.
  
  Not directly. For that you have to use a bidi-aware terminal. I'm
  running Mutt in Mlterm terminal emulator, which can handle LTR and RTL
  quiet well (but not perfectly).
  
  I agree, this is a job for the rendered, which is also why you shouldn't
  need your plain2html program -- the web browsers displaying your email
  in webmail apps should handle bi-di correctly as long as they understand
  UTF-8.  Might the webmail backend be doing something wrong?
  
  I don't agree... web browsers are not supposed to be able to know how
  to render bidi text. For this reason there are dir tags in
  HTML. Webmail backends are also not doing it. This is not the same as
  understand UTF-8.
 
 I'm not too familiar with bi-di, and I can see that a dir tag does exist
 for HTML.  We seem to agree that terminals (which have no HTML-like
 tags) are supposed to figure out how to render bi-di correctly.  Looking
 around a bit I see that there are three standard ways to indicate
 direction changes:
 
  - Use Unicode control characters, most of which are discouraged, except
for the right-to-left and left-to-right marks (which are for
specifying direction for weak-directional characters relative to
surrounding strong-directional characters);
 
  - Use HTML dir attribute or bdo element;
 
  - Use CSS rules ('direction' and 'bidi-override' props).
 
 The last two are for HTML docs only.  The first one is the only one that
 works in all contexts, while markup solutions based on anything other
 than Unicode require tags/attributes to be defined.
 
 But there is a Unicode bi-di algorithm...  From what I can tell,
 renderers that implement it should not require marks (except for
 weak-directional characters, as mentioned above).
 
  How would I know if the Hebrew text in your signature is displaying
  correctly?  [...]
  
  The first Hebrew letter in my first name is Ayn, which looks
  schematically like this:
  
[...]
  
  In a correct appearance you should see it at the rightmost place on
  the line that has my first name, Amit, in my signature... if it
  follows the word Amit immediately after the blank space, the terminal
  does not support bidi.
 
 Indeed, my terminal is not displaying those in right-to-left.  I see
 that some applications do display properly (for example, the Bluefish
 editor does, but vim/gvim does not).
 
 Nico
 -- 

If you're using urxvt as your terminal window, I've created a Perl
extension that will apply bidi rules to the text.

Check it out: http://www.chipstips.com/?p=584

-- 
Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F
http://camdensoftware.com | http://chipstips.com| http://chipsquips.com


pgpEdy5quqO44.pgp
Description: PGP signature

Re: New tool for sending HTML mail with Mutt

[Amit Ramon]

Nicolas Williams nicolas.willi...@oracle.com [2010-12-08 13:25 -0600]:


On Wed, Dec 08, 2010 at 09:17:02PM +0200, Amit Ramon wrote:

Chip Camden sterl...@camdensoftware.com [2010-12-08 11:01 -0800]:
On a related topic, is there any way to get mutt to display RTL for
certain characters?  The Hebrew characters in your signature, for
instance, are displayed LTR in my mutt, so they read backwards.

Not directly. For that you have to use a bidi-aware terminal. I'm
running Mutt in Mlterm terminal emulator, which can handle LTR and RTL
quiet well (but not perfectly).


I agree, this is a job for the rendered, which is also why you shouldn't
need your plain2html program -- the web browsers displaying your email
in webmail apps should handle bi-di correctly as long as they understand
UTF-8.  Might the webmail backend be doing something wrong?


I don't agree... web browsers are not supposed to be able to know how
to render bidi text. For this reason there are dir tags in
HTML. Webmail backends are also not doing it. This is not the same as
understand UTF-8.



How would I know if the Hebrew text in your signature is displaying
correctly?  The glyphs appear to be correct.  Would inserting spaces
between the characters change the order in which they appear?  If so, my
terminal (Terminator) is not handlint bi-di correctly :(


The first Hebrew letter in my first name is Ayn, which looks
schematically like this:

   #   #
#  #
 # #
  ##
   #   #
#  #
 # #
  ##

In a correct appearance you should see it at the rightmost place on
the line that has my first name, Amit, in my signature... if it
follows the word Amit immediately after the blank space, the terminal
does not support bidi.

--

::

 Amitעמית
 Ramon   רמון

Re: New tool for sending HTML mail with Mutt

[Nicolas Williams]

On Thu, Dec 09, 2010 at 07:25:11PM +0200, Amit Ramon wrote:
 Nicolas Williams nicolas.willi...@oracle.com [2010-12-08 13:25 -0600]:
 
 On Wed, Dec 08, 2010 at 09:17:02PM +0200, Amit Ramon wrote:
 Chip Camden sterl...@camdensoftware.com [2010-12-08 11:01 -0800]:
 On a related topic, is there any way to get mutt to display RTL for
 certain characters?  The Hebrew characters in your signature, for
 instance, are displayed LTR in my mutt, so they read backwards.
 
 Not directly. For that you have to use a bidi-aware terminal. I'm
 running Mutt in Mlterm terminal emulator, which can handle LTR and RTL
 quiet well (but not perfectly).
 
 I agree, this is a job for the rendered, which is also why you shouldn't
 need your plain2html program -- the web browsers displaying your email
 in webmail apps should handle bi-di correctly as long as they understand
 UTF-8.  Might the webmail backend be doing something wrong?
 
 I don't agree... web browsers are not supposed to be able to know how
 to render bidi text. For this reason there are dir tags in
 HTML. Webmail backends are also not doing it. This is not the same as
 understand UTF-8.

I'm not too familiar with bi-di, and I can see that a dir tag does exist
for HTML.  We seem to agree that terminals (which have no HTML-like
tags) are supposed to figure out how to render bi-di correctly.  Looking
around a bit I see that there are three standard ways to indicate
direction changes:

 - Use Unicode control characters, most of which are discouraged, except
   for the right-to-left and left-to-right marks (which are for
   specifying direction for weak-directional characters relative to
   surrounding strong-directional characters);

 - Use HTML dir attribute or bdo element;

 - Use CSS rules ('direction' and 'bidi-override' props).

The last two are for HTML docs only.  The first one is the only one that
works in all contexts, while markup solutions based on anything other
than Unicode require tags/attributes to be defined.

But there is a Unicode bi-di algorithm...  From what I can tell,
renderers that implement it should not require marks (except for
weak-directional characters, as mentioned above).

 How would I know if the Hebrew text in your signature is displaying
 correctly?  [...]
 
 The first Hebrew letter in my first name is Ayn, which looks
 schematically like this:
 
   [...]
 
 In a correct appearance you should see it at the rightmost place on
 the line that has my first name, Amit, in my signature... if it
 follows the word Amit immediately after the blank space, the terminal
 does not support bidi.

Indeed, my terminal is not displaying those in right-to-left.  I see
that some applications do display properly (for example, the Bluefish
editor does, but vim/gvim does not).

Nico
-- 

New tool for sending HTML mail with Mutt

[Amit Ramon]

Hello list,

I'd like to announce a new tool that I developed that allows sending
HTML-formatted mail from within Mutt. I know... being a Mutt's user
already means we are no big fans of HTML mail, but I had some reasons
for developing this tool, as I shall explain now.

I'm using Mutt as my main mail reader/writer for a couple of years now
and am very pleased with it. My only problem was when communicating
with people who are using web-mail for reading their mail. I'm writing
lots of mails in Hebrew, which is a right-to-left language. It seems
that many web-mail clients are not handling text/plain messages (this
is basically what Mutt sends) in some situations. The reason for that,
AFAIK, is that they just don't know the language direction and have to
make an arbitrary decision. Gmail, for example, seems to be basing
this decision on the UI language setting. If the user, for instance,
sets the language to English, a text/plain message will be
left-aligned, no matter in which language it is written. When the text
mixes words in both RTL and LTR languages, the order of the words
might be wrong. The same would happen if the UI languages is set to
Hebrew, but one tries to read a text/plain message in English. Since I
have (or just want...) to communicate with people who are not using
Mutt, and even like using web-mail clients, I decided to come up with
a solution.

The solution I came with is a 'filter' that stands between Mutt and
the actual mail-sending utility (e.g. sendmail or msmtp). Mutt is
configured to pass the mail to this new tool instead to sendmail. The
tool - plainMail2HTML - parses the mail, generates a HTML part and
attaches it to the message, and then passes it over to sendmail. So if
the original mail has only text so its type is text/plain, it would
become a multipart/alternative message that contains text/plain and
text/html parts. This is done automatically for every mail, or you can
of course configure the behavior using hooks and macros.

Another feature of plainMail2HTML is that it contains a parser that
parse reStructuredText (a text markup language) so I can control the
formatting of the mail. This parse is designed to be modular, so it
can be replaced with a different parser (although this was not yet
tried).

plainMail2HTML is written in Python and uses docutils. It also uses a
variation of docutils rst-to-html utility that reads the text and
insert direction tags into the html (dir=RTL, dir=LTR) so the
resulting HTML is BIDI-aware.

I just created a project for it on Sourceforge. I've been using it for
many months now and it's working pretty nice. It can also handle
forwarded messages and messages with attachments. It still lacks some
features and better error handling.

The project is https://sourceforge.net/projects/plain2html/

There is additional information in the README file on the project
page, and you can download a beta version. The project yet lacks
decent documentation, but I'd be glad to answer any question about it.

I hope some of you would find this interesting and perhaps even
useful. I'd be happy to hear any comments and suggestions. Developers
are welcome to join the project, too.

Best,

Amit

--

::

Amitעמית
Ramon   רמון

Re: New tool for sending HTML mail with Mutt

[Chip Camden]

Quoth Amit Ramon on Wednesday, 08 December 2010:
 Hello list,
 
 I'd like to announce a new tool that I developed that allows sending
 HTML-formatted mail from within Mutt. I know... being a Mutt's user
 already means we are no big fans of HTML mail, but I had some reasons
 for developing this tool, as I shall explain now.
 
 I'm using Mutt as my main mail reader/writer for a couple of years now
 and am very pleased with it. My only problem was when communicating
 with people who are using web-mail for reading their mail. I'm writing
 lots of mails in Hebrew, which is a right-to-left language. It seems
 that many web-mail clients are not handling text/plain messages (this
 is basically what Mutt sends) in some situations. The reason for that,
 AFAIK, is that they just don't know the language direction and have to
 make an arbitrary decision. Gmail, for example, seems to be basing
 this decision on the UI language setting. If the user, for instance,
 sets the language to English, a text/plain message will be
 left-aligned, no matter in which language it is written. When the text
 mixes words in both RTL and LTR languages, the order of the words
 might be wrong. The same would happen if the UI languages is set to
 Hebrew, but one tries to read a text/plain message in English. Since I
 have (or just want...) to communicate with people who are not using
 Mutt, and even like using web-mail clients, I decided to come up with
 a solution.
 
 The solution I came with is a 'filter' that stands between Mutt and
 the actual mail-sending utility (e.g. sendmail or msmtp). Mutt is
 configured to pass the mail to this new tool instead to sendmail. The
 tool - plainMail2HTML - parses the mail, generates a HTML part and
 attaches it to the message, and then passes it over to sendmail. So if
 the original mail has only text so its type is text/plain, it would
 become a multipart/alternative message that contains text/plain and
 text/html parts. This is done automatically for every mail, or you can
 of course configure the behavior using hooks and macros.
 
 Another feature of plainMail2HTML is that it contains a parser that
 parse reStructuredText (a text markup language) so I can control the
 formatting of the mail. This parse is designed to be modular, so it
 can be replaced with a different parser (although this was not yet
 tried).
 
 plainMail2HTML is written in Python and uses docutils. It also uses a
 variation of docutils rst-to-html utility that reads the text and
 insert direction tags into the html (dir=RTL, dir=LTR) so the
 resulting HTML is BIDI-aware.
 
 I just created a project for it on Sourceforge. I've been using it for
 many months now and it's working pretty nice. It can also handle
 forwarded messages and messages with attachments. It still lacks some
 features and better error handling.
 
 The project is https://sourceforge.net/projects/plain2html/
 
 There is additional information in the README file on the project
 page, and you can download a beta version. The project yet lacks
 decent documentation, but I'd be glad to answer any question about it.
 
 I hope some of you would find this interesting and perhaps even
 useful. I'd be happy to hear any comments and suggestions. Developers
 are welcome to join the project, too.
 
 Best,
 
 Amit
 
 -- 
 
 ::
 
 Amitעמית
 Ramon   רמון

On a related topic, is there any way to get mutt to display RTL for
certain characters?  The Hebrew characters in your signature, for
instance, are displayed LTR in my mutt, so they read backwards.

-- 
Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F
http://camdensoftware.com | http://chipstips.com| http://chipsquips.com


pgpdekJkbxo9S.pgp
Description: PGP signature

Re: New tool for sending HTML mail with Mutt

[Jason Helfman]

On Wed, Dec 08, 2010 at 11:01:04AM -0800, Chip Camden thus spake:

Quoth Amit Ramon on Wednesday, 08 December 2010:

Hello list,

I'd like to announce a new tool that I developed that allows sending
HTML-formatted mail from within Mutt. I know... being a Mutt's user
already means we are no big fans of HTML mail, but I had some reasons
for developing this tool, as I shall explain now.

I'm using Mutt as my main mail reader/writer for a couple of years now
and am very pleased with it. My only problem was when communicating
with people who are using web-mail for reading their mail. I'm writing
lots of mails in Hebrew, which is a right-to-left language. It seems
that many web-mail clients are not handling text/plain messages (this
is basically what Mutt sends) in some situations. The reason for that,
AFAIK, is that they just don't know the language direction and have to
make an arbitrary decision. Gmail, for example, seems to be basing
this decision on the UI language setting. If the user, for instance,
sets the language to English, a text/plain message will be
left-aligned, no matter in which language it is written. When the text
mixes words in both RTL and LTR languages, the order of the words
might be wrong. The same would happen if the UI languages is set to
Hebrew, but one tries to read a text/plain message in English. Since I
have (or just want...) to communicate with people who are not using
Mutt, and even like using web-mail clients, I decided to come up with
a solution.

The solution I came with is a 'filter' that stands between Mutt and
the actual mail-sending utility (e.g. sendmail or msmtp). Mutt is
configured to pass the mail to this new tool instead to sendmail. The
tool - plainMail2HTML - parses the mail, generates a HTML part and
attaches it to the message, and then passes it over to sendmail. So if
the original mail has only text so its type is text/plain, it would
become a multipart/alternative message that contains text/plain and
text/html parts. This is done automatically for every mail, or you can
of course configure the behavior using hooks and macros.

Another feature of plainMail2HTML is that it contains a parser that
parse reStructuredText (a text markup language) so I can control the
formatting of the mail. This parse is designed to be modular, so it
can be replaced with a different parser (although this was not yet
tried).

plainMail2HTML is written in Python and uses docutils. It also uses a
variation of docutils rst-to-html utility that reads the text and
insert direction tags into the html (dir=RTL, dir=LTR) so the
resulting HTML is BIDI-aware.

I just created a project for it on Sourceforge. I've been using it for
many months now and it's working pretty nice. It can also handle
forwarded messages and messages with attachments. It still lacks some
features and better error handling.

The project is https://sourceforge.net/projects/plain2html/

There is additional information in the README file on the project
page, and you can download a beta version. The project yet lacks
decent documentation, but I'd be glad to answer any question about it.

I hope some of you would find this interesting and perhaps even
useful. I'd be happy to hear any comments and suggestions. Developers
are welcome to join the project, too.

Best,

Amit

--

::

Amitעמית
Ramon   רמון


On a related topic, is there any way to get mutt to display RTL for
certain characters?  The Hebrew characters in your signature, for
instance, are displayed LTR in my mutt, so they read backwards.


Hebrew is left to right. That is how it is supposed to be read as a
language.



--
Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F
http://camdensoftware.com | http://chipstips.com| http://chipsquips.com




--
i am a mutthead

Re: New tool for sending HTML mail with Mutt

[Amit Ramon]

Chip Camden sterl...@camdensoftware.com [2010-12-08 11:01 -0800]:

On a related topic, is there any way to get mutt to display RTL for
certain characters?  The Hebrew characters in your signature, for
instance, are displayed LTR in my mutt, so they read backwards.


Not directly. For that you have to use a bidi-aware terminal. I'm
running Mutt in Mlterm terminal emulator, which can handle LTR and RTL
quiet well (but not perfectly).



--
Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F
http://camdensoftware.com | http://chipstips.com| http://chipsquips.com




--

::

Amitעמית
Ramon   רמון

Re: New tool for sending HTML mail with Mutt

[Nicolas Williams]

On Wed, Dec 08, 2010 at 09:17:02PM +0200, Amit Ramon wrote:
 Chip Camden sterl...@camdensoftware.com [2010-12-08 11:01 -0800]:
 On a related topic, is there any way to get mutt to display RTL for
 certain characters?  The Hebrew characters in your signature, for
 instance, are displayed LTR in my mutt, so they read backwards.
 
 Not directly. For that you have to use a bidi-aware terminal. I'm
 running Mutt in Mlterm terminal emulator, which can handle LTR and RTL
 quiet well (but not perfectly).

I agree, this is a job for the rendered, which is also why you shouldn't
need your plain2html program -- the web browsers displaying your email
in webmail apps should handle bi-di correctly as long as they understand
UTF-8.  Might the webmail backend be doing something wrong?

How would I know if the Hebrew text in your signature is displaying
correctly?  The glyphs appear to be correct.  Would inserting spaces
between the characters change the order in which they appear?  If so, my
terminal (Terminator) is not handlint bi-di correctly :(

Nico
-- 

Re: New tool for sending HTML mail with Mutt

[Chip Camden]

Quoth Jason Helfman on Wednesday, 08 December 2010:
 
 On a related topic, is there any way to get mutt to display RTL for
 certain characters?  The Hebrew characters in your signature, for
 instance, are displayed LTR in my mutt, so they read backwards.
 
 Hebrew is left to right. That is how it is supposed to be read as a
 language.
 

Uh, no.  It's traditionally RTL.  Where do you get that idea?

-- 
Sterling (Chip) Camden| sterl...@camdensoftware.com | 2048D/3A978E4F
http://camdensoftware.com | http://chipstips.com| http://chipsquips.com


pgpjOgUVQYC9V.pgp
Description: PGP signature

Re: New tool for sending HTML mail with Mutt

[Robert Holtzman]

On Wed, Dec 08, 2010 at 11:02:42AM -0800, Jason Helfman wrote:
 
 Hebrew is left to right. That is how it is supposed to be read as a
 language.

Where did you get that amazing piece of misinformation?

-- 
Bob Holtzman
Key ID: 8D549279
If you think you're getting free lunch,
 check the price of the beer


signature.asc
Description: Digital signature

Re: HTML mail: Why isn't it displayed?

[Monte Stevens]

On Fri, Nov 06, 2009 at 09:22:40PM -0700, lee wrote:

 Well, I have set implicit_autoview. Even when I press 'v' to view the
 attachments and then Enter to display it, I'm seeing the HTML source.

A recent post from Martin Krafft describes a problem rendering html.  It
sounds similar to yours; perhaps the issue is the same.  The subject is,
mutt no longer renders HTML or spawns browser on text/html
attachments.  

Here's a link to the most recent message in that thread.  (I hope that
sending you an html link is not a bad joke.)
http://marc.info/?l=mutt-usersm=125750062424772w=2

 Ok, so how do I get mutt to use a specific mailcap?

You did it, by setting:

mailcap_path=~/.mailcap

 I think it even used to work, and it might have stopped working after
 I installed the metamail package --- but I can't tell for sure if that
 actually has anything to do with it.

Hopefully the solutions in the other thread will work.

Re: HTML mail: Why isn't it displayed?

[bill lam]

On Tue, 03 Nov 2009, lee wrote:
 Hi,
 
 I've got an email with these headers:
 
 
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 X-Spam_score: 4.4
 X-Spam_score_int: 44
 X-Spam_bar: 
 
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml; xml:lang=de lang=de
 head
 
 
 Mutt displays the HTML garbage as plain text, unreadable. Now I've no
 idea if the problem is with mutt, or if the headers or something else
 are wrong.
 
 If the problem is with the email, it would be nice to know which RFCs
 are to be applied so that I can refer the sender of these mails to
 them and have them send them correctly encoded.

I suspect that email is mal-formated. The html is included inline
rather than as a multipart attachment.  Did you see the any
attachments in the attachment page?

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3

Re: HTML mail: Why isn't it displayed?

[lee]

On Sat, Nov 07, 2009 at 06:12:14AM -0400, Monte Stevens wrote:
 On Fri, Nov 06, 2009 at 09:22:40PM -0700, lee wrote:
 
  Well, I have set implicit_autoview. Even when I press 'v' to view the
  attachments and then Enter to display it, I'm seeing the HTML source.
 
 A recent post from Martin Krafft describes a problem rendering html.  It
 sounds similar to yours; perhaps the issue is the same.  The subject is,
 mutt no longer renders HTML or spawns browser on text/html
 attachments.  

Yeah, I've read that last night but couldn't find view-mailcap on
the help page. Now I've found it, and it's working --- might have to
do with me updating my Debian testing last night ...

 Here's a link to the most recent message in that thread.  (I hope that
 sending you an html link is not a bad joke.)
 http://marc.info/?l=mutt-usersm=125750062424772w=2

Nah, that's fine. Sending an URL is a totally different thing than
sending an HTML message.

  Ok, so how do I get mutt to use a specific mailcap?
 
 You did it, by setting:
 
 mailcap_path=~/.mailcap

That works now, too :)

Thanks!

Re: HTML mail: Why isn't it displayed?

[lee]

On Sat, Nov 07, 2009 at 06:35:17PM +0800, bill lam wrote:
 On Tue, 03 Nov 2009, lee wrote:
  Hi,
  
  I've got an email with these headers:
  
  
  Content-Type: text/html; charset=ISO-8859-1
  Content-Transfer-Encoding: quoted-printable
  X-Spam_score: 4.4
  X-Spam_score_int: 44
  X-Spam_bar: 
  
  !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
  html xmlns=http://www.w3.org/1999/xhtml; xml:lang=de lang=de
  head
  
  
 
 I suspect that email is mal-formated. The html is included inline
 rather than as a multipart attachment.  Did you see the any
 attachments in the attachment page?

It doesn't seem to have attachments: I have the counter displayed in
the message list, and it's 0 --- though that counter isn't always
right. When I look at the message with 'v', I'm seeing:


q:Exit  s:Save  |:Pipe  p:Print  ?:Help
  I 1 no description  
  [text/html, quoted, iso-8859-1, 7.2K]


So that would be inline, I guess? Is there an RFC specifying that HTML
source must not be inlined? I'd need something to point the sender of
the message to to have them change it.

Re: HTML mail: Why isn't it displayed?

[bill lam]

On Sat, 07 Nov 2009, lee wrote:
 On Sat, Nov 07, 2009 at 06:35:17PM +0800, bill lam wrote:
  On Tue, 03 Nov 2009, lee wrote:
   Hi,
   
   I've got an email with these headers:
   
   
   Content-Type: text/html; charset=ISO-8859-1
   Content-Transfer-Encoding: quoted-printable
   X-Spam_score: 4.4
   X-Spam_score_int: 44
   X-Spam_bar: 
   
   !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
  http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
   html xmlns=http://www.w3.org/1999/xhtml; xml:lang=de lang=de
   head
   
   
  
  I suspect that email is mal-formated. The html is included inline
  rather than as a multipart attachment.  Did you see the any
  attachments in the attachment page?
 
 It doesn't seem to have attachments: I have the counter displayed in
 the message list, and it's 0 --- though that counter isn't always
 right. When I look at the message with 'v', I'm seeing:
 
 
 q:Exit  s:Save  |:Pipe  p:Print  ?:Help
   I 1 no description
 [text/html, quoted, iso-8859-1, 7.2K]
 
 
 So that would be inline, I guess? Is there an RFC specifying that HTML
 source must not be inlined? I'd need something to point the sender of
 the message to to have them change it.

My isp also send this kind of machine generated monthly statement. I
guess they only care if it looks ok using outlook and not rfc
compliant.

-- 
regards,

GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3

Re: HTML mail: Why isn't it displayed?

[Monte Stevens]

On Wed, Nov 04, 2009 at 12:01:31AM -0700, lee wrote:
 PS:

Why is the PS at the top?

 Mutt seems to ignore ~/.mailcap.
 
 l...@cat:~/Mail$ mutt -nF /dev/null -Q mailcap_path
 mailcap_path=~/.mailcap:/usr/share/mutt/mailcap:/etc/mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap
 l...@cat:~/Mail$ 
 
 So which of the mailcap files mutt finds in the mailcap_path will it
 use? The manual doesn't say.

Based on the mailcap_path entry in man muttrc I would say that mutt
uses all the entries in all the files.  Perhaps you could shorten the
path so that you only need to worry about one file.

 On Tue, Nov 03, 2009 at 10:58:02PM -0700, lee wrote:
  I've got an email with these headers:
  
  Content-Type: text/html; charset=ISO-8859-1
  Content-Transfer-Encoding: quoted-printable
  X-Spam_score: 4.4
  X-Spam_score_int: 44
  X-Spam_bar: 

I've assumed this is the end of the headers.
 
  !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
  html xmlns=http://www.w3.org/1999/xhtml; xml:lang=de lang=de
  head

And that the above four lines are in the body of the message.

  Mutt displays the HTML garbage as plain text, unreadable. Now I've no
  idea if the problem is with mutt, or if the headers or something else
  are wrong.

I made a copy of your original post in another maibox.  Then I edited
that message, moving the quoted headers into the header section.

When I view your message in the mutt pager I see the html tags, since I
don't have implicit_autoview set in my muttrc.  When I press 'v' (for
view-attachments) I see one entry [text/html, quoted, iso-8859-1,]
in the attachment view.

When I view that attachment the html is rendered (and nicely
disappears).  The relevant entry in my mailcap file is:

text/html;  w3m -dump %s; nametemplate=%s.html; copiousoutput

It also renders OK with this mailcap entry:

text/html;  w3m %s | less; nametemplate=%s.html

  If the problem is with the email, it would be nice to know which RFCs
  are to be applied so that I can refer the sender of these mails to
  them and have them send them correctly encoded.

While I can't comment on the message you received, its reasonable
facsimile is rendered by w3m through mailcap on my system.  That tells
me that your message is probably OK and that something is wrong with
your mailcap.  Or, maybe your mailcap is fine and you don't have
implicit_autoview set and you're expecting to see only text in the mutt
pager.

Do you have problems with any other html messages?


-- 
Monte

HTML mail: Why isn't it displayed?

[lee]

Hi,

I've got an email with these headers:


Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam_score: 4.4
X-Spam_score_int: 44
X-Spam_bar: 

!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
   http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml; xml:lang=de lang=de
head


Mutt displays the HTML garbage as plain text, unreadable. Now I've no
idea if the problem is with mutt, or if the headers or something else
are wrong.

If the problem is with the email, it would be nice to know which RFCs
are to be applied so that I can refer the sender of these mails to
them and have them send them correctly encoded.

Re: HTML mail: Why isn't it displayed?

[lee]

PS:

Mutt seems to ignore ~/.mailcap.


l...@cat:~/Mail$ mutt -nF /dev/null -Q mailcap_path
mailcap_path=~/.mailcap:/usr/share/mutt/mailcap:/etc/mailcap:/etc/mailcap:/usr/etc/mailcap:/usr/local/etc/mailcap
l...@cat:~/Mail$ 


So which of the mailcap files mutt finds in the mailcap_path will it
use? The manual doesn't say.


On Tue, Nov 03, 2009 at 10:58:02PM -0700, lee wrote:
 Hi,
 
 I've got an email with these headers:
 
 
 Content-Type: text/html; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 X-Spam_score: 4.4
 X-Spam_score_int: 44
 X-Spam_bar: 
 
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml; xml:lang=de lang=de
 head
 
 
 Mutt displays the HTML garbage as plain text, unreadable. Now I've no
 idea if the problem is with mutt, or if the headers or something else
 are wrong.
 
 If the problem is with the email, it would be nice to know which RFCs
 are to be applied so that I can refer the sender of these mails to
 them and have them send them correctly encoded.

signatures - name+address is *minimum* (was: fast conversion of html mail to text)

[Sven Guckes]

* Laurabelle [EMAIL PROTECTED] [2002-09-26 18:03]:
 Just my 2p - I use procmail recipes (and a couple of scripts) to strip
 HTML formatting from all legitimate email.  The same scripts add a note
 to the effect that HTML has been removed; if I want to exchange email
 with that person again, I generally ask for text-only email.  People
 tend to cooperate, since after all they probably just don't realize it.

i have met quite some people who do undrestand the problem -
but keep ignoring that the keep offending people by sending
them all text as html, too.  the list is in my killfile...

 Sven  [usually attaching sigs which fit the content of the message]
 I find that my current .sig is often quite relevant when answering
 questions but even more so when asking them.  It reminds me that the
 answer is only as good as the question.  Besides, it's short.

 Laurabelle
 --
 ASCII silly question, get a silly ANSI.

this is a quote after sigdashes - but not a signature.
signatures contain at least a name and an address, too.

signatures contains a name *and* an address.  at least.
quotes are just quotes and may be added to signatures.

but i have to admit that the quote is nice, indeed! :-)

Sven

Re: fast conversion of html mail to text

[Mike Leone]

* Sven Guckes ([EMAIL PROTECTED]) wrote this on 09 30, 02 at 20:56: 
 * Sven Guckes said:
  well, if you subscribe to a HTML-only newsletter
  then you were asking for it - so it's your problem.
 
 * Michael Leone [EMAIL PROTECTED] [2002-09-26 17:27]:
  It's *not* a problem, for me, anyway.
 
 so you are ignoring the extra but superfluous data - fine.

Not ignoring it. And it's not (always) superflous - some people *want* their
email to be read in the way they present it - links, colors, etc. So I have
mutt call out w3m to see HTML-only email. Or I ignore it, if I feel like.
Like anything else, it's my choice. As ignoring it is your choice.

  To: [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED]
  X-Mailer: SquirrelMail (version 1.2.7)
 
 but you are obviously are also ignoring the fact that i am
 subscribed to the list and therefore do *not* need any CCs.

Usually, I edit that out, and have the list as the only email address in the
TO:, but I didn't bother that time.
 
 webmailers *suck*.  and if it is not the mailer
 then it must be the people using them.  *hrmpf*

Go have a beer or something, Sven - people will like you better if you're
less grumpy over things that are really not all that world-shattering.

G



msg31382/pgp0.pgp
Description: PGP signature

Re: fast conversion of html mail to text

[Sven Guckes]

* Mike Leone [EMAIL PROTECTED] [2002-09-26 03:35]:
   Actually, I've gotten many non-HTML spams, too.
   And I get many valid HTML mail, both
   newsletters and private correspondence.
  has the thought ever struck you that it might be *you*?

 Since I know many different people that both send and receive
 HTML mail, none of whome are spammers; and since I get a
 number of HTML-only newletters that are defintely not spam ...
 no, that thought has never struck me.  :-)

well, if you subscribe to a HTML-only newsletter
then you were asking for it - so it's your problem.

 Has the thought ever struck you that perhaps
 you are too restrictive in what you accept?

i have yet to see sn email which was enhanced by html.
and i suppose i do have a problem with DOCuments from
companies which forbid free software to use it, too.

   Random Thought:
  duh.
 Hey, not my fault - my SquirrelMail web interface
 sometimes forgets to read the output of the fortune program.

it's your problem then.  you are responsible for what you send!
please refrain from sending arbitrary noise to lists - thankyou.

Sven  [usually attaching sigs which fit the content of the message]

Re: fast conversion of html mail to text

[Michael Leone]

Sven Guckes said:
 * Mike Leone [EMAIL PROTECTED] [2002-09-26 03:35]:
   Actually, I've gotten many non-HTML spams, too.
   And I get many valid HTML mail, both
   newsletters and private correspondence.
  has the thought ever struck you that it might be *you*?

 Since I know many different people that both send and receive
 HTML mail, none of whome are spammers; and since I get a
 number of HTML-only newletters that are defintely not spam ...
 no, that thought has never struck me.  :-)

 well, if you subscribe to a HTML-only newsletter
 then you were asking for it - so it's your problem.

It's *not* a problem, for me, anyway. I know about the possible security
implications of HTML email, and know how to get around them. (most of
them, anyway).

 Has the thought ever struck you that perhaps
 you are too restrictive in what you accept?

 i have yet to see sn email which was enhanced by html.
 and i suppose i do have a problem with DOCuments from
 companies which forbid free software to use it, too.

Separate issue, tho.

-- 
PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Member, LEAF Project http://leaf.sourceforge.netAIM: MikeLeone
Public Key - http://www.mike-leone.com/~turgon/turgon-public-key.asc
Registered Linux user# 201348


Random Thought:
--
Cigarro: Objeto cilíndrico de papel, recheado com palha. Contém uma faísca
numa ponta e um idiota na outra.

Re: fast conversion of html mail to text

[Laurabelle]

On Sep 26 2002, Sven Guckes shared a puddle of experience:

snip about html email

Just my 2p - I use procmail recipes (and a couple of scripts) to strip
HTML formatting from all legitimate email.  The same scripts add a note
to the effect that HTML has been removed; if I want to exchange email
with that person again, I generally ask for text-only email.  People
tend to cooperate, since after all they probably just don't realize it.

Sven  [usually attaching sigs which fit the content of the message]

I find that my current .sig is often quite relevant when answering
questions but even more so when asking them.  It reminds me that the
answer is only as good as the question.  Besides, it's short.

Laurabelle
-- 
ASCII silly question, get a silly ANSI.

Re: fast conversion of html mail to text

[Laurabelle]

On Sep 25 2002, Erik Christiansen shared a puddle of experience:

snip
   (Of the 2247 advertising spams I've received since February, 1899
were html.)

Am I the only one who read that as February 1899 and thought what,
they had the internet back *then*?

Laurabelle
-- 
ASCII silly question, get a silly ANSI.

Re: fast conversion of html mail to text

[Michael Leone]

Laurabelle said:
 On Sep 25 2002, Erik Christiansen shared a puddle of experience:

 snip
   (Of the 2247 advertising spams I've received since February, 1899
were html.)

 Am I the only one who read that as February 1899 and thought what,
 they had the internet back *then*?

Yes, but only teletype machines. :-)

Actually, I've gotten many non-HTML spams, too. And I get many valid HTML
mail, both newsletters and private correspondence.


-- 
PGP Fingerprint: 0AA8 DC47 CB63 AE3F C739 6BF9 9AB4 1EF6 5AA5 BCDF
Member, LEAF Project http://leaf.sourceforge.netAIM: MikeLeone
Public Key - http://www.mike-leone.com/~turgon/turgon-public-key.asc
Registered Linux user# 201348


Random Thought:
--

Re: fast conversion of html mail to text

[Sven Guckes]

* On Sep 25 2002, Erik Christiansen..:
 Of the 2247 advertising spams I've received
 since February, 1899 were html.

* Laurabelle said:
 Am I the only one who read that as February 1899 and
 thought what, they had the internet back *then*?

* Michael Leone [EMAIL PROTECTED] [2002-09-25 18:37]:
 Yes, but only teletype machines. :-)

he he

 Actually, I've gotten many non-HTML spams, too.
 And I get many valid HTML mail, both
 newsletters and private correspondence.

has the thought ever struck you that it might be *you*?

 Random Thought:
 --


duh.

Sven  [bouncing back all html mail]

Re: fast conversion of html mail to text

[Mike Leone]

* Sven Guckes ([EMAIL PROTECTED]) wrote this on 09 25, 02 at 21:26: 
 * On Sep 25 2002, Erik Christiansen..:
  Of the 2247 advertising spams I've received
  since February, 1899 were html.
 
 * Laurabelle said:
  Am I the only one who read that as February 1899 and
  thought what, they had the internet back *then*?
 
 * Michael Leone [EMAIL PROTECTED] [2002-09-25 18:37]:
  Yes, but only teletype machines. :-)
 
 he he
 
  Actually, I've gotten many non-HTML spams, too.
  And I get many valid HTML mail, both
  newsletters and private correspondence.
 
 has the thought ever struck you that it might be *you*?

Since I know many different people that both send and receive HTML mail,
none of whome are spammers; and since I get a number of HTML-only newletters that
are defintely not spam ... no, that thought has never struck me.

:-)

Has the thought ever struck you that perhaps you are too restrictive in what you
accept?

 
  Random Thought:
  --
 
 
 duh.

Hey, not my fault - my SquirrelMail web interface sometimes forgets to read
the output of the fortune program.



msg31255/pgp0.pgp
Description: PGP signature

fast conversion of html mail to text

[Eric Smith]

I am getting a bit irritated by the second or two I need to wait
for `lynx -dump' or similiar to work when viewing the _many_ html
mails that happen upon my inbox - what are mutters doing to strip
the tags faster?

-- 
Eric Smith

Re: fast conversion of html mail to text

[Ken Weingold]

On Tue, Sep 24, 2002, Eric Smith wrote:
 I am getting a bit irritated by the second or two I need to wait
 for `lynx -dump' or similiar to work when viewing the _many_ html
 mails that happen upon my inbox - what are mutters doing to strip
 the tags faster?

Telling people not to send email as HTML.  Most don't know they're
doing it.


-Ken

Re: fast conversion of html mail to text

[Charles Cazabon]

Eric Smith [EMAIL PROTECTED] wrote:
 I am getting a bit irritated by the second or two I need to wait
 for `lynx -dump' or similiar to work when viewing the _many_ html
 mails that happen upon my inbox - what are mutters doing to strip
 the tags faster?

Deleting HTML mail unread.  It's /much/ faster that way.  Seriously; I've yet
to receive a piece of HTML mail that was worth reading.

Charles
-- 
---
Charles Cazabon [EMAIL PROTECTED]
GPL'ed software available at: http://www.qcc.ca/~charlesc/software/
---

Re: fast conversion of html mail to text

[Thomas E. Dickey]

On Tue, 24 Sep 2002, Eric Smith wrote:

 I am getting a bit irritated by the second or two I need to wait
 for `lynx -dump' or similiar to work when viewing the _many_ html
 mails that happen upon my inbox - what are mutters doing to strip
 the tags faster?

someone commented on lynx -dump recently, to the effect that there
are some messages which can be optimized in lynx by setting ALERTSECS,
INFOSECS and MESSAGESECS to zero.  (Actually he wanted to hard-code it
into the behavior of the -dump option, but it's easily scripted).

-- 
T.E.Dickey [EMAIL PROTECTED]
http://invisible-island.net
ftp://invisible-island.net

Re: fast conversion of html mail to text

[Sven Guckes]

* Eric old fruit Smith [EMAIL PROTECTED] [2002-09-24 13:44]:
 I am getting a bit irritated by the second or two I need to wait for
 `lynx -dump' or similiar to work when viewing the _many_ html mails that
 happen upon my inbox - what are mutters doing to strip the tags faster?

well - do not let mutt process the text/html stuff then.  simply ignore it!

Sven

-- 
HTMLHEADSTYLE type=text/css P#mypar {font-style: Bold; font-size:100pt;
color: red; background-color: yellow} /STYLE /HEAD BODY P id=mypar
Turn off the HTML in your emails - or else! /BODY /HTML

Re: fast conversion of html mail to text

[Johan Almqvist]

* Eric Smith [EMAIL PROTECTED] [020924 15:36]:
 I am getting a bit irritated by the second or two I need to wait
 for `lynx -dump' or similiar to work when viewing the _many_ html
 mails that happen upon my inbox - what are mutters doing to strip
 the tags faster?

Procmail

:0
*Content-type: text/html
{
:0 c
/home/johan/Maildir/.junk/

:0 fb
|lynx -force_html -dump /dev/stdin

:0 afwh
|formail -i Content-type: text/plain -I X-Johan: htmlkiller
}

(I don't really lie procmail, but I haven't come around to change this
script. I also save an extra copy in my junk Maildir, in case something
should get broken...)

-Johan
-- 
Johan Almqvist
http://www.almqvist.net/johan/qmail/

Re: fast conversion of html mail to text

[Patrick]

* Eric Smith [EMAIL PROTECTED] [09-24-02 08:54]:
 I am getting a bit irritated by the second or two I need to wait
 for `lynx -dump' or similiar to work when viewing the _many_ html
 mails that happen upon my inbox - what are mutters doing to strip
 the tags faster?

I use:
text/html; w3m -F -dump -T text/html %s; nametemplate=%s.html; copiousoutput

And it seems to be almost instantaneous.
-- 
Patrick Shanahan
Registered Linux User #207535 
  @ http://counter.li.org

Re: fast conversion of html mail to text

[bill luecke]

On Tue, Sep 24, 2002 at 03:36:49PM +0200, Eric Smith wrote:

I have the following line in my .mailcap

text/html; unhtml ; copiousoutput

I think the unhtml website is at 

http://www.econym.demon.co.uk/unhtml/

Then I view the mail as an attachment, and unhtml strips out the
tags. Seems instantaneous on my machine. I have no idea what it might
do for really complicated e-mails that had tables, etc. However,
unhtml seems excellent for getting rid of the formatting tags.


bill


 I am getting a bit irritated by the second or two I need to wait
 for `lynx -dump' or similiar to work when viewing the _many_ html
 mails that happen upon my inbox - what are mutters doing to strip
 the tags faster?
 
 -- 
 Eric Smith

-- 

William Luecke   

Re: fast conversion of html mail to text - unhtml

[Eric Smith]

bill luecke said:
 On Tue, Sep 24, 2002 at 03:36:49PM +0200, Eric Smith wrote:
 
 I have the following line in my .mailcap
 
 text/html; unhtml ; copiousoutput

good answer - apt-get install unhtml on debian

But it is still almost a second delay.
I think i will try and kill this problem with procmail.

-- 
Eric Smith

Re: fast conversion of html mail to text - unhtml

[Thomas E. Dickey]

On Tue, 24 Sep 2002, Eric Smith wrote:

 bill luecke said:
  On Tue, Sep 24, 2002 at 03:36:49PM +0200, Eric Smith wrote:
 
  I have the following line in my .mailcap
 
  text/html; unhtml ; copiousoutput

 good answer - apt-get install unhtml on debian

 But it is still almost a second delay.
 I think i will try and kill this problem with procmail.

What *SECS values does your lynx.cfg have?

-- 
T.E.Dickey [EMAIL PROTECTED]
http://invisible-island.net
ftp://invisible-island.net

Re: fast conversion of html mail to text

[Benjamin Pflugmann]

Hello.

On Tue 2002-09-24 at 15:36:49 +0200, Eric Smith wrote:
 I am getting a bit irritated by the second or two I need to wait
 for `lynx -dump' or similiar to work when viewing the _many_ html
 mails that happen upon my inbox - what are mutters doing to strip
 the tags faster?

Be sure to use the -nopause flag. Else, if lynx display a status
message for some reason, it will wait for some second(s). And yes, it
also does this with -dump and -source, where one does not get to see
the status message at all. At least, last time I tried.

Bye,

Benjamin.

-- 
[EMAIL PROTECTED]



msg31165/pgp0.pgp
Description: PGP signature

Re: fast conversion of html mail to text

[Thomas E. Dickey]

On Tue, 24 Sep 2002, Benjamin Pflugmann wrote:

 Hello.

 On Tue 2002-09-24 at 15:36:49 +0200, Eric Smith wrote:
  I am getting a bit irritated by the second or two I need to wait
  for `lynx -dump' or similiar to work when viewing the _many_ html
  mails that happen upon my inbox - what are mutters doing to strip
  the tags faster?

 Be sure to use the -nopause flag. Else, if lynx display a status
 message for some reason, it will wait for some second(s). And yes, it
 also does this with -dump and -source, where one does not get to see
 the status message at all. At least, last time I tried.

That's correct.

-- 
T.E.Dickey [EMAIL PROTECTED]
http://invisible-island.net
ftp://invisible-island.net

Re: fast conversion of html mail to text

[Christian Ordig]

On Tue, Sep 24, 2002 at 03:36:49PM +0200, Eric Smith wrote:
 I am getting a bit irritated by the second or two I need to wait
 for `lynx -dump' or similiar to work when viewing the _many_ html
 mails that happen upon my inbox - what are mutters doing to strip
 the tags faster?
let procmail kill it before it gets to my mutt .-)

-- 
Christian Ordig
Germany

Re: fast conversion of html mail to text

[Erik Christiansen]

On Tue, Sep 24, 2002 at 07:51:13AM -0600, Charles Cazabon wrote:
 Eric Smith [EMAIL PROTECTED] wrote:
  I am getting a bit irritated by the second or two I need to wait
  for `lynx -dump' or similiar to work when viewing the _many_ html
  mails that happen upon my inbox - what are mutters doing to strip
  the tags faster?
 
 Deleting HTML mail unread.  It's /much/ faster that way.  Seriously;
 I've yet to receive a piece of HTML mail that was worth reading.

   It's true! With procmail diverting html-only email to a junk folder,
   it is not each end-of-the-week survey that shows anything of interest.

   I'm no procmail guru, so others may be able to improve on:

   # First Content-Type: indicates lack of
   :0 HB:  # a plaintext alternative. i.e. HTML only:
   * 1^0 ^Content-Type:\/.*
   * MATCH ?? html
   junk

   And if you forget to look in there some weeks, what the heck? :-)

   (Of the 2247 advertising spams I've received since February, 1899
were html.)

Erik

Re: html mail - auto_view + mailcap

[Sven Guckes]

* Mike Arrison [EMAIL PROTECTED] [2002-05-13 10:36]:
 Having come from pine, I'm used to html mail being rendered
 by lynx or links or something automatically.  When I view an
 html mail in Mutt, it says [-- text/html is unsupported
 (use 'v' to view this part) --].  Is there something I
 can do to tell Mutt to render html with lynx or links?

  $ grep auto_view $HOME/.muttrc
  auto_view text/html application/msword

  $ egrep '(links|antiword)' $HOME/.mailcap
  text/html ; links -dump %s; nametemplate=%s.html; copiousoutput
  application/msword; antiword%s; copiousoutput

see also:
http://www.math.fu-berlin.de/~guckes/setup/mailcap
http://www.math.fu-berlin.de/~guckes/setup/mutt*

Sven

html mail

[Mike Arrison]

Hello,
Having come from pine, I'm used to html mail being rendered by
lynx or links or something automatically.  When I view an html mail in
Mutt, it says [-- text/html is unsupported (use 'v' to view this part)
--].  Is there something I can do to tell Mutt to render html with lynx
or links?

Thanks in advance,
 Mike Arrison

Re: html mail

[Simon White]

13-May-02 at 06:35, Mike Arrison ([EMAIL PROTECTED]) wrote :
 Hello,
 Having come from pine, I'm used to html mail being rendered by
 lynx or links or something automatically.  When I view an html mail in
 Mutt, it says [-- text/html is unsupported (use 'v' to view this part)
 --].  Is there something I can do to tell Mutt to render html with lynx
 or links?

Yes. Search for autoview and mailcap in the Mutt manual.

-- 
[Simon White. vim/mutt. [EMAIL PROTECTED] GIMPS:14.21% see www.mersenne.org]
Recognizing disagreements in belief requires having enough agreements in
belief to translate or understand the words and deeds of my opponent.
  -- Anthony O'Hear (combining, somewhat, several modern philosophers).

Re: html mail

[Tomas Venglovsky]

* Mike Arrison [EMAIL PROTECTED] [2002-05-13 12:36]:
 Hello,
 Having come from pine, I'm used to html mail being rendered by
 lynx or links or something automatically.  When I view an html mail in
 Mutt, it says [-- text/html is unsupported (use 'v' to view this part)
 --].  Is there something I can do to tell Mutt to render html with lynx
 or links?

Yes; put something like this to your ~/.mailcap

text/html; lynx -force_html %s

-- 
   _
Tomas VenglovskyASCII ribbon campaign ( )
Telenor Networks (system administrator)  - against HTML email  X
MOK-RIPE  vCards / \

Re: HTML Mail

[Sadiq Al-Lawatia]

Quoting Ian Chilton ([EMAIL PROTECTED]):
 Hello,
 
 Please reply direct to [EMAIL PROTECTED]
 
 I am trying to get HTML mails to display with links.

Ian,
I use links as my web browser as well and here is what I have in my
.mailcap :

text/html; links -dump %s; nametemplate=%s.html; copiousoutput

This should work fine without pressing v to view and then enter.

HTH.

--Sadiq

Re: HTML Mail

[Patrick]

* Rob 'Feztaa' Park [EMAIL PROTECTED] [04-13-02 00:37]:
 Alas! Patrick spake thus:
   I love dillo, it's so freaking fast. All it needs is just a few more
   features (like ftp support and bookmark heirarchies), and it'll replace
   Mozilla on my computer ;)
  
  You would probably also like skipstone (and it moving away from
  sourceforge).  Small and fast with more features than dillo.  Skipstone
  uses the GtkMozEmbed mozilla engine.  I use dillo for small browses
  that require few features and skipstone for more normal views.
 
 Looks interesting, I'm going to try it. It has tabbing, which is cool.
 How is it for loading time? You say it's fast -- faster or slower than
 dillo?

Features seem to mean less speed.  But it is still faster than the big
names, mozilla, galeon, etc.
-- 
Patrick Shanahan   Registered Linux User #207535
Registered at: http://counter.li.org

Re: HTML Mail

[Shawn McMahon]

begin  s. keeling quotation:
 
 spamcop's work, and hitting that last send reports bit.  Spamcop works
 great, except lynx tends to be the only browser that works well with
 their web server (Opera 5.0 is awful with it; Netscape is better; w3m

I have found the same thing; I just use Lynx via urlview, and it works
great.  You don't want to automate that anyway, it'd defeat the purpose
of feeding you the web page.  When they're more confident in
their defaults, they'll reopen the option for fast submissions.


-- 
Shawn McMahon| McMahon's Laws of Linux support:
http://www.eiv.com   | 1) There's more than one way to do it
AIM: spmcmahonfedex, smcmahoneiv | 2) Somebody thinks your way is wrong



msg27131/pgp0.pgp
Description: PGP signature

Re: HTML Mail

[David DeSimone]

Ian Chilton [EMAIL PROTECTED] wrote:

 [ian@buzz:~]$ cat .mailcap
 text/html; /usr/bin/links %s
 
 and these in .muttrc
 set mailcap_path=~/.mailcap
 auto_view text/html
 
 But I get this:
 mailcap entry for type text/html not found

Auto_view only looks for mailcap entries with the copiousoutput tag.

If you want to use an interactive browser like links, you must press 'v'
and press 'return' on the html attachment.

-- 
David DeSimone   | The doctrine of human equality reposes on this:
[EMAIL PROTECTED]   |  that there is no man really clever who has not
Hewlett-Packard  |  found that he is stupid. -- Gilbert K. Chesterson
Richardson IT|PGP: 5B 47 34 9F 3B 9A B0 0D  AB A6 15 F1 BB BE 8C 44

Re: HTML Mail

[s. keeling]

On Thu, Apr 11, 2002 at 02:54:29PM +0200, Stefan Frank wrote:
 At Thu, Apr 11 2002 [12:01 +0100], Ian Chilton aroused my curiosity with:
  text/html; /usr/bin/links %s
 
 Try something like:
 text/html; /usr/bin/links %s; copiousoutput
 
 and read section 5.3 MIME Viewer configuration with mailcap
 in the manual.

Since this thread came up, I've been trying some of the stuff you
people have been suggesting.  I'm finding it very confusing.

One of the things driving this is I'd like to find a way to easily
report spam to spamcop, which means I have to pass an ID and password.
This is possible with lynx -auth=uname:passwd.  With w3m or links, it
would be something like w3m http://uname:[EMAIL PROTECTED]/

That's the background.  So in my ~/.mailcap, I tried links %s;
copiousoutput:

  [-- Autoview using /usr/bin/links '/home/keeling/.mutt/tmp/mutt9aipDt' --]
  [-- Autoview stderr of /usr/bin/links '/home/keeling/.mutt/tmp/mutt9aipDt' --]
  ERROR: could not get terminal size

This in a real Xterm.  With no auto_view statements in .muttrc,
_everything_ comes up blah/blah is unsupported. use v ...


Here's (relevant parts of) my ~/.mailcap:

  --
# works great (lousy cookie handling, but otherwise fine)!
#
text/html;   w3m -cookie %s; copiousoutput; nametemplate=%s.html

# doesn't work at all, auto_view (.muttrc) or not.
#
# text/html;   /usr/bin/links %s; copiousoutput
# 
# [-- Autoview using /usr/bin/links '/home/keeling/.mutt/tmp/mutt9aipDt' --]
# ^[[1;1H[-- Autoview stderr of /usr/bin/links '/home/keeling/.mutt/tmp/mutt9aipDt' --]
# ^GERROR: could not get terminal size

# doesn't work.
#
# text/html;   /usr/bin/lynx -force_html %s; needsterminal;

# works with autoview (.muttrc).
#
# text/html;   /usr/bin/lynx -dump %s; copiousoutput; nametemplate=%s.html
  --


Right now, I like w3m the most of the three, lynx tends to work the
best, and links doesn't appear to work with mutt at all.

I've been rummaging around in the mutt manual for a couple of days
now, and I don't appear to be getting anywhere beyond where I was days
ago.  Ideas, comments, criticisms all welcome.

Finally, this is my first L post.  Is there a simple way to tell
mutt that I don't want to cc: the poster when I'm replying to the
list?  One of these days, I'm going to forget to clear out the cc:
header and somebody's gonna rag on me for it (with good reason IMO).

Thanks everybody.  You've been very helpful.   :-)


Mutt 1.3.12i (2000-11-27)
auto_view text/html
set mailcap_path=~/.mailcap

Links 0.92

Lynx Version 2.8.3dev.9 (13 Sep 1999)

Yes, I'm aware these are all getting a little long in the tooth.


-- 
Any technology distinguishable from magic is insufficiently advanced.
 TopQuark Software  Serv. Contract programmer, server bum.

Re: HTML Mail

[s. keeling]

On Fri, Apr 12, 2002 at 06:43:14PM -0500, David DeSimone wrote:
 Ian Chilton [EMAIL PROTECTED] wrote:
 
  [ian@buzz:~]$ cat .mailcap
  text/html; /usr/bin/links %s
  
  and these in .muttrc
  set mailcap_path=~/.mailcap
  auto_view text/html
  
  But I get this:
  mailcap entry for type text/html not found
 
 Auto_view only looks for mailcap entries with the copiousoutput tag.

Ah!  That's helpful, thanks.

 If you want to use an interactive browser like links, you must press 'v'
 and press 'return' on the html attachment.

Try w3m instead.


-- 
Any technology distinguishable from magic is insufficiently advanced.
 TopQuark Software  Serv. Contract programmer, server bum.

Re: HTML Mail

[Shawn McMahon]

begin  s. keeling quotation:
 
 One of the things driving this is I'd like to find a way to easily
 report spam to spamcop, which means I have to pass an ID and password.
 This is possible with lynx -auth=uname:passwd.  With w3m or links, it
 would be something like w3m http://uname:[EMAIL PROTECTED]/

Spamcop will give you an email address.  You forward the mails there,
and you can even make a Mutt alias to make it easy, so you just forward
them to spamcop.

Then they process it when the system load allows, and send you back an
URL to complete the process.  Much easier that trying to script a web
post, and has the advantage that you don't have to re-post if their
system load won't allow a submission at that moment.


-- 
Shawn McMahon| McMahon's Laws of Linux support:
http://www.eiv.com   | 1) There's more than one way to do it
AIM: spmcmahonfedex, smcmahoneiv | 2) Somebody thinks your way is wrong



msg27105/pgp0.pgp
Description: PGP signature

Re: HTML Mail

[Rocco Rutte]

Hi,

* s. keeling [04/13/02 02:10:27 CEST] wrote:
 That's the background.  So in my ~/.mailcap, I tried links %s;
 copiousoutput:

   [-- Autoview using /usr/bin/links '/home/keeling/.mutt/tmp/mutt9aipDt' --]
   [-- Autoview stderr of /usr/bin/links '/home/keeling/.mutt/tmp/mutt9aipDt' --]
   ERROR: could not get terminal size

 This in a real Xterm.  With no auto_view statements in .muttrc,
 _everything_ comes up blah/blah is unsupported. use v ...

Correct  behaviour.   Text-mode  browser   are   _interactive_
programs and thus need a terminal.  If you only want  them  to
print the page and exit (without waiting for user  input)  you
will have to tell them.

 Here's (relevant parts of) my ~/.mailcap:

 text/html;   w3m -cookie %s; copiousoutput; nametemplate=%s.html

Try 'w3m -dump' for autoview.

 # text/html;   /usr/bin/links %s; copiousoutput

Try 'links -dump' for autoview.

 # text/html;   /usr/bin/lynx -force_html %s; needsterminal;

Try 'lynx -dump' for autoview.

HTH,

Cheers, Rocco.



msg27106/pgp0.pgp
Description: PGP signature

Re: HTML Mail

[s. keeling]

On Fri, Apr 12, 2002 at 08:27:21PM -0400, Shawn McMahon wrote:
 begin  s. keeling quotation:
  
  One of the things driving this is I'd like to find a way to easily
  report spam to spamcop, which means I have to pass an ID and password.
  This is possible with lynx -auth=uname:passwd.  With w3m or links, it
  would be something like w3m http://uname:[EMAIL PROTECTED]/
 
 Spamcop will give you an email address.  You forward the mails there,

Actually, that's what I do now.  Submission works great.  I'm talking
about the final bit about getting onto their system, reviewing
spamcop's work, and hitting that last send reports bit.  Spamcop works
great, except lynx tends to be the only browser that works well with
their web server (Opera 5.0 is awful with it; Netscape is better; w3m
would be great, but there's a cookie handling bug; links just hangs
mutt - links can't figure out terminal geometry).

And why didn't the cc: line get filled in with your reply address this
time I did an L?  Excellent!


-- 
Any technology distinguishable from magic is insufficiently advanced.
 TopQuark Software  Serv. Contract programmer, server bum.