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
[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
