Re: Displaying HTML mail contents
>But that is as far as I go. The exmh interpreter is good enough >that I can tell if I really need to read the message or not. >If not, I simply don't. If I think I should read it, I send a >reply, informing the sender that I cannot read their message. >If the sender also believes I need to read the message, they >can send it again in a better format. If not, then I was mistaken, >and can simply ignore the message. I admire your commitment to principle, but ... well, I have a serious question: do you interact with the modern world at all? Specifically: do you ever order anything from an online retailer? The vast majority of email I get which doesn't render properly in exmh is not generated by humans, but by some automated system; sometimes it's marketing materials which I can safely ignore, but a lot of the time it IS in response to something I've done or ordered (and it almost always says somewhere something like, "Do not reply to this email, the email address is not monitored"). I don't particularly love this situation, but I don't really see an easy way of getting everyone else to change; it's clear any change has to be done on my end. --Ken ___ Exmh-workers mailing list Exmh-workers@redhat.com https://listman.redhat.com/mailman/listinfo/exmh-workers
Re: Displaying HTML mail contents
Date:Wed, 11 May 2022 21:22:08 -0400 From:Ken Hornstein Message-ID: <20220512012210.97cc5112...@pb-smtp2.pobox.com> | - I set the multipart alterative preference to text/plain first. | - For those messages (or ones that contain only text/html) I fall | back to using the HTML viewer in exmh, I do exactly that as well. | which as we all know is not wonderful. but which also has the advantage that it is less likely to hide information than a "real" HTML interpreter would do. But that is as far as I go. The exmh interpreter is good enough that I can tell if I really need to read the message or not. If not, I simply don't. If I think I should read it, I send a reply, informing the sender that I cannot read their message. If the sender also believes I need to read the message, they can send it again in a better format. If not, then I was mistaken, and can simply ignore the message. Works well enough for me. kre ___ Exmh-workers mailing list Exmh-workers@redhat.com https://listman.redhat.com/mailman/listinfo/exmh-workers
Re: Displaying HTML mail contents
> I was wondering how do you manage to view HTML contents since > nowadays most of our e-mails are written like this. My lame, busted-ass answer: - I set the multipart alterative preference to text/plain first. This helps a fair amount. Not all messages have useful text/plains even when they are multipart. - For those messages (or ones that contain only text/html) I fall back to using the HTML viewer in exmh, which as we all know is not wonderful. - If I still need something better, I use the nmh "show" command which uses w3m to convert the content and that takes care of 95% of my needs. - If that isn't sufficient I save it to a file and then use Firefox on it. --Ken ___ Exmh-workers mailing list Exmh-workers@redhat.com https://listman.redhat.com/mailman/listinfo/exmh-workers
Re: Displaying HTML mail contents
> I was wondering how do you manage to view HTML contents since > nowadays most of our e-mails are written like this. > > Works well for me using '/opt/bin/netscape' as you can see from > the screenshot enclosed. This netscape file is a symbolic link > to /usr/bin/firefox, in fact ;-) [...] > This worked for many years but stopped working with latest ver- > sions of firefox (i.e. 100.0-2.fc36). So I must downgrade to > version 93.0-2.fc35.x86_64 to keep that stuff up & running :-( Mozilla removed support for the old command line syntax for Firefox remote control a while back, so you need to switch to the new syntax. The equivalent command line is: firefox --new-window (The various arguments are covered in the Firefox manual page.) The change in command line syntax wasn't as arbitrary as it sounds, because Mozilla was changing the remote control mechanism as well. As suggested by the old syntax, the old remote control approach was essentially making RPC function calls to the running Firefox. In practice these had not been actual function calls for a long time, so the Firefox remote control code had to pick apart the strings it got to determine what to do. The new approach is more direct, with less pretense going on. (The actual way it works is best not examined too closely, unless you like seeing the sausage being made.) As a side note, in the past you could send a running Firefox (on X) remote control commands from another program, including from another machine. As a practical matter this is now no longer the case; Unix Firefox can now pretty much only be sent remote commands by running Firefox on the same machine. (The technical detail is that on X, Firefox remote control used to work through X properties. Firefox has increasingly been switching to remote control via DBus, which is intrinsically local and which as far as I know, no one has written a program to talk to.) - cks ___ Exmh-workers mailing list Exmh-workers@redhat.com https://listman.redhat.com/mailman/listinfo/exmh-workers
