--- /dev/null
+Return-Path: <sojkam1@fel.cvut.cz>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 103A96DE19F0\r
+ for <notmuch@notmuchmail.org>; Sat, 2 Jan 2016 13:24:36 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -1.737\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=1.113,\r
+ RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.55] autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id ySoJoGM-bYfj for <notmuch@notmuchmail.org>;\r
+ Sat, 2 Jan 2016 13:24:33 -0800 (PST)\r
+Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 8AB336DE19E9\r
+ for <notmuch@notmuchmail.org>; Sat, 2 Jan 2016 13:24:32 -0800 (PST)\r
+Received: from localhost (unknown [192.168.200.7])\r
+ by max.feld.cvut.cz (Postfix) with ESMTP id A6E4219F48FD;\r
+ Sat, 2 Jan 2016 22:24:31 +0100 (CET)\r
+X-Virus-Scanned: IMAP STYX AMAVIS\r
+Received: from max.feld.cvut.cz ([192.168.200.1])\r
+ by localhost (styx.feld.cvut.cz [192.168.200.7]) (amavisd-new, port 10044)\r
+ with ESMTP id RB3W74fXPKXR; Sat, 2 Jan 2016 22:24:29 +0100 (CET)\r
+Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])\r
+ by max.feld.cvut.cz (Postfix) with ESMTP id AE97319F474E;\r
+ Sat, 2 Jan 2016 22:24:28 +0100 (CET)\r
+Received: from wsh by steelpick.2x.cz with local (Exim 4.86)\r
+ (envelope-from <sojkam1@fel.cvut.cz>)\r
+ id 1aFTf0-0002J7-N3; Sat, 02 Jan 2016 22:24:26 +0100\r
+From: Michal Sojka <sojkam1@fel.cvut.cz>\r
+To: fauno <fauno@kiwwwi.com.ar>, notmuch@notmuchmail.org\r
+Subject: Re: notmuch-mua and jl-encrypt (was: file-error "not a regular file")\r
+In-Reply-To: <87k2nw6n2j.fsf@endefensadelsl.org>\r
+References:\r
+ <CAE+_6Tw18LY954NZt+koH-mn=nniubVdk4tR8TSitDy_6wJB2Q@mail.gmail.com>\r
+ <87wprzb4sj.fsf@endefensadelsl.org> <87ege6d41j.fsf@zancas.localnet>\r
+ <878u4e9jkx.fsf@endefensadelsl.org> <8737ukcm41.fsf@steelpick.2x.cz>\r
+ <87k2nw6n2j.fsf@endefensadelsl.org>\r
+User-Agent: Notmuch/0.21+30~g55c056a (http://notmuchmail.org) Emacs/24.5.1\r
+ (x86_64-pc-linux-gnu)\r
+Date: Sat, 02 Jan 2016 22:24:26 +0100\r
+Message-ID: <871t9zektx.fsf@steelpick.2x.cz>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sat, 02 Jan 2016 21:24:36 -0000\r
+\r
+Hi fauno,\r
+\r
+On Wed, Dec 30 2015, fauno wrote:\r
+> Michal Sojka <sojkam1@fel.cvut.cz> writes:\r
+>> can you share more details about how do you use jl-encrypt and which\r
+>> functions do not work? Recently, I posted a few patches that fix some\r
+>> problems related to the replacing message-mode with\r
+>> notmuch-message-mode. Maybe, there is more what we can do to not break\r
+>> user's setups.\r
+>\r
+> i've been using jl-encrypt unmodified with notmuch for a while now. i\r
+> just require it on my .emacs\r
+>\r
+> since 0.21, i had to rebind notmuch-message-mode C-c C-c and C-s C-s\r
+> keys:\r
+>\r
+> (define-key notmuch-message-mode-map (kbd "C-c C-c") 'jl-message-send-and-exit)\r
+> (define-key notmuch-message-mode-map (kbd "C-c C-s") 'jl-message-send)\r
+>\r
+> and solved the issue of fcc by setting notmuch-fcc-dirs to nil and\r
+> making my mta send me bcc of my own email.\r
+>\r
+> this has worked correctly for the last week.\r
+>\r
+>> From a brief look at jl-encrypt, it seems it is tightly bound to gnus,\r
+>> because it uses gnus-message-setup-hook. Maybe it will work again with\r
+>> notmuch if you use my patch [1] and run\r
+>>\r
+>> (add-hook 'message-setup-hook 'jl-encrypt-if-possible)\r
+>\r
+> i applied your patch to the 0.21 release and byte-compiled notmuch-mua.el\r
+>\r
+> the message is sent unencrypted unless i rebind C-c C-c as before. the\r
+> email is encrypted but it asks for the recipient, which i'm guessing\r
+> emacs can't figure out for itself anymore?\r
+>\r
+> also tested with `emacs -q` and loading this file, and jl-encrypt never\r
+> asks to encrypt the email when possible:\r
+>\r
+> # /tmp/emacs\r
+>\r
+> (require 'notmuch)\r
+> (add-to-list 'load-path "~/.emacs.d/lisp/")\r
+> (require 'jl-encrypt)\r
+> (add-hook 'message-setup-hook 'jl-encrypt-if-possible)\r
+> (add-hook 'message-setup-hook 'mml-secure-message-sign-pgpmime)\r
+>\r
+> by adding the C-c C-c rebind, it gets to encrypt, but asks for recipient\r
+> again.\r
+\r
+I looked into this and I think that the following workaround could work\r
+for you:\r
+\r
+ (defun jl-notmuch-message-send-and-exit (&optional arg)\r
+ (interactive "P")\r
+ (let ((message-fcc-handler-function #'notmuch-fcc-handler))\r
+ (jl-message-send-and-exit arg)))\r
+ \r
+ (defun jl-notmuch-message-send (&optional arg)\r
+ (interactive "P")\r
+ (let ((message-fcc-handler-function #'notmuch-fcc-handler))\r
+ (jl-message-send arg)))\r
+ \r
+ (define-key notmuch-message-mode-map (kbd "C-c C-c") 'jl-notmuch-message-send-and-exit)\r
+ (define-key notmuch-message-mode-map (kbd "C-c C-s") 'jl-notmuch-message-send)\r
+\r
+Unfortunately, I couldn't find a less intrusive solution for now,\r
+because notmuch uses the same "trick" (remapping keyboard shortcuts) as\r
+jl-encrypt to override message sending from message.el. This means that\r
+either jl-encrypt or notmuch can be bound to these keys but not both.\r
+\r
+Notmuch has to use this mechanism until the bug [1] is fixed in Emacs.\r
+\r
+Another possibility would be to introduce something like\r
+notmuch-send-hook which would allow other packages to hook into notmuch\r
+sending process, but this could be even more complex that the above\r
+workaround, so I don't think it is worth the effort.\r
+\r
+Best regards,\r
+-Michal\r
+\r
+[1] http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21174\r
projects / notmuch-archives.git / commitdiff