Re: Is linewrap dead?
On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson wrote: > Well, this has been quite the read. > > As a plain text person (aren't we all?) I find poor quality mail clients > annoying, as shown by the motivating screenshot of a plain text hard folder > message presenting on a narrow portrait mode mail reader. > > There seem to two approaches available: `format=flowed` which works well if > the mail reader supports it, and HTML which is a PITA to author for us. > > Having just got my `format=flowed` stuff working again after being broken > for a long time, and have been using some Discourse forums recently (via > email) which accept MarkDown, I've been filled with enthusiasm for MarkDown > email. And markdown's a decent source for basic HTML, since it's authoring > overhead is low and it is very readable in its raw form. > > So I've revisited the manual and found the `$send_multipart_alternative` > option and its friend `$send_multipart_alternative_filter`. They work well! > > So now I have a mechanism to send: `format=flowed` MarkDown with a aparallel > HTML alternative. The HTML should render in a "paragraphy" way for the HTML > people, and the MarkDown keeps me happy. > > My default setting is now: > > set send_multipart_alternative=no > set send_multipart_alternative_filter='echo text/html; echo; exec md2html' > > which is the inactive form, and I've added: > > message-hook . 'set send_multipart_alternative=no' > message-hook '%f htmlees' 'set send_multipart_alternative=no' Oops. That should be =yes above. > which will be turning it on for people in my (empty so far) "htmlees" mutt > group. I use a similar pattern (`%htmlers`) for preserring HTML over plain > text for certain messages. > > The `md2html` script is my personal script, which wraps `pandoc` and post > munges the HTML to indent the code blocks, which `pandoc`'s HTML does not > please my eye. It's here: > https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html > if anyone wants a starting point. > > I'm probably going to bind a key to turn this mode on at some point. > > Cheers, > Cameron Simpson Thanks, Cameron. It's odd that there isn't an md2html program out there already. I had to create one too (using python's markdown module). I like your indenting of code blocks, but it seems to put an additional blank line after each code block. That might not be intentional. And it looks like it doesn't do titles (which default to "-"). I guess that doesn't matter for email use, except that pandoc whinges about it on stderr. Do you have any advice for automating spaces at the end of non-final paragraph lines for format=flowed in vim? Perhaps I could just post-process messages with perl in my mutt-editor wrapper script. cheers, raf
Re: Having problems with POP3 setup
On Sat, Sep 03, 2022 at 05:35:31PM -0500, x...@trimaso.com.mx wrote: > What's the current panorama for POP3 nowadays? Is it still used or is it > dying? I heard Yahoo dropped POP3 support since years ago, except for paid > users... > > Thanks again. I don't think POP will go away entirely. I can't imagine dovecot removing support for it. The entities that would want to abandon POP are ones like Yahoo/Gmail/Microsoft who store their users' emails. I have a mail server on a little VM that some family members use. I wouldn't want to store their emails indefinitely, or be responsible for backups, so they all connect via POP to fetch mail, which they delete a week or two later (to give multiple devices a chance to see everything), and they handle their own backups. But I suppose it could disappear from big mail providers. When there are choices, they can pick a favourite and make a choice on behalf of their users rather than letting their users make their own choices. But this is speculation. I don't really know. cheers, raf
Re: Is linewrap dead?
Well, this has been quite the read. As a plain text person (aren't we all?) I find poor quality mail clients annoying, as shown by the motivating screenshot of a plain text hard folder message presenting on a narrow portrait mode mail reader. There seem to two approaches available: `format=flowed` which works well if the mail reader supports it, and HTML which is a PITA to author for us. Having just got my `format=flowed` stuff working again after being broken for a long time, and have been using some Discourse forums recently (via email) which accept MarkDown, I've been filled with enthusiasm for MarkDown email. And markdown's a decent source for basic HTML, since it's authoring overhead is low and it is very readable in its raw form. So I've revisited the manual and found the `$send_multipart_alternative` option and its friend `$send_multipart_alternative_filter`. They work well! So now I have a mechanism to send: `format=flowed` MarkDown with a aparallel HTML alternative. The HTML should render in a "paragraphy" way for the HTML people, and the MarkDown keeps me happy. My default setting is now: set send_multipart_alternative=no set send_multipart_alternative_filter='echo text/html; echo; exec md2html' which is the inactive form, and I've added: message-hook . 'set send_multipart_alternative=no' message-hook '%f htmlees' 'set send_multipart_alternative=no' which will be turning it on for people in my (empty so far) "htmlees" mutt group. I use a similar pattern (`%htmlers`) for preserring HTML over plain text for certain messages. The `md2html` script is my personal script, which wraps `pandoc` and post munges the HTML to indent the code blocks, which `pandoc`'s HTML does not please my eye. It's here: https://github.com/cameron-simpson/css/blob/main/bin-cs/md2html if anyone wants a starting point. I'm probably going to bind a key to turn this mode on at some point. Cheers, Cameron Simpson
Re: Having problems with POP3 setup
Thanks for all the advice. I did give Getmail a try, and you're right: it has more features. I'd probably try using it for daily use, like Msmtp, if it weren't for 2 issues: ---No STARTTLS support, only SSL: author at the mailing lists seems to not like very much the idea of implementing it. ---Unlike Msmtp, no direct integration with Mutt: it's run like an entirely separated program, no chance of running it from within Mutt since "custom commands" are not supported, not even with macros. Nevertheless, it's remains an interesting option. Now, three final doubts: ---Why isn't there a default binding for the "imap-fetch-mail" function, just like 'G' for POP3? I know I can assign it, but was curious ---If "LAST" command has been deprecated since long ago, is there a reason to still keep it? In the case of Getmail, is it that it actually does not use this command but another implementation? ---What's the current panorama for POP3 nowadays? Is it still used or is it dying? I heard Yahoo dropped POP3 support since years ago, except for paid users... Thanks again. El 2022-09-02 14:32, Sam Kuper escribió: On Fri, Sep 02, 2022 at 01:11:53PM -0500, X Tec wrote: On 2022-08-31 11:46:15, X Tec wrote: On 2022-08-30 18:34:42, Kevin J. McCarthy wrote: On Mon, Aug 29, 2022 at 03:14:21PM -0500, X Tec wrote: Fetching email with 'G' key just ignores the "pop_last=yes" setting because it always downloads all email regardless of locally read or not, even though other clients such as Outlook or Thunderbird don't do this mistake. So I don't think server doesn't support the LAST command... Run with debugging enabled (-d 2) and check the log file to see what the LAST command response is from the server. Since the command was deprecated some time ago, I would venture the server is returning an unknown command error. With debugger I saw this line: "-ERR Unknown command: LAST"; so I think you were right once again... OK, so that's that mystery resolved. Mutt's POP3 support *is* simple, so if LAST isn't supported, the behavior you are seeing with is expected. You may be happier just directly connecting to a pops:// URL via one of your mailboxes instead; or with a more sophisticated tool, such as Getmail (which Sam mentioned). So if I wanted this function, or the one of "keep messages in server for x days", would I need another external POP3 mail fetcher? Yes. There is one caveat. If the POP3 server is totally kooky, then even Getmail or suchlike might be unable to extract the desired behaviour from it. Fortunately, nothing so far seems particularly kooky about the POP3 server in your case. I did read in the Mutt wiki that Mutt originally didn't intend to have native SMTP support, but it ended up (reluctantly?) being added eventually; which is why I decided to learn Msmtp as well. However, I was unable to find any proof of this being the same case for IMAP and POP3, and I searched the whole wiki and docs. So I thought "so unlike SMTP, Mutt has always been supposed to support IMAP and POP3 natively". But then, must I understand that this is *not* the case for POP3? Could someone still help with these issues please? Mutt *does* support POP3, but as Kevin pointed out above, its POP3 support is simple, i.e. basic. If you want a more sophisticated MRA (i.e. POP3 client), then a third-party MRA such as Getmail will likely suit you better. Mutt roughly adheres to the Unix philosophy - "Make each program do one thing well." Mutt is an *amazing* MUA. It does not excel at anything else. (Nor should it.) Yes, Mutt has MRA and MTA capabilities, but these are limited. It is *good* that these capabilities are limited because that keeps the codebase, and the consequent bug surface and attack surface, small. (Purists might argue that Mutt should not have MRA or MTA capabilities at *all* - but for better or worse, the pragmatists who argued Mutt should have limited MRA and MTA capabilities got their way.) So, if you want an *amazing* lightweight MTA to sit alongside Mutt, msmtp is a great choice - and it seems you made that choice. Ace! Similarly, if you want an *amazing* lightweight MRA to sit alongside Mutt, Getmail is a great choice. Good luck, Sam
Re: Re: Is linewrap dead?
Il 03 settembre 2022 alle 12:33 Jan Eden via Mutt-users ha scritto: > While I find this thread quite entertaining, we should accept that we > are an increasingly small group of people who care not just about plain > text email (and its formatting), but about email in general. > > Over at gnupg-users, there was a recent discussion about the Washington > Post's malformed PGP key, and one participant summarized the situation > pretty well: > > "It would be interesting to see how long the key has been there in such a > state. If the answer is “a long time”, that is quite a field report: it > means signal and whatsapp (!) are more popular options (way more popular > options) than PGP + email for secure communications." > (https://lists.gnupg.org/pipermail/gnupg-users/2022-August/066156.html) I smile, that was me. I agree with your point: email use is getting relegated to corporate settings, dealing with banks/utilities, some services (newsletters).
Re: Re: Is linewrap dead?
On 2022-09-03 00:46, Derek Martin wrote: > On Wed, Aug 31, 2022 at 07:45:05PM -0400, John Hawkinson wrote: > > Derek Martin wrote on Wed, 31 Aug 2022 > > at 19:35:15 EDT in <20220831233515.gf13...@bladeshadow.org>: > > > > Evaluating the strength of a SHOULD requires looking at pragmatic > > realities. And that reality is that lots of messages are sent > > without hard line wraps. > > That's true but the vast majority of that is HTML mail, which has > entirely different set of formatting rules and display parameters, and > again, not applicable here. While I find this thread quite entertaining, we should accept that we are an increasingly small group of people who care not just about plain text email (and its formatting), but about email in general. Over at gnupg-users, there was a recent discussion about the Washington Post's malformed PGP key, and one participant summarized the situation pretty well: "It would be interesting to see how long the key has been there in such a state. If the answer is “a long time”, that is quite a field report: it means signal and whatsapp (!) are more popular options (way more popular options) than PGP + email for secure communications." (https://lists.gnupg.org/pipermail/gnupg-users/2022-August/066156.html) This is obviously not limited to *secure* communications (as many people do not care about security). Apologies for the digression. - Jan signature.asc Description: PGP signature
