[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring
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
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
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
Re: [PATCH v4] build: write VERSION file containing $(VERSION) string
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
[PATCH v4] build: write VERSION file containing $(VERSION) string
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>
Re: [PATCH 15/17] nmbug-status: Quote the title when using it as an id
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
[PATCH 15/17] nmbug-status: Quote the title when using it as an id
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}
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=> \&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] nmbug: Add 'clone' and replace FETCH_HEAD with @{upstream}
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=> \&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', $remot
Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring
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 00/17] nmbug-status: Python-3-compabitility and general refactoring
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
"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>
Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring
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.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
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
[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring
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>
Re: [PATCH] emacs: remove newlines from input to notmuch count --batch
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@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
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.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
[PATCH] emacs: remove newlines from input to notmuch count --batch
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
Re: [PATCH 2/2] emacs: Prefer Content-Description over filename for part buttons
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
[PATCH 2/2] emacs: Prefer Content-Description over filename for part buttons
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>
Re: [PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring
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
[PATCH 00/17] nmbug-status: Python-3-compabitility and general refactoring
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>
Re: [PATCH 2/2] emacs: Prefer Content-Description over filename for part buttons
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 signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] emacs: Prefer Content-Description over filename for part buttons
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
"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
[PATCH] emacs: remove newlines from input to notmuch count --batch
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" 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