[PATCH] Restore original keybinding ('r' = reply-to-all)
On Wed, 27 Jun 2012 10:55:53 -0700, Jameson Graef Rollins wrote: > On Wed, Jun 27 2012, Carl Worth wrote: > > Since the beginning of time, the emacs interface provided a keybinding > > of 'r' to reply to a message, (and originally, all recipients). > > > > Then, before release 0.12 the emacs interface acquired a new > > reply-to-sender only feature. In commit > > f02b475fa781bb5df3358c73213e7633a99f016e the new feature was put onto > > the original keybinding, (and reply-to-all was moved to 'R'). > > > > This restores the original keybinding and uses the new keybinding for > > the new feature. My bias is probably apparent in that I pushed the original patch... I think the there is potential for unfortunate mistakes with either set of bindings. On the one hand sending replies to unintended people can be very embarrassing. On the other hand, forgetting to reply to the group can also be problematic. The latter is easier to correct, _if_ it is detected. When we discussed this earlier, there were people who supported both options as default. I broke the tie based on my experience with other mailers, and the fact that apparently I worry more about sending things to too many people than to too few. Obviously Carl would have chosen differently. It would be easy enough to add a customization variable to swap the outcomes of r and R; iirc this is what wanderlust (or maybe VM) does. It seems that would not really make people any happier, since the complaint is not that it is hard to do the keybindings, but that the bindings changed. I do worry that by changing back, we annoy a whole new set of people. I'm not worried for myself; I can add the equivalent keybindings to my .emacs. I do (hypothetically) sympathize with people who just got used to the new behaviour and are surprised again. Anyway, if there is consensus that changing back is the right thing to do, then I can live with that. d
[PATCH] Restore original keybinding ('r' = reply-to-all)
On Wed, 27.06.2012 19:55, Jameson Graef Rollins wrote: > I actually rebound these keys immediately after the release, so I'm > perfectly happy to change back. Same here. I think the ratio of cases where I wanted to reply to all participants instead compared to just to the sender is something like 10:1. Moreover, it's significantly easier to just remove recipients from the headers than adding them, since one may no longer know who they are after pressing reply, for example in big threads on mailing lists. So these are my bikeshedding arguments for this change, but the last point is not _that_ subjective, I hope. Cheers, Daniel -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120627/e44dd922/attachment.pgp>
[PATCH] Restore original keybinding ('r' = reply-to-all)
On Wed, Jun 27 2012, Carl Worth wrote: > Since the beginning of time, the emacs interface provided a keybinding > of 'r' to reply to a message, (and originally, all recipients). > > Then, before release 0.12 the emacs interface acquired a new > reply-to-sender only feature. In commit > f02b475fa781bb5df3358c73213e7633a99f016e the new feature was put onto > the original keybinding, (and reply-to-all was moved to 'R'). > > This restores the original keybinding and uses the new keybinding for > the new feature. I actually rebound these keys immediately after the release, so I'm perfectly happy to change back. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20120627/057abcdc/attachment.pgp>
[RFC PATCH 00/14] modular mail stores based on URIs
Hi On Mon, 25 Jun 2012, Ethan Glasser-Camp wrote: > Hi guys, > > Sorry for dropping off the mailing list after I sent my last patch > series (http://notmuchmail.org/pipermail/notmuch/2012/009470.html). I > haven't had the time or a stable enough email address to really follow > notmuch development :) > > I signed onto #notmuch a week or two ago and asked what I would need > to do to get a feature like this one into mainline. j4ni told me that > he agreed with the feedback to my original patch series, and suggested > that I follow mjw1009's advice of having filenames encode all > information about mail storage transparently, and that this would > solve the problem with the original patch series of sprinkling mail > storage parameters all over the place. bremner suggested that he had > been thinking about how to support mbox or other multiple-message > archives, and also commented that he wasn't crazy about so much of the > API being in strings. > > Based on this advice, I decided to revise my approach to this > patchset, one that is based around the stated desire to work with mbox > formats. This approach, in contrast to the mailstore approach that > Michal Sojka proposed and I revised, encodes all mail access > information as URIs. These URIs are stored in Xapian the way that > relative paths are right now. Examples might be: > > maildir:///home/ethan/Mail/folder/cur/filename:2,S > mbox:///home/ethan/Mail/folder/file.mbox#byte-offset+lenght > couchdb://ethan:password at localhost:8080/some-doc-id First, thank you for resubmitting this: it is definitely a feature I would like to see in notmuch. And at a first glance I like the series (and I will try and review it over the next few days). > Personally, this isn't my favorite approach, for the following reasons: > > 1. Notmuch, at some point in its history, chose to store file paths > relative to a "mail database", with the intent that if this mail > database was moved, filenames would not change and everything would > Just Work (tm). The above scheme completely reverses this design > decision, and in general completely breaks this relocatability. I > don't see any easy way to handle this problem. This isn't just a > wishlist feature; at least two things in the test suite (caching of > corpus.mail, and the atomicity tests) rely on this behavior. Why can't the URI just store a relative path, at least for maildir:// and mbox:// ? It is purely internal to notmuch so it doesn't need to be very standard. > 2. Mail access information, i.e. open connections, etc. can only be > stored in variables global to the mailstore code, and cannot be stored > as private members of a mailstore object. This is more an aesthetic > concern than a functional one. > > Anyhow, the following (enormous) patch series implement this design. I > used uriparser as an external library to parse URIs. The API for this > library is a little idiosyncratic. uriparser supports parsing Unicode > URIs (strings of wchar_t), but I just used ASCII filenames because I > think that's what comes out of Xapian. Why use a library? Isn't it just a question of does the string contain // and, if so, splitting it? I guess that // is a nice separator as I think we can assume that a true path does not contain it (since a filename cannot contain /). > Patch 11 is borrowed directly from the last patch series. > > The last four or five patches add mbox support, including a few > tests. That part of the series is still very first-draft: I added a > new config option to specify URIs to scan, and ">From " lines still > need to be unescaped. However, we support scanning mbox files whether > messages have content-length or not. I have an idea that mbox byte-locations change when messages are marked as read (amongst other things). It might be worth saying that this initial implementation only works for unchanging mboxs (rather than the append only condition that you currently say). But I have not got as far as applying/testing the series yet. > I will try to receive feedback on this series more gratefully than the > last one. :) Just to say all of the above are genuine questions (not requests for you to rewrite stuff!) to try and understand the series. Best wishes Mark
[PATCH] Restore original keybinding ('r' = reply-to-all)
Since the beginning of time, the emacs interface provided a keybinding of 'r' to reply to a message, (and originally, all recipients). Then, before release 0.12 the emacs interface acquired a new reply-to-sender only feature. In commit f02b475fa781bb5df3358c73213e7633a99f016e the new feature was put onto the original keybinding, (and reply-to-all was moved to 'R'). This restores the original keybinding and uses the new keybinding for the new feature. --- The commit message above motivates this change from the point of view of interface compatibility. That argument would have been stronger if I had made it in January, (at the time of the change), rather than now, (since there's now a new incompatiblity made by changing things back). That said, I still think the compatibility argument is sound. I have other feelings as to which reply behavior should be treated preferentially. But those are potentially more controversial, so I'll leave the bikeshedding out of our commit history. Thanks to everyone keeping notmuch alive and well during my extended absence from maintainership. What a tremendous free-software success story this all is. I'm so grateful to all of you. -Carl emacs/notmuch-show.el |4 ++-- emacs/notmuch.el |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 4349836..399a8bd 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1145,8 +1145,8 @@ reset based on the original query." (define-key map "s" 'notmuch-search) (define-key map "m" 'notmuch-mua-new-mail) (define-key map "f" 'notmuch-show-forward-message) - (define-key map "r" 'notmuch-show-reply-sender) - (define-key map "R" 'notmuch-show-reply) + (define-key map "r" 'notmuch-show-reply) + (define-key map "R" 'notmuch-show-reply-sender) (define-key map "|" 'notmuch-show-pipe-message) (define-key map "w" 'notmuch-show-save-attachments) (define-key map "V" 'notmuch-show-view-raw-message) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index c6236db..3a6b025 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -215,8 +215,8 @@ For a mouse binding, return nil." (define-key map ">" 'notmuch-search-last-thread) (define-key map "p" 'notmuch-search-previous-thread) (define-key map "n" 'notmuch-search-next-thread) -(define-key map "r" 'notmuch-search-reply-to-thread-sender) -(define-key map "R" 'notmuch-search-reply-to-thread) +(define-key map "r" 'notmuch-search-reply-to-thread) +(define-key map "R" 'notmuch-search-reply-to-thread-sender) (define-key map "m" 'notmuch-mua-new-mail) (define-key map "s" 'notmuch-search) (define-key map "o" 'notmuch-search-toggle-order) -- 1.7.10
Re: [RFC PATCH 00/14] modular mail stores based on URIs
Hi On Mon, 25 Jun 2012, Ethan Glasser-Camp ethan.glasser.c...@gmail.com wrote: Hi guys, Sorry for dropping off the mailing list after I sent my last patch series (http://notmuchmail.org/pipermail/notmuch/2012/009470.html). I haven't had the time or a stable enough email address to really follow notmuch development :) I signed onto #notmuch a week or two ago and asked what I would need to do to get a feature like this one into mainline. j4ni told me that he agreed with the feedback to my original patch series, and suggested that I follow mjw1009's advice of having filenames encode all information about mail storage transparently, and that this would solve the problem with the original patch series of sprinkling mail storage parameters all over the place. bremner suggested that he had been thinking about how to support mbox or other multiple-message archives, and also commented that he wasn't crazy about so much of the API being in strings. Based on this advice, I decided to revise my approach to this patchset, one that is based around the stated desire to work with mbox formats. This approach, in contrast to the mailstore approach that Michal Sojka proposed and I revised, encodes all mail access information as URIs. These URIs are stored in Xapian the way that relative paths are right now. Examples might be: maildir:///home/ethan/Mail/folder/cur/filename:2,S mbox:///home/ethan/Mail/folder/file.mbox#byte-offset+lenght couchdb://ethan:password@localhost:8080/some-doc-id First, thank you for resubmitting this: it is definitely a feature I would like to see in notmuch. And at a first glance I like the series (and I will try and review it over the next few days). Personally, this isn't my favorite approach, for the following reasons: 1. Notmuch, at some point in its history, chose to store file paths relative to a mail database, with the intent that if this mail database was moved, filenames would not change and everything would Just Work (tm). The above scheme completely reverses this design decision, and in general completely breaks this relocatability. I don't see any easy way to handle this problem. This isn't just a wishlist feature; at least two things in the test suite (caching of corpus.mail, and the atomicity tests) rely on this behavior. Why can't the URI just store a relative path, at least for maildir:// and mbox:// ? It is purely internal to notmuch so it doesn't need to be very standard. 2. Mail access information, i.e. open connections, etc. can only be stored in variables global to the mailstore code, and cannot be stored as private members of a mailstore object. This is more an aesthetic concern than a functional one. Anyhow, the following (enormous) patch series implement this design. I used uriparser as an external library to parse URIs. The API for this library is a little idiosyncratic. uriparser supports parsing Unicode URIs (strings of wchar_t), but I just used ASCII filenames because I think that's what comes out of Xapian. Why use a library? Isn't it just a question of does the string contain // and, if so, splitting it? I guess that // is a nice separator as I think we can assume that a true path does not contain it (since a filename cannot contain /). Patch 11 is borrowed directly from the last patch series. The last four or five patches add mbox support, including a few tests. That part of the series is still very first-draft: I added a new config option to specify URIs to scan, and From lines still need to be unescaped. However, we support scanning mbox files whether messages have content-length or not. I have an idea that mbox byte-locations change when messages are marked as read (amongst other things). It might be worth saying that this initial implementation only works for unchanging mboxs (rather than the append only condition that you currently say). But I have not got as far as applying/testing the series yet. I will try to receive feedback on this series more gratefully than the last one. :) Just to say all of the above are genuine questions (not requests for you to rewrite stuff!) to try and understand the series. Best wishes Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Restore original keybinding ('r' = reply-to-all)
Since the beginning of time, the emacs interface provided a keybinding of 'r' to reply to a message, (and originally, all recipients). Then, before release 0.12 the emacs interface acquired a new reply-to-sender only feature. In commit f02b475fa781bb5df3358c73213e7633a99f016e the new feature was put onto the original keybinding, (and reply-to-all was moved to 'R'). This restores the original keybinding and uses the new keybinding for the new feature. --- The commit message above motivates this change from the point of view of interface compatibility. That argument would have been stronger if I had made it in January, (at the time of the change), rather than now, (since there's now a new incompatiblity made by changing things back). That said, I still think the compatibility argument is sound. I have other feelings as to which reply behavior should be treated preferentially. But those are potentially more controversial, so I'll leave the bikeshedding out of our commit history. Thanks to everyone keeping notmuch alive and well during my extended absence from maintainership. What a tremendous free-software success story this all is. I'm so grateful to all of you. -Carl emacs/notmuch-show.el |4 ++-- emacs/notmuch.el |4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 4349836..399a8bd 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1145,8 +1145,8 @@ reset based on the original query. (define-key map s 'notmuch-search) (define-key map m 'notmuch-mua-new-mail) (define-key map f 'notmuch-show-forward-message) - (define-key map r 'notmuch-show-reply-sender) - (define-key map R 'notmuch-show-reply) + (define-key map r 'notmuch-show-reply) + (define-key map R 'notmuch-show-reply-sender) (define-key map | 'notmuch-show-pipe-message) (define-key map w 'notmuch-show-save-attachments) (define-key map V 'notmuch-show-view-raw-message) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index c6236db..3a6b025 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -215,8 +215,8 @@ For a mouse binding, return nil. (define-key map 'notmuch-search-last-thread) (define-key map p 'notmuch-search-previous-thread) (define-key map n 'notmuch-search-next-thread) -(define-key map r 'notmuch-search-reply-to-thread-sender) -(define-key map R 'notmuch-search-reply-to-thread) +(define-key map r 'notmuch-search-reply-to-thread) +(define-key map R 'notmuch-search-reply-to-thread-sender) (define-key map m 'notmuch-mua-new-mail) (define-key map s 'notmuch-search) (define-key map o 'notmuch-search-toggle-order) -- 1.7.10 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Restore original keybinding ('r' = reply-to-all)
On Wed, Jun 27 2012, Carl Worth cwo...@cworth.org wrote: Since the beginning of time, the emacs interface provided a keybinding of 'r' to reply to a message, (and originally, all recipients). Then, before release 0.12 the emacs interface acquired a new reply-to-sender only feature. In commit f02b475fa781bb5df3358c73213e7633a99f016e the new feature was put onto the original keybinding, (and reply-to-all was moved to 'R'). This restores the original keybinding and uses the new keybinding for the new feature. I actually rebound these keys immediately after the release, so I'm perfectly happy to change back. jamie. pgpFQB7hO8uxR.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Restore original keybinding ('r' = reply-to-all)
On Wed, 27.06.2012 19:55, Jameson Graef Rollins wrote: I actually rebound these keys immediately after the release, so I'm perfectly happy to change back. Same here. I think the ratio of cases where I wanted to reply to all participants instead compared to just to the sender is something like 10:1. Moreover, it's significantly easier to just remove recipients from the headers than adding them, since one may no longer know who they are after pressing reply, for example in big threads on mailing lists. So these are my bikeshedding arguments for this change, but the last point is not _that_ subjective, I hope. Cheers, Daniel pgpMEJRTU1r5g.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Restore original keybinding ('r' = reply-to-all)
On Wed, 27 Jun 2012 10:55:53 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: On Wed, Jun 27 2012, Carl Worth cwo...@cworth.org wrote: Since the beginning of time, the emacs interface provided a keybinding of 'r' to reply to a message, (and originally, all recipients). Then, before release 0.12 the emacs interface acquired a new reply-to-sender only feature. In commit f02b475fa781bb5df3358c73213e7633a99f016e the new feature was put onto the original keybinding, (and reply-to-all was moved to 'R'). This restores the original keybinding and uses the new keybinding for the new feature. My bias is probably apparent in that I pushed the original patch... I think the there is potential for unfortunate mistakes with either set of bindings. On the one hand sending replies to unintended people can be very embarrassing. On the other hand, forgetting to reply to the group can also be problematic. The latter is easier to correct, _if_ it is detected. When we discussed this earlier, there were people who supported both options as default. I broke the tie based on my experience with other mailers, and the fact that apparently I worry more about sending things to too many people than to too few. Obviously Carl would have chosen differently. It would be easy enough to add a customization variable to swap the outcomes of r and R; iirc this is what wanderlust (or maybe VM) does. It seems that would not really make people any happier, since the complaint is not that it is hard to do the keybindings, but that the bindings changed. I do worry that by changing back, we annoy a whole new set of people. I'm not worried for myself; I can add the equivalent keybindings to my .emacs. I do (hypothetically) sympathize with people who just got used to the new behaviour and are surprised again. Anyway, if there is consensus that changing back is the right thing to do, then I can live with that. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
