[PATCH v3 0/8] emacs: JSON-based search cleanups

2012-07-15 Thread Mark Walters
On Sun, 15 Jul 2012, Austin Clements  wrote:
> On Sun, 15 Jul 2012, Mark Walters  wrote:
>> On Sun, 15 Jul 2012, Austin Clements  wrote:
>>> This version swaps out the notmuch-search-do-results macro for a
>>> higher-order function, notmuch-search-foreach-result.  This requires
>>> less squiting to understand and clearly distinguishes the arguments
>>> passed in to the function from the arguments passed to the callback.
>>> This version also updates the docstring for
>>> notmuch-search-result-format to mention that multi-line result formats
>>> work and how to enter them, and it adds a NEWS patch.
>>
>> Hello
>>
>> I am afraid I have found a minor (but reproducible) bug in the line
>> re-drawing even with single line results. Find a search result with a
>> partially elided author field and put the cursor after the ellipsis in
>> that line. Then update the tags. The result gets redrawn with ellipsis
>> written out in full. Re-redrawing with the cursor after the author field
>> redraws the line with the keeping the ellipsis written out in full,
>> whereas re-redrawing the line with cursor before the author field gets
>> it written with the correct ellipsis.
>
> Arrrg, overlays.
>
> I can think of two ways to fix this.  We could generate the author
> elision overlays lazily (say, via jit-lock).  This would have the added
> benefit of eliminating what I think is the last quadratic factor in
> building search buffers, but there are much easier ways to do that.  Or,
> I could scrap the insert-before-markers nonsense and manipulate point
> directly in notmuch-search-update-result, with the caveat that the
> little bit of support it had for doing sane things in some situations
> involving save-excursions would be lost.  Given that we never call
> notmuch-search-update-result inside a save-excursion (precisely because
> I couldn't reliably hit the narrow window of situations it could handle
> when there were save-excursions involved), I'd lean toward the latter
> option.

I think I don't really know enough emacs/lisp to be able to say anything
sensible. I think manipulating point directly seems good because then I
think we can make sure things work in the multiline case too. 

I haven't yet worked out whether multiline is an amusing "oh look it works"
or genuinely useful thing. I am leaning towards the latter as do often
work on laptops with quite small screens and think I would like to see
more about a smaller number of results.

Best wishes

Mark



[PATCH v3 0/8] emacs: JSON-based search cleanups

2012-07-15 Thread Mark Walters

On Sun, 15 Jul 2012, Austin Clements  wrote:
> This version swaps out the notmuch-search-do-results macro for a
> higher-order function, notmuch-search-foreach-result.  This requires
> less squiting to understand and clearly distinguishes the arguments
> passed in to the function from the arguments passed to the callback.
> This version also updates the docstring for
> notmuch-search-result-format to mention that multi-line result formats
> work and how to enter them, and it adds a NEWS patch.

Hello

I am afraid I have found a minor (but reproducible) bug in the line
re-drawing even with single line results. Find a search result with a
partially elided author field and put the cursor after the ellipsis in
that line. Then update the tags. The result gets redrawn with ellipsis
written out in full. Re-redrawing with the cursor after the author field
redraws the line with the keeping the ellipsis written out in full,
whereas re-redrawing the line with cursor before the author field gets
it written with the correct ellipsis.

Best wishes

