Re: RFC/PATCH emacs attachment handling
On Wed 07 Sep 2011 04:20, Mark Walters writes: > Hello > > I have modified the emacs interface for handling attachments by adding > a keymap to the attachment button. For example pressing v when on an > attachment button views the attachment (using the mailcap method) and > pressing s saves the attachment. I find this makes it a lot easier > when dealing with message with lots of attachments. In my gnus (haven't got rid the latest one, yet ;) : Pressing ENTER (RET) on top of text/html content: w3m-safe-view-this-url Pressing ENTER (RET) on top of text content: widget-button-press Pressing ENTER (RET) on top of an attachment: gnus-article-press-button Pressing 'o' on top of text executes: gnus-summary-save-article Pressing 'o' on top of an attachment: gnus-mime-save-part To user that is: Pressing Enter on top of an attachment will either show the attachment on buffer (in case there is 'converter' defined) or offer to save the attachment. Pressing 'o' on top of an attachment will always offer to save the attachment. Therefore I'd check rmail / gnus / vm / mh-e to check what keybindings those use and if there are some commonalities, align with those. > > Best wishes > > Mark > Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 0/2] sort saved searches, again
Hi, and thanks for all the comments - [I took the liberty of reordering Adam's paragraphs in my reply.] On Tue, 6 Sep 2011 08:23:43 -0700 (PDT), Adam Wolfe Gordon wrote: > I think having an option to sort the saved searches is a fine idea. > The Emacs Way would probably be to have an option for the sort order > that takes the name of a function, which is called to sort the > searches. My first thought is that this isn't very user-friendly. > But, thinking about it a bit more, if the default causes the searches > to be sorted alphabetically, and setting the value to nil causes them > not to be sorted, then it's user-friendly for the two most common > cases, and still 100% customizable for those who want different sort > orders. Please find this implemented in patch 1. > I keep my saved searches in a particular order, kind of emulating the > Gmail sidebar: unread, inbox, sent, all mail. Putting these in > alphabetical order either direction would not achieve the goal of > having the most used/important saved searches first (i.e. I hardly > ever use all mail, so it shouldn't be first in the list). > The tags list, on the other hand, I like having sorted to make tags > easy to find. It has a different purpose than saved searches for me, > so its behavior is different. I hardly use tags at all. I have dozens of saved searches instead. Thus I want the saved searches to be easy to find, and I'd rather have the computer sort them for me. I do admit to renaming the most important ones to start with capital letters so they pop up first even when sorted. Since it seems that people generally prefer to keep the most important saved searches first in the list, I've included patch 2 to make new saved searches be added to the end of the list rather than inserted in the beginning. BR, Jani. Jani Nikula (2): emacs: Add new customization option to sort saved searches emacs: Make saving new saved searches append, not prepend emacs/notmuch-hello.el | 28 ++-- 1 files changed, 26 insertions(+), 2 deletions(-) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 1/2] emacs: Add new customization option to sort saved searches
Add new customization option notmuch-saved-search-sort-function to sort saved searches in user-defined order. Provide a sort function to sort the saved searches in alphabetical order. Setting the search function to nil causes the saved searches not to be sorted, as before. This also remains the default. The function only affects display of the saved searches, not the order in which they are stored by custom. Signed-off-by: Jani Nikula --- emacs/notmuch-hello.el | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 65fde75..6c8e265 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -42,6 +42,26 @@ :type 'boolean :group 'notmuch) +(defun notmuch-sort-saved-searches (alist) + "Generate an alphabetically sorted saved searches alist." + (sort alist (lambda (a b) (string< (car a) (car b) + +(defcustom notmuch-saved-search-sort-function nil + "Function used to sort the saved searches for the notmuch-hello view. + +This variable controls how saved searches should be sorted. No +sorting (nil) displays the saved searches in the order they are +stored in `notmuch-saved-searches'. Sort alphabetically sorts the +saved searches in alphabetical order. Custom sort function should +be a function or a lambda expression that takes the saved +searches alist as a parameter, and returns a new saved searches +alist to be used." + :type '(choice (const :tag "No sorting" nil) +(const :tag "Sort alphabetically" notmuch-sort-saved-searches) +(function :tag "Custom sort function" + :value notmuch-sort-saved-searches)) + :group 'notmuch) + (defvar notmuch-hello-indent 4 "How much to indent non-headers.") @@ -440,6 +460,10 @@ Complete list of currently available key bindings: (widest (max saved-widest alltags-widest))) (when saved-alist + ;; Sort saved searches if required. + (when notmuch-saved-search-sort-function + (setq saved-alist + (funcall notmuch-saved-search-sort-function saved-alist))) (widget-insert "\nSaved searches: ") (widget-create 'push-button :notify (lambda (&rest ignore) -- 1.7.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 2/2] emacs: Make saving new saved searches append, not prepend
Append new saved searches at the end of saved searches rather than insert in front. Signed-off-by: Jani Nikula --- emacs/notmuch-hello.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 6c8e265..dc34ebe 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -188,8 +188,8 @@ Typically \",\" in the US and UK and \".\" in Europe." collect elem)) ;; Add the new one. (customize-save-variable 'notmuch-saved-searches -(push (cons name search) - notmuch-saved-searches)) +(add-to-list 'notmuch-saved-searches + (cons name search) t)) (message "Saved '%s' as '%s'." search name) (notmuch-hello-update))) -- 1.7.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] emacs: Fix notmuch-hello-tag-list-make-query defcustom
It was not possible to define custom filters or filter functions because the types were const. Remove const to allow editing. Signed-off-by: Jani Nikula --- emacs/notmuch-hello.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 65fde75..ad1a13f 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -66,8 +66,8 @@ Finally this can be a function that will be called for each tag and should return a filter for that tag, or nil to hide the tag." :type '(choice (const :tag "All messages" nil) (const :tag "Unread messages" "tag:unread") -(const :tag "Custom filter" string) -(const :tag "Custom filter function" function)) +(string :tag "Custom filter") +(function :tag "Custom filter function")) :group 'notmuch) (defcustom notmuch-hello-hide-tags nil -- 1.7.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] emacs: Fix notmuch-mua-user-agent defcustom
The :options keyword is not meaningful for function type. Also, it was not
possible to enter nil value, contrary to the notmuch-mua-user-agent
defcustom documentation. Specify the alternatives using choice type, taking
nil into account.
Signed-off-by: Jani Nikula
---
emacs/notmuch-mua.el | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 8824b08..8b95bd4 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -35,10 +35,12 @@
"Function used to generate a `User-Agent:' string. If this is
`nil' then no `User-Agent:' will be generated."
:group 'notmuch
- :type 'function
- :options '(notmuch-mua-user-agent-full
-notmuch-mua-user-agent-notmuch
-notmuch-mua-user-agent-emacs))
+ :type '(choice (const :tag "No user agent string" nil)
+(const :tag "Full" notmuch-mua-user-agent-full)
+(const :tag "Notmuch" notmuch-mua-user-agent-notmuch)
+(const :tag "Emacs" notmuch-mua-user-agent-emacs)
+(function :tag "Custom user agent function"
+ :value notmuch-mua-user-agent-full)))
(defcustom notmuch-mua-hidden-headers '("^User-Agent:")
"Headers that are added to the `message-mode' hidden headers
--
1.7.1
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 5/7] emacs: improve hidden signatures handling in notmuch-show-advance-and-archive
On Fri, 1 Jul 2011 08:55:20 +0400, Dmitry Kurochkin wrote: > Use `previous-single-char-property-change' instead of going > through each character by hand and testing it's visibility. This > fixes `notmuch-show-advance-and-archive' to work for the last > message in thread with hidden signature. Hi, this is still broken in master, did this patch fall between the cracks or something? BR, Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 5/7] emacs: improve hidden signatures handling in notmuch-show-advance-and-archive
On Wed, 07 Sep 2011 09:13:22 +, Jani Nikula wrote: > On Fri, 1 Jul 2011 08:55:20 +0400, Dmitry Kurochkin > wrote: > > Use `previous-single-char-property-change' instead of going > > through each character by hand and testing it's visibility. This > > fixes `notmuch-show-advance-and-archive' to work for the last > > message in thread with hidden signature. > > Hi, this is still broken in master, did this patch fall between the > cracks or something? > It was not applied to master. Just like many other patches. Regards, Dmitry > BR, > Jani. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2 0/2] sort saved searches, again
(Sorry if anyone gets this twice; I sent it to the list initially from the wrong email address.) On Wed, Sep 7, 2011 at 02:01, Jani Nikula wrote: > On Tue, 6 Sep 2011 08:23:43 -0700 (PDT), Adam Wolfe Gordon > wrote: >> I think having an option to sort the saved searches is a fine idea. >> The Emacs Way would probably be to have an option for the sort order >> that takes the name of a function, which is called to sort the >> searches. My first thought is that this isn't very user-friendly. >> But, thinking about it a bit more, if the default causes the searches >> to be sorted alphabetically, and setting the value to nil causes them >> not to be sorted, then it's user-friendly for the two most common >> cases, and still 100% customizable for those who want different sort >> orders. > > Please find this implemented in patch 1. I've tried the patches, and they work properly for me. I think this looks good; hopefully others agree. > I hardly use tags at all. I have dozens of saved searches instead. Thus > I want the saved searches to be easy to find, and I'd rather have the > computer sort them for me. I do admit to renaming the most important > ones to start with capital letters so they pop up first even when > sorted. > > Since it seems that people generally prefer to keep the most important > saved searches first in the list, I've included patch 2 to make new > saved searches be added to the end of the list rather than inserted in > the beginning. Indeed, I expect there are many different notmuch workflows. I think these patches keep notmuch general enough to support any workflow, while making the common ones very easy to use. -- Adam Wolfe Gordon ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Memory management practices
On Mon, 29 Aug 2011 16:30:57 -0400, Ben Gamari wrote: > [SNIP] > > In general, it seems to me that memory management in notmuch bindings is > a little bit harder than it needs to me due to the decision not to > talloc_ref parent objects when a new child object is created. This means > that a bindings author needs to recreate the ownership tree in their > binding, a task which is fairly easily done (except in the case of > Haskell due to the weak GC finalization guarantees) but seems quite > unnecessary. Is there a reason this decision was made? Would a patch be > accepted adding talloc_ref'ing parents in those functions creating > children and talloc_frees in *_destroys? > Any opinions concerning whether this is an acceptable idea? I wouldn't mind putting together a patch-set, but I'd rather not waste my time if the set would ultimately be rejected due to some technical objection I have yet to think of. Cheers, - Ben ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: SlackBuild package for notmuch 0.7
Hi, On Sun, 04 Sep 2011 19:15:56 +0200, Jostein Berntsen wrote: > > I have made a SlackBuild package for notmuch version 0.7 that makes it > easy to install it the correct way in Slackware 13.37: Thank you very much Jostein ! -- X=M=A ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: RFC/PATCH emacs attachment handling
Hello Tomi, On Wed, 07 Sep 2011 10:06:36 +0300, Tomi Ollila wrote: > On Wed 07 Sep 2011 04:20, Mark Walters writes: > > > Hello > > > > I have modified the emacs interface for handling attachments by adding > > a keymap to the attachment button. For example pressing v when on an > > attachment button views the attachment (using the mailcap method) and > > pressing s saves the attachment. I find this makes it a lot easier > > when dealing with message with lots of attachments. > > In my gnus (haven't got rid the latest one, yet ;) : > > Pressing ENTER (RET) on top of text/html content: w3m-safe-view-this-url > Pressing ENTER (RET) on top of text content: widget-button-press > Pressing ENTER (RET) on top of an attachment: gnus-article-press-button > > Pressing 'o' on top of text executes: gnus-summary-save-article > Pressing 'o' on top of an attachment: gnus-mime-save-part > > To user that is: > > Pressing Enter on top of an attachment will either show the attachment on > buffer (in case there is 'converter' defined) or offer to save the > attachment. Pressing 'o' on top of an attachment will always offer to save > the attachment. I really do not like it this behaviour. I'd rather want easy to memorize keybindings: 'v'iew,'s'ave, etc. -- X=M=A ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Do not attept to output part raw if part is not GMimePart.
On Tue, 06 Sep 2011 15:51:42 -0700, Jameson Graef Rollins wrote: > Everyone that I know of who has tried to reproduce this bug has been > able to. I vote that we include this patch in 0.8, so that we can get > it out of the way. I have pushed this to master. Sorry, I still don't plan to include it in 0.8. I think it is better to have a short strict freeze, than a long friendly one. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Do not attept to output part raw if part is not GMimePart.
On Wed, 07 Sep 2011 18:46:10 -0300, David Bremner wrote: > I have pushed this to master. Sorry, I still don't plan to include it in > 0.8. I think it is better to have a short strict freeze, than a long > friendly one. Ok, thanks. Just as long as I don't have to push to get this fix applied anymore. This will be more an issue for the users of the 0.8 branch, anyway, since I run my own version where this patch was applied many moons ago. jamie. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Memory management practices
On Wed, Sep 7, 2011 at 4:36 PM, Ben Gamari wrote: > On Mon, 29 Aug 2011 16:30:57 -0400, Ben Gamari wrote: >> [SNIP] >> >> In general, it seems to me that memory management in notmuch bindings is >> a little bit harder than it needs to me due to the decision not to >> talloc_ref parent objects when a new child object is created. This means >> that a bindings author needs to recreate the ownership tree in their >> binding, a task which is fairly easily done (except in the case of >> Haskell due to the weak GC finalization guarantees) but seems quite >> unnecessary. Is there a reason this decision was made? Would a patch be >> accepted adding talloc_ref'ing parents in those functions creating >> children and talloc_frees in *_destroys? >> > Any opinions concerning whether this is an acceptable idea? I wouldn't > mind putting together a patch-set, but I'd rather not waste my time if > the set would ultimately be rejected due to some technical objection I > have yet to think of. > > Cheers, I've been meaning to look in to this in depth. (I still haven't, but wanted to give you some reply.) In general (though perhaps not always?), libnotmuch uses talloc() to allocate children objects, which already implicitly creates a talloc reference from the parent object to the child object. You've certainly thought about this harder than I have, but it seems like the bindings should simply create an additional talloc reference and unlink that reference in the GC finalizer, so that the library-created references would maintain the integrity of the data structures, while the binding-created references would maintain their extent. Hence, I don't see why simultaneous GC would cause problems with talloc, or why the bindings would have to recreate the reference tree. I'm a bit confused by the reference tree you drew. The references in the underlying libnotmuch objects are the other way around. notmuch_query_t holds a talloc reference to every notmuch_messages_t it produces, not the other way around. (Though, in reality, these objects are completely independent of each other. This reference exists purely as a convenience for C programmers to make it easy to clean up all notmuch_messages_t objects when you destroy the notmuch_query_t. This is probably a poor interface; it may be better to take an explicit talloc context, which could be the query object, or could be something else. In fact, I would expect this to cause memory *leaks* in bindings if it were not handled carefully, rather than premature GC.) ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Memory management practices
On Wed, Sep 7, 2011 at 10:48 PM, Austin Clements wrote: > *snip* > > I'm a bit confused by the reference tree you drew. The references in > the underlying libnotmuch objects are the other way around. > notmuch_query_t holds a talloc reference to every notmuch_messages_t > it produces, not the other way around. Sorry, I went back and re-read your earlier messages and now I see why your references were the way they were. I stand by the rest of my previous message though. I think the technique used in the Python bindings only works because Python's GC happens to finalize in a particular order (though I doubt that's guaranteed, and could easily not be the case if you stray into the realm of its cycle collector). In general, it seems like approach is trying to recreate C-like memory management and is fragile as a result, whereas talloc should, I think, allow bindings to express their runtime's memory management rather naturally. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RFC/PATCH emacs attachment handling
Hello I have modified the emacs interface for handling attachments by adding a keymap to the attachment button. For example pressing v when on an attachment button views the attachment (using the mailcap method) and pressing s saves the attachment. I find this makes it a lot easier when dealing with message with lots of attachments. Other comments: "Viewing" a text/html button opens the part in the mailcap defined html viewer. "Viewing" a part with no mailcap entry just offers to save it. In this version I make the button default to viewing: this is obviously trivial to change but I am not sure what the right way to make that user-configurable is. Finally, I have also mapped the key "o" (other/open with) on a button to open with user chosen program. This could be split out into a separate patch if preferred. Best wishes Mark --- emacs/notmuch-show.el | 76 +++- 1 files changed, 68 insertions(+), 8 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 90f9af7..3a025c5 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -267,10 +267,21 @@ message at DEPTH in the current thread." (run-hooks 'notmuch-show-markup-headers-hook) (define-button-type 'notmuch-show-part-button-type - 'action 'notmuch-show-part-button-action + 'action 'notmuch-show-part-button-view-action + 'keymap 'notmuch-show-part-button-map 'follow-link t 'face 'message-mml) +(defvar notmuch-show-part-button-map + (let ((map (make-sparse-keymap))) + (set-keymap-parent map button-map) + (define-key map "s" 'notmuch-show-part-button-save-action) + (define-key map "v" 'notmuch-show-part-button-view-action) + (define-key map "o" 'notmuch-show-part-button-interactively-view-action) +map) + "Submap for button commands") +(fset 'notmuch-show-part-button-map notmuch-show-part-button-map) + (defun notmuch-show-insert-part-header (nth content-type declared-type &optional name comment) (let ((button)) (setq button @@ -285,7 +296,8 @@ message at DEPTH in the current thread." " ]") :type 'notmuch-show-part-button-type :notmuch-part nth - :notmuch-filename name)) + :notmuch-filename name + :notmuch-content-type content-type)) (insert "\n") ;; return button button)) @@ -309,6 +321,28 @@ message at DEPTH in the current thread." ;; ange-ftp, which is reasonable to use here. (mm-write-region (point-min) (point-max) file nil nil nil 'no-conversion t) +(defun notmuch-show-view-part (message-id nth content-type) + (let ((process-crypto notmuch-show-process-crypto)) +(with-temp-buffer + (setq notmuch-show-process-crypto process-crypto) + ;; Always acquires the part via `notmuch part', even if it is + ;; available in the JSON output. + (insert (notmuch-show-get-bodypart-internal message-id nth)) + ;; set mm-inlined-types to nil to force an external viewer + (let ((handle (mm-make-handle (current-buffer) (list content-type))) + (mm-inlined-types nil)) + (mm-display-part handle) + +(defun notmuch-show-interactively-view-part (message-id nth content-type) + (let ((process-crypto notmuch-show-process-crypto)) +(with-temp-buffer + (setq notmuch-show-process-crypto process-crypto) + ;; Always acquires the part via `notmuch part', even if it is + ;; available in the JSON output. + (insert (notmuch-show-get-bodypart-internal message-id nth)) + (let ((handle (mm-make-handle (current-buffer) (list content-type + (mm-interactively-view-part handle) + (defun notmuch-show-mm-display-part-inline (msg part content-type content) "Use the mm-decode/mm-view functions to display a part in the current buffer, if possible." @@ -1418,12 +1452,38 @@ buffer." ;; Commands typically bound to buttons. -(defun notmuch-show-part-button-action (button) - (let ((nth (button-get button :notmuch-part))) -(if nth - (notmuch-show-save-part (notmuch-show-get-message-id) nth - (button-get button :notmuch-filename)) - (message "Not a valid part (is it a fake part?)." +(defun notmuch-show-part-button-save-action (&optional button) + (interactive) + (let ((button (or button (button-at (point) +(if (not button) + nil + (let ((nth (button-get button :notmuch-part))) + (if nth + (notmuch-show-save-part (notmuch-show-get-message-id) nth + (button-get button :notmuch-filename)) + (message "Not a valid part (is it a fake part?).")) + +(defun notmuch-show-part-button-view-action (&optional button) + (interactive) + (let ((button (or button (button-at (point) +(if (not button) + nil + (let ((nth (button-get button :notmuch-part))) + (if nth + (notmuch-show-view-part (notmuch-show-ge
RFC/PATCH emacs attachment handling
On Wed 07 Sep 2011 04:20, Mark Walters writes: > Hello > > I have modified the emacs interface for handling attachments by adding > a keymap to the attachment button. For example pressing v when on an > attachment button views the attachment (using the mailcap method) and > pressing s saves the attachment. I find this makes it a lot easier > when dealing with message with lots of attachments. In my gnus (haven't got rid the latest one, yet ;) : Pressing ENTER (RET) on top of text/html content: w3m-safe-view-this-url Pressing ENTER (RET) on top of text content: widget-button-press Pressing ENTER (RET) on top of an attachment: gnus-article-press-button Pressing 'o' on top of text executes: gnus-summary-save-article Pressing 'o' on top of an attachment: gnus-mime-save-part To user that is: Pressing Enter on top of an attachment will either show the attachment on buffer (in case there is 'converter' defined) or offer to save the attachment. Pressing 'o' on top of an attachment will always offer to save the attachment. Therefore I'd check rmail / gnus / vm / mh-e to check what keybindings those use and if there are some commonalities, align with those. > > Best wishes > > Mark > Tomi
[PATCH v2 0/2] sort saved searches, again
Hi, and thanks for all the comments - [I took the liberty of reordering Adam's paragraphs in my reply.] On Tue, 6 Sep 2011 08:23:43 -0700 (PDT), Adam Wolfe Gordon wrote: > I think having an option to sort the saved searches is a fine idea. > The Emacs Way would probably be to have an option for the sort order > that takes the name of a function, which is called to sort the > searches. My first thought is that this isn't very user-friendly. > But, thinking about it a bit more, if the default causes the searches > to be sorted alphabetically, and setting the value to nil causes them > not to be sorted, then it's user-friendly for the two most common > cases, and still 100% customizable for those who want different sort > orders. Please find this implemented in patch 1. > I keep my saved searches in a particular order, kind of emulating the > Gmail sidebar: unread, inbox, sent, all mail. Putting these in > alphabetical order either direction would not achieve the goal of > having the most used/important saved searches first (i.e. I hardly > ever use all mail, so it shouldn't be first in the list). > The tags list, on the other hand, I like having sorted to make tags > easy to find. It has a different purpose than saved searches for me, > so its behavior is different. I hardly use tags at all. I have dozens of saved searches instead. Thus I want the saved searches to be easy to find, and I'd rather have the computer sort them for me. I do admit to renaming the most important ones to start with capital letters so they pop up first even when sorted. Since it seems that people generally prefer to keep the most important saved searches first in the list, I've included patch 2 to make new saved searches be added to the end of the list rather than inserted in the beginning. BR, Jani. Jani Nikula (2): emacs: Add new customization option to sort saved searches emacs: Make saving new saved searches append, not prepend emacs/notmuch-hello.el | 28 ++-- 1 files changed, 26 insertions(+), 2 deletions(-)
[PATCH v2 1/2] emacs: Add new customization option to sort saved searches
Add new customization option notmuch-saved-search-sort-function to sort saved searches in user-defined order. Provide a sort function to sort the saved searches in alphabetical order. Setting the search function to nil causes the saved searches not to be sorted, as before. This also remains the default. The function only affects display of the saved searches, not the order in which they are stored by custom. Signed-off-by: Jani Nikula --- emacs/notmuch-hello.el | 24 1 files changed, 24 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 65fde75..6c8e265 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -42,6 +42,26 @@ :type 'boolean :group 'notmuch) +(defun notmuch-sort-saved-searches (alist) + "Generate an alphabetically sorted saved searches alist." + (sort alist (lambda (a b) (string< (car a) (car b) + +(defcustom notmuch-saved-search-sort-function nil + "Function used to sort the saved searches for the notmuch-hello view. + +This variable controls how saved searches should be sorted. No +sorting (nil) displays the saved searches in the order they are +stored in `notmuch-saved-searches'. Sort alphabetically sorts the +saved searches in alphabetical order. Custom sort function should +be a function or a lambda expression that takes the saved +searches alist as a parameter, and returns a new saved searches +alist to be used." + :type '(choice (const :tag "No sorting" nil) +(const :tag "Sort alphabetically" notmuch-sort-saved-searches) +(function :tag "Custom sort function" + :value notmuch-sort-saved-searches)) + :group 'notmuch) + (defvar notmuch-hello-indent 4 "How much to indent non-headers.") @@ -440,6 +460,10 @@ Complete list of currently available key bindings: (widest (max saved-widest alltags-widest))) (when saved-alist + ;; Sort saved searches if required. + (when notmuch-saved-search-sort-function + (setq saved-alist + (funcall notmuch-saved-search-sort-function saved-alist))) (widget-insert "\nSaved searches: ") (widget-create 'push-button :notify (lambda (&rest ignore) -- 1.7.1
[PATCH v2 2/2] emacs: Make saving new saved searches append, not prepend
Append new saved searches at the end of saved searches rather than insert in front. Signed-off-by: Jani Nikula --- emacs/notmuch-hello.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 6c8e265..dc34ebe 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -188,8 +188,8 @@ Typically \",\" in the US and UK and \".\" in Europe." collect elem)) ;; Add the new one. (customize-save-variable 'notmuch-saved-searches -(push (cons name search) - notmuch-saved-searches)) +(add-to-list 'notmuch-saved-searches + (cons name search) t)) (message "Saved '%s' as '%s'." search name) (notmuch-hello-update))) -- 1.7.1
[PATCH 1/2] emacs: Fix notmuch-hello-tag-list-make-query defcustom
It was not possible to define custom filters or filter functions because the types were const. Remove const to allow editing. Signed-off-by: Jani Nikula --- emacs/notmuch-hello.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 65fde75..ad1a13f 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -66,8 +66,8 @@ Finally this can be a function that will be called for each tag and should return a filter for that tag, or nil to hide the tag." :type '(choice (const :tag "All messages" nil) (const :tag "Unread messages" "tag:unread") -(const :tag "Custom filter" string) -(const :tag "Custom filter function" function)) +(string :tag "Custom filter") +(function :tag "Custom filter function")) :group 'notmuch) (defcustom notmuch-hello-hide-tags nil -- 1.7.1
[PATCH 2/2] emacs: Fix notmuch-mua-user-agent defcustom
The :options keyword is not meaningful for function type. Also, it was not
possible to enter nil value, contrary to the notmuch-mua-user-agent
defcustom documentation. Specify the alternatives using choice type, taking
nil into account.
Signed-off-by: Jani Nikula
---
emacs/notmuch-mua.el | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
index 8824b08..8b95bd4 100644
--- a/emacs/notmuch-mua.el
+++ b/emacs/notmuch-mua.el
@@ -35,10 +35,12 @@
"Function used to generate a `User-Agent:' string. If this is
`nil' then no `User-Agent:' will be generated."
:group 'notmuch
- :type 'function
- :options '(notmuch-mua-user-agent-full
-notmuch-mua-user-agent-notmuch
-notmuch-mua-user-agent-emacs))
+ :type '(choice (const :tag "No user agent string" nil)
+(const :tag "Full" notmuch-mua-user-agent-full)
+(const :tag "Notmuch" notmuch-mua-user-agent-notmuch)
+(const :tag "Emacs" notmuch-mua-user-agent-emacs)
+(function :tag "Custom user agent function"
+ :value notmuch-mua-user-agent-full)))
(defcustom notmuch-mua-hidden-headers '("^User-Agent:")
"Headers that are added to the `message-mode' hidden headers
--
1.7.1
[PATCH v2 5/7] emacs: improve hidden signatures handling in notmuch-show-advance-and-archive
On Fri, 1 Jul 2011 08:55:20 +0400, Dmitry Kurochkin wrote: > Use `previous-single-char-property-change' instead of going > through each character by hand and testing it's visibility. This > fixes `notmuch-show-advance-and-archive' to work for the last > message in thread with hidden signature. Hi, this is still broken in master, did this patch fall between the cracks or something? BR, Jani.
[PATCH v2 5/7] emacs: improve hidden signatures handling in notmuch-show-advance-and-archive
On Wed, 07 Sep 2011 09:13:22 +, Jani Nikula wrote: > On Fri, 1 Jul 2011 08:55:20 +0400, Dmitry Kurochkin gmail.com> wrote: > > Use `previous-single-char-property-change' instead of going > > through each character by hand and testing it's visibility. This > > fixes `notmuch-show-advance-and-archive' to work for the last > > message in thread with hidden signature. > > Hi, this is still broken in master, did this patch fall between the > cracks or something? > It was not applied to master. Just like many other patches. Regards, Dmitry > BR, > Jani.
[PATCH v2 0/2] sort saved searches, again
(Sorry if anyone gets this twice; I sent it to the list initially from the wrong email address.) On Wed, Sep 7, 2011 at 02:01, Jani Nikula wrote: > On Tue, 6 Sep 2011 08:23:43 -0700 (PDT), Adam Wolfe Gordon xvx.ca> wrote: >> I think having an option to sort the saved searches is a fine idea. >> The Emacs Way would probably be to have an option for the sort order >> that takes the name of a function, which is called to sort the >> searches. My first thought is that this isn't very user-friendly. >> But, thinking about it a bit more, if the default causes the searches >> to be sorted alphabetically, and setting the value to nil causes them >> not to be sorted, then it's user-friendly for the two most common >> cases, and still 100% customizable for those who want different sort >> orders. > > Please find this implemented in patch 1. I've tried the patches, and they work properly for me. I think this looks good; hopefully others agree. > I hardly use tags at all. I have dozens of saved searches instead. Thus > I want the saved searches to be easy to find, and I'd rather have the > computer sort them for me. I do admit to renaming the most important > ones to start with capital letters so they pop up first even when > sorted. > > Since it seems that people generally prefer to keep the most important > saved searches first in the list, I've included patch 2 to make new > saved searches be added to the end of the list rather than inserted in > the beginning. Indeed, I expect there are many different notmuch workflows. I think these patches keep notmuch general enough to support any workflow, while making the common ones very easy to use. -- Adam Wolfe Gordon
Memory management practices
On Mon, 29 Aug 2011 16:30:57 -0400, Ben Gamari wrote: > [SNIP] > > In general, it seems to me that memory management in notmuch bindings is > a little bit harder than it needs to me due to the decision not to > talloc_ref parent objects when a new child object is created. This means > that a bindings author needs to recreate the ownership tree in their > binding, a task which is fairly easily done (except in the case of > Haskell due to the weak GC finalization guarantees) but seems quite > unnecessary. Is there a reason this decision was made? Would a patch be > accepted adding talloc_ref'ing parents in those functions creating > children and talloc_frees in *_destroys? > Any opinions concerning whether this is an acceptable idea? I wouldn't mind putting together a patch-set, but I'd rather not waste my time if the set would ultimately be rejected due to some technical objection I have yet to think of. Cheers, - Ben
SlackBuild package for notmuch 0.7
Hi, On Sun, 04 Sep 2011 19:15:56 +0200, Jostein Berntsen wrote: > > I have made a SlackBuild package for notmuch version 0.7 that makes it > easy to install it the correct way in Slackware 13.37: Thank you very much Jostein ! -- X=M=A
RFC/PATCH emacs attachment handling
Hello Tomi, On Wed, 07 Sep 2011 10:06:36 +0300, Tomi Ollila wrote: > On Wed 07 Sep 2011 04:20, Mark Walters writes: > > > Hello > > > > I have modified the emacs interface for handling attachments by adding > > a keymap to the attachment button. For example pressing v when on an > > attachment button views the attachment (using the mailcap method) and > > pressing s saves the attachment. I find this makes it a lot easier > > when dealing with message with lots of attachments. > > In my gnus (haven't got rid the latest one, yet ;) : > > Pressing ENTER (RET) on top of text/html content: w3m-safe-view-this-url > Pressing ENTER (RET) on top of text content: widget-button-press > Pressing ENTER (RET) on top of an attachment: gnus-article-press-button > > Pressing 'o' on top of text executes: gnus-summary-save-article > Pressing 'o' on top of an attachment: gnus-mime-save-part > > To user that is: > > Pressing Enter on top of an attachment will either show the attachment on > buffer (in case there is 'converter' defined) or offer to save the > attachment. Pressing 'o' on top of an attachment will always offer to save > the attachment. I really do not like it this behaviour. I'd rather want easy to memorize keybindings: 'v'iew,'s'ave, etc. -- X=M=A
[PATCH] Do not attept to output part raw if part is not GMimePart.
On Tue, 06 Sep 2011 15:51:42 -0700, Jameson Graef Rollins wrote: > Everyone that I know of who has tried to reproduce this bug has been > able to. I vote that we include this patch in 0.8, so that we can get > it out of the way. I have pushed this to master. Sorry, I still don't plan to include it in 0.8. I think it is better to have a short strict freeze, than a long friendly one. d
[PATCH] Do not attept to output part raw if part is not GMimePart.
On Wed, 07 Sep 2011 18:46:10 -0300, David Bremner wrote: > I have pushed this to master. Sorry, I still don't plan to include it in > 0.8. I think it is better to have a short strict freeze, than a long > friendly one. Ok, thanks. Just as long as I don't have to push to get this fix applied anymore. This will be more an issue for the users of the 0.8 branch, anyway, since I run my own version where this patch was applied many moons ago. jamie.
Memory management practices
On Wed, Sep 7, 2011 at 4:36 PM, Ben Gamari wrote: > On Mon, 29 Aug 2011 16:30:57 -0400, Ben Gamari > wrote: >> [SNIP] >> >> In general, it seems to me that memory management in notmuch bindings is >> a little bit harder than it needs to me due to the decision not to >> talloc_ref parent objects when a new child object is created. This means >> that a bindings author needs to recreate the ownership tree in their >> binding, a task which is fairly easily done (except in the case of >> Haskell due to the weak GC finalization guarantees) but seems quite >> unnecessary. Is there a reason this decision was made? Would a patch be >> accepted adding talloc_ref'ing parents in those functions creating >> children and talloc_frees in *_destroys? >> > Any opinions concerning whether this is an acceptable idea? I wouldn't > mind putting together a patch-set, but I'd rather not waste my time if > the set would ultimately be rejected due to some technical objection I > have yet to think of. > > Cheers, I've been meaning to look in to this in depth. (I still haven't, but wanted to give you some reply.) In general (though perhaps not always?), libnotmuch uses talloc() to allocate children objects, which already implicitly creates a talloc reference from the parent object to the child object. You've certainly thought about this harder than I have, but it seems like the bindings should simply create an additional talloc reference and unlink that reference in the GC finalizer, so that the library-created references would maintain the integrity of the data structures, while the binding-created references would maintain their extent. Hence, I don't see why simultaneous GC would cause problems with talloc, or why the bindings would have to recreate the reference tree. I'm a bit confused by the reference tree you drew. The references in the underlying libnotmuch objects are the other way around. notmuch_query_t holds a talloc reference to every notmuch_messages_t it produces, not the other way around. (Though, in reality, these objects are completely independent of each other. This reference exists purely as a convenience for C programmers to make it easy to clean up all notmuch_messages_t objects when you destroy the notmuch_query_t. This is probably a poor interface; it may be better to take an explicit talloc context, which could be the query object, or could be something else. In fact, I would expect this to cause memory *leaks* in bindings if it were not handled carefully, rather than premature GC.)
Memory management practices
On Wed, Sep 7, 2011 at 10:48 PM, Austin Clements wrote: > *snip* > > I'm a bit confused by the reference tree you drew. ?The references in > the underlying libnotmuch objects are the other way around. > notmuch_query_t holds a talloc reference to every notmuch_messages_t > it produces, not the other way around. Sorry, I went back and re-read your earlier messages and now I see why your references were the way they were. I stand by the rest of my previous message though. I think the technique used in the Python bindings only works because Python's GC happens to finalize in a particular order (though I doubt that's guaranteed, and could easily not be the case if you stray into the realm of its cycle collector). In general, it seems like approach is trying to recreate C-like memory management and is fragile as a result, whereas talloc should, I think, allow bindings to express their runtime's memory management rather naturally.
Not much database creation error
Thanks Sebastian, I'll test it as soon as I can. As a further question, I have a program opening the database for READ_WRITE access (this process provides a simple write only dbus interface) and I want clients to connect to notmuch over a read only connection. A problem I'm having is that when I add messages to the database, searching using the read only interface fails to show anything. Searching using the read-write interface shows each email message being added successfully. Is this api topology not expected/recommended/working? Please advise. Best Regards, Martin Owens On Mon, 2011-09-05 at 15:57 +0200, Sebastian Spaeth wrote: > > Let me know if this fixes things.
RFC/PATCH emacs attachment handling
> Finally, I have also mapped the key "o" (other/open with) on a button to > open with user chosen program. This could be split out into a separate > patch if preferred. This is great! In particular many people send PDF attachments to me with mime-type attachment/octet-stream, and notmuch could not view them and only offered to save them... I have wanted this functionality for long! Matthieu
Patch: Flush and Reopen
Hello, Per discussions on irc, I've attached a patch for your consideration which allows the developer to run two new database commands; notmuch_database_flush - used on read_write databases to commit changes to disk notmuch_database_reopen - used on read_only databases to reload from the disk Used in conjunction they can allow access by multiple programs at the same time. There are also changes to the python bindings to add these two methods to the database class. Regards, Martin Owens -- next part -- A non-text attachment was scrubbed... Name: 0001-Add-flush-and-reopen-methods-to-the-libnotmuch-and-t.patch Type: text/x-patch Size: 6898 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110907/da43f3a8/attachment-0001.bin>
