Lewis wrote:
> I'm also aware of two Vim clients on GitHub:
>
> * https://github.com/felipec/notmuch-vim (last commit: 2014-05-22)
>
> * https://github.com/imain/notmuch-vim (last commit: 2015-08-24)
>
> So, are the clients really stable, or are they rotting because nobody
> uses them? My hope
Adds attachment support through the mail gem. Notmuch-Attach headers
list files which are added to the message before sending.
Files are added by constructing a new post-processed transport Mail
object using the Notmuch-Attach header and the original Mail object. Any
attachments added (say by
).
Nick Howell (7):
vim: show: add mailcap filtering
vim: mailcap: forbid access to display server
vim: mailcap: gracefully handle missing mimetype
vim: mailcap: don't corrupt the view if filters write to stderr
vim: mailcap: redraw after processing
vim: mailcap: show all alternatives
Default to prevent mailcap from accessing the display server. Potential
concerns: a malicious .mailcap file + attachment could read your
keystrokes, or if the .mailcap file is non-malicious, an attachment
exploiting a vulnerability in your mailcap viewer.
In principle we should probably try to
---
vim/notmuch.vim | 1 +
1 file changed, 1 insertion(+)
diff --git a/vim/notmuch.vim b/vim/notmuch.vim
index a20dd86..5cb8d20 100644
--- a/vim/notmuch.vim
+++ b/vim/notmuch.vim
@@ -370,6 +370,7 @@ ruby << EOF
VIM::command("syntax region nmShowMsg#{i}Body start='\\%%%il'
).
Probably we should choose a more secure default, e.g. whitelisting
environment variables. It would be nice to recommend the use of a
sandbox.
Changes v1..v2:
- add missing patch "add multipart/alternative picking"
- correct poor conflict resolution in "handle mailcap failure
gr
---
vim/notmuch.vim | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/vim/notmuch.vim b/vim/notmuch.vim
index 89fa2dc..a20dd86 100644
--- a/vim/notmuch.vim
+++ b/vim/notmuch.vim
@@ -347,7 +347,7 @@ ruby << EOF
parts.each do |part|
Add mailcap filters, which allow us to display multiple parts.
See http://packages.debian.org/unstable/net/mime-support for details on
run-mailcap, the mailcap program we default to; the TLDR is that mailcap
is a program which accepts a mimetype argument, looks up a translation
program based on
Default to prevent mailcap from accessing the display server. Potential
concerns: a malicious .mailcap file + attachment could read your
keystrokes, or if the .mailcap file is non-malicious, an attachment
exploiting a vulnerability in your mailcap viewer.
In principle we should probably try to
Display all parts of a multipart/alternative message (or message-part)
if no alternative_preference matches any of the alternative mimetypes.
E.g. if a message is multipart/alternative with options text/plain and
text/html, and the alternative_preference is ['application/pdf'], no
preference
---
vim/notmuch.vim | 1 +
1 file changed, 1 insertion(+)
diff --git a/vim/notmuch.vim b/vim/notmuch.vim
index a20dd86..5cb8d20 100644
--- a/vim/notmuch.vim
+++ b/vim/notmuch.vim
@@ -370,6 +370,7 @@ ruby << EOF
VIM::command("syntax region nmShowMsg#{i}Body start='\\%%%il'
Some plaintext messages do not specify a mimetype. Instead of failing in
this situation, just assume the part is plaintext. (Maybe a better
strategy would be to check if the message contains non-unicode first?)
---
vim/notmuch.vim | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff
Display all parts of a multipart/alternative message (or message-part)
if no alternative_preference matches any of the alternative mimetypes.
E.g. if a message is multipart/alternative with options text/plain and
text/html, and the alternative_preference is ['application/pdf'], no
preference
---
vim/notmuch.vim | 6 ++
1 file changed, 6 insertions(+)
diff --git a/vim/notmuch.vim b/vim/notmuch.vim
index cdcaa5f..79a0e27 100644
--- a/vim/notmuch.vim
+++ b/vim/notmuch.vim
@@ -374,6 +374,12 @@ ruby << EOF
io.each_line do |l|
Nick Howell wrote:
> I have a few patchsets adding:
> - attachment support in compose
> - mailcap support for multipart messages
Mildly clean (imo), independent versions of these have been sent to
the mailing list; they are meant to be applied on-top of felipec's
repository. (I wa
15 matches
Mail list logo