Mark
>
> Diff from v2:
>
> diff --git a/NEWS b/NEWS
> index a1a6e93..7b33f0d 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -17,6 +17,20 @@ Maildir tag synchronization
>  Emacs Interface
>  ---
>  
> +Search results now get re-colored when tags are updated
> +
> +The formatting of tags in search results can now be customized
> +
> +  Previously, attempting to change the format of tags in
> +  `notmuch-search-result-format` would usually break tagging from
> +  search-mode.  We no longer make assumptions about the format.
> +
> +Multi-line search result formats are now supported
> +
> +  It is now possible to embed newlines in
> +  `notmuch-search-result-format` to make individual search results
> +  span multiple lines.
> +
>  Search now uses the JSON format internally
>  
>This should address problems with unusual characters in authors and
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index 7302fa7..ec760dc 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -69,7 +69,13 @@
>   date, count, authors, subject, tags
>  For example:
>   (setq notmuch-search-result-format \(\(\"authors\" . \"%-40s\"\)
> -  \(\"subject\" . \"%s\"\)\)\)"
> +  \(\"subject\" . \"%s\"\)\)\)
> +Line breaks are permitted in format strings.  Note that a line
> +break at the end of an \"authors\" field will get elided if the
> +authors list is long; place it instead at the beginning of the
> +following field.  To enter a line break when setting this
> +variable with setq, use \\n.  To enter a line break in customize,
> +press \\[quoted-insert] C-j."
>:type '(alist :key-type (string) :value-type (string))
>:group 'notmuch-search)
>  
> @@ -433,32 +439,39 @@ returns nil"
>  (next-single-property-change (or pos (point)) 'notmuch-search-result
>nil (point-max
>  
> -(defmacro notmuch-search-do-results (beg end pos-sym  body)
> -  "Invoke BODY for each result between BEG and END.
> -
> -POS-SYM will be bound to the point at the beginning of the
> -current result."
> -  (declare (indent 3))
> -  (let ((end-sym (make-symbol "end"))
> - (first-sym (make-symbol "first")))
> -`(let ((,pos-sym (notmuch-search-result-beginning ,beg))
> -;; End must be a marker in case body changes the text
> -(,end-sym (copy-marker ,end))
> -;; Make sure we examine one result, even if (= beg end)
> -(,first-sym t))
> -   ;; We have to be careful if the region extends beyond the
> -   ;; results.  In this case, pos could be null or there could be
> -   ;; no result at pos.
> -   (while (and ,pos-sym (or (< ,pos-sym ,end-sym) ,first-sym))
> -  (when (notmuch-search-get-result ,pos-sym)
> -, at body)
> -  (setq ,pos-sym (notmuch-search-result-end ,pos-sym)
> -,first-sym nil)
> +(defun notmuch-search-foreach-result (beg end function)
> +  "Invoke FUNCTION for each result between BEG and END.
> +
> +FUNCTION should take one argument.  It will be applied to the
> +character position of the beginning of each result that overlaps
> +the region between points BEG and END.  As a special case, if (=
> +BEG END), FUNCTION will be applied to the result containing point
> +BEG."
> +
> +  (lexical-let ((pos (notmuch-search-result-beginning beg))
> + ;; End must be a marker in case function changes the
> + ;; text.
> + (end (copy-marker end))
> + ;; Make sure we examine at least one result, even if
> + ;; (= beg end).
> + (first t))
> +;; We have to be careful if the region extends beyond the results.
> +;; In this case, pos could be null or there could be no result at
> +;; pos.
> +(while (and pos (or (< pos end) first))
> +  (when (notmuch-search-get-result pos)
> + (funcall function pos))
> +  (setq pos 

[PATCH v3 0/8] emacs: JSON-based search cleanups

2012-07-15 Thread Jameson Graef Rollins
On Sun, Jul 15 2012, Mark Walters  wrote:
> However, there are some problems with multiline search results (see
> below) so I think we should either fix these or just downplay this new
> functionality by, for example, removing the comments on newlines from
> the defcustom and saying in NEWS that the feature is experimental/not
> complete or similar. (NEWS could say how to enter newlines in the
> defcustom)
>
> With this minor comment on the documentation my criticisms should not
> hold up this excellent series.

I agree that multi-line support needs a little bit more work before it's
ready for prime time.  I'll keep experimenting with it as well and see
if I can uncover any other issues.

But I definitely also agree that that work should *not* hold up this
patch series, as it adds plenty of other benefits.

> Examples of "incompleteness": these are rather more personal but it
> seems odd to me to highlight one line rather than one result in the
> buffer. Similarly I would expect   to scroll up or down by
> one result rather than one line.

Highlighting the entire entry should definitely be fixed, since
otherwise it can be hard to see which of the other lines is associated
with the current entry.

I also notice that the author field munging causes some weird behaviors.
Certain formatter strings can cause it to break.  If we can get that
fixed it might be nice to have a similar functionality for the subject
field, which can also be really long.

jamie.
-- 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/20120715/098430ae/attachment.pgp>


[PATCH v3 0/8] emacs: JSON-based search cleanups

2012-07-15 Thread Austin Clements
On Sun, 15 Jul 2012, Mark Walters  wrote:
> On Sun, 15 Jul 2012, Austin Clements  wrote:
>> This version swaps out the notmuch-search-do-results macro for a
>> higher-order function, notmuch-search-foreach-result.  This requires
>> less squiting to understand and clearly distinguishes the arguments
>> passed in to the function from the arguments passed to the callback.
>> This version also updates the docstring for
>> notmuch-search-result-format to mention that multi-line result formats
>> work and how to enter them, and it adds a NEWS patch.
>
> Hello
>
> I am afraid I have found a minor (but reproducible) bug in the line
> re-drawing even with single line results. Find a search result with a
> partially elided author field and put the cursor after the ellipsis in
> that line. Then update the tags. The result gets redrawn with ellipsis
> written out in full. Re-redrawing with the cursor after the author field
> redraws the line with the keeping the ellipsis written out in full,
> whereas re-redrawing the line with cursor before the author field gets
> it written with the correct ellipsis.

Arrrg, overlays.

I can think of two ways to fix this.  We could generate the author
elision overlays lazily (say, via jit-lock).  This would have the added
benefit of eliminating what I think is the last quadratic factor in
building search buffers, but there are much easier ways to do that.  Or,
I could scrap the insert-before-markers nonsense and manipulate point
directly in notmuch-search-update-result, with the caveat that the
little bit of support it had for doing sane things in some situations
involving save-excursions would be lost.  Given that we never call
notmuch-search-update-result inside a save-excursion (precisely because
I couldn't reliably hit the narrow window of situations it could handle
when there were save-excursions involved), I'd lean toward the latter
option.


Notmuch scripts (again), now with more usenet

2012-07-15 Thread David Bremner
ccx at webprojekty.cz writes:

> I hope it's now in the form acceptable for inclusion to contrib.

Dear Jan;

Without looking too much at the details I think this is reasonable to
include in contrib, as a set of examples if nothing else. Still, I'm
curious about a few things. Are there actual users (other than the
author)?  What would we do about bug reports? Will you follow the list,
or would we explicitely tell people to contact you directly?

I guess some of the python experts might want to discuss the coding
style of notmuch-new.py. pylint goes ballistic, for whatever that is
worth.

For the shell stuff, I noticed lots of unquoted parameter expansion;
also at some point you make a temporary directory using $$
directly rather than using e.g. mktemp.

What did you have in mind for a license? since there is no linking here,
it does not have to be GPL3+, but some standard Free license is needed I
think; since I'm also maintaining the Debian package, I don't want to
have to remove your stuff before uploading to Debian.

d





[PATCH v3 0/8] emacs: JSON-based search cleanups

2012-07-15 Thread Mark Walters
On Sun, 15 Jul 2012, Austin Clements  wrote:
> This version swaps out the notmuch-search-do-results macro for a
> higher-order function, notmuch-search-foreach-result.  This requires
> less squiting to understand and clearly distinguishes the arguments
> passed in to the function from the arguments passed to the callback.
> This version also updates the docstring for
> notmuch-search-result-format to mention that multi-line result formats
> work and how to enter them, and it adds a NEWS patch.

Hi 

In essence this version looks good and, contrary to what I though
before, I do prefer this function version to the macro. In addition it
seems to work well in testing.

However, there are some problems with multiline search results (see
below) so I think we should either fix these or just downplay this new
functionality by, for example, removing the comments on newlines from
the defcustom and saying in NEWS that the feature is experimental/not
complete or similar. (NEWS could say how to enter newlines in the
defcustom)

With this minor comment on the documentation my criticisms should not
hold up this excellent series.

Multiline oddities and todo

There is still some strange scrolling when updating a result. One
example that seems reproducible is if the search format has trailing
newline and the cursor is at the start of that line it may jump to the
far right of the previous line (possibly scrolling the screen
horizontally) upon a tag change (eg +unread).

If the format has a newline at the start of the author field it
sometimes gets omitted from the output. (In addition to the known
problem at the end of the author field that Austin mentions in the
documentation for the defcustom).

Examples of "incompleteness": these are rather more personal but it
seems odd to me to highlight one line rather than one result in the
buffer. Similarly I would expect   to scroll up or down by
one result rather than one line.

I have a draft patch which fixes these two and mostly fixes the
scrolling but it is bigger than I would like (and I haven't yet ironed
out/checked all corner cases). I will split it up and send to the list
so people can try it (but it is not intended as a submission
currently).

As it seems to be tricky to get fully right it might be preferable
just to change the documentation as suggested above and leave
multi-line to the adventurous.

Best wishes 

Mark

>
> Diff from v2:
>
> diff --git a/NEWS b/NEWS
> index a1a6e93..7b33f0d 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -17,6 +17,20 @@ Maildir tag synchronization
>  Emacs Interface
>  ---
>  
> +Search results now get re-colored when tags are updated
> +
> +The formatting of tags in search results can now be customized
> +
> +  Previously, attempting to change the format of tags in
> +  `notmuch-search-result-format` would usually break tagging from
> +  search-mode.  We no longer make assumptions about the format.
> +
> +Multi-line search result formats are now supported
> +
> +  It is now possible to embed newlines in
> +  `notmuch-search-result-format` to make individual search results
> +  span multiple lines.
> +
>  Search now uses the JSON format internally
>  
>This should address problems with unusual characters in authors and
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index 7302fa7..ec760dc 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -69,7 +69,13 @@
>   date, count, authors, subject, tags
>  For example:
>   (setq notmuch-search-result-format \(\(\"authors\" . \"%-40s\"\)
> -  \(\"subject\" . \"%s\"\)\)\)"
> +  \(\"subject\" . \"%s\"\)\)\)
> +Line breaks are permitted in format strings.  Note that a line
> +break at the end of an \"authors\" field will get elided if the
> +authors list is long; place it instead at the beginning of the
> +following field.  To enter a line break when setting this
> +variable with setq, use \\n.  To enter a line break in customize,
> +press \\[quoted-insert] C-j."
>:type '(alist :key-type (string) :value-type (string))
>:group 'notmuch-search)
>  
> @@ -433,32 +439,39 @@ returns nil"
>  (next-single-property-change (or pos (point)) 'notmuch-search-result
>nil (point-max
>  
> -(defmacro notmuch-search-do-results (beg end pos-sym  body)
> -  "Invoke BODY for each result between BEG and END.
> -
> -POS-SYM will be bound to the point at the beginning of the
> -current result."
> -  (declare (indent 3))
> -  (let ((end-sym (make-symbol "end"))
> - (first-sym (make-symbol "first")))
> -`(let ((,pos-sym (notmuch-search-result-beginning ,beg))
> -;; End must be a marker in case body changes the text
> -(,end-sym (copy-marker ,end))
> -;; Make sure we examine one result, even if (= beg end)
> -(,first-sym t))
> -   ;; We have to be careful if the region extends beyond the
> -   ;; results.  In this case, 

Re: [PATCH v3 0/8] emacs: JSON-based search cleanups

2012-07-15 Thread Mark Walters

On Sun, 15 Jul 2012, Austin Clements amdra...@mit.edu wrote:
 This version swaps out the notmuch-search-do-results macro for a
 higher-order function, notmuch-search-foreach-result.  This requires
 less squiting to understand and clearly distinguishes the arguments
 passed in to the function from the arguments passed to the callback.
 This version also updates the docstring for
 notmuch-search-result-format to mention that multi-line result formats
 work and how to enter them, and it adds a NEWS patch.

Hello

I am afraid I have found a minor (but reproducible) bug in the line
re-drawing even with single line results. Find a search result with a
partially elided author field and put the cursor after the ellipsis in
that line. Then update the tags. The result gets redrawn with ellipsis
written out in full. Re-redrawing with the cursor after the author field
redraws the line with the keeping the ellipsis written out in full,
whereas re-redrawing the line with cursor before the author field gets
it written with the correct ellipsis.

Best wishes

Mark

 Diff from v2:

 diff --git a/NEWS b/NEWS
 index a1a6e93..7b33f0d 100644
 --- a/NEWS
 +++ b/NEWS
 @@ -17,6 +17,20 @@ Maildir tag synchronization
  Emacs Interface
  ---
  
 +Search results now get re-colored when tags are updated
 +
 +The formatting of tags in search results can now be customized
 +
 +  Previously, attempting to change the format of tags in
 +  `notmuch-search-result-format` would usually break tagging from
 +  search-mode.  We no longer make assumptions about the format.
 +
 +Multi-line search result formats are now supported
 +
 +  It is now possible to embed newlines in
 +  `notmuch-search-result-format` to make individual search results
 +  span multiple lines.
 +
  Search now uses the JSON format internally
  
This should address problems with unusual characters in authors and
 diff --git a/emacs/notmuch.el b/emacs/notmuch.el
 index 7302fa7..ec760dc 100644
 --- a/emacs/notmuch.el
 +++ b/emacs/notmuch.el
 @@ -69,7 +69,13 @@
   date, count, authors, subject, tags
  For example:
   (setq notmuch-search-result-format \(\(\authors\ . \%-40s\\)
 -  \(\subject\ . \%s\\)\)\)
 +  \(\subject\ . \%s\\)\)\)
 +Line breaks are permitted in format strings.  Note that a line
 +break at the end of an \authors\ field will get elided if the
 +authors list is long; place it instead at the beginning of the
 +following field.  To enter a line break when setting this
 +variable with setq, use \\n.  To enter a line break in customize,
 +press \\[quoted-insert] C-j.
:type '(alist :key-type (string) :value-type (string))
:group 'notmuch-search)
  
 @@ -433,32 +439,39 @@ returns nil
  (next-single-property-change (or pos (point)) 'notmuch-search-result
nil (point-max
  
 -(defmacro notmuch-search-do-results (beg end pos-sym rest body)
 -  Invoke BODY for each result between BEG and END.
 -
 -POS-SYM will be bound to the point at the beginning of the
 -current result.
 -  (declare (indent 3))
 -  (let ((end-sym (make-symbol end))
 - (first-sym (make-symbol first)))
 -`(let ((,pos-sym (notmuch-search-result-beginning ,beg))
 -;; End must be a marker in case body changes the text
 -(,end-sym (copy-marker ,end))
 -;; Make sure we examine one result, even if (= beg end)
 -(,first-sym t))
 -   ;; We have to be careful if the region extends beyond the
 -   ;; results.  In this case, pos could be null or there could be
 -   ;; no result at pos.
 -   (while (and ,pos-sym (or ( ,pos-sym ,end-sym) ,first-sym))
 -  (when (notmuch-search-get-result ,pos-sym)
 -,@body)
 -  (setq ,pos-sym (notmuch-search-result-end ,pos-sym)
 -,first-sym nil)
 +(defun notmuch-search-foreach-result (beg end function)
 +  Invoke FUNCTION for each result between BEG and END.
 +
 +FUNCTION should take one argument.  It will be applied to the
 +character position of the beginning of each result that overlaps
 +the region between points BEG and END.  As a special case, if (=
 +BEG END), FUNCTION will be applied to the result containing point
 +BEG.
 +
 +  (lexical-let ((pos (notmuch-search-result-beginning beg))
 + ;; End must be a marker in case function changes the
 + ;; text.
 + (end (copy-marker end))
 + ;; Make sure we examine at least one result, even if
 + ;; (= beg end).
 + (first t))
 +;; We have to be careful if the region extends beyond the results.
 +;; In this case, pos could be null or there could be no result at
 +;; pos.
 +(while (and pos (or ( pos end) first))
 +  (when (notmuch-search-get-result pos)
 + (funcall function pos))
 +  (setq pos (notmuch-search-result-end pos)
 + first nil
 +;; Unindent the function argument of 

Re: Notmuch scripts (again), now with more usenet

2012-07-15 Thread David Bremner
c...@webprojekty.cz writes:

 I hope it's now in the form acceptable for inclusion to contrib.

Dear Jan;

Without looking too much at the details I think this is reasonable to
include in contrib, as a set of examples if nothing else. Still, I'm
curious about a few things. Are there actual users (other than the
author)?  What would we do about bug reports? Will you follow the list,
or would we explicitely tell people to contact you directly?

I guess some of the python experts might want to discuss the coding
style of notmuch-new.py. pylint goes ballistic, for whatever that is
worth.

For the shell stuff, I noticed lots of unquoted parameter expansion;
also at some point you make a temporary directory using $$
directly rather than using e.g. mktemp.

What did you have in mind for a license? since there is no linking here,
it does not have to be GPL3+, but some standard Free license is needed I
think; since I'm also maintaining the Debian package, I don't want to
have to remove your stuff before uploading to Debian.

d



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


Re: [PATCH v3 0/8] emacs: JSON-based search cleanups

2012-07-15 Thread Austin Clements
On Sun, 15 Jul 2012, Mark Walters markwalters1...@gmail.com wrote:
 On Sun, 15 Jul 2012, Austin Clements amdra...@mit.edu wrote:
 This version swaps out the notmuch-search-do-results macro for a
 higher-order function, notmuch-search-foreach-result.  This requires
 less squiting to understand and clearly distinguishes the arguments
 passed in to the function from the arguments passed to the callback.
 This version also updates the docstring for
 notmuch-search-result-format to mention that multi-line result formats
 work and how to enter them, and it adds a NEWS patch.

 Hello

 I am afraid I have found a minor (but reproducible) bug in the line
 re-drawing even with single line results. Find a search result with a
 partially elided author field and put the cursor after the ellipsis in
 that line. Then update the tags. The result gets redrawn with ellipsis
 written out in full. Re-redrawing with the cursor after the author field
 redraws the line with the keeping the ellipsis written out in full,
 whereas re-redrawing the line with cursor before the author field gets
 it written with the correct ellipsis.

Arrrg, overlays.

I can think of two ways to fix this.  We could generate the author
elision overlays lazily (say, via jit-lock).  This would have the added
benefit of eliminating what I think is the last quadratic factor in
building search buffers, but there are much easier ways to do that.  Or,
I could scrap the insert-before-markers nonsense and manipulate point
directly in notmuch-search-update-result, with the caveat that the
little bit of support it had for doing sane things in some situations
involving save-excursions would be lost.  Given that we never call
notmuch-search-update-result inside a save-excursion (precisely because
I couldn't reliably hit the narrow window of situations it could handle
when there were save-excursions involved), I'd lean toward the latter
option.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v3 0/8] emacs: JSON-based search cleanups

2012-07-15 Thread Mark Walters
On Sun, 15 Jul 2012, Austin Clements amdra...@mit.edu wrote:
 On Sun, 15 Jul 2012, Mark Walters markwalters1...@gmail.com wrote:
 On Sun, 15 Jul 2012, Austin Clements amdra...@mit.edu wrote:
 This version swaps out the notmuch-search-do-results macro for a
 higher-order function, notmuch-search-foreach-result.  This requires
 less squiting to understand and clearly distinguishes the arguments
 passed in to the function from the arguments passed to the callback.
 This version also updates the docstring for
 notmuch-search-result-format to mention that multi-line result formats
 work and how to enter them, and it adds a NEWS patch.

 Hello

 I am afraid I have found a minor (but reproducible) bug in the line
 re-drawing even with single line results. Find a search result with a
 partially elided author field and put the cursor after the ellipsis in
 that line. Then update the tags. The result gets redrawn with ellipsis
 written out in full. Re-redrawing with the cursor after the author field
 redraws the line with the keeping the ellipsis written out in full,
 whereas re-redrawing the line with cursor before the author field gets
 it written with the correct ellipsis.

 Arrrg, overlays.

 I can think of two ways to fix this.  We could generate the author
 elision overlays lazily (say, via jit-lock).  This would have the added
 benefit of eliminating what I think is the last quadratic factor in
 building search buffers, but there are much easier ways to do that.  Or,
 I could scrap the insert-before-markers nonsense and manipulate point
 directly in notmuch-search-update-result, with the caveat that the
 little bit of support it had for doing sane things in some situations
 involving save-excursions would be lost.  Given that we never call
 notmuch-search-update-result inside a save-excursion (precisely because
 I couldn't reliably hit the narrow window of situations it could handle
 when there were save-excursions involved), I'd lean toward the latter
 option.

I think I don't really know enough emacs/lisp to be able to say anything
sensible. I think manipulating point directly seems good because then I
think we can make sure things work in the multiline case too. 

I haven't yet worked out whether multiline is an amusing oh look it works
or genuinely useful thing. I am leaning towards the latter as do often
work on laptops with quite small screens and think I would like to see
more about a smaller number of results.

Best wishes

Mark

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


Re: [PATCH v3 0/8] emacs: JSON-based search cleanups

2012-07-15 Thread Jameson Graef Rollins
On Sun, Jul 15 2012, Mark Walters markwalters1...@gmail.com wrote:
 However, there are some problems with multiline search results (see
 below) so I think we should either fix these or just downplay this new
 functionality by, for example, removing the comments on newlines from
 the defcustom and saying in NEWS that the feature is experimental/not
 complete or similar. (NEWS could say how to enter newlines in the
 defcustom)

 With this minor comment on the documentation my criticisms should not
 hold up this excellent series.

I agree that multi-line support needs a little bit more work before it's
ready for prime time.  I'll keep experimenting with it as well and see
if I can uncover any other issues.

But I definitely also agree that that work should *not* hold up this
patch series, as it adds plenty of other benefits.

 Examples of incompleteness: these are rather more personal but it
 seems odd to me to highlight one line rather than one result in the
 buffer. Similarly I would expect up down to scroll up or down by
 one result rather than one line.

Highlighting the entire entry should definitely be fixed, since
otherwise it can be hard to see which of the other lines is associated
with the current entry.

I also notice that the author field munging causes some weird behaviors.
Certain formatter strings can cause it to break.  If we can get that
fixed it might be nice to have a similar functionality for the subject
field, which can also be really long.

jamie.


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


Re: Notmuch scripts (again), now with more usenet

2012-07-15 Thread Daniel Schoepe
On Sun, 15.07.2012 18:36, David Bremner wrote:
 Are there actual users (other than the author)?

I started using the slrn2maildir script yesterday, but none of the other
scripts. It's working fine so far.

Cheers,
Daniel


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