Re: About line-breaks
Cameron Simpson writes: Could someone familiar with mutt's internals comment on this? I believe this is decided by ncurses when it does hard-wrap. I also have this problem when using urxvt+url-select, but it seems some other terminals work around this deficiency. I guess they manually check to see the position of the next character, and whether it appears to link to the last one of the last line. That's just a guess though.
Re: Forcing viewing HTML for certain senders
Cameron Simpson writes: In particular, I maintain a mutt group htmlers to track specific senders which send useless plain text components. Keeps the condition readable. That's a great idea, thanks a lot for bringing that up.
Forcing viewing HTML for certain senders
Is there some way to force viewing HTML for certain senders? I tend to prefer reading plain text over HTML (which I auto_view with w3m), but some senders send stupidly broken e-mails as plain text, and the only reasonable thing to do is view the HTML content instead. For example, some senders use mail software that that consistently just says plain text version unavailable in the plain text version, which is frankly just amazing, but the HTML version they send with it looks fine in w3m, so I'd prefer to view that by default for them. Thanks!
Re: Forcing viewing HTML for certain senders
I eventually worked this out[0]. I had previously tried using a message-hook to set alternative_order, but that didn't work because I didn't realise that alternative_order *appends*, it doesn't overwrite the existing alternative_order. So, the basic solution is to call unalternative_order every time before the message-hook is executed. 0: https://github.com/cdown/dotfiles/commit/c5927d
Disable To/Cc/Subject prompts when replying, but not when creating
Hello, Is there some way to disable the prompts for To/Cc/Subject when replying to a message, but still have them appear when creating a new one? Thanks. :-)
Re: Using $display_filter with $hdr_order
Erik Christiansen writes: Ahh, then another small tweak is required, to display the needed index info in the pager view: set pager_index_lines=6# Local thread view at top of display. Not only does that show 5 index lines, ending with that for the currently paged post, but also the index view status line, so that we have the maillist name at the top, and poster and subject at the bottom. The partial index view highlights the currently paged post, and the local time is displayed without the need to 'i' out and CR back in. Are you still sure that it is necessary to munge mails? ;-) Yes, that's not at all what I'm looking for. Thanks though. pgpRWtK0bko4n.pgp Description: PGP signature
Using $display_filter with $hdr_order
I have a script that replaces the Date header in e-mail with one in my local timezone. This works fine, but it stops hdr_order from working. Without $display_filter set, $hdr_order works fine. When $display_filter is set, $hdr_order stops functioning, and headers are displayed in whatever order they are present in the output of the display filter in. Is there some way to get $display_filter and $hdr_order to cooperate? You can find the display filter I am using attached. I am using the following configuration with Mutt 1.5.23: unhdr_order * hdr_order From: To: Cc: Date: Subject: set display_filter = ~/.config/mutt/filters/local-date Thanks. :-) #!/bin/sh temp=$(mktemp) cat $temp date=$(formail -xDate: $temp) date=$(date -R -d $date) formail -fI Date: $date $temp rm -f $temp pgp01JdnUkTmn.pgp Description: PGP signature
Re: Using $display_filter with $hdr_order
Hi Erik, Erik Christiansen writes: Is it essential to edit received email, or is it enough to just localise the time displayed in the index? Thanks for the suggestion, I already do this. Most of my time is spent iterating through e-mails in the pager view, though, so it's not ideal. For this reason, at least some kind of filtering is necessary for me. :-) pgpW3QghfYgXk.pgp Description: PGP signature
Re: Does mail_check work on IMAP? (Slow checking time)
Grant Edwards writes: I though mutt supported IMAP's IDLE command. That should reduce the latency to well under a second. At least in my experience, IMAP IDLE on mutt results in sporadic lockups (on Google Apps, at least). The only solution I found was to set mail_check and timeout to a low(ish) value. In the end I just downloaded my mail locally and read it from there. pgpP3xkDgNaRf.pgp Description: PGP signature
Mutt output garbled after fullscreen mailcap entry
I use the following entry in my mailcap to view images fullscreen: image/*; sxiv -bf %s This displays images full screen in sxiv. However, this causes me to need to restart mutt afterwards (C-l does not fix it), as the display gets garbled. After I close the fullscreen window, the attachment menu still looks fine. The problems start after I go back into the pager view, which has become shifted up so that around 20 lines of the mail are missing. Going back into the index view results in a totally blank screen, except for the pager status bar, which is somehow sitting around half way up the screen, even though the index status bar is now correctly showing at the bottom of the screen. Pressing j/k to move the cursor between messages results in them being drawn one by one. next-page/previous-page draws most of the index, but has some missing spaces that are just totally black where mails should be. Any ideas? Thanks. pgpxkHV1KwQJ5.pgp Description: PGP signature
Re: Mutt output garbled after fullscreen mailcap entry
Patrick Shanahan writes: !reset should reset the terminal Huh. I didn't think this was a terminal issue, but you're right, that does fix it. Is there a better way to fix this than writing a macro to do that? Where is the underlying cause for this? pgpOTOKuh1a5h.pgp Description: PGP signature
Re: Mutt output garbled after fullscreen mailcap entry
Chris Down writes: Is there a better way to fix this than writing a macro to do that? Where is the underlying cause for this? I changed my mailcap entry to: image/*; sxiv -bf %s \; reset I'm still interested in fixing the underlying cause. pgpGXzDeFpQu0.pgp Description: PGP signature
Displaying non-ASCII attachment names
On 1.5.22, when displaying attachments that are encoded in KOI-8 (and presumably other non-ASCII character encodings), the attachment name in the attach menu is displayed in a quoted-printable format, and is not decoded to the current locale. Is there some way to enable decoding of the attachment filename? pgp0Zi9rtNNP3.pgp Description: PGP signature
Re: Distinguishing Cc'd e-mail from To'd email
On 2014-02-11 16:43:35 +1300, Chris Bannister wrote: I don't know what this has to to with ~p, I'm only responding to the subject with how I distinguish CC'd and To'd mail. I find the status insufficient for quickly identifying the most important e-mails -- only colour seems to be able to do that, which is why I'm asking about how to go about that directly. pgpDjwzKNmjD8.pgp Description: PGP signature
Re: Distinguishing Cc'd e-mail from To'd email
I got an interesting mail from Nikola Petrov off-list saying that his Mutt configuration does not interpret ~p as including Cc'd mails. - In my case, if I limit to ~p, I get messages with the C flag set. - In his case, if he limits to ~p, he (apparently) does not. Is there some configuration option that changes what ~p matches? pgp2c48XLXB5G.pgp Description: PGP signature
Re: Distinguishing Cc'd e-mail from To'd email
On 2014-02-11 00:03:17 +1300, Chris Bannister wrote: On Mon, Feb 10, 2014 at 05:49:55PM +0800, Chris Down wrote: I got an interesting mail from Nikola Petrov off-list saying that his Mutt configuration does not interpret ~p as including Cc'd mails. Wouldn't it be better to keep the mails on list? Could get confusing otherwise. It wasn't me who brought it off list, I generally agree with that sentiment :-) pgpiJq_yJgBSo.pgp Description: PGP signature
Re: Distinguishing Cc'd e-mail from To'd email
On 2014-02-11 00:29:17 +1300, Chris Bannister wrote: In my .muttrc I have: set to_chars= +TCF See table 2.6 in the documentation. How does this affect the behaviour of ~p? As far as I can tell, this only appears to have to do with what is displayed in the status indicator. pgpiuFJtQ2K4R.pgp Description: PGP signature
Re: Distinguishing Cc'd e-mail from To'd email
On 2014-02-09 10:38:25 +0100, Suvayu Ali wrote: Doesn't %Z in index_format or pager_format give you that information? How does that help me to colour it? It is much quicker to read and interpret colors than stuff in the index format. pgpDda8Dv3iSx.pgp Description: PGP signature
Re: Distinguishing Cc'd e-mail from To'd email
On 2014-02-09 22:35:01 -0800, Will Yardley wrote: Given that, you could probably use these two simple patterns, though doesn't look like they can make use of $alternates directly. ~c EXPR messages carbon-copied to EXPR ~t EXPR messages addressed to EXPR I am not sure if putting a complicated expression there would significantly slow down loading the mssage inbox. Right -- but that was the essence of my question, how to populate these without having to manually duplicate the contents of $alternates. pgpurDY_LMyxu.pgp Description: PGP signature
Distinguishing Cc'd e-mail from To'd email
Right now I color my e-mails bright red when they match ~p. This is useful, but it aso highlights when I am Cc'd on a message, and I would like to only have e-mails that have me in the To header to be highlighted. Of course, I can use ~c and ~t, but this doesn't consult alternates (since it requires putting in the expression to match), so it would require me to manually maintain both alternates *and* the list of colored expressions. Is there some way to emulate having ~p only match messages To me without also matching those which are just Cc'd to me without maintaining another copy of my alternates? Thanks. pgpkVdutsxgfX.pgp Description: PGP signature
Re: Header caching
On 2014-01-26 13:49:34 +, Mick wrote: I tried all kinds of caching to make reading imap (on a remote mail server) acceptable and have failed to find a solution for really large mail folders that have tens of thousands of messages. Smaller imap folders are accessed quickly within a couple of seconds or so, but larger folders have always been a problem here, compared say to Kmail or T'bird. I don't know if it is down to caching architecture differences between various mail clients or not yet having tried some configuration that works for mutt, so I would be interested to see if you come across a solution. The only acceptable solution I have found is caching mails offline, but this is still slow for mailboxes with 10 messages. pgpx1kOLtQ9s4.pgp Description: PGP signature
Re: auto reply to html-mails
On 2014-01-23 14:48:34 +1100, Cameron Simpson wrote: BTW, text/enriched? Where does that lovely thing come from? It was defined in RFC 1896. Almost nobody uses it. pgpTs5PG0uWYc.pgp Description: PGP signature
Re: mutt native SMPT support vs Postfix?
On 2014-01-04 20:01:56 +0100, Matthias Apitz wrote: I'm using mutt (right now by typing) on my FreeBSD netbook, connected via UMTS WAN to my ISP. My mutt drops the mail (this mail) to the local MTA (sendmail) and this takes care for the transport to the next MX hop, even if the WAN link is down; the mail gets queued until the link comes up again. I think this, queuing, is a big advantage over talking SMTP directly by mutt. Well, that's exactly what I was recommending -- using something like sendmail over something which is designed for far more (Postfix). I typically don't use my computer when offline, so having a local mail queue would not be a big win for me over occasionally having to save outgoing e-mails to a local file when offline (which has happened about twice in the last two years). pgprWIxXP9cTU.pgp Description: PGP signature
Re: fetching mails to a local folder
On 2013-12-18 13:38:27 +0100, Matthias Apitz wrote: Is there some config example about how to fetch with fetchmail or mutt, some mails (2000) from my IMAP server to a local mbox, but without using a local MTA, as fetchmail normaly does? Or is this even possible with mutt itself (ofc with marking 2000 mails and after this storing them to a local folder); If I understood you correctly, take a look at offlineimap[0], mailsync[1], or isync[2] (disclaimer: I have not used any except for offlineimap, and that was a long time ago). 0: http://offlineimap.org/ 1: http://mailsync.sourceforge.net/ 2: http://isync.sourceforge.net/ pgpXd2Ys82KtU.pgp Description: PGP signature
Re: Setting From according to aliases
On 2013-12-18 13:28:37 +0100, Pau wrote: is this question so silly? I am guessing it is... I don't see anything wrong with your setup, a similar setup works for me. pgpvXB5ZvvkH5.pgp Description: PGP signature
Re: Setting From according to aliases
On 2013-12-18 13:53:47 +0100, Pau wrote: So, if you set alias Chris The Guy Who Replied ch...@chrisdown.name you see Chris The Guy Who Replied in your inbox? That's not the correct syntax. Here is an example entry from my aliases: alias mutt-users Mutt users mutt-users@mutt.org That is, `alias [short name] [replacement]'. pgphSEUoPC48k.pgp Description: PGP signature
Re: Setting From according to aliases
On 2013-12-19 08:18:07 +0100, Pau wrote: Actually, I think that the are not very much relevant. They are required by the spec, I believe (disclaimer: I haven't read the relevant RFC in years, maybe I'm wrong). pgpWmq31E46Zr.pgp Description: PGP signature
Re: Viewing HTML in a real browser
On 2013-12-15 12:32:40 +, Christian Ebert wrote: You can just use it without the --safe option? Right -- my point was about doing it without an external script. For now catting it to a file and opening it in chromium is sufficient, but it has some annoying caveats (charset, unsafe stuff)... thankfully I do this infrequently (and specifically) enough that that isn't really an issue though. Thanks, though. :-) pgp8AsdBy1ZWP.pgp Description: PGP signature
Re: Embedding a photograph within an email message (not attaching)
On 2013-12-16 12:39:47 +1100, m...@raf.org wrote: that's what the content-disposition is supposed to mean but outlook must have its own ideas about such things. it works in thunderbird. Outlook (as with most Microsoft software) is not standards compliant, you should expect it to do strange things at any time. pgpsxFlUj4C7X.pgp Description: PGP signature
Viewing HTML in a real browser
Occasionally I get complex HTML e-mails that don't quite work in w3m (which is what I have in my mailcap to view text/html). In these instances, I would like to be able to somehow view these in my browser. Right now my procedure is this: - Go to attach - Save the html part as /tmp/foo.html - Open my browser - Open file:///tmp/foo.html Is there some way I can automate this better, say, by being able to hit a key and have the HTML part of the message open in the browser? My browser is Chromium, but I think any generic solution should be adaptable. Thanks. pgpDeD1yNLEAM.pgp Description: PGP signature
Re: Viewing HTML in a real browser
On 2013-12-14 07:43:31 -0500, Peter Davis wrote:
If you Google pipe to browser, you'll find various tools that will
do this for you. I use one on the Mac called simply browser, but
there are others. Then in mutt you could simply view the list of parts
('v' command) and pipe the html ('|' command) to one of those.
I think these mostly just do what you're doing ... save the html to a
temp file and open that in the default browser.
Well, this is the macro I currently use:
macro attach B pipe-messagecat /tmp/mutt.html; chromium
/tmp/mutt.htmlenter
That obviously has a race condition, but in practise it's not an issue.
The one thing that annoys me is that I have to go into the attach menu
to select the HTML part to do this. If I pipe from the pager, I might
end up piping the text/plain part (which, in one particular case, says
You need HTML to view this message -- what the?!).
pgpHVXpmRUAqQ.pgp
Description: PGP signature
Re: Viewing HTML in a real browser
On 2013-12-14 18:03:57 -0500, Tim Gray wrote:
I use Christian's script for complex html messages, particularly ones that
have images attached in the email. However, it's a bit slower sometimes
then just opening up the html attachment via mailcap.
Thankfully I only plan to do this in instances where `w3m -dump` doesn't
suffice. :-)
I have two entries in my mailcap, one for viewing in Safari (on OS X)
and one for viewing in mutt via w3m and the copious output setting.
view-attach shows the w3m version in the pager and view-mailcap saves
the html in a temp directory and opens it in Safari, using Eric
Gebhart's view_attachment script.
text/html; /Users/me/bin/view_attachment %s html Safari ;
text/html; /usr/local/bin/w3m -dump %s; copiousoutput; nametemplate=%s.html
I believe since w3m can take input from stdin you don't need to use
nametemplate, and you can do something like the following instead:
text/html; w3m -I %{charset} -T text/html -dump; copiousoutput
pgpqF7OjZ_HM3.pgp
Description: PGP signature
Re: Viewing HTML in a real browser
On 2013-12-14 14:08:35 +, Christian Ebert wrote: Shameless plug: https://bitbucket.org/blacktrash/muttils has a viewhtmlmsg script which can be bound to a key. This looks pretty nice, thanks. Some of the checks it does seem quite useful. Perhaps some of it could be mitigated in-browser instead by using switches to disable unsafe content. pgpoYREwYDuW1.pgp Description: PGP signature
Re: sending encrypted mail to mailinglist
On 2013-12-08 07:05:42 +0100, Remco Rijnders wrote: The existing patches by Dale Woolridge, and made publically available* are patches for mutt to enhance its functionality. They are thus a derivative work. There are arguments that I could imagine one could make about patches as derivative work that would make this appropriate for legal precedent, not a mailing list thread where none of us are lawyers. Either way, I don't think it's appropriate to assert a license without successfully contacting the original author. If it was appropriate, other projects under the GPL would be happy to merge arbitrary changes in with their code without having to have it explicitly released. That's not (generally) the case. Those projects are also the ones with lawyers. pgpTArirvrsaK.pgp Description: PGP signature
Re: sending encrypted mail to mailinglist
On 2013-12-07 21:20:26 +0100, Rejo Zenger wrote: This patch was originaly written by Dale Woolridge for mutt versions 1.5.3 to 1.5.6. Dale Woolridge didn't mention the license under which he released his patch to the public. I have taken the liberty to release this patch under a GPLv2 license. That's not even close to how copyright works (q.v. Berne Convention). Go ask the copyright holder what license it is under, or don't do anything at all. pgpXBVQUTmaOl.pgp Description: PGP signature
Re: sending encrypted mail to mailinglist
On 2013-12-07 22:50:37 +0100, Rejo Zenger wrote: - I have made several attempts to contact Dave before (on the availability of updated patched, not the license), but to no avail. Copyright doesn't even expire on death in most countries. I'd consider uncontactable to be less egregious than dead. - As, I presume, he has made his patches available to the general public with the intention to help others with a similar problem and, I presume, he has no longer interest in maintaining the patches himself, I assumed he would not have a problem in someone else putting an effort in creating an updated version of his patches. Yes, these are just pre- and assumptions. If you wanted to help others, why did you license it under such a restrictive license? If someone used the GPLv2 to license any of my work because I hadn't specified a license, I would be pretty annoyed, because the GPL is awful. - For the same reason I presume he has made the earlier version of his patches available to the general public, I wanted to make the updated version available to the general public. I am aware of all the effort he (and Remco) has put in it, which is why I credited them. Credit does not mitigate copyright violation. - I know how copyright works. Of course. I am aware that there is no room for these afformentioned pre- and assumptions in copyright. So, I just removed the repository from github.com. That's not really what I meant. I am not against doing stuff like this for the public good, but it is a bit ridiculous to assert that the GPLv2 is the correct license for a work with unspecified copyright, don't you think, especially since it is so objectionable? pgpblG_tJWrJZ.pgp Description: PGP signature
Limiting threads based on individual message
Is there some way to limit to a thread based upon an individual message matching? I seem to remember seeing that there was some way to do this, but I don't see any information about it when looking at the pattern modifier documentation. For example: - Message-ID 1 and 2 are part of the same thread; - Message-ID 2 matches a limit pattern; - Message-ID 1 and 2 are displayed as part of the limit, because they are both part of the same thread. Thanks. pgpaSZ3PdouZL.pgp Description: PGP signature
Re: Limiting threads based on individual message
On 2013-12-06 11:23:08 -0700, Chris Down wrote: Is there some way to limit to a thread based upon an individual message matching? I seem to remember seeing that there was some way to do this, but I don't see any information about it when looking at the pattern modifier documentation. For example: - Message-ID 1 and 2 are part of the same thread; - Message-ID 2 matches a limit pattern; - Message-ID 1 and 2 are displayed as part of the limit, because they are both part of the same thread. My luck being what it is, as soon as I switched back to the documentation after writing that mail, I saw ~(PATTERN)... sorry for the noise. pgpVTMwA89Jk2.pgp Description: PGP signature
Re: Attachment signal
On 2013-11-19 10:23:42 +0100, Suvayu Ali wrote:
I use the following as my index_format:
%4C %Z %?X?@ ? %{%b %d} %-15.15n (%?M?ยป%3M%4c?) %s
The @ tells me there is an attachement, and the 4c tells me the size of
the email. I find this works mostly, except from some emails from Apple
Mail. It does not work when the Apple Mail user embeds the attachment
in the email (e.g. pictures). I think the MIME information set by Apple
Mail in this case is just plain wrong.
I tried this, and it caused Mutt to start having to download all message
bodies in the index. Is this expected, or did I do something wrong? If
so, it seems to defeat the point of knowing.
pgpaqvzEIQnB1.pgp
Description: PGP signature
Re: Attachment signal
On 2013-11-19 11:18:28 +0100, LEVAI Daniel wrote: But not to worry! Body caching[1] is might be just what you need :) I cache bodies, but this is a bit irritating since it takes ages to download my non-inbox folders that I haven't viewed for a while over IMAP :-) pgpTbMbuXNsaC.pgp Description: PGP signature
Re: Account-hooks do not work as expected
On 2013-11-16 22:18:10 +0100, Niels Kobschaetzki wrote: I am relatively new to mutt but was able to set up some account-hooks. I have three accounts A, B and C and when I start mutt everything works as expected. I start in account A and when I want to change folders or want to copy mails I see the folders of account A. When I send mail it is send from account A. Now I switch to account B. And everything works for account B, the same for account C. And then I switch back to account A and the following problems occur: When I want to change folders, I see the folders of the last account I was in (in this example account C), when I write a mail the From and SMTP-settings are those from the last account I was in. I also have this problem, I never found a solution. The good thing is that I mostly only use one account, so it's not a major issue. In addition I'd like to ask if there is a way to change the from when I am in the screen right after writing a mail? edit_headers is very useful for this (although you would do the changes in your editor that way). pgpBgD0p4My0g.pgp Description: PGP signature
Re: Yet another 'duplicate' thread
On 2013-11-12 19:22:24 +0100, Jonas Petong wrote:
Today I accidentally copied my mails into the same folder where they had been
stored before (evil keybinding!!!) and now I'm faced with about a 1000 copies
within my inbox. Since those duplicates do not have a unique mail-id, it's
hopeless to filter them with mutts integrated duplicate limiting pattern.
Command 'limit~=' has no effect in my case and deleting them by hand
will take me hours!
I know this question has been (unsuccessfully) asked before. Anyhow is there
is
a way to tag every other mail (literally every nth mail of my inbox-folder)
and
afterwards delete them? I know something about linux-scripting but
unfortunately
I have no clue where to start with and even which script-language to use.
for every file:
read file and put the message-id in a dict in { message-id: [file1,
file2..fileN] } order
for each key in that dict:
delete all filename values except the first
It should not be very complicated to write. If nobody else comes up with
something, I can possibly it for you after work.
pgpfkgvJm0Edy.pgp
Description: PGP signature
Removing the status bar
Is there some way to remove the status bar in the same manner that the help bar
can be removed (with unset help)?
For now, I have got something resembling what I want by setting the background
to the default colour and emptying {status,compose}_format, but this doesn't
free up the used space like unset help does, which is a little irritating.
I'm currently using 1.5.21, but I don't mind using a newer version if it
contains something that helps me achieve this.
Thanks!
pgpiy2BgvCiGu.pgp
Description: PGP signature
