[PATCH v2 0/3] emacs: Add new option notmuch-search-hide-excluded

[mohkale]

From: Mohsin Kaleem 

Hi,

I've finally managed to come back to this patch series. Since last time
I've collapsed all the separate commits into 3 main ones. The first adds
the new option and then updates the commands and tests that should be
affected by it. The second allows you to configure message exclusion in
notmuch-saved-searches. The last adds several tests for the new
functionality.

Mohsin Kaleem (3):
  emacs: Add new option notmuch-search-hide-excluded
  emacs: Allow notmuch-saved-searches to hide excluded messages
  test/emacs: Add test cases for notmuch-search-hide-excluded

 devel/emacs-keybindings.org   |   2 +-
 doc/notmuch-emacs.rst |   7 +
 emacs/notmuch-hello.el|  40 ++--
 emacs/notmuch-jump.el |  11 +-
 emacs/notmuch-lib.el  |  10 +
 emacs/notmuch-tree.el |  60 --
 emacs/notmuch.el  |  52 +++--
 test/T310-emacs.sh|   2 +-
 test/T460-emacs-tree.sh   |   2 +-
 test/T461-emacs-search-exclude.sh | 185 ++
 .../notmuch-search-tag-inbox-with-excluded|  25 +++
 .../notmuch-search-tag-inbox-without-excluded |  21 ++
 .../notmuch-tree-tag-inbox-with-excluded  |  53 +
 .../notmuch-tree-tag-inbox-without-excluded   |  49 +
 ...notmuch-unthreaded-tag-inbox-with-excluded |  53 +
 ...much-unthreaded-tag-inbox-without-excluded |  49 +
 .../notmuch-tree-tag-inbox-oldest-first   |  53 +
 17 files changed, 629 insertions(+), 45 deletions(-)
 create mode 100755 test/T461-emacs-search-exclude.sh
 create mode 100644 
test/emacs-exclude.expected-output/notmuch-search-tag-inbox-with-excluded
 create mode 100644 
test/emacs-exclude.expected-output/notmuch-search-tag-inbox-without-excluded
 create mode 100644 
test/emacs-exclude.expected-output/notmuch-tree-tag-inbox-with-excluded
 create mode 100644 
test/emacs-exclude.expected-output/notmuch-tree-tag-inbox-without-excluded
 create mode 100644 
test/emacs-exclude.expected-output/notmuch-unthreaded-tag-inbox-with-excluded
 create mode 100644 
test/emacs-exclude.expected-output/notmuch-unthreaded-tag-inbox-without-excluded
 create mode 100644 
test/emacs-tree.expected-output/notmuch-tree-tag-inbox-oldest-first

-- 
2.40.0

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

[PATCH v2 0/3] ruby: add latest config API

[Felipe Contreras]

Currently the simplest way to open the notmuch database properly a
client must do:

  $config = IO.popen(%w[notmuch config list]) do |io|
io.each(chomp: true).map { |e| e.split('=') }.to_h
  end
  $db_name = config['database.path']
  $db = Notmuch::Database.new($db_name)

While this works and it's not too overly complicated, the notmuch API
already has much better constucts.

This patch series allows the user to simply do:

  $db = Notmuch::Database.open_with_config
  $config = $db.config.to_h

And much more.

Since v1 this is rebased on top of master to resolve conflicts, and a
minor style update to one test.

Felipe Contreras (3):
  ruby: add new Database.open_with_config
  ruby: add db.config
  ruby: make db.config return an enumerator

 bindings/ruby/database.c | 95 
 bindings/ruby/defs.h | 10 +
 bindings/ruby/init.c |  2 +
 test/T395-ruby.sh| 14 ++
 4 files changed, 121 insertions(+)

Range-diff against v1:
1:  0d63249e = 1:  beba4602 ruby: add new Database.open_with_config
2:  41bae8f2 ! 2:  92a36061 ruby: add db.config
@@ Commit message
 Signed-off-by: Felipe Contreras 
 
  ## bindings/ruby/database.c ##
-@@ bindings/ruby/database.c: notmuch_rb_database_query_create (VALUE self, 
VALUE qstrv)
+@@ bindings/ruby/database.c: notmuch_rb_database_query_create (int argc, 
VALUE *argv, VALUE self)
  
  return Data_Wrap_Notmuch_Object (notmuch_rb_cQuery, 
_rb_query_type, query);
  }
@@ bindings/ruby/defs.h: extern ID ID_db_mode;
  extern const rb_data_type_t notmuch_rb_database_type;
 @@ bindings/ruby/defs.h: notmuch_rb_database_get_all_tags (VALUE self);
  VALUE
- notmuch_rb_database_query_create (VALUE self, VALUE qstrv);
+ notmuch_rb_database_query_create (int argc, VALUE *argv, VALUE self);
  
 +VALUE
 +notmuch_rb_database_config (int argc, VALUE *argv, VALUE self);
