[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Sat, Feb 08 2014, "W. Trevor King"  wrote:

> On Sat, Feb 08, 2014 at 08:29:41PM +0200, Tomi Ollila wrote:
>> On Sat, Feb 08 2014, W. Trevor King wrote:
>> > On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
>> >> 
>> >> yeah, the colour scheme is not my favourite. For the sake of being
>> >> semi-constructive, I attach an alternative suggestion #ffd96e and
>> >> #bce.
>> >
>> > Works for me.
>> 
>> I'm fine with that too.
>
> Updated in my example and nmbug-status-python3 branch.
>
>> >> More importantly some of the threads are run together: e.g. 
>> >> 
>> >> id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" and
>> >> id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"
>> >
>> > Both of those messages are part of the same thread
>> > (thread:eaab on my box, but I doubt thread IDs are
>> > portable), so I don't add a thread-separating space between them.
>> > Would you like more message-separating space even between messages
>> > in the same thread?
>> 
>> ?
>> 
>> I think the more space does not fix anything but it might help
>> regognizing message boundaries a bit (and thus would be a nice
>> feature).
>
> Added to my example and nmbug-status-python3 branch.  I'm using CSS
> for this new spacing, so non-CSS browsers (e.g. w3m) won't render the
> inter-message spacing.  I think the colored-link (second message row)
> vs. default id (first message row) makes inter-message separation
> clear enough in that case.

The 2 0.5em:s adds up to 1em between messages and that IMHO makes the
messages be too far apart from each other. I changed the padding-top
and padding-bottom values to 0.25em which IMHO is better...

> Cheers,
> Trevor

Tomi

[PATCH] emacs: remove newlines from input to notmuch count --batch

[Tomi Ollila]

On Sat, Feb 08 2014, David Bremner  wrote:

> Since a newline starts a new query in batch mode, this causes
> mysterious crashes in the emacs interface if saved searches contain
> newlines.  See the discussion at
>
>   id:87wqhcxb5j.fsf at maritornes.cs.unb.ca
>
> In general newlines seem to be just whitespace to the xapian query
> parser, so this should be mainly harmless.
> ---

LGTM.

Tomi


>  emacs/notmuch-hello.el | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> index 7b3d76b..e325cd3 100644
> --- a/emacs/notmuch-hello.el
> +++ b/emacs/notmuch-hello.el
> @@ -399,10 +399,12 @@ options will be handled as specified for
>(third elem)
>  (cdr elem
>   (insert
> -  (notmuch-hello-filtered-query count-query
> -(or (plist-get options :filter-count)
> -(plist-get options :filter)))
> -  "\n")))
> +  (replace-regexp-in-string
> +   "\n" " "
> +   (notmuch-hello-filtered-query count-query
> + (or (plist-get options :filter-count)
> + (plist-get options :filter
> +   "\n")))
>  
>  (unless (= (call-process-region (point-min) (point-max) notmuch-command
>   t t nil "count" "--batch") 0)
> -- 
> 1.8.5.2
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Sat, Feb 08 2014, "W. Trevor King"  wrote:

> On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
>> W. Trevor King writes:
>> > I'll remove this once the series lands, but I've currently got a
>> > preview up at http://tremily.us/status.html
>> 
>> yeah, the colour scheme is not my favourite. For the sake of being
>> semi-constructive, I attach an alternative suggestion #ffd96e and
>> #bce.
>
> Works for me.

I'm fine with that too.

>
>> More importantly some of the threads are run together: e.g. 
>> 
>> id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" and
>> id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"
>
> Both of those messages are part of the same thread
> (thread:eaab on my box, but I doubt thread IDs are
> portable), so I don't add a thread-separating space between them.
> Would you like more message-separating space even between messages in
> the same thread?

They're in the same (notmuch) thread. Easily testable with

notmuch search id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" or 
id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"

and therefore shown together. The commit 
02cafc84b4540cd0fb878121dcb3551b4ecd9fd1 made this happen always
(but without this this could have happened if there were no
other patches in new threads coming along in between.

I think the more space does not fix anything but it might help regognizing
message boundaries a bit (and thus would be a nice feature).

> Cheers,
> Trevor

Tomi

[PATCH v4] build: write VERSION file containing $(VERSION) string

[W. Trevor King]

On Thu, Feb 06, 2014 at 12:58:33AM +0200, Tomi Ollila wrote:
> -VERSION:=$(shell git describe --match '[0-9.]*'|sed -e s/_/~/ -e s/-/+/ -e 
> s/-/~/)
> +# Also write VERSION file in case its contents differ from $(VERSION)
> +VERSION:=$(shell\
> + gv=`git describe --match '[0-9.]*'|sed -e s/_/~/ -e s/-/+/ -e s/-/~/`;\

Ew, backticks ;).  What about handling more of the logic in Make:

  VERSION := $(shell git describe ?)
  FILE_VERSION := $(shell test -f VERSION || touch VERSION; cat VERSION)
  ifneq ($(FILE_VERSION), $(VERSION))
$(shell echo "$(VERSION)" > VERSION)
  endif

> +# Depend (also) on 'version' file. In case of ifeq ($(IS_GIT),yes)
> +# this file may already have been updated.
> +VERSION: version
> + echo $(VERSION) > $@

Do we care about case-insensitive filesystems where VERSION will
collide with version?

> -CLEAN := $(CLEAN) notmuch notmuch-shared $(notmuch_client_modules) 
> notmuch.elc
> +CLEAN := $(CLEAN) VERSION notmuch notmuch-shared $(notmuch_client_modules)

Where did notmuch.elc go?

Cheers,
Trevor

-- 
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/20140208/f10dd7db/attachment.pgp>

[PATCH 15/17] nmbug-status: Quote the title when using it as an id

[W. Trevor King]

On Mon, Feb 03, 2014 at 02:59:33AM -0800, W. Trevor King wrote:
> +if 'id' not in view:
> +view['id'] = quote(view['title'])

Stuff like href="#Maybe%20Ready%20%28Core%20and%20Emacs%29" wasn't
working for me on Firefox 24.2.0, so I've tweaked this commit to slug
titles instead of quoting them.  Pushed to my nmbug-status-python3
branch and queued for my v2 submission.

Cheers,
Trevor

-- 
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/20140208/ee287256/attachment.pgp>

[PATCH] nmbug: Add 'clone' and replace FETCH_HEAD with @{upstream}

[W. Trevor King]

From: "W. Trevor King" 

With two branches getting fetched (master and config), the branch
referenced by FETCH_HEAD is ambiguous.  For example, I have:

  $ cat FETCH_HEAD
  41d7bfa7184cc93c9dac139d1674e9530799e3b0 \
not-for-merge   branch 'config' of http://nmbug.tethera.net/git/nmbug-tags
  acd379ccb973c45713eee9db177efc530f921954 \
not-for-merge   branch 'master' of http://nmbug.tethera.net/git/nmbug-tags

(where I wrapped the line by hand).  This means that FETCH_HEAD
references the config branch:

  $ git rev-parse FETCH_HEAD
  41d7bfa7184cc93c9dac139d1674e9530799e3b0

which breaks all of the FETCH_HEAD logic in nmbug (where FETCH_HEAD is
assumed to point to the master branch).

Instead of relying on FETCH_HEAD, use @{upstream} as the
remote-tracking branch that should be merged/diffed/integrated into
HEAD.  @{upstream} was added in Git v1.7.0 (2010-02-12) [1], so
relying on it should be fairly safe.  One tricky bit is that bare
repositories don't set upstream tracking branches by default:

  $ git clone --bare http://nmbug.tethera.net/git/nmbug-tags.git nmbug-bare
  $ cd nmbug-bare
  $ git remote show origin
  * remote origin
Fetch URL: http://nmbug.tethera.net/git/nmbug-tags.git
Push  URL: http://nmbug.tethera.net/git/nmbug-tags.git
HEAD branch: master
Local refs configured for 'git push':
  config pushes to config (up to date)
  master pushes to master (up to date)

While in a non-bare clone:

  $ git clone http://nmbug.tethera.net/git/nmbug-tags.git
  $ cd nmbug-tags
  $ git remote show origin
  * remote origin
Fetch URL: http://nmbug.tethera.net/git/nmbug-tags.git
Push  URL: http://nmbug.tethera.net/git/nmbug-tags.git
HEAD branch: master
Remote branches:
  config tracked
  master tracked
Local branch configured for 'git pull':
  master merges with remote master
Local ref configured for 'git push':
  master pushes to master (up to date)

>From the clone docs [2]:

  --bare::
Make a 'bare' Git repository?
Also the branch heads at the remote are copied directly
to corresponding local branch heads, without mapping
them to `refs/remotes/origin/`.  When this option is
used, neither remote-tracking branches nor the related
configuration variables are created.

To use @{upstream}, we need to restore the local vs. remote-tracking
distinction, so this commit adds 'nmbug clone', which adds the
following configuration adjustments:

  $ git config remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
  $ git config branch.$branch.remote origin
  $ git config branch.$branch.merge refs/heads/$branch

where $branch is the branch referenced by the remote's HEAD, which
'git clone' uses to setup the local branch.  After tweaking the
config, we populate the new remote-tracking branches with:

  $ git fetch origin

After which:

  $ git rev-parse @{upstream}
  acd379ccb973c45713eee9db177efc530f921954

gives us the master-branch commit.  Existing nmbug users will have to
run the configuration tweaks and re-fetch by hand.  If you don't have
any local commits, you could also blow away your NMBGIT repository and
re-clone from scratch:

  $ nmbug clone http://nmbug.tethera.net/git/nmbug-tags.git

Besides removing the ambiguity of FETCH_HEAD, this commit allows users
to configure which upstream branch they want nmbug to track via 'git
config', in case they want to change their upstream repository.

[1]: 
http://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes/1.7.0.txt
[2]: http://git.kernel.org/cgit/git/git.git/tree/Documentation/git-clone.txt
---
 devel/nmbug/nmbug | 49 +++--
 1 file changed, 35 insertions(+), 14 deletions(-)

diff --git a/devel/nmbug/nmbug b/devel/nmbug/nmbug
index 90d98b6..3c1d597 100755
--- a/devel/nmbug/nmbug
+++ b/devel/nmbug/nmbug
@@ -26,6 +26,7 @@ my $ESCAPED_RX =  qr{$ESCAPE_CHAR([A-Fa-f0-9]{2})};
 my %command = (
 archive=> \_archive,
 checkout   => \_checkout,
+clone  => \_clone,
 commit => \_commit,
 fetch  => \_fetch,
 help   => \_help,
@@ -125,6 +126,17 @@ sub do_archive {
   system ('git', "--git-dir=$NMBGIT", 'archive', 'HEAD');
 }

+sub do_clone {
+  my $repository = shift;
+  system ('git', 'clone', '--bare', $repository, $NMBGIT) == 0
+or die "'git clone' exited with nonzero value\n";
+  my $branch = git ('symbolic-ref', 'HEAD');
+  $branch =~ s|^refs/heads/||;
+  git ('config', 'remote.origin.fetch', '+refs/heads/*:refs/remotes/origin/*');
+  git ('config', "branch.$branch.remote", 'origin');
+  git ('config', "branch.$branch.merge", 'refs/heads/$branch');
+  do_fetch();
+}

 sub is_committed {
   my $status = shift;
@@ -332,21 +344,24 @@ To discard your changes,  run 'nmbug checkout'

 sub do_pull {
   my $remote = shift || 'origin';
+  my $branch = shift || 'master';

   git ( 'fetch', 

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Sat, Feb 08, 2014 at 09:37:43PM +0200, Tomi Ollila wrote:
> On Sat, Feb 08 2014, W. Trevor King wrote:
> > On Sat, Feb 08, 2014 at 08:29:41PM +0200, Tomi Ollila wrote:
> >> On Sat, Feb 08 2014, W. Trevor King wrote:
> >> > On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
> >> >> More importantly some of the threads are run together: e.g. 
> >> >> 
> >> >> id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" and
> >> >> id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"
> >> >
> >> > Both of those messages are part of the same thread
> >> > (thread:eaab on my box, but I doubt thread IDs are
> >> > portable), so I don't add a thread-separating space between them.
> >> > Would you like more message-separating space even between messages
> >> > in the same thread?
> >> 
> >> ?
> >> 
> >> I think the more space does not fix anything but it might help
> >> regognizing message boundaries a bit (and thus would be a nice
> >> feature).
> >
> > Added to my example and nmbug-status-python3 branch.  I'm using CSS
> > for this new spacing, so non-CSS browsers (e.g. w3m) won't render the
> > inter-message spacing.  I think the colored-link (second message row)
> > vs. default id (first message row) makes inter-message separation
> > clear enough in that case.
> 
> The 2 0.5em:s adds up to 1em between messages and that IMHO makes the
> messages be too far apart from each other. I changed the padding-top
> and padding-bottom values to 0.25em which IMHO is better...

0.25em works for me.  Branch and example updated.

Cheers,
Trevor

-- 
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/20140208/0e4b11d0/attachment.pgp>

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[David Bremner]

"W. Trevor King"  writes:

 > I'll remove this once the series lands, but I've currently got a
 > preview up at http://tremily.us/status.html

 yeah, the colour scheme is not my favourite. For the sake of being
 semi-constructive, I attach an alternative suggestion using colours
 #ffd96e and #bce.

 More importantly some of the threads are run together: e.g. 

 id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" and
 id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"

-- next part --
A non-text attachment was scrubbed...
Name: colour.png
Type: image/png
Size: 89089 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140208/810e5982/attachment-0001.png>

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Sat, Feb 08, 2014 at 08:29:41PM +0200, Tomi Ollila wrote:
> On Sat, Feb 08 2014, W. Trevor King wrote:
> > On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
> >> W. Trevor King writes:
> >> > I'll remove this once the series lands, but I've currently got a
> >> > preview up at http://tremily.us/status.html
> >> 
> >> yeah, the colour scheme is not my favourite. For the sake of being
> >> semi-constructive, I attach an alternative suggestion #ffd96e and
> >> #bce.
> >
> > Works for me.
> 
> I'm fine with that too.

Updated in my example and nmbug-status-python3 branch.

> >> More importantly some of the threads are run together: e.g. 
> >> 
> >> id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" and
> >> id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"
> >
> > Both of those messages are part of the same thread
> > (thread:eaab on my box, but I doubt thread IDs are
> > portable), so I don't add a thread-separating space between them.
> > Would you like more message-separating space even between messages
> > in the same thread?
> 
> ?
> 
> I think the more space does not fix anything but it might help
> regognizing message boundaries a bit (and thus would be a nice
> feature).

Added to my example and nmbug-status-python3 branch.  I'm using CSS
for this new spacing, so non-CSS browsers (e.g. w3m) won't render the
inter-message spacing.  I think the colored-link (second message row)
vs. default id (first message row) makes inter-message separation
clear enough in that case.

Cheers,
Trevor

-- 
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/20140208/c4bd6531/attachment-0001.pgp>

[PATCH] emacs: remove newlines from input to notmuch count --batch

[David Bremner]

Since a newline starts a new query in batch mode, this causes
mysterious crashes in the emacs interface if saved searches contain
newlines.  See the discussion at

  id:87wqhcxb5j.fsf at maritornes.cs.unb.ca

In general newlines seem to be just whitespace to the xapian query
parser, so this should be mainly harmless.
---
 emacs/notmuch-hello.el | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 7b3d76b..e325cd3 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -399,10 +399,12 @@ options will be handled as specified for
 (third elem)
   (cdr elem
(insert
-(notmuch-hello-filtered-query count-query
-  (or (plist-get options :filter-count)
-  (plist-get options :filter)))
-"\n")))
+(replace-regexp-in-string
+ "\n" " "
+ (notmuch-hello-filtered-query count-query
+   (or (plist-get options :filter-count)
+   (plist-get options :filter
+ "\n")))

 (unless (= (call-process-region (point-min) (point-max) notmuch-command
t t nil "count" "--batch") 0)
-- 
1.8.5.2

[PATCH 2/2] emacs: Prefer Content-Description over filename for part buttons

[W. Trevor King]

On Mon, Feb 03, 2014 at 12:34:18PM -0800, W. Trevor King wrote:
> On Mon, Feb 03, 2014 at 08:15:35PM +, Mark Walters wrote:
> > My only other comment on the series is that you should update
> > devel/schemata in the first patch to reflect this addition.
> 
> Ah, I didn't realize that file existed :p.

Looking at this more, I'm unsure about whether or not I should bump
the version.  b96ba63 (show: indicate length, encoding of omitted body
content, 2012-12-16) added part.content-length? and
part.content-transfer-encoding? and doesn't bump the version, while
abeac48 (search: Add stable queries to thread search results,
2013-10-24) adds thread_summary.query and does bump the version.  From
notmuch-client.h:

 Backwards-incompatible changes such as removing map fields, changing
 the meaning of map fields, or changing the meanings of list elements
 should increase this.  New (required) map fields can be added without
 increasing this.

I think that the addition of part.content-description? should not bump
the version, but then I'm not sure how to document the change in
devel/schemata.  I'm leaning towards something like:

  diff --git a/devel/schemata b/devel/schemata
  index 41dc4a6..63d8aa4 100644
  --- a/devel/schemata
  +++ b/devel/schemata
  @@ -26,6 +26,9 @@ v1
   v2
   - Added the thread_summary.query field.

  +Staged for v3
  +- Added the part.content-descrition? field.
  +
   Common non-terminals
   
  ?

Alternatively, there could be a minor version that gets bumped on each
tweak, however insignificant.

Thoughts?

Trevor

-- 
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/20140208/08fe3796/attachment.pgp>

[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
> W. Trevor King writes:
> > I'll remove this once the series lands, but I've currently got a
> > preview up at http://tremily.us/status.html
> 
> yeah, the colour scheme is not my favourite. For the sake of being
> semi-constructive, I attach an alternative suggestion #ffd96e and
> #bce.

Works for me.

> More importantly some of the threads are run together: e.g. 
> 
> id:"4eddf2b1.4288980a.0b74.5557 at mx.google.com" and
> id:"E1RYMYd-0003wu-Ea at thinkbox.jade-hamburg.de"

Both of those messages are part of the same thread
(thread:eaab on my box, but I doubt thread IDs are
portable), so I don't add a thread-separating space between them.
Would you like more message-separating space even between messages in
the same thread?

Cheers,
Trevor

-- 
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/20140208/2ece50e6/attachment.pgp>

[PATCH 2/2] emacs: Prefer Content-Description over filename for part buttons

[W. Trevor King]

On Sat, Feb 08, 2014 at 08:55:02AM -0400, David Bremner wrote:
> "W. Trevor King"  writes:
> > Rather than patching this in Emacs, maybe we should collapse the
> > ?not set? and ?set to empty string? cases in notmuch-show.c?  I
> > can't think of any reasons why someone would want to distinguish
> > those two cases, and it's easier all around if we standardize the
> > representation as far upstream as possible.
> 
> Do the RFCs have anything to say about headers with empty content?
> If not I'd be inclined to leave the CLI output as raw as possible,
> just because people are always finding new ways to apply tools.

RFC 2183 does not describe Content-Description, it just uses it in
some examples [1].  In all the examples where Content-Description is
present, the value is not empty.  RFC 2045 defines
Content-Description, but it doesn't give all that much information
[2]:

  The ability to associate some descriptive information with a given
  body is often desirable.  For example, it may be useful to mark an
  "image" body as "a picture of the Space Shuttle Endeavor."  Such
  text may be placed in the Content-Description header field.  This
  header field is always optional.

description := "Content-Description" ":" *text

  The description is presumed to be given in the US-ASCII character
  set, although the mechanism specified in RFC 2047 may be used for
  non-US-ASCII Content-Description values.

I couldn't find more generic references to the meaning of empty header
values, but I find it hard to imagine anyone assigning semantic value
to an explicitly-empty description (vs. no Content-Description at
all).

Cheers,
Trevor

[1]: http://tools.ietf.org/html/rfc2183#section-3
[2]: http://tools.ietf.org/html/rfc2045#section-8

-- 
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/20140208/53c31b6d/attachment.pgp>

[PATCH 2/2] emacs: Prefer Content-Description over filename for part buttons

[David Bremner]

"W. Trevor King"  writes:

>
> Rather than patching this in Emacs, maybe we should collapse the ?not
> set? and ?set to empty string? cases in notmuch-show.c?  I can't think
> of any reasons why someone would want to distinguish those two cases,
> and it's easier all around if we standardize the representation as far
> upstream as possible.
>

Do the RFCs have anything to say about headers with empty content? If
not I'd be inclined to leave the CLI output as raw as possible, just
because people are always finding new ways to apply tools.

d

Re: [PATCH 2/2] emacs: Prefer Content-Description over filename for part buttons

[David Bremner]

W. Trevor King wk...@tremily.us writes:


 Rather than patching this in Emacs, maybe we should collapse the “not
 set” and “set to empty string” cases in notmuch-show.c?  I can't think
 of any reasons why someone would want to distinguish those two cases,
 and it's easier all around if we standardize the representation as far
 upstream as possible.


Do the RFCs have anything to say about headers with empty content? If
not I'd be inclined to leave the CLI output as raw as possible, just
because people are always finding new ways to apply tools.

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH] emacs: remove newlines from input to notmuch count --batch

[David Bremner]

Since a newline starts a new query in batch mode, this causes
mysterious crashes in the emacs interface if saved searches contain
newlines.  See the discussion at

  id:87wqhcxb5j@maritornes.cs.unb.ca

In general newlines seem to be just whitespace to the xapian query
parser, so this should be mainly harmless.
---
 emacs/notmuch-hello.el | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 7b3d76b..e325cd3 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -399,10 +399,12 @@ options will be handled as specified for
 (third elem)
   (cdr elem
(insert
-(notmuch-hello-filtered-query count-query
-  (or (plist-get options :filter-count)
-  (plist-get options :filter)))
-\n)))
+(replace-regexp-in-string
+ \n  
+ (notmuch-hello-filtered-query count-query
+   (or (plist-get options :filter-count)
+   (plist-get options :filter
+ \n)))
 
 (unless (= (call-process-region (point-min) (point-max) notmuch-command
t t nil count --batch) 0)
-- 
1.8.5.2

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 2/2] emacs: Prefer Content-Description over filename for part buttons

[W. Trevor King]

On Sat, Feb 08, 2014 at 08:55:02AM -0400, David Bremner wrote:
 W. Trevor King wk...@tremily.us writes:
  Rather than patching this in Emacs, maybe we should collapse the
  “not set” and “set to empty string” cases in notmuch-show.c?  I
  can't think of any reasons why someone would want to distinguish
  those two cases, and it's easier all around if we standardize the
  representation as far upstream as possible.
 
 Do the RFCs have anything to say about headers with empty content?
 If not I'd be inclined to leave the CLI output as raw as possible,
 just because people are always finding new ways to apply tools.

RFC 2183 does not describe Content-Description, it just uses it in
some examples [1].  In all the examples where Content-Description is
present, the value is not empty.  RFC 2045 defines
Content-Description, but it doesn't give all that much information
[2]:

  The ability to associate some descriptive information with a given
  body is often desirable.  For example, it may be useful to mark an
  image body as a picture of the Space Shuttle Endeavor.  Such
  text may be placed in the Content-Description header field.  This
  header field is always optional.

description := Content-Description : *text

  The description is presumed to be given in the US-ASCII character
  set, although the mechanism specified in RFC 2047 may be used for
  non-US-ASCII Content-Description values.

I couldn't find more generic references to the meaning of empty header
values, but I find it hard to imagine anyone assigning semantic value
to an explicitly-empty description (vs. no Content-Description at
all).

Cheers,
Trevor

[1]: http://tools.ietf.org/html/rfc2183#section-3
[2]: http://tools.ietf.org/html/rfc2045#section-8

-- 
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 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
 W. Trevor King writes:
  I'll remove this once the series lands, but I've currently got a
  preview up at http://tremily.us/status.html
 
 yeah, the colour scheme is not my favourite. For the sake of being
 semi-constructive, I attach an alternative suggestion #ffd96e and
 #bce.

Works for me.

 More importantly some of the threads are run together: e.g. 
 
 id:4eddf2b1.4288980a.0b74.5...@mx.google.com and
 id:e1rymyd-0003wu...@thinkbox.jade-hamburg.de

Both of those messages are part of the same thread
(thread:eaab on my box, but I doubt thread IDs are
portable), so I don't add a thread-separating space between them.
Would you like more message-separating space even between messages in
the same thread?

Cheers,
Trevor

-- 
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 2/2] emacs: Prefer Content-Description over filename for part buttons

[W. Trevor King]

On Mon, Feb 03, 2014 at 12:34:18PM -0800, W. Trevor King wrote:
 On Mon, Feb 03, 2014 at 08:15:35PM +, Mark Walters wrote:
  My only other comment on the series is that you should update
  devel/schemata in the first patch to reflect this addition.
 
 Ah, I didn't realize that file existed :p.

Looking at this more, I'm unsure about whether or not I should bump
the version.  b96ba63 (show: indicate length, encoding of omitted body
content, 2012-12-16) added part.content-length? and
part.content-transfer-encoding? and doesn't bump the version, while
abeac48 (search: Add stable queries to thread search results,
2013-10-24) adds thread_summary.query and does bump the version.  From
notmuch-client.h:

 Backwards-incompatible changes such as removing map fields, changing
 the meaning of map fields, or changing the meanings of list elements
 should increase this.  New (required) map fields can be added without
 increasing this.

I think that the addition of part.content-description? should not bump
the version, but then I'm not sure how to document the change in
devel/schemata.  I'm leaning towards something like:

  diff --git a/devel/schemata b/devel/schemata
  index 41dc4a6..63d8aa4 100644
  --- a/devel/schemata
  +++ b/devel/schemata
  @@ -26,6 +26,9 @@ v1
   v2
   - Added the thread_summary.query field.

  +Staged for v3
  +- Added the part.content-descrition? field.
  +
   Common non-terminals
   
  …

Alternatively, there could be a minor version that gets bumped on each
tweak, however insignificant.

Thoughts?

Trevor

-- 
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 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Sat, Feb 08 2014, W. Trevor King wk...@tremily.us wrote:

 On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
 W. Trevor King writes:
  I'll remove this once the series lands, but I've currently got a
  preview up at http://tremily.us/status.html
 
 yeah, the colour scheme is not my favourite. For the sake of being
 semi-constructive, I attach an alternative suggestion #ffd96e and
 #bce.

 Works for me.

I'm fine with that too.


 More importantly some of the threads are run together: e.g. 
 
 id:4eddf2b1.4288980a.0b74.5...@mx.google.com and
 id:e1rymyd-0003wu...@thinkbox.jade-hamburg.de

 Both of those messages are part of the same thread
 (thread:eaab on my box, but I doubt thread IDs are
 portable), so I don't add a thread-separating space between them.
 Would you like more message-separating space even between messages in
 the same thread?

They're in the same (notmuch) thread. Easily testable with

notmuch search id:4eddf2b1.4288980a.0b74.5...@mx.google.com or 
id:e1rymyd-0003wu...@thinkbox.jade-hamburg.de

and therefore shown together. The commit 
02cafc84b4540cd0fb878121dcb3551b4ecd9fd1 made this happen always
(but without this this could have happened if there were no
other patches in new threads coming along in between.

I think the more space does not fix anything but it might help regognizing
message boundaries a bit (and thus would be a nice feature).

 Cheers,
 Trevor

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: remove newlines from input to notmuch count --batch

[Tomi Ollila]

On Sat, Feb 08 2014, David Bremner da...@tethera.net wrote:

 Since a newline starts a new query in batch mode, this causes
 mysterious crashes in the emacs interface if saved searches contain
 newlines.  See the discussion at

   id:87wqhcxb5j@maritornes.cs.unb.ca

 In general newlines seem to be just whitespace to the xapian query
 parser, so this should be mainly harmless.
 ---

LGTM.

Tomi


  emacs/notmuch-hello.el | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)

 diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
 index 7b3d76b..e325cd3 100644
 --- a/emacs/notmuch-hello.el
 +++ b/emacs/notmuch-hello.el
 @@ -399,10 +399,12 @@ options will be handled as specified for
(third elem)
  (cdr elem
   (insert
 -  (notmuch-hello-filtered-query count-query
 -(or (plist-get options :filter-count)
 -(plist-get options :filter)))
 -  \n)))
 +  (replace-regexp-in-string
 +   \n  
 +   (notmuch-hello-filtered-query count-query
 + (or (plist-get options :filter-count)
 + (plist-get options :filter
 +   \n)))
  
  (unless (= (call-process-region (point-min) (point-max) notmuch-command
   t t nil count --batch) 0)
 -- 
 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 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Sat, Feb 08, 2014 at 08:29:41PM +0200, Tomi Ollila wrote:
 On Sat, Feb 08 2014, W. Trevor King wrote:
  On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
  W. Trevor King writes:
   I'll remove this once the series lands, but I've currently got a
   preview up at http://tremily.us/status.html
  
  yeah, the colour scheme is not my favourite. For the sake of being
  semi-constructive, I attach an alternative suggestion #ffd96e and
  #bce.
 
  Works for me.
 
 I'm fine with that too.

Updated in my example and nmbug-status-python3 branch.

  More importantly some of the threads are run together: e.g. 
  
  id:4eddf2b1.4288980a.0b74.5...@mx.google.com and
  id:e1rymyd-0003wu...@thinkbox.jade-hamburg.de
 
  Both of those messages are part of the same thread
  (thread:eaab on my box, but I doubt thread IDs are
  portable), so I don't add a thread-separating space between them.
  Would you like more message-separating space even between messages
  in the same thread?
 
 …
 
 I think the more space does not fix anything but it might help
 regognizing message boundaries a bit (and thus would be a nice
 feature).

Added to my example and nmbug-status-python3 branch.  I'm using CSS
for this new spacing, so non-CSS browsers (e.g. w3m) won't render the
inter-message spacing.  I think the colored-link (second message row)
vs. default id (first message row) makes inter-message separation
clear enough in that case.

Cheers,
Trevor

-- 
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 00/17] nmbug-status: Python-3-compabitility and general refactoring

[Tomi Ollila]

On Sat, Feb 08 2014, W. Trevor King wk...@tremily.us wrote:

 On Sat, Feb 08, 2014 at 08:29:41PM +0200, Tomi Ollila wrote:
 On Sat, Feb 08 2014, W. Trevor King wrote:
  On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
  
  yeah, the colour scheme is not my favourite. For the sake of being
  semi-constructive, I attach an alternative suggestion #ffd96e and
  #bce.
 
  Works for me.
 
 I'm fine with that too.

 Updated in my example and nmbug-status-python3 branch.

  More importantly some of the threads are run together: e.g. 
  
  id:4eddf2b1.4288980a.0b74.5...@mx.google.com and
  id:e1rymyd-0003wu...@thinkbox.jade-hamburg.de
 
  Both of those messages are part of the same thread
  (thread:eaab on my box, but I doubt thread IDs are
  portable), so I don't add a thread-separating space between them.
  Would you like more message-separating space even between messages
  in the same thread?
 
 …
 
 I think the more space does not fix anything but it might help
 regognizing message boundaries a bit (and thus would be a nice
 feature).

 Added to my example and nmbug-status-python3 branch.  I'm using CSS
 for this new spacing, so non-CSS browsers (e.g. w3m) won't render the
 inter-message spacing.  I think the colored-link (second message row)
 vs. default id (first message row) makes inter-message separation
 clear enough in that case.

The 2 0.5em:s adds up to 1em between messages and that IMHO makes the
messages be too far apart from each other. I changed the padding-top
and padding-bottom values to 0.25em which IMHO is better...

 Cheers,
 Trevor

Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring

[W. Trevor King]

On Sat, Feb 08, 2014 at 09:37:43PM +0200, Tomi Ollila wrote:
 On Sat, Feb 08 2014, W. Trevor King wrote:
  On Sat, Feb 08, 2014 at 08:29:41PM +0200, Tomi Ollila wrote:
  On Sat, Feb 08 2014, W. Trevor King wrote:
   On Sat, Feb 08, 2014 at 09:54:28AM -0400, David Bremner wrote:
   More importantly some of the threads are run together: e.g. 
   
   id:4eddf2b1.4288980a.0b74.5...@mx.google.com and
   id:e1rymyd-0003wu...@thinkbox.jade-hamburg.de
  
   Both of those messages are part of the same thread
   (thread:eaab on my box, but I doubt thread IDs are
   portable), so I don't add a thread-separating space between them.
   Would you like more message-separating space even between messages
   in the same thread?
  
  …
  
  I think the more space does not fix anything but it might help
  regognizing message boundaries a bit (and thus would be a nice
  feature).
 
  Added to my example and nmbug-status-python3 branch.  I'm using CSS
  for this new spacing, so non-CSS browsers (e.g. w3m) won't render the
  inter-message spacing.  I think the colored-link (second message row)
  vs. default id (first message row) makes inter-message separation
  clear enough in that case.
 
 The 2 0.5em:s adds up to 1em between messages and that IMHO makes the
 messages be too far apart from each other. I changed the padding-top
 and padding-bottom values to 0.25em which IMHO is better...

0.25em works for me.  Branch and example updated.

Cheers,
Trevor

-- 
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

[PATCH] nmbug: Add 'clone' and replace FETCH_HEAD with @{upstream}

[W. Trevor King]

From: W. Trevor King wk...@tremily.us

With two branches getting fetched (master and config), the branch
referenced by FETCH_HEAD is ambiguous.  For example, I have:

  $ cat FETCH_HEAD
  41d7bfa7184cc93c9dac139d1674e9530799e3b0 \
not-for-merge   branch 'config' of http://nmbug.tethera.net/git/nmbug-tags
  acd379ccb973c45713eee9db177efc530f921954 \
not-for-merge   branch 'master' of http://nmbug.tethera.net/git/nmbug-tags

(where I wrapped the line by hand).  This means that FETCH_HEAD
references the config branch:

  $ git rev-parse FETCH_HEAD
  41d7bfa7184cc93c9dac139d1674e9530799e3b0

which breaks all of the FETCH_HEAD logic in nmbug (where FETCH_HEAD is
assumed to point to the master branch).

Instead of relying on FETCH_HEAD, use @{upstream} as the
remote-tracking branch that should be merged/diffed/integrated into
HEAD.  @{upstream} was added in Git v1.7.0 (2010-02-12) [1], so
relying on it should be fairly safe.  One tricky bit is that bare
repositories don't set upstream tracking branches by default:

  $ git clone --bare http://nmbug.tethera.net/git/nmbug-tags.git nmbug-bare
  $ cd nmbug-bare
  $ git remote show origin
  * remote origin
Fetch URL: http://nmbug.tethera.net/git/nmbug-tags.git
Push  URL: http://nmbug.tethera.net/git/nmbug-tags.git
HEAD branch: master
Local refs configured for 'git push':
  config pushes to config (up to date)
  master pushes to master (up to date)

While in a non-bare clone:

  $ git clone http://nmbug.tethera.net/git/nmbug-tags.git
  $ cd nmbug-tags
  $ git remote show origin
  * remote origin
Fetch URL: http://nmbug.tethera.net/git/nmbug-tags.git
Push  URL: http://nmbug.tethera.net/git/nmbug-tags.git
HEAD branch: master
Remote branches:
  config tracked
  master tracked
Local branch configured for 'git pull':
  master merges with remote master
Local ref configured for 'git push':
  master pushes to master (up to date)

From the clone docs [2]:

  --bare::
Make a 'bare' Git repository…
Also the branch heads at the remote are copied directly
to corresponding local branch heads, without mapping
them to `refs/remotes/origin/`.  When this option is
used, neither remote-tracking branches nor the related
configuration variables are created.

To use @{upstream}, we need to restore the local vs. remote-tracking
distinction, so this commit adds 'nmbug clone', which adds the
following configuration adjustments:

  $ git config remote.origin.fetch '+refs/heads/*:refs/remotes/origin/*'
  $ git config branch.$branch.remote origin
  $ git config branch.$branch.merge refs/heads/$branch

where $branch is the branch referenced by the remote's HEAD, which
'git clone' uses to setup the local branch.  After tweaking the
config, we populate the new remote-tracking branches with:

  $ git fetch origin

After which:

  $ git rev-parse @{upstream}
  acd379ccb973c45713eee9db177efc530f921954

gives us the master-branch commit.  Existing nmbug users will have to
run the configuration tweaks and re-fetch by hand.  If you don't have
any local commits, you could also blow away your NMBGIT repository and
re-clone from scratch:

  $ nmbug clone http://nmbug.tethera.net/git/nmbug-tags.git

Besides removing the ambiguity of FETCH_HEAD, this commit allows users
to configure which upstream branch they want nmbug to track via 'git
config', in case they want to change their upstream repository.

[1]: 
http://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes/1.7.0.txt
[2]: http://git.kernel.org/cgit/git/git.git/tree/Documentation/git-clone.txt
---
 devel/nmbug/nmbug | 49 +++--
 1 file changed, 35 insertions(+), 14 deletions(-)

diff --git a/devel/nmbug/nmbug b/devel/nmbug/nmbug
index 90d98b6..3c1d597 100755
--- a/devel/nmbug/nmbug
+++ b/devel/nmbug/nmbug
@@ -26,6 +26,7 @@ my $ESCAPED_RX =  qr{$ESCAPE_CHAR([A-Fa-f0-9]{2})};
 my %command = (
 archive= \do_archive,
 checkout   = \do_checkout,
+clone  = \do_clone,
 commit = \do_commit,
 fetch  = \do_fetch,
 help   = \do_help,
@@ -125,6 +126,17 @@ sub do_archive {
   system ('git', --git-dir=$NMBGIT, 'archive', 'HEAD');
 }
 
+sub do_clone {
+  my $repository = shift;
+  system ('git', 'clone', '--bare', $repository, $NMBGIT) == 0
+or die 'git clone' exited with nonzero value\n;
+  my $branch = git ('symbolic-ref', 'HEAD');
+  $branch =~ s|^refs/heads/||;
+  git ('config', 'remote.origin.fetch', '+refs/heads/*:refs/remotes/origin/*');
+  git ('config', branch.$branch.remote, 'origin');
+  git ('config', branch.$branch.merge, 'refs/heads/$branch');
+  do_fetch();
+}
 
 sub is_committed {
   my $status = shift;
@@ -332,21 +344,24 @@ To discard your changes,  run 'nmbug checkout'
 
 sub do_pull {
   my $remote = shift || 'origin';
+  my $branch = shift || 'master';
 
   git ( 'fetch', 

Re: [PATCH 15/17] nmbug-status: Quote the title when using it as an id

[W. Trevor King]

On Mon, Feb 03, 2014 at 02:59:33AM -0800, W. Trevor King wrote:
 +if 'id' not in view:
 +view['id'] = quote(view['title'])

Stuff like href=#Maybe%20Ready%20%28Core%20and%20Emacs%29 wasn't
working for me on Firefox 24.2.0, so I've tweaked this commit to slug
titles instead of quoting them.  Pushed to my nmbug-status-python3
branch and queued for my v2 submission.

Cheers,
Trevor

-- 
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 v4] build: write VERSION file containing $(VERSION) string

[W. Trevor King]

On Thu, Feb 06, 2014 at 12:58:33AM +0200, Tomi Ollila wrote:
 -VERSION:=$(shell git describe --match '[0-9.]*'|sed -e s/_/~/ -e s/-/+/ -e 
 s/-/~/)
 +# Also write VERSION file in case its contents differ from $(VERSION)
 +VERSION:=$(shell\
 + gv=`git describe --match '[0-9.]*'|sed -e s/_/~/ -e s/-/+/ -e s/-/~/`;\

Ew, backticks ;).  What about handling more of the logic in Make:

  VERSION := $(shell git describe …)
  FILE_VERSION := $(shell test -f VERSION || touch VERSION; cat VERSION)
  ifneq ($(FILE_VERSION), $(VERSION))
$(shell echo $(VERSION)  VERSION)
  endif

 +# Depend (also) on 'version' file. In case of ifeq ($(IS_GIT),yes)
 +# this file may already have been updated.
 +VERSION: version
 + echo $(VERSION)  $@

Do we care about case-insensitive filesystems where VERSION will
collide with version?

 -CLEAN := $(CLEAN) notmuch notmuch-shared $(notmuch_client_modules) 
 notmuch.elc
 +CLEAN := $(CLEAN) VERSION notmuch notmuch-shared $(notmuch_client_modules)

Where did notmuch.elc go?

Cheers,
Trevor

-- 
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