Re: all intermediate drafts appear in threads (v0.24.2, Emacs 25.2)
Matt Armstrong writes: > David Bremner writes: > This is happening to me on a fairly regular basis too. Is there > something I can bind C-x C-s to in notmuch-show that doesn't create a > new draft? > > I like the idea of saving the drafts in the DB, so perhaps just getting > the deleted stuff working in an unsurprising way in notmuch-show is the > best way forward. For me, when I save a second draft, the first is tagged as deleted, and then mostly not shown. It's not perfect, but it's good enough at the moment. One person I talked to who was confused by the number of drafts in their inbox had excludes turned off. Excludes won't prevent deleted drafts showing up in threads, but they will be collapsed. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: all intermediate drafts appear in threads (v0.24.2, Emacs 25.2)
David Bremner writes: > Sanjoy Mahajan writes: > >> I save an outgoing email as I write it and often (as if it were a >> regular document) by using the usual Emacs key sequence C-x C-s. With >> notmuch v0.24, notmuch saves a proper draft each time I use C-x C-s. >> The result is a million drafts, which may be good. >> >> However, it means that the thread view (in notmuch-show mode) includes >> the zillion drafts. Attached is a screenshot of what I mean (sorry that >> it is so small -- I downsampled it to get within the message-size >> limit). I made the example by sending myself (sanjoy@localhost) a short >> msg. Then I replied to it with 'r', and saved the reply a few times >> (first with "Draft v1" as the body text, the next time with "Draft v2", >> etc.). > > It could be a nice feature to toggle visibility of drafts (and other > excluded messages) in notmuch-show mode. So far nobody wrote such a > thing. > > Two things you might find useful to know: > > - you can resume editing a previous draft with 'e' > - autosaving does not create drafts > > If it really bugs you, you could override the binding C-x C-s in > notmuch-show mode. This is happening to me on a fairly regular basis too. Is there something I can bind C-x C-s to in notmuch-show that doesn't create a new draft? I like the idea of saving the drafts in the DB, so perhaps just getting the deleted stuff working in an unsurprising way in notmuch-show is the best way forward. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Make the shell location configurable
Robert Ewald writes: > Does the shell-file-name have to be bourne shell compatible? My > understanding is that using "/bin/sh" requires a POSIX compatible shell, > bash specific shell scripts should be invoked with e.g. /bin/bash. > I believe a POSIX compatible shell is sufficient in this particular case. > Of course, if shell-file-name is not POSIX compatible this line may not > work. Yeah, I was sloppy. Hopefully POSIX compatibility is enough (if not we can probably fix that). But as you note there's no guarantee shell-file-name is POSIX compatible. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: bug: notmuch show --decrypt leads to SIGSEGV
Matt Armstrong writes: > David Bremner writes: > >> Matt Armstrong writes: >> >>> I've been able to diagnose a SIGSEGV, and I have a workaround that >>> satisfies me. I'm unsure how to fix it, so I'll describe the problem >>> and leave it at that. >>> >>> Repro: >>> >>> % notmuch --version >>> notmuch 0.25+22~g0967e46 (a recent git @HEAD) >>> % notmuch show --format=sexp --decrypt thread:0002ad2c >>> -> SIGSEGV >> >> Do you have a way for people other than you to reproduce it? I assume >> not all threads are a problem for you with --decrypt? > > The times I have encountered this involve email I can't reveal, so a > repro would take some work. I'm happy to try to dig out specific > details, but I'm at a slight disadvantage here due to unfamiliarity. > Understood. If you manage to bisect the commit that introduces the problem (I suspect the rearrangement to support gmime-3.0, but you never know), that might be helpful. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: bug: notmuch show --decrypt leads to SIGSEGV
David Bremner writes: > Matt Armstrong writes: > >> I've been able to diagnose a SIGSEGV, and I have a workaround that >> satisfies me. I'm unsure how to fix it, so I'll describe the problem >> and leave it at that. >> >> Repro: >> >> % notmuch --version >> notmuch 0.25+22~g0967e46 (a recent git @HEAD) >> % notmuch show --format=sexp --decrypt thread:0002ad2c >> -> SIGSEGV > > Do you have a way for people other than you to reproduce it? I assume > not all threads are a problem for you with --decrypt? The times I have encountered this involve email I can't reveal, so a repro would take some work. I'm happy to try to dig out specific details, but I'm at a slight disadvantage here due to unfamiliarity. I didn't this notice this before, but I am getting this on stderr: "Failed to construct pkcs7 context." So g_mime_gpg_context_new() is returning NULL. I am running an old Ubuntu variant. My libgmime is libgmime-2.6-dev. Looks like nothing in the API contract for g_mime_gpg_context_new() states that it never returns NULL. Still, it appears that libgmime is built with ENABLE_CRYPTOGRAPHY (when I download gmime source and debbuild it, config.h sets that macro), so I'm at a loss for why that function would return an error. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: bug: notmuch show --decrypt leads to SIGSEGV
Matt Armstrong writes: > I've been able to diagnose a SIGSEGV, and I have a workaround that > satisfies me. I'm unsure how to fix it, so I'll describe the problem > and leave it at that. > > Repro: > > % notmuch --version > notmuch 0.25+22~g0967e46 (a recent git @HEAD) > % notmuch show --format=sexp --decrypt thread:0002ad2c > -> SIGSEGV Do you have a way for people other than you to reproduce it? I assume not all threads are a problem for you with --decrypt? d signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
bug: notmuch show --decrypt leads to SIGSEGV
I've been able to diagnose a SIGSEGV, and I have a workaround that
satisfies me. I'm unsure how to fix it, so I'll describe the problem
and leave it at that.
Repro:
% notmuch --version
notmuch 0.25+22~g0967e46 (a recent git @HEAD)
% notmuch show --format=sexp --decrypt thread:0002ad2c
-> SIGSEGV
Workaround:
Don't pass --decrypt. In Emacs, configure notmuch-crypto-process-mime
to shut off crypto processing, or C-u before in notmuch-show before
viewing a problematic thread.
Diagnosis:
mime-node.c's _mime_node_create() can return NULL in various scenarios
yet few to none of its callers appear to handle it properly. In this
particular case, the NULL is returned here:
#if (GMIME_MAJOR_VERSION < 3)
if ((GMIME_IS_MULTIPART_ENCRYPTED (part) && node->ctx->crypto->decrypt)
|| (GMIME_IS_MULTIPART_SIGNED (part) && node->ctx->crypto->verify)) {
GMimeContentType *content_type = g_mime_object_get_content_type (part);
const char *protocol = g_mime_content_type_get_parameter (content_type,
"protocol");
cryptoctx = notmuch_crypto_get_context (node->ctx->crypto, protocol);
if (!cryptoctx) {
return NULL;
}
}
#endif
Note above a missing call to talloc_free(node) before the return, which
suggests a kind of bit-rot has set in for the GMIME_MAJOR_VERSION<3
case? Anyway...
mime_node_child() calls _mime_node_create() and will SIGSEGV:
node = _mime_node_create (parent, sub);
if (child == parent->next_child && parent->next_part_num != -1) {
/* We're traversing in depth-first order. Record the child's
* depth-first numbering. */
node->part_num = parent->next_part_num;
node->next_part_num = node->part_num + 1;
If I address that by returning NULL from mime_node_child() when
_mime_node_create() does, then the problem cascades to callers. None of
the callers of mime_node_child() explicitly handle the NULL return case:
mime-node.c:mime_node_t *child = mime_node_child (node, i);
notmuch-show.c:571: format_part_text (ctx, sp, mime_node_child (node, i),
indent, params);
notmuch-show.c:622: format_part_sprinter (ctx, sp, mime_node_child
(node, 0), first, TRUE, include_html);
notmuch-show.c:724: format_part_sprinter (ctx, sp, mime_node_child (node,
i), i == 0, TRUE, include_html);
..._mime_node_seek_dfs_walk will proceed to SIGSEGV, and so will
format_part_...().
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Make the shell location configurable
Robert Ewald writes: > The location of the shell is not always /bin/sh. Use the > shell-file-name variable to be able to specify the shell location. > --- Can you say a bit more about the problem you are trying to solve? I think shell-file-name is not guaranteed to be Bourne shell compatible. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Make the shell location configurable
On Tue, Aug 15 2017, Robert Ewald wrote: > The location of the shell is not always /bin/sh. Use the > shell-file-name variable to be able to specify the shell location. > --- > emacs/notmuch-lib.el | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el > index 337b20ac..8dffe9f2 100644 > --- a/emacs/notmuch-lib.el > +++ b/emacs/notmuch-lib.el > @@ -921,7 +921,7 @@ status." >(command (or (executable-find notmuch-command) > (error "command not found: %s" notmuch-command))) >(proc (apply #'start-process name buffer > - "/bin/sh" "-c" > + shell-file-name "-c" > "exec 2>\"$1\"; shift; exec \"$0\" \"$@\"" > command err-file args))) > (process-put proc 'err-file err-file) I don't yet know a (unix) system where /bin/sh did not provide a bourne compatible shell that supports the syntax used above. My shell-file-name expands to "/bin/zsh". I wonder if it expanded like "/usr/bin/tcsh" or "/path/to/fish" or "/path/to/rc" those worked here. Tomi > -- > 2.11.0 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Make the shell location configurable
The location of the shell is not always /bin/sh. Use the shell-file-name variable to be able to specify the shell location. --- emacs/notmuch-lib.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el index 337b20ac..8dffe9f2 100644 --- a/emacs/notmuch-lib.el +++ b/emacs/notmuch-lib.el @@ -921,7 +921,7 @@ status." (command (or (executable-find notmuch-command) (error "command not found: %s" notmuch-command))) (proc (apply #'start-process name buffer - "/bin/sh" "-c" + shell-file-name "-c" "exec 2>\"$1\"; shift; exec \"$0\" \"$@\"" command err-file args))) (process-put proc 'err-file err-file) -- 2.11.0 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: wish: notmuch-emacs: tag unsent email with same key bindings as in notmuch show
Gregor Zattler writes: > Hi notmuch developers, it's super fast to use "k" + key binding > to tag mails in notmuch-emacs show, it's great that one may tag > unsent emails via the Fcc: header, but even there is C-c C-f C-w > in message mode it's error prone and especially slow to edit tags > without UI support. > > It would be great if in notmuch-emacs the same tagging bindings > worked for unsent mails (obviously not with "k" but another key > combo as prefix key ["C-c k" is not bound in message mode at > least in my configuration]) as in notmuch show. > It seems like a reasonable idea for someone (TM) to impliment. I'd just note that C-c bindings are reserved for user bindings by convention, so we'd probably want to use something else. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
wish: notmuch-emacs: tag unsent email with same key bindings as in notmuch show
Hi notmuch developers, it's super fast to use "k" + key binding to tag mails in notmuch-emacs show, it's great that one may tag unsent emails via the Fcc: header, but even there is C-c C-f C-w in message mode it's error prone and especially slow to edit tags without UI support. It would be great if in notmuch-emacs the same tagging bindings worked for unsent mails (obviously not with "k" but another key combo as prefix key ["C-c k" is not bound in message mode at least in my configuration]) as in notmuch show. Thanks for your attention, Gregor ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