@@ bindings/ruby/init.c
 @@ bindings/ruby/init.c: Init_notmuch (void)
  notmuch_rb_database_find_message_by_filename, 1); /* in 
database.c */
  rb_define_method (notmuch_rb_cDatabase, "all_tags", 
notmuch_rb_database_get_all_tags, 0); /* in database.c */
- rb_define_method (notmuch_rb_cDatabase, "query", 
notmuch_rb_database_query_create, 1); /* in database.c */
+ rb_define_method (notmuch_rb_cDatabase, "query", 
notmuch_rb_database_query_create, -1); /* in database.c */
 +rb_define_method (notmuch_rb_cDatabase, "config", 
notmuch_rb_database_config, -1); /* in database.c */
  
  /*
@@ test/T395-ruby.sh: test_ruby < EXPECTED
 +test_ruby <<"EOF"
-+config_db = Notmuch::Database.open_with_config
-+config_db.config { |e| puts '%s=%s' % e }
++Notmuch::Database.open_with_config do |db|
++  db.config { |e| puts '%s=%s' % e }
++end
 +EOF
 +
  test_done
3:  e6880180 = 3:  4efe195f ruby: make db.config return an enumerator
-- 
2.32.0
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

[PATCH v2 0/3] Allow functions in notmuch-*-result-format

[David Edmondson]

As well as allowing headers to be specified in the various result
format lists, allow functions that can be used to implement per-user
logic when generating the results.

David Edmondson (3):
  emacs: Use pcase in notmuch-search-insert-field
  emacs: Allow functions in notmuch-search-result-format
  emacs: Allow functions in notmuch-{tree,unthreaded}-result-format

 emacs/notmuch-tree.el |  3 +++
 emacs/notmuch.el  | 47 +--
 2 files changed, 30 insertions(+), 20 deletions(-)

-- 
2.29.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

[PATCH v2 0/3] support for format=flowed text display

[David Edmondson]

support for format=flowed text display

This patch improves the display of format=flowed text parts.

I suspect that format=flowed display and some of the other content
washing might interact in annoying ways, but the only way to be sure
is to see how people feel about the results.

v2:
- Update the schemata.


David Edmondson (3):
  notmuch: Include the format parameter of text/plain parts
  emacs: Pass the part to text/plain hook functions
  emacs: Process format=flowed text

 devel/schemata|  2 ++
 emacs/notmuch-show.el |  5 +++--
 emacs/notmuch-wash.el | 24 +++-
 notmuch-show.c| 13 +
 4 files changed, 37 insertions(+), 7 deletions(-)

-- 
2.11.0

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

Re: [PATCH v2 0/3] postpone and resume support

[Daniel Kahn Gillmor]

On Fri 2016-06-03 13:49:52 -0400, Mark Walters  
wrote:
> This is a new version of the WIP patch at
> id:1464915472-5669-1-git-send-email-markwalters1...@gmail.com
>
> So far it seems to deal with all cases that I have tried, and the
> CAVEATS list is rather smaller than before.
>
> The bindings are C-x C-s to save a draft (in notmuch-message-mode) C-c
> C-p to postpone a draft (ie save and exit buffer), and "e" to resume
> editing from either show or tree mode. You may want to add "draft" to
> your list of excluded tags to hide them unless you specifically search
> for them.

This is a really useful series, even with the caveats Mark lists.  i've
tested it and it behaves as expected for me.

A bit more discussion on the caveats:

> Each save saves a separate copy of the message. We hide these copies
> with the deleted tag but we don't actually delete them. Thus if you
> save several copies of message with large attachments you will use a
> lot of space.

This is a little bit weird, because it means that all these deleted
drafts show up in the thread view when viewing the thread from which the
message was composed.  Is there a reason to not actually delete older
drafts when "re-postponing" or sending?  We created the message
ourselves, so it seems like it's fair to delete it.

> If you use signing or encryption then I don't know what will happen: 
> I have not tested at all.  You might sign a partial message that you
> didn't mean too; you might expose plain text to someone.

I've just tested this for signing, and it's doing the thing i was afraid
it would do :/ When saving a draft marked as a message to be signed, the
message signature is made on the draft.  Even worse, restoring a saved
draft like this leaves the user editing the plaintext while the old
message signature is likely to be appended, which will result in broken
signatures :/

Maybe there's a way to temporarily inhibit the interpretation of all
#secure flags during draft saving (and propagate them through upon
resume)?  I think that would be advisable anyway -- if we ultimately
decide that we want to encrypt drafts, we don't want to encrypt them to
the actual recipients anyway; we only want encrypt-to-self, because we
want to avoid the situation where the person we're sending the message
to gets access to our drafts folder and reads our unfinished/unedited
compositions, so that would be a separate and distinct improvement.

> Finally, and this is not really a caveat, it *may* be possible to resume
> a previously sent message. At the moment I haven't tested this, and
> have made it so that emacs warns before allowing it.

I've tested it.  It's possible, and it even seems to work :) there are
weird interactions between things like DKIM and modified message-ids,
but i think the warning provided is sufficient to let people know that
if they're doing that sort of thing and something breaks, they get to
keep both pieces.  The biggest danger, i think, is in marking the
non-draft for deletion if a user goes ahead with restoring it.

  --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2 0/3] postpone and resume support

[Mark Walters]

This is a new version of the WIP patch at
id:1464915472-5669-1-git-send-email-markwalters1...@gmail.com

So far it seems to deal with all cases that I have tried, and the
CAVEATS list is rather smaller than before.

The bindings are C-x C-s to save a draft (in notmuch-message-mode) C-c
C-p to postpone a draft (ie save and exit buffer), and "e" to resume
editing from either show or tree mode. You may want to add "draft" to
your list of excluded tags to hide them unless you specifically search
for them.

CAVEATS

Attachments work, but the attachment that will be sent is the
attachment that was there when the message was postponed. (Attachments
added after resume are obviously not added until the message is sent.)

Each save saves a separate copy of the message. We hide these copies
with the deleted tag but we don't actually delete them. Thus if you
save several copies of message with large attachments you will use a
lot of space.

If you use signing or encryption then I don't know what will happen: 
I have not tested at all.  You might sign a partial message that you
didn't mean too; you might expose plain text to someone.

Finally, and this is not really a caveat, it *may* be possible to resume
a previously sent message. At the moment I haven't tested this, and
have made it so that emacs warns before allowing it.

Best wishes

Mark


Mark Walters (3):
  emacs: tree: move binding for pressing button in message pane to g
  emacs: notmuch-check-exit-status bugfix
  emacs:  postpone/resume support

 emacs/notmuch-lib.el |  10 +++-
 emacs/notmuch-message.el | 135 +++
 emacs/notmuch-mua.el |   4 ++
 emacs/notmuch-show.el|  13 +
 emacs/notmuch-tree.el|   3 +-
 5 files changed, 162 insertions(+), 3 deletions(-)

-- 
2.1.4

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

[PATCH v2 0/3] Improve the display of matching/non-matching authors.

[David Edmondson]

Improve the display of matching/non-matching authors.

Distinguishing between matching and non-matching authors in the emacs
interface is currently done by parsing the :authors attribute of a
search result. If one of the authors uses the pipe symbol (|) in their
'From' address this parsing incorrectly determines the matching and
non-matching authors.

Address this by adding explicit matching and non-matching authors
attributes to the structured output formats.

v2:
- Return the matching/non-matching authors as a list.
- More improvements to the code that renders the authors are possible
  (to improve the chosen break between visible and invisible), but a
  planned re-write of the `notmuch-search-result-format' code would
  render that irrelevant.


David Edmondson (3):
  search: Separately report matching and non-matching authors.
  emacs: Improved display of matching/non-matching authors.
  test: Update tests for 'authors_matched' and authors_non_matched'.

 emacs/notmuch.el |  64 ++
 notmuch-search.c | 105 +++
 test/T160-json.sh|   9 
 test/T170-sexp.sh|   4 +-
 test/T470-missing-headers.sh |   8 
 5 files changed, 159 insertions(+), 31 deletions(-)

-- 
2.1.1

[PATCH v2 0/3] Improve the display of matching/non-matching authors.

[David Edmondson]

Improve the display of matching/non-matching authors.

Distinguishing between matching and non-matching authors in the emacs
interface is currently done by parsing the :authors attribute of a
search result. If one of the authors uses the pipe symbol (|) in their
'From' address this parsing incorrectly determines the matching and
non-matching authors.

Address this by adding explicit matching and non-matching authors
attributes to the structured output formats.

v2:
- Return the matching/non-matching authors as a list.
- More improvements to the code that renders the authors are possible
  (to improve the chosen break between visible and invisible), but a
  planned re-write of the `notmuch-search-result-format' code would
  render that irrelevant.


David Edmondson (3):
  search: Separately report matching and non-matching authors.
  emacs: Improved display of matching/non-matching authors.
  test: Update tests for 'authors_matched' and authors_non_matched'.

 emacs/notmuch.el |  64 ++
 notmuch-search.c | 105 +++
 test/T160-json.sh|   9 
 test/T170-sexp.sh|   4 +-
 test/T470-missing-headers.sh |   8 
 5 files changed, 159 insertions(+), 31 deletions(-)

-- 
2.1.1

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

[PATCH v2 0/3] notmuch insert failure paths and post-insert hook

[Jani Nikula]

This is v2 of the final three patches of [1]. The failure paths have
been improved further still, with some new warning messages on any
cleanup errors as well. Man pages have been updated.

Tests are still lacking. The post-insert hook should be simple, but I
haven't had a sudden outburst of creativity in figuring out how to test
all the fail scenarios.

BR,
Jani.


[1] id:cover.1411379395.git.jani at nikula.org

Jani Nikula (3):
  cli/insert: add fail path to add_file_to_database
  cli/insert: require succesful message indexing for success status
  cli/insert: add post-insert hook

 doc/man1/notmuch-insert.rst |  26 ++--
 doc/man5/notmuch-hooks.rst  |  11 
 notmuch-insert.c| 140 +++-
 test/T070-insert.sh |   2 +-
 4 files changed, 132 insertions(+), 47 deletions(-)

-- 
2.1.0

[PATCH v2 0/3] notmuch insert failure paths and post-insert hook

[Jani Nikula]

This is v2 of the final three patches of [1]. The failure paths have
been improved further still, with some new warning messages on any
cleanup errors as well. Man pages have been updated.

Tests are still lacking. The post-insert hook should be simple, but I
haven't had a sudden outburst of creativity in figuring out how to test
all the fail scenarios.

BR,
Jani.


[1] id:cover.1411379395.git.j...@nikula.org

Jani Nikula (3):
  cli/insert: add fail path to add_file_to_database
  cli/insert: require succesful message indexing for success status
  cli/insert: add post-insert hook

 doc/man1/notmuch-insert.rst |  26 ++--
 doc/man5/notmuch-hooks.rst  |  11 
 notmuch-insert.c| 140 +++-
 test/T070-insert.sh |   2 +-
 4 files changed, 132 insertions(+), 47 deletions(-)

-- 
2.1.0

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

[PATCH v2 0/3] vim plugin updates

[David Bremner]

Felipe Contreras  writes:

> A few trivial updates, and an important fix.
>
> Changes since v1: improved commit messages.

I have pushed these to release and master.

d
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 647 bytes
Desc: not available
URL: 

Re: [PATCH v2 0/3] vim plugin updates

[David Bremner]

Felipe Contreras felipe.contre...@gmail.com writes:

 A few trivial updates, and an important fix.

 Changes since v1: improved commit messages.

I have pushed these to release and master.

d


pgpFeATpEBPAw.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2 0/3] vim plugin updates

[Felipe Contreras]

A few trivial updates, and an important fix.

Changes since v1: improved commit messages.

Felipe Contreras (2):
  vim: fix count_threads variable check
  vim: improve the way messages are sent

Paul Roberts (1):
  vim: make the html handler configurable

 vim/notmuch.vim | 39 ---
 1 file changed, 24 insertions(+), 15 deletions(-)

-- 
1.9.2+fc1.19.g85b6256

[PATCH v2 0/3] vim plugin updates

[Felipe Contreras]

A few trivial updates, and an important fix.

Changes since v1: improved commit messages.

Felipe Contreras (2):
  vim: fix count_threads variable check
  vim: improve the way messages are sent

Paul Roberts (1):
  vim: make the html handler configurable

 vim/notmuch.vim | 39 ---
 1 file changed, 24 insertions(+), 15 deletions(-)

-- 
1.9.2+fc1.19.g85b6256

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

[Patch v2 0/3] contrib: pick: remove an unused variable

[Tomi Ollila]

On Tue, Aug 27 2013, Mark Walters  wrote:

> v2 of this series is at
> id:1377460214-4795-1-git-send-email-markwalters1009 at gmail.com
>
> v2 had a bug on refresh view (which I should have tested more). The
> main pick view only worked by fluke as the initial call to pick-worker
> was inside a let binding.
>
> This version fixes the bug, moves the call to pick-worker outside the
> let binding (so the bug would have shown up sooner) and also adds a
> test for refresh view.
>
> It is also rebased on top of
> id:1377547043-17584-1-git-send-email-markwalters1009 at gmail.com so that
> series should be applied first.

Looks Good, tests pass. +1

>
> Best wishes
>
> Mark

Tomi


>
>
> Mark Walters (3):
>   contrib: pick: remove unneeded variable notmuch-pick-buffer-name
>   contrib: pick: add docstring for notmuch-pick-worker
>   contrib: pick: test: refresh view
>
>  contrib/notmuch-pick/notmuch-pick.el |   29 +
>  contrib/notmuch-pick/test/emacs-pick |   11 +++
>  2 files changed, 24 insertions(+), 16 deletions(-)
>
> -- 
> 1.7.9.1
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>

-- 
uussigu

Re: [Patch v2 0/3] contrib: pick: remove an unused variable

[Mark Walters]

I should have included a diff from v2: see below (obviously the test in
patch 3 is also new).

Best wishes

Mark 



diff --git a/contrib/notmuch-pick/notmuch-pick.el 
b/contrib/notmuch-pick/notmuch-pick.el
index f6710e9..5d46d42 100644
--- a/contrib/notmuch-pick/notmuch-pick.el
+++ b/contrib/notmuch-pick/notmuch-pick.el
@@ -812,7 +812,7 @@ Complete list of currently available key bindings:
(setq search-args basic-query))
 (if notmuch-pick-asynchronous-parser
(let ((proc (notmuch-start-notmuch
-notmuch-pick buffer #'notmuch-pick-process-sentinel
+notmuch-pick (current-buffer) 
#'notmuch-pick-process-sentinel
 show --body=false --format=sexp
 message-arg search-args))
  ;; Use a scratch buffer to accumulate partial output.
@@ -853,13 +853,13 @@ The arguments are:
(concat *notmuch-pick- query *)
(inhibit-read-only t))
 
-(switch-to-buffer buffer)
-;; Don't track undo information for this buffer
-(set 'buffer-undo-list t)
+(switch-to-buffer buffer))
+  ;; Don't track undo information for this buffer
+  (set 'buffer-undo-list t)
 
-(notmuch-pick-worker query query-context target open-target)
+  (notmuch-pick-worker query query-context target open-target)
 
-(setq truncate-lines t)))
+  (setq truncate-lines t))
 
 
 ;; Set up key bindings from the rest of notmuch.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[Patch v2 0/3] contrib: pick: remove an unused variable

[Mark Walters]

I should have included a diff from v2: see below (obviously the test in
patch 3 is also new).

Best wishes

Mark 



diff --git a/contrib/notmuch-pick/notmuch-pick.el 
b/contrib/notmuch-pick/notmuch-pick.el
index f6710e9..5d46d42 100644
--- a/contrib/notmuch-pick/notmuch-pick.el
+++ b/contrib/notmuch-pick/notmuch-pick.el
@@ -812,7 +812,7 @@ Complete list of currently available key bindings:
(setq search-args basic-query))
 (if notmuch-pick-asynchronous-parser
(let ((proc (notmuch-start-notmuch
-"notmuch-pick" buffer #'notmuch-pick-process-sentinel
+"notmuch-pick" (current-buffer) 
#'notmuch-pick-process-sentinel
 "show" "--body=false" "--format=sexp"
 message-arg search-args))
  ;; Use a scratch buffer to accumulate partial output.
@@ -853,13 +853,13 @@ The arguments are:
(concat "*notmuch-pick-" query "*")
(inhibit-read-only t))

-(switch-to-buffer buffer)
-;; Don't track undo information for this buffer
-(set 'buffer-undo-list t)
+(switch-to-buffer buffer))
+  ;; Don't track undo information for this buffer
+  (set 'buffer-undo-list t)

-(notmuch-pick-worker query query-context target open-target)
+  (notmuch-pick-worker query query-context target open-target)

-(setq truncate-lines t)))
+  (setq truncate-lines t))


 ;; Set up key bindings from the rest of notmuch.

[Patch v2 0/3] contrib: pick: remove an unused variable

[Mark Walters]

v2 of this series is at
id:1377460214-4795-1-git-send-email-markwalters1009 at gmail.com

v2 had a bug on refresh view (which I should have tested more). The
main pick view only worked by fluke as the initial call to pick-worker
was inside a let binding.

This version fixes the bug, moves the call to pick-worker outside the
let binding (so the bug would have shown up sooner) and also adds a
test for refresh view.

It is also rebased on top of
id:1377547043-17584-1-git-send-email-markwalters1009 at gmail.com so that
series should be applied first.

Best wishes

Mark


Mark Walters (3):
  contrib: pick: remove unneeded variable notmuch-pick-buffer-name
  contrib: pick: add docstring for notmuch-pick-worker
  contrib: pick: test: refresh view

 contrib/notmuch-pick/notmuch-pick.el |   29 +
 contrib/notmuch-pick/test/emacs-pick |   11 +++
 2 files changed, 24 insertions(+), 16 deletions(-)

-- 
1.7.9.1

[Patch v2 0/3] contrib: pick: remove an unused variable

[Mark Walters]

v2 of this series is at
id:1377460214-4795-1-git-send-email-markwalters1...@gmail.com

v2 had a bug on refresh view (which I should have tested more). The
main pick view only worked by fluke as the initial call to pick-worker
was inside a let binding.

This version fixes the bug, moves the call to pick-worker outside the
let binding (so the bug would have shown up sooner) and also adds a
test for refresh view.

It is also rebased on top of
id:1377547043-17584-1-git-send-email-markwalters1...@gmail.com so that
series should be applied first.

Best wishes

Mark


Mark Walters (3):
  contrib: pick: remove unneeded variable notmuch-pick-buffer-name
  contrib: pick: add docstring for notmuch-pick-worker
  contrib: pick: test: refresh view

 contrib/notmuch-pick/notmuch-pick.el |   29 +
 contrib/notmuch-pick/test/emacs-pick |   11 +++
 2 files changed, 24 insertions(+), 16 deletions(-)

-- 
1.7.9.1

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

[PATCH v2 0/3] Clean up reply's encoding story

[Austin Clements]

This is v2 of id:1376332839-22825-1-git-send-email-amdragon at mit.edu.
This fixes an unintentional temporary test breakage and two typos in
the last patch's commit message.  There's no version diff from v1
because the final trees are the same.

[PATCH v2 0/3] Contrib: Pick: Remove horrible hack

[David Bremner]

Mark Walters  writes:

> This is a trivial rebase of
> id:1369551008-30697-1-git-send-email-markwalters1009 at gmail.com to
> current master.  I have included the dependent patch
> id:1369550458-30562-1-git-send-email-markwalters1009 at gmail.com

Pushed,

d

[PATCH v2 0/3] Contrib: Pick: Remove horrible hack

[Mark Walters]

This is a trivial rebase of
id:1369551008-30697-1-git-send-email-markwalters1009 at gmail.com to
current master.  I have included the dependent patch
id:1369550458-30562-1-git-send-email-markwalters1009 at gmail.com

As I said in id:87sj00xapn.fsf at qmul.ac.uk this removes the worst piece
of code in pick (a sleep loop while waiting for the correct message to arrive)

Although the diffstat is relatively large

 1 files changed, 4 insertions(+), 2 deletions(-)
 1 files changed, 12 insertions(+), 25 deletions(-)
 1 files changed, 17 insertions(+), 6 deletions(-)

for the each patch the final one is only 3 lines of code changed.

Many thanks

Mark




Mark Walters (3):
  contrib: pick: if no target specified go to first matching message
  contrib: pick: remove hack notmuch-pick-show-match-message-with-wait
  contrib: pick: fix refresh result

 contrib/notmuch-pick/notmuch-pick.el |   66 +-
 1 files changed, 33 insertions(+), 33 deletions(-)

-- 
1.7.9.1

[PATCH v2 0/3] emacs: show: lazy handling of hidden parts

[Adam Wolfe Gordon]

On Sun, May 26, 2013 at 1:57 AM, Mark Walters  
wrote:
> This is a slightly tweaked version of
> id:1367672478-12247-1-git-send-email-markwalters1009 at gmail.com minus
> the first two patches which have already been pushed.

>From a quick read-through, this series looks good to me. I applied the
patches to my build today and they improve the performance of show
substantially.

Re: [PATCH v2 0/3] emacs: show: lazy handling of hidden parts

[Adam Wolfe Gordon]

On Sun, May 26, 2013 at 1:57 AM, Mark Walters markwalters1...@gmail.com wrote:
 This is a slightly tweaked version of
 id:1367672478-12247-1-git-send-email-markwalters1...@gmail.com minus
 the first two patches which have already been pushed.

From a quick read-through, this series looks good to me. I applied the
patches to my build today and they improve the performance of show
substantially.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2 0/3] emacs: show: lazy handling of hidden parts

[Mark Walters]

This is a slightly tweaked version of
id:1367672478-12247-1-git-send-email-markwalters1009 at gmail.com minus
the first two patches which have already been pushed.

The second patch of the previous series obsoleted the handler
notmuch-show-insert-part-inline-patch-fake-part so we remove that and
we update the commit message of the second patch in this series to but
otherwise patches 2 and 3 of this are identical to patches 3 and 4 of
the previous series.

There is one change that inadvertently slipped into the second patch
of the previous series: it changed the (fake) name of the fake inline
patch parts from inline-patch-fake-part to "inline patch". (I think
this was when I was testing whether I could do away with the
notmuch-show-insert-part-inline-patch-fake-part handler but I forgot
to revert it after). The only place it shows to a user is in the part
button title: it will say something like

 [ 0001-emacs-show-separate-out-handling-of-application-octe.patch: inline 
patch (as text/x-diff) ]

instead of 

 [ 0001-emacs-show-separate-out-handling-of-application-octe.patch: 
inline-patch-fake-part (as text/x-diff) ]

but perhaps it should be reverted anyway.

Sorry for messing that bit up

Best wishes

Mark

Mark Walters (3):
  emacs: show: fake wash parts are handled at insert-bodypart level
  emacs: show: move the insertion of the header button to the top level
  emacs: show: implement lazy hidden part handling

 emacs/notmuch-show.el |  121 +
 1 files changed, 71 insertions(+), 50 deletions(-)

-- 
1.7.9.1

[PATCH v2 0/3] cli: mail-followup-to support

[Mark Walters]

Hi

On Sat, 30 Mar 2013, Jani Nikula  wrote:
> This is v2 of [1], rebased against master and with a better commit
> message for patch 1/3. Patch 1/3 is trivial cleanup and IMO could just
> be merged. There was debate on the actual stuff 2/3 and 3/3 [2].
>
> I don't think adding a --reply-to=list option to notmuch reply is a good
> idea. We should just do the right thing and keep the cli simple. Perhaps
> we should drop the configuration (patch 2/3) altogether, and just
> support mail-followup-to?

I think I don't like it as a config option: I would prefer it either as
no option or a command line option (or the JSON as you suggest). I think
we currently honour reply-to unconditionally and ignore mail-reply-to:
is that correct? Otherwise I think the patch looks fine.

> Or, perhaps notmuch reply should return *all* options in json, and let
> the UI decide. Above all, let the UI change the reply style while
> editing the reply. I'd probably like this approach most, more than these
> patches, but I don't have the time to do it.

I have some preliminary patches to do this: will post shortly.

Best wishes

Mark


> Here are the patches anyway; perhaps they could be an intermediate step,
> or just a reference for anyone willing to do the above.
>
>
> BR,
> Jani.
>
>
> [1] id:5eaa3acc22ee5513bdce5ab931b7a79ade880e06.1362254104.git.jani at 
> nikula.org
> [2] id:20130303120745.GA4884 at hili.localdomain
>
> Jani Nikula (3):
>   cli: config: remove unnecessary braces from if blocks
>   cli: add reply.honor_followup_to configuration option
>   cli: support Mail-Followup-To: in notmuch reply
>
>  notmuch-client.h |7 +++
>  notmuch-config.c |   56 
> ++
>  notmuch-reply.c  |   25 ++--
>  3 files changed, 74 insertions(+), 14 deletions(-)
>
> -- 
> 1.7.10.4
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v2 0/3] cli: mail-followup-to support

[Mark Walters]

Hi

On Sat, 30 Mar 2013, Jani Nikula j...@nikula.org wrote:
 This is v2 of [1], rebased against master and with a better commit
 message for patch 1/3. Patch 1/3 is trivial cleanup and IMO could just
 be merged. There was debate on the actual stuff 2/3 and 3/3 [2].

 I don't think adding a --reply-to=list option to notmuch reply is a good
 idea. We should just do the right thing and keep the cli simple. Perhaps
 we should drop the configuration (patch 2/3) altogether, and just
 support mail-followup-to?

I think I don't like it as a config option: I would prefer it either as
no option or a command line option (or the JSON as you suggest). I think
we currently honour reply-to unconditionally and ignore mail-reply-to:
is that correct? Otherwise I think the patch looks fine.

 Or, perhaps notmuch reply should return *all* options in json, and let
 the UI decide. Above all, let the UI change the reply style while
 editing the reply. I'd probably like this approach most, more than these
 patches, but I don't have the time to do it.

I have some preliminary patches to do this: will post shortly.

Best wishes

Mark


 Here are the patches anyway; perhaps they could be an intermediate step,
 or just a reference for anyone willing to do the above.


 BR,
 Jani.


 [1] id:5eaa3acc22ee5513bdce5ab931b7a79ade880e06.1362254104.git.j...@nikula.org
 [2] id:20130303120745.GA4884@hili.localdomain

 Jani Nikula (3):
   cli: config: remove unnecessary braces from if blocks
   cli: add reply.honor_followup_to configuration option
   cli: support Mail-Followup-To: in notmuch reply

  notmuch-client.h |7 +++
  notmuch-config.c |   56 
 ++
  notmuch-reply.c  |   25 ++--
  3 files changed, 74 insertions(+), 14 deletions(-)

 -- 
 1.7.10.4

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

[PATCH v2 0/3] cli: clean up gmime 2.4 vs. 2.6 conditional build

[David Bremner]

Jani Nikula  writes:

> This is v2 of [1]. Added comments per David's request, and while at it,
> added a third patch to conform the existing conditional build in notmuch
> show to the same style. The whole series should have no functional
> changes, and thus v2 should have no functional changes since v1. ;)
>

Pushed.

d

Re: [PATCH v2 0/3] cli: clean up gmime 2.4 vs. 2.6 conditional build

[David Bremner]

Jani Nikula j...@nikula.org writes:

 This is v2 of [1]. Added comments per David's request, and while at it,
 added a third patch to conform the existing conditional build in notmuch
 show to the same style. The whole series should have no functional
 changes, and thus v2 should have no functional changes since v1. ;)


Pushed.

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

[PATCH v2 0/3] cli: clean up gmime 2.4 vs. 2.6 conditional build

[Tomi Ollila]

On Sun, Mar 31 2013, Tomi Ollila  wrote:

> On Sat, Mar 30 2013, Jani Nikula  wrote:
>
>> This is v2 of [1]. Added comments per David's request, and while at it,
>> added a third patch to conform the existing conditional build in notmuch
>> show to the same style. The whole series should have no functional
>> changes, and thus v2 should have no functional changes since v1. ;)
>>
>> I have not tested this on gmime 2.4.
>
> I have gmime 2.4(.24) on this system. The code compiles and
> exactly the same set of tests pass/fail as without this patch
> (unfortunately this system cannot cope with just some of the
> crypto patches, so I cannot give absolute guarantee:

Ok, the failure cases below are just those which are changed in
this patch. So I had to dig further...

... actually this
  'PASS   emacs delivery of encrypted message with attachment'
fails to deliver the message.

After the following change:

--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -442,7 +442,8 @@ emacs_deliver_message ()

 test_emacs \
"(let ((message-send-mail-function 'message-smtpmail-send-it)
-  (smtpmail-smtp-server \"localhost\")
+  (smtpmail-smtp-server 'local)
+  ;;(smtpmail-smtp-server \"localhost\")
   (smtpmail-smtp-service \"25025\"))
   (notmuch-hello)
   (notmuch-mua-mail)

The failured cases below PASSes.

(I've stumbled the same problem a few cases before but haven't 
figured out a good patch so far...)

>
> crypto: Testing PGP/MIME signature verification and decryption
>  PASS   emacs delivery of signed message
>  PASS   signature verification
>  PASS   signature verification with full owner trust
>  PASS   signature verification with signer key unavailable
>  PASS   emacs delivery of encrypted message with attachment
>  FAIL   decryption, --format=text
>  FAIL   decryption, --format=json
>  FAIL   decryption, --format=json, --part=4
>  FAIL   decrypt attachment (--part=5 --format=raw)
>  FAIL   decryption failure with missing key
>  PASS   emacs delivery of encrypted + signed message
>  FAIL   decryption + signature verification
>  FAIL   reply to encrypted message
>  FAIL   signature verification with revoked key
>
> anyway, as said, exactly the same set fails without these pathes
>
> The reason for failure is most probably in my system and not something
> w/ notmuch crypto support -- If I run `emacs foo.org.gpg` this just
> hangs waiting me to give passphrase in (invisible?) curses request)
>
> So, bottom line: LGTM.
>
>> BR,
>> Jani.
>
> Tomi
>
>
>> [1] id:a9f12ba474fc51df71e2fd2b7a20a8d101729c6e.1362319765.git.jani at 
>> nikula.org
>>
>> Jani Nikula (3):
>>   cli: crypto: abstract gpg context creation for clarity
>>   cli: mime node: abstract decryption and signature verification
>>   cli: conform to same conditional build style as elsewhere in
>> notmuch-show
>>
>>  crypto.c   |   66 -
>>  mime-node.c|  218 
>> 
>>  notmuch-show.c |   46 ++--
>>  3 files changed, 215 insertions(+), 115 deletions(-)
>>
>> -- 
>> 1.7.10.4

[PATCH v2 0/3] cli: clean up gmime 2.4 vs. 2.6 conditional build

[Tomi Ollila]

On Sat, Mar 30 2013, Jani Nikula  wrote:

> This is v2 of [1]. Added comments per David's request, and while at it,
> added a third patch to conform the existing conditional build in notmuch
> show to the same style. The whole series should have no functional
> changes, and thus v2 should have no functional changes since v1. ;)
>
> I have not tested this on gmime 2.4.

I have gmime 2.4(.24) on this system. The code compiles and
exactly the same set of tests pass/fail as without this patch
(unfortunately this system cannot cope with just some of the
crypto patches, so I cannot give absolute guarantee:

crypto: Testing PGP/MIME signature verification and decryption
 PASS   emacs delivery of signed message
 PASS   signature verification
 PASS   signature verification with full owner trust
 PASS   signature verification with signer key unavailable
 PASS   emacs delivery of encrypted message with attachment
 FAIL   decryption, --format=text
 FAIL   decryption, --format=json
 FAIL   decryption, --format=json, --part=4
 FAIL   decrypt attachment (--part=5 --format=raw)
 FAIL   decryption failure with missing key
 PASS   emacs delivery of encrypted + signed message
 FAIL   decryption + signature verification
 FAIL   reply to encrypted message
 FAIL   signature verification with revoked key

anyway, as said, exactly the same set fails without these pathes

The reason for failure is most probably in my system and not something
w/ notmuch crypto support -- If I run `emacs foo.org.gpg` this just
hangs waiting me to give passphrase in (invisible?) curses request)

So, bottom line: LGTM.

> BR,
> Jani.

Tomi


> [1] id:a9f12ba474fc51df71e2fd2b7a20a8d101729c6e.1362319765.git.jani at 
> nikula.org
>
> Jani Nikula (3):
>   cli: crypto: abstract gpg context creation for clarity
>   cli: mime node: abstract decryption and signature verification
>   cli: conform to same conditional build style as elsewhere in
> notmuch-show
>
>  crypto.c   |   66 -
>  mime-node.c|  218 
> 
>  notmuch-show.c |   46 ++--
>  3 files changed, 215 insertions(+), 115 deletions(-)
>
> -- 
> 1.7.10.4
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v2 0/3] cli: clean up gmime 2.4 vs. 2.6 conditional build

[Tomi Ollila]

On Sat, Mar 30 2013, Jani Nikula j...@nikula.org wrote:

 This is v2 of [1]. Added comments per David's request, and while at it,
 added a third patch to conform the existing conditional build in notmuch
 show to the same style. The whole series should have no functional
 changes, and thus v2 should have no functional changes since v1. ;)

 I have not tested this on gmime 2.4.

I have gmime 2.4(.24) on this system. The code compiles and
exactly the same set of tests pass/fail as without this patch
(unfortunately this system cannot cope with just some of the
crypto patches, so I cannot give absolute guarantee:

crypto: Testing PGP/MIME signature verification and decryption
 PASS   emacs delivery of signed message
 PASS   signature verification
 PASS   signature verification with full owner trust
 PASS   signature verification with signer key unavailable
 PASS   emacs delivery of encrypted message with attachment
 FAIL   decryption, --format=text
 FAIL   decryption, --format=json
 FAIL   decryption, --format=json, --part=4
 FAIL   decrypt attachment (--part=5 --format=raw)
 FAIL   decryption failure with missing key
 PASS   emacs delivery of encrypted + signed message
 FAIL   decryption + signature verification
 FAIL   reply to encrypted message
 FAIL   signature verification with revoked key

anyway, as said, exactly the same set fails without these pathes

The reason for failure is most probably in my system and not something
w/ notmuch crypto support -- If I run `emacs foo.org.gpg` this just
hangs waiting me to give passphrase in (invisible?) curses request)

So, bottom line: LGTM.

 BR,
 Jani.

Tomi


 [1] id:a9f12ba474fc51df71e2fd2b7a20a8d101729c6e.1362319765.git.j...@nikula.org

 Jani Nikula (3):
   cli: crypto: abstract gpg context creation for clarity
   cli: mime node: abstract decryption and signature verification
   cli: conform to same conditional build style as elsewhere in
 notmuch-show

  crypto.c   |   66 -
  mime-node.c|  218 
 
  notmuch-show.c |   46 ++--
  3 files changed, 215 insertions(+), 115 deletions(-)

 -- 
 1.7.10.4

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

Re: [PATCH v2 0/3] cli: clean up gmime 2.4 vs. 2.6 conditional build

[Tomi Ollila]

On Sun, Mar 31 2013, Tomi Ollila tomi.oll...@iki.fi wrote:

 On Sat, Mar 30 2013, Jani Nikula j...@nikula.org wrote:

 This is v2 of [1]. Added comments per David's request, and while at it,
 added a third patch to conform the existing conditional build in notmuch
 show to the same style. The whole series should have no functional
 changes, and thus v2 should have no functional changes since v1. ;)

 I have not tested this on gmime 2.4.

 I have gmime 2.4(.24) on this system. The code compiles and
 exactly the same set of tests pass/fail as without this patch
 (unfortunately this system cannot cope with just some of the
 crypto patches, so I cannot give absolute guarantee:

Ok, the failure cases below are just those which are changed in
this patch. So I had to dig further...

... actually this
  'PASS   emacs delivery of encrypted message with attachment'
fails to deliver the message.

After the following change:

--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -442,7 +442,8 @@ emacs_deliver_message ()
 
 test_emacs \
(let ((message-send-mail-function 'message-smtpmail-send-it)
-  (smtpmail-smtp-server \localhost\)
+  (smtpmail-smtp-server 'local)
+  ;;(smtpmail-smtp-server \localhost\)
   (smtpmail-smtp-service \25025\))
   (notmuch-hello)
   (notmuch-mua-mail)

The failured cases below PASSes.

(I've stumbled the same problem a few cases before but haven't 
figured out a good patch so far...)


 crypto: Testing PGP/MIME signature verification and decryption
  PASS   emacs delivery of signed message
  PASS   signature verification
  PASS   signature verification with full owner trust
  PASS   signature verification with signer key unavailable
  PASS   emacs delivery of encrypted message with attachment
  FAIL   decryption, --format=text
  FAIL   decryption, --format=json
  FAIL   decryption, --format=json, --part=4
  FAIL   decrypt attachment (--part=5 --format=raw)
  FAIL   decryption failure with missing key
  PASS   emacs delivery of encrypted + signed message
  FAIL   decryption + signature verification
  FAIL   reply to encrypted message
  FAIL   signature verification with revoked key

 anyway, as said, exactly the same set fails without these pathes

 The reason for failure is most probably in my system and not something
 w/ notmuch crypto support -- If I run `emacs foo.org.gpg` this just
 hangs waiting me to give passphrase in (invisible?) curses request)

 So, bottom line: LGTM.

 BR,
 Jani.

 Tomi


 [1] 
 id:a9f12ba474fc51df71e2fd2b7a20a8d101729c6e.1362319765.git.j...@nikula.org

 Jani Nikula (3):
   cli: crypto: abstract gpg context creation for clarity
   cli: mime node: abstract decryption and signature verification
   cli: conform to same conditional build style as elsewhere in
 notmuch-show

  crypto.c   |   66 -
  mime-node.c|  218 
 
  notmuch-show.c |   46 ++--
  3 files changed, 215 insertions(+), 115 deletions(-)

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

[PATCH v2 0/3] cli: mail-followup-to support

[Jani Nikula]

This is v2 of [1], rebased against master and with a better commit
message for patch 1/3. Patch 1/3 is trivial cleanup and IMO could just
be merged. There was debate on the actual stuff 2/3 and 3/3 [2].

I don't think adding a --reply-to=list option to notmuch reply is a good
idea. We should just do the right thing and keep the cli simple. Perhaps
we should drop the configuration (patch 2/3) altogether, and just
support mail-followup-to?

Or, perhaps notmuch reply should return *all* options in json, and let
the UI decide. Above all, let the UI change the reply style while
editing the reply. I'd probably like this approach most, more than these
patches, but I don't have the time to do it.

Here are the patches anyway; perhaps they could be an intermediate step,
or just a reference for anyone willing to do the above.


BR,
Jani.


[1] id:5eaa3acc22ee5513bdce5ab931b7a79ade880e06.1362254104.git.jani at 
nikula.org
[2] id:20130303120745.GA4884 at hili.localdomain

Jani Nikula (3):
  cli: config: remove unnecessary braces from if blocks
  cli: add reply.honor_followup_to configuration option
  cli: support Mail-Followup-To: in notmuch reply

 notmuch-client.h |7 +++
 notmuch-config.c |   56 ++
 notmuch-reply.c  |   25 ++--
 3 files changed, 74 insertions(+), 14 deletions(-)

-- 
1.7.10.4

[PATCH v2 0/3] cli: clean up gmime 2.4 vs. 2.6 conditional build

[Jani Nikula]

This is v2 of [1]. Added comments per David's request, and while at it,
added a third patch to conform the existing conditional build in notmuch
show to the same style. The whole series should have no functional
changes, and thus v2 should have no functional changes since v1. ;)

I have not tested this on gmime 2.4.

BR,
Jani.


[1] id:a9f12ba474fc51df71e2fd2b7a20a8d101729c6e.1362319765.git.j...@nikula.org

Jani Nikula (3):
  cli: crypto: abstract gpg context creation for clarity
  cli: mime node: abstract decryption and signature verification
  cli: conform to same conditional build style as elsewhere in
notmuch-show

 crypto.c   |   66 -
 mime-node.c|  218 
 notmuch-show.c |   46 ++--
 3 files changed, 215 insertions(+), 115 deletions(-)

-- 
1.7.10.4

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

[PATCH v2 0/3] cli: mail-followup-to support

[Jani Nikula]

This is v2 of [1], rebased against master and with a better commit
message for patch 1/3. Patch 1/3 is trivial cleanup and IMO could just
be merged. There was debate on the actual stuff 2/3 and 3/3 [2].

I don't think adding a --reply-to=list option to notmuch reply is a good
idea. We should just do the right thing and keep the cli simple. Perhaps
we should drop the configuration (patch 2/3) altogether, and just
support mail-followup-to?

Or, perhaps notmuch reply should return *all* options in json, and let
the UI decide. Above all, let the UI change the reply style while
editing the reply. I'd probably like this approach most, more than these
patches, but I don't have the time to do it.

Here are the patches anyway; perhaps they could be an intermediate step,
or just a reference for anyone willing to do the above.


BR,
Jani.


[1] id:5eaa3acc22ee5513bdce5ab931b7a79ade880e06.1362254104.git.j...@nikula.org
[2] id:20130303120745.GA4884@hili.localdomain

Jani Nikula (3):
  cli: config: remove unnecessary braces from if blocks
  cli: add reply.honor_followup_to configuration option
  cli: support Mail-Followup-To: in notmuch reply

 notmuch-client.h |7 +++
 notmuch-config.c |   56 ++
 notmuch-reply.c  |   25 ++--
 3 files changed, 74 insertions(+), 14 deletions(-)

-- 
1.7.10.4

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

[PATCH v2 0/3] Allow emacs to toggle display of all parts including multipart

[Mark Walters]

Hi

I now have a version which does this `right': using invisibility as with
citations and signatures etc. It is working but I need to look through
more carefully before posting.

Best wishes

Mark

On Mon, 03 Dec 2012, Mark Walters  wrote:
> This is rather more polished version of
> id:1351152563-27277-1-git-send-email-markwalters1009 at gmail.com.
>
> The first patch modifies the behaviour of show refresh buffer to keep
> state more accurately where possible. It can never be perfect but it
> makes a reasonable attempt. This is independent of patches 2 and 3.
>
> The second patch allows the user to toggle the visibility of any part
> with 't' on the part button. It does this by storing a list of all
> parts that the user has over-ruled.
>
> The final patch binds the toggle to the default action in cases where
> the part has no filename. Is this a reasonable heuristic? And should
> it be customisable? In all cases the defined actions (save, view,
> other, and toggle) always do their action (ie they do not apply any
> heuristics)
>
> Overall I am pleased with the way it works. The one caveat is that it
> does redisplay the whole buffer when toggling the parts: it might be
> nice to use invisibility but that is beyond my lisp. Moreover it could
> be added at a later stage without changing the user experience.
>
>
> Best wishes
>
> Mark
>
>
> Mark Walters (3):
>   emacs: show: make refresh fix point(ish)
>   emacs: allow the user to toggle the visibility of
> multipart/alternative parts
>   emacs: show make default part button toggle view when sensible
>
>  emacs/notmuch-show.el |   80 ++--
>  1 files changed, 63 insertions(+), 17 deletions(-)
>
> -- 
> 1.7.9.1

[PATCH v2 0/3] Allow emacs to toggle display of all parts including multipart

[Mark Walters]

This is rather more polished version of
id:1351152563-27277-1-git-send-email-markwalters1009 at gmail.com.

The first patch modifies the behaviour of show refresh buffer to keep
state more accurately where possible. It can never be perfect but it
makes a reasonable attempt. This is independent of patches 2 and 3.

The second patch allows the user to toggle the visibility of any part
with 't' on the part button. It does this by storing a list of all
parts that the user has over-ruled.

The final patch binds the toggle to the default action in cases where
the part has no filename. Is this a reasonable heuristic? And should
it be customisable? In all cases the defined actions (save, view,
other, and toggle) always do their action (ie they do not apply any
heuristics)

Overall I am pleased with the way it works. The one caveat is that it
does redisplay the whole buffer when toggling the parts: it might be
nice to use invisibility but that is beyond my lisp. Moreover it could
be added at a later stage without changing the user experience.


Best wishes

Mark


Mark Walters (3):
  emacs: show: make refresh fix point(ish)
  emacs: allow the user to toggle the visibility of
multipart/alternative parts
  emacs: show make default part button toggle view when sensible

 emacs/notmuch-show.el |   80 ++--
 1 files changed, 63 insertions(+), 17 deletions(-)

-- 
1.7.9.1

Re: [PATCH v2 0/3] Allow emacs to toggle display of all parts including multipart

[Mark Walters]

Hi

I now have a version which does this `right': using invisibility as with
citations and signatures etc. It is working but I need to look through
more carefully before posting.

Best wishes

Mark

On Mon, 03 Dec 2012, Mark Walters markwalters1...@gmail.com wrote:
 This is rather more polished version of
 id:1351152563-27277-1-git-send-email-markwalters1...@gmail.com.

 The first patch modifies the behaviour of show refresh buffer to keep
 state more accurately where possible. It can never be perfect but it
 makes a reasonable attempt. This is independent of patches 2 and 3.

 The second patch allows the user to toggle the visibility of any part
 with 't' on the part button. It does this by storing a list of all
 parts that the user has over-ruled.

 The final patch binds the toggle to the default action in cases where
 the part has no filename. Is this a reasonable heuristic? And should
 it be customisable? In all cases the defined actions (save, view,
 other, and toggle) always do their action (ie they do not apply any
 heuristics)

 Overall I am pleased with the way it works. The one caveat is that it
 does redisplay the whole buffer when toggling the parts: it might be
 nice to use invisibility but that is beyond my lisp. Moreover it could
 be added at a later stage without changing the user experience.


 Best wishes

 Mark


 Mark Walters (3):
   emacs: show: make refresh fix point(ish)
   emacs: allow the user to toggle the visibility of
 multipart/alternative parts
   emacs: show make default part button toggle view when sensible

  emacs/notmuch-show.el |   80 ++--
  1 files changed, 63 insertions(+), 17 deletions(-)

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

[PATCH v2 0/3] Allow emacs to toggle display of all parts including multipart

[Mark Walters]

This is rather more polished version of
id:1351152563-27277-1-git-send-email-markwalters1...@gmail.com.

The first patch modifies the behaviour of show refresh buffer to keep
state more accurately where possible. It can never be perfect but it
makes a reasonable attempt. This is independent of patches 2 and 3.

The second patch allows the user to toggle the visibility of any part
with 't' on the part button. It does this by storing a list of all
parts that the user has over-ruled.

The final patch binds the toggle to the default action in cases where
the part has no filename. Is this a reasonable heuristic? And should
it be customisable? In all cases the defined actions (save, view,
other, and toggle) always do their action (ie they do not apply any
heuristics)

Overall I am pleased with the way it works. The one caveat is that it
does redisplay the whole buffer when toggling the parts: it might be
nice to use invisibility but that is beyond my lisp. Moreover it could
be added at a later stage without changing the user experience.


Best wishes

Mark


Mark Walters (3):
  emacs: show: make refresh fix point(ish)
  emacs: allow the user to toggle the visibility of
multipart/alternative parts
  emacs: show make default part button toggle view when sensible

 emacs/notmuch-show.el |   80 ++--
 1 files changed, 63 insertions(+), 17 deletions(-)

-- 
1.7.9.1

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

[PATCH v2 0/3] Better id: link buttonization

[Tomi Ollila]

On Wed, Nov 14 2012, Ethan Glasser-Camp wrote:

> Austin Clements  writes:
>
>> This is v2 of id:"1351650561-7331-1-git-send-email-amdragon at mit.edu".
>> This makes Jani's suggested additions to the regexp and adds support
>> for RFC 2392 mid: links, as suggested by Sascha.
>
> This series looks fine to me.

LGTM too. 

although this is different than others in test/emacs:

 +test_expect_equal_file EXPECTED OUTPUT

(grep test_expect_equal_file test/emacs)

The diff output in case of failure makes more sense when the args
are in this order -- but probably that should be changed
bu changing the arg handling order in test_expect_equal_file
(to be consistent with test_expect_equal) and then change the order
in the "remaining" uses of test_expect_equal_file EXPECTED OUTPUT.

> Ethan

Tomi

Re: [PATCH v2 0/3] Better id: link buttonization

[Tomi Ollila]

On Wed, Nov 14 2012, Ethan Glasser-Camp wrote:

 Austin Clements amdra...@mit.edu writes:

 This is v2 of id:1351650561-7331-1-git-send-email-amdra...@mit.edu.
 This makes Jani's suggested additions to the regexp and adds support
 for RFC 2392 mid: links, as suggested by Sascha.

 This series looks fine to me.

LGTM too. 

although this is different than others in test/emacs:

 +test_expect_equal_file EXPECTED OUTPUT

(grep test_expect_equal_file test/emacs)

The diff output in case of failure makes more sense when the args
are in this order -- but probably that should be changed
bu changing the arg handling order in test_expect_equal_file
(to be consistent with test_expect_equal) and then change the order
in the remaining uses of test_expect_equal_file EXPECTED OUTPUT.

 Ethan

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

[PATCH v2 0/3] Better id: link buttonization

[Ethan Glasser-Camp]

Austin Clements  writes:

> This is v2 of id:"1351650561-7331-1-git-send-email-amdragon at mit.edu".
> This makes Jani's suggested additions to the regexp and adds support
> for RFC 2392 mid: links, as suggested by Sascha.

This series looks fine to me.

Ethan

Re: [PATCH v2 0/3] Better id: link buttonization

[Ethan Glasser-Camp]

Austin Clements amdra...@mit.edu writes:

 This is v2 of id:1351650561-7331-1-git-send-email-amdra...@mit.edu.
 This makes Jani's suggested additions to the regexp and adds support
 for RFC 2392 mid: links, as suggested by Sascha.

This series looks fine to me.

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

[PATCH v2 0/3] Better id: link buttonization

[Austin Clements]

This is v2 of id:"1351650561-7331-1-git-send-email-amdragon at mit.edu".
This makes Jani's suggested additions to the regexp and adds support
for RFC 2392 mid: links, as suggested by Sascha.

[PATCH v2 0/3] Better id: link buttonization

[Austin Clements]

This is v2 of id:1351650561-7331-1-git-send-email-amdra...@mit.edu.
This makes Jani's suggested additions to the regexp and adds support
for RFC 2392 mid: links, as suggested by Sascha.

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

[PATCH v2 0/3] indicate length of omitted body content

[Peter Wang]

The first commit is tangentally related.  An expected test case output
in test/crypto previously had a filename left unnormalised by
notmuch_json_show_sanitize because it was not followed by comma.
The next commit causes the comma to be present, breaking the expected
output.

In the 2nd commit, a content-transfer-encoding field was added and
comments clarified.

In the 3rd commit, the content-length of an encrypted attachment had
to be normalised because it varies between runs.

Peter Wang (3):
  test: normalize only message filenames in show json
  show: indicate length, encoding of omitted body content
  test: conform to content length, encoding fields

 devel/schemata   |9 -
 notmuch-show.c   |   14 ++
 test/crypto  |   30 +-
 test/json|2 +-
 test/multipart   |   11 ++-
 test/test-lib.sh |2 +-
 6 files changed, 51 insertions(+), 17 deletions(-)

-- 
1.7.4.4

[PATCH v2 0/3] indicate length of omitted body content

[Peter Wang]

The first commit is tangentally related.  An expected test case output
in test/crypto previously had a filename left unnormalised by
notmuch_json_show_sanitize because it was not followed by comma.
The next commit causes the comma to be present, breaking the expected
output.

In the 2nd commit, a content-transfer-encoding field was added and
comments clarified.

In the 3rd commit, the content-length of an encrypted attachment had
to be normalised because it varies between runs.

Peter Wang (3):
  test: normalize only message filenames in show json
  show: indicate length, encoding of omitted body content
  test: conform to content length, encoding fields

 devel/schemata   |9 -
 notmuch-show.c   |   14 ++
 test/crypto  |   30 +-
 test/json|2 +-
 test/multipart   |   11 ++-
 test/test-lib.sh |2 +-
 6 files changed, 51 insertions(+), 17 deletions(-)

-- 
1.7.4.4

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

[Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Jani Nikula]

On Fri, 04 May 2012, Mark Walters  wrote:
> On Wed, 02 May 2012, Jameson Graef Rollins  
> wrote:
>> On Sun, Apr 29 2012, Austin Clements  wrote:
>>> I haven't really looked at this series yet, but I do have a quick
>>> high-level question.  Why use separate customization variables for the
>>> colors in search and show mode?  Wouldn't it make more sense to set
>>> the colors just once and use them in both modes?
>>
>> I thought about this myself as soon as I read the patch.  I think I
>> would always want the colors to match, so it would make sense to me to
>> set them in one place.
>
> Hi
>
> I think both are useful (see my reply to Austin) but having show apply
> the faces from notmuch-search first seems a good idea.
>
> There are a couple of extra reasons why I like the show ones
> separate. One is that I like to colour headerlines of matching messages to
> highlight them, but in search mode that would highlight every
> line. Secondly, I colour some things "negatively" in show mode: for
> example I show excluded messages in grey. This negative colouring does
> not make sense for search mode because I would only want to grey out
> results where all messages were excluded not results where at least one
> message is excluded. Of course we don't show entirely excluded threads
> in search, but similar comments apply to say the "replied" tag: I could
> show those in green (on the basis they are "dealt with") but I would not
> want a thread coloured green just because I have replied to one message
> in it.

I completely agree with having separate faces for search and show.

>>> BTW, I like how this clearly distinguishes tags and flags.  I wonder
>>> if we could transition to flags for some information that's current
>>> shoe-horned into tags but actually represents immutable information
>>> about a message (attachment, signed, and encrypted or so).
>>
>> Yes!  As Austin probably remembers, we've discussed this before.  I
>> definitely agree that it makes sense to somehow distinguish "immutable"
>> information that is a fundamental, unchanging/able property of the
>> message, and it might be nice to look ahead to that here.
>
> In essence I agree: my only concern is can the user search for these
> immutable things, and what syntax is used there. 

Making a separation between immutable properties (like "attachment" or
"signed") and tags is a good goal, but AFAICS doing that right requires
changes all the way down to the library. I wouldn't worry about it at
all here. From emacs UI perspective they're all just tags. This is here
now, and works; there's no need to complicate matters when there's
nobody doing anything about the plumbing. Fixing this later is a trivial
matter compared to the plumbing work in cli and lib.


BR,
Jani.



>
> Best wishes
>
> Mark
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: [Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Jani Nikula]

On Fri, 04 May 2012, Mark Walters markwalters1...@gmail.com wrote:
 On Wed, 02 May 2012, Jameson Graef Rollins jroll...@finestructure.net wrote:
 On Sun, Apr 29 2012, Austin Clements amdra...@mit.edu wrote:
 I haven't really looked at this series yet, but I do have a quick
 high-level question.  Why use separate customization variables for the
 colors in search and show mode?  Wouldn't it make more sense to set
 the colors just once and use them in both modes?

 I thought about this myself as soon as I read the patch.  I think I
 would always want the colors to match, so it would make sense to me to
 set them in one place.

 Hi

 I think both are useful (see my reply to Austin) but having show apply
 the faces from notmuch-search first seems a good idea.

 There are a couple of extra reasons why I like the show ones
 separate. One is that I like to colour headerlines of matching messages to
 highlight them, but in search mode that would highlight every
 line. Secondly, I colour some things negatively in show mode: for
 example I show excluded messages in grey. This negative colouring does
 not make sense for search mode because I would only want to grey out
 results where all messages were excluded not results where at least one
 message is excluded. Of course we don't show entirely excluded threads
 in search, but similar comments apply to say the replied tag: I could
 show those in green (on the basis they are dealt with) but I would not
 want a thread coloured green just because I have replied to one message
 in it.

I completely agree with having separate faces for search and show.

 BTW, I like how this clearly distinguishes tags and flags.  I wonder
 if we could transition to flags for some information that's current
 shoe-horned into tags but actually represents immutable information
 about a message (attachment, signed, and encrypted or so).

 Yes!  As Austin probably remembers, we've discussed this before.  I
 definitely agree that it makes sense to somehow distinguish immutable
 information that is a fundamental, unchanging/able property of the
 message, and it might be nice to look ahead to that here.

 In essence I agree: my only concern is can the user search for these
 immutable things, and what syntax is used there. 

Making a separation between immutable properties (like attachment or
signed) and tags is a good goal, but AFAICS doing that right requires
changes all the way down to the library. I wouldn't worry about it at
all here. From emacs UI perspective they're all just tags. This is here
now, and works; there's no need to complicate matters when there's
nobody doing anything about the plumbing. Fixing this later is a trivial
matter compared to the plumbing work in cli and lib.


BR,
Jani.




 Best wishes

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

[Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Jameson Graef Rollins]

On Thu, May 03 2012, Mark Walters  wrote:
> There are a couple of extra reasons why I like the show ones
> separate. One is that I like to colour headerlines of matching messages to
> highlight them, but in search mode that would highlight every
> line. Secondly, I colour some things "negatively" in show mode: for
> example I show excluded messages in grey. This negative colouring does
> not make sense for search mode because I would only want to grey out
> results where all messages were excluded not results where at least one
> message is excluded. Of course we don't show entirely excluded threads
> in search, but similar comments apply to say the "replied" tag: I could
> show those in green (on the basis they are "dealt with") but I would not
> want a thread coloured green just because I have replied to one message
> in it.

Ok, that makes sense.  Maybe there could be switch to inherit colors,
and then a way to set them independently as well.

>>> BTW, I like how this clearly distinguishes tags and flags.  I wonder
>>> if we could transition to flags for some information that's current
>>> shoe-horned into tags but actually represents immutable information
>>> about a message (attachment, signed, and encrypted or so).
>>
>> Yes!  As Austin probably remembers, we've discussed this before.  I
>> definitely agree that it makes sense to somehow distinguish "immutable"
>> information that is a fundamental, unchanging/able property of the
>> message, and it might be nice to look ahead to that here.
>
> In essence I agree: my only concern is can the user search for these
> immutable things, and what syntax is used there. 

Well, nothing exists yet so we can define it as we wish, but I would say
absolutely they should be searchable.  That's an important part.  They
just wouldn't be changable, like tags are, since they represent
immutable characteristics of the original message.  I would suggest we
use something like "prop:" (for "property"), e.g. "prop:signed", or
"prop:attachment", etc.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Mark Walters]

On Wed, 02 May 2012, Jameson Graef Rollins  
wrote:
> On Sun, Apr 29 2012, Austin Clements  wrote:
>> I haven't really looked at this series yet, but I do have a quick
>> high-level question.  Why use separate customization variables for the
>> colors in search and show mode?  Wouldn't it make more sense to set
>> the colors just once and use them in both modes?
>
> I thought about this myself as soon as I read the patch.  I think I
> would always want the colors to match, so it would make sense to me to
> set them in one place.

Hi

I think both are useful (see my reply to Austin) but having show apply
the faces from notmuch-search first seems a good idea.

There are a couple of extra reasons why I like the show ones
separate. One is that I like to colour headerlines of matching messages to
highlight them, but in search mode that would highlight every
line. Secondly, I colour some things "negatively" in show mode: for
example I show excluded messages in grey. This negative colouring does
not make sense for search mode because I would only want to grey out
results where all messages were excluded not results where at least one
message is excluded. Of course we don't show entirely excluded threads
in search, but similar comments apply to say the "replied" tag: I could
show those in green (on the basis they are "dealt with") but I would not
want a thread coloured green just because I have replied to one message
in it.

>
>> BTW, I like how this clearly distinguishes tags and flags.  I wonder
>> if we could transition to flags for some information that's current
>> shoe-horned into tags but actually represents immutable information
>> about a message (attachment, signed, and encrypted or so).
>
> Yes!  As Austin probably remembers, we've discussed this before.  I
> definitely agree that it makes sense to somehow distinguish "immutable"
> information that is a fundamental, unchanging/able property of the
> message, and it might be nice to look ahead to that here.

In essence I agree: my only concern is can the user search for these
immutable things, and what syntax is used there. 

Best wishes

Mark

Re: [Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Jameson Graef Rollins]

On Thu, May 03 2012, Mark Walters markwalters1...@gmail.com wrote:
 There are a couple of extra reasons why I like the show ones
 separate. One is that I like to colour headerlines of matching messages to
 highlight them, but in search mode that would highlight every
 line. Secondly, I colour some things negatively in show mode: for
 example I show excluded messages in grey. This negative colouring does
 not make sense for search mode because I would only want to grey out
 results where all messages were excluded not results where at least one
 message is excluded. Of course we don't show entirely excluded threads
 in search, but similar comments apply to say the replied tag: I could
 show those in green (on the basis they are dealt with) but I would not
 want a thread coloured green just because I have replied to one message
 in it.

Ok, that makes sense.  Maybe there could be switch to inherit colors,
and then a way to set them independently as well.

 BTW, I like how this clearly distinguishes tags and flags.  I wonder
 if we could transition to flags for some information that's current
 shoe-horned into tags but actually represents immutable information
 about a message (attachment, signed, and encrypted or so).

 Yes!  As Austin probably remembers, we've discussed this before.  I
 definitely agree that it makes sense to somehow distinguish immutable
 information that is a fundamental, unchanging/able property of the
 message, and it might be nice to look ahead to that here.

 In essence I agree: my only concern is can the user search for these
 immutable things, and what syntax is used there. 

Well, nothing exists yet so we can define it as we wish, but I would say
absolutely they should be searchable.  That's an important part.  They
just wouldn't be changable, like tags are, since they represent
immutable characteristics of the original message.  I would suggest we
use something like prop: (for property), e.g. prop:signed, or
prop:attachment, etc.

jamie.


pgp2wN9NfNqGz.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Mark Walters]

On Wed, 02 May 2012, Jameson Graef Rollins jroll...@finestructure.net wrote:
 On Sun, Apr 29 2012, Austin Clements amdra...@mit.edu wrote:
 I haven't really looked at this series yet, but I do have a quick
 high-level question.  Why use separate customization variables for the
 colors in search and show mode?  Wouldn't it make more sense to set
 the colors just once and use them in both modes?

 I thought about this myself as soon as I read the patch.  I think I
 would always want the colors to match, so it would make sense to me to
 set them in one place.

Hi

I think both are useful (see my reply to Austin) but having show apply
the faces from notmuch-search first seems a good idea.

There are a couple of extra reasons why I like the show ones
separate. One is that I like to colour headerlines of matching messages to
highlight them, but in search mode that would highlight every
line. Secondly, I colour some things negatively in show mode: for
example I show excluded messages in grey. This negative colouring does
not make sense for search mode because I would only want to grey out
results where all messages were excluded not results where at least one
message is excluded. Of course we don't show entirely excluded threads
in search, but similar comments apply to say the replied tag: I could
show those in green (on the basis they are dealt with) but I would not
want a thread coloured green just because I have replied to one message
in it.


 BTW, I like how this clearly distinguishes tags and flags.  I wonder
 if we could transition to flags for some information that's current
 shoe-horned into tags but actually represents immutable information
 about a message (attachment, signed, and encrypted or so).

 Yes!  As Austin probably remembers, we've discussed this before.  I
 definitely agree that it makes sense to somehow distinguish immutable
 information that is a fundamental, unchanging/able property of the
 message, and it might be nice to look ahead to that here.

In essence I agree: my only concern is can the user search for these
immutable things, and what syntax is used there. 

Best wishes

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

[Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Jameson Graef Rollins]

On Sun, Apr 29 2012, Austin Clements  wrote:
> I haven't really looked at this series yet, but I do have a quick
> high-level question.  Why use separate customization variables for the
> colors in search and show mode?  Wouldn't it make more sense to set
> the colors just once and use them in both modes?

I thought about this myself as soon as I read the patch.  I think I
would always want the colors to match, so it would make sense to me to
set them in one place.

> BTW, I like how this clearly distinguishes tags and flags.  I wonder
> if we could transition to flags for some information that's current
> shoe-horned into tags but actually represents immutable information
> about a message (attachment, signed, and encrypted or so).

Yes!  As Austin probably remembers, we've discussed this before.  I
definitely agree that it makes sense to somehow distinguish "immutable"
information that is a fundamental, unchanging/able property of the
message, and it might be nice to look ahead to that here.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

Re: [Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Jameson Graef Rollins]

On Sun, Apr 29 2012, Austin Clements amdra...@mit.edu wrote:
 I haven't really looked at this series yet, but I do have a quick
 high-level question.  Why use separate customization variables for the
 colors in search and show mode?  Wouldn't it make more sense to set
 the colors just once and use them in both modes?

I thought about this myself as soon as I read the patch.  I think I
would always want the colors to match, so it would make sense to me to
set them in one place.

 BTW, I like how this clearly distinguishes tags and flags.  I wonder
 if we could transition to flags for some information that's current
 shoe-horned into tags but actually represents immutable information
 about a message (attachment, signed, and encrypted or so).

Yes!  As Austin probably remembers, we've discussed this before.  I
definitely agree that it makes sense to somehow distinguish immutable
information that is a fundamental, unchanging/able property of the
message, and it might be nice to look ahead to that here.

jamie.


pgpSrbgQN56ES.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Mark Walters]

On Mon, 30 Apr 2012, Austin Clements  wrote:
> I haven't really looked at this series yet, but I do have a quick
> high-level question.  Why use separate customization variables for the
> colors in search and show mode?  Wouldn't it make more sense to set
> the colors just once and use them in both modes?

I think that their use is somewhat different since in show mode the
colour can be quite high contrast because mostly you only have a few
header lines (that may depend how much time you spend in
expanded/collapsed views); one example is that in show mode the header
line normally has a background colour (I think even without
customisation) whereas in search mode that would be weird as every line
would have it.

> BTW, I like how this clearly distinguishes tags and flags.  I wonder
> if we could transition to flags for some information that's current
> shoe-horned into tags but actually represents immutable information
> about a message (attachment, signed, and encrypted or so).

Yes some of those could make sense: I hadn't thought about them at
all. I think attachment is closer to a genuine tag as I frequently include
tag:attachment in my searched but I would guess that searching for
signed/encrypted is not as common (but I don't use either so could be wrong)

> My one concern is that there's a common tag called "flagged", so this
> might be overloading terminology.

I hadn't thought of that: I agree but don't have a good suggestion for
avoiding it. 

Best wishes

Mark


>
> Quoth Mark Walters on Apr 29 at 11:48 pm:
>> This is a rebased (but otherwise unchanged) version of
>> id:"1334431301-27303-1-git-send-email-markwalters1009 at gmail.com".
>> 
>> It's probably too late for 0.13 but in case anyone would like to look
>> at it this version applies cleanly to master so should be easier to
>> test.
>> 
>> The first two patches are basically David Edmondson's patch
>> id:"1325006003-27152-1-git-send-email-dme at dme.org".
>> 
>> Best wishes
>> 
>> Mark
>> 
>> 
>> Mark Walters (3):
>>   emacs: Move colour line from search to lib
>>   emacs: Add `notmuch-show-line-faces' and apply it.
>>   emacs: allow notmuch-show-line-faces to use flags for colouring
>> 
>>  emacs/notmuch-lib.el  |   18 ++
>>  emacs/notmuch-show.el |   44 
>>  emacs/notmuch.el  |   15 +--
>>  3 files changed, 59 insertions(+), 18 deletions(-)

[Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Mark Walters]

This is a rebased (but otherwise unchanged) version of
id:"1334431301-27303-1-git-send-email-markwalters1009 at gmail.com".

It's probably too late for 0.13 but in case anyone would like to look
at it this version applies cleanly to master so should be easier to
test.

The first two patches are basically David Edmondson's patch
id:"1325006003-27152-1-git-send-email-dme at dme.org".

Best wishes

Mark


Mark Walters (3):
  emacs: Move colour line from search to lib
  emacs: Add `notmuch-show-line-faces' and apply it.
  emacs: allow notmuch-show-line-faces to use flags for colouring

 emacs/notmuch-lib.el  |   18 ++
 emacs/notmuch-show.el |   44 
 emacs/notmuch.el  |   15 +--
 3 files changed, 59 insertions(+), 18 deletions(-)

-- 
1.7.9.1

[Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Austin Clements]

I haven't really looked at this series yet, but I do have a quick
high-level question.  Why use separate customization variables for the
colors in search and show mode?  Wouldn't it make more sense to set
the colors just once and use them in both modes?

BTW, I like how this clearly distinguishes tags and flags.  I wonder
if we could transition to flags for some information that's current
shoe-horned into tags but actually represents immutable information
about a message (attachment, signed, and encrypted or so).

My one concern is that there's a common tag called "flagged", so this
might be overloading terminology.

Quoth Mark Walters on Apr 29 at 11:48 pm:
> This is a rebased (but otherwise unchanged) version of
> id:"1334431301-27303-1-git-send-email-markwalters1009 at gmail.com".
> 
> It's probably too late for 0.13 but in case anyone would like to look
> at it this version applies cleanly to master so should be easier to
> test.
> 
> The first two patches are basically David Edmondson's patch
> id:"1325006003-27152-1-git-send-email-dme at dme.org".
> 
> Best wishes
> 
> Mark
> 
> 
> Mark Walters (3):
>   emacs: Move colour line from search to lib
>   emacs: Add `notmuch-show-line-faces' and apply it.
>   emacs: allow notmuch-show-line-faces to use flags for colouring
> 
>  emacs/notmuch-lib.el  |   18 ++
>  emacs/notmuch-show.el |   44 
>  emacs/notmuch.el  |   15 +--
>  3 files changed, 59 insertions(+), 18 deletions(-)

[Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Mark Walters]

This is a rebased (but otherwise unchanged) version of
id:1334431301-27303-1-git-send-email-markwalters1...@gmail.com.

It's probably too late for 0.13 but in case anyone would like to look
at it this version applies cleanly to master so should be easier to
test.

The first two patches are basically David Edmondson's patch
id:1325006003-27152-1-git-send-email-...@dme.org.

Best wishes

Mark


Mark Walters (3):
  emacs: Move colour line from search to lib
  emacs: Add `notmuch-show-line-faces' and apply it.
  emacs: allow notmuch-show-line-faces to use flags for colouring

 emacs/notmuch-lib.el  |   18 ++
 emacs/notmuch-show.el |   44 
 emacs/notmuch.el  |   15 +--
 3 files changed, 59 insertions(+), 18 deletions(-)

-- 
1.7.9.1

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

Re: [Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Austin Clements]

I haven't really looked at this series yet, but I do have a quick
high-level question.  Why use separate customization variables for the
colors in search and show mode?  Wouldn't it make more sense to set
the colors just once and use them in both modes?

BTW, I like how this clearly distinguishes tags and flags.  I wonder
if we could transition to flags for some information that's current
shoe-horned into tags but actually represents immutable information
about a message (attachment, signed, and encrypted or so).

My one concern is that there's a common tag called flagged, so this
might be overloading terminology.

Quoth Mark Walters on Apr 29 at 11:48 pm:
 This is a rebased (but otherwise unchanged) version of
 id:1334431301-27303-1-git-send-email-markwalters1...@gmail.com.
 
 It's probably too late for 0.13 but in case anyone would like to look
 at it this version applies cleanly to master so should be easier to
 test.
 
 The first two patches are basically David Edmondson's patch
 id:1325006003-27152-1-git-send-email-...@dme.org.
 
 Best wishes
 
 Mark
 
 
 Mark Walters (3):
   emacs: Move colour line from search to lib
   emacs: Add `notmuch-show-line-faces' and apply it.
   emacs: allow notmuch-show-line-faces to use flags for colouring
 
  emacs/notmuch-lib.el  |   18 ++
  emacs/notmuch-show.el |   44 
  emacs/notmuch.el  |   15 +--
  3 files changed, 59 insertions(+), 18 deletions(-)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Mark Walters]

On Mon, 30 Apr 2012, Austin Clements amdra...@mit.edu wrote:
 I haven't really looked at this series yet, but I do have a quick
 high-level question.  Why use separate customization variables for the
 colors in search and show mode?  Wouldn't it make more sense to set
 the colors just once and use them in both modes?

I think that their use is somewhat different since in show mode the
colour can be quite high contrast because mostly you only have a few
header lines (that may depend how much time you spend in
expanded/collapsed views); one example is that in show mode the header
line normally has a background colour (I think even without
customisation) whereas in search mode that would be weird as every line
would have it.

 BTW, I like how this clearly distinguishes tags and flags.  I wonder
 if we could transition to flags for some information that's current
 shoe-horned into tags but actually represents immutable information
 about a message (attachment, signed, and encrypted or so).

Yes some of those could make sense: I hadn't thought about them at
all. I think attachment is closer to a genuine tag as I frequently include
tag:attachment in my searched but I would guess that searching for
signed/encrypted is not as common (but I don't use either so could be wrong)

 My one concern is that there's a common tag called flagged, so this
 might be overloading terminology.

I hadn't thought of that: I agree but don't have a good suggestion for
avoiding it. 

Best wishes

Mark



 Quoth Mark Walters on Apr 29 at 11:48 pm:
 This is a rebased (but otherwise unchanged) version of
 id:1334431301-27303-1-git-send-email-markwalters1...@gmail.com.
 
 It's probably too late for 0.13 but in case anyone would like to look
 at it this version applies cleanly to master so should be easier to
 test.
 
 The first two patches are basically David Edmondson's patch
 id:1325006003-27152-1-git-send-email-...@dme.org.
 
 Best wishes
 
 Mark
 
 
 Mark Walters (3):
   emacs: Move colour line from search to lib
   emacs: Add `notmuch-show-line-faces' and apply it.
   emacs: allow notmuch-show-line-faces to use flags for colouring
 
  emacs/notmuch-lib.el  |   18 ++
  emacs/notmuch-show.el |   44 
  emacs/notmuch.el  |   15 +--
  3 files changed, 59 insertions(+), 18 deletions(-)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2 0/3] composing patches

[Felipe Contreras]

Hi,

I don't know how it works in gnus, but at least on the vim mode, the output
generated by 'notmuch reply' is not ready to be sent, at least the Message-ID
field is needed, and also is nice to have the User-Agent.

Besides, in order to avoid creating a new message by hand (possibly fetching
the info from notmuch config), it's more straightforward to have 'notmuch
compose' command.

In the future 'notmuch compose' might be used to replace 'notmuch reply' and
possily add a forward option too. It might also be possible to add mail aliases
when composing a message, and these aliases might be used while generating the
'notmuch search' output.

Although we are adding extra fields in notmuch reply, higher layers can just
override them easily.

Felipe Contreras (3):
  Add 'compose' command
  reply: add message-id header
  reply: add user-agent field

 Makefile.local|1 +
 notmuch-client.h  |3 ++
 notmuch-compose.c |  111 +
 notmuch-reply.c   |   17 
 notmuch.c |5 +++
 5 files changed, 137 insertions(+)
 create mode 100644 notmuch-compose.c

-- 
1.7.10

[PATCH v2 0/3] composing patches

[Adam Wolfe Gordon]

Hi Felipe,

On Wed, Apr 18, 2012 at 06:39, Felipe Contreras
 wrote:
> I don't know how it works in gnus, but at least on the vim mode, the output
> generated by 'notmuch reply' is not ready to be sent, at least the Message-ID
> field is needed, and also is nice to have the User-Agent.

In the emacs interface, the Message-ID header is generated when the
message is sent, so it never shows up in the reply buffer. The
User-Agent header is created by the emacs reply code.

> Besides, in order to avoid creating a new message by hand (possibly fetching
> the info from notmuch config), it's more straightforward to have 'notmuch
> compose' command.
>
> In the future 'notmuch compose' might be used to replace 'notmuch reply' and
> possily add a forward option too. It might also be possible to add mail 
> aliases
> when composing a message, and these aliases might be used while generating the
> 'notmuch search' output.

I can see how this functionality is useful, and I like the idea of
consolidating message creation, forwarding, and reply. However, if
this is intended to replace or share code with reply (and I think it
should), it should support all the existing reply formats: default,
json, and headers-only.

In fact, I think it might make more sense to make this work an
extension of the existing reply code rather than a rewrite.
notmuch-reply.c could become notmuch-compose.c, and provide the
compose command (with flags for creating a reply), and also the reply
command (which would just be an alias to the compose functionality).

> ?Makefile.local ? ?| ? ?1 +
> ?notmuch-client.h ?| ? ?3 ++
> ?notmuch-compose.c | ?111 
> +
> ?notmuch-reply.c ? | ? 17 
> ?notmuch.c ? ? ? ? | ? ?5 +++

Such a big new features should definitely have some tests.

-- Adam

[PATCH v2 0/3] composing patches

[Felipe Contreras]

Hi,

I don't know how it works in gnus, but at least on the vim mode, the output
generated by 'notmuch reply' is not ready to be sent, at least the Message-ID
field is needed, and also is nice to have the User-Agent.

Besides, in order to avoid creating a new message by hand (possibly fetching
the info from notmuch config), it's more straightforward to have 'notmuch
compose' command.

In the future 'notmuch compose' might be used to replace 'notmuch reply' and
possily add a forward option too. It might also be possible to add mail aliases
when composing a message, and these aliases might be used while generating the
'notmuch search' output.

Although we are adding extra fields in notmuch reply, higher layers can just
override them easily.

Felipe Contreras (3):
  Add 'compose' command
  reply: add message-id header
  reply: add user-agent field

 Makefile.local|1 +
 notmuch-client.h  |3 ++
 notmuch-compose.c |  111 +
 notmuch-reply.c   |   17 
 notmuch.c |5 +++
 5 files changed, 137 insertions(+)
 create mode 100644 notmuch-compose.c

-- 
1.7.10

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

Re: [PATCH v2 0/3] composing patches

[Adam Wolfe Gordon]

Hi Felipe,

On Wed, Apr 18, 2012 at 06:39, Felipe Contreras
felipe.contre...@gmail.com wrote:
 I don't know how it works in gnus, but at least on the vim mode, the output
 generated by 'notmuch reply' is not ready to be sent, at least the Message-ID
 field is needed, and also is nice to have the User-Agent.

In the emacs interface, the Message-ID header is generated when the
message is sent, so it never shows up in the reply buffer. The
User-Agent header is created by the emacs reply code.

 Besides, in order to avoid creating a new message by hand (possibly fetching
 the info from notmuch config), it's more straightforward to have 'notmuch
 compose' command.

 In the future 'notmuch compose' might be used to replace 'notmuch reply' and
 possily add a forward option too. It might also be possible to add mail 
 aliases
 when composing a message, and these aliases might be used while generating the
 'notmuch search' output.

I can see how this functionality is useful, and I like the idea of
consolidating message creation, forwarding, and reply. However, if
this is intended to replace or share code with reply (and I think it
should), it should support all the existing reply formats: default,
json, and headers-only.

In fact, I think it might make more sense to make this work an
extension of the existing reply code rather than a rewrite.
notmuch-reply.c could become notmuch-compose.c, and provide the
compose command (with flags for creating a reply), and also the reply
command (which would just be an alias to the compose functionality).

  Makefile.local    |    1 +
  notmuch-client.h  |    3 ++
  notmuch-compose.c |  111 
 +
  notmuch-reply.c   |   17 
  notmuch.c         |    5 +++

Such a big new features should definitely have some tests.

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

[PATCH v2 0/3] Rewrite default reply format

[David Bremner]

Austin Clements  writes:

> This version fixes two minor formatting issues that Tomi pointed out
> [1].  There are no other changes.
>
> [1] id:"m2d382ia9d.fsf at guru.guru-group.fi"

pushed, 

d

Re: [PATCH v2 0/3] Rewrite default reply format

[David Bremner]

Austin Clements amdra...@mit.edu writes:

 This version fixes two minor formatting issues that Tomi pointed out
 [1].  There are no other changes.

 [1] id:m2d382ia9d@guru.guru-group.fi

pushed, 

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

[PATCH v2 0/3] Rewrite default reply format

[Austin Clements]

This version fixes two minor formatting issues that Tomi pointed out
[1].  There are no other changes.

[1] id:"m2d382ia9d.fsf at guru.guru-group.fi"

[PATCH v2 0/3] Rewrite default reply format

[Austin Clements]

This version fixes two minor formatting issues that Tomi pointed out
[1].  There are no other changes.

[1] id:m2d382ia9d@guru.guru-group.fi

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

[PATCH v2 0/3] cli: notmuch tag/restore refactoring

[Jani Nikula]

v2 of id:"cover.1332604895.git.jani at nikula.org" with the following
non-functional changes, addressing David's concerns in mail and IRC:

 - do not use C99 style struct assignment in patch 1
 - for now, keep tag_message() local to notmuch-restore.c in patch 3

BR,
Jani.

Jani Nikula (3):
  cli: refactor "notmuch tag" data structures for tagging operations
  cli: refactor "notmuch tag" query tagging into a separate function
  cli: refactor "notmuch restore" message tagging into a separate
function

 notmuch-restore.c |  148 +--
 notmuch-tag.c |  166 +++--
 2 files changed, 163 insertions(+), 151 deletions(-)

-- 
1.7.5.4

[PATCH v2 0/3] cli: notmuch tag/restore refactoring

[Jani Nikula]

v2 of id:cover.1332604895.git.j...@nikula.org with the following
non-functional changes, addressing David's concerns in mail and IRC:

 - do not use C99 style struct assignment in patch 1
 - for now, keep tag_message() local to notmuch-restore.c in patch 3

BR,
Jani.

Jani Nikula (3):
  cli: refactor notmuch tag data structures for tagging operations
  cli: refactor notmuch tag query tagging into a separate function
  cli: refactor notmuch restore message tagging into a separate
function

 notmuch-restore.c |  148 +--
 notmuch-tag.c |  166 +++--
 2 files changed, 163 insertions(+), 151 deletions(-)

-- 
1.7.5.4

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

[Patch v2 0/3] Add test and fix exclude bug

[David Bremner]

On Wed, 14 Mar 2012 12:26:51 +, Mark Walters  
wrote:
> The test in the previous patches
> id:"1331551914-28323-1-git-send-email-markwalters1009 at gmail.com"
> triggered the bug accidentally. It accidentally set the exclude tags
> to be "=" and "deleted" rather than just "deleted". The non-existent
> "=" tag (i.e., the tag that does not occur anywhere in the Xapian
> database) triggered the bug.

pushed,

d

Re: [Patch v2 0/3] Add test and fix exclude bug

[David Bremner]

On Wed, 14 Mar 2012 12:26:51 +, Mark Walters markwalters1...@gmail.com 
wrote:
 The test in the previous patches
 id:1331551914-28323-1-git-send-email-markwalters1...@gmail.com
 triggered the bug accidentally. It accidentally set the exclude tags
 to be = and deleted rather than just deleted. The non-existent
 = tag (i.e., the tag that does not occur anywhere in the Xapian
 database) triggered the bug.

pushed,

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

[Patch v2 0/3] Add test and fix exclude bug

[Jameson Graef Rollins]

On Wed, 14 Mar 2012 12:26:51 +, Mark Walters  
wrote:
> The test in the previous patches
> id:"1331551914-28323-1-git-send-email-markwalters1009 at gmail.com"
> triggered the bug accidentally. It accidentally set the exclude tags
> to be "=" and "deleted" rather than just "deleted". The non-existent
> "=" tag (i.e., the tag that does not occur anywhere in the Xapian
> database) triggered the bug. First we correct the tests to just set
> the "deleted" tag, then we add some tests including one with a
> deliberately non-existent tag. Finally, we modify the exclusion code
> to avoid the bug.
> 
> The modification also appears to fix a similar problem for jrollins
> that I have not yet been able to reproduce.
> 
> Since the code is now more clearly correct, cleaner and we do
> definitely avoid a Xapian bug I think these patches can be committed
> even without knowing why it fixed jrollins' bug.
> 
> Finally these apply to current master (not to the --with-excluded series).

tested, and it works for me, so LGTM.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[Patch v2 0/3] Add test and fix exclude bug

[Austin Clements]

Quoth Mark Walters on Mar 14 at 12:26 pm:
> The test in the previous patches
> id:"1331551914-28323-1-git-send-email-markwalters1009 at gmail.com"
> triggered the bug accidentally. It accidentally set the exclude tags
> to be "=" and "deleted" rather than just "deleted". The non-existent
> "=" tag (i.e., the tag that does not occur anywhere in the Xapian
> database) triggered the bug. First we correct the tests to just set
> the "deleted" tag, then we add some tests including one with a
> deliberately non-existent tag. Finally, we modify the exclusion code
> to avoid the bug.
> 
> The modification also appears to fix a similar problem for jrollins
> that I have not yet been able to reproduce.
> 
> Since the code is now more clearly correct, cleaner and we do
> definitely avoid a Xapian bug I think these patches can be committed
> even without knowing why it fixed jrollins' bug.
> 
> Finally these apply to current master (not to the --with-excluded series).

LGTM.  It would be nice to have the broken tests marked broken in the
patch that introduces them, but it's fine.

Re: [Patch v2 0/3] Add test and fix exclude bug

[Austin Clements]

Quoth Mark Walters on Mar 14 at 12:26 pm:
 The test in the previous patches
 id:1331551914-28323-1-git-send-email-markwalters1...@gmail.com
 triggered the bug accidentally. It accidentally set the exclude tags
 to be = and deleted rather than just deleted. The non-existent
 = tag (i.e., the tag that does not occur anywhere in the Xapian
 database) triggered the bug. First we correct the tests to just set
 the deleted tag, then we add some tests including one with a
 deliberately non-existent tag. Finally, we modify the exclusion code
 to avoid the bug.
 
 The modification also appears to fix a similar problem for jrollins
 that I have not yet been able to reproduce.
 
 Since the code is now more clearly correct, cleaner and we do
 definitely avoid a Xapian bug I think these patches can be committed
 even without knowing why it fixed jrollins' bug.
 
 Finally these apply to current master (not to the --with-excluded series).

LGTM.  It would be nice to have the broken tests marked broken in the
patch that introduces them, but it's fine.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[Patch v2 0/3] Add test and fix exclude bug

[Mark Walters]

The test in the previous patches
id:"1331551914-28323-1-git-send-email-markwalters1009 at gmail.com"
triggered the bug accidentally. It accidentally set the exclude tags
to be "=" and "deleted" rather than just "deleted". The non-existent
"=" tag (i.e., the tag that does not occur anywhere in the Xapian
database) triggered the bug. First we correct the tests to just set
the "deleted" tag, then we add some tests including one with a
deliberately non-existent tag. Finally, we modify the exclusion code
to avoid the bug.

The modification also appears to fix a similar problem for jrollins
that I have not yet been able to reproduce.

Since the code is now more clearly correct, cleaner and we do
definitely avoid a Xapian bug I think these patches can be committed
even without knowing why it fixed jrollins' bug.

Finally these apply to current master (not to the --with-excluded series).

Best wishes

Mark

Mark Walters (3):
  test: the test for the exclude code mistakenly excludes the tag "="
  test: add tests for message only search
  lib: fix an exclude bug

 lib/query.cc |5 +++--
 test/count   |2 +-
 test/search  |   19 ++-
 3 files changed, 22 insertions(+), 4 deletions(-)

-- 
1.7.9.1

[RFC PATCH v2 0/3] notmuch-pick: an emacs threaded message view with split-pane

[Mark Walters]

On Mon, 13 Feb 2012 14:35:31 +0530, "Aneesh Kumar K.V"  wrote:
> On Sun, 12 Feb 2012 18:49:36 +, Mark Walters  gmail.com> wrote:
> > Here is a rebased version of the notmuch-pick patch set
> > id:"87d39k1gvi.fsf at qmul.ac.uk". It now applies directly 
> > to master since Jani's notmuch-show command line parsing 
> > has been pushed.
> > 
> > It includes the significant bug fix (at least for anyone working 
> > with a dark background) from Daniel making matched messages 
> > highlight color both configurable and have a sensible default.
> > These are in the notmuch-pick subgroup of the customize menus.
> > 

Hi

> Really nice patchset. It would be really nice if we can get the serach
> limit patchset before this. That way the pick result will be limitted.

Do you mean id:"1327692900-22926-1-git-send-email-jani at nikula.org"? That
would not affect notmuch-pick. In fact, since notmuch-pick uses
notmuch-show.c rather than notmuch-search.c the cli doesn't have the
--limit option. You are quite right that this may be the way to go
though.

> I also noticied that mails are not marked as read when i select them in
> the notmuch-pick mode. Also for me the tree structures appears as
> below. 

Are they not marked as read at all, or just not marked as read in the
notmuch-pick display (try pressing '=' and see if they are shown
correctly on refresh). It would be very nice to have the tags refresh
automatically but I have not implemented it (it may be beyond my lisp-fu).

>  Today 00:19  Mark Walters  ???[RFC PATCH v2 1/3] cli: notmuch-show 
> changes to support pick (notmuch)
>  Today 02:38  Daniel Schoepe ...  
> (notmuch, signed)
>  Today 03:38  Mark Walters   ...  
> (notmuch)
>  Today 00:19  Mark Walters  ???[RFC PATCH v2 2/3] emacs: changes to 
> other files to support notmuch-pick (notmuch)
>  Today 03:57  Mark Walters   ...  
> (notmuch)
>  Today 00:19  Mark Walters  ???[RFC PATCH v2 3/3] emacs: add 
> notmuch-pick itself  (notmuch)

I am not quite sure what this looks like (as I am not sure what is my
emacs doing things and what is what you sent. Could you send me a
screenshot (and an explanation of what is wrong if it is not clear from
the screenshot)?

Thanks

Mark

[RFC PATCH v2 0/3] notmuch-pick: an emacs threaded message view with split-pane

[Aneesh Kumar K.V]

On Sun, 12 Feb 2012 18:49:36 +, Mark Walters  
wrote:
> Here is a rebased version of the notmuch-pick patch set
> id:"87d39k1gvi.fsf at qmul.ac.uk". It now applies directly 
> to master since Jani's notmuch-show command line parsing 
> has been pushed.
> 
> It includes the significant bug fix (at least for anyone working 
> with a dark background) from Daniel making matched messages 
> highlight color both configurable and have a sensible default.
> These are in the notmuch-pick subgroup of the customize menus.
> 

Really nice patchset. It would be really nice if we can get the serach
limit patchset before this. That way the pick result will be limitted.
I also noticied that mails are not marked as read when i select them in
the notmuch-pick mode. Also for me the tree structures appears as
below. 

 Today 00:19  Mark Walters  ???[RFC PATCH v2 1/3] cli: notmuch-show 
changes to support pick (notmuch)
 Today 02:38  Daniel Schoepe ...
  (notmuch, signed)
 Today 03:38  Mark Walters   ...
  (notmuch)
 Today 00:19  Mark Walters  ???[RFC PATCH v2 2/3] emacs: changes to 
other files to support notmuch-pick (notmuch)
 Today 03:57  Mark Walters   ...
  (notmuch)
 Today 00:19  Mark Walters  ???[RFC PATCH v2 3/3] emacs: add 
notmuch-pick itself  (notmuch)

Re: [RFC PATCH v2 0/3] notmuch-pick: an emacs threaded message view with split-pane

[Aneesh Kumar K.V]

On Sun, 12 Feb 2012 18:49:36 +, Mark Walters markwalters1...@gmail.com 
wrote:
 Here is a rebased version of the notmuch-pick patch set
 id:87d39k1gvi@qmul.ac.uk. It now applies directly 
 to master since Jani's notmuch-show command line parsing 
 has been pushed.
 
 It includes the significant bug fix (at least for anyone working 
 with a dark background) from Daniel making matched messages 
 highlight color both configurable and have a sensible default.
 These are in the notmuch-pick subgroup of the customize menus.
 

Really nice patchset. It would be really nice if we can get the serach
limit patchset before this. That way the pick result will be limitted.
I also noticied that mails are not marked as read when i select them in
the notmuch-pick mode. Also for me the tree structures appears as
below. 

 Today 00:19  Mark Walters  ├┬►[RFC PATCH v2 1/3] cli: notmuch-show 
changes to support pick (notmuch)
 Today 02:38  Daniel Schoepe│├─► ...
  (notmuch, signed)
 Today 03:38  Mark Walters  │╰─► ...
  (notmuch)
 Today 00:19  Mark Walters  ├┬►[RFC PATCH v2 2/3] emacs: changes to 
other files to support notmuch-pick (notmuch)
 Today 03:57  Mark Walters  │╰─► ...
  (notmuch)
 Today 00:19  Mark Walters  ├─►[RFC PATCH v2 3/3] emacs: add 
notmuch-pick itself  (notmuch)


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

Re: [RFC PATCH v2 0/3] notmuch-pick: an emacs threaded message view with split-pane

[Mark Walters]

On Mon, 13 Feb 2012 14:35:31 +0530, Aneesh Kumar K.V 
aneesh.ku...@linux.vnet.ibm.com wrote:
 On Sun, 12 Feb 2012 18:49:36 +, Mark Walters markwalters1...@gmail.com 
 wrote:
  Here is a rebased version of the notmuch-pick patch set
  id:87d39k1gvi@qmul.ac.uk. It now applies directly 
  to master since Jani's notmuch-show command line parsing 
  has been pushed.
  
  It includes the significant bug fix (at least for anyone working 
  with a dark background) from Daniel making matched messages 
  highlight color both configurable and have a sensible default.
  These are in the notmuch-pick subgroup of the customize menus.
  

Hi

 Really nice patchset. It would be really nice if we can get the serach
 limit patchset before this. That way the pick result will be limitted.

Do you mean id:1327692900-22926-1-git-send-email-j...@nikula.org? That
would not affect notmuch-pick. In fact, since notmuch-pick uses
notmuch-show.c rather than notmuch-search.c the cli doesn't have the
--limit option. You are quite right that this may be the way to go
though.

 I also noticied that mails are not marked as read when i select them in
 the notmuch-pick mode. Also for me the tree structures appears as
 below. 

Are they not marked as read at all, or just not marked as read in the
notmuch-pick display (try pressing '=' and see if they are shown
correctly on refresh). It would be very nice to have the tags refresh
automatically but I have not implemented it (it may be beyond my lisp-fu).

  Today 00:19  Mark Walters  ├┬►[RFC PATCH v2 1/3] cli: notmuch-show 
 changes to support pick (notmuch)
  Today 02:38  Daniel Schoepe│├─► ...  
 (notmuch, signed)
  Today 03:38  Mark Walters  │╰─► ...  
 (notmuch)
  Today 00:19  Mark Walters  ├┬►[RFC PATCH v2 2/3] emacs: changes to 
 other files to support notmuch-pick (notmuch)
  Today 03:57  Mark Walters  │╰─► ...  
 (notmuch)
  Today 00:19  Mark Walters  ├─►[RFC PATCH v2 3/3] emacs: add 
 notmuch-pick itself  (notmuch)

I am not quite sure what this looks like (as I am not sure what is my
emacs doing things and what is what you sent. Could you send me a
screenshot (and an explanation of what is wrong if it is not clear from
the screenshot)?

Thanks

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

[RFC PATCH v2 0/3] notmuch-pick: an emacs threaded message view with split-pane

[Mark Walters]

On Sun, 12 Feb 2012 12:39:13 -0800, Jameson Graef Rollins  wrote:
> On Sun, 12 Feb 2012 18:49:36 +, Mark Walters  gmail.com> wrote:
> > Here is a rebased version of the notmuch-pick patch set
> > id:"87d39k1gvi.fsf at qmul.ac.uk". It now applies directly 
> > to master since Jani's notmuch-show command line parsing 
> > has been pushed.
> 
> Hey, Mark.  Thanks for working on this.  However, none of the patches
> have commit messages, so there's no explanation for what any of the
> patches are supposed to do.  This is particularly bothersome for the
> first patch, which introduces a lot of unexplained changes to the cli.
> 
> I think I would like to review this patch set, since I think I'm
> interested in the functionality it may be introducing, but without any
> commit messages or explanation what the patches are meant to do it's
> kind of a non starter for me.

Hi 

At the moment I was mostly looking for feedback on whether people like
the final outcome (i.e., whether people liked it enough to be worth
tidying). I will add comments on the first two patches.

Best wishes

Mark

[RFC PATCH v2 0/3] notmuch-pick: an emacs threaded message view with split-pane

[Mark Walters]

Here is a rebased version of the notmuch-pick patch set
id:"87d39k1gvi.fsf at qmul.ac.uk". It now applies directly 
to master since Jani's notmuch-show command line parsing 
has been pushed.

It includes the significant bug fix (at least for anyone working 
with a dark background) from Daniel making matched messages 
highlight color both configurable and have a sensible default.
These are in the notmuch-pick subgroup of the customize menus.

Best wishes

Mark

Mark Walters (3):
  cli: notmuch-show changes to support pick
  emacs: changes to other files to support notmuch-pick
  emacs: add notmuch-pick itself

 emacs/Makefile.local   |3 +-
 emacs/notmuch-hello.el |   10 +
 emacs/notmuch-lib.el   |4 +
 emacs/notmuch-pick.el  |  585 
 emacs/notmuch-query.el |4 +-
 emacs/notmuch-show.el  |   25 ++-
 emacs/notmuch.el   |8 +
 notmuch-client.h   |9 +-
 notmuch-show.c |   90 +++-
 9 files changed, 722 insertions(+), 16 deletions(-)
 create mode 100644 emacs/notmuch-pick.el

-- 
1.7.2.3

[RFC PATCH v2 0/3] notmuch-pick: an emacs threaded message view with split-pane

[Jameson Graef Rollins]

On Sun, 12 Feb 2012 18:49:36 +, Mark Walters  
wrote:
> Here is a rebased version of the notmuch-pick patch set
> id:"87d39k1gvi.fsf at qmul.ac.uk". It now applies directly 
> to master since Jani's notmuch-show command line parsing 
> has been pushed.

Hey, Mark.  Thanks for working on this.  However, none of the patches
have commit messages, so there's no explanation for what any of the
patches are supposed to do.  This is particularly bothersome for the
first patch, which introduces a lot of unexplained changes to the cli.

I think I would like to review this patch set, since I think I'm
interested in the functionality it may be introducing, but without any
commit messages or explanation what the patches are meant to do it's
kind of a non starter for me.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[RFC PATCH v2 0/3] notmuch-pick: an emacs threaded message view with split-pane

[Mark Walters]

Here is a rebased version of the notmuch-pick patch set
id:87d39k1gvi@qmul.ac.uk. It now applies directly 
to master since Jani's notmuch-show command line parsing 
has been pushed.

It includes the significant bug fix (at least for anyone working 
with a dark background) from Daniel making matched messages 
highlight color both configurable and have a sensible default.
These are in the notmuch-pick subgroup of the customize menus.

Best wishes

Mark

Mark Walters (3):
  cli: notmuch-show changes to support pick
  emacs: changes to other files to support notmuch-pick
  emacs: add notmuch-pick itself

 emacs/Makefile.local   |3 +-
 emacs/notmuch-hello.el |   10 +
 emacs/notmuch-lib.el   |4 +
 emacs/notmuch-pick.el  |  585 
 emacs/notmuch-query.el |4 +-
 emacs/notmuch-show.el  |   25 ++-
 emacs/notmuch.el   |8 +
 notmuch-client.h   |9 +-
 notmuch-show.c |   90 +++-
 9 files changed, 722 insertions(+), 16 deletions(-)
 create mode 100644 emacs/notmuch-pick.el

-- 
1.7.2.3

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

Re: [RFC PATCH v2 0/3] notmuch-pick: an emacs threaded message view with split-pane

[Jameson Graef Rollins]

On Sun, 12 Feb 2012 18:49:36 +, Mark Walters markwalters1...@gmail.com 
wrote:
 Here is a rebased version of the notmuch-pick patch set
 id:87d39k1gvi@qmul.ac.uk. It now applies directly 
 to master since Jani's notmuch-show command line parsing 
 has been pushed.

Hey, Mark.  Thanks for working on this.  However, none of the patches
have commit messages, so there's no explanation for what any of the
patches are supposed to do.  This is particularly bothersome for the
first patch, which introduces a lot of unexplained changes to the cli.

I think I would like to review this patch set, since I think I'm
interested in the functionality it may be introducing, but without any
commit messages or explanation what the patches are meant to do it's
kind of a non starter for me.

jamie.


pgpJOooCk0ETs.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [RFC PATCH v2 0/3] notmuch-pick: an emacs threaded message view with split-pane

[Mark Walters]

On Sun, 12 Feb 2012 12:39:13 -0800, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Sun, 12 Feb 2012 18:49:36 +, Mark Walters markwalters1...@gmail.com 
 wrote:
  Here is a rebased version of the notmuch-pick patch set
  id:87d39k1gvi@qmul.ac.uk. It now applies directly 
  to master since Jani's notmuch-show command line parsing 
  has been pushed.
 
 Hey, Mark.  Thanks for working on this.  However, none of the patches
 have commit messages, so there's no explanation for what any of the
 patches are supposed to do.  This is particularly bothersome for the
 first patch, which introduces a lot of unexplained changes to the cli.
 
 I think I would like to review this patch set, since I think I'm
 interested in the functionality it may be introducing, but without any
 commit messages or explanation what the patches are meant to do it's
 kind of a non starter for me.

Hi 

At the moment I was mostly looking for feedback on whether people like
the final outcome (i.e., whether people liked it enough to be worth
tidying). I will add comments on the first two patches.

Best wishes

Mark

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

[PATCH v2 0/3] Second step of 'show' rewrite

[Austin Clements]

This revision addresses Jani's comments.  It removes some
const-stripping casts (at the cost of dropping a const from the API),
fixes a delayed free, and cleans up some aesthetics.

[PATCH v2 0/3] Second step of 'show' rewrite

[Austin Clements]

This revision addresses Jani's comments.  It removes some
const-stripping casts (at the cost of dropping a const from the API),
fixes a delayed free, and cleans up some aesthetics.

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

[PATCH v2 0/3] emacs: notmuch-hello search cleanup

[David Edmondson]

On Thu, 19 Jan 2012 00:22:53 +0400, Dmitry Kurochkin  wrote:
> Changes in v2 since v1:
> 
> * expected results changes for tests moved from patch 2 to 1 where it belong

The patch set looks good to me.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: 

[PATCH v2 0/3] emacs: notmuch-hello search cleanup

[Dmitry Kurochkin]

Changes in v2 since v1:

* expected results changes for tests moved from patch 2 to 1 where it belong

Regards,
  Dmitry

Re: [PATCH v2 0/3] emacs: notmuch-hello search cleanup

[David Edmondson]

On Thu, 19 Jan 2012 00:22:53 +0400, Dmitry Kurochkin 
dmitry.kuroch...@gmail.com wrote:
 Changes in v2 since v1:
 
 * expected results changes for tests moved from patch 2 to 1 where it belong

The patch set looks good to me.


pgpNMumAPxq0s.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2 0/3] emacs: notmuch-hello search cleanup

[Dmitry Kurochkin]

Changes in v2 since v1:

* expected results changes for tests moved from patch 2 to 1 where it belong

Regards,
  Dmitry

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

[PATCH v2 0/3]

[Jameson Graef Rollins]

On Fri, 13 Jan 2012 18:07:01 -0500, Austin Clements  wrote:
> This addresses Jani's comments and improves some of the text and code
> comments.

This is a really nice feature addition, Austin.  And it works like a
charm.  ++1.

A couple of small comments to follow.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH v2 0/3]

[Austin Clements]

This addresses Jani's comments and improves some of the text and code
comments.

[PATCH v2 0/3]

[Austin Clements]

This addresses Jani's comments and improves some of the text and code
comments.

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

[PATCH v2 0/3] emacs: Document notmuch-show-get-message-properties

[Jameson Graef Rollins]

On Fri, 16 Dec 2011 09:01:21 -0400, David Bremner  wrote:
> The others are (not too surprisingly) stale and need rebasing. I'm also
> not clear on whether we have concensus on whether the patches are
> suitable for inclusion, so feedback from others would be welcome
> (perhaps before Daniel goes to the trouble of rebasing).

I definitely like the idea of thread outlining, but this isn't quite the
implementation that I would personally like to see.  What I would like
requires a bunch of changes to notmuch show, though.  This looks like it
could be kind of interesting to me in the interim, though, and it's not
particular invasive, so if Daniel want's to rebase it I see no problem.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 

[PATCH v2 0/3] emacs: Document notmuch-show-get-message-properties

[David Bremner]

On Fri,  8 Jul 2011 20:46:54 +0200, Daniel Schoepe  wrote:
> This version fixes the issues mentioned by Austin and highlights the currently
> displayed message in the outline buffer. My previous issues with 
> 'point-entered
> and 'point-left were caused by linum-mode, so don't enable it for 
> notmuch-show buffers.

I have pushed the first (documentation) patch in the series.

The others are (not too surprisingly) stale and need rebasing. I'm also
not clear on whether we have concensus on whether the patches are
suitable for inclusion, so feedback from others would be welcome
(perhaps before Daniel goes to the trouble of rebasing).

d

Re: [PATCH v2 0/3] emacs: Document notmuch-show-get-message-properties

[David Bremner]

On Fri,  8 Jul 2011 20:46:54 +0200, Daniel Schoepe 
daniel.scho...@googlemail.com wrote:
 This version fixes the issues mentioned by Austin and highlights the currently
 displayed message in the outline buffer. My previous issues with 
 'point-entered
 and 'point-left were caused by linum-mode, so don't enable it for 
 notmuch-show buffers.

I have pushed the first (documentation) patch in the series.

The others are (not too surprisingly) stale and need rebasing. I'm also
not clear on whether we have concensus on whether the patches are
suitable for inclusion, so feedback from others would be welcome
(perhaps before Daniel goes to the trouble of rebasing).

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