Small bug in json-search changes

2012-08-06 Thread Austin Clements
Nice catch.  I think the solution is either exactly this, or we should
strip "thread:" off notmuch-search-target-thread when we set it.  I
would lean slightly toward the latter so we don't have to generate up
a new (identical) string on every notmuch-search-show-result call, but
I doubt it would make much difference in the grand scheme of things.

Quoth Mark Walters on Aug 07 at 12:10 am:
> 
> Hi
> 
> I have found a small bug in the recent changes to notmuch search to use
> the JSON output. If you refresh the search buffer "point" does not stay
> on the same thread. 
> 
> I think the problem is that notmuch-search-refresh-view calls notmuch
> search with target-thread set to notmuch-search-find-thread-id which
> returns the thread-id with "thread:" prefixed, whereas
> notmuch-search-show-result checks for a match with (plist-get result
> :thread) which is the thread id with no prefix.
> 
> The patch below fixes this but I am not sure it is the nicest fix.
> 
> Best wishes
> 
> Mark
> 
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index d2d82a9..a53d5a0 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -798,7 +798,7 @@ non-authors is found, assume that all of the authors 
> match."
>   (insert "\n")
>   (notmuch-search-color-line beg (point) (plist-get result :tags))
>   (put-text-property beg (point) 'notmuch-search-result result))
> -  (when (string= (plist-get result :thread) notmuch-search-target-thread)
> +  (when (string= (concat "thread:" (plist-get result :thread)) 
> notmuch-search-target-thread)
>   (setq notmuch-search-target-thread "found")
>   (goto-char beg)
>  
> 


[PATCH] notmuch-show: add notmuch-show-auto-mark-read option

2012-08-06 Thread Michal Nazarewicz
Austin Clements  writes:
> LGTM, though I wonder: Is this actually what you want, or would you be
> happy with automatic read marking if it followed a different pattern
> (perhaps a more predictable pattern)?

At the moment, I feel that's what I want.  I have a few keys set up for
addings tags like mute or delete, ie.:

 (set-key notmuch-show-mode-map key
  (notmuch-show-tag tag) (notmuch-show-next-thread t))

This adds the tag and opens the next thread, which is great, except
I sometimes don't want to mark the next thread unread.

I have two more shortcut which go to the next thread but one of them
removes unread tag.  This way, this setup does not mean I have to type
more -- I just need to conciously choose whether I want to tag current
message read or not.

> Quoth Michal Nazarewicz on Aug 06 at  4:20 pm:
>> From: Michal Nazarewicz 
>> 
>> Setting `notmuch-show-auto-mark-read' to nil stops notmuch-show from marking
>> the message as read (by removing the unread tag).  Inteded for people who
>> like to mark messages read explicitly.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Micha? ?mina86? Nazarewicz(o o)
ooo +--ooO--(_)--Ooo--
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120806/5b15e7cd/attachment.pgp>


PATCH: notmuch-mutt.rc macros (with correct commit msg)

2012-08-06 Thread Jani Nikula

On Sun, 27 May 2012, Jason Ryan  wrote:
> Ref: id:"20120527004107.GA4869 at Centurion"
>
> Please find attached the patch with a descriptive commit message?

Hi, this patch no longer applies to master, so I've tagged it as
notmuch::stale. (See http://nmbug.tethera.net/status/)

>
> /J
>
> -- 
>
> http://jasonwryan.com/  [GnuPG Key: B1BD4E40]
>
>
> From 9dd4db8dfeafb6464cccf81cb78038b7a252d080 Mon Sep 17 00:00:00 2001
> From: jasonwryan 
> Date: Sun, 27 May 2012 12:34:27 +1200
> Subject: [PATCH] Small fix to two macros in notmuch-mutt.rc
>
> A couple of minor fixes to ensure that the two macros,
> for  and  work as advertised.
> ---
>  contrib/notmuch-mutt/notmuch-mutt.rc |8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/contrib/notmuch-mutt/notmuch-mutt.rc 
> b/contrib/notmuch-mutt/notmuch-mutt.rc
> index c0ff000..38ad584 100644
> --- a/contrib/notmuch-mutt/notmuch-mutt.rc
> +++ b/contrib/notmuch-mutt/notmuch-mutt.rc
> @@ -2,8 +2,8 @@ macro index  \
>"unset wait_keynotmuch-mutt 
> --prompt search`echo 
> ${XDG_CACHE_HOME:-$HOME/.cache}/notmuch/mutt/results`" \
>"notmuch: search mail"
>  macro index  \
> -  "unset wait_keynotmuch-mutt 
> thread`echo 
> ${XDG_CACHE_HOME:-$HOME/.cache}/notmuch/mutt/results`set
>  wait_key" \
> -  "notmuch: reconstruct thread"
> +  "unset wait_keyunignore 
> message-idnotmuch-mutt 
> thread`echo 
> ${XDG_CACHE_HOME:-$HOME/.cache}/notmuch/mutt/results`set
>  wait_key" \
> +  "search and reconstruct owning thread with notmuch"
>  macro index  \
> -  "unset wait_keynotmuch-mutt tag 
> -inbox" \
> -  "notmuch: remove message from inbox"
> +  "unset wait_keyunignore 
> message-idnotmuch-mutt -- tag -inbox" \
> +  "remove message from inbox with notmuch"
> -- 
> 1.7.10.2
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


Vim plugins

2012-08-06 Thread Anton Khirnov

Hi,

On Sun, 5 Aug 2012 14:52:44 +0100 (BST), Sepp Tannhuber  wrote:
> Dear all,
> 
> I would like to check the available vim plugins. At least I found three:
> - the original one
> - Felipe's ruby plugin
> - Anton's python plugin
> 
> First of all can you tell me where I find the files of the python plugin?
> I tried
> ? $ git clone git://git.khirnov.net/git/notmuch
> But I cannot find the python files in the vim directory. What am I doing 
> wrong?
> 

you have to checkout the vim branch, then the files are in vim/plugin

I deleted all other branches from my repo now so nobody else gets
confused like this.

-- 
Anton Khirnov


[PATCH] emacs: Make moving to the previous message move to the previous boundary

2012-08-06 Thread Tomi Ollila
On Sat, Jul 14 2012, Austin Clements  wrote:

> Previously, notmuch-show-previous-message would move to the beginning
> of the message before the message containing point.  This patch makes
> it instead move to the previous message *boundary*.  That is, if point
> isn't already at the beginning of the message, it moves to the
> beginning of the current message.  This is consistent with
> notmuch-show-next-message, which can be thought of as moving to the
> next message boundary.  Several people have expressed a preference for
> this.
> ---

LGTM. Contrary to what I wrote in id:"m2pq746tlq.fsf at guru.guru-group.fi"
I think this could be pushed...

Tomi

> This patch accompanies the series in [0] (though they're independent
> and can be applied in either order).  This makes the behavior of 'p'
> and 'P' in show-mode conceptually similar to the new behavior of 'p'
> in search-mode.
>
> [0] 1342140319-19859-1-git-send-email-amdragon at mit.edu
>
>  emacs/notmuch-show.el |   10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 6335d45..02e319f 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -1525,9 +1525,11 @@ thread, navigate to the next thread in the parent 
> search buffer."
>(goto-char (point-max)
>  
>  (defun notmuch-show-previous-message ()
> -  "Show the previous message."
> +  "Show the previous message or the start of the current message."
>(interactive)
> -  (notmuch-show-goto-message-previous)
> +  (if (= (point) (notmuch-show-message-top))
> +  (notmuch-show-goto-message-previous)
> +(notmuch-show-move-to-message-top))
>(notmuch-show-mark-read)
>(notmuch-show-message-adjust))
>  
> @@ -1587,7 +1589,9 @@ to show, nil otherwise."
>  (defun notmuch-show-previous-open-message ()
>"Show the previous open message."
>(interactive)
> -  (while (and (notmuch-show-goto-message-previous)
> +  (while (and (if (= (point) (notmuch-show-message-top))
> +   (notmuch-show-goto-message-previous)
> + (notmuch-show-move-to-message-top))
> (not (notmuch-show-message-visible-p
>(notmuch-show-mark-read)
>(notmuch-show-message-adjust))
> -- 
> 1.7.10
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


Release plans for 0.14

2012-08-06 Thread Tomi Ollila
On Mon, Aug 06 2012, David Bremner  wrote:

> It has been a few months since we last had a release.
>
> I'd like to to another release within the next few weeks. To this end
> I'd like to take a snapshot of master next Sunday (August 12), and
> release that plus urgent bugfixes a week later (August 19).
>
> I realize this won't be time to get all of the interesting patches we
> are working on reviewed and merged in, but I don't want to fall into the
> trap of delaying the release indefinitely.
>
> Discussion?

I'd say no more features. Everybody is to pull latest HEAD: 6b820673fc9c
and start using it as widely they can (with personal patches if they have
-- at least I cannot live without those :)

Only test changes that may help finding bugs in current HEAD and documentation
updates are to be accepted.
(for example my notmuch-test-wait patches can wait...)

All the interesting patches we have in "queue" are to be postponed
until 0.14 is out to lessen the chance of unexpeted problems that may
arise...

> d

Tomi


[PATCH 3/4] show: indicate length of omitted body content (text)

2012-08-06 Thread Austin Clements
I'm not sure it's worth updating the text format.  There's already
plenty of disparity between the JSON and text formats, we're
considering deprecating the text format, and, from what I understand,
this might actually break consumers of the text format (the vim
frontend?) since the text format isn't particularly extensible.

Quoth Peter Wang on Aug 05 at  5:22 pm:
> If a leaf part's body content is omitted, return the content length in
> --format=text output, for parity with --format=json output.
> ---
>  notmuch-show.c |   23 +++
>  1 files changed, 19 insertions(+), 4 deletions(-)
> 
> diff --git a/notmuch-show.c b/notmuch-show.c
> index 5c54257..cde8a1e 100644
> --- a/notmuch-show.c
> +++ b/notmuch-show.c
> @@ -488,9 +488,17 @@ format_part_text (const void *ctx, sprinter_t *sp, 
> mime_node_t *node,
>   GMIME_OBJECT (node->envelope_part) : node->part;
>  GMimeContentType *content_type = g_mime_object_get_content_type (meta);
>  const notmuch_bool_t leaf = GMIME_IS_PART (node->part);
> +notmuch_bool_t leaf_text_part = FALSE;
>  const char *part_type;
>  int i;
>  
> +if (leaf &&
> + g_mime_content_type_is_type (content_type, "text", "*") &&
> + !g_mime_content_type_is_type (content_type, "text", "html"))
> +{
> + leaf_text_part = TRUE;
> +}
> +
>  if (node->envelope_file) {
>   notmuch_message_t *message = node->envelope_file;
>  
> @@ -519,7 +527,16 @@ format_part_text (const void *ctx, sprinter_t *sp, 
> mime_node_t *node,
>   printf (", Filename: %s", filename);
>   if (cid)
>   printf (", Content-id: %s", cid);
> - printf (", Content-type: %s\n", g_mime_content_type_to_string 
> (content_type));
> + printf (", Content-type: %s", g_mime_content_type_to_string 
> (content_type));
> + if (leaf && !leaf_text_part) {
> + GMimeDataWrapper *wrapper = g_mime_part_get_content_object 
> (GMIME_PART (node->part));
> + GMimeStream *stream = g_mime_data_wrapper_get_stream (wrapper);
> + ssize_t length = g_mime_stream_length (stream);
> + if (length >= 0) {
> + printf (", Content-length: %ld", length);
> + }

Same comment about possibly unref'ing wrapper and/or stream.

> + }
> + printf ("\n");
>  }
>  
>  if (GMIME_IS_MESSAGE (node->part)) {
> @@ -547,9 +564,7 @@ format_part_text (const void *ctx, sprinter_t *sp, 
> mime_node_t *node,
>  }
>  
>  if (leaf) {
> - if (g_mime_content_type_is_type (content_type, "text", "*") &&
> - !g_mime_content_type_is_type (content_type, "text", "html"))
> - {
> + if (leaf_text_part) {
>   GMimeStream *stream_stdout = g_mime_stream_file_new (stdout);
>   g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), 
> FALSE);
>   show_text_part_content (node->part, stream_stdout, 0);


[PATCH 1/4] show: indicate length of omitted body content (json)

2012-08-06 Thread Austin Clements
What's the overall goal of adding this?  Are you planning to add size
information to one of the frontends?

Quoth Peter Wang on Aug 05 at  5:22 pm:
> If a leaf part's body content is omitted, return the content length in
> --format=json output.  This information may be used by the consumer,
> e.g. to decide whether to download a large attachment over a slow link.
> ---
>  devel/schemata |5 -
>  notmuch-show.c |8 
>  2 files changed, 12 insertions(+), 1 deletions(-)
> 
> diff --git a/devel/schemata b/devel/schemata
> index 9cb25f5..3df2764 100644
> --- a/devel/schemata
> +++ b/devel/schemata
> @@ -69,7 +69,10 @@ part = {
>  # A leaf part's body content is optional, but may be included if
>  # it can be correctly encoded as a string.  Consumers should use
>  # this in preference to fetching the part content separately.
> -content?:   string
> +content?:   string,
> +# If a leaf part's body content is not included, the content-length
> +# may be included instead.

You mentioned elsewhere that the content-length returned is an
estimate.  If that's the case, this comment should say as much.  Is it
actually the case, though?  g_mime_part_get_content_object is
remarkably poorly documented for such an important function, but based
on format_part_raw, it seems like the content-length your code returns
will be exactly the number of bytes returned by the raw format for a
leaf part.

> +content-length?: int
>  }
>  
>  # The headers of a message or part (format_headers_json with reply = FALSE)
> diff --git a/notmuch-show.c b/notmuch-show.c
> index 3556293..5c54257 100644
> --- a/notmuch-show.c
> +++ b/notmuch-show.c
> @@ -664,6 +664,14 @@ format_part_json (const void *ctx, sprinter_t *sp, 
> mime_node_t *node,
>   sp->map_key (sp, "content");
>   sp->string_len (sp, (char *) part_content->data, part_content->len);
>   g_object_unref (stream_memory);
> + } else {
> + GMimeDataWrapper *wrapper = g_mime_part_get_content_object 
> (GMIME_PART (node->part));
> + GMimeStream *stream = g_mime_data_wrapper_get_stream (wrapper);
> + ssize_t length = g_mime_stream_length (stream);
> + if (length >= 0) {
> + sp->map_key (sp, "content-length");
> + sp->integer (sp, length);
> + }

Do wrapper or stream need to be g_object_unref'd?

Any idea what the performance overhead of this is?  I'm just curious.
It might be approximately nothing, since GMime's parser is eager.

>   }
>  } else if (GMIME_IS_MULTIPART (node->part)) {
>   sp->map_key (sp, "content");


[PATCH] notmuch-show: add notmuch-show-auto-mark-read option

2012-08-06 Thread Austin Clements
LGTM, though I wonder: Is this actually what you want, or would you be
happy with automatic read marking if it followed a different pattern
(perhaps a more predictable pattern)?

Quoth Michal Nazarewicz on Aug 06 at  4:20 pm:
> From: Michal Nazarewicz 
> 
> Setting `notmuch-show-auto-mark-read' to nil stops notmuch-show from marking
> the message as read (by removing the unread tag).  Inteded for people who
> like to mark messages read explicitly.
> ---
>  emacs/notmuch-show.el |   16 +---
>  1 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index d318430..85a17b1 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -183,6 +183,14 @@ provided with an MLA argument nor `completing-read' 
> input."
>notmuch-show-stash-mlarchive-link-alist))
>:group 'notmuch-show)
>  
> +(defcustom notmuch-show-auto-mark-read t
> +  "Whether to automatically mark message as read when it is shown.  If
> +nil, message needs to be marked as read manually for instance by
> +removing the unread tag."
> +  :type 'boolean
> +  :group 'notmuch-show)
> +
> +
>  (defmacro with-current-notmuch-show-message ( body)
>"Evaluate body with current buffer set to the text of current message"
>`(save-excursion
> @@ -1374,9 +1382,11 @@ current thread."
>"Are the headers of the current message visible?"
>(notmuch-show-get-prop :headers-visible))
>  
> -(defun notmuch-show-mark-read ()
> -  "Mark the current message as read."
> -  (notmuch-show-tag-message "-unread"))
> +(defun notmuch-show-mark-read ( force)
> +  "Mark the current message as read if FORCE or
> +`notmuch-show-auto-mark-read' is non-nil."
> +  (when (or force notmuch-show-auto-mark-read)
> +(notmuch-show-tag-message "-unread")))
>  
>  ;; Functions for getting attributes of several messages in the current
>  ;; thread.


[PATCH 1/2] notmuch-dump: remove deprecated positional argument for output file

2012-08-06 Thread David Bremner
david at tethera.net writes:

> From: David Bremner 
>
> The syntax --output=filename is a smaller change than deleting the
> output argument completely, and conceivably useful e.g. when running
> notmuch under a debugger.

I pushed these three patches. Let the angry howls from people running
production systems on automatic builds of notmuch master begin ;).

d


[PATCH v2 2/7] lib: add a date/time parser module

2012-08-06 Thread Jani Nikula

Hi David, thanks for the review!

On Sun, 05 Aug 2012, David Bremner  wrote:
> Jani Nikula  writes:
>
>> +
>> +static enum field
>> +abs_to_rel_field (enum field field)
>> +{
>> +assert (field <= TM_ABS_YEAR);
>> +
>> +/* note: depends on the enum ordering */
>> +return field + (TM_REL_SEC - TM_ABS_SEC);
>> +}
>> +
>
> I wonder if this would be slightly nicer of you defined a TM_FIRST_REL
> or so as a synonym like TM_NONE and TM_SIZE

Good idea.

>> +/* get zero value for field */
>> +static int
>> +field_zero (enum field field)
>> +{
>> +if (field == TM_ABS_MDAY || field == TM_ABS_MON)
>> +return 1;
>> +else if (field == TM_ABS_YEAR)
>> +return 1970;
>> +else
>> +return 0;
>> +}
>
> what do you think about using the word "epoch" instead of zero here?

As a non-native speaker, I'll just take your word for it if you think it
would be better. :)

>> +static bool
>> +get_postponed_number (struct state *state, int *v, int *n, char *d)
>> +{
>
> I found the 1 letter names not quite obvious here.

True. I think v and n are used fairly consistently throughout the source
file, so I'll have to consider longer names vs. documentation comment
for them.

> At this point reading the code, I have not trouble understanding each
> line/function, but I feel like I'm missing the big picture a bit. 

Yeah, perhaps the code reads better if you follow from the top level
parse_time_string() down. Which is at the very end. A "big picture"
documentation comment would do no harm.

> What is a postponed number?

I see that you grasped that later, but I'll describe anyway. Parsing is
done from left to right, in a greedy fashion (i.e. match the longest
possible known expression). If after that we encounter a number that we
don't know what to do with yet, postpone it until we move on to the next
expression. The parser for that might eat the preceding "postponed"
number (for example "5 August", 5 would be postponed because we don't
know what to do with yet, but then "August" would be the context to make
it day of month). If that is not the case, the number will be parsed by
parse_postponed_number() as a lonely, single number between there. (Yes,
this should be documented better with the "big picture".)

>
>> +/*
>> + * REVISIT: There could be a "next_field" that would be set from
>> + * "field" for the duration of the handle_postponed_number() call,
>> + * so it has more information to work with.
>> + */
>
> The notmuch convention seems to be to use XXX: for this. I'm not sure
> I'd bother changing, especially if we can't decide how to package this.

Okay, can be changed if needed.

>
>> +/* Time set helper. No input checking. Use UNSET (-1) to leave unset. */
>> +static int
>> +set_abs_time (struct state *state, int hour, int min, int sec)
>> +{
>> +int r;
>> +
>> +if (hour != UNSET) {
>> +if ((r = set_field (state, TM_ABS_HOUR, hour)))
>> +return r;
>> +}
>
> So for this function and the next, the first match wins? I don't really
> see the motivation for this, maybe you can explain a bit.

The whole parser tries to be as unambiguous as possible. If the input
leads to a situation in which any absolute time field (see enum field)
is attempted to set twice, it means it appears twice in the input. For
example, "2012-08-06 August", where the month is set twice. By design,
that is not allowed, and set_field() fails, even if it's the same
value. The only semi-exception is having redundant weekday there, for
example "Monday, August 6".

>
>
>> +/* timezone codes: offset in minutes. FIXME: add more codes. */
>
> Did you think about trying to delegate the list of timezones to the
> system?

No. :) I'll look into it.

>
>> + * Compare strings s and keyword. Return number of matching chars on
>> + * match, 0 for no match. Match must be at least n chars (n == 0 all
>> + * of keyword), otherwise it's not a match. Use match_case for case
>> + * sensitive matching.
>> + */
>
> I guess that's fine, and it is internal, but maybe -1 for whole string
> would be slightly nicer (although I can't imagine what good matching 0
> length strings is at the moment).

Can be changed.

>
>> +/* Minimum match length. */
>> +p = strchr (keyword, '|');
>> +if (p) {
>> +minlen = p - keyword;
>> +memmove (p, p + 1, strlen (p + 1) + 1);
>> +}
>
> Something about that memmove creeps me out, but I trust you that it's
> correct. Alternatively I guess you could represent keywords as pairs of
> strings, which is probably more of a pain.

I didn't bother to double check it now, but I remember thinking it over
very carefully. :) I agree it could use more clarity to be more
obviously correct.

(Initially the minlen was coded as an int in the table, but the above
allows the localization to decide how long the match must be.)

>
>
>> +
>> +/* Parse a single number. Typically postpone parsing until later. */
>
> OK, so I finally start to understand what a postponed 

Re: Inheriting tags from parent

2012-08-06 Thread Michal Nazarewicz
 Quoth Michal Nazarewicz on Aug 03 at  4:29 pm:
 I've just started using notmuch and am wondering if there is a way to
 make message “inherit” some of the tags from messages they are written
 in replay to (or in general are part of the same thread).
 
 I'm mostly thinking about a “mute” tag which I'd add to messages that
 are completely uninteresting to me.  With the “inheritance” mechanism,
 I'd be able to make notmuch automatically mute all the replays within
 the same thread.

Austin Clements amdra...@mit.edu writes:
 I have a hacky and now ancient patch series that you're welcome to try
 porting to a recent notmuch on the inheritable-tags-hack branch at
   http://awakening.csail.mit.edu/git/notmuch.git
 One general problem with this approach is dealing with threads whose
 messages arrive or are ingested out of order.  I don't think this is
 an insurmountable problem, but my patch certainly doesn't handle it
 correctly.

I'll keep that in mind, but lack of time, won't probably let me play
with it...

 There are also several other solutions to mute tags around.  For
 example, some people use a post-new hook to search for threads that
 contain at least one mute tag and then feed these thread IDs back in
 to notmuch tag to add the mute tag to everything in the thread.  I
 believe this is also the approach used by the afew tagging system for
 killed threads.

Yeah, that's what I'm doing now.  Basically “notmuch search
--output=threads is:mute” and then join all the lines with “or” to
finally do “notmuch tag +mute threads”.  I was, however, hoping for
something more dedicated.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--


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


Re: Release plans for 0.14

2012-08-06 Thread Tomi Ollila
On Mon, Aug 06 2012, David Bremner da...@tethera.net wrote:

 It has been a few months since we last had a release.

 I'd like to to another release within the next few weeks. To this end
 I'd like to take a snapshot of master next Sunday (August 12), and
 release that plus urgent bugfixes a week later (August 19).

 I realize this won't be time to get all of the interesting patches we
 are working on reviewed and merged in, but I don't want to fall into the
 trap of delaying the release indefinitely.

 Discussion?

I'd say no more features. Everybody is to pull latest HEAD: 6b820673fc9c
and start using it as widely they can (with personal patches if they have
-- at least I cannot live without those :)

Only test changes that may help finding bugs in current HEAD and documentation
updates are to be accepted.
(for example my notmuch-test-wait patches can wait...)

All the interesting patches we have in queue are to be postponed
until 0.14 is out to lessen the chance of unexpeted problems that may
arise...

 d

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


Re: [PATCH] emacs: Make moving to the previous message move to the previous boundary

2012-08-06 Thread Tomi Ollila
On Sat, Jul 14 2012, Austin Clements amdra...@mit.edu wrote:

 Previously, notmuch-show-previous-message would move to the beginning
 of the message before the message containing point.  This patch makes
 it instead move to the previous message *boundary*.  That is, if point
 isn't already at the beginning of the message, it moves to the
 beginning of the current message.  This is consistent with
 notmuch-show-next-message, which can be thought of as moving to the
 next message boundary.  Several people have expressed a preference for
 this.
 ---

LGTM. Contrary to what I wrote in id:m2pq746tlq@guru.guru-group.fi
I think this could be pushed...

Tomi

 This patch accompanies the series in [0] (though they're independent
 and can be applied in either order).  This makes the behavior of 'p'
 and 'P' in show-mode conceptually similar to the new behavior of 'p'
 in search-mode.

 [0] 1342140319-19859-1-git-send-email-amdra...@mit.edu

  emacs/notmuch-show.el |   10 +++---
  1 file changed, 7 insertions(+), 3 deletions(-)

 diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
 index 6335d45..02e319f 100644
 --- a/emacs/notmuch-show.el
 +++ b/emacs/notmuch-show.el
 @@ -1525,9 +1525,11 @@ thread, navigate to the next thread in the parent 
 search buffer.
(goto-char (point-max)
  
  (defun notmuch-show-previous-message ()
 -  Show the previous message.
 +  Show the previous message or the start of the current message.
(interactive)
 -  (notmuch-show-goto-message-previous)
 +  (if (= (point) (notmuch-show-message-top))
 +  (notmuch-show-goto-message-previous)
 +(notmuch-show-move-to-message-top))
(notmuch-show-mark-read)
(notmuch-show-message-adjust))
  
 @@ -1587,7 +1589,9 @@ to show, nil otherwise.
  (defun notmuch-show-previous-open-message ()
Show the previous open message.
(interactive)
 -  (while (and (notmuch-show-goto-message-previous)
 +  (while (and (if (= (point) (notmuch-show-message-top))
 +   (notmuch-show-goto-message-previous)
 + (notmuch-show-move-to-message-top))
 (not (notmuch-show-message-visible-p
(notmuch-show-mark-read)
(notmuch-show-message-adjust))
 -- 
 1.7.10

 ___
 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 1/4] show: indicate length of omitted body content (json)

2012-08-06 Thread Peter Wang
On Sun, 05 Aug 2012 14:37:02 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 On Sun, Aug 05 2012, Peter Wang noval...@gmail.com wrote:
  diff --git a/devel/schemata b/devel/schemata
  index 9cb25f5..3df2764 100644
  --- a/devel/schemata
  +++ b/devel/schemata
  @@ -69,7 +69,10 @@ part = {
   # A leaf part's body content is optional, but may be included if
   # it can be correctly encoded as a string.  Consumers should use
   # this in preference to fetching the part content separately.
  -content?:   string
  +content?:   string,
  +# If a leaf part's body content is not included, the content-length
  +# may be included instead.
  +content-length?: int
 
 Hey, Peter.  Something somewhere, and probably at least here in the
 schemata, should mention what the uids are (b? kB? KiB? YiB?)

I thought content-length was a MIME header, but it's not.
Anyway, it's the length of the encoded content in bytes.  GMime
doesn't provide an easy way to return the length of the decoded content.

I actually only need an _estimate_ of the decoded size to present to the
user.  Strictly speaking, that requires knowledge of the transfer encoding.
Previously I planned on guessing it from the content-type, but I think
it's better to return the transfer encoding as well (if any).

Alternatively, notmuch could put in more effort to return the exact
length of the decoded content.  But it's a waste of time if no consumers
will use it.

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


Re: [PATCH 3/4] show: indicate length of omitted body content (text)

2012-08-06 Thread Austin Clements
I'm not sure it's worth updating the text format.  There's already
plenty of disparity between the JSON and text formats, we're
considering deprecating the text format, and, from what I understand,
this might actually break consumers of the text format (the vim
frontend?) since the text format isn't particularly extensible.

Quoth Peter Wang on Aug 05 at  5:22 pm:
 If a leaf part's body content is omitted, return the content length in
 --format=text output, for parity with --format=json output.
 ---
  notmuch-show.c |   23 +++
  1 files changed, 19 insertions(+), 4 deletions(-)
 
 diff --git a/notmuch-show.c b/notmuch-show.c
 index 5c54257..cde8a1e 100644
 --- a/notmuch-show.c
 +++ b/notmuch-show.c
 @@ -488,9 +488,17 @@ format_part_text (const void *ctx, sprinter_t *sp, 
 mime_node_t *node,
   GMIME_OBJECT (node-envelope_part) : node-part;
  GMimeContentType *content_type = g_mime_object_get_content_type (meta);
  const notmuch_bool_t leaf = GMIME_IS_PART (node-part);
 +notmuch_bool_t leaf_text_part = FALSE;
  const char *part_type;
  int i;
  
 +if (leaf 
 + g_mime_content_type_is_type (content_type, text, *) 
 + !g_mime_content_type_is_type (content_type, text, html))
 +{
 + leaf_text_part = TRUE;
 +}
 +
  if (node-envelope_file) {
   notmuch_message_t *message = node-envelope_file;
  
 @@ -519,7 +527,16 @@ format_part_text (const void *ctx, sprinter_t *sp, 
 mime_node_t *node,
   printf (, Filename: %s, filename);
   if (cid)
   printf (, Content-id: %s, cid);
 - printf (, Content-type: %s\n, g_mime_content_type_to_string 
 (content_type));
 + printf (, Content-type: %s, g_mime_content_type_to_string 
 (content_type));
 + if (leaf  !leaf_text_part) {
 + GMimeDataWrapper *wrapper = g_mime_part_get_content_object 
 (GMIME_PART (node-part));
 + GMimeStream *stream = g_mime_data_wrapper_get_stream (wrapper);
 + ssize_t length = g_mime_stream_length (stream);
 + if (length = 0) {
 + printf (, Content-length: %ld, length);
 + }

Same comment about possibly unref'ing wrapper and/or stream.

 + }
 + printf (\n);
  }
  
  if (GMIME_IS_MESSAGE (node-part)) {
 @@ -547,9 +564,7 @@ format_part_text (const void *ctx, sprinter_t *sp, 
 mime_node_t *node,
  }
  
  if (leaf) {
 - if (g_mime_content_type_is_type (content_type, text, *) 
 - !g_mime_content_type_is_type (content_type, text, html))
 - {
 + if (leaf_text_part) {
   GMimeStream *stream_stdout = g_mime_stream_file_new (stdout);
   g_mime_stream_file_set_owner (GMIME_STREAM_FILE (stream_stdout), 
 FALSE);
   show_text_part_content (node-part, stream_stdout, 0);
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] notmuch-show: add notmuch-show-auto-mark-read option

2012-08-06 Thread Michal Nazarewicz
Austin Clements amdra...@mit.edu writes:
 LGTM, though I wonder: Is this actually what you want, or would you be
 happy with automatic read marking if it followed a different pattern
 (perhaps a more predictable pattern)?

At the moment, I feel that's what I want.  I have a few keys set up for
addings tags like mute or delete, ie.:

 (set-key notmuch-show-mode-map key
  (notmuch-show-tag tag) (notmuch-show-next-thread t))

This adds the tag and opens the next thread, which is great, except
I sometimes don't want to mark the next thread unread.

I have two more shortcut which go to the next thread but one of them
removes unread tag.  This way, this setup does not mean I have to type
more -- I just need to conciously choose whether I want to tag current
message read or not.

 Quoth Michal Nazarewicz on Aug 06 at  4:20 pm:
 From: Michal Nazarewicz min...@mina86.com
 
 Setting `notmuch-show-auto-mark-read' to nil stops notmuch-show from marking
 the message as read (by removing the unread tag).  Inteded for people who
 like to mark messages read explicitly.

-- 
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of  o' \,=./ `o
..o | Computer Science,  Michał “mina86” Nazarewicz(o o)
ooo +email/xmpp: m...@google.com--ooO--(_)--Ooo--

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


Re: Vim plugins

2012-08-06 Thread Sepp Tannhuber
Hi Anton,

thanks for answering. Finally I found it. My next problem is that I have 
absolutely no idea how to use it.
I followed the instructions I have found in this mailing list and copied the 
syntax files into my ~/.vim/syntax
and the two plugin files into my ~/.vim/plugin folders.

Then I called
    vi -c 'NMVimpy()'
The result is
    E492: Not an editor command: NMVimpy()

I tried
    vi -c ':nm_vimpy()'
as well. And vi answers
    No mapping found

Is there a README file or any other kind of documentation for your script?

Best regards
Joseph

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


Re: Small bug in json-search changes

2012-08-06 Thread Austin Clements
Nice catch.  I think the solution is either exactly this, or we should
strip thread: off notmuch-search-target-thread when we set it.  I
would lean slightly toward the latter so we don't have to generate up
a new (identical) string on every notmuch-search-show-result call, but
I doubt it would make much difference in the grand scheme of things.

Quoth Mark Walters on Aug 07 at 12:10 am:
 
 Hi
 
 I have found a small bug in the recent changes to notmuch search to use
 the JSON output. If you refresh the search buffer point does not stay
 on the same thread. 
 
 I think the problem is that notmuch-search-refresh-view calls notmuch
 search with target-thread set to notmuch-search-find-thread-id which
 returns the thread-id with thread: prefixed, whereas
 notmuch-search-show-result checks for a match with (plist-get result
 :thread) which is the thread id with no prefix.
 
 The patch below fixes this but I am not sure it is the nicest fix.
 
 Best wishes
 
 Mark
 
 diff --git a/emacs/notmuch.el b/emacs/notmuch.el
 index d2d82a9..a53d5a0 100644
 --- a/emacs/notmuch.el
 +++ b/emacs/notmuch.el
 @@ -798,7 +798,7 @@ non-authors is found, assume that all of the authors 
 match.
   (insert \n)
   (notmuch-search-color-line beg (point) (plist-get result :tags))
   (put-text-property beg (point) 'notmuch-search-result result))
 -  (when (string= (plist-get result :thread) notmuch-search-target-thread)
 +  (when (string= (concat thread: (plist-get result :thread)) 
 notmuch-search-target-thread)
   (setq notmuch-search-target-thread found)
   (goto-char beg)
  
 
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: Vim plugins

2012-08-06 Thread Anton Khirnov

On Mon, 6 Aug 2012 23:29:08 +0100 (BST), Sepp Tannhuber 
sepp.tannhu...@yahoo.de wrote:
 Hi Anton,
 
 thanks for answering. Finally I found it. My next problem is that I have 
 absolutely no idea how to use it.
 I followed the instructions I have found in this mailing list and copied the 
 syntax files into my ~/.vim/syntax
 and the two plugin files into my ~/.vim/plugin folders.
 
 Then I called
     vi -c 'NMVimpy()'
 The result is
     E492: Not an editor command: NMVimpy()
 
 I tried
     vi -c ':nm_vimpy()'
 as well. And vi answers
     No mapping found
 

I invoke it as vim -c :NMVimpy

 Is there a README file or any other kind of documentation for your script?
 

I wish. Patches welcome ;)

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


Segmentation fault in notmuch search --format=json

2012-08-06 Thread Ben Gamari
It seems some messages trigger a segmentation fault in
`do_search_threads()`. It appears the problem occurs (at least) when
`authors` is NULL.

Program received signal SIGSEGV, Segmentation fault.
0x00415aa3 in json_string (sp=0x646c70, val=0x0) at 
sprinter-json.c:121
121 json_string_len (sp, val, strlen (val));
(gdb) bt
#0  0x00415aa3 in json_string (sp=0x646c70, val=0x0)
at sprinter-json.c:121
#1  0x0041084b in do_search_threads (format=0x646c70, 
query=0x64bb70, 
sort=NOTMUCH_SORT_NEWEST_FIRST, output=OUTPUT_SUMMARY, offset=0, 
limit=-1)
at notmuch-search.c:131
#2  0x00411361 in notmuch_search_command (ctx=0x6361b0, argc=3, 
argv=0x7fffdfb0) at notmuch-search.c:405
#3  0x00409e22 in main (argc=4, argv=0x7fffdfa8) at 
notmuch.c:294
(gdb) up
#1  0x0041084b in do_search_threads (format=0x646c70, 
query=0x64bb70, 
sort=NOTMUCH_SORT_NEWEST_FIRST, output=OUTPUT_SUMMARY, offset=0, 
limit=-1)
at notmuch-search.c:131
131 format-string (format, authors);
(gdb) list
126 format-map_key (format, matched);
127 format-integer (format, matched);
128 format-map_key (format, total);
129 format-integer (format, total);
130 format-map_key (format, authors);
131 format-string (format, authors);
132 format-map_key (format, subject);
133 format-string (format, subject);
134 }
135 
(gdb) 

It seems that the message in question was produced by a script I use to
feed RSS feeds into notmuch so while I wouldn't doubt that there are few
cases where `authors` should be NULL, it would be nice if notmuch
handled this case with a bit more grace.

Cheers,

- Ben

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