Re: [Patch v3 0/3] emacs: show: redesign unread/read logic

[Mark Walters]

On Thu, 08 May 2014, David Edmondson  wrote:
> On Wed, May 07 2014, Mark Walters wrote:
>> A message is marked read if:
>>
>> 1) if you navigate to a message using n/p (next/prev open message) 
>>
>> 2) if you navigate to it using N/P (next/prev message) regardless of
>> whether the message is open or closed.
>>
>> 3) if you go to it using n.s.next-matching-message (not bound by
>> default) whether message is open or closed.
>>
>> 4) when you enter a buffer and notmuch goes to the first open message.
>>
>> but not marked read in cases like:
>>
>> 1) opening a message
>>
>> 2) viewing or entering a message using other notmuch navigation such as
>> notmuch-show-advance and friends (bound to space)
>
> My experience is that this removes the 'unread' tag.

Sorry I was wrong here. This one does mark it read.

>> 3) viewing or entering a message using arrow keys, page-up page-down,
>> ctrl-v mouse clicks etc

This is perhaps a key one: should the above mark it read.

>> Personally, I think marking a closed message read is a bug,
>
> Agreed.
>
>> and not marking it read when opening it is too
>
> Agreed.
>
>> (at least in many cases).
>
> I would be happy with just these fixed (i.e. the current behaviour with
> those two bug fixes). My typical use is to move around a thread using
> Space, Backspace, n, p, N and P with RET, M-RET and C-u M-RET to
> manipulate open/closed state (i.e. not the normal emacs movement
> commands to move).
>
>> The other problem with the current approach (in my view) is that if
>> you try to use the navigation commands non-interactively then messages
>> end up being marked read, even if they are never displayed to the
>> user.
>
> In what cases does this happen? (Not arguing, just not fully
> understanding.)

I had a series for implementing filtering (ie limiting the open
messages) in show where it was the main cause of my stopping. See
id:20120429005736.gk2...@mit.edu for details of the problems.

>> Linking into the post-command-hook means that this should "just work".
>>
>> Questions:  What does it mean for a message to be the current message?
>> Is it just point being in the message?
>
> This makes sense to me, other than perhaps "point being in an _open_
> message". I don't want moving point through a closed message with C-n to
> remove the 'unread' tag.

Oh yes I completely agree with that.

Best wishes

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

[PATCH v2] emacs/notmuch-mua: Generate improved cited text for replies

[David Edmondson]

