[PATCH] configure: only install bash completion if supported
On Sun, 02 Feb 2014, David Bremner wrote: > Mark Walters writes: > >> This LGTM (untested) > > I did test it, at least completely removing bash completion works as > expected. > > Unfortunately --with-bash-completion does not override this test because > the order things are processed. Do you think this is a bug? I wondered > if users that "know what they are doing" (TM) might want to force > installation even though the pkg-config test fails. I thought it was a feature, not a bug, but I'm fine either way. BR, Jani.
[PATCH v2 0/7] lib: replace the message header parser with gmime
On Sun, 02 Feb 2014, Mark Walters wrote: > Patches 1-4 basically LGTM but patch 1 needs to be rebased since all the > tests were renamed. I have a couple of minor comments on patches 2 and 3 > that I will send separately. Thanks Mark. I've addressed all your comments, and will post v3 after I've tested it a bit. BR, Jani.
show inline html images as attachments in emacs notmuch-show
Hi This sounds like a bug. However, I don't think I have any emails showing this problem. Have you got any examples that are public, or at least public enough they can be sent privately? Best wishes Mark On Sat, 01 Feb 2014, Jonas H?rsch wrote: > hej, everyone, > > currently when i receive a mail containing inline images in a html > alternative part, which use those cid references. they are sometimes > shown, but other times not visible at all and just a [cid] token is > shown. > > is it possible to provide regular attachment buttons for such images, > regardless whether they can be displayed or not. this would make sure, > that one can display them and it's even easily possible to save them > separately. > > thanks for any hints on how to get there, > > jonas > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[RFC] Content-Description when naming MIME parts in Emacs mode
"W. Trevor King" writes: > But that doesn't work, because :content-description doesn't exist in > the part plist. I've looked through the source for a bit and can't > figure out where that part plist is coming from. This is the parsed output from the command line call "notmuch show --format=sexp $searchterms" d
[PATCH] configure: only install bash completion if supported
Jani Nikula writes: > On Sun, 02 Feb 2014, David Bremner wrote: >> Mark Walters writes: >> >>> This LGTM (untested) >> >> I did test it, at least completely removing bash completion works as >> expected. >> >> Unfortunately --with-bash-completion does not override this test because >> the order things are processed. Do you think this is a bug? I wondered >> if users that "know what they are doing" (TM) might want to force >> installation even though the pkg-config test fails. > > I thought it was a feature, not a bug, but I'm fine either way. I can live with the current patch. As you pointed out on IRC, this is the usual way missing dependencies work. And I think we should avoid extra complications in the configure script when we can.
[PATCH] configure: only install bash completion if supported
Our bash completion depends on bash-completion 1.90 or later. Only
install where available.
---
configure | 8
1 file changed, 8 insertions(+)
diff --git a/configure b/configure
index 13b6062..66aaedb 100755
--- a/configure
+++ b/configure
@@ -360,6 +360,14 @@ else
have_valgrind=0
fi
+printf "Checking for bash-completion (>= 1.90)... "
+if pkg-config --atleast-version=1.90 bash-completion; then
+printf "Yes.\n"
+else
+printf "No (will not install bash completion).\n"
+WITH_BASH=0
+fi
+
if [ -z "${EMACSLISPDIR}" ]; then
if pkg-config --exists emacs; then
EMACSLISPDIR=$(pkg-config emacs --variable sitepkglispdir)
--
1.8.5.2
[PATCH v2 3/7] util: make sanitize string available in string util for reuse
On Sat, 30 Nov 2013, Jani Nikula wrote:
> No functional changes.
> ---
> notmuch-search.c | 19 ---
> util/string-util.c | 22 ++
> util/string-util.h | 7 +++
> 3 files changed, 29 insertions(+), 19 deletions(-)
>
> diff --git a/notmuch-search.c b/notmuch-search.c
> index 11cd6ee..8b6940a 100644
> --- a/notmuch-search.c
> +++ b/notmuch-search.c
> @@ -30,25 +30,6 @@ typedef enum {
> OUTPUT_TAGS
> } output_t;
>
> -static char *
> -sanitize_string (const void *ctx, const char *str)
> -{
> -char *out, *loop;
> -
> -if (NULL == str)
> - return NULL;
> -
> -loop = out = talloc_strdup (ctx, str);
> -
> -for (; *loop; loop++) {
> - if (*loop == '\t' || *loop == '\n')
> - *loop = ' ';
> - else if ((unsigned char)(*loop) < 32)
> - *loop = '?';
> -}
> -return out;
> -}
> -
> /* Return two stable query strings that identify exactly the matched
> * and unmatched messages currently in thread. If there are no
> * matched or unmatched messages, the returned buffers will be
> diff --git a/util/string-util.c b/util/string-util.c
> index a5622d7..9e2f728 100644
> --- a/util/string-util.c
> +++ b/util/string-util.c
> @@ -37,6 +37,28 @@ strtok_len (char *s, const char *delim, size_t *len)
> return *len ? s : NULL;
> }
>
> +char *
> +sanitize_string (const void *ctx, const char *str)
> +{
> +char *out, *loop;
> +
> +if (! str)
> + return NULL;
> +
> +out = talloc_strdup (ctx, str);
> +if (! out)
> + return NULL;
> +
> +for (loop = out; *loop; loop++) {
> + if (*loop == '\t' || *loop == '\n')
> + *loop = ' ';
> + else if ((unsigned char)(*loop) < 32)
> + *loop = '?';
> +}
> +
> +return out;
> +}
> +
> static int
> is_unquoted_terminator (unsigned char c)
> {
> diff --git a/util/string-util.h b/util/string-util.h
> index 0194607..228420d 100644
> --- a/util/string-util.h
> +++ b/util/string-util.h
> @@ -19,6 +19,13 @@
>
> char *strtok_len (char *s, const char *delim, size_t *len);
>
> +/* Return a talloced string with str sanitized.
> + *
> + * Whitespace (tabs and newlines) is replaced with spaces,
> + * non-printable characters with question marks.
> + */
A complete triviality but I would prefer "Whitespace characters (tabs
and newlines) are replaced with spaces..." just to emphasise that e.g.
multiple tabs are replaced by multiple spaces.
Best wishes
Mark
> +char *sanitize_string (const void *ctx, const char *str);
> +
> /* Construct a boolean term query with the specified prefix (e.g.,
> * "id") and search term, quoting term as necessary. Specifically, if
> * term contains any non-printable ASCII characters, non-ASCII
> --
> 1.8.4.2
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 2/7] cli: refactor reply from guessing
On Sat, 30 Nov 2013, Jani Nikula wrote:
> The guess_from_received_header() function had grown quite big. Chop it
> up into smaller functions.
>
> No functional changes.
> ---
> notmuch-reply.c | 178
> +---
> 1 file changed, 105 insertions(+), 73 deletions(-)
>
> diff --git a/notmuch-reply.c b/notmuch-reply.c
> index 9d6f843..ca41405 100644
> --- a/notmuch-reply.c
> +++ b/notmuch-reply.c
> @@ -369,78 +369,44 @@ add_recipients_from_message (GMimeMessage *reply,
> return from_addr;
> }
>
> +/*
> + * Look for the user's address in " for " in the
> + * received headers.
> + *
> + * Return the address that was found, if any, and NULL otherwise.
> + */
> static const char *
> -guess_from_received_header (notmuch_config_t *config, notmuch_message_t
> *message)
> +guess_from_received_for (notmuch_config_t *config, const char *received)
> {
> -const char *addr, *received, *by;
> -char *mta,*ptr,*token;
> -char *domain=NULL;
> -char *tld=NULL;
> -const char *delim=". \t";
> -size_t i;
> -
> -const char *to_headers[] = {
> - "Envelope-to",
> - "X-Original-To",
> - "Delivered-To",
> -};
> -
> -/* sadly, there is no standard way to find out to which email
> - * address a mail was delivered - what is in the headers depends
> - * on the MTAs used along the way. So we are trying a number of
> - * heuristics which hopefully will answer this question.
> -
> - * We only got here if none of the users email addresses are in
> - * the To: or Cc: header. From here we try the following in order:
> - * 1) check for an Envelope-to: header
> - * 2) check for an X-Original-To: header
> - * 3) check for a Delivered-To: header
> - * 4) check for a (for ) clause in Received: headers
> - * 5) check for the domain part of known email addresses in the
> - *'by' part of Received headers
> - * If none of these work, we give up and return NULL
> - */
I like having the logic laid out in a comment as above so would prefer
to see something similar included (that is points 1-6) but I am happy to
be overruled.
> -for (i = 0; i < ARRAY_SIZE (to_headers); i++) {
> - const char *tohdr = notmuch_message_get_header (message, to_headers[i]);
> -
> - /* Note: tohdr potentially contains a list of email addresses. */
> - addr = user_address_in_string (tohdr, config);
> - if (addr)
> - return addr;
> -}
> +const char *ptr;
>
> -/* We get the concatenated Received: headers and search from the
> - * front (last Received: header added) and try to extract from
> - * them indications to which email address this message was
> - * delivered.
> - * The Received: header is special in our get_header function
> - * and is always concatenated.
> - */
> -received = notmuch_message_get_header (message, "received");
> -if (received == NULL)
> +ptr = strstr (received, " for ");
> +if (! ptr)
> return NULL;
>
> -/* First we look for a " for " in the received
> - * header
> - */
> -ptr = strstr (received, " for ");
> +return user_address_in_string (ptr, config);
> +}
>
> -/* Note: ptr potentially contains a list of email addresses. */
> -addr = user_address_in_string (ptr, config);
> -if (addr)
> - return addr;
> -
> -/* Finally, we parse all the " by MTA ..." headers to guess the
> - * email address that this was originally delivered to.
> - * We extract just the MTA here by removing leading whitespace and
> - * assuming that the MTA name ends at the next whitespace.
> - * We test for *(by+4) to be non-'\0' to make sure there's
> - * something there at all - and then assume that the first
> - * whitespace delimited token that follows is the receiving
> - * system in this step of the receive chain
> - */
> -by = received;
> -while((by = strstr (by, " by ")) != NULL) {
> +/*
> + * Parse all the " by MTA ..." parts in received headers to guess the
> + * email address that this was originally delivered to.
> + *
> + * Extract just the MTA here by removing leading whitespace and
> + * assuming that the MTA name ends at the next whitespace. Test for
> + * *(by+4) to be non-'\0' to make sure there's something there at all
> + * - and then assume that the first whitespace delimited token that
> + * follows is the receiving system in this step of the receive chain.
> + *
> + * Return the address that was found, if any, and NULL otherwise.
> + */
> +static const char *
> +guess_from_received_by (notmuch_config_t *config, const char *received)
> +{
> +const char *addr;
> +const char *by = received;
> +char *domain, *tld, *mta, *ptr, *token;
> +
> +while ((by = strstr (by, " by ")) != NULL) {
> by += 4;
> if (*by == '\0')
> break;
> @@ -454,7 +420,7 @@ guess_from_received_header (notmuch_config_t *config,
>
[PATCH v2 0/7] lib: replace the message header parser with gmime
Patches 1-4 basically LGTM but patch 1 needs to be rebased since all the tests were renamed. I have a couple of minor comments on patches 2 and 3 that I will send separately. Best wishes Mark On Sat, 30 Nov 2013, Jani Nikula wrote: > This is v2 of id:cover.1381948853.git.jani at nikula.org with more polish. > > Patches 1-4 do prep work to fix some of the differences in the parsers > in advance. Arguably they are not that bad regardless of the parser > change. > > Patches 5-6 actually make the change. Having two patches is a somewhat > artificial division, but perhaps makes it easier to review. > > Patch 7 is just a hack to make perf tests not ignore so many mails... we > have quite a bit of non-emails in the corpus by gmime parser > standards. And this illustrates one of the differences in the parsers. > > > BR, > Jani. > > Jani Nikula (7): > cli: sanitize tabs and newlines to spaces in notmuch search > cli: refactor reply from guessing > util: make sanitize string available in string util for reuse > cli: sanitize the received header before scanning for replies > lib: replace the header parser with gmime > lib: parse messages only once > HACK: fix broken messages in the perf test corpus > > lib/database.cc | 6 +- > lib/index.cc | 70 +--- > lib/message-file.c| 351 > +- > lib/message.cc| 6 + > lib/notmuch-private.h | 20 ++- > notmuch-reply.c | 186 > notmuch-search.c | 17 -- > performance-test/perf-test-lib.sh | 4 + > test/search-output| 2 +- > util/string-util.c| 22 +++ > util/string-util.h| 7 + > 11 files changed, 297 insertions(+), 394 deletions(-) > > -- > 1.8.4.2 > > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] configure: only install bash completion if supported
This LGTM (untested)
I think this is the right way to do this: I don't think we should
spam a user with error messages for attempting tab completion with
an older version of bash-completion (which I think you said was the case
with the other version)
Best wishes
Mark
On Sun, 02 Feb 2014, Jani Nikula wrote:
> Our bash completion depends on bash-completion 1.90 or later. Only
> install where available.
> ---
> configure | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/configure b/configure
> index 13b6062..66aaedb 100755
> --- a/configure
> +++ b/configure
> @@ -360,6 +360,14 @@ else
> have_valgrind=0
> fi
>
> +printf "Checking for bash-completion (>= 1.90)... "
> +if pkg-config --atleast-version=1.90 bash-completion; then
> +printf "Yes.\n"
> +else
> +printf "No (will not install bash completion).\n"
> +WITH_BASH=0
> +fi
> +
> if [ -z "${EMACSLISPDIR}" ]; then
> if pkg-config --exists emacs; then
> EMACSLISPDIR=$(pkg-config emacs --variable sitepkglispdir)
> --
> 1.8.5.2
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/1] emacs: initialize ido(-completing-read) in emacs 23.[123]
Tomi Ollila writes: > I tested this on emacs 23.1 & 24.3. I tested it on 23.4 and 24.3.1, as expected it didn't break anything. d
[PATCH] configure: only install bash completion if supported
Mark Walters writes: > This LGTM (untested) I did test it, at least completely removing bash completion works as expected. Unfortunately --with-bash-completion does not override this test because the order things are processed. Do you think this is a bug? I wondered if users that "know what they are doing" (TM) might want to force installation even though the pkg-config test fails. d
bash completion error with 0.17
Thanks Jani. I've just looked at the bash-completion formula on Homebrew.
It says that bash-completion 2.0 and above needs bash4, but the current
version of OSX, 10.9, still has bash 3.2, which is why, at least under
Homebrew, we can't update bash-completion to the latest version.
I think your patch probably makes sense. Once a user updates to a newer
bash-completion, it will just begin working, while for users like me, the
error message goes away.
On 2 February 2014 13:54, Jani Nikula wrote:
> On Sun, 02 Feb 2014, Jani Nikula wrote:
> > The trivial "fix" patch would likely just check for the existence of
> > _init_completion, and refuse to complete without it. For anything
> > fancier, patches welcome...
>
> The patch below would get rid of the error message (and completion, for
> that matter) when _init_completion is not present.
>
> I'm not sure whether this is the way to go, or should we rather check
> for a recent enough bash-completion during configure, or
> recommend/suggest it, or what. The error message does tell us what's
> wrong, although it's annoying for the user (probably more so than just
> not completing).
>
> BR,
> Jani.
>
>
>
> diff --git a/completion/notmuch-completion.bash
> b/completion/notmuch-completion.bash
> index 0f13204..0c457a8 100644
> --- a/completion/notmuch-completion.bash
> +++ b/completion/notmuch-completion.bash
> @@ -384,6 +384,10 @@ _notmuch()
> {
> local _notmuch_commands="compact config count dump help insert new
> reply restore search setup show tag"
> local arg cur prev words cword split
> +
> +# require bash-completion with _init_completion
> +type -t _init_completion >/dev/null 2>&1 || return
> +
> _init_completion || return
>
> COMPREPLY=()
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20140202/ce34b6a8/attachment.html>
[PATCH v2 0/7] lib: replace the message header parser with gmime
On Wed, 15 Jan 2014, David Bremner wrote: > Jani Nikula writes: > >> This is v2 of id:cover.1381948853.git.jani at nikula.org with more polish. >> >> Patches 1-4 do prep work to fix some of the differences in the parsers >> in advance. Arguably they are not that bad regardless of the parser >> change. >> >> Patches 5-6 actually make the change. Having two patches is a somewhat >> artificial division, but perhaps makes it easier to review. >> > > I had a quick look at these changes, and nothing jumped out at me. I'd > appreciate a second pair of eyes on them. Anyone? Patches 1-4 are pretty straightforward prep work, IMHO useful on their own too. It would help just to get them reviewed and merged first. BR, Jani. > > I ran the performance suite, and there is only one message (in version > 0.4 of the corpus) newly classified as non-mail. Of course I did clean > up the corpus a bunch from 0.3 to 0.4. I didn't see any shocking changes > in performance before and after the patches. I only had patience enough > to run twice in both cases. > > d
bash completion error with 0.17
On Sun, 02 Feb 2014, Jani Nikula wrote:
> The trivial "fix" patch would likely just check for the existence of
> _init_completion, and refuse to complete without it. For anything
> fancier, patches welcome...
The patch below would get rid of the error message (and completion, for
that matter) when _init_completion is not present.
I'm not sure whether this is the way to go, or should we rather check
for a recent enough bash-completion during configure, or
recommend/suggest it, or what. The error message does tell us what's
wrong, although it's annoying for the user (probably more so than just
not completing).
BR,
Jani.
diff --git a/completion/notmuch-completion.bash
b/completion/notmuch-completion.bash
index 0f13204..0c457a8 100644
--- a/completion/notmuch-completion.bash
+++ b/completion/notmuch-completion.bash
@@ -384,6 +384,10 @@ _notmuch()
{
local _notmuch_commands="compact config count dump help insert new reply
restore search setup show tag"
local arg cur prev words cword split
+
+# require bash-completion with _init_completion
+type -t _init_completion >/dev/null 2>&1 || return
+
_init_completion || return
COMPREPLY=()
[PATCH] completion: bash completion for notmuch new --quiet option
notmuch new now has --quiet option, complete it too.
---
completion/notmuch-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/completion/notmuch-completion.bash
b/completion/notmuch-completion.bash
index 04324bb..0f13204 100644
--- a/completion/notmuch-completion.bash
+++ b/completion/notmuch-completion.bash
@@ -208,7 +208,7 @@ _notmuch_new()
case "${cur}" in
-*)
- local options="--no-hooks"
+ local options="--no-hooks --quiet"
COMPREPLY=( $(compgen -W "${options}" -- ${cur}) )
;;
esac
--
1.8.5.2
bash completion error with 0.17
On Sun, 02 Feb 2014, Anand Buddhdev wrote: > Hi Jani, > > I already have bash-completion installed, although it's version 1.3. At a glance, it seems _init_completion was introduced in bash-completion 1.90: http://anonscm.debian.org/gitweb/?p=bash-completion/bash-completion.git;a=commitdiff;h=32dbe76784acc39b17ee9ca7bc21c28f4f2b23b5 $ git tag --contains 32dbe76784acc39b17ee9ca7bc21c28f4f2b23b5 1.90 1.99 2.0 2.1 BR, Jani. > > > On 2 February 2014 11:44, Jani Nikula wrote: > >> On Sun, 02 Feb 2014, Anand Buddhdev wrote: >> > Hi people, >> > >> > I've just discovered notmuch. I've installed version 0.17 on my Mac using >> > Homebrew. I've also built a forked mutt with notmuch support, and I'm >> > exploring setting up virtual folders, and keeping all mail in a single >> "All >> > Mail" Maildir, with everything just tagged, a la Gmail :) I love it. >> > >> > I have one issue to report: when I type "notmuch" at the command-line and >> > press tab, bash completion gives me the following error: >> > >> > $ notmuch -bash: _init_completion: command not found >> > >> > Looks like something is missing in the bash completion script. I'd >> > appreciate if someone could make a patch. >> >> You'll need the bash-completion package [1] too. I'm not sure about >> versions, but likely reasonably recent. >> >> The trivial "fix" patch would likely just check for the existence of >> _init_completion, and refuse to complete without it. For anything >> fancier, patches welcome... >> >> >> BR, >> Jani. >> >> >> [1] http://bash-completion.alioth.debian.org/ >>
[RFC] Content-Description when naming MIME parts in Emacs mode
On the rss2email list, Victor Orlikowski pointed out [1] that a number of MUAs don't use the Subject header of attached message/rfc822 parts to label multipart/digest subparts [2]. Instead, notmuch and several other MUAs use the filename parameter [3] as a content hint [4]. Using the filename parameter seems more sane than diving into the message/rfc822 part header, but that's still not what the filename parameter was designed for. It makes more sense to me to use the message/rfc822 part's Content-Description header [5,6], falling back on the filename parameter if Content-Description isn't set. It's pretty easy to patch notmuch-show-insert-bodypart to do this: diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 1ac80ca..485c7d1 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -874,13 +874,16 @@ useful for quoting in replies)." content-type)) (nth (plist-get part :id)) (beg (point)) + (name (if (plist-get part :content-description) + (plist-get part :content-description) + (plist-get part :filename))) ;; Hide the part initially if HIDE is t. (show-part (not (equal hide t))) ;; We omit the part button for the first (or only) part if ;; this is text/plain, or HIDE is 'no-buttons. (button (unless (or (equal hide 'no-buttons) (and (string= mime-type "text/plain") (<= nth 1))) - (notmuch-show-insert-part-header nth mime-type content-type (plist-get part :filename + (notmuch-show-insert-part-header nth mime-type content-type name))) (content-beg (point))) ;; Store the computed mime-type for later use (e.g. by attachment handlers). But that doesn't work, because :content-description doesn't exist in the part plist. I've looked through the source for a bit and can't figure out where that part plist is coming from. Is it loaded from notmuch output in notmuch-show-build-buffer? I assume that information comes from the index, in which case I'd need to tweak _index_mime_part in lib/index.cc to add the description. Indexing descriptions seems like a generally useful thing, even outside of my digest usecase (e.g. search image/jpeg attachements with ?genome? in their description [6]). However, adding a field to the schema is more invasive than changing the Emacs mode's attachment formatting; I thought I should check in here for feedback and advice before wading in with my ?a?x?e?? scalpel ;). Thoughs? Trevor [1]: http://article.gmane.org/gmane.mail.rss2email/211 [2]: Digests: http://tools.ietf.org/html/rfc2046#section-5.1.5 [3]: Filename: http://tools.ietf.org/search/rfc2183#section-2.3 [4]: Filename hint to notmuch-show-insert-part-header: http://git.notmuchmail.org/git/notmuch/blob/HEAD:/emacs/notmuch-show.el#l883 [5]: Content-Desciption: http://tools.ietf.org/html/rfc2045#section-8 [6]: Content-Description examples: http://tools.ietf.org/html/rfc2183#section-3 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140202/0ab1f513/attachment.pgp>
bash completion error with 0.17
On Sun, 02 Feb 2014, Anand Buddhdev wrote: > Hi people, > > I've just discovered notmuch. I've installed version 0.17 on my Mac using > Homebrew. I've also built a forked mutt with notmuch support, and I'm > exploring setting up virtual folders, and keeping all mail in a single "All > Mail" Maildir, with everything just tagged, a la Gmail :) I love it. > > I have one issue to report: when I type "notmuch" at the command-line and > press tab, bash completion gives me the following error: > > $ notmuch -bash: _init_completion: command not found > > Looks like something is missing in the bash completion script. I'd > appreciate if someone could make a patch. You'll need the bash-completion package [1] too. I'm not sure about versions, but likely reasonably recent. The trivial "fix" patch would likely just check for the existence of _init_completion, and refuse to complete without it. For anything fancier, patches welcome... BR, Jani. [1] http://bash-completion.alioth.debian.org/
bash completion error with 0.17
Hi Jani, I already have bash-completion installed, although it's version 1.3. On 2 February 2014 11:44, Jani Nikula wrote: > On Sun, 02 Feb 2014, Anand Buddhdev wrote: > > Hi people, > > > > I've just discovered notmuch. I've installed version 0.17 on my Mac using > > Homebrew. I've also built a forked mutt with notmuch support, and I'm > > exploring setting up virtual folders, and keeping all mail in a single > "All > > Mail" Maildir, with everything just tagged, a la Gmail :) I love it. > > > > I have one issue to report: when I type "notmuch" at the command-line and > > press tab, bash completion gives me the following error: > > > > $ notmuch -bash: _init_completion: command not found > > > > Looks like something is missing in the bash completion script. I'd > > appreciate if someone could make a patch. > > You'll need the bash-completion package [1] too. I'm not sure about > versions, but likely reasonably recent. > > The trivial "fix" patch would likely just check for the existence of > _init_completion, and refuse to complete without it. For anything > fancier, patches welcome... > > > BR, > Jani. > > > [1] http://bash-completion.alioth.debian.org/ > -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140202/10e35a60/attachment.html>
bash completion error with 0.17
Hi people, I've just discovered notmuch. I've installed version 0.17 on my Mac using Homebrew. I've also built a forked mutt with notmuch support, and I'm exploring setting up virtual folders, and keeping all mail in a single "All Mail" Maildir, with everything just tagged, a la Gmail :) I love it. I have one issue to report: when I type "notmuch" at the command-line and press tab, bash completion gives me the following error: $ notmuch -bash: _init_completion: command not found Looks like something is missing in the bash completion script. I'd appreciate if someone could make a patch. Regards, Anand -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140202/c04a01bf/attachment.html>
bash completion error with 0.17
Hi people, I've just discovered notmuch. I've installed version 0.17 on my Mac using Homebrew. I've also built a forked mutt with notmuch support, and I'm exploring setting up virtual folders, and keeping all mail in a single All Mail Maildir, with everything just tagged, a la Gmail :) I love it. I have one issue to report: when I type notmuch at the command-line and press tab, bash completion gives me the following error: $ notmuch -bash: _init_completion: command not found Looks like something is missing in the bash completion script. I'd appreciate if someone could make a patch. Regards, Anand ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: bash completion error with 0.17
On Sun, 02 Feb 2014, Anand Buddhdev arh...@gmail.com wrote: Hi people, I've just discovered notmuch. I've installed version 0.17 on my Mac using Homebrew. I've also built a forked mutt with notmuch support, and I'm exploring setting up virtual folders, and keeping all mail in a single All Mail Maildir, with everything just tagged, a la Gmail :) I love it. I have one issue to report: when I type notmuch at the command-line and press tab, bash completion gives me the following error: $ notmuch -bash: _init_completion: command not found Looks like something is missing in the bash completion script. I'd appreciate if someone could make a patch. You'll need the bash-completion package [1] too. I'm not sure about versions, but likely reasonably recent. The trivial fix patch would likely just check for the existence of _init_completion, and refuse to complete without it. For anything fancier, patches welcome... BR, Jani. [1] http://bash-completion.alioth.debian.org/ ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: bash completion error with 0.17
Hi Jani, I already have bash-completion installed, although it's version 1.3. On 2 February 2014 11:44, Jani Nikula j...@nikula.org wrote: On Sun, 02 Feb 2014, Anand Buddhdev arh...@gmail.com wrote: Hi people, I've just discovered notmuch. I've installed version 0.17 on my Mac using Homebrew. I've also built a forked mutt with notmuch support, and I'm exploring setting up virtual folders, and keeping all mail in a single All Mail Maildir, with everything just tagged, a la Gmail :) I love it. I have one issue to report: when I type notmuch at the command-line and press tab, bash completion gives me the following error: $ notmuch -bash: _init_completion: command not found Looks like something is missing in the bash completion script. I'd appreciate if someone could make a patch. You'll need the bash-completion package [1] too. I'm not sure about versions, but likely reasonably recent. The trivial fix patch would likely just check for the existence of _init_completion, and refuse to complete without it. For anything fancier, patches welcome... BR, Jani. [1] http://bash-completion.alioth.debian.org/ ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] completion: bash completion for notmuch new --quiet option
notmuch new now has --quiet option, complete it too.
---
completion/notmuch-completion.bash | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/completion/notmuch-completion.bash
b/completion/notmuch-completion.bash
index 04324bb..0f13204 100644
--- a/completion/notmuch-completion.bash
+++ b/completion/notmuch-completion.bash
@@ -208,7 +208,7 @@ _notmuch_new()
case ${cur} in
-*)
- local options=--no-hooks
+ local options=--no-hooks --quiet
COMPREPLY=( $(compgen -W ${options} -- ${cur}) )
;;
esac
--
1.8.5.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: bash completion error with 0.17
On Sun, 02 Feb 2014, Jani Nikula j...@nikula.org wrote:
The trivial fix patch would likely just check for the existence of
_init_completion, and refuse to complete without it. For anything
fancier, patches welcome...
The patch below would get rid of the error message (and completion, for
that matter) when _init_completion is not present.
I'm not sure whether this is the way to go, or should we rather check
for a recent enough bash-completion during configure, or
recommend/suggest it, or what. The error message does tell us what's
wrong, although it's annoying for the user (probably more so than just
not completing).
BR,
Jani.
diff --git a/completion/notmuch-completion.bash
b/completion/notmuch-completion.bash
index 0f13204..0c457a8 100644
--- a/completion/notmuch-completion.bash
+++ b/completion/notmuch-completion.bash
@@ -384,6 +384,10 @@ _notmuch()
{
local _notmuch_commands=compact config count dump help insert new reply
restore search setup show tag
local arg cur prev words cword split
+
+# require bash-completion with _init_completion
+type -t _init_completion /dev/null 21 || return
+
_init_completion || return
COMPREPLY=()
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 0/7] lib: replace the message header parser with gmime
On Wed, 15 Jan 2014, David Bremner da...@tethera.net wrote: Jani Nikula j...@nikula.org writes: This is v2 of id:cover.1381948853.git.j...@nikula.org with more polish. Patches 1-4 do prep work to fix some of the differences in the parsers in advance. Arguably they are not that bad regardless of the parser change. Patches 5-6 actually make the change. Having two patches is a somewhat artificial division, but perhaps makes it easier to review. I had a quick look at these changes, and nothing jumped out at me. I'd appreciate a second pair of eyes on them. Anyone? Patches 1-4 are pretty straightforward prep work, IMHO useful on their own too. It would help just to get them reviewed and merged first. BR, Jani. I ran the performance suite, and there is only one message (in version 0.4 of the corpus) newly classified as non-mail. Of course I did clean up the corpus a bunch from 0.3 to 0.4. I didn't see any shocking changes in performance before and after the patches. I only had patience enough to run twice in both cases. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: bash completion error with 0.17
Thanks Jani. I've just looked at the bash-completion formula on Homebrew.
It says that bash-completion 2.0 and above needs bash4, but the current
version of OSX, 10.9, still has bash 3.2, which is why, at least under
Homebrew, we can't update bash-completion to the latest version.
I think your patch probably makes sense. Once a user updates to a newer
bash-completion, it will just begin working, while for users like me, the
error message goes away.
On 2 February 2014 13:54, Jani Nikula j...@nikula.org wrote:
On Sun, 02 Feb 2014, Jani Nikula j...@nikula.org wrote:
The trivial fix patch would likely just check for the existence of
_init_completion, and refuse to complete without it. For anything
fancier, patches welcome...
The patch below would get rid of the error message (and completion, for
that matter) when _init_completion is not present.
I'm not sure whether this is the way to go, or should we rather check
for a recent enough bash-completion during configure, or
recommend/suggest it, or what. The error message does tell us what's
wrong, although it's annoying for the user (probably more so than just
not completing).
BR,
Jani.
diff --git a/completion/notmuch-completion.bash
b/completion/notmuch-completion.bash
index 0f13204..0c457a8 100644
--- a/completion/notmuch-completion.bash
+++ b/completion/notmuch-completion.bash
@@ -384,6 +384,10 @@ _notmuch()
{
local _notmuch_commands=compact config count dump help insert new
reply restore search setup show tag
local arg cur prev words cword split
+
+# require bash-completion with _init_completion
+type -t _init_completion /dev/null 21 || return
+
_init_completion || return
COMPREPLY=()
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] configure: only install bash completion if supported
Our bash completion depends on bash-completion 1.90 or later. Only
install where available.
---
configure | 8
1 file changed, 8 insertions(+)
diff --git a/configure b/configure
index 13b6062..66aaedb 100755
--- a/configure
+++ b/configure
@@ -360,6 +360,14 @@ else
have_valgrind=0
fi
+printf Checking for bash-completion (= 1.90)...
+if pkg-config --atleast-version=1.90 bash-completion; then
+printf Yes.\n
+else
+printf No (will not install bash completion).\n
+WITH_BASH=0
+fi
+
if [ -z ${EMACSLISPDIR} ]; then
if pkg-config --exists emacs; then
EMACSLISPDIR=$(pkg-config emacs --variable sitepkglispdir)
--
1.8.5.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] configure: only install bash completion if supported
This LGTM (untested)
I think this is the right way to do this: I don't think we should
spam a user with error messages for attempting tab completion with
an older version of bash-completion (which I think you said was the case
with the other version)
Best wishes
Mark
On Sun, 02 Feb 2014, Jani Nikula j...@nikula.org wrote:
Our bash completion depends on bash-completion 1.90 or later. Only
install where available.
---
configure | 8
1 file changed, 8 insertions(+)
diff --git a/configure b/configure
index 13b6062..66aaedb 100755
--- a/configure
+++ b/configure
@@ -360,6 +360,14 @@ else
have_valgrind=0
fi
+printf Checking for bash-completion (= 1.90)...
+if pkg-config --atleast-version=1.90 bash-completion; then
+printf Yes.\n
+else
+printf No (will not install bash completion).\n
+WITH_BASH=0
+fi
+
if [ -z ${EMACSLISPDIR} ]; then
if pkg-config --exists emacs; then
EMACSLISPDIR=$(pkg-config emacs --variable sitepkglispdir)
--
1.8.5.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 0/7] lib: replace the message header parser with gmime
Patches 1-4 basically LGTM but patch 1 needs to be rebased since all the tests were renamed. I have a couple of minor comments on patches 2 and 3 that I will send separately. Best wishes Mark On Sat, 30 Nov 2013, Jani Nikula j...@nikula.org wrote: This is v2 of id:cover.1381948853.git.j...@nikula.org with more polish. Patches 1-4 do prep work to fix some of the differences in the parsers in advance. Arguably they are not that bad regardless of the parser change. Patches 5-6 actually make the change. Having two patches is a somewhat artificial division, but perhaps makes it easier to review. Patch 7 is just a hack to make perf tests not ignore so many mails... we have quite a bit of non-emails in the corpus by gmime parser standards. And this illustrates one of the differences in the parsers. BR, Jani. Jani Nikula (7): cli: sanitize tabs and newlines to spaces in notmuch search cli: refactor reply from guessing util: make sanitize string available in string util for reuse cli: sanitize the received header before scanning for replies lib: replace the header parser with gmime lib: parse messages only once HACK: fix broken messages in the perf test corpus lib/database.cc | 6 +- lib/index.cc | 70 +--- lib/message-file.c| 351 +- lib/message.cc| 6 + lib/notmuch-private.h | 20 ++- notmuch-reply.c | 186 notmuch-search.c | 17 -- performance-test/perf-test-lib.sh | 4 + test/search-output| 2 +- util/string-util.c| 22 +++ util/string-util.h| 7 + 11 files changed, 297 insertions(+), 394 deletions(-) -- 1.8.4.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 2/7] cli: refactor reply from guessing
On Sat, 30 Nov 2013, Jani Nikula j...@nikula.org wrote:
The guess_from_received_header() function had grown quite big. Chop it
up into smaller functions.
No functional changes.
---
notmuch-reply.c | 178
+---
1 file changed, 105 insertions(+), 73 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 9d6f843..ca41405 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -369,78 +369,44 @@ add_recipients_from_message (GMimeMessage *reply,
return from_addr;
}
+/*
+ * Look for the user's address in for em...@add.res in the
+ * received headers.
+ *
+ * Return the address that was found, if any, and NULL otherwise.
+ */
static const char *
-guess_from_received_header (notmuch_config_t *config, notmuch_message_t
*message)
+guess_from_received_for (notmuch_config_t *config, const char *received)
{
-const char *addr, *received, *by;
-char *mta,*ptr,*token;
-char *domain=NULL;
-char *tld=NULL;
-const char *delim=. \t;
-size_t i;
-
-const char *to_headers[] = {
- Envelope-to,
- X-Original-To,
- Delivered-To,
-};
-
-/* sadly, there is no standard way to find out to which email
- * address a mail was delivered - what is in the headers depends
- * on the MTAs used along the way. So we are trying a number of
- * heuristics which hopefully will answer this question.
-
- * We only got here if none of the users email addresses are in
- * the To: or Cc: header. From here we try the following in order:
- * 1) check for an Envelope-to: header
- * 2) check for an X-Original-To: header
- * 3) check for a Delivered-To: header
- * 4) check for a (for em...@add.res) clause in Received: headers
- * 5) check for the domain part of known email addresses in the
- *'by' part of Received headers
- * If none of these work, we give up and return NULL
- */
I like having the logic laid out in a comment as above so would prefer
to see something similar included (that is points 1-6) but I am happy to
be overruled.
-for (i = 0; i ARRAY_SIZE (to_headers); i++) {
- const char *tohdr = notmuch_message_get_header (message, to_headers[i]);
-
- /* Note: tohdr potentially contains a list of email addresses. */
- addr = user_address_in_string (tohdr, config);
- if (addr)
- return addr;
-}
+const char *ptr;
-/* We get the concatenated Received: headers and search from the
- * front (last Received: header added) and try to extract from
- * them indications to which email address this message was
- * delivered.
- * The Received: header is special in our get_header function
- * and is always concatenated.
- */
-received = notmuch_message_get_header (message, received);
-if (received == NULL)
+ptr = strstr (received, for );
+if (! ptr)
return NULL;
-/* First we look for a for em...@add.res in the received
- * header
- */
-ptr = strstr (received, for );
+return user_address_in_string (ptr, config);
+}
-/* Note: ptr potentially contains a list of email addresses. */
-addr = user_address_in_string (ptr, config);
-if (addr)
- return addr;
-
-/* Finally, we parse all the by MTA ... headers to guess the
- * email address that this was originally delivered to.
- * We extract just the MTA here by removing leading whitespace and
- * assuming that the MTA name ends at the next whitespace.
- * We test for *(by+4) to be non-'\0' to make sure there's
- * something there at all - and then assume that the first
- * whitespace delimited token that follows is the receiving
- * system in this step of the receive chain
- */
-by = received;
-while((by = strstr (by, by )) != NULL) {
+/*
+ * Parse all the by MTA ... parts in received headers to guess the
+ * email address that this was originally delivered to.
+ *
+ * Extract just the MTA here by removing leading whitespace and
+ * assuming that the MTA name ends at the next whitespace. Test for
+ * *(by+4) to be non-'\0' to make sure there's something there at all
+ * - and then assume that the first whitespace delimited token that
+ * follows is the receiving system in this step of the receive chain.
+ *
+ * Return the address that was found, if any, and NULL otherwise.
+ */
+static const char *
+guess_from_received_by (notmuch_config_t *config, const char *received)
+{
+const char *addr;
+const char *by = received;
+char *domain, *tld, *mta, *ptr, *token;
+
+while ((by = strstr (by, by )) != NULL) {
by += 4;
if (*by == '\0')
break;
@@ -454,7 +420,7 @@ guess_from_received_header (notmuch_config_t *config,
notmuch_message_t *message
* as domain and tld.
*/
domain = tld = NULL;
-
Re: [PATCH v2 3/7] util: make sanitize string available in string util for reuse
On Sat, 30 Nov 2013, Jani Nikula j...@nikula.org wrote:
No functional changes.
---
notmuch-search.c | 19 ---
util/string-util.c | 22 ++
util/string-util.h | 7 +++
3 files changed, 29 insertions(+), 19 deletions(-)
diff --git a/notmuch-search.c b/notmuch-search.c
index 11cd6ee..8b6940a 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -30,25 +30,6 @@ typedef enum {
OUTPUT_TAGS
} output_t;
-static char *
-sanitize_string (const void *ctx, const char *str)
-{
-char *out, *loop;
-
-if (NULL == str)
- return NULL;
-
-loop = out = talloc_strdup (ctx, str);
-
-for (; *loop; loop++) {
- if (*loop == '\t' || *loop == '\n')
- *loop = ' ';
- else if ((unsigned char)(*loop) 32)
- *loop = '?';
-}
-return out;
-}
-
/* Return two stable query strings that identify exactly the matched
* and unmatched messages currently in thread. If there are no
* matched or unmatched messages, the returned buffers will be
diff --git a/util/string-util.c b/util/string-util.c
index a5622d7..9e2f728 100644
--- a/util/string-util.c
+++ b/util/string-util.c
@@ -37,6 +37,28 @@ strtok_len (char *s, const char *delim, size_t *len)
return *len ? s : NULL;
}
+char *
+sanitize_string (const void *ctx, const char *str)
+{
+char *out, *loop;
+
+if (! str)
+ return NULL;
+
+out = talloc_strdup (ctx, str);
+if (! out)
+ return NULL;
+
+for (loop = out; *loop; loop++) {
+ if (*loop == '\t' || *loop == '\n')
+ *loop = ' ';
+ else if ((unsigned char)(*loop) 32)
+ *loop = '?';
+}
+
+return out;
+}
+
static int
is_unquoted_terminator (unsigned char c)
{
diff --git a/util/string-util.h b/util/string-util.h
index 0194607..228420d 100644
--- a/util/string-util.h
+++ b/util/string-util.h
@@ -19,6 +19,13 @@
char *strtok_len (char *s, const char *delim, size_t *len);
+/* Return a talloced string with str sanitized.
+ *
+ * Whitespace (tabs and newlines) is replaced with spaces,
+ * non-printable characters with question marks.
+ */
A complete triviality but I would prefer Whitespace characters (tabs
and newlines) are replaced with spaces... just to emphasise that e.g.
multiple tabs are replaced by multiple spaces.
Best wishes
Mark
+char *sanitize_string (const void *ctx, const char *str);
+
/* Construct a boolean term query with the specified prefix (e.g.,
* id) and search term, quoting term as necessary. Specifically, if
* term contains any non-printable ASCII characters, non-ASCII
--
1.8.4.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 0/7] lib: replace the message header parser with gmime
On Sun, 02 Feb 2014, Mark Walters markwalters1...@gmail.com wrote: Patches 1-4 basically LGTM but patch 1 needs to be rebased since all the tests were renamed. I have a couple of minor comments on patches 2 and 3 that I will send separately. Thanks Mark. I've addressed all your comments, and will post v3 after I've tested it a bit. BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: show inline html images as attachments in emacs notmuch-show
Hi This sounds like a bug. However, I don't think I have any emails showing this problem. Have you got any examples that are public, or at least public enough they can be sent privately? Best wishes Mark On Sat, 01 Feb 2014, Jonas Hörsch jo...@chaoflow.net wrote: hej, everyone, currently when i receive a mail containing inline images in a html alternative part, which use those cid references. they are sometimes shown, but other times not visible at all and just a [cid] token is shown. is it possible to provide regular attachment buttons for such images, regardless whether they can be displayed or not. this would make sure, that one can display them and it's even easily possible to save them separately. thanks for any hints on how to get there, jonas ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC] Content-Description when naming MIME parts in Emacs mode
On the rss2email list, Victor Orlikowski pointed out [1] that a number of MUAs don't use the Subject header of attached message/rfc822 parts to label multipart/digest subparts [2]. Instead, notmuch and several other MUAs use the filename parameter [3] as a content hint [4]. Using the filename parameter seems more sane than diving into the message/rfc822 part header, but that's still not what the filename parameter was designed for. It makes more sense to me to use the message/rfc822 part's Content-Description header [5,6], falling back on the filename parameter if Content-Description isn't set. It's pretty easy to patch notmuch-show-insert-bodypart to do this: diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 1ac80ca..485c7d1 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -874,13 +874,16 @@ useful for quoting in replies). content-type)) (nth (plist-get part :id)) (beg (point)) + (name (if (plist-get part :content-description) + (plist-get part :content-description) + (plist-get part :filename))) ;; Hide the part initially if HIDE is t. (show-part (not (equal hide t))) ;; We omit the part button for the first (or only) part if ;; this is text/plain, or HIDE is 'no-buttons. (button (unless (or (equal hide 'no-buttons) (and (string= mime-type text/plain) (= nth 1))) - (notmuch-show-insert-part-header nth mime-type content-type (plist-get part :filename + (notmuch-show-insert-part-header nth mime-type content-type name))) (content-beg (point))) ;; Store the computed mime-type for later use (e.g. by attachment handlers). But that doesn't work, because :content-description doesn't exist in the part plist. I've looked through the source for a bit and can't figure out where that part plist is coming from. Is it loaded from notmuch output in notmuch-show-build-buffer? I assume that information comes from the index, in which case I'd need to tweak _index_mime_part in lib/index.cc to add the description. Indexing descriptions seems like a generally useful thing, even outside of my digest usecase (e.g. search image/jpeg attachements with “genome” in their description [6]). However, adding a field to the schema is more invasive than changing the Emacs mode's attachment formatting; I thought I should check in here for feedback and advice before wading in with my —a̶x̶e̶— scalpel ;). Thoughs? Trevor [1]: http://article.gmane.org/gmane.mail.rss2email/211 [2]: Digests: http://tools.ietf.org/html/rfc2046#section-5.1.5 [3]: Filename: http://tools.ietf.org/search/rfc2183#section-2.3 [4]: Filename hint to notmuch-show-insert-part-header: http://git.notmuchmail.org/git/notmuch/blob/HEAD:/emacs/notmuch-show.el#l883 [5]: Content-Desciption: http://tools.ietf.org/html/rfc2045#section-8 [6]: Content-Description examples: http://tools.ietf.org/html/rfc2183#section-3 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] configure: only install bash completion if supported
Mark Walters markwalters1...@gmail.com writes: This LGTM (untested) I did test it, at least completely removing bash completion works as expected. Unfortunately --with-bash-completion does not override this test because the order things are processed. Do you think this is a bug? I wondered if users that know what they are doing (TM) might want to force installation even though the pkg-config test fails. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] configure: only install bash completion if supported
On Sun, 02 Feb 2014, David Bremner da...@tethera.net wrote: Mark Walters markwalters1...@gmail.com writes: This LGTM (untested) I did test it, at least completely removing bash completion works as expected. Unfortunately --with-bash-completion does not override this test because the order things are processed. Do you think this is a bug? I wondered if users that know what they are doing (TM) might want to force installation even though the pkg-config test fails. I thought it was a feature, not a bug, but I'm fine either way. BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/1] emacs: initialize ido(-completing-read) in emacs 23.[123]
Tomi Ollila tomi.oll...@iki.fi writes: I tested this on emacs 23.1 24.3. I tested it on 23.4 and 24.3.1, as expected it didn't break anything. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] configure: only install bash completion if supported
Jani Nikula j...@nikula.org writes: On Sun, 02 Feb 2014, David Bremner da...@tethera.net wrote: Mark Walters markwalters1...@gmail.com writes: This LGTM (untested) I did test it, at least completely removing bash completion works as expected. Unfortunately --with-bash-completion does not override this test because the order things are processed. Do you think this is a bug? I wondered if users that know what they are doing (TM) might want to force installation even though the pkg-config test fails. I thought it was a feature, not a bug, but I'm fine either way. I can live with the current patch. As you pointed out on IRC, this is the usual way missing dependencies work. And I think we should avoid extra complications in the configure script when we can. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC] Content-Description when naming MIME parts in Emacs mode
W. Trevor King wk...@tremily.us writes: But that doesn't work, because :content-description doesn't exist in the part plist. I've looked through the source for a bit and can't figure out where that part plist is coming from. This is the parsed output from the command line call notmuch show --format=sexp $searchterms d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: show inline html images as attachments in emacs notmuch-show
Hi all, I can confirm this behaviour as well. With certain emails the CID images are not displayed, and there is no means how to show them except writing on disk and view externally. i have reported this problem some times ago, but I haven't find any solution yet. http://notmuchmail.org/pipermail/notmuch/2012/012493.html .d. Mark Walters markwalters1...@gmail.com writes: Hi This sounds like a bug. However, I don't think I have any emails showing this problem. Have you got any examples that are public, or at least public enough they can be sent privately? Best wishes Mark On Sat, 01 Feb 2014, Jonas Hörsch jo...@chaoflow.net wrote: hej, everyone, currently when i receive a mail containing inline images in a html alternative part, which use those cid references. they are sometimes shown, but other times not visible at all and just a [cid] token is shown. is it possible to provide regular attachment buttons for such images, regardless whether they can be displayed or not. this would make sure, that one can display them and it's even easily possible to save them separately. thanks for any hints on how to get there, jonas ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
