[PATCH] emacs: Add notmuch-before/after-tag-hook
address completion when composing
On Thu, 12 May 2011 00:38:20 -0700, Jameson Graef Rollins wrote: > On Thu, 12 May 2011 02:04:41 +0200, Florian Friesdorf > wrote: > > 1. store to/cc/bcc in xapian > > Hey, Florian. I think all of these fields are actually already stored > in the database. No, just the terms are, not the full string. (although for search, that could actually be enough) Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/cc19b54f/attachment.pgp>
Multiple sender identities (composing)
Jameson Graef Rollins writes: > This is great, guys. I've been wanting to get something like this > working for a while now. Agreed. Would be awesome if someone could post it to the Wiki...
Header and other questions
Jameson Graef Rollins writes: > On Mon, 16 May 2011 11:27:52 -0400, Jesse Rosenthal > wrote: >> The decision, if I remember correctly, was that regions are so intuitive >> for emacs users, and many people reported trying to tag by region >> without thinking about it, that this approach would make sense for the >> emacs interface. In other words, keep the emacs interface emacsy. I >> think I still agree with that, since I feel like having both would be >> confusing (what do you do when you select a marked-line in a region?) >> and I like the one I tend toward intuitively. But I certainly see the >> benefit of the other functionality as well. > > I should mention that in my experience it's usually not that hard to > construct searches (or filters on searches) that pair down to just the > messages you want to tag, in which case you can just tag the entire > buffer. I guess so. I still haven't really switched to notmuch for real mail so I have little experience. I don't quite remember why I would have found it handy when I wrote it, but it was while I was busy experimenting with tagging my existing archive.
Multiple sender identities (composing)
On Mon, 16 May 2011 09:52:32 -0700, Jameson Graef Rollins wrote: > On Mon, 16 May 2011 11:52:43 +0200, Thomas Jost > wrote: > > On Mon, 16 May 2011 19:29:07 +1000, Stewart Smith > flamingspork.com> wrote: > > > Thought I'd share this bit of my .emacs snippet that may be useful to go > > > on the emacs tips page. > > > > > > This does the following: > > > - sets up a list of possible identities to have mail From > > > - on composing mail, it prompts you for who you want to send mail from > > > - pressing enter will give you the default (first in the list) > > > - otherwise you have tab completion > > This is great, guys. I've been wanting to get something like this > working for a while now. > > Have you guys looked at home message-mode does bbdb address completion > in the To: and From: headers? It has the nice benefit of being able to > tab through all full addresses for a bbdb entry. It would be nice to > have this function fill in a default address, with the cursor at the end > of the address, and then just tab through all the options without having > to type in anything. ido is pretty cool, though, and accomplishes a > similar effect. I don't know much about bbdb; right now I'm completing addresses with notmuch-address.el and a little Python script that I wrote [1]. It can complete the From header too, although I had never tried that before writing this mail :) > It would be nice to pull the addresses from the notmuch config, eg: > > notmuch config get user.primary_email > notmuch config get user.other_email Nice idea, I like that. However this way you can only get the address part, not the username part. And when using some addresses I want to put a nickname instead of my full name, so just using a default user name is not very convenient. Or is it possible to put things like "User Name " in the notmuch config? > I would ideally like to be able to choose the From: address right before > sending, as opposed to right before composing. Has anyone tried to get > that working? I was not having much luck with send-hooks, since it > looks like it expects the message to be complete at that point. I haven't tried that, but it would indeed be nice to be able to do that at send time. The message-seend-hook doc states that "this hook is run quite early when sending", so I would expect that to be the best solution. However, if for some reason it doesn't work, it's probably possible to write a little function around message-send (...or even to advise it) to do whatever you want before it is actually executed. I'll try to have a look at this tomorrow. Regards, Thomas [1] https://github.com/Schnouki/dotfiles/blob/master/notmuch/addrbook.py -- Thomas/Schnouki -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/a28dee05/attachment.pgp>
Multiple sender identities (composing)
Thought I'd share this bit of my .emacs snippet that may be useful to go on the emacs tips page. This does the following: - sets up a list of possible identities to have mail From - on composing mail, it prompts you for who you want to send mail from - pressing enter will give you the default (first in the list) - otherwise you have tab completion You may also want to set this: '(message-sendmail-envelope-from (quote header)) (in custom-set-variables) so that if you're doing postfix sender based routing or the like, it gets the correct address and doesn't end up sending things the wrong way. (setq stewart/mua-identities (list "Stewart Smith " "Stewart Smith ")) (defun stewart/notmuch-mua-mail ( from) (interactive) (setq from (completing-read "Sender identity: " stewart/mua-identities nil t nil nil (car stewart/mua-identities))) (notmuch-mua-mail nil nil (list (cons 'from from (define-key notmuch-show-mode-map "m" (lambda () "send email" (interactive) (stewart/notmuch-mua-mail))) (define-key notmuch-search-mode-map "m" (lambda () "send email" (interactive) (stewart/notmuch-mua-mail))) -- Stewart Smith
Multiple sender identities (composing)
Jameson Graef Rollins wrote at 2011-05-16 11:52 -0500: > This is great, guys. I've been wanting to get something like this > working for a while now. Yes; thanks Stewart, Thomas. This is one thing that has slowed my transition to notmuch (from Mutt). Perhaps some of this or links to it could be added to the wiki? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/7c0547fb/attachment.pgp>
MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 15:37:49 -0700, Jameson Graef Rollins wrote: > See mml-secure-message-sign-pgpmime to sign an entire message, as > opposed to just a single part. Thanks! That's good to know. (Trying here.) > I think the two paths reconverge later in the series. Can you look > ahead a bit to see if that concern is addressed? Daniel did point me to later in the series where the numbers are at least the same in text and json output. I've grabbed that state for generating a test case, (also with Daniels test message). And I'm now cooking up a new commit that will pass that test but with less code duplication than the current patch. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/38c88847/attachment.pgp>
address completion when composing
On Mon, 16 May 2011 22:04:42 +0200, Sebastian Spaeth wrote: > No, just the terms are, not the full string. (although for search, that > could actually be enough) Right. It's easy enough to search on the "To:" field. But for address completion, I think we realyl will want to fix the database to store complete names+addresses that can be recovered for messages matching a search. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/6f7231d1/attachment-0001.pgp>
MIME restructuring [was: Re: release-candidate/0.6]
On 05/16/2011 05:20 PM, Carl Worth wrote: > Interestingly, this is not quite the behavior I get (with commit > 373f352). With --format=text I'm now seeing: > > 2) C > 3) D > 4) E --format=text should only show the parts that are readable in text. the ultimate goal is to get the part numbers aligned across all --format choices, regardless of the ability of the format to show the actual nesting. > So that explains some of my confusion. The behavioral change of this > commit is really only impacting the json format, and not the text. That > wasn't clear from the commit message (and I had only been doing my > testing with the text backend). It should ultimately affect the numbering in all parts. There's no way for the text part to do anything like the nesting that we're doing in json, though, due to the output format. > This seems to be justifying my fears about the code duplication---the > two code paths are already divergent, (which means that things like > notmuch part-number identifiers cannot be used between the different > formats). I'd like to fix that by preventing the code duplication. > > Also, both paths seem to be suffering from some excess part-number > incrementing somewhere. The confusions you outline were fixed (by me, iirc) somewhere later in the crypto tree. I did not want to tamper with dme's crypto branch directly (though i now suspect that's what i should have done). i'd give you a commit ID, but i suspect you're sufficiently rebased that this wouldn't be helpful. --dkg -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/444e1751/attachment.pgp>
Header and other questions
On Sun, 15 May 2011 18:16:31 -0400, Jesse Rosenthal wrote: > It's possible, and works the way you'd think it would -- just select a > bunch of threads in the search list, and then tag them. It will apply > the tag to the messages in the region. (In fact, tagging a single thread > is just a special case of this, with a one-line region.) I think this is only a subset of the requested functionality, since one can only tag consecutive threads at once. -- 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/20110516/d11ad892/attachment.pgp>
MIME restructuring [was: Re: release-candidate/0.6]
On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote: > So a message like this: > > A???multipart/signed 355339 bytes > B ???multipart/mixed 353462 bytes > C ???text/plain 235 bytes > D ???image/jpeg attachment [foo.jpg] 352752 bytes > E ??application/pgp-signature attachment [signature.asc] 1030 bytes > > would come out with three parts: > > 1) C > 2) D > 3) E > > the new code assigns this message to 5 parts: > > 1) A > 2) B > 3) C > 4) D > 5) E This message should itself be a comparably complex message, with a tiny attached image of a geek with a bike. Feel free to use this in the test suite (the picture and this message are hereby released under the same license as notmuch itself). Note that if the mailing list attaches a footer, the MIME tree will be even more delightfully complicated, for added fun and games. --dkg -- next part -- A non-text attachment was scrubbed... Name: dkg-tiny.png Type: image/png Size: 15893 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/4703788b/attachment-0001.png> -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/4703788b/attachment-0001.pgp>
MIME restructuring [was: Re: release-candidate/0.6]
On 05/16/2011 04:42 PM, Carl Worth wrote: > Meanwhile, I still can't tell exactly what the behavioral change > intended is. The commit message talks about "fully recursing" > and "match[ing] the MIME structure of the message". Was it not > fully recursing before? In what way did the output not match the > MIME structure before? before, the output was a linearized version of the mime tree, in particular removing the multipart pieces and only enumerating the leaves in a depth-first walk of the tree. So a message like this: A???multipart/signed 355339 bytes B ???multipart/mixed 353462 bytes C ???text/plain 235 bytes D ???image/jpeg attachment [foo.jpg] 352752 bytes E ??application/pgp-signature attachment [signature.asc] 1030 bytes would come out with three parts: 1) C 2) D 3) E the new code assigns this message to 5 parts: 1) A 2) B 3) C 4) D 5) E This change is critical to be able to properly delineate which parts of a message were signed and/or encrypted. hth, --dkg -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1030 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/6dc1c7cd/attachment.pgp>
[RFC/PATCH] Vim client rewrite
On Mon, 16 May 2011 14:36:07 +0300, Felipe Contreras wrote: > On Sun, May 15, 2011 at 10:15 PM, wrote: > > my attempts to make the vim client more usable somehow spiraled out of > > control and turned into a huge rewrite. The intermediate results I > > hereby present for your amusement and comments. > > (attached as whole files, since the patch would be unreadable) > > > > The main point of the rewrite is splitting of a large part of the code > > into Python. This should have the following advantages: > > 1) python-notmuch bindings can be used, which should allow for cleaner > > ? and more reliable code than running the binary and parsing its output > > ? with regexps. > > ? (also provides a nice use case for python-notmuch) > > 2) Python's huge standard library makes implementing some features MUCH > > easier. > > 3) More people know Python than vimscript, thus making the client > > ? development easier > > > > The code is ? quality, but should be close to usable. > > It already has some features not present in the mainline vim client, > > like attachments (viewing and sending, saving to file should be trivial > > to add, will be done when I have some time), better support for unicode > > and more. > > > > Some UI features from the mainline versions that I didn't use were > > removed and customization options are somewhat lacking atm. This is of > > course to be improved later, depending on the responses. > > > > Comments, bugreports and fixes very much welcome. > > Do you have a git repo where to fetch these changes? Or can you > provide a series of patches with 'git format-patch'? > Ah right, forgot to mention it. git://git.khirnov.net/git/notmuch branch vim. -- Anton Khirnov
MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 14:20:07 -0700, Carl Worth wrote: > I'll have to learn better how to control the emacs mail composer in > order to understand how to get signatures to cover attachments if I want > to do that kind of thing. See mml-secure-message-sign-pgpmime to sign an entire message, as opposed to just a single part. > This seems to be justifying my fears about the code duplication---the > two code paths are already divergent, (which means that things like > notmuch part-number identifiers cannot be used between the different > formats). I'd like to fix that by preventing the code duplication. > > Also, both paths seem to be suffering from some excess part-number > incrementing somewhere. I think the two paths reconverge later in the series. Can you look ahead a bit to see if that concern is addressed? 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/20110516/1cf51c2e/attachment.pgp>
[RFC/PATCH] Vim client rewrite
On Sun, May 15, 2011 at 10:15 PM, wrote: > my attempts to make the vim client more usable somehow spiraled out of > control and turned into a huge rewrite. The intermediate results I > hereby present for your amusement and comments. > (attached as whole files, since the patch would be unreadable) > > The main point of the rewrite is splitting of a large part of the code > into Python. This should have the following advantages: > 1) python-notmuch bindings can be used, which should allow for cleaner > ? and more reliable code than running the binary and parsing its output > ? with regexps. > ? (also provides a nice use case for python-notmuch) > 2) Python's huge standard library makes implementing some features MUCH > easier. > 3) More people know Python than vimscript, thus making the client > ? development easier > > The code is ? quality, but should be close to usable. > It already has some features not present in the mainline vim client, > like attachments (viewing and sending, saving to file should be trivial > to add, will be done when I have some time), better support for unicode > and more. > > Some UI features from the mainline versions that I didn't use were > removed and customization options are somewhat lacking atm. This is of > course to be improved later, depending on the responses. > > Comments, bugreports and fixes very much welcome. Do you have a git repo where to fetch these changes? Or can you provide a series of patches with 'git format-patch'? -- Felipe Contreras
MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor wrote: > So a message like this: > > A???multipart/signed 355339 bytes > B ???multipart/mixed 353462 bytes > C ???text/plain 235 bytes > D ???image/jpeg attachment [foo.jpg] 352752 bytes > E ??application/pgp-signature attachment [signature.asc] 1030 bytes I tried creating a message like that but mine came out slightly differently: > A???multipart/mixed > B ???multipart/signed > C ???text/plain > D ???application/pgp-signature > E ??application/octet-stream I'll have to learn better how to control the emacs mail composer in order to understand how to get signatures to cover attachments if I want to do that kind of thing. > would come out with three parts: > > 1) C > 2) D > 3) E That is indeed the behavior I see with master (for both text and json output). > the new code assigns this message to 5 parts: > > 1) A > 2) B > 3) C > 4) D > 5) E Interestingly, this is not quite the behavior I get (with commit 373f352). With --format=text I'm now seeing: 2) C 3) D 4) E and with --format=json I'm seeing (I think this structure is right): 1) A 3) B 5) C 7) D 9) E So that explains some of my confusion. The behavioral change of this commit is really only impacting the json format, and not the text. That wasn't clear from the commit message (and I had only been doing my testing with the text backend). This seems to be justifying my fears about the code duplication---the two code paths are already divergent, (which means that things like notmuch part-number identifiers cannot be used between the different formats). I'd like to fix that by preventing the code duplication. Also, both paths seem to be suffering from some excess part-number incrementing somewhere. All of this should be easy to get right with a careful test case or two. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/73d64505/attachment.pgp>
MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor wrote: > before, the output was a linearized version of the mime tree, in > particular removing the multipart pieces and only enumerating the leaves > in a depth-first walk of the tree. > > So a message like this: [snip example of change] Thanks, Daniel! That does make things much more clear. So what I'd love to see from here is a commit with a description like the above, and then a test case looking like your example.
release-candidate/0.6
On Fri, 13 May 2011 01:07:08 -0700, Jameson Graef Rollins wrote: > Hi, Carl. I went through dme's multipart patch series and cleaned > things up. ... > The result is the new > > release-candidate/0.6+mpmfix Thanks so much! This looks much better than before. I'm still hitting some snags quite early in the review process, (I'm hoping that real soon we'll be able to just start merging like crazy). Here at the things I've seen so far: d3e7415d "add argument to part format function to indicate initial part" This one fails to build due to a simple missing argument, (easy mistake with the recent splitting of patches). 373f352b "Have output structure fully reflect message MIME structure" I'm not comfortable with this commit. Previously there was recursion in one function, (show_message_part), and afterwards there is duplicated code performing recursion in both format_part_text and format_part_json. Similarly, the code adds header formatting code that duplicates functionality in the existing format_headers_text and format_headers_json functions. Meanwhile, I still can't tell exactly what the behavioral change intended is. The commit message talks about "fully recursing" and "match[ing] the MIME structure of the message". Was it not fully recursing before? In what way did the output not match the MIME structure before? It would probably be easier to tell what was going on if the test suite were updated at the same time (or in a subsequent commit at least). As is, this commit introduces test suite failures, (re-ordering of MIME part ID numbers and then emacs-client confusion), which remain until commit 7ee6aaa1 But what does the rest of the series really need from this commit? Is there some structural change to the json output aside from the part ID? If so, we're definitely missing a test for that directly, (other than the indirect testing we get with the emacs tests). 28ab74e0 "clean up expected emacs output to reflect cleaner from lines introduced in 78d6c196d90" This commit message refers to a stale (now non-existent) commit ID. I presume it's attempting to reference the commit with a message of "emacs: Show cleaner `From:' addresses in the summary line.". Granted, it's hard to keep commit IDs valid in a branch that's getting continually rebuilt. One fix is to not use the commit identifiers. Another help would be to have the test-suite cleanups occurring more closely after the commits that changed things. I'm happy to help work on cleaning up some of these issues if that would be useful. Let me know. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/7437e239/attachment.pgp>
Multiple sender identities (composing)
On Mon, 16 May 2011 19:29:07 +1000, Stewart Smith wrote: > Thought I'd share this bit of my .emacs snippet that may be useful to go > on the emacs tips page. > > This does the following: > - sets up a list of possible identities to have mail From > - on composing mail, it prompts you for who you want to send mail from > - pressing enter will give you the default (first in the list) > - otherwise you have tab completion And here's the same for choosing the identity when forwarding a mail: ;; Choose the identity used to forward a mail (defun schnouki/notmuch-mua-forward-message () (interactive) (let* ((from (ido-completing-read "Sender identity: " schnouki/mua-identities nil nil nil nil (car schnouki/mua-identities))) (address-components (mail-extract-address-components from)) (user-full-name (car address-components)) (user-mail-address (cadr address-components))) (notmuch-mua-forward-message))) (people who don't use or like ido may want to replace ido-completing-read with completing-read) If anyone is interested, I have some more useful snippets available on https://github.com/Schnouki/dotfiles/blob/master/emacs/init-50-mail.el#L232: - function to choose a signature according to the From header - function to choose the sender identity according to the To header (useful for replying to work e-mails using your work address, or for replying to a ML with a subscribed address that won't be rejected) - function to change the SMTP server that will be used for sending the mail according to the From header It seriously lacks documentation so don't hesitate to ask if you have any problem with it :) Regards, -- Thomas/Schnouki -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/221f9279/attachment-0001.pgp>
Multiple sender identities (composing)
On Mon, 16 May 2011 20:03:34 +0200, Thomas Jost wrote: > Nice idea, I like that. However this way you can only get the address > part, not the username part. And when using some addresses I want to put > a nickname instead of my full name, so just using a default user name is > not very convenient. > Or is it possible to put things like "User Name " in the > notmuch config? notmuch config get user.name 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/20110516/d27bfff8/attachment.pgp>
Header and other questions
Hi, On Mon, 16 May 2011 17:15:17 +0200, Daniel Schoepe wrote: > I think this is only a subset of the requested functionality, since one > can only tag consecutive threads at once. It seems like for non-consecutive messages to be tagged, there'd have to be some sort of mutt-style message-marking facility. There was some discussion when the feature was first introduced about whether to go with region or marking. I think I wrote a quick version of both. (I just checked -- that uncertainty is actually still there in the commit msg of 4c9585933 where the region feature comes in.) The decision, if I remember correctly, was that regions are so intuitive for emacs users, and many people reported trying to tag by region without thinking about it, that this approach would make sense for the emacs interface. In other words, keep the emacs interface emacsy. I think I still agree with that, since I feel like having both would be confusing (what do you do when you select a marked-line in a region?) and I like the one I tend toward intuitively. But I certainly see the benefit of the other functionality as well. Best, Jesse
Header and other questions
On Sat, 14 May 2011 22:23:16 -0700, mueen at nawaz.org wrote: > 2. Using the Python bindings, I want to do a query, get the messages, > and examine the headers of the messages. The problem is that if a > message is multi-part, then, I can't find any way to see the main > headers. I can only see the "headers" of each part. (I really would like > this working!) Python just does a notmuch_message_get_headers I believe, so it will return whatever libnotmuch returns. Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/b1e4f8bc/attachment.pgp>
storing From and Subject in xapian
On Sat, 14 May 2011 21:37:25 -0400, Austin Clements wrote: > I wonder if a better approach would be to use > notmuch_message_get_header everywhere, rather than introducing > _notmuch_message_get_header_value, and have it simply recognize > headers that can be retrieved directly from the database. Then > library callers could take advantage of this optimization and it could > be trivially extended to other headers in the future. +1, this is what the python bindings would prefer ;) Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/85925103/attachment.pgp>
Multiple sender identities (composing)
On Mon, 16 May 2011 11:52:43 +0200, Thomas Jost wrote: > On Mon, 16 May 2011 19:29:07 +1000, Stewart Smith flamingspork.com> wrote: > > Thought I'd share this bit of my .emacs snippet that may be useful to go > > on the emacs tips page. > > > > This does the following: > > - sets up a list of possible identities to have mail From > > - on composing mail, it prompts you for who you want to send mail from > > - pressing enter will give you the default (first in the list) > > - otherwise you have tab completion This is great, guys. I've been wanting to get something like this working for a while now. Have you guys looked at home message-mode does bbdb address completion in the To: and From: headers? It has the nice benefit of being able to tab through all full addresses for a bbdb entry. It would be nice to have this function fill in a default address, with the cursor at the end of the address, and then just tab through all the options without having to type in anything. ido is pretty cool, though, and accomplishes a similar effect. It would be nice to pull the addresses from the notmuch config, eg: notmuch config get user.primary_email notmuch config get user.other_email I would ideally like to be able to choose the From: address right before sending, as opposed to right before composing. Has anyone tried to get that working? I was not having much luck with send-hooks, since it looks like it expects the message to be complete at that point. 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/20110516/c4d289c4/attachment-0001.pgp>
Header and other questions
On Mon, 16 May 2011 11:27:52 -0400, Jesse Rosenthal wrote: > The decision, if I remember correctly, was that regions are so intuitive > for emacs users, and many people reported trying to tag by region > without thinking about it, that this approach would make sense for the > emacs interface. In other words, keep the emacs interface emacsy. I > think I still agree with that, since I feel like having both would be > confusing (what do you do when you select a marked-line in a region?) > and I like the one I tend toward intuitively. But I certainly see the > benefit of the other functionality as well. I should mention that in my experience it's usually not that hard to construct searches (or filters on searches) that pair down to just the messages you want to tag, in which case you can just tag the entire buffer. 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/20110516/772f6f85/attachment.pgp>
storing From and Subject in xapian
Austin Clements writes: > I wonder if a better approach would be to use > notmuch_message_get_header everywhere, rather than introducing > _notmuch_message_get_header_value, and have it simply recognize > headers that can be retrieved directly from the database. Then > library callers could take advantage of this optimization and it could > be trivially extended to other headers in the future. That's a good idea, updated patch below. This version also has fallback handling for database entries that don't have the new header value fields. I couldn't find a way to have the Xapian API differentiate between undefined and blank value fields so empty subject lines are encoded as a single space. Also, the address completion discussion made me think that maybe a value field containing To/Cc/Bcc could be added too to avoid message file parsing for the address search case but I haven't tried implementing that yet. -- next part -- A non-text attachment was scrubbed... Name: notmuch-value3.patch Type: text/x-patch Size: 3296 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110516/3667bc4c/attachment.bin> -- next part -- -- Istvan
Header and other questions
Hi On Sat, 14 May 2011 22:23:16 -0700, mueen at nawaz.org wrote: > 3. Can I mark a bunch of messages for tagging in the Emacs interface? I > know I can tag all messages in a query, but sometimes I'd just like to > select a few manually and tag them (or apply some other command to > them). I do not think that's possible at the moment but that could be quite useful. /Xavier
Re: storing From and Subject in xapian
On Sat, 14 May 2011 21:37:25 -0400, Austin Clements amdra...@mit.edu wrote: I wonder if a better approach would be to use notmuch_message_get_header everywhere, rather than introducing _notmuch_message_get_header_value, and have it simply recognize headers that can be retrieved directly from the database. Then library callers could take advantage of this optimization and it could be trivially extended to other headers in the future. +1, this is what the python bindings would prefer ;) Sebastian pgpnOGWzDitM2.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Multiple sender identities (composing)
Thought I'd share this bit of my .emacs snippet that may be useful to go on the emacs tips page. This does the following: - sets up a list of possible identities to have mail From - on composing mail, it prompts you for who you want to send mail from - pressing enter will give you the default (first in the list) - otherwise you have tab completion You may also want to set this: '(message-sendmail-envelope-from (quote header)) (in custom-set-variables) so that if you're doing postfix sender based routing or the like, it gets the correct address and doesn't end up sending things the wrong way. (setq stewart/mua-identities (list Stewart Smith stew...@flamingspork.com Stewart Smith stewart.sm...@percona.com)) (defun stewart/notmuch-mua-mail (optional from) (interactive) (setq from (completing-read Sender identity: stewart/mua-identities nil t nil nil (car stewart/mua-identities))) (notmuch-mua-mail nil nil (list (cons 'from from (define-key notmuch-show-mode-map m (lambda () send email (interactive) (stewart/notmuch-mua-mail))) (define-key notmuch-search-mode-map m (lambda () send email (interactive) (stewart/notmuch-mua-mail))) -- Stewart Smith ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC/PATCH] Vim client rewrite
On Sun, May 15, 2011 at 10:15 PM, an...@khirnov.net wrote: my attempts to make the vim client more usable somehow spiraled out of control and turned into a huge rewrite. The intermediate results I hereby present for your amusement and comments. (attached as whole files, since the patch would be unreadable) The main point of the rewrite is splitting of a large part of the code into Python. This should have the following advantages: 1) python-notmuch bindings can be used, which should allow for cleaner and more reliable code than running the binary and parsing its output with regexps. (also provides a nice use case for python-notmuch) 2) Python's huge standard library makes implementing some features MUCH easier. 3) More people know Python than vimscript, thus making the client development easier The code is α quality, but should be close to usable. It already has some features not present in the mainline vim client, like attachments (viewing and sending, saving to file should be trivial to add, will be done when I have some time), better support for unicode and more. Some UI features from the mainline versions that I didn't use were removed and customization options are somewhat lacking atm. This is of course to be improved later, depending on the responses. Comments, bugreports and fixes very much welcome. Do you have a git repo where to fetch these changes? Or can you provide a series of patches with 'git format-patch'? -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Multiple sender identities (composing)
On Mon, 16 May 2011 11:52:43 +0200, Thomas Jost schno...@schnouki.net wrote: On Mon, 16 May 2011 19:29:07 +1000, Stewart Smith stew...@flamingspork.com wrote: (people who don't use or like ido may want to replace ido-completing-read with completing-read) I couldn't get ido to work at all (Ubuntu Natty). It would just prompt and not tab complete or even accept enter (it would insert a newline in minibuffer) - which is why I just ended up using completing-read. - function to change the SMTP server that will be used for sending the mail according to the From header I actually just do this via postfix sender_dependent_relayhost_maps which ends up working quite nicely. -- Stewart Smith ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC/PATCH] Vim client rewrite
On Mon, 16 May 2011 14:36:07 +0300, Felipe Contreras felipe.contre...@gmail.com wrote: On Sun, May 15, 2011 at 10:15 PM, an...@khirnov.net wrote: my attempts to make the vim client more usable somehow spiraled out of control and turned into a huge rewrite. The intermediate results I hereby present for your amusement and comments. (attached as whole files, since the patch would be unreadable) The main point of the rewrite is splitting of a large part of the code into Python. This should have the following advantages: 1) python-notmuch bindings can be used, which should allow for cleaner and more reliable code than running the binary and parsing its output with regexps. (also provides a nice use case for python-notmuch) 2) Python's huge standard library makes implementing some features MUCH easier. 3) More people know Python than vimscript, thus making the client development easier The code is α quality, but should be close to usable. It already has some features not present in the mainline vim client, like attachments (viewing and sending, saving to file should be trivial to add, will be done when I have some time), better support for unicode and more. Some UI features from the mainline versions that I didn't use were removed and customization options are somewhat lacking atm. This is of course to be improved later, depending on the responses. Comments, bugreports and fixes very much welcome. Do you have a git repo where to fetch these changes? Or can you provide a series of patches with 'git format-patch'? Ah right, forgot to mention it. git://git.khirnov.net/git/notmuch branch vim. -- Anton Khirnov ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Header and other questions
On Sun, 15 May 2011 18:16:31 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote: It's possible, and works the way you'd think it would -- just select a bunch of threads in the search list, and then tag them. It will apply the tag to the messages in the region. (In fact, tagging a single thread is just a special case of this, with a one-line region.) I think this is only a subset of the requested functionality, since one can only tag consecutive threads at once. -- Daniel pgpb7qYX3MKAG.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Multiple sender identities (composing)
On Mon, 16 May 2011 09:52:32 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: On Mon, 16 May 2011 11:52:43 +0200, Thomas Jost schno...@schnouki.net wrote: On Mon, 16 May 2011 19:29:07 +1000, Stewart Smith stew...@flamingspork.com wrote: Thought I'd share this bit of my .emacs snippet that may be useful to go on the emacs tips page. This does the following: - sets up a list of possible identities to have mail From - on composing mail, it prompts you for who you want to send mail from - pressing enter will give you the default (first in the list) - otherwise you have tab completion This is great, guys. I've been wanting to get something like this working for a while now. Have you guys looked at home message-mode does bbdb address completion in the To: and From: headers? It has the nice benefit of being able to tab through all full addresses for a bbdb entry. It would be nice to have this function fill in a default address, with the cursor at the end of the address, and then just tab through all the options without having to type in anything. ido is pretty cool, though, and accomplishes a similar effect. I don't know much about bbdb; right now I'm completing addresses with notmuch-address.el and a little Python script that I wrote [1]. It can complete the From header too, although I had never tried that before writing this mail :) It would be nice to pull the addresses from the notmuch config, eg: notmuch config get user.primary_email notmuch config get user.other_email Nice idea, I like that. However this way you can only get the address part, not the username part. And when using some addresses I want to put a nickname instead of my full name, so just using a default user name is not very convenient. Or is it possible to put things like User Name m...@myself.com in the notmuch config? I would ideally like to be able to choose the From: address right before sending, as opposed to right before composing. Has anyone tried to get that working? I was not having much luck with send-hooks, since it looks like it expects the message to be complete at that point. I haven't tried that, but it would indeed be nice to be able to do that at send time. The message-seend-hook doc states that this hook is run quite early when sending, so I would expect that to be the best solution. However, if for some reason it doesn't work, it's probably possible to write a little function around message-send (...or even to advise it) to do whatever you want before it is actually executed. I'll try to have a look at this tomorrow. Regards, Thomas [1] https://github.com/Schnouki/dotfiles/blob/master/notmuch/addrbook.py -- Thomas/Schnouki pgpo7HMjRGfGm.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: address completion when composing
On Thu, 12 May 2011 00:38:20 -0700, Jameson Graef Rollins wrote: On Thu, 12 May 2011 02:04:41 +0200, Florian Friesdorf f...@chaoflow.net wrote: 1. store to/cc/bcc in xapian Hey, Florian. I think all of these fields are actually already stored in the database. No, just the terms are, not the full string. (although for search, that could actually be enough) Sebastian pgpRSVOElMBiQ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: release-candidate/0.6
On Fri, 13 May 2011 01:07:08 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: Hi, Carl. I went through dme's multipart patch series and cleaned things up. ... The result is the new release-candidate/0.6+mpmfix Thanks so much! This looks much better than before. I'm still hitting some snags quite early in the review process, (I'm hoping that real soon we'll be able to just start merging like crazy). Here at the things I've seen so far: d3e7415d add argument to part format function to indicate initial part This one fails to build due to a simple missing argument, (easy mistake with the recent splitting of patches). 373f352b Have output structure fully reflect message MIME structure I'm not comfortable with this commit. Previously there was recursion in one function, (show_message_part), and afterwards there is duplicated code performing recursion in both format_part_text and format_part_json. Similarly, the code adds header formatting code that duplicates functionality in the existing format_headers_text and format_headers_json functions. Meanwhile, I still can't tell exactly what the behavioral change intended is. The commit message talks about fully recursing and match[ing] the MIME structure of the message. Was it not fully recursing before? In what way did the output not match the MIME structure before? It would probably be easier to tell what was going on if the test suite were updated at the same time (or in a subsequent commit at least). As is, this commit introduces test suite failures, (re-ordering of MIME part ID numbers and then emacs-client confusion), which remain until commit 7ee6aaa1 But what does the rest of the series really need from this commit? Is there some structural change to the json output aside from the part ID? If so, we're definitely missing a test for that directly, (other than the indirect testing we get with the emacs tests). 28ab74e0 clean up expected emacs output to reflect cleaner from lines introduced in 78d6c196d90 This commit message refers to a stale (now non-existent) commit ID. I presume it's attempting to reference the commit with a message of emacs: Show cleaner `From:' addresses in the summary line.. Granted, it's hard to keep commit IDs valid in a branch that's getting continually rebuilt. One fix is to not use the commit identifiers. Another help would be to have the test-suite cleanups occurring more closely after the commits that changed things. I'm happy to help work on cleaning up some of these issues if that would be useful. Let me know. -Carl pgpT3nil5FBZU.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Add notmuch-before/after-tag-hook
From the commit message: emacs: add notmuch-before- and notmuch-after-tag-hook This patch adds hooks that are run before/after messages are tagged from the emacs interface. In order to implement this and to avoid having hooks parse all the arguments to the notmuch binary again, I created a `notmuch-tag' function that other modules should use instead of running (notmuch-call-notmuch-process tag ...) directly. I wasn't sure about adding the notmuch-tag function, but I think it is a bit cleaner than calling notmuch-call-notmuch-process directly in so many places anyway. Of course, any comments or criticism is appreciated. -- Daniel From 1acc99736a84e5294ba44368690dd79001e2e347 Mon Sep 17 00:00:00 2001 From: Daniel Schoepe daniel.scho...@googlemail.com Date: Sun, 15 May 2011 17:48:58 +0200 Subject: [PATCH] emacs: add notmuch-before- and notmuch-after-tag-hook This patch adds hooks that are run before/after messages are tagged From the emacs interface. In order to implement this and to avoid having hooks parse all the arguments to the notmuch binary again, I created a `notmuch-tag' function that other modules should use instead of running (notmuch-call-notmuch-process tag ...) directly. --- emacs/notmuch-message.el |3 +-- emacs/notmuch-show.el| 12 emacs/notmuch.el | 45 + 3 files changed, 46 insertions(+), 14 deletions(-) diff --git a/emacs/notmuch-message.el b/emacs/notmuch-message.el index d5c96c2..aefd3fb 100644 --- a/emacs/notmuch-message.el +++ b/emacs/notmuch-message.el @@ -44,8 +44,7 @@ the \inbox\ and \todo\, you would set (concat + str) str)) notmuch-message-replied-tags))) - (apply 'notmuch-call-notmuch-process tag - (append tags (list (concat id: (car (car rep nil)) + (apply 'notmuch-tag (concat id: (car (car rep))) tags) (add-hook 'message-send-hook 'notmuch-message-mark-replied) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 825988c..2b905c8 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1273,10 +1273,8 @@ the result. (new-tags (notmuch-show-add-tags-worker current-tags toadd))) (unless (equal current-tags new-tags) - (apply 'notmuch-call-notmuch-process - (append (cons tag - (mapcar (lambda (s) (concat + s)) toadd)) - (cons (notmuch-show-get-message-id) nil))) + (apply 'notmuch-tag (notmuch-show-get-message-id) + (mapcar (lambda (s) (concat + s)) toadd)) (notmuch-show-set-tags new-tags (defun notmuch-show-remove-tag (rest toremove) @@ -1289,10 +1287,8 @@ the result. (new-tags (notmuch-show-del-tags-worker current-tags toremove))) (unless (equal current-tags new-tags) - (apply 'notmuch-call-notmuch-process - (append (cons tag - (mapcar (lambda (s) (concat - s)) toremove)) - (cons (notmuch-show-get-message-id) nil))) + (apply 'notmuch-tag (notmuch-show-get-message-id) + (mapcar (lambda (s) (concat - s)) toremove)) (notmuch-show-set-tags new-tags (defun notmuch-show-toggle-headers () diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 1d683f8..837136d 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -465,6 +465,44 @@ and will also appear in a buffer named \*Notmuch errors*\. (error (buffer-substring beg end)) )) +(defun notmuch-tag (query rest tags) + Add/remove tags in TAGS to messages matching QUERY. + +TAGS should be a list of strings of the form \+TAG\ or \-TAG\ and +QUERY should be a string containing the search-query. + +Note: Other code should always use this function alter tags of +messages instead of running (notmuch-call-notmuch-process \tag\ ..) +directly, so that hooks specified in notmuch-before-tag-hook and +notmuch-after-tag-hook will be run. + (run-hooks 'notmuch-before-tag-hook) + (apply 'notmuch-call-notmuch-process + (append (list tag) tags (list -- query))) + (run-hooks 'notmuch-after-tag-hook)) + +(defcustom notmuch-before-tag-hook nil + Hooks that are run before tags of a message are modified. + +'tags' will contain the tags that are about to be added or removed as +a list of strings of the form \+TAG\ or \-TAG\. +'query' will be a string containing the search query that determines +the messages that are about to be tagged + + :type 'hook + :options '(hl-line-mode) + :group 'notmuch) + +(defcustom notmuch-after-tag-hook nil + Hooks that are run before tags of a message are modified. + +'tags' will contain the tags that were added or removed as +a list of strings of the form \+TAG\ or \-TAG\. +'query' will be a string containing the search query that determines +the messages that were tagged + :type 'hook + :options '(hl-line-mode) + :group 'notmuch) + (defun notmuch-search-set-tags (tags) (save-excursion (end-of-line) @@ -504,7 +542,7 @@ and will also appear in a buffer named \*Notmuch errors*\. (defun
MIME restructuring [was: Re: release-candidate/0.6]
On 05/16/2011 04:42 PM, Carl Worth wrote: Meanwhile, I still can't tell exactly what the behavioral change intended is. The commit message talks about fully recursing and match[ing] the MIME structure of the message. Was it not fully recursing before? In what way did the output not match the MIME structure before? before, the output was a linearized version of the mime tree, in particular removing the multipart pieces and only enumerating the leaves in a depth-first walk of the tree. So a message like this: A└┬╴multipart/signed 355339 bytes B ├┬╴multipart/mixed 353462 bytes C │├╴text/plain 235 bytes D │└╴image/jpeg attachment [foo.jpg] 352752 bytes E └╴application/pgp-signature attachment [signature.asc] 1030 bytes would come out with three parts: 1) C 2) D 3) E the new code assigns this message to 5 parts: 1) A 2) B 3) C 4) D 5) E This change is critical to be able to properly delineate which parts of a message were signed and/or encrypted. hth, --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: before, the output was a linearized version of the mime tree, in particular removing the multipart pieces and only enumerating the leaves in a depth-first walk of the tree. So a message like this: [snip example of change] Thanks, Daniel! That does make things much more clear. So what I'd love to see from here is a commit with a description like the above, and then a test case looking like your example. From there, I'd next like a new version of the commit that gets the intended behavior with less code duplication. I'll work on each of the above unless someone beats me to any of it. Let me know. -Carl pgpMZOFRqBDEc.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote: So a message like this: A└┬╴multipart/signed 355339 bytes B ├┬╴multipart/mixed 353462 bytes C │├╴text/plain 235 bytes D │└╴image/jpeg attachment [foo.jpg] 352752 bytes E └╴application/pgp-signature attachment [signature.asc] 1030 bytes would come out with three parts: 1) C 2) D 3) E the new code assigns this message to 5 parts: 1) A 2) B 3) C 4) D 5) E This message should itself be a comparably complex message, with a tiny attached image of a geek with a bike. Feel free to use this in the test suite (the picture and this message are hereby released under the same license as notmuch itself). Note that if the mailing list attaches a footer, the MIME tree will be even more delightfully complicated, for added fun and games. --dkg attachment: dkg-tiny.png signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 16:50:06 -0400, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: So a message like this: A└┬╴multipart/signed 355339 bytes B ├┬╴multipart/mixed 353462 bytes C │├╴text/plain 235 bytes D │└╴image/jpeg attachment [foo.jpg] 352752 bytes E └╴application/pgp-signature attachment [signature.asc] 1030 bytes I tried creating a message like that but mine came out slightly differently: A└┬╴multipart/mixed B ├┬╴multipart/signed C │├╴text/plain D │└╴application/pgp-signature E └╴application/octet-stream I'll have to learn better how to control the emacs mail composer in order to understand how to get signatures to cover attachments if I want to do that kind of thing. would come out with three parts: 1) C 2) D 3) E That is indeed the behavior I see with master (for both text and json output). the new code assigns this message to 5 parts: 1) A 2) B 3) C 4) D 5) E Interestingly, this is not quite the behavior I get (with commit 373f352). With --format=text I'm now seeing: 2) C 3) D 4) E and with --format=json I'm seeing (I think this structure is right): 1) A 3) B 5) C 7) D 9) E So that explains some of my confusion. The behavioral change of this commit is really only impacting the json format, and not the text. That wasn't clear from the commit message (and I had only been doing my testing with the text backend). This seems to be justifying my fears about the code duplication---the two code paths are already divergent, (which means that things like notmuch part-number identifiers cannot be used between the different formats). I'd like to fix that by preventing the code duplication. Also, both paths seem to be suffering from some excess part-number incrementing somewhere. All of this should be easy to get right with a careful test case or two. -Carl pgpi20C4xluPG.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
lol, made my day! Simon On 05/16/2011 11:05 PM, Daniel Kahn Gillmor wrote: On 05/16/2011 04:50 PM, Daniel Kahn Gillmor wrote: So a message like this: A└┬╴multipart/signed 355339 bytes B ├┬╴multipart/mixed 353462 bytes C │├╴text/plain 235 bytes D │└╴image/jpeg attachment [foo.jpg] 352752 bytes E └╴application/pgp-signature attachment [signature.asc] 1030 bytes would come out with three parts: 1) C 2) D 3) E the new code assigns this message to 5 parts: 1) A 2) B 3) C 4) D 5) E This message should itself be a comparably complex message, with a tiny attached image of a geek with a bike. Feel free to use this in the test suite (the picture and this message are hereby released under the same license as notmuch itself). Note that if the mailing list attaches a footer, the MIME tree will be even more delightfully complicated, for added fun and games. --dkg ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
On 05/16/2011 05:20 PM, Carl Worth wrote: Interestingly, this is not quite the behavior I get (with commit 373f352). With --format=text I'm now seeing: 2) C 3) D 4) E --format=text should only show the parts that are readable in text. the ultimate goal is to get the part numbers aligned across all --format choices, regardless of the ability of the format to show the actual nesting. So that explains some of my confusion. The behavioral change of this commit is really only impacting the json format, and not the text. That wasn't clear from the commit message (and I had only been doing my testing with the text backend). It should ultimately affect the numbering in all parts. There's no way for the text part to do anything like the nesting that we're doing in json, though, due to the output format. This seems to be justifying my fears about the code duplication---the two code paths are already divergent, (which means that things like notmuch part-number identifiers cannot be used between the different formats). I'd like to fix that by preventing the code duplication. Also, both paths seem to be suffering from some excess part-number incrementing somewhere. The confusions you outline were fixed (by me, iirc) somewhere later in the crypto tree. I did not want to tamper with dme's crypto branch directly (though i now suspect that's what i should have done). i'd give you a commit ID, but i suspect you're sufficiently rebased that this wouldn't be helpful. --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Multiple sender identities (composing)
Jameson Graef Rollins wrote at 2011-05-16 11:52 -0500: This is great, guys. I've been wanting to get something like this working for a while now. Yes; thanks Stewart, Thomas. This is one thing that has slowed my transition to notmuch (from Mutt). Perhaps some of this or links to it could be added to the wiki? signature.asc Description: Digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 14:20:07 -0700, Carl Worth cwo...@cworth.org wrote: I'll have to learn better how to control the emacs mail composer in order to understand how to get signatures to cover attachments if I want to do that kind of thing. See mml-secure-message-sign-pgpmime to sign an entire message, as opposed to just a single part. This seems to be justifying my fears about the code duplication---the two code paths are already divergent, (which means that things like notmuch part-number identifiers cannot be used between the different formats). I'd like to fix that by preventing the code duplication. Also, both paths seem to be suffering from some excess part-number incrementing somewhere. I think the two paths reconverge later in the series. Can you look ahead a bit to see if that concern is addressed? jamie. pgpWdZACwWbe8.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: address completion when composing
On Mon, 16 May 2011 22:04:42 +0200, Sebastian Spaeth sebast...@sspaeth.de wrote: No, just the terms are, not the full string. (although for search, that could actually be enough) Right. It's easy enough to search on the To: field. But for address completion, I think we realyl will want to fix the database to store complete names+addresses that can be recovered for messages matching a search. -Carl pgpwR7J9v7Ei1.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: MIME restructuring [was: Re: release-candidate/0.6]
On Mon, 16 May 2011 15:37:49 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: See mml-secure-message-sign-pgpmime to sign an entire message, as opposed to just a single part. Thanks! That's good to know. (Trying here.) I think the two paths reconverge later in the series. Can you look ahead a bit to see if that concern is addressed? Daniel did point me to later in the series where the numbers are at least the same in text and json output. I've grabbed that state for generating a test case, (also with Daniels test message). And I'm now cooking up a new commit that will pass that test but with less code duplication than the current patch. -Carl pgpyr1d2eo38O.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Header and other questions
Jameson Graef Rollins jroll...@finestructure.net writes: On Mon, 16 May 2011 11:27:52 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote: The decision, if I remember correctly, was that regions are so intuitive for emacs users, and many people reported trying to tag by region without thinking about it, that this approach would make sense for the emacs interface. In other words, keep the emacs interface emacsy. I think I still agree with that, since I feel like having both would be confusing (what do you do when you select a marked-line in a region?) and I like the one I tend toward intuitively. But I certainly see the benefit of the other functionality as well. I should mention that in my experience it's usually not that hard to construct searches (or filters on searches) that pair down to just the messages you want to tag, in which case you can just tag the entire buffer. I guess so. I still haven't really switched to notmuch for real mail so I have little experience. I don't quite remember why I would have found it handy when I wrote it, but it was while I was busy experimenting with tagging my existing archive. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Multiple sender identities (composing)
Jameson Graef Rollins jroll...@finestructure.net writes: This is great, guys. I've been wanting to get something like this working for a while now. Agreed. Would be awesome if someone could post it to the Wiki... ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