Use the message display code to generate message text to cite in
replies.
---
 emacs/notmuch-mua.el | 38 --
 1 file changed, 8 insertions(+), 30 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 95e4a4d..09c922f 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -28,7 +28,7 @@
 
 (eval-when-compile (require 'cl))
 
-(declare-function notmuch-show-insert-bodypart "notmuch-show" (msg part depth 
&optional hide))
+(declare-function notmuch-show-insert-body "notmuch-show" (msg body depth))
 
 ;;
 
@@ -123,31 +123,6 @@ list."
else if (notmuch-match-content-type (plist-get part :content-type) 
"multipart/*")
  do (notmuch-mua-reply-crypto (plist-get part :content
 
-(defun notmuch-mua-get-quotable-parts (parts)
-  (loop for part in parts
-   if (notmuch-match-content-type (plist-get part :content-type) 
"multipart/alternative")
- collect (let* ((subparts (plist-get part :content))
-   (types (mapcar (lambda (part) (plist-get part 
:content-type)) subparts))
-   (chosen-type (car (notmuch-multipart/alternative-choose 
types
-  (loop for part in (reverse subparts)
-if (notmuch-match-content-type (plist-get part 
:content-type) chosen-type)
-return part))
-   else if (notmuch-match-content-type (plist-get part :content-type) 
"multipart/*")
- append (notmuch-mua-get-quotable-parts (plist-get part :content))
-   else if (notmuch-match-content-type (plist-get part :content-type) 
"text/*")
- collect part))
-
-(defun notmuch-mua-insert-quotable-part (message part)
-  ;; We don't want text properties leaking from the show renderer into
-  ;; the reply so we use a temp buffer. Also we don't want hooks, such
-  ;; as notmuch-wash-*, to be run on the quotable part so we set
-  ;; notmuch-show-insert-text/plain-hook to nil.
-  (insert (with-temp-buffer
-   (let ((notmuch-show-insert-text/plain-hook nil))
- ;; Show the part but do not add buttons.
- (notmuch-show-insert-bodypart message part 0 'no-buttons))
-   (buffer-substring-no-properties (point-min) (point-max)
-
 ;; There is a bug in emacs 23's message.el that results in a newline
 ;; not being inserted after the References header, so the next header
 ;; is concatenated to the end of it. This function fixes the problem,
@@ -225,10 +200,13 @@ list."
(insert "From: " from "\n")
(insert "Date: " date "\n\n")
 
-   ;; Get the parts of the original message that should be quoted; this 
includes
-   ;; all the text parts, except the non-preferred ones in a 
multipart/alternative.
-   (let ((quotable-parts (notmuch-mua-get-quotable-parts (plist-get 
original :body
- (mapc (apply-partially 'notmuch-mua-insert-quotable-part original) 
quotable-parts))
+   (insert (with-temp-buffer
+ ;; Don't attempt to clean up messages, excerpt
+ ;; citations, etc. in the original message before
+ ;; quoting.
+ (let ((notmuch-show-insert-text/plain-hook nil))
+   (notmuch-show-insert-body original (plist-get original 
:body) 0)
+   (buffer-substring-no-properties (point-min) (point-max)
 
(set-mark (point))
(goto-char start)
-- 
2.0.0.rc0

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

[PATCH v2] emacs: Improve the cited message included in replies

[David Edmondson]

emacs: Improve the cited message included in replies

v2:
- Don't run the text/plain hooks when generating the message to quote.


David Edmondson (1):
  emacs/notmuch-mua: Generate improved cited text for replies

 emacs/notmuch-mua.el | 38 --
 1 file changed, 8 insertions(+), 30 deletions(-)

-- 
2.0.0.rc0

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

Re: [Patch v3 0/3] emacs: show: redesign unread/read logic

[David Edmondson]

On Wed, May 07 2014, Mark Walters wrote:
> A message is marked read if:
>
> 1) if you navigate to a message using n/p (next/prev open message) 
>
> 2) if you navigate to it using N/P (next/prev message) regardless of
> whether the message is open or closed.
>
> 3) if you go to it using n.s.next-matching-message (not bound by
> default) whether message is open or closed.
>
> 4) when you enter a buffer and notmuch goes to the first open message.
>
> but not marked read in cases like:
>
> 1) opening a message
>
> 2) viewing or entering a message using other notmuch navigation such as
> notmuch-show-advance and friends (bound to space)

My experience is that this removes the 'unread' tag.

> 3) viewing or entering a message using arrow keys, page-up page-down,
> ctrl-v mouse clicks etc
>
> Personally, I think marking a closed message read is a bug,

Agreed.

> and not marking it read when opening it is too

Agreed.

> (at least in many cases).

I would be happy with just these fixed (i.e. the current behaviour with
those two bug fixes). My typical use is to move around a thread using
Space, Backspace, n, p, N and P with RET, M-RET and C-u M-RET to
manipulate open/closed state (i.e. not the normal emacs movement
commands to move).

> The other problem with the current approach (in my view) is that if
> you try to use the navigation commands non-interactively then messages
> end up being marked read, even if they are never displayed to the
> user.

In what cases does this happen? (Not arguing, just not fully
understanding.)

> Linking into the post-command-hook means that this should "just work".
>
> Questions:  What does it mean for a message to be the current message?
> Is it just point being in the message?

This makes sense to me, other than perhaps "point being in an _open_
message". I don't want moving point through a closed message with C-n to
remove the 'unread' tag.

> Would you be happy with a message being marked read when point entered
> the message? That could be done from the post-command-hook
> infrastructure to fix some of the problems mentioned above.
>
> I think that is likely that people will disagree on how they want this
> to work so I would like to try and make it customisable so I would
> definitely be interested to see if I can get the behaviour you would
> like from this infrastructure (or something similar).
>
> Best wishes
>
> Mark


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

[PATCH 1/1] devel: news2wiki to recognize yyyy-mm-dd or UNRELEASED as release date

[Tomi Ollila]

The -mm-dd (actually \d\d\d\d-\d\d-\d\d) for a bit more restrictive
(and self-documentative) than the \w\w\w\w-... that used to be there and
UNRELEASED so that developers can test the latest NEWS converted to mdwn
format before submitting NEWS patches.
---
 devel/news2wiki.pl | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/devel/news2wiki.pl b/devel/news2wiki.pl
index 8066ba7..d966bab 100755
--- a/devel/news2wiki.pl
+++ b/devel/news2wiki.pl
@@ -32,8 +32,7 @@ while ()
 {
 warn "$ARGV[0]:$.: tab(s) in line!\n" if /\t/;
 warn "$ARGV[0]:$.: trailing whitespace\n" if /\s\s$/;
-# The date part in regex recognizes wip version dates like: (201x-xx-xx).
-if (/^Notmuch\s+(\S+)\s+\((\w\w\w\w-\w\w-\w\w)\)\s*$/) {
+if (/^Notmuch\s+(\S+)\s+\((\d\d\d\d-\d\d-\d\d|UNRELEASED)\)\s*$/) {
# open O... autocloses previously opened file.
open O, '>', "$ARGV[1]/release-$1.mdwn" or die $!;
print "+ release-$1.mdwn...\n";
-- 
1.9.0

Github?

[Wael Nasreddine]

I forgot to mention that I also enabled Travis-CI for notmuch, you can
access it here , there are 33 failed
tests, they are also failing on my own machine.

On Wed May 07 2014 at 10:28:06 PM, Wael Nasreddine <
wael.nasredd...@gmail.com> wrote:

> Hello everyone,
>
> Thank you so much for creating Notmuch, I am coming from sup and I was
> looking for a more stable alternative and I think I found what I am looking
> for :)
>
> I was a bit disappointed that the project is not living (or at least
> mirrored) to Github, it would have made my search much easier. Any thoughts
> on moving to Github? I took the liberty of making the first move by
> creating https://github.com/notmuch and splitting the contrib/ and
> binding/ into their own repository (conserving all their history).
>
> @owners and devs, if you'd like to explore the Github option more I'd be
> happy to grant you admin rights of the notmuch Github organisation.
>
> Thanks,
>
> Wael
>
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Github?

[Wael Nasreddine]

Hello everyone,

Thank you so much for creating Notmuch, I am coming from sup and I was
looking for a more stable alternative and I think I found what I am looking
for :)

I was a bit disappointed that the project is not living (or at least
mirrored) to Github, it would have made my search much easier. Any thoughts
on moving to Github? I took the liberty of making the first move by
creating https://github.com/notmuch and splitting the contrib/ and binding/
into their own repository (conserving all their history).

@owners and devs, if you'd like to explore the Github option more I'd be
happy to grant you admin rights of the notmuch Github organisation.

Thanks,

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

Linux-only fdatasync() in 3c13bc

[David Bremner]

Tomi Ollila  writes:

> On Wed, May 07 2014, Kushal Kumaran  
> wrote:
>
>> X?c?  writes:
>>
>>> Also, commit 3c13bc introduced a call to fdatasync() which is not
>>> available on FreeBSD, and probably not either on MacOS at least.
>>>
>>
>> fdatasync is POSIX:
>> http://pubs.opengroup.org/onlinepubs/009695399/functions/fdatasync.html
>
> No wonder it is problematic, then >;)
>

I seem to recall Austin saying on IRC that this usage was guaranteed to
call fsync anyway. Comments Austin?

d

folder and path completely broken in HEAD?

[Mark Walters]

> The trick here is that it's easy to miss people who are happy with
> current functionality. Adding functionality to address newly-identified
> use cases makes a lot of sense. But removing functionality runs the risk
> of only discovering that people were relying on it after the fact,
> (Which seems to have happened here).

Yes indeed. I think one thing that I, at least, hadn't realised is that
people have lots of strange mail layouts often to work around problems
in mail agents (notmuch or others) or filesystem limitations etc.

>>> The idea of path: is that it's the exact filesystem directory, relative
>>> from the maildir root, with an rsync like ** syntax for recursive
>>> matching.
>
> This definition of "path:" seems good. It covers a lot of cases that the
> original "folder:" did not and allows precise, predictable control.
>
>>> Turns out people want folder: to hide maildir implementation
>>> details like cur and new.
>
> Which is something that "folder:" always did.
>
>>> These are not compatible, or you need to add a syntax that's not easy
>>> or discoverable.
>
> OK. So I won't argue that we don't need two different syntaxes here. But
> I will continue to discuss a use case that was addressed before and is
> no longer.
>
>> I think many of us would agree, but there were users who wanted to
>> distinguish new and cur, and in at least one case, the toplevel as
>> well.
>
> So now, "path:" allows for that, right?
>
> My concern is not so much that "path:" was added to address new things,
> but more than "folder:" was modified in a way that dropped useful
> functionality, (beyond just fixing bugs in "folder:" such as the
> accidental support of stemming).

One possibly perverse remark: it wouldn't surprise me if someone
actually used the stemming. I have used folders called old older and
oldest and that probably can be excluded by stemming.

All I am really saying is that any change we made was going to break
some people's setups.

>> I think it is unfortunate that we need two variants, but I think they do
>> do different things.
>
> I'll accept that.
>
> But, while I have heard a good definition of "path:", (see above), I
> haven't heard a good one for "folder:" yet. Can you provide that?

I think folder:foo/bar means "In the maildir exactly foo/bar"

>> Also, I think any single user will find one matches their setup and
>> use that one essentially exclusively:
>
> The current discussion is evidence against that. We have a user of
> folder: that can no longer get at the desired functionality, (that used
> to exist).

Sorry I wasn't trying to suggest that the current setup does everything
people want (clearly not!): just answering your question about the
differences being confusing. since each user will probably only use one
of them they probably become accustomed to its use.

Indeed, I think of the choice as being analogous to allowing the user to
choose which path scheme they like (so sort of like a customisation):
maildir folder based or filesystem path based.

>> Indeed, it may be that a third option of roughly a maildir++: search term
>> might solve David's use case.
>
> Or just making "folder:" index each term of a filesytem path like it
> used to do. And if that doesn't give sufficient control to some users,
> then "path:" is available.

We could do this. It might break things for user who are using the new
syntax  Maybe we could make an initial / match the root of the
maildir store. But I think some people will dislike any of the options.

>
> I've already lost what I would have preferred, (a single syntax for all
> use cases---which was lost not to a design problem, but simply the
> implementation difficulty of requiring a custom query parser). I really
> would not like to see things continue down to have a *third* syntax.

So this third syntax would fit with my view of it being a customisation
like thing.

Best wishes

Mark

[Patch v3 0/3] emacs: show: redesign unread/read logic

[Mark Walters]

On Wed, 07 May 2014, David Edmondson  wrote:
> On Tue, Mar 25 2014, Mark Walters wrote:
>> The third patch adds my attempt at a plausible logic. I find it works
>> very well: it usually does both what I expect and what I want.
>
> Whilst I think that the patch is well done, I don't like the resulting
> behaviour. That is a personal preference, of course. At the moment it
> doesn't seem that there is a way to accept this patch and (optionally)
> retain the existing behaviour. Do you have any thoughts on how we might
> achieve that?

Thanks for looking and for the feedback. I should emphasise to everyone
that I would like all feedback whether positive or negative!

> I don't have a strong preference for the default behaviour, though I
> suspect that something closer to the current behaviour (where a message
> is marked seen when it becomes the current message[1]) would better
> match user expectation (but this is an opinion, not something founded in
> fact).

Just for the record I will detail what happens currently and then I have
a couple questions about your suggestion.

A message is marked read if:

1) if you navigate to a message using n/p (next/prev open message) 

2) if you navigate to it using N/P (next/prev message) regardless of
whether the message is open or closed.

3) if you go to it using n.s.next-matching-message (not bound by
default) whether message is open or closed.

4) when you enter a buffer and notmuch goes to the first open message.

but not marked read in cases like:

1) opening a message

2) viewing or entering a message using other notmuch navigation such as
notmuch-show-advance and friends (bound to space)

3) viewing or entering a message using arrow keys, page-up page-down,
ctrl-v mouse clicks etc

Personally, I think marking a closed message read is a bug, and not
marking it read when opening it is too (at least in many cases).  The
other problem with the current approach (in my view) is that if you try
to use the navigation commands non-interactively then messages end up
being marked read, even if they are never displayed to the user. Linking
into the post-command-hook means that this should "just work".

Questions:  What does it mean for a message to be the current message?
Is it just point being in the message? Would you be happy with a message
being marked read when point entered the message? That could be done
from the post-command-hook infrastructure to fix some of the problems
mentioned above.

I think that is likely that people will disagree on how they want this
to work so I would like to try and make it customisable so I would
definitely be interested to see if I can get the behaviour you would
like from this infrastructure (or something similar).

Best wishes

Mark

[RFC] [PATCH] emacs/notmuch-mua: Generate improved cited text for replies

[David Edmondson]

Use the message display code to generate message text to cite in
replies.
---

This breaks the tests, which know about the details of how the reply
buffer looks in emacs. I will fix that of course, if this approach is
considered acceptable.

The original implementation took a simplistic view of how a reply to a
complex message could be generated (essentially it tried to reduce it
to a flat list of text parts). Given that we already have code to
display more complex message structure, it seems obvious to use it.

 emacs/notmuch-mua.el | 34 --
 1 file changed, 4 insertions(+), 30 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 95e4a4d..a8cff3d 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -28,7 +28,7 @@

 (eval-when-compile (require 'cl))

-(declare-function notmuch-show-insert-bodypart "notmuch-show" (msg part depth 
&optional hide))
+(declare-function notmuch-show-insert-body "notmuch-show" (msg body depth))

 ;;

@@ -123,31 +123,6 @@ list."
else if (notmuch-match-content-type (plist-get part :content-type) 
"multipart/*")
  do (notmuch-mua-reply-crypto (plist-get part :content

-(defun notmuch-mua-get-quotable-parts (parts)
-  (loop for part in parts
-   if (notmuch-match-content-type (plist-get part :content-type) 
"multipart/alternative")
- collect (let* ((subparts (plist-get part :content))
-   (types (mapcar (lambda (part) (plist-get part 
:content-type)) subparts))
-   (chosen-type (car (notmuch-multipart/alternative-choose 
types
-  (loop for part in (reverse subparts)
-if (notmuch-match-content-type (plist-get part 
:content-type) chosen-type)
-return part))
-   else if (notmuch-match-content-type (plist-get part :content-type) 
"multipart/*")
- append (notmuch-mua-get-quotable-parts (plist-get part :content))
-   else if (notmuch-match-content-type (plist-get part :content-type) 
"text/*")
- collect part))
-
-(defun notmuch-mua-insert-quotable-part (message part)
-  ;; We don't want text properties leaking from the show renderer into
-  ;; the reply so we use a temp buffer. Also we don't want hooks, such
-  ;; as notmuch-wash-*, to be run on the quotable part so we set
-  ;; notmuch-show-insert-text/plain-hook to nil.
-  (insert (with-temp-buffer
-   (let ((notmuch-show-insert-text/plain-hook nil))
- ;; Show the part but do not add buttons.
- (notmuch-show-insert-bodypart message part 0 'no-buttons))
-   (buffer-substring-no-properties (point-min) (point-max)
-
 ;; There is a bug in emacs 23's message.el that results in a newline
 ;; not being inserted after the References header, so the next header
 ;; is concatenated to the end of it. This function fixes the problem,
@@ -225,10 +200,9 @@ list."
(insert "From: " from "\n")
(insert "Date: " date "\n\n")

-   ;; Get the parts of the original message that should be quoted; this 
includes
-   ;; all the text parts, except the non-preferred ones in a 
multipart/alternative.
-   (let ((quotable-parts (notmuch-mua-get-quotable-parts (plist-get 
original :body
- (mapc (apply-partially 'notmuch-mua-insert-quotable-part original) 
quotable-parts))
+   (insert (with-temp-buffer
+ (notmuch-show-insert-body original (plist-get original :body) 
0)
+ (buffer-substring-no-properties (point-min) (point-max

(set-mark (point))
(goto-char start)
-- 
2.0.0.rc0

Linux-only fdatasync() in 3c13bc

[Kushal Kumaran]

X?c?  writes:

> Also, commit 3c13bc introduced a call to fdatasync() which is not
> available on FreeBSD, and probably not either on MacOS at least.
>

fdatasync is POSIX:
http://pubs.opengroup.org/onlinepubs/009695399/functions/fdatasync.html

-- 
regards,
kushal
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140507/b4778e27/attachment-0001.pgp>

[PATCH v4 2/3] emacs: `notmuch-show-buttonize-links' only `notmuch-show's a message if it exists

[David Edmondson]

[ Trimmed to/cc list. ]

On Sun, Jan 22 2012, Pieter Praet wrote:
> * emacs/notmuch-show.el (notmuch-show-found-target-p): new predicate function
>   that uses notmuch(1) 'count' to see if a query turns up any results.
>
> * emacs/notmuch-show.el (notmuch-show-if-found): new function that only shows
>   a message/thread if present in the database and otherwise returns an error.
>
> * emacs/notmuch-show.el (notmuch-show-buttonize-links): some deduplication,
>   and use new function `notmuch-show-if-found' instead of `notmuch-show'
>   to prevent showing a blank screen for Message-Id's which aren't present
>   in the database.

Mark provided some feedback about this (relating to exclusions), but
more generally there is a problem that `M-x notmuch-show id:doesntexist'
will result in an error ("notmuch-show-message-top: Beginning of
buffer"). That seems like a bug that should be fixed.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 310 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140507/32156654/attachment.pgp>

[Patch v3 0/3] emacs: show: redesign unread/read logic

[David Edmondson]

On Tue, Mar 25 2014, Mark Walters wrote:
> The third patch adds my attempt at a plausible logic. I find it works
> very well: it usually does both what I expect and what I want.

Whilst I think that the patch is well done, I don't like the resulting
behaviour. That is a personal preference, of course. At the moment it
doesn't seem that there is a way to accept this patch and (optionally)
retain the existing behaviour. Do you have any thoughts on how we might
achieve that?

I don't have a strong preference for the default behaviour, though I
suspect that something closer to the current behaviour (where a message
is marked seen when it becomes the current message[1]) would better
match user expectation (but this is an opinion, not something founded in
fact).

Footnotes: 
[1]  Modulo bugs.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 310 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140507/649d5608/attachment.pgp>

Linux-only fdatasync() in 3c13bc

[Tomi Ollila]

On Wed, May 07 2014, Kushal Kumaran  wrote:

> X?c?  writes:
>
>> Also, commit 3c13bc introduced a call to fdatasync() which is not
>> available on FreeBSD, and probably not either on MacOS at least.
>>
>
> fdatasync is POSIX:
> http://pubs.opengroup.org/onlinepubs/009695399/functions/fdatasync.html

No wonder it is problematic, then >;)

> -- 
> regards,
> kushal

Tomi

[PATCH] devel: make man-to-mdwn.pl to work with generated manual pages

[Tomi Ollila]

The new manual pages converted from rst using sphinx or rst2man
has somewhat different syntax. man-to-mdwn.pl is now adjusted
to produce even better output from this syntax (a bug ot two
was fixed along the adjustents done).
This tool still produces better results than just using the
html pages generated using sphinx / rst2html. For example those
tools don't create inter-page hyperlinks -- and the preformatted
pages written by man-to-mdwn.pl just works well with manual page
content.
---

With the notmuch-wiki commit b2e421fc7 (Thu May 8 00:12:05 2014 +0300)
the manpages* content is generated by this tool on scientific linux 6.2
machine and no manual post-editing was done.

 devel/man-to-mdwn.pl | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/devel/man-to-mdwn.pl b/devel/man-to-mdwn.pl
index 4b59bd663698..64e6202ae970 100755
--- a/devel/man-to-mdwn.pl
+++ b/devel/man-to-mdwn.pl
@@ -6,18 +6,18 @@
 # This program is used to generate mdwn-formatted notmuch manual pages
 # for notmuch wiki. Example run:
 #
-# $ ./devel/man-to-mdwn.pl man ../notmuch-wiki
+# $ ./devel/man-to-mdwn.pl doc/_build/man ../notmuch-wiki
 #
 # In case taken into more generic use, modify these comments and examples.
 
-use 5.8.1;
+use 5.10.1;
 use strict;
 use warnings;
 
 unless (@ARGV == 2) {
 warn "\n$0  \n\n";
 # Remove/edit this comment if this script is taken into generic use.
-warn "Example: ./devel/man-to-mdwn.pl man ../notmuch-wiki\n\n";
+warn "Example: ./devel/man-to-mdwn.pl doc/_build/man ../notmuch-wiki\n\n";
 exit 1;
 }
 
@@ -48,11 +48,6 @@ while ()
 }
 close P;
 
-#undef $ENV{'GROFF_NO_SGR'};
-#delete $ENV{'GROFF_NO_SGR'};
-$ENV{'GROFF_NO_SGR'} = '1';
-$ENV{'TERM'} = 'vt100'; # does this matter ?
-
 my %htmlqh = qw/& &   < <   > >   ' '   " "/;
 # do html quotation to $_[0] (which is an alias to the given arg)
 sub htmlquote($)
@@ -70,8 +65,10 @@ while (my ($k, $v) = each %fhash)
 #next if -l $v; # skip symlinks here. -- not... references there may be.
 
 my @lines;
-#open I, '-|', qw/groff -man -T utf8/, $v;
-open I, '-|', qw/groff -man -T latin1/, $v; # this and GROFF_NO_SGR='1'
+open I, '-|', qw/env -i/, "PATH=$ENV{PATH}",
+   qw/GROFF_NO_SGR=1 TERM=vt100 LANG=en_US.utf8 LC_ALL=en_US.utf8/,
+   qw/man/, $v;
+   #qw/man -t -E utf8 -T utf8/, $v; # <- needs newer man...
 
 my ($emptyline, $pre, $hl) = (0, 0, 'h1');
 while () {
@@ -79,13 +76,15 @@ while (my ($k, $v) = each %fhash)
$emptyline = 1;
next;
}
-   s/(?<=\S)\s{8,}.*//; # $hl = 'h1' if s/(?<=\S)\s{8,}.*//;
-   htmlquote $_;
+   # keep only leftmost in lines like 'NOTMUCH(1)   notmuch   NOTMUCH(1)'
+   s/\S\K\s{8,}\S.+\s{8,}\S.*//; # $hl = 'h1' if s/(?<=\S)\s{8,}.*//;
s/[_&]\010&/&/g;
-   s/((?:_\010[^_])+)/$1<\/u>/g;
+   s/((?:_\010[^_])+)/\001u\002$1\001\/u\002/g;
s/_\010(.)/$1/g;
-   s/((?:.\010.)+)/$1<\/b>/g;
+   s/((?:.\010.)+)/\001b\002$1\001\/b\002/g;
s/.\010(.)/$1/g;
+   htmlquote $_;
+   s/\001//g;
 
if (/^\S/) {
$pre = 0, push @lines, "\n" if $pre;
@@ -116,7 +115,7 @@ while (my ($k, $v) = each %fhash)
 my $pe = '';
 foreach (@lines) {
if ($pe) {
-   if (s/^(\s+)([^<]+)<\/b>\((\d+)\)//) {
+   if (s/^(\s+)([^<]+)\((\d+)\)<\/b>//) {
my $link = maymakelink "$pe-$2-$3";
$link = maymakelink "$pe$2-$3" unless $link;
if ($link) {
@@ -132,7 +131,7 @@ while (my ($k, $v) = each %fhash)
}
$pe = '';
}
-   s/([^<]+)<\/b>\((\d+)\)/mayconvert($1, $2)/ge;
+   s/([^<]+)\((\d+)\)<\/b>/mayconvert($1, $2)/ge;
$pe = $1 if s/([^<]+)-<\/b>\s*$//;
print $_;
 }
@@ -169,7 +168,7 @@ foreach (sort srt values %fhash)
 open I, '<', $in or die $!;
 my $s;
 while () {
-   if (/^\s*[.]TH\s+\S+\s+(\S+)/) {
+   if (/^\s*[.]TH\s+\S+\s+"?(\S+?)"?\s/) {
$s = $1;
last;
}
-- 
1.8.0

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

GMAIL tag sync arriving in "next" branch in Offlineimap

[Jani Nikula]

On Wed, 07 May 2014, Rainer M Krug  wrote:
> Recently, gmail tag sync was discussed here, and it seems something is
> happening in Offlineimap: patches implementing synching of gmail tags to 
> X-Labels have been applied in the "next" branch and announced on the
> Offline mailing list. 

https://github.com/OfflineIMAP/offlineimap/commit/0e4afa913253c43409e6a32a6b6e11e8b03ed3d9

"""
This is an example of a setup where GMail gets synced with a local
Maildir. It also keeps track of GMail labels, that get embedded into the
messages under the header X-Keywords (or whatever labelsheader is set
to), and syncs them back and forth the same way as flags.

The first time it runs on a large repository may take some time as the
labels are read / embedded on every message. Afterwards local label
changes are detected using modification times (much faster):
"""

Modification of message files as labels change? Ugh.

I guess notmuch could read a user configurable header and apply the tags
there, but notmuch modifying the message files is probably not going to
happen.


BR,
Jani.

Improving spam-tagging keybinding function to act on region in emacs

[Olivier Berger]

Hi.

Mark Walters  writes:

> Hello
>
> As this section was rather outdated I have updated to modern notmuch. (In
> fact the lisp snippets should work back to at least 0.13)
>
> On Tue, 06 May 2014, Olivier Berger  
> wrote:
>> Hi.
>>
>> I've tried tu use the tips indicated at
>> http://notmuchmail.org/emacstips/#index8h2 so as to add a keybinding to
>> tag spam messages, and wonder if there's a possibility to make it apply
>> on selected regions, like what notmuch-search-archive-thread does.
>
> I have added a snippet showing how to do this (and noted that is not
> possible in notmuch-tree as we don't have a tag region option there).
>

Thanks. This works exactly I like it :-)

>> Btw, I think that the current examples could be improved by adding a 
>> (next-line)
>> at the end, like :
>> (define-key notmuch-search-mode-map "S"
>> (lambda ()
>>   "mark messages in thread as spam"
>>   (interactive)
>>   (notmuch-search-tag '("+spam" "-inbox"))
>>   (next-line)))
>
> I have left this as it is as this works in search mode, but not show
> mode and I didn't want to have too many examples. Obviously feel free to
> edit the wiki if you like!
>

Note that I'm now using the following :
  (define-key notmuch-search-mode-map "S"
(lambda (&optional beg end)
  "mark messages in thread as spam"
  (interactive (notmuch-search-interactive-region))
  (notmuch-search-tag '("+spam" "-inbox") beg end)
  (if (eq beg end) (notmuch-search-next-thread

This offers the possibility to jump to the next line when tagging
individual lines, and not do so when acting on a region.

Btw, such a difference in behaviour may be a tiny, but still nice
improvement on the code of notmuch-search-archive-thread too.

I haven't touched the wiki, as I'm not sure this is the best way to
write it and everyone would be interested.

Hope this helps.

Best regards,

-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Linux-only fdatasync() in 3c13bc

[Austin Clements]

Quoth David Bremner on May 07 at 10:17 pm:
> Tomi Ollila  writes:
> 
> > On Wed, May 07 2014, Kushal Kumaran  
> > wrote:
> >
> >> X?c?  writes:
> >>
> >>> Also, commit 3c13bc introduced a call to fdatasync() which is not
> >>> available on FreeBSD, and probably not either on MacOS at least.
> >>>
> >>
> >> fdatasync is POSIX:
> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/fdatasync.html
> >
> > No wonder it is problematic, then >;)
> >
> 
> I seem to recall Austin saying on IRC that this usage was guaranteed to
> call fsync anyway. Comments Austin?

Yes, since the size of the file will have definitely changed, the
metadata will have to be flushed anyway, so using fdatasync here has
no advantage over using fsync.

[PATCH 1/1] devel: news2wiki to recognize yyyy-mm-dd or UNRELEASED as release date

[Tomi Ollila]

The -mm-dd (actually \d\d\d\d-\d\d-\d\d) for a bit more restrictive
(and self-documentative) than the \w\w\w\w-... that used to be there and
UNRELEASED so that developers can test the latest NEWS converted to mdwn
format before submitting NEWS patches.
---
 devel/news2wiki.pl | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/devel/news2wiki.pl b/devel/news2wiki.pl
index 8066ba7..d966bab 100755
--- a/devel/news2wiki.pl
+++ b/devel/news2wiki.pl
@@ -32,8 +32,7 @@ while ()
 {
 warn "$ARGV[0]:$.: tab(s) in line!\n" if /\t/;
 warn "$ARGV[0]:$.: trailing whitespace\n" if /\s\s$/;
-# The date part in regex recognizes wip version dates like: (201x-xx-xx).
-if (/^Notmuch\s+(\S+)\s+\((\w\w\w\w-\w\w-\w\w)\)\s*$/) {
+if (/^Notmuch\s+(\S+)\s+\((\d\d\d\d-\d\d-\d\d|UNRELEASED)\)\s*$/) {
# open O... autocloses previously opened file.
open O, '>', "$ARGV[1]/release-$1.mdwn" or die $!;
print "+ release-$1.mdwn...\n";
-- 
1.9.0

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

Re: folder and path completely broken in HEAD?

[Mark Walters]

> The trick here is that it's easy to miss people who are happy with
> current functionality. Adding functionality to address newly-identified
> use cases makes a lot of sense. But removing functionality runs the risk
> of only discovering that people were relying on it after the fact,
> (Which seems to have happened here).

Yes indeed. I think one thing that I, at least, hadn't realised is that
people have lots of strange mail layouts often to work around problems
in mail agents (notmuch or others) or filesystem limitations etc.

>>> The idea of path: is that it's the exact filesystem directory, relative
>>> from the maildir root, with an rsync like ** syntax for recursive
>>> matching.
>
> This definition of "path:" seems good. It covers a lot of cases that the
> original "folder:" did not and allows precise, predictable control.
>
>>> Turns out people want folder: to hide maildir implementation
>>> details like cur and new.
>
> Which is something that "folder:" always did.
>
>>> These are not compatible, or you need to add a syntax that's not easy
>>> or discoverable.
>
> OK. So I won't argue that we don't need two different syntaxes here. But
> I will continue to discuss a use case that was addressed before and is
> no longer.
>
>> I think many of us would agree, but there were users who wanted to
>> distinguish new and cur, and in at least one case, the toplevel as
>> well.
>
> So now, "path:" allows for that, right?
>
> My concern is not so much that "path:" was added to address new things,
> but more than "folder:" was modified in a way that dropped useful
> functionality, (beyond just fixing bugs in "folder:" such as the
> accidental support of stemming).

One possibly perverse remark: it wouldn't surprise me if someone
actually used the stemming. I have used folders called old older and
oldest and that probably can be excluded by stemming.

All I am really saying is that any change we made was going to break
some people's setups.

>> I think it is unfortunate that we need two variants, but I think they do
>> do different things.
>
> I'll accept that.
>
> But, while I have heard a good definition of "path:", (see above), I
> haven't heard a good one for "folder:" yet. Can you provide that?

I think folder:foo/bar means "In the maildir exactly foo/bar"

>> Also, I think any single user will find one matches their setup and
>> use that one essentially exclusively:
>
> The current discussion is evidence against that. We have a user of
> folder: that can no longer get at the desired functionality, (that used
> to exist).

Sorry I wasn't trying to suggest that the current setup does everything
people want (clearly not!): just answering your question about the
differences being confusing. since each user will probably only use one
of them they probably become accustomed to its use.

Indeed, I think of the choice as being analogous to allowing the user to
choose which path scheme they like (so sort of like a customisation):
maildir folder based or filesystem path based.

>> Indeed, it may be that a third option of roughly a maildir++: search term
>> might solve David's use case.
>
> Or just making "folder:" index each term of a filesytem path like it
> used to do. And if that doesn't give sufficient control to some users,
> then "path:" is available.

We could do this. It might break things for user who are using the new
syntax  Maybe we could make an initial / match the root of the
maildir store. But I think some people will dislike any of the options.

>
> I've already lost what I would have preferred, (a single syntax for all
> use cases---which was lost not to a design problem, but simply the
> implementation difficulty of requiring a custom query parser). I really
> would not like to see things continue down to have a *third* syntax.

So this third syntax would fit with my view of it being a customisation
like thing.

Best wishes

Mark

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

[PATCH v2] emacs: Add support for saved search accelerators

[David Edmondson]

Extended the saved search definition to allow the inclusion of an
accelerator key for the search. Bind 'j' in the common mode map as a
leader for such accelerator keys.
---
 emacs/notmuch-hello.el |  5 -
 emacs/notmuch-lib.el   | 46 ++
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 3de5238..64d5aa1 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -85,6 +85,7 @@ searches so they still work in customize."
(group :format "%v" :inline t (const :format "  Query: " 
:query) (string :format "%v")))
  (checklist :inline t
 :format "%v"
+(group :format "%v" :inline t (const :format "Key: " 
:key) (key-sequence :format "%v"))
 (group :format "%v" :inline t (const :format "Count-Query: 
" :count-query) (string :format "%v"))
 (group :format "%v" :inline t (const :format "" 
:sort-order)
(choice :tag " Sort Order"
@@ -101,6 +102,7 @@ a plist. Supported properties are

   :nameName of the search (required).
   :query   Search to run (required).
+  :key Optional accelerator key.
   :count-query Optional extra query to generate the count
shown. If not present then the :query property
is used.
@@ -551,7 +553,8 @@ with `notmuch-hello-query-counts'."
(when elem
  (if (> column-indent 0)
  (widget-insert (make-string column-indent ? )))
- (let* ((name (plist-get elem :name))
+ (let* ((key (plist-get elem :key))
+(name (plist-get elem :name))
 (query (plist-get elem :query))
 (oldest-first (case (plist-get elem :sort-order)
 (newest-first nil)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index 2941da3..f8c5f96 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -25,6 +25,10 @@
 (require 'mm-decode)
 (require 'cl)

+(declare-function notmuch-search "notmuch" (&optional query oldest-first 
target-thread target-line continuation))
+(declare-function notmuch-saved-search-get "notmuch-hello" (saved-search 
field))
+(defvar notmuch-saved-searches) ;; In `notmuch-hello.el'.
+
 (defvar notmuch-command "notmuch"
   "Command to run the notmuch binary.")

@@ -130,6 +134,7 @@ For example, if you wanted to remove an \"inbox\" tag and 
add an
 (define-key map "m" 'notmuch-mua-new-mail)
 (define-key map "=" 'notmuch-refresh-this-buffer)
 (define-key map "G" 'notmuch-poll-and-refresh-this-buffer)
+(define-key map "j" 'notmuch-jump)
 map)
   "Keymap shared by all notmuch modes.")

@@ -845,6 +850,47 @@ status."
 (defvar notmuch-show-process-crypto nil)
 (make-variable-buffer-local 'notmuch-show-process-crypto)

+;; Jump key support:
+
+(defvar notmuch-jump-search nil)
+(defun notmuch-jump-map ()
+  (let ((map (make-sparse-keymap))
+   help)
+(set-keymap-parent map minibuffer-local-map)
+(suppress-keymap map)
+(dolist (saved-search notmuch-saved-searches)
+  (let ((key (notmuch-saved-search-get saved-search :key)))
+   (when key
+ (define-key map key `(lambda ()
+(interactive)
+(setq notmuch-jump-search ',saved-search)
+(exit-minibuffer)))
+ (push (format "%s: %s"
+   (propertize key 'face 'minibuffer-prompt)
+   (notmuch-saved-search-get saved-search :name))
+   help
+;; Hitting ? displays a quick hint of the accelerators.
+(define-key map "?" `(lambda ()
+  (interactive)
+  (message "%s"
+   (mapconcat #'identity
+  ;; Reverse the list so
+  ;; that elements appear
+  ;; in the same order as
+  ;; `notmuch-saved-searches'.
+  (reverse ',help)
+  " "
+map))
+
+(defun notmuch-jump ()
+  "Read a saved search accelerator key and perform the search."
+  (interactive)
+  (setq notmuch-jump-search nil)
+  (read-from-minibuffer "Jump to saved search: " nil (notmuch-jump-map))
+  (when notmuch-jump-search
+(notmuch-search (notmuch-saved-search-get notmuch-jump-search :query)
+   (notmuch-saved-search-get notmuch-jump-search 
:oldest-first
+
 (provide 'notmuch-lib)

 ;; Local Variables:
-- 
2.0.0.rc0

[PATCH v2] emacs: Add support for saved search accelerator keys

[David Edmondson]

emacs: Add support for saved search accelerator keys

This arose out a conversation in #notmuch and Mark's patch to extend
the saved search custom specification based on requirements for an
external package (Austin's notmuch-go.el).

v2:
- Comments from Mark Walters:
  - Use `notmuch-saved-search-get'.
  - Use key-sequence rather than string in the custom definition.
  - Add a ? binding to display the accelerators.
  - Use the minibuffer-local-map as parent for the new keymap.
  - Fix external declarations.
  - Remove the display of the accelerators in notmuch-hello.


David Edmondson (1):
  emacs: Add support for saved search accelerators

 emacs/notmuch-hello.el |  5 -
 emacs/notmuch-lib.el   | 46 ++
 2 files changed, 50 insertions(+), 1 deletion(-)

-- 
2.0.0.rc0

Re: [Patch v3 0/3] emacs: show: redesign unread/read logic

[Mark Walters]

On Wed, 07 May 2014, David Edmondson  wrote:
> On Tue, Mar 25 2014, Mark Walters wrote:
>> The third patch adds my attempt at a plausible logic. I find it works
>> very well: it usually does both what I expect and what I want.
>
> Whilst I think that the patch is well done, I don't like the resulting
> behaviour. That is a personal preference, of course. At the moment it
> doesn't seem that there is a way to accept this patch and (optionally)
> retain the existing behaviour. Do you have any thoughts on how we might
> achieve that?

Thanks for looking and for the feedback. I should emphasise to everyone
that I would like all feedback whether positive or negative!

> I don't have a strong preference for the default behaviour, though I
> suspect that something closer to the current behaviour (where a message
> is marked seen when it becomes the current message[1]) would better
> match user expectation (but this is an opinion, not something founded in
> fact).

Just for the record I will detail what happens currently and then I have
a couple questions about your suggestion.

A message is marked read if:

1) if you navigate to a message using n/p (next/prev open message) 

2) if you navigate to it using N/P (next/prev message) regardless of
whether the message is open or closed.

3) if you go to it using n.s.next-matching-message (not bound by
default) whether message is open or closed.

4) when you enter a buffer and notmuch goes to the first open message.

but not marked read in cases like:

1) opening a message

2) viewing or entering a message using other notmuch navigation such as
notmuch-show-advance and friends (bound to space)

3) viewing or entering a message using arrow keys, page-up page-down,
ctrl-v mouse clicks etc

Personally, I think marking a closed message read is a bug, and not
marking it read when opening it is too (at least in many cases).  The
other problem with the current approach (in my view) is that if you try
to use the navigation commands non-interactively then messages end up
being marked read, even if they are never displayed to the user. Linking
into the post-command-hook means that this should "just work".

Questions:  What does it mean for a message to be the current message?
Is it just point being in the message? Would you be happy with a message
being marked read when point entered the message? That could be done
from the post-command-hook infrastructure to fix some of the problems
mentioned above.

I think that is likely that people will disagree on how they want this
to work so I would like to try and make it customisable so I would
definitely be interested to see if I can get the behaviour you would
like from this infrastructure (or something similar).

Best wishes

Mark




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

Re: Linux-only fdatasync() in 3c13bc

[Austin Clements]

Quoth David Bremner on May 07 at 10:17 pm:
> Tomi Ollila  writes:
> 
> > On Wed, May 07 2014, Kushal Kumaran  
> > wrote:
> >
> >> Xīcò  writes:
> >>
> >>> Also, commit 3c13bc introduced a call to fdatasync() which is not
> >>> available on FreeBSD, and probably not either on MacOS at least.
> >>>
> >>
> >> fdatasync is POSIX:
> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/fdatasync.html
> >
> > No wonder it is problematic, then >;)
> >
> 
> I seem to recall Austin saying on IRC that this usage was guaranteed to
> call fsync anyway. Comments Austin?

Yes, since the size of the file will have definitely changed, the
metadata will have to be flushed anyway, so using fdatasync here has
no advantage over using fsync.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[RFC] [PATCH] emacs/notmuch-mua: Generate improved cited text for replies

[David Edmondson]

Use the message display code to generate message text to cite in
replies.
---

This breaks the tests, which know about the details of how the reply
buffer looks in emacs. I will fix that of course, if this approach is
considered acceptable.

The original implementation took a simplistic view of how a reply to a
complex message could be generated (essentially it tried to reduce it
to a flat list of text parts). Given that we already have code to
display more complex message structure, it seems obvious to use it.

 emacs/notmuch-mua.el | 34 --
 1 file changed, 4 insertions(+), 30 deletions(-)

diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 95e4a4d..a8cff3d 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -28,7 +28,7 @@
 
 (eval-when-compile (require 'cl))
 
-(declare-function notmuch-show-insert-bodypart "notmuch-show" (msg part depth 
&optional hide))
+(declare-function notmuch-show-insert-body "notmuch-show" (msg body depth))
 
 ;;
 
@@ -123,31 +123,6 @@ list."
else if (notmuch-match-content-type (plist-get part :content-type) 
"multipart/*")
  do (notmuch-mua-reply-crypto (plist-get part :content
 
-(defun notmuch-mua-get-quotable-parts (parts)
-  (loop for part in parts
-   if (notmuch-match-content-type (plist-get part :content-type) 
"multipart/alternative")
- collect (let* ((subparts (plist-get part :content))
-   (types (mapcar (lambda (part) (plist-get part 
:content-type)) subparts))
-   (chosen-type (car (notmuch-multipart/alternative-choose 
types
-  (loop for part in (reverse subparts)
-if (notmuch-match-content-type (plist-get part 
:content-type) chosen-type)
-return part))
-   else if (notmuch-match-content-type (plist-get part :content-type) 
"multipart/*")
- append (notmuch-mua-get-quotable-parts (plist-get part :content))
-   else if (notmuch-match-content-type (plist-get part :content-type) 
"text/*")
- collect part))
-
-(defun notmuch-mua-insert-quotable-part (message part)
-  ;; We don't want text properties leaking from the show renderer into
-  ;; the reply so we use a temp buffer. Also we don't want hooks, such
-  ;; as notmuch-wash-*, to be run on the quotable part so we set
-  ;; notmuch-show-insert-text/plain-hook to nil.
-  (insert (with-temp-buffer
-   (let ((notmuch-show-insert-text/plain-hook nil))
- ;; Show the part but do not add buttons.
- (notmuch-show-insert-bodypart message part 0 'no-buttons))
-   (buffer-substring-no-properties (point-min) (point-max)
-
 ;; There is a bug in emacs 23's message.el that results in a newline
 ;; not being inserted after the References header, so the next header
 ;; is concatenated to the end of it. This function fixes the problem,
@@ -225,10 +200,9 @@ list."
(insert "From: " from "\n")
(insert "Date: " date "\n\n")
 
-   ;; Get the parts of the original message that should be quoted; this 
includes
-   ;; all the text parts, except the non-preferred ones in a 
multipart/alternative.
-   (let ((quotable-parts (notmuch-mua-get-quotable-parts (plist-get 
original :body
- (mapc (apply-partially 'notmuch-mua-insert-quotable-part original) 
quotable-parts))
+   (insert (with-temp-buffer
+ (notmuch-show-insert-body original (plist-get original :body) 
0)
+ (buffer-substring-no-properties (point-min) (point-max
 
(set-mark (point))
(goto-char start)
-- 
2.0.0.rc0

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

Log of tagging actions

[Sebastian Fischmeister]

Hi,

The amazing thing about the notmuch emacs interface is that with just a
couple of keystrokes you can quickly manipulate a lot of emails and thus
be very efficient. The big disadvantage is that with just a couple of
keystrokes you can manipulate a lot of emails and thus quickly
completely mess up your emails. Just think about the scenario of a cat
wandering across your keyboard.

Is there a possibility to log all tagging actions done in notmuch?
Something like:

, ,  

It would be helpful for restoring things in case something went wrong,
and it could be the start of an undo function.

  Sebastian

GMAIL tag sync arriving in "next" branch in Offlineimap

[Rainer M Krug]

Recently, gmail tag sync was discussed here, and it seems something is
happening in Offlineimap: patches implementing synching of gmail tags to 
X-Labels have been applied in the "next" branch and announced on the
Offline mailing list. 

Cheers,

Rainer
-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  Rainer at krugs.de

Skype:  RMkrug

PGP: 0x0F52F982
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 494 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140507/6904aedf/attachment.pgp>

Re: [PATCH v4 2/3] emacs: `notmuch-show-buttonize-links' only `notmuch-show's a message if it exists

[David Edmondson]

[ Trimmed to/cc list. ]

On Sun, Jan 22 2012, Pieter Praet wrote:
> * emacs/notmuch-show.el (notmuch-show-found-target-p): new predicate function
>   that uses notmuch(1) 'count' to see if a query turns up any results.
>
> * emacs/notmuch-show.el (notmuch-show-if-found): new function that only shows
>   a message/thread if present in the database and otherwise returns an error.
>
> * emacs/notmuch-show.el (notmuch-show-buttonize-links): some deduplication,
>   and use new function `notmuch-show-if-found' instead of `notmuch-show'
>   to prevent showing a blank screen for Message-Id's which aren't present
>   in the database.

Mark provided some feedback about this (relating to exclusions), but
more generally there is a problem that `M-x notmuch-show id:doesntexist'
will result in an error ("notmuch-show-message-top: Beginning of
buffer"). That seems like a bug that should be fixed.


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

Re: [Patch v3 0/3] emacs: show: redesign unread/read logic

[David Edmondson]

On Tue, Mar 25 2014, Mark Walters wrote:
> The third patch adds my attempt at a plausible logic. I find it works
> very well: it usually does both what I expect and what I want.

Whilst I think that the patch is well done, I don't like the resulting
behaviour. That is a personal preference, of course. At the moment it
doesn't seem that there is a way to accept this patch and (optionally)
retain the existing behaviour. Do you have any thoughts on how we might
achieve that?

I don't have a strong preference for the default behaviour, though I
suspect that something closer to the current behaviour (where a message
is marked seen when it becomes the current message[1]) would better
match user expectation (but this is an opinion, not something founded in
fact).

Footnotes: 
[1]  Modulo bugs.


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

Log of tagging actions

[Sebastian Fischmeister]

Hi,

The amazing thing about the notmuch emacs interface is that with just a
couple of keystrokes you can quickly manipulate a lot of emails and thus
be very efficient. The big disadvantage is that with just a couple of
keystrokes you can manipulate a lot of emails and thus quickly
completely mess up your emails. Just think about the scenario of a cat
wandering across your keyboard.

Is there a possibility to log all tagging actions done in notmuch?
Something like:

, ,  

It would be helpful for restoring things in case something went wrong,
and it could be the start of an undo function.

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

[PATCH] emacs: hello: allow arbitrary lisp for generating the count.

[David Edmondson]

uery
> +   (or (plist-get options :filter-count)
> +   (plist-get options :filter
> +"\n"
>  
>  (unless (= (call-process-region (point-min) (point-max) notmuch-command
>   t t nil "count" "--batch") 0)
> @@ -515,12 +519,17 @@ (defun notmuch-hello-query-counts (query-list &rest 
> options)
>   (mapcar
>(lambda (elem)
>   (let* ((elem-plist (notmuch-hello-saved-search-to-plist elem))
> +(count-query (plist-get elem-plist :count-query))
>  (search-query (plist-get elem-plist :query))
>  (filtered-query (notmuch-hello-filtered-query
>   search-query (plist-get options :filter)))
> -(message-count (prog1 (read (current-buffer))
> - (forward-line 1
> -   (when (and filtered-query (or (plist-get options 
> :show-empty-searches) (> message-count 0)))
> +(message-count (if (functionp count-query)
> +   (funcall count-query elem-plist)
> + (prog1 (read (current-buffer))
> +   (forward-line 1)
> +   (when (and filtered-query (or (plist-get options :show-empty-searches)
> + (not (integerp message-count))
> + (> message-count 0)))
>   (setq elem-plist (plist-put elem-plist :query filtered-query))
>   (plist-put elem-plist :count message-count
>query-list
> @@ -559,7 +568,9 @@ (defun notmuch-hello-insert-buttons (searches)
>(otherwise notmuch-search-oldest-first)))
>(msg-count (plist-get elem :count)))
>   (widget-insert (format "%8s "
> -(notmuch-hello-nice-number msg-count)))
> +(if (stringp msg-count)
> +msg-count
> +  (notmuch-hello-nice-number 
> msg-count
>   (widget-create 'push-button
>  :notify #'notmuch-hello-widget-search
>  :notmuch-search-terms query
> -- 
> 1.7.10.4
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 310 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140507/bc1cd05b/attachment.pgp>

Re: Linux-only fdatasync() in 3c13bc

[David Bremner]

Tomi Ollila  writes:

> On Wed, May 07 2014, Kushal Kumaran  wrote:
>
>> Xīcò  writes:
>>
>>> Also, commit 3c13bc introduced a call to fdatasync() which is not
>>> available on FreeBSD, and probably not either on MacOS at least.
>>>
>>
>> fdatasync is POSIX:
>> http://pubs.opengroup.org/onlinepubs/009695399/functions/fdatasync.html
>
> No wonder it is problematic, then >;)
>

I seem to recall Austin saying on IRC that this usage was guaranteed to
call fsync anyway. Comments Austin?

d


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

Re: Linux-only fdatasync() in 3c13bc

[Tomi Ollila]

On Wed, May 07 2014, Kushal Kumaran  wrote:

> Xīcò  writes:
>
>> Also, commit 3c13bc introduced a call to fdatasync() which is not
>> available on FreeBSD, and probably not either on MacOS at least.
>>
>
> fdatasync is POSIX:
> http://pubs.opengroup.org/onlinepubs/009695399/functions/fdatasync.html

No wonder it is problematic, then >;)

> -- 
> regards,
> kushal

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

Re: GMAIL tag sync arriving in "next" branch in Offlineimap

[Jani Nikula]

On Wed, 07 May 2014, Rainer M Krug  wrote:
> Recently, gmail tag sync was discussed here, and it seems something is
> happening in Offlineimap: patches implementing synching of gmail tags to 
> X-Labels have been applied in the "next" branch and announced on the
> Offline mailing list. 

https://github.com/OfflineIMAP/offlineimap/commit/0e4afa913253c43409e6a32a6b6e11e8b03ed3d9

"""
This is an example of a setup where GMail gets synced with a local
Maildir. It also keeps track of GMail labels, that get embedded into the
messages under the header X-Keywords (or whatever labelsheader is set
to), and syncs them back and forth the same way as flags.

The first time it runs on a large repository may take some time as the
labels are read / embedded on every message. Afterwards local label
changes are detected using modification times (much faster):
"""

Modification of message files as labels change? Ugh.

I guess notmuch could read a user configurable header and apply the tags
there, but notmuch modifying the message files is probably not going to
happen.


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

Re: Improving spam-tagging keybinding function to act on region in emacs

[Olivier Berger]

Hi.

Mark Walters  writes:

> Hello
>
> As this section was rather outdated I have updated to modern notmuch. (In
> fact the lisp snippets should work back to at least 0.13)
>
> On Tue, 06 May 2014, Olivier Berger  
> wrote:
>> Hi.
>>
>> I've tried tu use the tips indicated at
>> http://notmuchmail.org/emacstips/#index8h2 so as to add a keybinding to
>> tag spam messages, and wonder if there's a possibility to make it apply
>> on selected regions, like what notmuch-search-archive-thread does.
>
> I have added a snippet showing how to do this (and noted that is not
> possible in notmuch-tree as we don't have a tag region option there).
>

Thanks. This works exactly I like it :-)

>> Btw, I think that the current examples could be improved by adding a 
>> (next-line)
>> at the end, like :
>> (define-key notmuch-search-mode-map "S"
>> (lambda ()
>>   "mark messages in thread as spam"
>>   (interactive)
>>   (notmuch-search-tag '("+spam" "-inbox"))
>>   (next-line)))
>
> I have left this as it is as this works in search mode, but not show
> mode and I didn't want to have too many examples. Obviously feel free to
> edit the wiki if you like!
>

Note that I'm now using the following :
  (define-key notmuch-search-mode-map "S"
(lambda (&optional beg end)
  "mark messages in thread as spam"
  (interactive (notmuch-search-interactive-region))
  (notmuch-search-tag '("+spam" "-inbox") beg end)
  (if (eq beg end) (notmuch-search-next-thread

This offers the possibility to jump to the next line when tagging
individual lines, and not do so when acting on a region.

Btw, such a difference in behaviour may be a tiny, but still nice
improvement on the code of notmuch-search-archive-thread too.

I haven't touched the wiki, as I'm not sure this is the best way to
write it and everyone would be interested.

Hope this helps.

Best regards,

-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH v2] emacs: Add support for saved search accelerator keys

[David Edmondson]

emacs: Add support for saved search accelerator keys

This arose out a conversation in #notmuch and Mark's patch to extend
the saved search custom specification based on requirements for an
external package (Austin's notmuch-go.el).

v2:
- Comments from Mark Walters:
  - Use `notmuch-saved-search-get'.
  - Use key-sequence rather than string in the custom definition.
  - Add a ? binding to display the accelerators.
  - Use the minibuffer-local-map as parent for the new keymap.
  - Fix external declarations.
  - Remove the display of the accelerators in notmuch-hello.


David Edmondson (1):
  emacs: Add support for saved search accelerators

 emacs/notmuch-hello.el |  5 -
 emacs/notmuch-lib.el   | 46 ++
 2 files changed, 50 insertions(+), 1 deletion(-)

-- 
2.0.0.rc0

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

[PATCH v2] emacs: Add support for saved search accelerators

[David Edmondson]

Extended the saved search definition to allow the inclusion of an
accelerator key for the search. Bind 'j' in the common mode map as a
leader for such accelerator keys.
---
 emacs/notmuch-hello.el |  5 -
 emacs/notmuch-lib.el   | 46 ++
 2 files changed, 50 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index 3de5238..64d5aa1 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -85,6 +85,7 @@ searches so they still work in customize."
(group :format "%v" :inline t (const :format "  Query: " 
:query) (string :format "%v")))
  (checklist :inline t
 :format "%v"
+(group :format "%v" :inline t (const :format "Key: " 
:key) (key-sequence :format "%v"))
 (group :format "%v" :inline t (const :format "Count-Query: 
" :count-query) (string :format "%v"))
 (group :format "%v" :inline t (const :format "" 
:sort-order)
(choice :tag " Sort Order"
@@ -101,6 +102,7 @@ a plist. Supported properties are
 
   :nameName of the search (required).
   :query   Search to run (required).
+  :key Optional accelerator key.
   :count-query Optional extra query to generate the count
shown. If not present then the :query property
is used.
@@ -551,7 +553,8 @@ with `notmuch-hello-query-counts'."
(when elem
  (if (> column-indent 0)
  (widget-insert (make-string column-indent ? )))
- (let* ((name (plist-get elem :name))
+ (let* ((key (plist-get elem :key))
+(name (plist-get elem :name))
 (query (plist-get elem :query))
 (oldest-first (case (plist-get elem :sort-order)
 (newest-first nil)
diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index 2941da3..f8c5f96 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -25,6 +25,10 @@
 (require 'mm-decode)
 (require 'cl)
 
+(declare-function notmuch-search "notmuch" (&optional query oldest-first 
target-thread target-line continuation))
+(declare-function notmuch-saved-search-get "notmuch-hello" (saved-search 
field))
+(defvar notmuch-saved-searches) ;; In `notmuch-hello.el'.
+
 (defvar notmuch-command "notmuch"
   "Command to run the notmuch binary.")
 
@@ -130,6 +134,7 @@ For example, if you wanted to remove an \"inbox\" tag and 
add an
 (define-key map "m" 'notmuch-mua-new-mail)
 (define-key map "=" 'notmuch-refresh-this-buffer)
 (define-key map "G" 'notmuch-poll-and-refresh-this-buffer)
+(define-key map "j" 'notmuch-jump)
 map)
   "Keymap shared by all notmuch modes.")
 
@@ -845,6 +850,47 @@ status."
 (defvar notmuch-show-process-crypto nil)
 (make-variable-buffer-local 'notmuch-show-process-crypto)
 
+;; Jump key support:
+
+(defvar notmuch-jump-search nil)
+(defun notmuch-jump-map ()
+  (let ((map (make-sparse-keymap))
+   help)
+(set-keymap-parent map minibuffer-local-map)
+(suppress-keymap map)
+(dolist (saved-search notmuch-saved-searches)
+  (let ((key (notmuch-saved-search-get saved-search :key)))
+   (when key
+ (define-key map key `(lambda ()
+(interactive)
+(setq notmuch-jump-search ',saved-search)
+(exit-minibuffer)))
+ (push (format "%s: %s"
+   (propertize key 'face 'minibuffer-prompt)
+   (notmuch-saved-search-get saved-search :name))
+   help
+;; Hitting ? displays a quick hint of the accelerators.
+(define-key map "?" `(lambda ()
+  (interactive)
+  (message "%s"
+   (mapconcat #'identity
+  ;; Reverse the list so
+  ;; that elements appear
+  ;; in the same order as
+  ;; `notmuch-saved-searches'.
+  (reverse ',help)
+  " "
+map))
+
+(defun notmuch-jump ()
+  "Read a saved search accelerator key and perform the search."
+  (interactive)
+  (setq notmuch-jump-search nil)
+  (read-from-minibuffer "Jump to saved search: " nil (notmuch-jump-map))
+  (when notmuch-jump-search
+(notmuch-search (notmuch-saved-search-get notmuch-jump-search :query)
+   (notmuch-saved-search-get notmuch-jump-search 
:oldest-first
+
 (provide 'notmuch-lib)
 
 ;; Local Variables:
-- 
2.0.0.rc0

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

Re: Linux-only fdatasync() in 3c13bc

[Kushal Kumaran]

Xīcò  writes:

> Also, commit 3c13bc introduced a call to fdatasync() which is not
> available on FreeBSD, and probably not either on MacOS at least.
>

fdatasync is POSIX:
http://pubs.opengroup.org/onlinepubs/009695399/functions/fdatasync.html

-- 
regards,
kushal


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

GMAIL tag sync arriving in "next" branch in Offlineimap

[Rainer M Krug]

Recently, gmail tag sync was discussed here, and it seems something is
happening in Offlineimap: patches implementing synching of gmail tags to 
X-Labels have been applied in the "next" branch and announced on the
Offline mailing list. 

Cheers,

Rainer
-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :   +33 - (0)9 53 10 27 44
Cell:   +33 - (0)6 85 62 59 98
Fax :   +33 - (0)9 58 10 27 44

Fax (D):+49 - (0)3 21 21 25 22 44

email:  rai...@krugs.de

Skype:  RMkrug

PGP: 0x0F52F982


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

[PATCH v2 00/10] add insert --must-index option

[Tomi Ollila]

On Wed, Apr 16 2014, Peter Wang  wrote:

> Follow up to id:1374365254-13227-1-git-send-email-novalazy at gmail.com
> The main changes are to take into account failures during
> tagging and flushing of the database.
>
> I took Jani's patch id:1390152046-6509-1-git-send-email-jani at nikula.org
> without modification.
>
> The soname bump is included in case it is required.

I guess it is -- then changing in that file is not enough, lib/notmuch.h
needs to have the same change.

But, would a MINOR value update work -- anyone who needs only 3.1.0
could also work with 3.2.0...

If MINOR update were sufficient then we would not need to add
api changes that supports logging (etc.) to this conversation...

... but anyone interested these changes should also take a look
of the actual changes... :D

Tomi

> The python/go/ruby changes are untested.



>
>
> Jani Nikula (1):
>   lib: add return status to database close and destroy
>
> Peter Wang (9):
>   lib: bump soname
>   python: handle return status of database close and destroy
>   go: add return status to database close method
>   ruby: handle return status of database close
>   cli: refactor insert
>   cli: indicate insert failure mode in exit status
>   cli: add insert --must-index option
>   test: test insert --must-index
>   man: update insert documentation
>
>  bindings/go/src/notmuch/notmuch.go  |   4 +-
>  bindings/python/notmuch/database.py |  12 ++--
>  bindings/ruby/database.c|   4 +-
>  doc/man1/notmuch-insert.rst |  24 +--
>  lib/Makefile.local  |   2 +-
>  lib/database.cc |  30 ++--
>  lib/notmuch.h   |  15 +++-
>  notmuch-insert.c| 134 
> +---
>  test/T070-insert.sh |  32 +++--
>  9 files changed, 176 insertions(+), 81 deletions(-)
>
> -- 
> 1.8.4
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch