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
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
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:
re
Size: 480 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20141201/791543e6/attachment.pgp>
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>
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
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
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
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
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
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
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
12 matches
Mail list logo
