Re: Unsubscribing from mailing-list threads (was: Preferred way to get imap emails)
On Jul 30, 2019 at 7:40, Matthias Apitz wrote: A solution must be based on some kind of a local "database" file of threads marked as "bad" threads (perhaps as patterns) and one must actively store the given "bad" thread into it, for example with M and then a D would later, even in the next mutt session, read this "database" file and delete all threads from the actual mailbox for all patterns in it. Would it be possible to keep this information in the email by, say, adding a header to it. And have mutt mark any message whose parent contains this header as read. Something like this as a macro or hook (untested): ~h X-Mark-Thread-Read\n An external tool can probably add the header if mutt can't do it. One could also (ab)use the spam detection mechanism spam "X-Mark-Thread-Read" "100/NotInterested" I'm reading this out of the NeoMutt manual, I suppose Mutt has similar functionality. I Cc'ed the author of the article: fa...@ariis.it Please keep him/her in Cc when you reply. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature
Re: format=flowed
On Jan 05, 2019 at 17:02, Ed Blackman wrote: On Wed, Dec 19, 2018 at 11:10:02AM -0800, Will Yardley wrote: Even when people are using the right options in vim and doing everything else right, it seems very fragile and prone to generating invalid flowed emails. I stopped using format=flowed because not much besides Mutt supports it, and particularly not GMail and Outlook. That's interesting. I've been using format=flowed for ages now, never really checked how it looked in other MUA. It worked in Mutt and I was happy with that. Never got any complaints. But when I did use it, I configured vim to use syntax highlighting to add an underline highlight to the trailing space at the end of a line that format=flowed uses to know that it's a line that should be flowed. It was subtle enough to not bother me when composing (since the sentence your composing has a "trailing space" before you start the next word), but blatent enough to see when I'm looking over the message before saving. In ~/.vim/after/syntax/mail.vim, I have: " color trailing spaces to easily see where format=flowed lines will wrap and " not wrap syntax match lineEndWrap / $/ hi WrapLines term=bold,underline cterm=bold,underline gui=bold,underline if &background == "dark" hi WrapLines ctermfg=White ctermbg=Black guifg=Black guibg=White else hi WrapLines ctermfg=Black ctermbg=White guifg=Black guibg=White endif hi def link lineEndWrap WrapLines Vim has built in support for highlighting trailing spaces using `listchars`. I have this in my vimrc. It's also helpful to highlight them in other documents, but I don't want to be distracted while in INSERT mode. set listchars+=trail:· augroup trailing au! au InsertEnter * :set listchars-=trail:· au InsertLeave * :set listchars+=trail:· augroup END In addition, I also do some auto formatting for every email I compose, in `ftplugin/mail.vim`, I have: setlocal formatoptions+=awt " auto-format " pad '>' with a single space keeppatterns keepjumps %s/>\ze\([^> ]\|$\)/> /e " remove spaces between '>' keeppatterns keepjumps %s/> >/>>/ge " remove trailing spaces in header keeppatterns keepjumps 1;/^$/s/ *$//e signature.asc Description: PGP signature
[SPAM?] Re: preview images before attaching
On Sep 05, 2016 at 8:46, Peter P. wrote: I am frequently attaching images to emails in mutt and wonder if there is a way I can preview them when selecting the files, but before actually attaching them. I imagine selecting/entering the path to the file to be attached, but then pressing TAB once more, or using any other keypress, launching eg. imagemagick's display to show the image briefly. I use a combination of vim, the CheckAttach plugin [0] and ranger [1] and w3mimgdisplay. [2] Basically you simply edit your mail, run :AttachFile and select the file in ranger which can show you a preview on the side. [0] https://github.com/vim-scripts/CheckAttach.vim [1] http://nongnu.org/ranger/ [2] https://github.com/ranger/ranger/wiki/Image-Previews signature.asc Description: PGP signature
Re: How does Ian do the "name > " quoting?
On Jan 10, 2016 at 8:11, Cameron Simpson wrote: On 09Jan2016 04:22, David Ellement wrote: On 2016-01-09, Cameron Simpson wrote My current practice is: leave this alone, and use format=flowed ... I'm a vim user, so if you also are I can assist in vim modes to aid format=flowed composition. I highly recommend it! I'm interested; perhaps there are others. If you get multiple responses, could you reply to the list? (Or a link, if the information is available somewhere). There was a long thread back in September 2015 about this. For me the core items are the mutt settings "text_flowed=yes" and the vim setting "set formatoptions=waqj". In more detail: mutt settings: text_flowed=yes, reflow_text=yes, reflow_wrap=-4 I set "editor=vim-flowed" when composing/replying to mail. It is normally just vim, as vim-flowed is hyper annoying if you're not editing email; so it is just vim (well, $EDITOR) even in my mutt settings - only the mail editing phase gets vim-flowed. and vim-flowed is here: https://bitbucket.org/cameron_simpson/css/src/tip/bin/vim-flowed It trims trailing spaces from the headers (I use "edit_headers=yes") and invokes vim with "set formatoptions=waqj". Why not put these settings in `ftplugin/mail.vim` or in a `autocmd FileType mail [..]`? Anyway, these are my mail.vim settings: https://git.rmz.io/dotfiles.git/blob/HEAD:/vim/ftplugin/mail.vim I do a bit more mangling than you.
Re: sending mails readable on small screens
On Nov 30, 2015 at 21:48, Matthias Apitz wrote: El día Monday, November 30, 2015 a las 02:29:30PM -0600, Derek Martin escribió: On Mon, Nov 30, 2015 at 08:03:04PM +0100, Matthias Apitz wrote: No it does not: http://rmz.io/ff.png Can you put it soemwhere where only HTTP is onvolved. SSL claims the page as insecure. No. It only claims that the certificate the server is using is self-signed, meaning that it can't be validated as belonging to anyone in particular by the big certificate trusts. If you're willing to look at it without SSL entirely, then who cares if the cert doesn't validate? This is just not interesting. Maybe for you (Derek Martin) it is not, but for me. It is already an issue if a posted URL of http://... is redirected to some SSL URL of untrusted certifications. I totally agree with Derek, that is why I redirect all my http requests to https. I'd choose encrypted with a so-called "untrusted" self-signed certificate over unencrypted anytime.
Re: sending mails readable on small screens
On Nov 30, 2015 at 22:10, bastian-muttu...@t6l.de wrote: On 30Nov15 15:44 +, Samir Benmendil wrote: On Nov 29, 2015 at 19:42, Matthias Apitz wrote: El d?a Sunday, November 29, 2015 a las 05:55:32PM +0100, Bernard Massot escribi?: I'm struggling to build mails readable on small screens, ie mails whose lines wrap correctly even when there are few columns. I'm indeed thinking of smart phones. I thought format=flowed would be the answer. However the first mailer I tried – K9 mail – doesn't support f=f. I guess Android's native app is no better. So f=f isn't the universal solution. Your mail renders fine in my Ubuntu mobile phone BQ E4.5, in Dekko and in mutt, see the screens: Dekko: http://www.unixarea.de/screenshot20151129_180118205.png mutt: http://www.unixarea.de/screenshot20151129_180302430.png f=f seems to be the esoteric way to tackle that problem. All other users just make sure their terminal is at least 80 chars wide. text/plain is just what it is, plain text. No formating meta data in there. f=f doesn't really have much meta data, just a space at the end of a line that is still part of the same paragraph. No it does not: http://rmz.io/ff.png That screen is approx 65 chars wide/narrow. But also I would not count that as not readable. But it doesn't wrap correctly when there are few columns, which is what Bernard was asking about. And that is the problem with text/plain and textwidth=72, if you have less than 72-80 chars you going to run into those wrapping problems. And on the other hand if you have a very wide terminal and (for some reason) like to read long lines of text, you can't, because the lines are forcefully wrapped for you. With f=f, I can change the textwidth to MY liking and have it formatted properly. https://rmz.io/f=f:reflow_wrap=60.png https://rmz.io/f=f:reflow_wrap=80.png https://rmz.io/f=f:reflow_wrap=120.png (note that I reflow all my replies) You might have better luck with "quoted-printable". "f=f" is much nicer though. To my knowledge quopri is an encoding method. I would not say that could solve the problem here. quopri can encode long lines and is more widely supported. It would flow properly if you write your paragraph onto the same line, and don't add any hard wraps.
Re: Move old messages
On Nov 27, 2015 at 14:41, Jon LaBadie wrote: One thought, if I'm away for a week or more this would archive several days of unread mail. Adding a simple ~R to the pattern seems to eliminate this concern. Are there any side-effects I overlook? folder-hook FreeBSD$ push 'T~R~d> 5d;s/incoming/os/bsd/FreeBSD-OLD I like to keep active threads and important messages as well. I delete all the rest since they are archived somewhere else anyway. Here's my hook: folder-hook inbox push '!~(~U|~F|~d<3m)' This deletes any message that is not part of a thread which contains a message that is `~U`nread, `-F`lagged or `~d`ate < 3 months. signature.asc Description: PGP signature
Re: sending mails readable on small screens
On Nov 29, 2015 at 19:42, Matthias Apitz wrote: El d?a Sunday, November 29, 2015 a las 05:55:32PM +0100, Bernard Massot escribi?: I'm struggling to build mails readable on small screens, ie mails whose lines wrap correctly even when there are few columns. I'm indeed thinking of smart phones. I thought format=flowed would be the answer. However the first mailer I tried – K9 mail – doesn't support f=f. I guess Android's native app is no better. So f=f isn't the universal solution. Your mail renders fine in my Ubuntu mobile phone BQ E4.5, in Dekko and in mutt, see the screens: Dekko: http://www.unixarea.de/screenshot20151129_180118205.png mutt: http://www.unixarea.de/screenshot20151129_180302430.png No it does not: http://rmz.io/ff.png But that is because it was not a f=f message. What do you suggest? It seems HTML is the only widely supported format, which doesn't have line wrapping problems. So should I make Mutt creating automatically an HTML part of a multipart/alternative, using an empty HTML page template and wrapping paragraphs in tags? Is there something more clever to do? No, please no HTML. Indeed, please don't use HTML. You might have better luck with "quoted-printable". "f=f" is much nicer though.
Re: format=flowed
On Sep 18, 2015 at 20:17, Erik Christiansen wrote:
On 18.09.15 10:33, Samir Benmendil wrote:
On Sep 18, 2015 at 19:09, Erik Christiansen wrote:
Now there's no need to hunt around amongst all sorts of files,
wondering where stuff is configured - it's configured in the config
file!
There's a function for that:
| " edit configs {{{2
| function! EditConfig(what)
| let l:dir = split(&runtimepath,',')[0]
| if a:what == 'vimrc'
| let l:file = expand($MYVIMRC)
| elseif ! isdirectory(globpath(l:dir, a:what))
| echoe a:what." is not valid!"
| elseif empty(&filetype)
| echoe 'filetype is empty!'
| else
| let l:file = l:dir.'/'.a:what.'/'.&filetype.'.vim'
| endif
| | execute ':vsplit '.file
| execute ':lcd %:p:h'
| endf
| nmap ev :call EditConfig('vimrc')
| nmap ef :call EditConfig('ftplugin')
| nmap es :call EditConfig('syntax')
| nmap ei :call EditConfig('indent')
| nmap eu :UltiSnipsEdit:lcd %:p:h
This is way simpler than searching for it in the huge monolithic
vimrc.
Samir, your irony gave me a very good belly laugh!
"simpler" was probably not the right choice of word. "easier" is what I
meant to say.
If I want to change filetype specific settings I can hit ef and
I'll get a new split with a small file containing settings only relevant
to the current filetype regardless of what that filetype is.
With folding, the attractively monolithic .vimrc is visually small.
Structure makes everything readily accessible - without any need for
complex functions to get to a swarm of files.
Of course, folding is great, and everything in my vimrc is folded as
well.
Still, you are most welcome to do it your way.
And so are you to disagree with me.
Samir
Re: format=flowed
On Sep 18, 2015 at 19:09, Erik Christiansen wrote:
On 18.09.15 09:47, Christian Brabandt wrote:
On Fr, 18 Sep 2015, Erik Christiansen wrote:
> So, in .vimrc, something vaguely like:
>
> au BufNewFile,BufRead ~/Desktop/mutt-* call Set_for_mutt()
[...]
You don't need that autocommand. Simply create a file
~/.vim/ftplugin/mail.vim and put all mutt related stuff there and add
an entry :filetype plugin to your .vimrc
Thanks Christian, for the alternative implementation, but I don't need
~/.vim/ftplugin/mail.vim when I can equally easily do it in .vimrc.
Keeps your .vimrc cleaner.
Keeping everything vim-related in one config file is _wy_ cleaner.
Cluttering the filesystem with a swarm of files seems untidy, and is a
good way to leave config behind when moving to a new installation/OS
upgrade, I figure.
Not if you have your vim folder under version control.
Now there's no need to hunt around amongst all sorts of files,
wondering where stuff is configured - it's configured in the config
file!
There's a function for that:
| " edit configs {{{2
| function! EditConfig(what)
| let l:dir = split(&runtimepath,',')[0]
| if a:what == 'vimrc'
| let l:file = expand($MYVIMRC)
| elseif ! isdirectory(globpath(l:dir, a:what))
| echoe a:what." is not valid!"
| elseif empty(&filetype)
| echoe 'filetype is empty!'
| else
| let l:file = l:dir.'/'.a:what.'/'.&filetype.'.vim'
| endif
|
| execute ':vsplit '.file
| execute ':lcd %:p:h'
| endf
| nmap ev :call EditConfig('vimrc')
| nmap ef :call EditConfig('ftplugin')
| nmap es :call EditConfig('syntax')
| nmap ei :call EditConfig('indent')
| nmap eu :UltiSnipsEdit:lcd %:p:h
This is way simpler than searching for it in the huge monolithic vimrc.
Re: format=flowed
On Sep 18, 2015 at 17:00, Erik Christiansen wrote: On 18.09.15 10:41, Cameron Simpson wrote: I'm pretty sure the vim mode I'm using doesn't do quoting correctly if I edit the quoted sections. Need to check that on my end. While editing a mutt tmp file, it can be useful to set something like: set formatoptions=qrjl This will not generate f=f messages. You need to 'set fo+=w' so that trailing white space indicate a paragraph continues on the next line. The 'l' stops breaking of long lines in insert mode, allowing "textwidth" to be deliberately exceeded. (YMMV) AFAIC f=f messages should still "hard wrap" at 72 char, so IMO 't' is the better choice. Things are further complicated by receive messages from people not using format=flowed. I probably need to incorporate their quotes differently depending In either case, here, vim (in mutt) manually reflows a paragraph of quoted text to "textwidth", respecting (multiple levels of) quoting, with "gq}". (Mine's automatically set to 72 when I'm in mutt.) 'gq' will also not reflow the paragraph correctly since it doesn't add spaces at the end. You want to use 'J' when 'set fo=a', unfortunately it doesn't take an operator so I use visual selection for that. I just realized that f=f requires that there is no space between '>'s in multi level quotes, i.e. '> > quote' is not a valid 2-level quote, it should be '>> quote' or '>>quote'. I haven't figured out a way to set this up properly in vim.
Re: format=flowed
On Sep 16, 2015 at 7:17, Ian Zimmerman wrote: > On 2015-09-16 12:29 +0100, Samir Benmendil wrote: > > You need to set *reflow_wrap=72*. > I have no such option in my mutt. > > mutt 1.5.21 - the version in Debian wheezy, which lots of us run for > unrelated reasons [1]. That said, I compile it from the source > package anyway, so I will get to upgrading it at some point. Please do. According to the changelog, the f=f handling was fixed a mere two weeks after the 1.5.21 release, *5 years ago*.
Re: format=flowed
On Sep 16, 2015 at 12:41, Cameron Simpson wrote: > On 15Sep2015 19:27, Ian Zimmerman wrote: > > The result is > > similar to what I always get reading plain text messages in Gmail: a > > hard to read mess. If you just had 1 long line per paragraph > > (terminated with a space), it would fold only at 78 and look fine. > > > > Am I still missing something? > My treatment of the quoted material may be wrong (or very > suboptimal); just looking at this message all the quoted > lines lack trailing spaces and I need to investigate that. > My vim setup for this is very crude. > > Could you detail what happens to my message with both the > quoted and actual reply text please? I can reflow your normal body, but the quoted text does not reflow properly. How is this message reflowed? Does the quoted text in this message flow correctly? How about this? On Sep 16, 45BC at 12:41, Cicero wrote: > On Sep 15, 45BC at 12:41, Cicero wrote: > > Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do > > eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim > > ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut > > aliquip ex ea commodo consequat. Duis aute irure dolor in > > reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla > > pariatur. Excepteur sint occaecat cupidatat non proident, sunt in > > culpa qui officia deserunt mollit anim id est laborum. > Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do > eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad > minim veniam, quis nostrud exercitation ullamco laboris nisi ut > aliquip ex ea commodo consequat. Duis aute irure dolor in > reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla > pariatur. Excepteur sint occaecat cupidatat non proident, sunt in > culpa qui officia deserunt mollit anim id est laborum.
Re: format=flowed
On Sep 15, 2015 at 20:11, Ian Zimmerman wrote: > I attach a file which is the paste of how I see your original message > when I set wrap=72 in mutt. You need to set *reflow_wrap=72*.
Change Bcc in reply-hook
Hi mutters, I would like to set the From and the Bcc header in a reply-hook. My relevant muttrc entries are: reply-hook "%L group" source ~/.mutt/accounts/group and in ~/.mutt/accounts/group: set from = "a@a.a" unmy_hdr Bcc: my_hdr Bcc: $from The From header is set correctly, but the Bcc isn't. In the manual I found "that my_hdr commands which modify recipient headers, or the message's subject, don't have any effect on the current message when executed from a send-hook", and read somewhere that this also applies to reply-hooks. Is there any way to get arround this? Basically what I want to do is move mails I send to both the inbox and another folder dependent on the from address. Any ideas? Cheers
