Re: multilingual notmuch (and Content-Language)
On Sun, Mar 18 2018, Daniel Kahn Gillmor wrote: > https://tools.ietf.org/html/rfc3282 describes a Content-Language: > header. https://tools.ietf.org/html/rfc8255 describes > a multipart/multilingual Content-Type. > > notmuch currently uses xapian with a hard-coded English stemmer which > works great for me as a monolingual American, but limits the > applicability of notmuch to Anglophiles (people who speak English). > That makes me sad. > > AIUI, xapian is pretty much committed to being a single-language > indexer. Have you seen the different stemmers it already has? Reference: https://xapian.org/docs/sourcedoc/html/dir_430c089e7e18d7ac6ff937a35cc3312c.html > But i just wanted to point out that it's possible that we > could be smarter about this in notmuch, and wanted to make a space for > possible design discussion. > > a few concrete suggestions (intended as brainstorming, feedback welcome): > > * if we know our index expects english, and we have a message part that >*is not* english (e.g. Content-Language: es), we could avoid indexing >that part. I'd prefer leaving the choice of default stemmer to the user. > * during indexing, we could add a property to each message when we >discover a Content-Language header. this would let you do something >like "notmuch search property:lang=es" to find all messages >explicitly tagged as spanish. > > * (pretty crazy) If we're willing to search in another language we >could add an additional xapian database configured that language, and >we could index identified parts in that language. Do we need to have separate DB if we can use different stemmers dynamically? > * for text parts without a Content-Language: header, we could do some >concrete heuristics to guess the language. For example, choose the >1000 most popular words for each language we might know about, and >look for their presence in the text. Choose the language that is >most heavily represented, and store it in the index as a property. >this could be combined with the suggestions above. +1 for heuristics. > what do you think? what ideas are missing from the branstorm above? I'd > love to hear from people with multilingual mailboxes about how we might > be able to make notmuch work better for them. As an actively bilingual person (English and Spanish), I love this idea. Servilio -- Servilio Afre Puentes Programmer/Analyst, SHARCNET project RHPCS | http://www.rhpcs.mcmaster.ca SHARCNET | https://sharcnet.ca Compute Ontario | http://computeontario.ca Compute/Calcul Canada | http://computecanada.ca 905-525-9140, x22540 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [BUG] gmime-3.0.1 (was: [PATCH] crypto: gracefully handle gmime errors)
On Tue, Sep 05 2017, Jan Malakhovski wrote: [...] > I added `gpgme` to `buildInputs` of `gmime` and now `notmuch` passes all > the tests. Yay! So that was the root problem. > > Is it correct to assume that when building with `gmime-3` `notmuch` > stops calling `gpg` binary and does all the things PGP using `gmime-3`? Yes, they use GPGME instead of a custom wrapper: https://mail.gnome.org/archives/gmime-devel-list/2017-April/msg2.html BTW, I created a merge-request to have GMime 3 in Nixpkgs: https://github.com/NixOS/nixpkgs/pull/28796 Servilio -- Servilio Afre Puentes ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC] [PATCH v1 0/2] Improve the display of headers.
Hi David, I like the idea of aligning the headers, but won't padding with spaces from the left break code that expects at the beginning of the line? Servilio ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2 2/2] emacs: hello: allow deleting individual searches in the history
This commit adds an extra button at the end of the search entries that allows deleting that individual search from the history. A short confirmation (?y? or ?n?) is made before taking action. --- emacs/notmuch-hello.el | 25 +++-- 1 file changed, 23 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index 1ad1bea..147c08c 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -286,6 +286,15 @@ afterwards.") (message "Saved '%s' as '%s'." search name) (notmuch-hello-update))) +(defun notmuch-hello-delete-search-from-history (widget) + (interactive) + (let ((search (widget-value +(symbol-value + (widget-get widget :notmuch-saved-search-widget) +(setq notmuch-search-history (delete search +notmuch-search-history)) +(notmuch-hello-update))) + (defun notmuch-hello-longest-label (searches-alist) (or (loop for elem in searches-alist maximize (length (car elem))) @@ -624,7 +633,12 @@ Complete list of currently available key bindings: ;; `[save]' button. 6 ;; for the `[save]' ;; button. - 1 6)) + 1 6 + ;; 1 for the space + ;; before the `[del]' + ;; button. 5 for the + ;; `[del]' button. + 1 5)) :action (lambda (widget ignore) (notmuch-hello-search (widget-value widget))) search)) @@ -633,7 +647,14 @@ Complete list of currently available key bindings: :notify (lambda (widget ignore) (notmuch-hello-add-saved-search widget)) :notmuch-saved-search-widget widget-symbol -"save")) +"save") + (widget-insert " ") + (widget-create 'push-button +:notify (lambda (widget ignore) + (when (y-or-n-p "Are you sure you want to delete this search? ") + (notmuch-hello-delete-search-from-history widget))) +:notmuch-saved-search-widget widget-symbol +"del")) (widget-insert "\n")) (indent-rigidly start (point) notmuch-hello-indent)) nil)) -- 1.8.3
[PATCH v2 1/2] emacs: hello: ask confirmation for clearing recent searches
The button to clear the recent searches in notmuch-hello is easy to press accidentally while moving around the, clearing potentially useful searches with no way of recovering them. --- emacs/notmuch-hello.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index c1c6f4b..1ad1bea 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -599,8 +599,9 @@ Complete list of currently available key bindings: (widget-insert "Recent searches: ") (widget-create 'push-button :notify (lambda ( ignore) -(setq notmuch-search-history nil) -(notmuch-hello-update)) +(when (y-or-n-p "Are you sure you want to clear the searches? ") + (setq notmuch-search-history nil) + (notmuch-hello-update))) "clear") (widget-insert "\n\n") (let ((start (point))) -- 1.8.3
[PATCH v2 0/2] Enhancements to notmuch-hello search history
Hi, Two patches that enhance the notmuch-hello search history UI. Though minor changes, I find them very helpful. This second iteration includes the modifications suggested by Jani and Tomi. Servilio Afre Puentes (2): emacs: hello: ask confirmation for clearing recent searches emacs: hello: allow deleting individual searches in the history emacs/notmuch-hello.el | 30 ++ 1 file changed, 26 insertions(+), 4 deletions(-) -- 1.8.3
[PATCH 0/2] Enhancements to notmuch-hello search history
Jani Nikula writes: > On Fri, 03 May 2013, Servilio Afre Puentes wrote: >> Two patches that enhance the notmuch-hello search history UI. Though >> minor I find them very helpful. > > Both seem to work as advertised; I did not look at the code much. A > minor bikeshed is that I think y-or-n-p would suffice in patch 1/2. I know, but as it clears the whole history I decided to go with a confirmation that required more attention to diminish the chance of accident, and the action is taken not so oftenly (at least for me, and my guess is that it is the same for most) so it stills balances out positively in the usability. Servilio
Re: [PATCH 0/2] Enhancements to notmuch-hello search history
Jani Nikula j...@nikula.org writes: On Fri, 03 May 2013, Servilio Afre Puentes servi...@gmail.com wrote: Two patches that enhance the notmuch-hello search history UI. Though minor I find them very helpful. Both seem to work as advertised; I did not look at the code much. A minor bikeshed is that I think y-or-n-p would suffice in patch 1/2. I know, but as it clears the whole history I decided to go with a confirmation that required more attention to diminish the chance of accident, and the action is taken not so oftenly (at least for me, and my guess is that it is the same for most) so it stills balances out positively in the usability. Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] emacs: hello: allow deleting individual searches in the history
This commit adds an extra button at the end of the search entries that allows deleting that individual search from the history. A short confirmation (?y? or ?n?) is made before taking action. --- emacs/notmuch-hello.el | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index aa063b7..9fbbdc9 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -286,6 +286,16 @@ afterwards.") (message "Saved '%s' as '%s'." search name) (notmuch-hello-update))) +(defun notmuch-hello-delete-search-from-history (widget) + (interactive) + (let ((search (widget-value +(symbol-value + (widget-get widget :notmuch-saved-search-widget) +(setq notmuch-search-history (delete search +notmuch-search-history)) +(notmuch-hello-update) +)) + (defun notmuch-hello-longest-label (searches-alist) (or (loop for elem in searches-alist maximize (length (car elem))) @@ -624,7 +634,12 @@ Complete list of currently available key bindings: ;; `[save]' button. 6 ;; for the `[save]' ;; button. - 1 6)) + 1 6 + ;; 1 for the space + ;; before the `[del]' + ;; button. 5 for the + ;; `[del]' button. + 1 5)) :action (lambda (widget ignore) (notmuch-hello-search (widget-value widget))) search)) @@ -633,7 +648,14 @@ Complete list of currently available key bindings: :notify (lambda (widget ignore) (notmuch-hello-add-saved-search widget)) :notmuch-saved-search-widget widget-symbol -"save")) +"save") + (widget-insert " ") + (widget-create 'push-button +:notify (lambda (widget ignore) + (when (y-or-n-p "Are you sure you want to delete this search? ") + (notmuch-hello-delete-search-from-history widget))) +:notmuch-saved-search-widget widget-symbol +"del")) (widget-insert "\n")) (indent-rigidly start (point) notmuch-hello-indent)) nil)) -- 1.8.2.1
[PATCH 1/2] emacs: hello: ask confirmation for clearing recent searches
The button to clear the recent searches in notmuch-hello is easy to press accidentally while moving around the, clearing potentially useful searches with no way of recovering them. --- emacs/notmuch-hello.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index c1c6f4b..aa063b7 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -599,8 +599,9 @@ Complete list of currently available key bindings: (widget-insert "Recent searches: ") (widget-create 'push-button :notify (lambda ( ignore) -(setq notmuch-search-history nil) -(notmuch-hello-update)) +(when (yes-or-no-p "Are you sure you want to clear the searches? ") + (setq notmuch-search-history nil) + (notmuch-hello-update))) "clear") (widget-insert "\n\n") (let ((start (point))) -- 1.8.2.1
[PATCH 0/2] Enhancements to notmuch-hello search history
Hi, Two patches that enhance the notmuch-hello search history UI. Though minor I find them very helpful. Servilio Afre Puentes (2): emacs: hello: ask confirmation for clearing recent searches emacs: hello: allow deleting individual searches in the history emacs/notmuch-hello.el | 31 +++ 1 file changed, 27 insertions(+), 4 deletions(-) -- 1.8.2.1
[PATCH 0/2] Enhancements to notmuch-hello search history
Hi, Two patches that enhance the notmuch-hello search history UI. Though minor I find them very helpful. Servilio Afre Puentes (2): emacs: hello: ask confirmation for clearing recent searches emacs: hello: allow deleting individual searches in the history emacs/notmuch-hello.el | 31 +++ 1 file changed, 27 insertions(+), 4 deletions(-) -- 1.8.2.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] emacs: hello: ask confirmation for clearing recent searches
The button to clear the recent searches in notmuch-hello is easy to press accidentally while moving around the, clearing potentially useful searches with no way of recovering them. --- emacs/notmuch-hello.el | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index c1c6f4b..aa063b7 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -599,8 +599,9 @@ Complete list of currently available key bindings: (widget-insert Recent searches: ) (widget-create 'push-button :notify (lambda (rest ignore) -(setq notmuch-search-history nil) -(notmuch-hello-update)) +(when (yes-or-no-p Are you sure you want to clear the searches? ) + (setq notmuch-search-history nil) + (notmuch-hello-update))) clear) (widget-insert \n\n) (let ((start (point))) -- 1.8.2.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] emacs: hello: allow deleting individual searches in the history
This commit adds an extra button at the end of the search entries that allows deleting that individual search from the history. A short confirmation («y» or «n») is made before taking action. --- emacs/notmuch-hello.el | 26 -- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el index aa063b7..9fbbdc9 100644 --- a/emacs/notmuch-hello.el +++ b/emacs/notmuch-hello.el @@ -286,6 +286,16 @@ afterwards.) (message Saved '%s' as '%s'. search name) (notmuch-hello-update))) +(defun notmuch-hello-delete-search-from-history (widget) + (interactive) + (let ((search (widget-value +(symbol-value + (widget-get widget :notmuch-saved-search-widget) +(setq notmuch-search-history (delete search +notmuch-search-history)) +(notmuch-hello-update) +)) + (defun notmuch-hello-longest-label (searches-alist) (or (loop for elem in searches-alist maximize (length (car elem))) @@ -624,7 +634,12 @@ Complete list of currently available key bindings: ;; `[save]' button. 6 ;; for the `[save]' ;; button. - 1 6)) + 1 6 + ;; 1 for the space + ;; before the `[del]' + ;; button. 5 for the + ;; `[del]' button. + 1 5)) :action (lambda (widget rest ignore) (notmuch-hello-search (widget-value widget))) search)) @@ -633,7 +648,14 @@ Complete list of currently available key bindings: :notify (lambda (widget rest ignore) (notmuch-hello-add-saved-search widget)) :notmuch-saved-search-widget widget-symbol -save)) +save) + (widget-insert ) + (widget-create 'push-button +:notify (lambda (widget rest ignore) + (when (y-or-n-p Are you sure you want to delete this search? ) + (notmuch-hello-delete-search-from-history widget))) +:notmuch-saved-search-widget widget-symbol +del)) (widget-insert \n)) (indent-rigidly start (point) notmuch-hello-indent)) nil)) -- 1.8.2.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Use a single buffer invisibility spec to fix quadratic search cost.
Hi, Given that this change is about display of search results, I have the suspicion that the following two factors might be more relevant: - size of the Emacs frame: bigger would mean more threads to show - composition of the search results, specially length of the threads displayed, as the longer they go, the more hidden text there will be And because of this, though you might already have a proper method for measuring it, the results are different. I thought about this because my searches have only ~180 threads, yet I could notice the difference. Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Use a single buffer invisibility spec to fix quadratic search cost.
Hi, Given that this change is about display of search results, I have the suspicion that the following two factors might be more relevant: - size of the Emacs frame: bigger would mean more threads to show - composition of the search results, specially length of the threads displayed, as the longer they go, the more hidden text there will be And because of this, though you might already have a proper method for measuring it, the results are different. I thought about this because my searches have only ~180 threads, yet I could notice the difference. Servilio
[PATCH] emacs: Use a single buffer invisibility spec to fix quadratic search cost.
On 10 November 2011 08:33, Sebastian Spaeth wrote: > On Tue, ?8 Nov 2011 21:55:28 -0500, Austin Clements > wrote: >> ?emacs/notmuch.el | ? 11 +++ >> ?1 files changed, 3 insertions(+), 8 deletions(-) > > > Tested and works great here! +1 for quick inclusion. I join the petition, I have been using for a couple of days and the difference is noticeable. Servilio
Re: [PATCH] emacs: Use a single buffer invisibility spec to fix quadratic search cost.
On 10 November 2011 08:33, Sebastian Spaeth sebast...@sspaeth.de wrote: On Tue, 8 Nov 2011 21:55:28 -0500, Austin Clements amdra...@mit.edu wrote: emacs/notmuch.el | 11 +++ 1 files changed, 3 insertions(+), 8 deletions(-) Tested and works great here! +1 for quick inclusion. I join the petition, I have been using for a couple of days and the difference is noticeable. Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] emacs: bad regexp @ `notmuch-search-process-filter'
What about encoding in notmuch the elements composing the line, print the elements with a separator that would be encoded if it appears in an element, then do the reverse in emacs. One such encoding might be URL-encoding. Servilio
Re: [PATCH v2] emacs: bad regexp @ `notmuch-search-process-filter'
What about encoding in notmuch the elements composing the line, print the elements with a separator that would be encoded if it appears in an element, then do the reverse in emacs. One such encoding might be URL-encoding. Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
branchs and tags and merges oh my!
On 3 July 2011 08:44, David Bremner wrote: > On Sun, 3 Jul 2011 03:14:03 -0400, servilio wrote: >> >> I think there is no need for tags on master, "make dist" should only >> be run on the "release" branch, right? > > It isn't just about make dist (which I anyway thinks makes sense to run > on master to make snapshots). Every compilation from git gets a version > number from running git-describe. ?So unless we want all developers to > have useless/annoying version numbers, we have to care about tags on > master. Why not just generate version when building from master in a different way? Servilio
branchs and tags and merges oh my!
On 3 July 2011 08:32, David Bremner wrote: > On Sat, 2 Jul 2011 15:23:02 -0500, Jed Brown wrote: > >> Remind me of why bugfix patches can't (usually) be applied to the >> release branch first, then merged into master? > > Yes, that might work out for a "release" consisting of one or two > critical patches, and happening more or less instantly. ?But maybe it > makes sense to make more of an effort to do (some of) the release > specific commits first on release and then merging to master, rather > than cherry-picking everything during a freeze. If by "a freeze" you mean freezing Carl's working branch, I agree, that work is better done in different branch so no restriction is imposed on Carl workflow. > In that case we obviously need to merge release back to master. ?If we > want to have one long running release branch, this leads to cross > merging between the two branches. > > -.--m--m---.-- master > ? ? | ? ? ? ? ? ? ?^ ? ? ?^ ? ? ?/ > ? ? ?\ ? ? ? ? ? ?/ ? ? ?/__v > ? ? ? \ ? ? ? ? ?/ ? ? ?/v > ? ? ? ?.+--+m---+ > ? ? ? ? ? ? ? ?0.6 ? ?0.6.1 ? ? 0.7 > > This is all a bit hypothetical at this point of course, since there has > never been a bug-fix release. But there shouldn't be any issue, any changes done in "release" should be merged back to master as I see it. Servilio
branchs and tags and merges oh my!
On 2 July 2011 13:30, David Bremner wrote: > On Sat, 2 Jul 2011 11:59:04 -0400, servilio wrote: >> What about having Carl do the merging of features into a develop >> branch[1], then the release manager prepares a release in a release >> branch, merging back and tagging into master when release is ready? A >> similar workflow could be followed for bugfix releases (branch to >> bugfix/release branch, prepare, merge back to master, tag). > > We could also call the develop branch "master" and use something like > "release" for the branch that contains the release history. I like this idea, two separate long-living branches for the releases and development. What branch would be the head of the master repository in this case? I'd prefer it to be "release", as it would provide the latest stable release when cloning. Also, in the name of the people that might want to build a stable version from source, preparing the release in a separate branch might be a good idea, merging the work there back to master when finished and into release to make the release. >?This is is technically quite close to option #2, but perhaps conceptually > clearer (and throwing in Tom's tagging idea). > > ? ? ? 0.7-pre ? ? ? ? ?0.8-pre ? ? ? ?0.9-pre > -.+--.+-.+- master > ? ? ?\ ? ? ? ? ? ? / ? ? ? ? ? ? ?/ > ? ? ? . ? ?| ? ? ? ? ? ? / > ? ? ? ? ? ? ? ?\ ?/ ? ? 0.7 ? ? / > ? ? ? ? ? ? ? ? +m--+-+m+ release > ? ? ? ? ? ? ?0.6 ? ? ? ? ?0.7.1 ? ? ? 0.8 > > One difference in this version is that a merge from master onto release > (and convenience tagging of master) occurs only when we are ready to release. I think there is no need for tags on master, "make dist" should only be run on the "release" branch, right? Servilio
Re: branchs and tags and merges oh my!
On 2 July 2011 13:30, David Bremner da...@tethera.net wrote: On Sat, 2 Jul 2011 11:59:04 -0400, servilio servi...@gmail.com wrote: What about having Carl do the merging of features into a develop branch[1], then the release manager prepares a release in a release branch, merging back and tagging into master when release is ready? A similar workflow could be followed for bugfix releases (branch to bugfix/release branch, prepare, merge back to master, tag). We could also call the develop branch master and use something like release for the branch that contains the release history. I like this idea, two separate long-living branches for the releases and development. What branch would be the head of the master repository in this case? I'd prefer it to be release, as it would provide the latest stable release when cloning. Also, in the name of the people that might want to build a stable version from source, preparing the release in a separate branch might be a good idea, merging the work there back to master when finished and into release to make the release. This is is technically quite close to option #2, but perhaps conceptually clearer (and throwing in Tom's tagging idea). 0.7-pre 0.8-pre 0.9-pre -.+--.+-.+- master \ / / . | / \ / 0.7 / +m--+-+m+ release 0.6 0.7.1 0.8 One difference in this version is that a merge from master onto release (and convenience tagging of master) occurs only when we are ready to release. I think there is no need for tags on master, make dist should only be run on the release branch, right? Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
branchs and tags and merges oh my!
On 1 July 2011 19:47, David Bremner wrote: > On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard > wrote: >> > 2) merge master onto the release branch >> >> This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging. > > Can you elaborate? Naively it seems like one ends up with the same kind > of spur of history off of the 0.6 tag in both cases. > > .--master > ? ?\ > ? ? 0.6 bugfix > > versus > > -.--. > ? ? ?\ ? ? ? ? ?\ > ? ? ? 0.6master > ? ? ? ? ? ? \ > ? ? ? ? ? ? ?- bugfix > >> As an alternative, you probably should have simply put non-release >> patches on a separate 'feature branch' (probably residing in the feature >> author's repository) which would then be merged onto master post-0.6 > > Yes, that is certainly nice from a git history point of view. On the > other hand the point of separating the roles of feature merger from > release mechanic was to allow Carl more time to work on merging features > into master, and I'm not sure how turning master over to the release > manager helps that. What about having Carl do the merging of features into a develop branch[1], then the release manager prepares a release in a release branch, merging back and tagging into master when release is ready? A similar workflow could be followed for bugfix releases (branch to bugfix/release branch, prepare, merge back to master, tag). This workflow would keep a nice useful history while allowing even more independence between the feature merging and release process, what do you think? Servilio [1] Or next, or whatever other name is better understood by the community.
Re: branchs and tags and merges oh my!
On 1 July 2011 19:47, David Bremner da...@tethera.net wrote: On Fri, 01 Jul 2011 14:48:24 -0700, Keith Packard kei...@keithp.com wrote: 2) merge master onto the release branch This makes doing 'bug fix' stuff on top of 0.6 a bit more challenging. Can you elaborate? Naively it seems like one ends up with the same kind of spur of history off of the 0.6 tag in both cases. .--master \ 0.6 bugfix versus -.--. \ \ 0.6master \ - bugfix As an alternative, you probably should have simply put non-release patches on a separate 'feature branch' (probably residing in the feature author's repository) which would then be merged onto master post-0.6 Yes, that is certainly nice from a git history point of view. On the other hand the point of separating the roles of feature merger from release mechanic was to allow Carl more time to work on merging features into master, and I'm not sure how turning master over to the release manager helps that. What about having Carl do the merging of features into a develop branch[1], then the release manager prepares a release in a release branch, merging back and tagging into master when release is ready? A similar workflow could be followed for bugfix releases (branch to bugfix/release branch, prepare, merge back to master, tag). This workflow would keep a nice useful history while allowing even more independence between the feature merging and release process, what do you think? Servilio [1] Or next, or whatever other name is better understood by the community. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
storing From and Subject in xapian
On 12 May 2011 04:39, Istvan Marko wrote: > Stewart Smith writes: > >> Would it be possible to progressively fill the DB with the new data? >> >> i.e. >> >> if Subject/From not in db for message >> ? ?add Subject/From for this message to DB. > > I started looking into this but then realized that notmuch search opens > the database in read-only mode so it cannot make updates. It might be > desirable to keep it that way for safety and locking reasons. What about the following: - increase NOTMUCH_DATABASE_VERSION[1] - update notmuch_database_upgrade[2] to fill in the new data for the documents missing it - include an upgradedb command that wraps notmuch_database_upgrade[2] - have notmuch search prints a warning about running a DB version less than the runtime and suggests running upgradedb Regards, Servilio [1] http://git.notmuchmail.org/git/notmuch/blob/HEAD:/lib/database.cc#l39 [2] http://git.notmuchmail.org/git/notmuch/blob/HEAD:/lib/database.cc#l765
Re: storing From and Subject in xapian
On 12 May 2011 04:39, Istvan Marko notm...@kismala.com wrote: Stewart Smith stew...@flamingspork.com writes: Would it be possible to progressively fill the DB with the new data? i.e. if Subject/From not in db for message add Subject/From for this message to DB. I started looking into this but then realized that notmuch search opens the database in read-only mode so it cannot make updates. It might be desirable to keep it that way for safety and locking reasons. What about the following: - increase NOTMUCH_DATABASE_VERSION[1] - update notmuch_database_upgrade[2] to fill in the new data for the documents missing it - include an upgradedb command that wraps notmuch_database_upgrade[2] - have notmuch search prints a warning about running a DB version less than the runtime and suggests running upgradedb Regards, Servilio [1] http://git.notmuchmail.org/git/notmuch/blob/HEAD:/lib/database.cc#l39 [2] http://git.notmuchmail.org/git/notmuch/blob/HEAD:/lib/database.cc#l765 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] python/thread: always return a string in get_subject/authors
On 9 May 2011 08:20, David Bremner wrote: > On Mon, ?9 May 2011 09:06:34 +0200, Anton Khirnov > wrote: >> Now None is returned when those don't exist, which is inconvenient to >> deal with. > > I'm not using the python bindings, but from a philosophical point of > view, this change makes me a bit uncomfortable since it apparently > merges two cases together, and makes an error (no Subject) > indistinguishable from an odd situation (Subject of empty string). > Or am I missing something here? I see the the same issue. Servilio
Re: [PATCH] python/thread: always return a string in get_subject/authors
On 9 May 2011 08:20, David Bremner da...@tethera.net wrote: On Mon, 9 May 2011 09:06:34 +0200, Anton Khirnov an...@khirnov.net wrote: Now None is returned when those don't exist, which is inconvenient to deal with. I'm not using the python bindings, but from a philosophical point of view, this change makes me a bit uncomfortable since it apparently merges two cases together, and makes an error (no Subject) indistinguishable from an odd situation (Subject of empty string). Or am I missing something here? I see the the same issue. Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: (auto-)tagging sent messages
On 18 April 2011 16:26, Austin Clements amdra...@mit.edu wrote: On Sun, Apr 17, 2011 at 2:23 PM, Jameson Graef Rollins jroll...@finestructure.net wrote: By giving notmuch new a path to a message in the store: notmuch new /path/to/message By feeding notmuch new a message on stdin, and then having it write the message to a specified location: notmuch new /path/to/maildir message You could then add the ability to add tags at the time of index: notmuch new +foo +bar /path/to/message I like more the idea of using a CLI option, e.g.: notmuch new --tag=foo --tag=bar /path/to/message I think passing specific messages or directories to notmuch new would enable some nice features; beyond immediate indexing any tagging of sent mail, it could be combined with inotify to immediately index any new mail I would add efficiently, it can be done right now, but it would scan the whole mail sub-tree everytime. However, concurrency and atomicity have to be considered carefully with any proposal like this. For example, notmuch new +foo +bar /path/to/message has concurrency hazards: the caller has to store the message before invoking notmuch new, but if the machine crashes between these two operations, the message will be indexed with default tags on the next notmuch new. Similarly, a chance unrelated invocation of notmuch new immediately after the message is stored would result in the new message being indexed with default tags. One solution to both issues would be to add the feature to notmuch new of taking the initial tags from a custom header (e.g.: X-Notmuchmail-Agent-Initial-Tags), and use message-ignored-mail-headers[1] to filter this header out the sent message. Servilio [1] http://www.gnu.org/software/emacs/manual/html_mono/message.html#Mail-Headers ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC] Enhancements to address completion
2011/3/14 Kristoffer Ström kristof...@rymdkoloni.se: Have you looked at 'ido-completing-read that comes with ido-mode? [...] It allows for fuzzy matching on any part of the name. Yes, that's what I use, yes with flex matching. Regards, Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC] Enhancements to address completion
2011/3/14 Kristoffer Str?m : > Have you looked at 'ido-completing-read that comes with ido-mode? [...] > It allows for fuzzy matching on any part of the name. Yes, that's what I use, yes with flex matching. Regards, Servilio
[RFC] Enhancements to address completion
I have been working in some enhancements to the emacs UI address completion, and this weekend I was able to find a way to finish the implementation to an acceptable (to me) state. The gist of it is allowing the completion in Emacs to match against any part of the addresses returned by the notmuch-addrlookup command. I could not find a way to have completing-read behave that way, the strategy of matching anchored to the beginning of strings is in-grained in its design for what I've seen. The current implementation uses Ido, included with Emacs at least in version 23, and is available at: git://git.latertulia.org/servilio/notmuch.git In the branch complete-name-and-address-v2. There is a web interface if you prefer to see the changes, just use "http" as the protocol in your web browser. The first few changes in the branch are fixes and small enhancements I found while working on this, and I have sent them as separate patches for acceptance as they are independent of this work. All of this has been in use (in the form of the branch without "-v2") for almost a year. I started a message in August but somehow successfully forgot completely about it. Regards, Servilio
[PATCH] No initial input for completing-read.
Seeding the autocompletion with the first match makes it harder to see what the other matches are, as all the extra characters would need to be deleted before being able to see the matches. --- emacs/notmuch-address.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el index 2960da9..fc2df12 100644 --- a/emacs/notmuch-address.el +++ b/emacs/notmuch-address.el @@ -57,7 +57,7 @@ line." (chosen (if (eq num-options 1) (car options) (completing-read (format "Address (%s matches): " num-options) - (cdr options) nil nil (car options) + options nil nil nil 'notmuch-address-history (when chosen (push chosen notmuch-address-history) -- 1.7.4.1
[PATCH] Save global match data when looking for the beginning of field.
Thus avoid disrupting usage of regular expressions functions elsewhere. --- emacs/notmuch-address.el |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el index 52e320d..2960da9 100644 --- a/emacs/notmuch-address.el +++ b/emacs/notmuch-address.el @@ -47,9 +47,9 @@ line." (defun notmuch-address-expand-name () (let* ((end (point)) (beg (save-excursion - (re-search-backward "\\(\\`\\|[\n:,]\\)[ \t]*") - (match-end 0) - )) + (save-match-data + (re-search-backward "\\(\\`\\|[\n:,]\\)[ \t]*") + (match-end 0 (orig (buffer-substring-no-properties beg end)) (completion-ignore-case t) (options (notmuch-address-options orig)) -- 1.7.4.1
[PATCH] Eliminate redundant code.
There is no need to move the cursor to the position if you can retrieve its value directly. --- emacs/notmuch-address.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el index 1a7c577..52e320d 100644 --- a/emacs/notmuch-address.el +++ b/emacs/notmuch-address.el @@ -48,8 +48,8 @@ line." (let* ((end (point)) (beg (save-excursion (re-search-backward "\\(\\`\\|[\n:,]\\)[ \t]*") - (goto-char (match-end 0)) - (point))) + (match-end 0) + )) (orig (buffer-substring-no-properties beg end)) (completion-ignore-case t) (options (notmuch-address-options orig)) -- 1.7.4.1
[RFC] Enhancements to address completion
I have been working in some enhancements to the emacs UI address completion, and this weekend I was able to find a way to finish the implementation to an acceptable (to me) state. The gist of it is allowing the completion in Emacs to match against any part of the addresses returned by the notmuch-addrlookup command. I could not find a way to have completing-read behave that way, the strategy of matching anchored to the beginning of strings is in-grained in its design for what I've seen. The current implementation uses Ido, included with Emacs at least in version 23, and is available at: git://git.latertulia.org/servilio/notmuch.git In the branch complete-name-and-address-v2. There is a web interface if you prefer to see the changes, just use http as the protocol in your web browser. The first few changes in the branch are fixes and small enhancements I found while working on this, and I have sent them as separate patches for acceptance as they are independent of this work. All of this has been in use (in the form of the branch without -v2) for almost a year. I started a message in August but somehow successfully forgot completely about it. Regards, Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Eliminate redundant code.
There is no need to move the cursor to the position if you can retrieve its value directly. --- emacs/notmuch-address.el |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el index 1a7c577..52e320d 100644 --- a/emacs/notmuch-address.el +++ b/emacs/notmuch-address.el @@ -48,8 +48,8 @@ line. (let* ((end (point)) (beg (save-excursion (re-search-backward \\(\\`\\|[\n:,]\\)[ \t]*) - (goto-char (match-end 0)) - (point))) + (match-end 0) + )) (orig (buffer-substring-no-properties beg end)) (completion-ignore-case t) (options (notmuch-address-options orig)) -- 1.7.4.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Save global match data when looking for the beginning of field.
Thus avoid disrupting usage of regular expressions functions elsewhere. --- emacs/notmuch-address.el |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el index 52e320d..2960da9 100644 --- a/emacs/notmuch-address.el +++ b/emacs/notmuch-address.el @@ -47,9 +47,9 @@ line. (defun notmuch-address-expand-name () (let* ((end (point)) (beg (save-excursion - (re-search-backward \\(\\`\\|[\n:,]\\)[ \t]*) - (match-end 0) - )) + (save-match-data + (re-search-backward \\(\\`\\|[\n:,]\\)[ \t]*) + (match-end 0 (orig (buffer-substring-no-properties beg end)) (completion-ignore-case t) (options (notmuch-address-options orig)) -- 1.7.4.1 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Implement a simple read-eval-print loop.
Hi Michal, On 20 November 2010 16:15, Michal Sojka wrote: > On Sat, 20 Nov 2010, servilio wrote: >> This implementation uses GNU readline for the prompt and command >> history, with the default file completion enabled. GLib is used to >> split the read line into an arguments list. > > Hi, > > I haven't tested it yet, but it seems to be exactly the piece of code I > wanted to have to speed up notmuch-hello when notmuch is used remotely > over ssh. Spawning new ssh for every saved search to get the count of > matched messages has a way too big overhead. Is this the use case you > had in mind when implementing this? Great to see that you find it useful. Yes, the remote usage was in my mind, but it should enhance the local usage as well. We could also create a quicker test run using the shell. The disadvantage of using an interactive shell is that you can have only one operation running in the UI, and I see no way of interrumpting an operation unless you kill the process, but as starting a new shell shouldn't be a biggie, this might not be as limiting as might seem. The ideal would be for libnotmuch to be able to connect to a xapian-tcpsrv, but haven't had time to look at than, and an interactive shell seemed to be less time demanding to implement (and had the subjective promise of providing a lot of fun). > Currently, I have only one comment to the patch. For me, "repl" is a bit > unintuitive. I was thinking about "shell" as the name of subcommand for > this. I agree, maybe "shell" or "interactive" would be more intuitive, but when I started "repl" was the only one I could think of. Servilio
[PATCH] Implement a simple read-eval-print loop.
This implementation uses GNU readline for the prompt and command
history, with the default file completion enabled. GLib is used to
split the read line into an arguments list.
---
Makefile.local |2 +-
configure | 40 ++-
notmuch.c | 115 ++--
3 files changed, 141 insertions(+), 16 deletions(-)
diff --git a/Makefile.local b/Makefile.local
index f9b5a9b..3aff873 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -31,7 +31,7 @@ GPG_FILE=$(SHA1_FILE).asc
# Smash together user's values with our extra values
FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS)
$(CONFIGURE_CFLAGS) $(extra_cflags)
FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS)
$(extra_cflags) $(extra_cxxflags)
-FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch
$(AS_NEEDED_LDFLAGS) $(GMIME_LDFLAGS) $(TALLOC_LDFLAGS)
+FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch
$(AS_NEEDED_LDFLAGS) $(GMIME_LDFLAGS) $(TALLOC_LDFLAGS)
$(READLINE_LDFLAGS)
FINAL_NOTMUCH_LINKER = CC
ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1)
FINAL_NOTMUCH_LDFLAGS += $(CONFIGURE_LDFLAGS)
diff --git a/configure b/configure
index c58dd0f..c9ea920 100755
--- a/configure
+++ b/configure
@@ -259,6 +259,32 @@ else
errors=$((errors + 1))
fi
+printf "Checking for readline... "
+
+echo "#include
+#include
+#include
+
+int main(void)
+{
+static char *line = (char *)NULL;
+line = readline(\"\");
+add_history(line);
+return 0;
+}" > have_readline.c
+
+if ${CC} -lreadline -o have_readline have_readline.c > /dev/null 2>&1
+then
+printf "Yes.\n"
+have_readline=1
+readline_ldflags="-lreadline"
+else
+printf "No.\n"
+have_readline=0
+errors=$((errors + 1))
+fi
+rm -f have_readline have_readline.c
+
printf "Checking for valgrind development files... "
if pkg-config --exists valgrind; then
printf "Yes.\n"
@@ -341,6 +367,10 @@ EOF
echo " The talloc library (including development files such as
headers)"
echo " http://talloc.samba.org/;
fi
+if [ $have_readline -eq 0 ]; then
+ echo " The readline library (including development files such as
headers)"
+ echo " http://tiswww.case.edu/php/chet/readline/rltop.html;
+fi
cat <
* Keith Packard
+ * Servilio Afre Puentes
*/
+#include
+
+#include
+
+#include
+#include
+#include
+
#include "notmuch-client.h"
typedef int (*command_function_t) (void *ctx, int argc, char *argv[]);
@@ -35,6 +44,9 @@ typedef struct command {
static int
notmuch_help_command (void *ctx, int argc, char *argv[]);
+static int
+notmuch_repl_command (void *ctx, int argc, char *argv[]);
+
static const char search_terms_help[] =
"\tSeveral notmuch commands accept a comman syntax for search\n"
"\tterms.\n"
@@ -361,6 +373,10 @@ command_t commands[] = {
"\tby the \"--format=json\" option of \"notmuch show\". If the\n"
"\tmessage specified by the search terms does not include a\n"
"\tpart with the specified \"id\" there will be no output." },
+{ "repl", notmuch_repl_command,
+ NULL,
+ "Execute an interactive interpreter of notmuch commands.",
+ "\tAlso known as a read-eval-print loop.\n" },
{ "config", notmuch_config_command,
"[get|set] . [value ...]",
"Get or set settings in the notmuch configuration file.",
@@ -471,6 +487,90 @@ notmuch_help_command (unused (void *ctx), int
argc, char *argv[])
return 1;
}
+static int
+notmuch_command_dispatch (void *ctx, int argc, char *argv[])
+{
+command_t *command;
+unsigned int i;
+
+for (i = 0; i < ARRAY_SIZE (commands); i++) {
+ command = [i];
+
+ if (strcmp (argv[0], command->name) == 0)
+ return (command->function) (ctx, argc - 1, [1]);
+}
+
+fprintf (stderr, "Error: Unknown command '%s' (see \"notmuch help\")\n",
+argv[0]);
+
+return 1;
+}
+
+/*
+ * A notmuch REPL (Read-eval-print loop) with readline support.
+ */
+static int
+notmuch_repl_command (void *ctx, unused (int argc), unused (char *argv[]))
+{
+const char *prompt = "notmuch> ";
+static char *line = (char *)NULL;
+int ret = 0;
+gint read_argc = 0;
+gchar **read_argv;
+GError *parse_error;
+
+/* Initialize readline. */
+/* Allow conditional parsing of the ~/.inputrc file. */
+rl_readline_name = "notmuch";
+
+do
+{
+read_argv = NULL;
+parse_error = NULL;
+line = readline(prompt);
+ if (line && *line)
+ {
+ g_shell_parse_argv((gchar *)line,
+
[PATCH] Implement a simple read-eval-print loop.
This implementation uses GNU readline for the prompt and command
history, with the default file completion enabled. GLib is used to
split the read line into an arguments list.
---
Makefile.local |2 +-
configure | 40 ++-
notmuch.c | 115 ++--
3 files changed, 141 insertions(+), 16 deletions(-)
diff --git a/Makefile.local b/Makefile.local
index f9b5a9b..3aff873 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -31,7 +31,7 @@ GPG_FILE=$(SHA1_FILE).asc
# Smash together user's values with our extra values
FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS)
$(CONFIGURE_CFLAGS) $(extra_cflags)
FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS)
$(extra_cflags) $(extra_cxxflags)
-FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch
$(AS_NEEDED_LDFLAGS) $(GMIME_LDFLAGS) $(TALLOC_LDFLAGS)
+FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch
$(AS_NEEDED_LDFLAGS) $(GMIME_LDFLAGS) $(TALLOC_LDFLAGS)
$(READLINE_LDFLAGS)
FINAL_NOTMUCH_LINKER = CC
ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1)
FINAL_NOTMUCH_LDFLAGS += $(CONFIGURE_LDFLAGS)
diff --git a/configure b/configure
index c58dd0f..c9ea920 100755
--- a/configure
+++ b/configure
@@ -259,6 +259,32 @@ else
errors=$((errors + 1))
fi
+printf Checking for readline...
+
+echo #include stdio.h
+#include readline/readline.h
+#include readline/history.h
+
+int main(void)
+{
+static char *line = (char *)NULL;
+line = readline(\\);
+add_history(line);
+return 0;
+} have_readline.c
+
+if ${CC} -lreadline -o have_readline have_readline.c /dev/null 21
+then
+printf Yes.\n
+have_readline=1
+readline_ldflags=-lreadline
+else
+printf No.\n
+have_readline=0
+errors=$((errors + 1))
+fi
+rm -f have_readline have_readline.c
+
printf Checking for valgrind development files...
if pkg-config --exists valgrind; then
printf Yes.\n
@@ -341,6 +367,10 @@ EOF
echo The talloc library (including development files such as
headers)
echo http://talloc.samba.org/;
fi
+if [ $have_readline -eq 0 ]; then
+ echo The readline library (including development files such as
headers)
+ echo http://tiswww.case.edu/php/chet/readline/rltop.html;
+fi
cat EOF
With any luck, you're using a modern, package-based operating system
@@ -349,11 +379,11 @@ case a simple command will install everything
you need. For example:
On Debian and similar systems:
- sudo apt-get install libxapian-dev libgmime-2.4-dev libtalloc-dev
+ sudo apt-get install libxapian-dev libgmime-2.4-dev libtalloc-dev
libreadline-dev
Or on Fedora and similar systems:
- sudo yum install xapian-core-devel gmime-devel libtalloc-devel
+ sudo yum install xapian-core-devel gmime-devel libtalloc-devel
readline-devel
On other systems, similar commands can be used, but the details of the
package names may be different.
@@ -560,6 +590,9 @@ GMIME_LDFLAGS = ${gmime_ldflags}
TALLOC_CFLAGS = ${talloc_cflags}
TALLOC_LDFLAGS = ${talloc_ldflags}
+# Flags needed to compile and link against readline
+READLINE_LDFLAGS = ${readline_ldflags}
+
# Flags needed to have linker set rpath attribute
RPATH_LDFLAGS = ${rpath_ldflags}
@@ -580,5 +613,6 @@ CONFIGURE_CXXFLAGS =
-DHAVE_GETLINE=\$(HAVE_GETLINE) \$(GMIME_CFLAGS)\\
\$(TALLOC_CFLAGS) -DHAVE_VALGRIND=\$(HAVE_VALGRIND) \\
\$(VALGRIND_CFLAGS) \$(XAPIAN_CXXFLAGS) \\
-DHAVE_STRCASESTR=\$(HAVE_STRCASESTR)
-CONFIGURE_LDFLAGS = \$(GMIME_LDFLAGS) \$(TALLOC_LDFLAGS) \$(XAPIAN_LDFLAGS)
+CONFIGURE_LDFLAGS = \$(GMIME_LDFLAGS) \$(TALLOC_LDFLAGS) \\
+ \$(READLINE_LDFLAGS) \$(XAPIAN_LDFLAGS) \\
EOF
diff --git a/notmuch.c b/notmuch.c
index 9ba0ec0..630e272 100644
--- a/notmuch.c
+++ b/notmuch.c
@@ -18,8 +18,17 @@
*
* Authors: Carl Worth cwo...@cworth.org
* Keith Packard kei...@keithp.com
+ * Servilio Afre Puentes servi...@gmail.com
*/
+#include stdio.h
+
+#include string.h
+
+#include glib.h
+#include readline/readline.h
+#include readline/history.h
+
#include notmuch-client.h
typedef int (*command_function_t) (void *ctx, int argc, char *argv[]);
@@ -35,6 +44,9 @@ typedef struct command {
static int
notmuch_help_command (void *ctx, int argc, char *argv[]);
+static int
+notmuch_repl_command (void *ctx, int argc, char *argv[]);
+
static const char search_terms_help[] =
\tSeveral notmuch commands accept a comman syntax for search\n
\tterms.\n
@@ -361,6 +373,10 @@ command_t commands[] = {
\tby the \--format=json\ option of \notmuch show\. If the\n
\tmessage specified by the search terms does not include a\n
\tpart with the specified \id\ there will be no output. },
+{ repl, notmuch_repl_command,
+ NULL,
+ Execute an interactive interpreter of notmuch commands.,
+ \tAlso known as a read
Re: [PATCH] Implement a simple read-eval-print loop.
Hi Michal, On 20 November 2010 16:15, Michal Sojka sojk...@fel.cvut.cz wrote: On Sat, 20 Nov 2010, servilio wrote: This implementation uses GNU readline for the prompt and command history, with the default file completion enabled. GLib is used to split the read line into an arguments list. Hi, I haven't tested it yet, but it seems to be exactly the piece of code I wanted to have to speed up notmuch-hello when notmuch is used remotely over ssh. Spawning new ssh for every saved search to get the count of matched messages has a way too big overhead. Is this the use case you had in mind when implementing this? Great to see that you find it useful. Yes, the remote usage was in my mind, but it should enhance the local usage as well. We could also create a quicker test run using the shell. The disadvantage of using an interactive shell is that you can have only one operation running in the UI, and I see no way of interrumpting an operation unless you kill the process, but as starting a new shell shouldn't be a biggie, this might not be as limiting as might seem. The ideal would be for libnotmuch to be able to connect to a xapian-tcpsrv, but haven't had time to look at than, and an interactive shell seemed to be less time demanding to implement (and had the subjective promise of providing a lot of fun). Currently, I have only one comment to the patch. For me, repl is a bit unintuitive. I was thinking about shell as the name of subcommand for this. I agree, maybe shell or interactive would be more intuitive, but when I started repl was the only one I could think of. Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuchsync: handling of the deleted tag
On 14 November 2010 22:03, Jameson Rollins wrote: [...] > I think the 'print0' might have been a mistake on Carl's part. ?I don't > think that option is actually supported by notmuch. ?In which case xargs > -0 isn't going to work as expected because there are no null characters > in the input stream to use as delimiters. > >> So for anyone else who is stuck adjusting the one liner like >> notmuch search --output=files tag:deleted -print0 | xargs -d '\n' rm > > This is working because the input stream is newline delimited. ?So I > think the -print0 is confusing the issue. And "xargs -L1 ..." will solve the issue in a nicer way. So the above would be: notmuch search --output=files tag:deleted | xargs -L1 rm Servilio
Re: notmuchsync: handling of the deleted tag
On 14 November 2010 22:03, Jameson Rollins jroll...@finestructure.net wrote: [...] I think the 'print0' might have been a mistake on Carl's part. I don't think that option is actually supported by notmuch. In which case xargs -0 isn't going to work as expected because there are no null characters in the input stream to use as delimiters. So for anyone else who is stuck adjusting the one liner like notmuch search --output=files tag:deleted -print0 | xargs -d '\n' rm This is working because the input stream is newline delimited. So I think the -print0 is confusing the issue. And xargs -L1 ... will solve the issue in a nicer way. So the above would be: notmuch search --output=files tag:deleted | xargs -L1 rm Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 0/4] Maildir synchronization v2
On 13 October 2010 08:13, Michal Sojka wrote: [...] > THERE IS CURRENTLY ONE KNOWN ISSUE: Viewing/storing of attachments of > unread messages doesn't work. The reason is that when you view the > message its unread tag is removed which causes the file to be renamed, > but Emacs still uses the original name to access the attachment. You can > workaround this by closing the message and opening it again. This issue > will be fixed after we (I) implement "notmuch cat" command. With this > command, emacs would not access the messages by the file name, but by > running notmuch cat id: which will always give the correct > content. Wouldn't it be more efficient to query notmuch for the filename using the message ID we store in the DB? When network usage is implemented, tramp can give us transparent remote file access in emacs. Regards, Servilio
Re: [PATCH 0/4] Maildir synchronization v2
On 13 October 2010 08:13, Michal Sojka sojk...@fel.cvut.cz wrote: [...] THERE IS CURRENTLY ONE KNOWN ISSUE: Viewing/storing of attachments of unread messages doesn't work. The reason is that when you view the message its unread tag is removed which causes the file to be renamed, but Emacs still uses the original name to access the attachment. You can workaround this by closing the message and opening it again. This issue will be fixed after we (I) implement notmuch cat command. With this command, emacs would not access the messages by the file name, but by running notmuch cat id:message-id which will always give the correct content. Wouldn't it be more efficient to query notmuch for the filename using the message ID we store in the DB? When network usage is implemented, tramp can give us transparent remote file access in emacs. Regards, Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuch-next branch
On 11 October 2010 14:45, Felipe Contreras wrote: > Hi, > > I think many people agree notmuch mainline has been rather slow. So > I'm proposing to have notmuch-next branch, either on github or > gitorious (please vote). +1 for gitorious, you can use OpenID and their code is available (for me a sign of more faith in free software than the Github people). An alternative would be to have a list of git branches in the wiki, with description, clone URL, etc. Servilio
Re: notmuch-next branch
On 11 October 2010 14:45, Felipe Contreras felipe.contre...@gmail.com wrote: Hi, I think many people agree notmuch mainline has been rather slow. So I'm proposing to have notmuch-next branch, either on github or gitorious (please vote). +1 for gitorious, you can use OpenID and their code is available (for me a sign of more faith in free software than the Github people). An alternative would be to have a list of git branches in the wiki, with description, clone URL, etc. Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch-next branch
On 11 October 2010 15:01, Jameson Rollins jroll...@finestructure.net wrote: On Mon, 11 Oct 2010 21:45:47 +0300, Felipe Contreras felipe.contre...@gmail.com wrote: I think many people agree notmuch mainline has been rather slow. So I'm proposing to have notmuch-next branch, either on github or gitorious (please vote). More than one person should have write access to this repo, but some guidelines should be in place. I propose that patches should be signed-off-by at least another person in the mailing list before pushing. It would be nice if this is how the mainline branch works, but we don't need to wait for that to happen. We need to vote on who are the people to have write access. I think this generally sounds like a fine idea, but I don't see why we need a single central repo that multiple people need access to. The whole point of git is to allow for distributed development without need for a central repo. In this case, folks can just merge the patches they're interested in into a next branch in their own personal repos, publish them where ever they want, and then every body can just keep their next branches synced with each other. As consensus is reached, the next release will emerge. +1 and maintaining a list of these repos in the wiki ;) Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
bug tracking
On 28 April 2010 16:34, David Bremner wrote: [...] > Meanwhile Jesse Rosenthal and I started chatting about, and Jesse > started implementing, some tools for grabbing remote collections of tags > and merging them into their own namespace. ?This may give us a > notmuch-oriented way of managing the mailing list a bit better as a kind > of bug tracker. I don't want to promise things on Jesse's behalf, but I > personally am holding off on further bug tracker experiments until I see > how this works out. I have been playing in my head with the idea of using notmuch to track bugs, thinking of ways it could be done. Using tags and searches this should be fine, and even (if not right now, I am sure in the future we will) easily see what bugs have patches/pull requests proposed[1]. While reading your message, David, I think I've found and idea might enable this: enabling the dump command to accept a search term. With this in place, our bug database can be composed of the mail archive + a dump of the tags used for bug management. There another wrinkle with this approach, but a solvable one I think: the current implementation of the restore command will wipe all local state for the related messages. This is really bad for people tracking individually bugs/features in their local notmuch databases, e.g.: using tags such as TODO, REVIEW, etc. But with a way of non-destructively applying a set of tags to a messages we could have a distributed issue/feature/etc tracking system that is 100% notmuch-based and message driven (PR for the feature, we have to think forward!). IMHO this will allow for totally awesome workflows. And we should name it "notmuch issues" or "notmuch bugs". Servilio [1] I like pull request because they are easier to manage: you don't need to resend the patch series when you need to update your work.
Re: bug tracking
On 28 April 2010 16:34, David Bremner brem...@unb.ca wrote: [...] Meanwhile Jesse Rosenthal and I started chatting about, and Jesse started implementing, some tools for grabbing remote collections of tags and merging them into their own namespace. This may give us a notmuch-oriented way of managing the mailing list a bit better as a kind of bug tracker. I don't want to promise things on Jesse's behalf, but I personally am holding off on further bug tracker experiments until I see how this works out. I have been playing in my head with the idea of using notmuch to track bugs, thinking of ways it could be done. Using tags and searches this should be fine, and even (if not right now, I am sure in the future we will) easily see what bugs have patches/pull requests proposed[1]. While reading your message, David, I think I've found and idea might enable this: enabling the dump command to accept a search term. With this in place, our bug database can be composed of the mail archive + a dump of the tags used for bug management. There another wrinkle with this approach, but a solvable one I think: the current implementation of the restore command will wipe all local state for the related messages. This is really bad for people tracking individually bugs/features in their local notmuch databases, e.g.: using tags such as TODO, REVIEW, etc. But with a way of non-destructively applying a set of tags to a messages we could have a distributed issue/feature/etc tracking system that is 100% notmuch-based and message driven (PR for the feature, we have to think forward!). IMHO this will allow for totally awesome workflows. And we should name it notmuch issues or notmuch bugs. Servilio [1] I like pull request because they are easier to manage: you don't need to resend the patch series when you need to update your work. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Allow headers to be shown by default in show mode
On 23 April 2010 13:13, Dirk Hohndel wrote: > On Fri, 23 Apr 2010 12:54:21 +0100, David Edmondson wrote: >> Add `notmuch-show-headers-visible' which, when set `t', causes headers >> to be shown by default. > > Excellent - Carl, can you pull this into 0.3, please? +1 Servilio
Re: [PATCH] emacs: Allow headers to be shown by default in show mode
On 23 April 2010 13:13, Dirk Hohndel hohn...@infradead.org wrote: On Fri, 23 Apr 2010 12:54:21 +0100, David Edmondson d...@dme.org wrote: Add `notmuch-show-headers-visible' which, when set `t', causes headers to be shown by default. Excellent - Carl, can you pull this into 0.3, please? +1 Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
pull request
On 22 April 2010 08:30, David Edmondson wrote: > On Thu, 22 Apr 2010 04:58:16 -0400, Servilio Afre Puentes gmail.com> wrote: >> On 21 April 2010 17:03, Carl Worth wrote: >> > On Mon, 19 Apr 2010 09:27:39 +0100, David Edmondson wrote: >> [...] >> > Meanwhile, another issue with the result of this series is that I now >> > seem to get rendering for both the text/plain and the text/html >> > alternatives when a message has both. For now, the paragraphs are >> > wrapped much more nicely in the rendering of the html portion, but links >> > are apparently entirely missing. The link URLs at least appear in the >> > text/plain rendering, (which is pretty ugly, but at least not impossible >> > to use). >> > >> > If we could get one version or the other working completely, then it >> > would be nice to display only one. >> >> I think that a better approach here would be to list them as parts if >> they are present, then have a [configurable] way to show only one by >> default, and the other would be available to show in-line. > > Showing only one (with a variable allowing you to express preference) is > my intention. Any non-shown parts will appear as attachments - you can > save them using the button (and perhaps later view them). Why not see them in-line if possible? > This can make quite a big difference in a 200 message thread with lots > of 'text/plain or text/html ?' choices - using the text/plain part will > improve the performance of building the show buffer significantly. Yes, it can make a big difference. >> What I miss in this view sometimes is the possibility of being able to >> see the structure of the thread. A way to toggle the expanded state of >> the messages originally expanded when I first opened the view would do >> this very nicely. > > Ah, so you want a "go back to how it was initially" command? Yep, then bind it to a key that would alternate between collapsing all messages and expanding the ones that were originally expanded. Servilio
pull request
On 21 April 2010 17:03, Carl Worth wrote: > On Mon, 19 Apr 2010 09:27:39 +0100, David Edmondson wrote: [...] > Meanwhile, another issue with the result of this series is that I now > seem to get rendering for both the text/plain and the text/html > alternatives when a message has both. For now, the paragraphs are > wrapped much more nicely in the rendering of the html portion, but links > are apparently entirely missing. The link URLs at least appear in the > text/plain rendering, (which is pretty ugly, but at least not impossible > to use). > > If we could get one version or the other working completely, then it > would be nice to display only one. I think that a better approach here would be to list them as parts if they are present, then have a [configurable] way to show only one by default, and the other would be available to show in-line. [...] >> commit e9d737feb5a49fd59e1f27bccd24cac2fd1ef749 >> >> ? ? emacs/notmuch-show.el: Add `notmuch-show-toggle-all' bound to M-RET >> >> ? ? `notmuch-show-toggle-all' changes the visibility all of the messages >> ? ? in the current thread. By default it makes all of the messages not >> ? ? visible. With a prefix argument, it makes them all visible. > > I didn't push this one yet. > > The feature is *almost* what I want. It's just that I often want to open > all messages in a thread, (and I've never found myself wanting to close > all messages). So I'd like to switch which behavior requires the prefix > argument here. What I miss in this view sometimes is the possibility of being able to see the structure of the thread. A way to toggle the expanded state of the messages originally expanded when I first opened the view would do this very nicely. [...] > [Aside: We could improve our help screen by making RET on any line then > bring up the full help message for that function.] +1 >> commit b3be927b54956a7258f203159e0bdb954e686c80 >> >> ? ? emacs: Support for customizing search result display > > Finally, this is pushed. It's a quite lovely feature that's quite easy > to take advantage of from "M-x customize-group" "notmuch". > > Anyone, if you haven't tried that mode yet for customizing notmuch, you > should give it a try. (And we should add some hint somewhere to make it > easier to find. Perhaps a keybinding to get to the customization > buffer.) The help screen is a very good place to place a link to the customization screen. Servilio
Re: pull request
On 22 April 2010 08:30, David Edmondson d...@dme.org wrote: On Thu, 22 Apr 2010 04:58:16 -0400, Servilio Afre Puentes servi...@gmail.com wrote: On 21 April 2010 17:03, Carl Worth cwo...@cworth.org wrote: On Mon, 19 Apr 2010 09:27:39 +0100, David Edmondson d...@dme.org wrote: [...] Meanwhile, another issue with the result of this series is that I now seem to get rendering for both the text/plain and the text/html alternatives when a message has both. For now, the paragraphs are wrapped much more nicely in the rendering of the html portion, but links are apparently entirely missing. The link URLs at least appear in the text/plain rendering, (which is pretty ugly, but at least not impossible to use). If we could get one version or the other working completely, then it would be nice to display only one. I think that a better approach here would be to list them as parts if they are present, then have a [configurable] way to show only one by default, and the other would be available to show in-line. Showing only one (with a variable allowing you to express preference) is my intention. Any non-shown parts will appear as attachments - you can save them using the button (and perhaps later view them). Why not see them in-line if possible? This can make quite a big difference in a 200 message thread with lots of 'text/plain or text/html ?' choices - using the text/plain part will improve the performance of building the show buffer significantly. Yes, it can make a big difference. What I miss in this view sometimes is the possibility of being able to see the structure of the thread. A way to toggle the expanded state of the messages originally expanded when I first opened the view would do this very nicely. Ah, so you want a go back to how it was initially command? Yep, then bind it to a key that would alternate between collapsing all messages and expanding the ones that were originally expanded. Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
python cnotmuch -> notmuch
On 21 April 2010 20:38, Carl Worth wrote: > On Mon, 19 Apr 2010 21:50:13 +0200, "Sebastian Spaeth" SSpaeth.de> wrote: [...] > Though that brings up the question of what to name the Debian package > for these bindings. A quick "apt-cache search python" suggests that > python-notmuch might not be a crazy name. And looks like the one recommended by the Debian Python Policy: http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names Servilio
[PATCH] emacs: Try to name search buffers using info in notmuch-folders
On 21 April 2010 20:10, Carl Worth wrote:
> On Sun, 18 Apr 2010 23:55:50 -0400, Servilio Afre Puentes gmail.com> wrote:
>> As the user has already defined aliases for certain searches in
>> notmuch-folders, search buffer names that use these aliases will
>> be easier to identify.
>
> A lovely feature, thanks!
My pleasure! Thanks to you for notmuch!
> I've pushed this out now (along with a tiny follow-up to avoid a warning
> From the emacs compiler).
Great, I noticed that when building, but as everything worked fine
afterwards, I decided to wait to get some feedback on the list. But
you were faster!
> It does occur to me that once we have saved searches supported at a
> lower level within notmuch, then this functionality won't be needed in
> the emacs interface at all, (since the nice name and the search strings
> will then be equivalent).
Yep.
> And this patch even makes a proposal for what the saved-search syntax
> could be. It uses "[ inbox ]" for a saved search named "inbox". I
> believe that sup is already using "{inbox}" for a similar
> feature. Perhaps a bracketed style like that is what we want.
For me it was the easier thing to read, I suppose that this can be
made to be customizable so the user can set it up to be whatever is
easier to read.
Servilio
Re: [PATCH] emacs: Try to name search buffers using info in notmuch-folders
On 21 April 2010 20:10, Carl Worth cwo...@cworth.org wrote:
On Sun, 18 Apr 2010 23:55:50 -0400, Servilio Afre Puentes
servi...@gmail.com wrote:
As the user has already defined aliases for certain searches in
notmuch-folders, search buffer names that use these aliases will
be easier to identify.
A lovely feature, thanks!
My pleasure! Thanks to you for notmuch!
I've pushed this out now (along with a tiny follow-up to avoid a warning
From the emacs compiler).
Great, I noticed that when building, but as everything worked fine
afterwards, I decided to wait to get some feedback on the list. But
you were faster!
It does occur to me that once we have saved searches supported at a
lower level within notmuch, then this functionality won't be needed in
the emacs interface at all, (since the nice name and the search strings
will then be equivalent).
Yep.
And this patch even makes a proposal for what the saved-search syntax
could be. It uses [ inbox ] for a saved search named inbox. I
believe that sup is already using {inbox} for a similar
feature. Perhaps a bracketed style like that is what we want.
For me it was the easier thing to read, I suppose that this can be
made to be customizable so the user can set it up to be whatever is
easier to read.
Servilio
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: python cnotmuch - notmuch
On 21 April 2010 20:38, Carl Worth cwo...@cworth.org wrote: On Mon, 19 Apr 2010 21:50:13 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: [...] Though that brings up the question of what to name the Debian package for these bindings. A quick apt-cache search python suggests that python-notmuch might not be a crazy name. And looks like the one recommended by the Debian Python Policy: http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Try to provide search buffers with titles from notmuch-folders.
This patch has been obsoleted by the one sent in message: x2hb22065d01004182055vc111d42az357076f93b6cb72a at mail.gmail.com Servilio
[PATCH] emacs: Try to name search buffers using info in notmuch-folders
This patch obsoletes the one sent in message: r2sb22065d01004150516jf099f3dcw180a7db0dc972...@mail.gmail.com 8-- As the user has already defined aliases for certain searches in notmuch-folders, search buffer names that use these aliases will be easier to identify. --- emacs/notmuch.el | 23 ++- 1 files changed, 22 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 0adaf8b..f18b1ac 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -695,6 +695,27 @@ characters as well as `_.+-'. (apply 'notmuch-call-notmuch-process tag (append action-split (list notmuch-search-query-string) nil +(defun notmuch-search-buffer-title (query) + Returns the title for a buffer with notmuch search results. + (let* ((folder (rassoc-if (lambda (key) + (string-match (concat ^ (regexp-quote key)) + query)) + notmuch-folders)) +(folder-name (car folder)) +(folder-query (cdr folder))) +(cond ((and folder (equal folder-query query)) + ;; Query is the same as folder search (ignoring case) + (concat *notmuch-folder- folder-name *)) + (folder + (concat *notmuch-search- + (replace-regexp-in-string (concat ^ (regexp-quote folder-query)) +(concat [ folder-name ]) +query) + *)) + (t + (concat *notmuch-search- query *)) + ))) + ;;;###autoload (defun notmuch-search (query optional oldest-first target-thread target-line) Run \notmuch search\ with the given query string and display results. @@ -707,7 +728,7 @@ The optional parameters are used as follows: target-line: The line number to move to if the target thread does not appear in the search results. (interactive sNotmuch search: ) - (let ((buffer (get-buffer-create (concat *notmuch-search- query * + (let ((buffer (get-buffer-create (notmuch-search-buffer-title query (switch-to-buffer buffer) (notmuch-search-mode) (set 'notmuch-search-query-string query) -- 1.7.0.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Bulk message tagging
On 15 April 2010 21:46, Carl Worth wrote: [...] > We'll probably need to arrange for notmuch to accept search > specifications on stdin or so. Or a daemon mode with a pipe or DBus interface. Servilio
[PATCH] Try to provide search buffers with titles from notmuch-folders.
--- emacs/notmuch.el | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index be09f42..17e0e86 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -696,6 +696,15 @@ characters as well as `_.+-'. (apply 'notmuch-call-notmuch-process "tag" (append action-split (list notmuch-search-query-string) nil +(defun notmuch-search-buffer-title (query) + "Returns the title for a buffer with notmuch search results." + (let ((folder (car (rassoc query notmuch-folders + (if folder + (concat "*notmuch-folder-" folder "*") +(concat "*notmuch-search-" query "*")) + ) +) + ;;;###autoload (defun notmuch-search (query oldest-first target-thread target-line) "Run \"notmuch search\" with the given query string and display results. @@ -708,7 +717,7 @@ The optional parameters are used as follows: target-line: The line number to move to if the target thread does not appear in the search results." (interactive "sNotmuch search: ") - (let ((buffer (get-buffer-create (concat "*notmuch-search-" query "*" + (let ((buffer (get-buffer-create (notmuch-search-buffer-title query (switch-to-buffer buffer) (notmuch-search-mode) (set 'notmuch-search-query-string query) -- 1.7.0.4
[PATCH] Try to provide search buffers with titles from notmuch-folders.
--- emacs/notmuch.el | 11 ++- 1 files changed, 10 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index be09f42..17e0e86 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -696,6 +696,15 @@ characters as well as `_.+-'. (apply 'notmuch-call-notmuch-process tag (append action-split (list notmuch-search-query-string) nil +(defun notmuch-search-buffer-title (query) + Returns the title for a buffer with notmuch search results. + (let ((folder (car (rassoc query notmuch-folders + (if folder + (concat *notmuch-folder- folder *) +(concat *notmuch-search- query *)) + ) +) + ;;;###autoload (defun notmuch-search (query optional oldest-first target-thread target-line) Run \notmuch search\ with the given query string and display results. @@ -708,7 +717,7 @@ The optional parameters are used as follows: target-line: The line number to move to if the target thread does not appear in the search results. (interactive sNotmuch search: ) - (let ((buffer (get-buffer-create (concat *notmuch-search- query * + (let ((buffer (get-buffer-create (notmuch-search-buffer-title query (switch-to-buffer buffer) (notmuch-search-mode) (set 'notmuch-search-query-string query) -- 1.7.0.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: when archiving move the cursor depending on the sort order.
On 14 April 2010 05:53, Sebastian Spaeth wrote: > On 2010-04-14, Michal Sojka wrote: >> On Tue, 13 Apr 2010, Servilio Afre Puentes wrote: >> > The current hardcoded behaviour will not take you to the next unread >> > thread when the sort order is set to newer-first from the default of >> > older-first. >> >> Is this really what we want? If I sort messages by newest first, it >> menas that I want to process my emails from the newest to the oldest. >> I'm satisfied with the current behavour. > > Agreed, I would be very surprised to get a different behavior. Hmmm, interesting. I still want to process my messages from oldest to newest but prefer them to be shown with the newest at the top. I will create and send a second version of the patch later today that takes this into account... Servilio
Re: [PATCH] emacs: when archiving move the cursor depending on the sort order.
On 14 April 2010 05:53, Sebastian Spaeth sebast...@sspaeth.de wrote: On 2010-04-14, Michal Sojka wrote: On Tue, 13 Apr 2010, Servilio Afre Puentes wrote: The current hardcoded behaviour will not take you to the next unread thread when the sort order is set to newer-first from the default of older-first. Is this really what we want? If I sort messages by newest first, it menas that I want to process my emails from the newest to the oldest. I'm satisfied with the current behavour. Agreed, I would be very surprised to get a different behavior. Hmmm, interesting. I still want to process my messages from oldest to newest but prefer them to be shown with the newest at the top. I will create and send a second version of the patch later today that takes this into account... Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Extend the archive function to operate on regions too.
Signed-off-by: Servilio Afre Puentes --- emacs/notmuch.el | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 517c53a..4d4971f 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -264,7 +264,7 @@ For a mouse binding, return nil." (define-key map "f" 'notmuch-search-filter) (define-key map [mouse-1] 'notmuch-search-show-thread) (define-key map "*" 'notmuch-search-operate-all) -(define-key map "a" 'notmuch-search-archive-thread) +(define-key map "a" 'notmuch-search-archive-thread-or-region) (define-key map "-" 'notmuch-search-remove-tag) (define-key map "+" 'notmuch-search-add-tag) (define-key map (kbd "RET") 'notmuch-search-show-thread) @@ -359,7 +359,7 @@ participants in the thread, a representative subject line, and any tags). Pressing \\[notmuch-search-show-thread] on any line displays that thread. The '\\[notmuch-search-add-tag]' and '\\[notmuch-search-remove-tag]' -keys can be used to add or remove tags from a thread. The '\\[notmuch-search-archive-thread]' key +keys can be used to add or remove tags from a thread. The '\\[notmuch-search-archive-thread-or-region]' key is a convenience for archiving a thread (removing the \"inbox\" tag). The '\\[notmuch-search-operate-all]' key can be used to add or remove a tag from all threads in the current buffer. @@ -566,12 +566,12 @@ thread or threads in the current region." (notmuch-search-remove-tag-region tag beg end)) (notmuch-search-remove-tag-thread tag -(defun notmuch-search-archive-thread () - "Archive the currently selected thread (remove its \"inbox\" tag). +(defun notmuch-search-archive-thread-or-region () + "Archive the currently selected thread or region (remove its \"inbox\" tag). This function advances the next thread when finished." (interactive) - (notmuch-search-remove-tag-thread "inbox") + (notmuch-search-remove-tag "inbox") (forward-line)) (defun notmuch-search-process-sentinel (proc msg) -- 1.7.0.4
[PATCH] emacs: when archiving move the cursor depending on the sort order.
The current hardcoded behaviour will not take you to the next unread thread when the sort order is set to newer-first from the default of older-first. Signed-off-by: Servilio Afre Puentes --- emacs/notmuch.el |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 517c53a..728aa2b 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -572,7 +572,9 @@ thread or threads in the current region." This function advances the next thread when finished." (interactive) (notmuch-search-remove-tag-thread "inbox") - (forward-line)) + (if notmuch-search-oldest-first + (forward-line) +(previous-line))) (defun notmuch-search-process-sentinel (proc msg) "Add a message to let user know when \"notmuch search\" exits" -- 1.7.0.4
[PATCH] emacs: when archiving move the cursor depending on the sort order.
The current hardcoded behaviour will not take you to the next unread thread when the sort order is set to newer-first from the default of older-first. Signed-off-by: Servilio Afre Puentes servi...@gmail.com --- emacs/notmuch.el |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 517c53a..728aa2b 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -572,7 +572,9 @@ thread or threads in the current region. This function advances the next thread when finished. (interactive) (notmuch-search-remove-tag-thread inbox) - (forward-line)) + (if notmuch-search-oldest-first + (forward-line) +(previous-line))) (defun notmuch-search-process-sentinel (proc msg) Add a message to let user know when \notmuch search\ exits -- 1.7.0.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Extend the archive function to operate on regions too.
Signed-off-by: Servilio Afre Puentes servi...@gmail.com --- emacs/notmuch.el | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 517c53a..4d4971f 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -264,7 +264,7 @@ For a mouse binding, return nil. (define-key map f 'notmuch-search-filter) (define-key map [mouse-1] 'notmuch-search-show-thread) (define-key map * 'notmuch-search-operate-all) -(define-key map a 'notmuch-search-archive-thread) +(define-key map a 'notmuch-search-archive-thread-or-region) (define-key map - 'notmuch-search-remove-tag) (define-key map + 'notmuch-search-add-tag) (define-key map (kbd RET) 'notmuch-search-show-thread) @@ -359,7 +359,7 @@ participants in the thread, a representative subject line, and any tags). Pressing \\[notmuch-search-show-thread] on any line displays that thread. The '\\[notmuch-search-add-tag]' and '\\[notmuch-search-remove-tag]' -keys can be used to add or remove tags from a thread. The '\\[notmuch-search-archive-thread]' key +keys can be used to add or remove tags from a thread. The '\\[notmuch-search-archive-thread-or-region]' key is a convenience for archiving a thread (removing the \inbox\ tag). The '\\[notmuch-search-operate-all]' key can be used to add or remove a tag from all threads in the current buffer. @@ -566,12 +566,12 @@ thread or threads in the current region. (notmuch-search-remove-tag-region tag beg end)) (notmuch-search-remove-tag-thread tag -(defun notmuch-search-archive-thread () - Archive the currently selected thread (remove its \inbox\ tag). +(defun notmuch-search-archive-thread-or-region () + Archive the currently selected thread or region (remove its \inbox\ tag). This function advances the next thread when finished. (interactive) - (notmuch-search-remove-tag-thread inbox) + (notmuch-search-remove-tag inbox) (forward-line)) (defun notmuch-search-process-sentinel (proc msg) -- 1.7.0.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
please eat my data!
On 12 April 2010 13:47, Dirk Hohndel wrote: > On Mon, 12 Apr 2010 10:14:05 -0700, Stewart Smith flamingspork.com> wrote: >> On Mon, 12 Apr 2010 17:24:35 +0200, "Sebastian Spaeth" > SSpaeth.de> wrote: >> > What I find intersting is that we have a 2x speedup and a 10x speedup >> > for different queries. Olly was saying on IRC that both *should* really be >> > behaving in much the same manner. >> >> Remember that on ext3 (and pretty sure ext4) fsync is the same as >> sync(). So performance depends on how much dirty data you have in your cache. >> >> libeatmydata also gets rid of msync(), O_SYNC etc as well. > > Which is why so many of us have started to use BTRFS... How stable is it now? What kernel version and distro are you using? Servilio
Re: please eat my data!
On 12 April 2010 13:47, Dirk Hohndel hohn...@infradead.org wrote: On Mon, 12 Apr 2010 10:14:05 -0700, Stewart Smith stew...@flamingspork.com wrote: On Mon, 12 Apr 2010 17:24:35 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: What I find intersting is that we have a 2x speedup and a 10x speedup for different queries. Olly was saying on IRC that both *should* really be behaving in much the same manner. Remember that on ext3 (and pretty sure ext4) fsync is the same as sync(). So performance depends on how much dirty data you have in your cache. libeatmydata also gets rid of msync(), O_SYNC etc as well. Which is why so many of us have started to use BTRFS... How stable is it now? What kernel version and distro are you using? Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Remove dangling opening curly bracket.
Signed-off-by: Servilio Afre Puentes
---
notmuch-reply.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 3798d60..8eb4754 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -383,7 +383,7 @@ notmuch_reply_format_default(void *ctx,
notmuch_config_t *config, notmuch_query_
if (from_addr == NULL)
from_addr = guess_from_received_header (config, message);
- if (from_addr == NULL) {
+ if (from_addr == NULL)
from_addr = notmuch_config_get_user_primary_email (config);
from_addr = talloc_asprintf (ctx, "%s <%s>",
--
1.7.0
[PATCH] Remove dangling opening curly bracket.
Signed-off-by: Servilio Afre Puentes servi...@gmail.com
---
notmuch-reply.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 3798d60..8eb4754 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -383,7 +383,7 @@ notmuch_reply_format_default(void *ctx,
notmuch_config_t *config, notmuch_query_
if (from_addr == NULL)
from_addr = guess_from_received_header (config, message);
- if (from_addr == NULL) {
+ if (from_addr == NULL)
from_addr = notmuch_config_get_user_primary_email (config);
from_addr = talloc_asprintf (ctx, %s %s,
--
1.7.0
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)
On 4 February 2010 00:05, martin f krafft wrote: > also sprach Servilio Afre Puentes [2010.02.04.1714 > +1300]: >> In the second link, the links with the text "commitdiff" provide >> it, and you have the Atom and RSS feeds at the bottom. > > As I see it, the feeds have links to the commitdiffs, but that's not > quite the same as having the diffs inline. Oh, diffs inline. [...] > If there is indeed an RSS/Atom feed on gitweb that includes the > diffs inline, please give me the URL; I can't fine ond. Can't see that even in the code. Servilio
[notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)
On 3 February 2010 15:18, martin f krafft wrote: > also sprach Marten Veldthuis [2010.02.04.0353 > +1300]: >> > Like this? http://notmuchmail.org/recentchanges/ >> >> No, more like this: http://git.notmuchmail.org/git/notmuch-wiki > > To my knowledge, neither of these two give you diffs. This is what > a post-receive hook offers. In the second link, the links with the text "commitdiff" provide it, and you have the Atom and RSS feeds at the bottom. Servilio
Re: [notmuch] Git commit mails (was: New wiki instance on the notmuchmail.org website)
On 3 February 2010 15:18, martin f krafft madd...@madduck.net wrote: also sprach Marten Veldthuis mar...@veldthuis.com [2010.02.04.0353 +1300]: Like this? http://notmuchmail.org/recentchanges/ No, more like this: http://git.notmuchmail.org/git/notmuch-wiki To my knowledge, neither of these two give you diffs. This is what a post-receive hook offers. In the second link, the links with the text commitdiff provide it, and you have the Atom and RSS feeds at the bottom. Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Better folder name search strategy.
This allows the use non-word characters (e.g.: "/") as the folder name in the notmuch-folders variable. --- notmuch.el |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/notmuch.el b/notmuch.el index 97914f2..bdb0200 100644 --- a/notmuch.el +++ b/notmuch.el @@ -1467,7 +1467,9 @@ Currently available key bindings: (save-excursion (beginning-of-line) (let ((beg (point))) - (forward-word) + (save-match-data + (re-search-forward "[ \t]" nil t)) + (backward-char) (filter-buffer-substring beg (point) (defun notmuch-folder-show-search ( folder) -- 1.6.5
[notmuch] [PATCH] Better folder name search strategy.
This allows the use non-word characters (e.g.: /) as the folder name in the notmuch-folders variable. --- notmuch.el |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/notmuch.el b/notmuch.el index 97914f2..bdb0200 100644 --- a/notmuch.el +++ b/notmuch.el @@ -1467,7 +1467,9 @@ Currently available key bindings: (save-excursion (beginning-of-line) (let ((beg (point))) - (forward-word) + (save-match-data + (re-search-forward [ \t] nil t)) + (backward-char) (filter-buffer-substring beg (point) (defun notmuch-folder-show-search (optional folder) -- 1.6.5 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] tag dir proposal [was: Re: Git as notmuch object store]
2010/1/28 martin f krafft : > also sprach Jameson Rollins [2010.01.26.1046 > +1300]: >> > For example, I might have: >> > >> > ~/.notmuch-config: >> > >> > ? ? [database] >> > ? ? path=/home/pioto/mail >> > ? ? ... >> > ? ? [tags] >> > ? ? pioto at pioto.org/INBOX.ListMail.notmuch = notmuch >> > >> > So, a 'tags' section, where each key is the folder name, relative to the >> > db path, and the value is one or more tag names >> >> I think this idea is a really good one and I would like to pursue it as >> a tangent thread here. ?I was going to propose something very similar to >> this. ?I think it's a very flexible idea that would help in a lot of >> ways. > > I think we need to carefully distinguish here. The above seems to > suggest a mapping from folder to tag, but we don't actually need > tags for folder locations because those can (and should) be implicitly > determined from the database I think that the usefulness of this functionality is that we can have a mapping from physical organization of the mail to a tagging scheme of our choosing, and we can be relieved from having to remember the location of the mail (that can be different in different from different mail clients). But even right now I can't find a documented way of searching by location, so AFAIK the implementation of this proposal would allow something that is not possible at the moment. >> [tags] >> inbox = +inbox,+unread >> sent = +sent >> drafts = +draft >> archive = -inbox > > This proposal, on the other hand, is an interesting one, but when is > it supposed to happen? It just feels wrong to make this happen as > part of 'notmuch new'. Why so? > What I would like to see is a notmuch-aware MDA, e.g. a programme > which reads an incoming mail on stdin and can do all this kind of > stuff, e.g. assign tags based on such rules (or take tags as > arguments, so that I could trivially set tags from procmail too), > write the message to the message store, and update the database. Such an MDA wouldn't need to use "notmuch new", and thus won't be affected by this > This would allow us to get rid of 'notmuch new' altogether, at least > conceptually. We'd still need it if mail is being delivered > independently, e.g. with offlineimap. Then we'd still need it, why not make it better? Regards, Servilio
Re: [notmuch] tag dir proposal [was: Re: Git as notmuch object store]
2010/1/28 martin f krafft madd...@madduck.net: also sprach Jameson Rollins jroll...@finestructure.net [2010.01.26.1046 +1300]: For example, I might have: ~/.notmuch-config: [database] path=/home/pioto/mail ... [tags] pi...@pioto.org/INBOX.ListMail.notmuch = notmuch So, a 'tags' section, where each key is the folder name, relative to the db path, and the value is one or more tag names I think this idea is a really good one and I would like to pursue it as a tangent thread here. I was going to propose something very similar to this. I think it's a very flexible idea that would help in a lot of ways. I think we need to carefully distinguish here. The above seems to suggest a mapping from folder to tag, but we don't actually need tags for folder locations because those can (and should) be implicitly determined from the database I think that the usefulness of this functionality is that we can have a mapping from physical organization of the mail to a tagging scheme of our choosing, and we can be relieved from having to remember the location of the mail (that can be different in different from different mail clients). But even right now I can't find a documented way of searching by location, so AFAIK the implementation of this proposal would allow something that is not possible at the moment. [tags] inbox = +inbox,+unread sent = +sent drafts = +draft archive = -inbox This proposal, on the other hand, is an interesting one, but when is it supposed to happen? It just feels wrong to make this happen as part of 'notmuch new'. Why so? What I would like to see is a notmuch-aware MDA, e.g. a programme which reads an incoming mail on stdin and can do all this kind of stuff, e.g. assign tags based on such rules (or take tags as arguments, so that I could trivially set tags from procmail too), write the message to the message store, and update the database. Such an MDA wouldn't need to use notmuch new, and thus won't be affected by this This would allow us to get rid of 'notmuch new' altogether, at least conceptually. We'd still need it if mail is being delivered independently, e.g. with offlineimap. Then we'd still need it, why not make it better? Regards, Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Introducing notmuchsync
2010/1/19 Jameson Rollins : [...] > That said, I have vasilated just a bit on this, as to whether notmuch > should touch the mail at all, or just process it. ?But having thought > about it a bit, I think that notmuch really *is* an MUA, or at least > the mail processing part of a MUA (MUA minus message reader), and > should therefore do the appropriate things with the maildir. I on the other hand think that it is just the indexer, and that the right way to integrate it into a MUA is by making this MUA call notmuch to update the DB/index with the actions just performed on a message/group of messages (moving, deleting, tagging, etc.). For what I've read so far from messages of the authors in this mailing list and the programmed behaviour, I think that is the intention (though not fully implemented yet) and in my opinion the right one. Maybe if the notmuch.el code would have been written as a set of hooks into Gnus for customizing views this would have been more evident (though I haven't neither used or looked at the vim front-end code), or maybe I am missing the point entirely and the long-term goal of the authors is to have a full-fledged MUA. Regards, Servilio
[notmuch] Joining
Maybe a bit late for saying Hi, glad to join! since I have already sent another message, but yesterday was a long day at work. I also knew about notmuch from the LWN article back in December and have been following it through the git update and the mail archive since then (though not reading all messages neither all the code). I am also very glad of something like this having been created and look forward to help enhance it and use it more extensively (right now I am trying to get the Gnus bit in place). Regards, Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
