Re: Is there any way to view text/html inline *only if* we think text/plain is not right?
José María Mateos wrote on Thu, 18 May 2023 at 20:41:49 EDT in : > That works (I have to remove a "bind attach view-mailcap" I have in > my .muttrc), Well, ironically, doesn't that do want you want, almost? I guess it depends on your mailcap. (see below) > but opens the view outside of the pager. Would there be a way to > have that inside the pager, as one would normally get when > prioritizing text/html in alternative_order? You can also hit "m" instead of RET to get view-mailcap which ought to view -- oh, in your case that's set for Firefox. If you want the pager you need to run . That doesn't have a default binding, so you could :exec view-pager but probably you want to bind it to a key. That does require you to have a "copiousoutput" entry in your .mailcap for HTML. I have text/html;w3m -o display_image=0 -T %t; copiousoutput which works well enough. YMMV. > > Or alternatively, you could create a macro to do the same, although I'm not > > sure it's worth the bother? > > A member of the list provided a macro to open the first HTML attachment on > Firefox and I've been > using it for a while. of course, that macro is agnostic as to Firefox. It just opens it in whatever your mailcap specifies. > macro index,pager ,b "/html" > "View first HTML attachment in browser" > > I guess something similar could be done here. Yes, you can search for html with /html instead of hitting . Honestly I'm not sure this happens enough to be worth automating into a macro, teaching your brain to hit 'jj' is pretty easy and arguably a better and more flexible and adaptive solution. But up to you! -- jh...@alum.mit.edu John Hawkinson
Re: Is there any way to view text/html inline *only if* we think text/plain is not right?
José María Mateos wrote on Thu, 18 May 2023
at 19:53:50 EDT in :
> 2. If I'm not convinced by that version, press some key and then text/html is
> displayed inline (using
> w3m, lynx, links, or whatever in the ~/.mailcap file).
Well, some key *sequence* is: 'v', 'j', 'j', RET
assuming that it's a normal multipart/alternative with two parts so two
down-arrows ('j') get you to the 2nd part.
Or alternatively, you could create a macro to do the same, although I'm not
sure it's worth the bother?
--
jh...@alum.mit.edu
John Hawkinson
> I don't know if point 2 is a possibility, to be honest. Does anyone know if
> this can be done?
Re: Re: Forward with attachments
Jan Eden via Mutt-users wrote on Sun, 23 Apr 2023 at 02:42:23 EDT in : > On 2023-04-22 14:58, Akkana Peck wrote: > > > Thanks: I'd also been trying to find a way to forward with > > attachments, and $forward_attachments helps as long as there's no ... > Isn't this what the mime_forward variable is for? Not...really. $mime_forward wraps the entire message in a message/rfc-822 attachment, preserving the full attachment structure. This is great if the recipient can deal with it, and is interested in doing so...sometimes that's not the case. Some MUAs have trouble with them, and others make it just a pain to deal with opening attachments within attachments. (And these problems increase if there is a forwarded message that is then forwarded). I think what is asked for is to flatten the attachment hierarchy and include all attachments as top-level attachments in the forwarded message. This is what, e.g., Gmail will do when forwarding. I sometimes want this behavior when it's more important to get the message across than to forensically preserve the original message. (Although since it often involves HTML, I tend not to use mutt to send those kinds of messages, so I'm not sure I would personally find a mutt feature to do this all that helpful. But that's just me.) -- jh...@alum.mit.edu John Hawkinson
Re: Forward with attachments
Jason wrote on Tue, 18 Apr 2023 at 22:18:55 EDT in <20230419021855.7mdssofxkkngo...@abcmailbox.net>: > I just did. It dumped the plain text file into the new message body > below the original body text. Not what I want, but admittedly it's Tangentially, but relatedly, I sometimes wonder at this. I cannot forget the painful memory of when a person sent me a multimegabyte database file (CSV?) and I hit 'r' and replied and said Thanks without looking at the quoted message, and had no idea that the entire database file was quoted at the bottom of my message. Well, I noticed it was taking a little more time to actually send than normal, and then I was horrified to discover it. I'm not sure whether this suggests this is a default in need of attention or clever heuristics (not that mutt is big on this) or what... -- jh...@alum.mit.edu John Hawkinson > not very often that there would be a plain text attachment.
Re: mark as read
Jon LaBadie wrote on Sun, 2 Oct 2022
at 17:23:17 EDT in :
> Maybe I'm overlooking something. A "mark as read" command
> that works with tagged messages.
You can use the set-flag command (bound to 'w') with atagged group, so:
;wN
to set the 'N' flag on the tagged messages.
And similarly clear-flag ('W') for the opposite situation.
(I don't understand Patrick's reply)
--
jh...@alum.mit.edu
John Hawkinson
> Is there any command that will work with tagged messages to
> mark them as read irrespective of their current status or
> thread status?
Re: Is linewrap dead? Now: Self hosted SMTP
(Replying to Mihai, but keeping Bastian's subject-line change...an operation which Mutt is not great at, but better than most...I dunno what to do with In-Reply-To/References: here, tho.) Mihai Lazarescu wrote on Mon, 12 Sep 2022 at 15:07:37 EDT in : > It took some work to set it up, but that's it. Surely not a mass solution, > yet feasible and stable. ... > Only Microsoft (outlook.com, hotmail.com) seem to filter the whole IP block, > but I am too lazy to ask the > provider to fix or change provider altogether. This is hard to take seriously. Precise numbers are hard come to by, but I think Microsoft is the number 2 hosting provider, globally, after Google/Gmail, and has a substantial market share. Deciding that it's OK to not worry about them suggests a very different attitude toward email reliability and interoperability than most people would choose. -- jh...@alum.mit.edu John Hawkinson
Re: Two doubts about POP3 and IMAP
[ I want to preface this by saying the recent discussions about POP3 that suggest it is a reasonable approach or a viable alternative are quite concerning to me, becauase as a practical matter, my understanding is that basically "nobody should still be using POP3" and it is a moribund and technically inadequate protocol with a lot of problems, and you are much better off figuring whatever is necessary to make IMAP work in your circumstance. But that's not this thread. And also that it's a potentially religious viewpoint and may well be wrong, and I personally have plenty of reasons to be unhappy with IMAP. ] meine's explanation is not satisfactory and does not make sense to me. I think the correct explanation is that under most circumstances, the default timeouts combined with the IMAP IDLE command and IMAP NOTIFY extension make it such that clients should not need to poll IMAP servers for new mail and so a user should not have to initiate such a manual poll. But I think many of us do not live in that reality. I indeed have bind index \` imap-fetch-mail in my .muttrc and I use it with some regularity, although I am not always satisfied with the results. -- jh...@alum.mit.edu John Hawkinson meine wrote on Sun, 11 Sep 2022 at 15:16:11 EDT in : > > 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 > > AFAIK POP3 needs to be triggered with 'G' to fetch newe mails and IMAP > just reads the mailserver for all mails in your boxes. IMAP is to have > all emails from wherever you access the account, so you don't have to > use some fetch command because it is already done at access.
Re: Identifying messages with no To: or CC: headers?
> Could you not prepend your EXPR with something like this? > > `^(Delivered|Envelope)-To:\ ` I belive that you want this to be all-lowercase, because those headers can be any case, and mutt will search case-insensitively per sec. 8.3 of the manual: > As for regular expressions, a lower case string search pattern makes Mutt > perform a case-insensitive search except for IMAP (because for IMAP Mutt > performs server-side searches which don't support case-insensitivity). Of course, you have to lower-case your EXPR (expr?) too. It would be nice if we had a better way to do that. -- jh...@alum.mit.edu John Hawkinson
Re: Is linewrap dead?
Derek Martin wrote on Wed, 31 Aug 2022 at 19:35:15 EDT in <20220831233515.gf13...@bladeshadow.org>: > > I don't really think we're flouting the standards. > ... > So it IS only a recommendation, not a requirement--but it's a pretty > strong recommendation, and either way you're still flouting it. No. Flouting a recommendation in a standard is not flouting the standard. Pleae don't twist my words. (If you want to be pedantic, you may accuse me of flouting a SHOULD recommendation within a standard, and I will admit to it, but I think such a contextless admission misses the point.) 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. Furthermore, if the choice were between standards-compliance and readable emails by more recipients, most of us would choose the pragmatic choice of readable emails. That's not to say we are faced with such a stark choice -- it is far more nuanced and a matter of opinion and individual judgment. Also, RFC5322 is not intended to be a standard that governs what user should do. It's for MTAs and MUAs and other mail software. That, of course, speaks to the nuanced and pragmatic analysis. -- jh...@alum.mit.edu John Hawkinson
Re: Is linewrap dead?
Kurt Hackenberg wrote on Wed, 31 Aug 2022 at 17:22:48 EDT in <2d716370-8c96-adcf-11d4-939a3f808...@panix.com>: > > I don't really think we're flouting the standards. > > Very long lines -- one line per paragraph -- changes the meaning of > ASCII/Unicode. err, what? I am confused what we are discussing. > I could live with that if it were labelled, with a new MIME subtype, but I > agree that a new subtype probably And even more so here. John Hawkinson wrote on Wed, 31 Aug 2022 at 16:38:11 EDT in : > I suppose I should send some 2,000-character paragraph emails as tests to see > what happens, but I very much doubt there will be problems as a result. Anyhow, if I send a 2,000-character line in mutt, it encodes it in quoted-printable. So no standards problem. Can we please move back to...I don't even know. Other suggestions on ways to handle the problem of devices that don't display hard-wrapped text well? I mean, at the moment, the choices are: (a) hard-wrap the lines (b) don't wrap the lines at all (my preference) (c) format=flowed, which works approximately nowhere that (a) doesn't It's a good thing no one is proposing a different set of defaults for mutt. Oh maybe we're discussing how to accomplish these things in vim or Emacs? I dunno, again. -- jh...@alum.mit.edu John Hawkinson
Re: Is linewrap dead?
I don't mean to monopolize the conversation, but: Derek Martin wrote on Wed, 31 Aug 2022 at 15:48:55 EDT in <20220831194855.gc13...@bladeshadow.org>: > I don't see why this matters, because as I already pointed out, any > desktop GUI MUA will have no trouble displaying 72 character lines > wrapped as they are, and any *reasonable* mobile can do the same by > rotating it. (1) I do not agree that it is reasonable to expect mobile users to rotate their screens. (a) I think many won't do it (I don't usually have rotation enabled, for instance, because it leads to nuisance rotation. That means I have to unlock rotation to make it happen, which is annoying.) (b) Even if recipients *do* rotate, they will still have the subconscious/psychological result that "Dealing with Derek's emails takes more work, he is annoying." (2) On desktop GUIs, emails will be readable, but they will look different from most other sender's emails. This again becomes a variant of (1)(b). > > What tends to happen is those people psychologically view > > hard-wrapped 72-char emails as ugly and they become a far less > > effective means of communication than other people's emails are, > > regardless of conscious choice. > > This is unscientific nonsense. [[citation needed]] I think we can all accept that when people have to do more work to accomplish a task for Person A versus Person B, they can come to resent Person A. I'm sure we can dig up social science research on this topic generally, but is it really necessary? > There actually is significant psychological research into the ideal > line length for reading. There's some variation, but the consensus > seems to come in at about 60-75 characters, at a width of roughly > 4-5". Sure, but this assumes a lot of things. It assumes reasonably-formatted columns widths and vieport spaces, etc. It assumes we're not comparing fixed-width fonts to proportional ones and plai ntext versus HTML emails and all kidns of related issues. I very much doubt that these assumptions generally hold. > > As for standards-compliance, that's a red herring. Long lines are > > not going to trip up any modern client, they're just not. > > It may be less relevant today, but it's still relevant. As noted by Kurt, this is up to the MUA to address, and is easily fixed by encoding as quoted-printable. Probably other ways too. > The bottom line is there is absolutely no reason why hard-wrapped > lines of plain text at 72 characters should ever need to display > unreadably for any desktop user, or even anyone on any reasonable > mobile device which can rotate lines parallel to their longer side, Hard disagree. People don't always rotate, shouldn't have to, and will resent it when forced to do so. It may well be that some people aren't bothered, as you posit, but it's certainly not all people, and I would suggest it is not even close to the majority. > that doesn't boil down to the choice of the user. Flouting the > standards is a bad habit to be in. They exist for good reason; if you > choose to abandon them you do so at your own peril, and the rest of us > should not be expected to accommodate you. I don't really think we're flouting the standards. I suppose I should send some 2,000-character paragraph emails as tests to see what happens, but I very much doubt there will be problems as a result. -- jh...@alum.mit.edu John Hawkinson
Re: Is linewrap dead?
Francesco Ariis wrote on Wed, 31 Aug 2022 at 13:57:43 EDT in : > I do not have a smartphone, can I ask someone to provide a .png on > how this or other similar messages look on a smartphone client? I am > very curious and hopefully a definite guideline will pop up from this I sent a previous version of this email with inlined PNG, but of course the list software marked it for moderation. See the image at https://imgur.com/TUfUy82. which shows how your email displayed for me in the Android Gmail app. Note the short lines like "clients my emails" and "provide a .png on". It could certainly be worse (and it often is), but it's not great. -- jh...@alum.mit.edu John Hawkinson
Re: Is linewrap dead?
Derek Martin wrote on Wed, 31 Aug 2022 at 13:39:42 EDT in <20220831173942.gb13...@bladeshadow.org>: > It's been my experience that if you read your mail on anything other > than a phone, the 72-character line width is fine, and even on a phone > if you turn it sideways it's still fine. My preferred solution, then, > has been to stick with following the standards and assume that if you > insist on reading mail on a hand-held device that can't accommodate > the standard, and/or refuse to rotate it so that it can, then you get > what you get, it's your choice and the consequences of your choice are > on you. That'd be true if we were sending emails to ourselves, but a lot of us send email to people who read their mail primarily or exclusively on phones and in desktop GUIs that don't approximate 72-chars. What tends to happen is those people psychologically view hard-wrapped 72-char emails as ugly and they become a far less effective means of communication than other people's emails are, regardless of conscious choice. It's great if you can choose the people who read your emails, but most of us are not so fortunate. As for standards-compliance, that's a red herring. Long lines are not going to trip up any modern client, they're just not. -- jh...@alum.mit.edu John Hawkinson
Re: Is linewrap dead?
Kurt Hackenberg wrote on Mon, 29 Aug 2022 at 02:58:32 EDT in
:
> If you put a newline only at the end of a paragraph, it won't be displayed
> correctly by software that doesn't expect that. Such software will probably
> either break each line exactly at the right margin, maybe in the middle of a
> word, or display a paragraph as a single very long line, maybe with a scroll
> bar.
THe point of my statement is to say that this is not a problem in practice, no.
One of the problems with email is there are so many different clients out there
that run on so many differnet devices and are configurable in so many different
ways that it's not possible to make any kind of absolute statement ("this
always works") beyond statements about standards conformance, which have to be
tempered with pragmatic reality. And furthermore it's quite different with
different cultural groups; there are some people ("this business world") that
only use some kinds of clients, and others (err...the elite hacker world? ha
ha) who only use some other kinds, and sometimes these groups don't
intercommunicate enough for there to be an awareness of how the others operate.
One example of this is the whole "don't top post / replies inline" versus "ONLY
top-post here!" -type debates, where both sides are entirely ignorant of the
merits of the other's positions.
But I can confidently say that after years of doing this, omitting newlines
from internal line breaks in paragraphs has proved to be a much better
compromise than including them. It displays much better in a wide array of
clients, especially modern ones (webmail clients, mobile clients), and is not
particularly problematic in classical clients (like mutt).
[ I think, also, that without doing a survey of a wide variety of readers, it's
tough to appreciate the scope of this problem. I had NO IDEA how bad my
hard-wrapped emails used to format for people using clients like Outlook until
I looked into it explicitly. People just don't tend to talk about things like
that unless you press them. Although they do make value judgements ("XYZ's
emails are hard to read.") ]
(This email reminds me that a derivative question is how to handle quoted text.
I usually continue to wrap quoted text at 72 chars with hard line breaks, as
I've done in this message. I don't worry too much about quoted text being
inconveniently formatted in readers that deal with multiple screen sizes,
although maybe I should.
> One solution would be to invent a new MIME type, say text/paragraph, for
This is obviously a non-starter when the goal is to interoperate with today's
technology as much as possible.
> Maybe text/plain format=flowed is a solution. It's displayed correctly by
Maybe.
--
jh...@alum.mit.edu
John Hawkinson
> software that assumes format=fixed (on a screen that's wide enough), and at
> any width by software that understands format=flowed. Mutt can display
> format=flowed correctly at any width, if it's configured to.
>
> Do phone mail readers understand text/plain format=flowed?
Re: Is linewrap dead?
I gave up on linewrapping emails I transmit several years ago for the reasons you describe, and it has been the right decision. I have not shaken the feeling that maybe I should learn how to compose format=flowed messages, but I guess it's not worth the trouble -- or at least I never managed to get it to work right. And yes, I toggle M-x visual-line-mode in Emacs while composing, sometimes multiple times, which simulates how the email may be read. -- jh...@alum.mit.edu John Hawkinson Tavis Ormandy wrote on Sun, 28 Aug 2022 at 20:28:29 EDT in : > Hello, long time mutt user here - I've always hard wrapped my lines at > 72 columns for as long as I can remember. > > The problem is popular modern mobile and web-based MUAs don't handle > this and can make unexpected linewrap decisions. It's no issue when > emailing UNIX nerds, but non-nerds think I'm doing something wrong. > > I've seen people convincingly argue it's time to abandon `tw=72` and > never wrap lines manually - newlines are for when you want a new > paragraph. > > I've tested, and this does look a lot better on Android for example... > but it just feels and looks wrong! What's the general concensus on this > issue? > > I find it so weird for my lines not to soft-wrap in a big xterm that > I had to make a vim macro to "fake" wrap them while composing :)
Re: muttrc file for aol.com email?
On Mon, Dec 20, 2021 at 4:33 AM D.J.J. Ring, Jr. wrote: > I just heard gmail was going to become not compatible with mutt. How dare > they? This is a prett ystrong claim, and it is going to cause a lot of consternation and panic, whether it turns out to be true or mistaken. Can you please share some more information so we can figure out how to address it and how concerned to be? Is there supporting information? Is it a rumor? If rumor, what's the provenance? Heard from a friend-of-a-friend-of-a-friend? From a reliable source you can explain, etc? Thank you. -- jh...@alum.mit.edu John Hawkinson
Re: Search program that can find an E-Mail with an exact Date: match
I find this discussion a bit…surprising? It seems like "mboxgrep" (https://datatipp.se/mboxgrep/) does this just fine. E.g. mboxgrep -rH -m maildir 'Date: Sun, 17 Mar 2019 21:24:26 -0700' dir recursively searches the headers of all mailboxes within 'dir' for the pattern specified. I don't know that "-m maildir" is necessary, but it works. And if you don't have mboxgrep or don't feel like installing it (e.g. for a one-off), just plain old grep will get you 90% of the way there, assuming you can tolerate a few false positives if there are email messages that happen to have that same date string in their bodies (e.g. quoting messages): fgrep -r 'Date: Sun, 17 Mar 2019 21:24:26 -0700' dir And of course you could add a ^ to the front and make it a regexp (and add -G in the case of mboxgrep, or switch to grep from fgrep). Oh, you ask: > I can grep for the E-Mail but then I'm left with the issue of > extracting the body/text which is what I actually want. Can I > 'pipe' the mailbox (found by grep) into mutt and then get the > output on stdout, that's what I'd need. Well, you can just use grep to determine which file contains what you want, and direct mutt to that particular mailbox file. It does not, to me, seem like this is either "odd" or a "corner case." This is searching for a particular header in a set of messages, that should not be a rare requirement, although of course many people never do it. It is also, however, out of scope for mutt — mutt isn't a tool for searching multiple mailboxes. Perhaps there's a better mailing list for this sort of question? -- jh...@alum.mit.edu John Hawkinson > Chris Green writes: > > > I'm looking for a way to find (and display) an E-Mail when I know > > the exact value of the Date: header. > > The 'usual' search programs such as Mairix can't do this as they > > all expect a date range and also expect it to be at least a day > > long. > > I've also tried grepmail but that seems not to be able to search > > maildir E-Mails. > > > > Is there anything out there that can do this? > > I can grep for the E-Mail but then I'm left with the issue of > > extracting the body/text which is what I actually want. Can I > > 'pipe' the mailbox (found by grep) into mutt and then get the > > output on stdout, that's what I'd need.
Re: question/suggestion
Derek Martin wrote on Mon, 25 Oct 2021 at 19:00:12 EDT in <20211025230012.gc9...@bladeshadow.org>: > Cost? I see no cost, other than the time needed to physically check My Oct. 7 email, to which you replied, enumerated several costs that I perceived. That you go on to state that you perceive no costs, without addressing the costs explicitly raised by others, makes your email seem disingenuous. I'm not sure what to make of it. Reasonable people can disagree as to whether a particular cost is significant or not, but you seem to be doing something else. I'm not clear if there the proposal on the floor is the initial one to add Fw:, or the subsequent one to "conform" to Gmail and Outlook by removing the email address,as well as adding Fw/Fwd. The discussion we had, such as it was, was not particularly clear aobut which of those cases it was responsive to. To add something new without repating my prior comments: I find value in having the address of originator of the forwarded message appear in the Subject line, because it makes clear, deep into an ensuing thread, that "we're talking about [Steve]'s message." YMMV on that pro, of course, as it may with all. > In the context of a subject line, a leading "fwd" (regardless of > case) is very unlikely to be confused with anything else, due to > ubiquity of the convention. Confusion seems a red herring. No one has credibly suggested that any of the options, current or extent, proposed or in use, are confusing to anyone at all. -- jh...@alum.mit.edu John Hawkinson
Re: question/suggestion
ಚಿರಾಗ್ ನಟರಾಜ್ wrote on Thu, 7 Oct 2021
at 23:32:00 EDT in :
> Any email client (including mobile email clients) worth its salt is
> going to wrap the subject line (at least in the email view, if not
> in the index view), so that shouldn't really be an issue, right?
My principal concern is with the index view. And none of the 4 email clients I
use wrap the index view (mutt, Gmail web, Gmail mobile, Outlook web), nor would
I want them to (because then they'd be taking too much vertical real estate,
too).
> That's true. However, convention is *also* important,
Unsupported argument.
> and Mutt's convention is...unconventional.
Not particularly.
It's not Outlook's and it's not Gmail's, so it's not the market leader, but its
difference is not particularly confusing or difficult to understand.
> Most email systems usually use FW: at the beginning to indicate that
> the email has been forwarded (if I'm not mistaken).
No, if we're going to be pedantic.
And "not quite" if we are going to be flexible on case sensitivity.
Outlook uses "Fw: ", and Gmail uses "Fwd: ".
Between them I think they dominate the market ("most email systems").
> Why shouldn't Mutt do the same?
We should do the best we can, and if there is a situation where there is strong
value in conformance, we should consider the costs and benefits to conforming.
Here, I haven't seen any meaningful argument beyond the idea that the current
behavor might be confusing. But I've never heard of anyone being confused by
it, and my experience is that nobody is confused. You haven't even suggested
that you have found a single person to be confused (and I think we'd need a lot
more than one example).
Indeed, even were there confusion, it would be fleeting, because it's obvious
what's going on upon viewing the context of the message, regardless of whether
the "Forwarded message" text is present (as it is when mime_forward is unset).
If some people were confused, then we'd have to evaluate the seriousness of
that confusion against the costs of change. Line length is one cost I
articulaed. Another is that absolutely any change has a cost, and causes people
to have to figure out how to get used to it. That's mostly a one-time cost and
sometimes it's easy to argue it's worth it for the greater good, but that's a
tough argument to make here.
But of course you're free to set your own configuration. Or we could include a
sample commented line in the muttrc labelled "# Make forwarding look like
Outlook's" or whatever. But I think a much more compelling case is required to
change the default.
Of course, others may disagree.
--
jh...@alum.mit.edu
John Hawkinson
Re: question/suggestion
I'd object to the proposal to add the "FW: " characters to the default. Space is at a premium in modern Subject lines, especially with the prevalence of mobile devices that have limited screen real estate, and cutting out 3 characters is very undesirable. I think it's pretty clear from context that an email address followed by a colon is indicative of forwarding — email addresses are identities and an identity prefixing something else (such as here, a Subject line), has good affordances for associating that identity with what follows, and that's the essence of what forwarding is. Indeed, I sometimes wonder if we'd be better off without the leading "[", but I haven't brought myself to try to save that single character. -- jh...@alum.mit.edu John Hawkinson On Thu, Oct 7, 2021 at 10:24 PM ಚಿರಾಗ್ ನಟರಾಜ್ wrote: > 12021/06/39 09:27.23 ನಲ್ಲಿ, Globe Trotter via Mutt-users < > mutt-users@mutt.org> ಬರೆದರು: > > When I foward my mutt-composed email, I have something like the > following, which I believe is the default behaviour: > > > > [mutt-users@mutt.org: Email subject] > > > > which I think is very nice because it gives the recipient an idea of > whether the originator of this email is someone s/he should even bother > reading from. > > > > However, most e-mailers are not mutt, so most people probably have no > idea what this means. > > > > May I suggest the following default that clarifies better what is going > on, or something like that, in the subject line? > > > > [FW: from mutt-users@mutt.org: Email subject] > > > > Thoughts? > > > > Thanks a bunch! > > > > GT. > > > > Ooh, that gets an upvote from me (I'm also going to go set that variable > in my config...even though I don't forward many emails, it's useful to have > it set when I do). > > - Chiraag > -- > ಚಿರಾಗ್ ನಟರಾಜ್ > Pronouns: he/him/his >
Re: How to execute command (as opposed to function) from the command prompt
Chris Green wrote on Tue, 29 Jun 2021 at 13:31:49 EDT in : > How do you execute a *command* from the mutt command prompt? > > So, for example, having hit : to get to the command prompt how can I > do to show/hide the sidebar? :exec sidebar-toggle-visible -- jh...@alum.mit.edu John Hawkinson
Re: Using UTC time in Date header
Gregory Anders wrote on Fri, 14 May 2021 at 21:57:04 EDT in : > I don't mean to invalidate your opinion, but I don't think using UTC > universally is actually all that bad. Each individual person just needs to That may be nice for you, but most of the non-software-engineering normal humans I exchange email with are not capable of doing any timeone math whatsoever, much less the next zone over. UTC is right out. This is especially the case for those who tend to use Exchange, which curiously offers these UTC defaults, I guess on the assumption that everyone's mail clients will convert everything to local time. To put it different, it's not so much that I don't want to the timezone math (although I don't really), it's that I am confident that the people I deal with do not. I'm sure your experience may be different, but those are my requirements. -- jh...@alum.mit.edu John Hawkinson
Re: Using UTC time in Date header
For what it's worth, I have a desire for the opposite kind of feature, although
I don't quite know how it should work.
I want to see and use timezones as displayed in messages as long as they are
nearby US timezones that my brain is facile with the trivial arithmetic for
(i.e. US/Eastern, US/Central, US/Pacific, and I suppose the rare US/Mountain).
But when a header comes in UTC, I'd much rather convert it to local time,
especially so I don't have to think about how DST affects the offset.
But also this is an issue for attributions. When I reply to someone, I want the
attribution to properly reflect the time in a zone they understand, because I
assume other humans can't easily do timezone math. As long as their client used
their local zone, this works great.
But more and more Exchange/Outlook/whatever are using UTC, and that means the
times in attributions echoed back to them are too hard.
A while back I gave up and converted from %{%a, %e %b %Y} to %[%a, %e %b %Y].
I don't love this, but it seems to work better.
I don't really know what to suggest, though. It's hard to think of a good
heuristic that would be worth coding up in C.
I suppose if mutt were extensible in lua or lisp or whatever, I could easily
write my own function that handled the US timezones differently from other
ones, and that would solve most of my problems.
Anyhow, this email isn't really intended to be actionable in any way, but I
thought it was worth talking about the problem, perhaps as a way to inform...I
don't know what, perhaps future development, but probably not.
Thanks for listening.
--
jh...@alum.mit.edu
John Hawkinson
Re: Deleting Attachments from Index View
The IMAP FETCH command allegedly supports retrieving individual sections of a message, including the headers and parsed sections of the body based on MIME parts. I have no idea what the support for this feature is like. -- jh...@alum.mit.edu John Hawkinson
Re: mutt and gmail
Jude, I find your email puzzling. I don't believe there've been any recent outages of Gmail's IMAP service, i.e. nothing that would prevent mutt from connecting to Gmail and retrieving mail. Can you be more clear about what problem are trying to address, and how you might solve it? There was a recent outage Gmail outage that prevented Gmail's SMTP inbound servers from receiving email to Gmail users, and cause that mail to bounce. See, variously: Hacker News https://news.ycombinator.com/item?id=25436062 Google's app dashboard https://www.google.com/appsstatus#hl=en=issue=1=a8b67908fadee664c68c240ff9f529ab Google's alleged "incident report" http://www.google.com/appsstatus/ir/4et50yp2ckm8otv.pdf (linked from the dashboard). You can also monitor Google's appstatus dashboard via RSS at https://www.google.com/appsstatus/rss/en -- jh...@alum.mit.edu John Hawkinson Jude DaShiell wrote on Sun, 20 Dec 2020 at 16:49:57 EST in : > Given gmail isn't always available these days for whatever reason(s) I'm > wondering how best to regularly monitor gmail servers so users would know > if the servers are alive when they use mutt to connect and do mail > transactions. Probably putting something into mutt would not be feasible. > I don't know if any other light-weight command line solutions for this > type of monitoring are already available since I've had no occasion to do > it yet. > > When people state they cannot recieve email with a stable version of mutt > and it not being all that long ago gmail was down and that got on the news > an ability to monitor services would seem to be useful. The gmail > monitoring should only be attempted once it's established a network > connection exists since if you haven't got a network certainly no service > on the network will work.
Re: is it possible to set bcc
Setting Bcc and using record have different functions, and although there is a lot of overlap, the former tells you something about the mail delivery infrastructure. I use my_hdr Bcc: jh...@alum.mit.edu to set bcc unconditionally, without a hook. -- jh...@alum.mit.edu John Hawkinson Remco Rijnders wrote on Fri, 23 Oct 2020 at 11:37:56 EDT in : > On Fri, Oct 23, 2020 at 03:31:49PM +, Globe wrote in > : > > > I want to set bcc to my address for every e-mail I send from an > > account. How do I do that? Do I define a hook? > > You could use a hook for it, but it might be simpler to use the record > functionality. See http://www.mutt.org/doc/manual/#record for how to > automatically save a copy of every outgoing message to a folder of > your choice.
Toggling between two values of a string variable?
I feel like this is a silly question, but here goes: I've recently found myself toggling back and forth the "postponed" variable to deal with either postponing messages locally (no network dependancy!) or dealing with postponed messages in a remote IMAP mailbox for collaboration with a mobile client (e.g. Gmail's Drafts folder). Experience has shown there is no one right answer, I need to use one definition of postponed sometimes, and one the other. Ideally I'd like to bind a key to toggle between two values of a string variable. There doesn't seem to be a good way to accomplish this -- is there a trick? As an alternative, I (notionally) bound ,a to :set postponed to one value, and ,b to :set it to another. I do not love this. Both display the result (:set ?postponed\n) so I can at least see what I've done. I realize on some level this is plea for macro/scripting language with true conditionals, and we're not going to get there anytime soon. The last time I had a problem of this nature in mutt I bound the macro to ! execute a perl script that did its thing and then made use of the fact that mutt was running under screen(1) and used screen's "slowpaste" to tell mutt to :source a temporary file that redefined things as desired. Since my mutt isn't running under screen anymore (although I suppose I could), this approach doesn't work, and it was pretty janky anyhow. I guess it's collateral, but I was surprised that I couldn't get :toggle to work with a $my_foo variable. I guess it would not really have helped me make progress, but seemed like it could be a building block in some more complex scheme. Thanks for any thoughts. -- jh...@alum.mit.edu John Hawkinson
Re: Going GUI...er
disclaimer: I have not reviewed this thread in its entirety. Grant Edwards wrote on Sat, 2 May 2020 at 12:16:45 EDT in : > _Nobody_ I work with uses an email client that properly displays > plaintext as sent by mutt. ... > Most of my family and friends do almost all of their e-mail on phones. > Plaintext is very hard to read on small screans because it doesn't > re-flow to fit the screen width. Forcing people to read plaintext on > small screens is, IMO, inconsiderate. This is not an attribute of mutt or plaintext. It is an attribute of plaintext with a particular kind of fixed line breaks. Personally, I send mail via mutt and do not place hard line breaks at the end of each line, but effectively send every paragraph as a single very long line. (I often compose using Emacs' M-x visual-line-mode.) I think this is not as good as proper format/flowed, but there seem to be technical difficulties making that work reliably, so it's an OK substitute. > Insisting that the world switch from HTML to plaintext for e-mail is > just tilting at a windmill. I think this view is correct. -- jh...@alum.mit.edu John Hawkinson
Re: format=flowed
Only tangentially relevant, I spent a while trying to get format=flowed to work effectively a year or so ago and couldn't easily do so (perhaps I was testing against Gmail, I don't recall), and ended up just converting to sending messages with no line-breaks at all within each paragraph. Like this. I'm not particular proud of this, and it's incompatible with quoting, so I put hard line breaks when I quote text, and it's somewhat annoying to compose (I use emacs' M-x visual-line-mode to do so), but it certainly wraps properly in most clients. --jh...@mit.edu John Hawkinson
Re: Mutt -> Compose -> Some kind of alert?
> When replying to some certain emails, I > usually have to add other recipients to > the list. But unfortunately, I often > forget to do so. I suggest you set edit_headers such that the recipient fields are available while you are editing the message. I do also have a macro: macro index ,h ":toggle edit_headers\n:set ?edit_headers\n" "toggle edit_headers" So I can turn on and off header-editing, although I'm struggling to remember why that's useful thing to do...I almost always have it on. Maybe when replying to messages with hundreds or thousands of recipients... --jh...@mit.edu John Hawkinson
Re: [Mutt] Exceptions to ~p based on From:?
Mihai Lazarescu wrote on Sun, 23 Sep 2018 at 11:50:01 +0200 in <20180923095001.ga19...@mtl.m.lazarescu.org>: > If non-mutt solutions are acceptable, I'd change u...@domain.name to > user-j...@domain.name in some procmail rule(s). Thanks, Mihai. I'm loathe to reject all non-mutt solutions, but I don't have a practical way to run procmail (or anything else) before messages are delivered to the IMAP server. So no that doesn't work for me. (I think, also, that I'd not be really comfortable with the idea of modifying the headers[*] that come on a message. Adding headers seems fine, but modifying the existing ones seems like a line that shouldn't be crossed. In a world where we have DKIM, it seems an especially bad idea, although I don't know if DKIM tends to include the To: header in its crypto hashes). --jh...@mit.edu John Hawkinson [*] I will say I've given serious thought to modifying the Date: field for messages that express the date in UTC that are sent by people who are in substantially on-UTC timezones, like US/Eastern, so I can't say I'm as much of an absolutist on this point as my words might suggest
Exceptions to ~p based on From:?
Hi, mutt-users: I sent a work-in-progress patch to mutt-dev about this, but Kevin asked me to take it up here first. I'm a big user of limiting my index to only personal messages (limit to "%p", or MUTT_PERSONAL_RECIP in the source). See http://lists.mutt.org/pipermail/mutt-dev/Week-of-Mon-20180917/000232.html Although this used to work pretty well, more and more the modern mailing list paradigm (e.g. Mailchimp lists, etc.) is to have bulk or list messages that are indistinguishable from personal mail, e.g.: From: "NYTimes.com" To: u...@domain.name Subject: Today's Headlines: Rod Rosenstein Suggested Secretly Recording Trump and of course this shows up in ~p, which is not desirable. Most of the time, I can get around this by changing the subscription address to someting else, e.g.: From: "NYTimes.com" To: user-j...@domain.name Subject: Today's Headlines: Rod Rosenstein Suggested Secretly Recording Trump However, there are some lists where that is impractical, and the only way to clearly identify them is with the From: line. I'd like messages to those lists excluded from ~p. My patch, which I know is clearly wrong, searches the From: of each message against the "unalternates" exclusion list, and so I can exclude the relevant list from the pattern, and ~p works. But this is a misuse of "unalternates," which is supposed to be used to match against recipient fields (To:, Cc:). Does anyone have suggestions or workflows for accomplishing this? Kevin points out I could shift gears and adjust what I limit to, such as putting the problematic senders in an address group and limiting to "~p !%f mylists". That...sort of works, but also is really impractical for me, becuse I often type limiting patterns and going from 2 keystrokes to 10 (or 8, if it was one-letter group) is not pleasant. And although I could use a macro, I also regularly use ~p in more complicated patterns, so a macro would only help with the simplest of them that are easily repeatable. How do others approach this problem? Does anyone else think that mutt should have a better solution, like a way to exclude messages from ~p based on their From: field? If so what would that llok like, and how should it interact with lists and subscribedlists, if at all? Thanks. --jh...@mit.edu John Hawkinson
