[PATCH v2] emacs: Added "is:" style completion to notmuch-read-query.
Charles Celerier writes: > Can the variables in the varlist depend on the definition of variables > that precede them in the list? I believe I tried your suggestion, but > quickly gave up as Emacs gave me an error claiming that all-tags was > void. That's the point of lexical-let* vs lexical-let d
[PATCH v2] emacs: Added "is:" style completion to notmuch-read-query.
Charles Celerier writes: > Can the variables in the varlist depend on the definition of variables > that precede them in the list? I believe I tried your suggestion, but > quickly gave up as Emacs gave me an error claiming that all-tags was > void. Yes, with the let*/lexical-let* variants of let/lexical-let. This is stated in the let* documentation (that is, C-h f let* RET). ciao, lele. -- nickname: Lele Gaifax | Quando vivr? di quello che ho pensato ieri real: Emanuele Gaifas | comincer? ad aver paura di chi mi copia. lele at metapensiero.it | -- Fortunato Depero, 1929.
Exchange mutilation of multipart/encrypted
My employer uses an Exchange server in place of an MTA. It mutilates multipart/encrypted messages, so that when I receive a PGP/MIME message the Emacs-notmuch interface shows me: [ multipart/mixed ] [ text/plain ] [ ATT2: application/pgp-encrypted ] [ msg.asc: application/octet-stream ] When I used Gnus heavily, I wrote a little program to un-mutilate PGP/MIME mail: ~~~ (defun repair-multipart-encrypted (article) "Switch a multipart/mixed header to multipart/encrypted. This helps cope with broken Exchange servers." (interactive (list (gnus-summary-article-number))) (gnus-with-article article (message-narrow-to-head) (goto-char (point-min)) (search-forward "Content-Type") (search-forward "mixed") (replace-match "encrypted; protocol=\"application/pgp-encrypted\"" t t) (widen)) (let (gnus-mark-article-hook) (gnus-summary-select-article t t nil article))) ~~~ I'd love to have a way to tell Emacs-notmuch to treat a part as of a different type, and provide parameters. Alternately, I'd be happy to edit the file on disk and have it re-indexed---but that seems likely to cause me regret. Any advice? I see `notmuch-show-insert-bodypart-internal` and expect to call that with a forced content-type. Thanks, Brian -- Brian Sniffen "I reserve the right to evolve my views, and state that views I previously expressed may have been somehere along the spectrum from insufficiently nuanced through ill-informed to dead wrong."
[PATCH v2] emacs: Added "is:" style completion to notmuch-read-query.
I see now. I tried using lexical-let*, but now it appears that pulling the assignment of minibuffer-completion-table into the lexical-let* breaks the function, while pulling all the other assigments in works fine. I'm not sure why that happens. I am not a very skilled emacs-lisp programmer, so I am afraid something funny is happening here that is beyond my understanding. charles David Bremner writes: > Charles Celerier writes: > >> Can the variables in the varlist depend on the definition of variables >> that precede them in the list? I believe I tried your suggestion, but >> quickly gave up as Emacs gave me an error claiming that all-tags was >> void. > > That's the point of lexical-let* vs lexical-let > > d -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 480 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20141201/791543e6/attachment.pgp>
[PATCH v2] emacs: Added "is:" style completion to notmuch-read-query.
Can the variables in the varlist depend on the definition of variables that precede them in the list? I believe I tried your suggestion, but quickly gave up as Emacs gave me an error claiming that all-tags was void. charles David Edmondson writes: > On Sat, Nov 29 2014, Charles Celerier wrote: >> The notmuch-search-terms man page states that "tag:" is equivalent >> to "is:". Completion for "is:" style searches is now supported >> in the Emacs interface. >> >> Signed-off-by: Charles Celerier >> --- >> emacs/notmuch.el | 11 +++ >> 1 file changed, 7 insertions(+), 4 deletions(-) >> >> diff --git a/emacs/notmuch.el b/emacs/notmuch.el >> index 218486a..d29499c 100644 >> --- a/emacs/notmuch.el >> +++ b/emacs/notmuch.el >> @@ -856,12 +856,15 @@ See `notmuch-tag' for information on the format of >> TAG-CHANGES." >> >> PROMPT is the string to prompt with." >>(lexical-let >> +(( all-tags >> +(mapcar (lambda (tag) (notmuch-escape-boolean-term tag)) >> +(process-lines notmuch-command "search" "--output=tags" >> "*" >> + (let > > I think that David's suggestion was that you would have only one `let' > form, so something like: > > (lexical-let* >((all-tags (mapcar ...)) > (completions (append ...)) > (keymap (copy-keymap ...)) > (current-query ...)) > ...) > >>((completions >> (append (list "folder:" "path:" "thread:" "id:" "date:" "from:" "to:" >>"subject:" "attachment:") >> -(mapcar (lambda (tag) >> - (concat "tag:" (notmuch-escape-boolean-term tag))) >> -(process-lines notmuch-command "search" "--output=tags" >> "*") >> +(mapcar (lambda (tag) (concat "tag:" tag)) all-tags) >> +(mapcar (lambda (tag) (concat "is:" tag)) all-tags >> (let ((keymap (copy-keymap minibuffer-local-map)) >>(current-query (case major-mode >> (notmuch-search-mode (notmuch-search-get-query)) >> @@ -884,7 +887,7 @@ PROMPT is the string to prompt with." >>(define-key keymap (kbd "TAB") 'minibuffer-complete) >>(let ((history-delete-duplicates t)) >> (read-from-minibuffer prompt nil keymap nil >> - 'notmuch-search-history current-query nil) >> + 'notmuch-search-history current-query nil)) >> >> (defun notmuch-search-get-query () >>"Return the current query in this search buffer" >> -- >> 2.1.2 >> >> ___ >> notmuch mailing list >> notmuch at notmuchmail.org >> http://notmuchmail.org/mailman/listinfo/notmuch -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 480 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20141201/e5bc8e86/attachment.pgp>
[Vagrant Cascadian] Bug#759646: notmuch-emacs: switching mode= to invalid value sends unencrypted mail
David Edmondson writes: >> I'm a little torn what to do here. On the one hand the upstream change >> fixes the bug as reported. On the other hand, if something corrupts the >> #secure tag (e.g., by deleting a letter), then the message is still sent >> un-uncrypted. > > I'm unclear on what you mean. Is it that "upgrade to 24.4" is not a good > enough answer, because we are still leaving pre-24.4 people out in the > cold? No, I mean the fix is rather narrow in that editing somewhere else on the same line causes the same problem as before, even in 24.4 d
[Vagrant Cascadian] Bug#759646: notmuch-emacs: switching mode= to invalid value sends unencrypted mail
On Mon, Dec 01 2014, David Bremner wrote: > David Edmondson writes: > >>> I'm a little torn what to do here. On the one hand the upstream change >>> fixes the bug as reported. On the other hand, if something corrupts the >>> #secure tag (e.g., by deleting a letter), then the message is still sent >>> un-uncrypted. >> >> I'm unclear on what you mean. Is it that "upgrade to 24.4" is not a good >> enough answer, because we are still leaving pre-24.4 people out in the >> cold? > > No, I mean the fix is rather narrow in that editing somewhere else on > the same line causes the same problem as before, even in 24.4 Ah, okay. Well, off to emacs-devel with you, then :-D
[Vagrant Cascadian] Bug#759646: notmuch-emacs: switching mode= to invalid value sends unencrypted mail
On Sat, Nov 29 2014, David Bremner wrote: > David Edmondson writes: > >> On Tue, Sep 02 2014, Tomi Ollila wrote: >>> On Tue, Sep 02 2014, Daniel Kahn Gillmor wrote: >>> On 08/30/2014 03:37 AM, Jani Nikula wrote: > I'm inclined to think this is a bug in message-mode. I agree it's a bug in message-mode, not in notmuch itself. >>> >>> I think it might be here: >>> >>> http://bzr.savannah.gnu.org/lh/emacs/emacs-24/annotate/head:/lisp/gnus/mml.el#L258 >>> >>> (it takes time to load, please wait...) >>> >>> If cond does not match, then don't fail... >> >> This looks to have been fixed in emacs at the end of September 2014. > > Right, this fix was released in emacs 24.4 > > I'm a little torn what to do here. On the one hand the upstream change > fixes the bug as reported. On the other hand, if something corrupts the > #secure tag (e.g., by deleting a letter), then the message is still sent > un-uncrypted. I'm unclear on what you mean. Is it that "upgrade to 24.4" is not a good enough answer, because we are still leaving pre-24.4 people out in the cold?
[PATCH v2] emacs: Added "is:" style completion to notmuch-read-query.
On Sat, Nov 29 2014, Charles Celerier wrote: > The notmuch-search-terms man page states that "tag:" is equivalent > to "is:". Completion for "is:" style searches is now supported > in the Emacs interface. > > Signed-off-by: Charles Celerier > --- > emacs/notmuch.el | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/emacs/notmuch.el b/emacs/notmuch.el > index 218486a..d29499c 100644 > --- a/emacs/notmuch.el > +++ b/emacs/notmuch.el > @@ -856,12 +856,15 @@ See `notmuch-tag' for information on the format of > TAG-CHANGES." > > PROMPT is the string to prompt with." >(lexical-let > +(( all-tags > +(mapcar (lambda (tag) (notmuch-escape-boolean-term tag)) > +(process-lines notmuch-command "search" "--output=tags" > "*" > + (let I think that David's suggestion was that you would have only one `let' form, so something like: (lexical-let* ((all-tags (mapcar ...)) (completions (append ...)) (keymap (copy-keymap ...)) (current-query ...)) ...) >((completions > (append (list "folder:" "path:" "thread:" "id:" "date:" "from:" "to:" > "subject:" "attachment:") > - (mapcar (lambda (tag) > - (concat "tag:" (notmuch-escape-boolean-term tag))) > - (process-lines notmuch-command "search" "--output=tags" > "*") > + (mapcar (lambda (tag) (concat "tag:" tag)) all-tags) > + (mapcar (lambda (tag) (concat "is:" tag)) all-tags > (let ((keymap (copy-keymap minibuffer-local-map)) > (current-query (case major-mode > (notmuch-search-mode (notmuch-search-get-query)) > @@ -884,7 +887,7 @@ PROMPT is the string to prompt with." >(define-key keymap (kbd "TAB") 'minibuffer-complete) >(let ((history-delete-duplicates t)) > (read-from-minibuffer prompt nil keymap nil > - 'notmuch-search-history current-query nil) > + 'notmuch-search-history current-query nil)) > > (defun notmuch-search-get-query () >"Return the current query in this search buffer" > -- > 2.1.2 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Added is:tag style completion to notmuch-read-query.
Charles Celerier ccel...@cs.stanford.edu writes: Can the variables in the varlist depend on the definition of variables that precede them in the list? I believe I tried your suggestion, but quickly gave up as Emacs gave me an error claiming that all-tags was void. Yes, with the let*/lexical-let* variants of let/lexical-let. This is stated in the let* documentation (that is, C-h f let* RET). ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Added is:tag style completion to notmuch-read-query.
Charles Celerier ccel...@cs.stanford.edu writes: Can the variables in the varlist depend on the definition of variables that precede them in the list? I believe I tried your suggestion, but quickly gave up as Emacs gave me an error claiming that all-tags was void. That's the point of lexical-let* vs lexical-let d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] emacs: Added is:tag style completion to notmuch-read-query.
I see now. I tried using lexical-let*, but now it appears that pulling the assignment of minibuffer-completion-table into the lexical-let* breaks the function, while pulling all the other assigments in works fine. I'm not sure why that happens. I am not a very skilled emacs-lisp programmer, so I am afraid something funny is happening here that is beyond my understanding. charles David Bremner da...@tethera.net writes: Charles Celerier ccel...@cs.stanford.edu writes: Can the variables in the varlist depend on the definition of variables that precede them in the list? I believe I tried your suggestion, but quickly gave up as Emacs gave me an error claiming that all-tags was void. That's the point of lexical-let* vs lexical-let d signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
