[PATCH] notmuch.el: 'F' in search mode takes us to a list of folders.
On Sat, 27 Feb 2010 08:49:06 +0100, Sebastian Spaeth
wrote:
> From: David Edmondson
> ---
> Dear Carl, I start out notmuch in my inbox search, but find myself
> navigating to the notmuch-folder view quite often. Therefore the key
> binding 'F' to open a notmuch-folder is really handy.
I agree that a single-key binding for this is really handy.
I'm actually currently using super-n (a personal customization I have)
to get to notmuch-folder view from *any* buffer in emacs.
And I want to make a (cleaned-up) version of notmuch-folder be the
starting point for notmuch, (rather than the inbox view). And I also
want to make the 'q' binding more clever so that instead of just closing
the current view it will actually return to the parent view. That would
make 'q' be a single-key binding from most search views (unfiltered ones
at least) to the notmuch-folder view.
But that's all future ideas---back to the current patch.
I don't really like the keybinding of 'F' for this. We've mostly avoided
capitalized bindings so far, (we have quite a few lowercase bindings
available after all). The few we have are all alternate versions of the
lowercase version, ("N" = next message vs. 'n' = next unread
message). Since "F" = folder-view is unrelated to 'f' = filter, I'd like
to avoid that.
Also, I think we need a better name for notmuch-folder view anyway. We
have an outstanding patch to make the filesystem-directory of mail
messages available with a search syntax of "folder:". So there's a
conceptual clash of "folder" there already.
So maybe this view needs a name like "home" or even just "notmuch"? Like
I said, I would like to make my cleaned-up version (see TODO for a
mockup) be the view that one gets with "M-x notmuch".
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100407/ec918a51/attachment.pgp>
[PATCH] Fix the default value for --includedir.
On Wed, 7 Apr 2010 11:48:31 -0400, Mike Kelly wrote:
> -includedir = ${INCLUDEDIR:=\$(prefix)/lib}
> +includedir = ${INCLUDEDIR:=\$(prefix)/include}
Yikes! That's pretty embarrassing.
(I probably would have noticed in the Debian package, but debhelper
automatically passes an explicit --includedir that happens to match what
should have been the default here before).
Thanks for this fix. This is pushed.
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100407/b4a4228b/attachment.pgp>
[PATCH] Fix code extracting the MTA from Received: headers
On Wed, 07 Apr 2010 13:38:29 -0700, Dirk Hohndel wrote: > The previous code made too many assumptions about the (sadly not > standardized) format of the Received headers. This version should > be more robust to deal with different variations. Thanks for maintaining this. I'll have to fiddle with my mail setup before this feature is useful for me. So I haven't tested this, (other than to verify that it hasn't broken "notmuch reply" for me). But I've pushed this now at least. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100407/530ccb81/attachment.pgp>
[PATCH] Derive version numbers from git
On Tue, 06 Apr 2010 18:11:28 +0200, Michal Sojka wrote: > On Tue, 06 Apr 2010, Sebastian Spaeth wrote: > > > But, there are people without git installed that download the release > > tarball. So if this patch makes it, we need to replace this with a > > static version number when baking a release tar. > > Right, here is an updated patch. It's more complicated than the previous > one, but it solves the issue. I like this idea, definitely. But the other piece needed here is a way for me to be able to specify a version in order to release. In my current release instructions (notmuch/RELEASING) I do that by manually incrementing the version number in the Makefile. Then a tag is created later when the "make release" target runs. It would be possible for me to instead create the tag to specify the version, but there's a few things I don't like about this: 1. After I increment the version number (early in the release process) I often find one or two little things I need to change to make the release perfect. So there are likely more commits later, but I obviously don't want some git-describe version to end up in the final tar file. 2. I don't actually want to create a tag, (I *especially* don't want to push it), until the release actually happens. That's the point of the tag in my view, (to say "*this* is what I released"), so making the tag early seems wrong, (and leaves the door open to make mistakes). Any suggestion for this part? > +include Makefile.version > + > +.PHONY: Makefile.version > +Makefile.version: > + echo VERSION=$(if $(wildcard version),`cat version`,`git describe > --dirty`) > $@ Could that be simplified to just use $(shell) rather than a separate file and an include? I suppose what we could do is to just have the creation of the version file be part of the release process. That would be simple enough. Then we could drop this rule: > +version: > + git describe > $@ What do you think? -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100407/06e5a998/attachment.pgp>
Plans for the 0.2 release (this week)
We've obviously got a lot of interest in notmuch, and a huge pile of features that need to be merged. I think that means we're in a state where we can have extremely regular releases, with continually improving feature sets. I'm thinking releases once per week or so. With each release, I expect people to remind me of their favorite features that haven't been merged, (while I'll continue to work through any backlog on my own). For the upcoming 0.2 release, here are some things that I would like to have in place: * Any further changes from the Sebastian's repository. Sebastian, I worked through one list I saw recently. Do you have another list to propose yet? * The big batch of emacs-client improvements from David E.'s repository. David, do you have particular things to recommend here? * Changes to indexing, (addition of body:, folder:, list:, etc.). This is stuff that I'll work on. * Some library additions (move_to_first for the iterators, and perhaps a notmuch_database_add_message_with_data which Srinivasa requested to support integration of notmuch into evolution). I'll work on these as well, (I know that there are patches for some of these on the list already). * Anything else that people want, (especially things that already exist and that you're already using). Support for maildir flags on import would be great here. I'm still waiting to see a complete solution I think. So keep the patches coming, and the pointers to patches that you want me to look at. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100407/44f77e09/attachment.pgp>
[notmuch] [Sebastian Spaeth] Pull requests
On Thu, 25 Mar 2010 22:50:52 -0400, micah anderson wrote: > The only other patch that I find absolutely crucial, that you do not > include, is the 'Preserve folder information when indexing' patch which, > although not perfect, does significantly change my life. This, (along with "allow mailing-list headers to be indexed"), is near the top of my mental todo list for notmuch. The trick with these is to smoothly do the re-indexing for people that aren't building an index
[notmuch] [Sebastian Spaeth] Pull requests
On Mon, 01 Mar 2010 15:57:00 +0100, "Sebastian Spaeth" wrote: > >From git repository git://github.com/spaetz/notmuch-all-feature.git I > would like to advocate the following branches for quick pulling. Each > contains 1 or 2 patches. They have all been based on todays > cworth/master, so it should be really painless. Thanks Sebastian, both for pulling these together and mentioning them here. I've now gone through everything in this list and either merged the patch or asked for further work, (and in either case I've replied to one of the original messages proposing the patch). Keep up the good work! -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100407/3198b20e/attachment.pgp>
[notmuch] [PATCH] notmuch-new: Respect maildir flags when importing a new message
On Mon, 1 Mar 2010 14:28:56 +0100, Sebastian Spaeth wrote: > When importing a new mail do check for maildir tags and assign > corresponding notmuch tags. I think this is a useful thing to support, as obviously new users have *some* state that's interesting to import (which messages have been "seen" for example), and simply importing their entire email archive with both the "inbox" and "unread" tags is not helpful. So I'd like to figure out how to support this. > Do note that this will only add tags when importing a really new > message, and will not do anything when detecting a file rename > (although someone should really make it honor file renames as > well). Deleteing an existing message in another IMAP client will > therefore not trigger tagging (as it counts as a file rename). But I think we really need to fix that if we're going to claim that notmuch "supports maildir flags" in any sense. It's a fairly tricky issue though since we can have multiple files that have the same message ID, but then have different maildir flags. And it's the matter of arbitrary ordering which one of these files appears as "new" and which one appears as a "rename". It's not obvious to me what we can do here unless we make some assumptions, (such as "mails always start without the seen flag, and once it appears it can't be removed" or so). But I'd love some input
[notmuch] [PATCH v2] notmuch.el: add functionality in notmuch search mode to add or remove tags by region
On Tue, 16 Feb 2010 19:07:40 -0500, Jesse Rosenthal wrote: > This patch adds `-region' versions of the `notmuch-search-' commands to find > properties. It also splits up `notmuch-add/remove-tags' into both a > `-thread' and a `-region' version. (This makes us modify > `notmuch-search-archive-thread' to use the > `notmuch-search-remove-tag-thread' function, instead of > `notmuch-search-remove-tag', for consistency.) The add/remove-tag command > called by pressing `+' or `-' will then choose accordingly, based on whether > region is active. > > This version fixes a couple of errors in the first version, which led to > incorrect marking of some tags in the search view (though the actual > tagging was still correct). It's also based on current master. > > I'm not sure any more if region selection is actually the correct way to > do this, or if a mutt-style message-marking method would be better. But > I didn't want a buggy incorrect version out there. I think this feature is very useful, and that the region is definitely an appropriate way to implement it, (doing region-based operations is very natural for emacs users). Mutt-style marking could be implemented as well, but that would be separate I think. I tested this patch a bit and added one small cleanup to the documentation (see below). I also don't like the duplication of code in notmuch-search-add-tag-thread and notmuch-search-add-tag-region, (and the same in the remove case). Fortunately, I think this easy to avoid by simply making notmuch-search-add-tag-thread call: (notmuch-search-add-tag-region tag (point) (point)) and the same in the remove case. But I haven't pushed this patch yet for a flaw in the case of selecting beyond the last thread, (such as selecting to the line that includes the "End of search results). If I try an operation on that line, it will act like it works, (it displays the new tags by all threads), but then a refresh makes them all disappear again. Presumably the "notmuch tag" command is failing, this isn't being noticed, and the code marches on to update the representation of the tags. And presumably the notmuch tag is failing because no thread ID is found for the last line, so the mapconcat call is sticking an extra " or " onto the end of the search string. And Xapian doesn't like that: $ notmuch search tag:inbox or A Xapian exception occurred performing query: Syntax: OR Query string was: tag:inbox or Things behave even worse if I make the region be the entire buffer, (including the last blank line). Then the commands hang. I got nervous that this was then adding "or or" and trying to add/remove a tag to every message containing the word "or". But I haven't looked closely. If we can fix this bug, then I'd like to apply this patch. I'd even like to fix the "*" binding to be implemented in terms of something like these functions so that we could get visual updates of the tag state
[PATCH] Fix code extracting the MTA from Received: headers
The previous code made too many assumptions about the (sadly not
standardized) format of the Received headers. This version should
be more robust to deal with different variations.
Signed-off-by: Dirk Hohndel
---
notmuch-reply.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 8eb4754..39377e1 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -296,28 +296,23 @@ guess_from_received_header (notmuch_config_t *config,
notmuch_message_t *message
received = notmuch_message_get_header (message, "received");
by = strstr (received, " by ");
if (by && *(by+4)) {
- /* we know that there are 4 characters after by - either the 4th one
-* is '\0' (broken header) or it is the first letter of the hostname
-* that last received this email - which we'll use to guess the right
-* from email address
+ /* sadly, the format of Received: headers is a bit inconsistent,
+* depending on the MTA used. So we try to extract just the MTA
+* here by removing leading whitespace and assuming that the MTA
+* name ends at the next whitespace
+* we test for *(by+4) to be non-'\0' to make sure there's something
+* there at all - and then assume that the first whitespace delimited
+* token that follows is the last receiving server
*/
mta = strdup (by+4);
if (mta == NULL)
return NULL;
-
- /* After the MTA comes its IP address (or HELO response) in parenthesis.
-* so let's terminate the string there
-*/
- if ((ptr = strchr (mta, '(')) == NULL) {
- free (mta);
+ token = strtok(mta," \t");
+ if (token == NULL)
return NULL;
- }
- *ptr = '\0';
-
/* Now extract the last two components of the MTA host name
* as domain and tld
*/
- token = mta;
while ((ptr = strsep (, delim)) != NULL) {
if (*ptr == '\0')
continue;
--
1.6.6.1
--
Dirk Hohndel
Intel Open Source Technology Center
[PATCH] emacs: Correct the documentation for notmuch-search-add-tag (and -remove-tag)
These commands act on all messages in the thread, not simply those that match the search. (There are use case for both behaviors, but the documentation must match the behavior that's actually implemented). --- emacs/notmuch.el |9 - 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 64f3e3d..517c53a 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -532,12 +532,11 @@ and will also appear in a buffer named \"*Notmuch errors*\"." (notmuch-search-set-tags (delete tag (notmuch-search-get-tags))) (forward-line)) - (defun notmuch-search-add-tag (tag) "Add a tag to the currently selected thread or region. -The tag is added to messages in the currently selected thread or -region which match the current search terms." +The tag is added to all messages in the currently selected thread +or threads in the current region." (interactive (list (notmuch-select-tag-with-completion "Tag to add: "))) (save-excursion @@ -550,8 +549,8 @@ region which match the current search terms." (defun notmuch-search-remove-tag (tag) "Remove a tag from the currently selected thread or region. -The tag is removed from all messages in the currently selected thread -or region which match the current search terms." +The tag is removed from all messages in the currently selected +thread or threads in the current region." (interactive (list (notmuch-select-tag-with-completion "Tag to remove: " -- 1.7.0 -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100407/bc289f04/attachment.pgp>
[notmuch] Fcc, Maildir, and Emacs message-mode -- a bit of code
On Wed, 27 Jan 2010 09:44:41 -0500, Jameson Rollins wrote: > Hey, folks. Following up on this thread about better fcc handling, > Jesse passed on a simple python script he wrote that uses the python > "mailbox" module to deliver a message on stdin to a specified maildir > directory. It's very a simple, elegant and general purpose script > (attached). > > I then put the following in my notmuch .emacs to use the new script in > message-mode to fcc sent mail to my ~/.mail/sent directory: > > ;; fcc handler > (defun maildir-deliver-region(destdir) > (shell-command-on-region >(point-min) (point-max) >(concat "maildir-deliver.py -c -s -d " destdir))) > (setq message-fcc-handler-function 'maildir-deliver-region) > (defun my-message-header-setup () > (message-add-header "Fcc: ~/.mail/sent")) > (add-hook 'message-send-hook 'my-message-header-setup) This is really nice - just what I needed. Well, almost. Instead of passing in destdir it would be even better if the lisp code figured out which MailDir to use. So we'd have a configuration variable that matched From addresses to MailDirs "dirk at hohndel.org" "~/MailDirHohndel" "dirk.hohndel at intel.com" "~/MailDirIntel" etc. And just for safety used the passed in destdir as fallback / default. Anyone willing / able to add this? I can't lisp to save my life... /D -- Dirk Hohndel Intel Open Source Technology Center
[PATCH 1/2] notmuch.el: Allow citation suffixes to be shown as well as prefixes.
On Tue, 6 Apr 2010 09:39:19 +0200, Sebastian Spaeth wrote: > From: David Edmondson > > In many conversations the last few lines of a citation are more > interesting than the first few lines, hence allow those to be shown if > desired. Thanks, David! (and Sebastian). I've pushed out this change, (along with a followup that actually enables this functionality by default), and I absolutely love it already. > Modify the face used for the citation button to distinguish it from > the surrounding citation. This piece looks totally independent, so I separated it out. I was going to push it out separately, but I didn't actually find that it did anything by default. (For me, font-lock-comment-delimiter-face inherits from font-lock-comment-face with no changes.) And actually, that makes me realize that we should be defining our own notmuch face names for all the faces we use. Instead of just using font-lock (or even message-mode) face names, we should use our own, (but make them inherit liberally from other modes where that makes sense. With that, plus changing a bunch of our current defvar calls into defcustom calls, and I think we'd have a fairly reasonable customize interface where people could tweak the appearance of notmuch without having to write any emacs lisp. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100407/4b618494/attachment.pgp>
finding the emacs lisp after install
After this change... > commit dfbec15b2388158693ab0dce0c7d348c4c5a98a5 > Author: Carl Worth > Date: Tue Apr 6 15:05:13 2010 -0700 > > Install emacs lisp files into a notmuch sub-directory of site-lisp. > > Now that we have multiple emacs-lisp source files, it's just more > polite this way. ...how is emacs supposed to find these files? .../site-lisp/notmuch is not in my load-path by default (Debian GNU Emacs 23.1.1). dme. -- David Edmondson, http://dme.org
[notmuch] [PATCH] notmuch.el: Colour cited regions and signatures with message-cited-text-face.
On Mon, 15 Feb 2010 09:41:49 +, David Edmondson wrote: > --- > notmuch.el |2 ++ Thanks, David. I've pushed this now, (with the later fix from Sebastian applied). -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100407/266850a9/attachment.pgp>
[notmuch] [Sebastian Spaeth] Pull requests
On 2010-04-07, micah anderson wrote: > > > The only other patch that I find absolutely crucial, that you do not > > > include, is the 'Preserve folder information when indexing' patch which, > > > although not perfect, does significantly change my life. This patch in included in my branch now. There is a branch with just that patch over cworth/master in http://github.com/spaetz/notmuch-all-feature/tree/issue28-search-folder-name However, testing this, it does not seem to work for me: I dumped and restored all mails, redoing my database and notmuch count folder:inbox shows 2 messages that contain "folder:" in their body. weird. I'll investigate. Sebastian
[PATCH] Fix the default value for --includedir.
---
configure |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/configure b/configure
index 21780a6..59e4092 100755
--- a/configure
+++ b/configure
@@ -357,7 +357,7 @@ prefix = ${PREFIX}
libdir = ${LIBDIR:=\$(prefix)/lib}
# The directory to which header files should be installed
-includedir = ${INCLUDEDIR:=\$(prefix)/lib}
+includedir = ${INCLUDEDIR:=\$(prefix)/include}
# The directory to which man pages should be installed
mandir = ${MANDIR:=\$(prefix)/share/man}
--
1.7.0.4
[notmuch] [PATCH] Further improvements to tag-based coloring in search.
On Sat, 6 Feb 2010 20:21:43 -0500, Aaron Ecay wrote: > Makes the following improvements: > - fix up doc strings > - suppress the creation of unnecessary let-bindings > - create overlays lazily (to avoid creating many overlays for threads > that do not get colored) Hi Aaron, I saw this fixed-up version from you only after I'd pushed the previous one. If you could resend a new change on top of what's now in master, then that would be appreciated. Thanks, -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100407/c126fb00/attachment.pgp>
[notmuch] [PATCHv2] notmuch.el: colorize lines in notmuch-search based on thread tags.
On Thu, 04 Feb 2010 19:38:20 -0500, Jameson Graef Rollins wrote:
> Arbitrary font faces can be specified for given thread tags. By
> default, no coloring is applied. To specify coloring, place something
> like this in your .emacs:
>
> (setq notmuch-search-line-faces '(("delete" . (:foreground "red"))
> ("unread" . (:foreground "green"
>
> Order matters: line faces listed first will take precedence (in the
> example above, a thread tagged both "delete" and "unread" will be
> colored red, since the "delete" face is listed before the "unread").
Hi Jameson,
Thanks for this patch. I just pushed it (based on what I found
originally in spaetz' tree). Only after coming back here did I find that
you had sent a second version that colored "delete" tags by default.
I haven't added that part for a couple of reasons:
1. The commit message doesn't match the behavior of the patch, (it says
"no coloring is applied" by default.
2. I think we'll go with a tag name of "deleted" rather than "delete".
I did fix up some indentation and a slightly scrambled commit
message. But maybe that only existed in spaetz' tree.
Finally, I checked the customization support, ("M-x customize", then
browse Applications->Email->Notmuch), and saw that notmuch-tag-face is
much easier to customize there, (provides a drop-down value menu with
buttons for modifying the face---where I couldn't even figure out how to
use customize for the new notmuch-search-line-faces).
Plus, I think both of these values should likely be merged into a single
face-selection option, (perhaps with a separate Boolean to determine
whether to highlight just the tag name or the whole line).
Thanks again for the improvements, and hopefully you'll see quicker
merging from me in the future.
-Carl
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100407/fbc89baf/attachment.pgp>
[notmuch] [PATCH v2] notmuch.el: Make notmuch-show buffer name first subject, instead of thread-id
On Fri, 12 Feb 2010 17:19:23 -0500, Jesse Rosenthal wrote: > Change the buffer name to a uniquified subject of the thread (i.e. the > subject of the first message in the thread) instead of the thread-id. This > is more meaningful to the user, and will make it easier to scroll through > numerous open buffers. A very lovely change, Jesse! Thanks for this (which is now pushed). And again, thanks to Sebastian for guiding the patch through the file renaming. There is one minor issue with this patch which is that viewing an identical thread more than once will bring up a new buffer rather than re-using the existing buffer. But of course, we *want* a separate buffer if the thread-ID is different but the (abbreviated) subject just happens to match. So there would have to be something clever to do the right thing here. I'm not making this minor regression block the patch, since it's so nice otherwise. > This version of the patch improves on the first version by ensuring that > the buffer names are unique, and that the `notmuch-show' command can > still be used interactively. > > Signed-off-by: Jesse Rosenthal > --- > notmuch.el | 25 +++-- > 1 files changed, 19 insertions(+), 6 deletions(-) That last paragraph above is good guidance for understanding the patch, but not useful as part of the permanent commit history. So I removed it before pushing the commit. In the future, you can put text like that *after* the "---" just below your Signed-off-by and then "git am" will automatically ignore it. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100407/29d87f2e/attachment.pgp>
[notmuch] Message parsing issue?
David Bremner wrote: > One thing I noticed was that the message you sent (at least, if I got > the correct attachment), had X-Spam headers _before_ the "From " > line. If I remove those headers then the message displays Ok. It is > probably not worth putting too much effort into that display code since > it is in the process of being completely rewritten. Perhaps an extra > pass through "formail" can format you message headers a bit more nicely? I noticed this as well. I hope the new display code in Notmuch will be able to handle such cases, unless there are good reasons not to do so.
[notmuch] [PATCH] fontify date in header
On Fri, 22 Jan 2010 10:45:53 -0500, Jameson Rollins wrote: > The date was unfairly left out of getting pretty colors in the > notmuch-show header display. This fixes that grave injustice. Thanks, Jameson. This is pushed now (finally!). And thanks to Sebastian for tracking this and rebasing to the current file location. -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100407/2abf74ee/attachment.pgp>
finding the emacs lisp after install
On Wed, 07 Apr 2010 12:42:21 +0100, David Edmondson wrote:
> After this change...
>
> > Install emacs lisp files into a notmuch sub-directory of site-lisp.
> >
> > Now that we have multiple emacs-lisp source files, it's just more
> > polite this way.
>
> ...how is emacs supposed to find these files? .../site-lisp/notmuch is
> not in my load-path by default (Debian GNU Emacs 23.1.1).
Ah, good point.
The Debian package goes through some magic (in
/etc/emacs/site-start.d/50notmuch.el) to ensure that this directory is
added to the load-path.
Given that, I've just changed the default back to just install the files
into ${prefix}/share/emacs/site-lisp and made the Debian packaging
request ${prefix}/share/emacs/site-lisp/notmuch when it configures (see
below).
Thanks for the report,
-Carl
[PATCH] Makefile: Install emacs code to site-lisp, not site-lisp/notmuch
And just make the Debian packaging request site-lisp/notmuch like it
wants. Otherwise, the installed files won't appear on the load-path
so won't be found by emacs.
---
configure|6 +++---
debian/rules |3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index 21780a6..959c65a 100755
--- a/configure
+++ b/configure
@@ -71,7 +71,7 @@ Fine tuning of some installation directories is available:
--includedir=DIRInstall header files to DIR [PREFIX/include]
--mandir=DIRInstall man pages to DIR [PREFIX/share/man]
--sysconfdir=DIRRead-only single-machine data [PREFIX/etc]
- --emacslispdir=DIR Elisp [PREFIX/share/emacs/site-lisp/notmuch]
+ --emacslispdir=DIR Emacs code [PREFIX/share/emacs/site-lisp]
Additional options are accepted for compatibility with other
configure-script calling conventions, but don't do anything yet:
@@ -219,9 +219,9 @@ fi
if [ -z "${EMACSLISPDIR}" ]; then
if pkg-config --modversion emacs > /dev/null 2>&1; then
- EMACSLISPDIR=$(pkg-config emacs --variable sitepkglispdir)/notmuch
+ EMACSLISPDIR=$(pkg-config emacs --variable sitepkglispdir)
else
- EMACSLISPDIR='$(prefix)/share/emacs/site-lisp/notmuch'
+ EMACSLISPDIR='$(prefix)/share/emacs/site-lisp'
fi
fi
diff --git a/debian/rules b/debian/rules
index 1f6c4bb..0c20c94 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,9 @@
%:
dh $@
+override_dh_auto_configure:
+ dh_auto-configure --emacslispdir=/usr/share/emacs/site-lisp/notmuch
+
override_dh_installdocs:
dh_installdocs
install -m644 vim/README debian/notmuch/usr/share/doc/notmuch/README.vim
--
1.7.0
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20100407/4b2322bd/attachment.pgp>
[PATCH] * notmuch-reply.c: 542e32876 introduced a superfluous { in an if statement
---
notmuch-reply.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index e69e7a4..f26ca39 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -402,7 +402,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.6.3.3
[notmuch] [Sebastian Spaeth] Pull requests
On 2010-03-27, micah anderson wrote: > On Thu, 25 Mar 2010 22:50:52 -0400, micah anderson > wrote: > > On Mon, 01 Mar 2010 15:57:00 +0100, "Sebastian Spaeth" > SSpaeth.de> wrote: > > > > > From git repository git://github.com/spaetz/notmuch-all-feature.git I > > > would like to advocate the following branches for quick pulling. Each > > > contains 1 or 2 patches. They have all been based on todays > > > cworth/master, so it should be really painless. > > > > Thanks for pulling these all together! All the ones that you propose I > > also use and would really like these to be merged as well. > > > > The only other patch that I find absolutely crucial, that you do not > > include, is the 'Preserve folder information when indexing' patch which, > > although not perfect, does significantly change my life. > > Glad you find it useful. Yes, having the folder information would indeed > be nice. Is that patch working well for you? (Can you point me to the > mail ID of the patch you are using? There have been several versions > around). The patch works really well for me. I also had difficulty figuring out which was the latest. The thread is thread:4ca0710d708e648c214ba3a67469f5bd, and the Message-ID is: 1265122868-12133-1-git-send-email-sojkam1 at fel.cvut.cz I had to rebase the patch to get it to apply with the other features that you have in your branch. I'm attaching that rebased patch to this message. -- 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/20100407/c33b4278/attachment.pgp> -- next part -- A non-text attachment was scrubbed... Name: folder.diff Type: text/x-diff Size: 4412 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100407/c33b4278/attachment.diff>
[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] * notmuch-reply.c: 542e32876 introduced a superfluous { in an if statement
---
notmuch-reply.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index e69e7a4..f26ca39 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -402,7 +402,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.6.3.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [Sebastian Spaeth] Pull requests
On 2010-04-07, micah anderson wrote: The only other patch that I find absolutely crucial, that you do not include, is the 'Preserve folder information when indexing' patch which, although not perfect, does significantly change my life. This patch in included in my branch now. There is a branch with just that patch over cworth/master in http://github.com/spaetz/notmuch-all-feature/tree/issue28-search-folder-name However, testing this, it does not seem to work for me: I dumped and restored all mails, redoing my database and notmuch count folder:inbox shows 2 messages that contain folder: in their body. weird. I'll investigate. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
finding the emacs lisp after install
After this change... commit dfbec15b2388158693ab0dce0c7d348c4c5a98a5 Author: Carl Worth cwo...@cworth.org Date: Tue Apr 6 15:05:13 2010 -0700 Install emacs lisp files into a notmuch sub-directory of site-lisp. Now that we have multiple emacs-lisp source files, it's just more polite this way. ...how is emacs supposed to find these files? .../site-lisp/notmuch is not in my load-path by default (Debian GNU Emacs 23.1.1). dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] Debian package update ?
On Mon, 05 Apr 2010 08:12:51 +0200, Xavier Maillard x...@gnu.org wrote: I feel like being far behind master with my current (official) Debian package. Is there any chance to get a more recent one soon ? Hi Xavier, I did update the Debian packaging yesterday, and uploaded new packages. (The upload might take a while before it appears since it added new libnotmuch1 and libnotmuch-dev packages that will have to be approved.) It took me a while to get around to updating the Debian package because the new library meant reworking the package a bit, I wanted to do an actual tar-file release before a new package, etc. With all of that stuff implemented now, it should be a very quick process to update the packages in the future. So hopefully there won't be much skew going forward. -Carl pgpN2aRF4izUz.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: finding the emacs lisp after install
On Wed, 07 Apr 2010 12:42:21 +0100, David Edmondson d...@dme.org wrote:
After this change...
Install emacs lisp files into a notmuch sub-directory of site-lisp.
Now that we have multiple emacs-lisp source files, it's just more
polite this way.
...how is emacs supposed to find these files? .../site-lisp/notmuch is
not in my load-path by default (Debian GNU Emacs 23.1.1).
Ah, good point.
The Debian package goes through some magic (in
/etc/emacs/site-start.d/50notmuch.el) to ensure that this directory is
added to the load-path.
Given that, I've just changed the default back to just install the files
into ${prefix}/share/emacs/site-lisp and made the Debian packaging
request ${prefix}/share/emacs/site-lisp/notmuch when it configures (see
below).
Thanks for the report,
-Carl
From a7a961c510a87dc8af2842decabcbc9ecb7c1139 Mon Sep 17 00:00:00 2001
From: Carl Worth cwo...@cworth.org
Date: Wed, 7 Apr 2010 10:07:23 -0700
Subject: [PATCH] Makefile: Install emacs code to site-lisp, not
site-lisp/notmuch
And just make the Debian packaging request site-lisp/notmuch like it
wants. Otherwise, the installed files won't appear on the load-path
so won't be found by emacs.
---
configure|6 +++---
debian/rules |3 +++
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index 21780a6..959c65a 100755
--- a/configure
+++ b/configure
@@ -71,7 +71,7 @@ Fine tuning of some installation directories is available:
--includedir=DIRInstall header files to DIR [PREFIX/include]
--mandir=DIRInstall man pages to DIR [PREFIX/share/man]
--sysconfdir=DIRRead-only single-machine data [PREFIX/etc]
- --emacslispdir=DIR Elisp [PREFIX/share/emacs/site-lisp/notmuch]
+ --emacslispdir=DIR Emacs code [PREFIX/share/emacs/site-lisp]
Additional options are accepted for compatibility with other
configure-script calling conventions, but don't do anything yet:
@@ -219,9 +219,9 @@ fi
if [ -z ${EMACSLISPDIR} ]; then
if pkg-config --modversion emacs /dev/null 21; then
- EMACSLISPDIR=$(pkg-config emacs --variable sitepkglispdir)/notmuch
+ EMACSLISPDIR=$(pkg-config emacs --variable sitepkglispdir)
else
- EMACSLISPDIR='$(prefix)/share/emacs/site-lisp/notmuch'
+ EMACSLISPDIR='$(prefix)/share/emacs/site-lisp'
fi
fi
diff --git a/debian/rules b/debian/rules
index 1f6c4bb..0c20c94 100755
--- a/debian/rules
+++ b/debian/rules
@@ -2,6 +2,9 @@
%:
dh $@
+override_dh_auto_configure:
+ dh_auto-configure --emacslispdir=/usr/share/emacs/site-lisp/notmuch
+
override_dh_installdocs:
dh_installdocs
install -m644 vim/README debian/notmuch/usr/share/doc/notmuch/README.vim
--
1.7.0
pgpSFfYwrjXrl.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] fontify date in header
On Fri, 22 Jan 2010 10:45:53 -0500, Jameson Rollins jroll...@finestructure.net wrote: The date was unfairly left out of getting pretty colors in the notmuch-show header display. This fixes that grave injustice. Thanks, Jameson. This is pushed now (finally!). And thanks to Sebastian for tracking this and rebasing to the current file location. -Carl pgpKYEU6CtGVd.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCHv2] notmuch.el: colorize lines in notmuch-search based on thread tags.
On Thu, 04 Feb 2010 19:38:20 -0500, Jameson Graef Rollins jroll...@finestructure.net wrote: Arbitrary font faces can be specified for given thread tags. By default, no coloring is applied. To specify coloring, place something like this in your .emacs: (setq notmuch-search-line-faces '((delete . (:foreground red)) (unread . (:foreground green Order matters: line faces listed first will take precedence (in the example above, a thread tagged both delete and unread will be colored red, since the delete face is listed before the unread). Hi Jameson, Thanks for this patch. I just pushed it (based on what I found originally in spaetz' tree). Only after coming back here did I find that you had sent a second version that colored delete tags by default. I haven't added that part for a couple of reasons: 1. The commit message doesn't match the behavior of the patch, (it says no coloring is applied by default. 2. I think we'll go with a tag name of deleted rather than delete. I did fix up some indentation and a slightly scrambled commit message. But maybe that only existed in spaetz' tree. Finally, I checked the customization support, (M-x customize, then browse Applications-Email-Notmuch), and saw that notmuch-tag-face is much easier to customize there, (provides a drop-down value menu with buttons for modifying the face---where I couldn't even figure out how to use customize for the new notmuch-search-line-faces). Plus, I think both of these values should likely be merged into a single face-selection option, (perhaps with a separate Boolean to determine whether to highlight just the tag name or the whole line). Thanks again for the improvements, and hopefully you'll see quicker merging from me in the future. -Carl pgpPdyb5s50VE.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH] Further improvements to tag-based coloring in search.
On Sat, 6 Feb 2010 20:21:43 -0500, Aaron Ecay aarone...@gmail.com wrote: Makes the following improvements: - fix up doc strings - suppress the creation of unnecessary let-bindings - create overlays lazily (to avoid creating many overlays for threads that do not get colored) Hi Aaron, I saw this fixed-up version from you only after I'd pushed the previous one. If you could resend a new change on top of what's now in master, then that would be appreciated. Thanks, -Carl pgpytvUEK2tYV.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Fix code extracting the MTA from Received: headers
The previous code made too many assumptions about the (sadly not
standardized) format of the Received headers. This version should
be more robust to deal with different variations.
Signed-off-by: Dirk Hohndel hohn...@infradead.org
---
notmuch-reply.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/notmuch-reply.c b/notmuch-reply.c
index 8eb4754..39377e1 100644
--- a/notmuch-reply.c
+++ b/notmuch-reply.c
@@ -296,28 +296,23 @@ guess_from_received_header (notmuch_config_t *config,
notmuch_message_t *message
received = notmuch_message_get_header (message, received);
by = strstr (received, by );
if (by *(by+4)) {
- /* we know that there are 4 characters after by - either the 4th one
-* is '\0' (broken header) or it is the first letter of the hostname
-* that last received this email - which we'll use to guess the right
-* from email address
+ /* sadly, the format of Received: headers is a bit inconsistent,
+* depending on the MTA used. So we try to extract just the MTA
+* here by removing leading whitespace and assuming that the MTA
+* name ends at the next whitespace
+* we test for *(by+4) to be non-'\0' to make sure there's something
+* there at all - and then assume that the first whitespace delimited
+* token that follows is the last receiving server
*/
mta = strdup (by+4);
if (mta == NULL)
return NULL;
-
- /* After the MTA comes its IP address (or HELO response) in parenthesis.
-* so let's terminate the string there
-*/
- if ((ptr = strchr (mta, '(')) == NULL) {
- free (mta);
+ token = strtok(mta, \t);
+ if (token == NULL)
return NULL;
- }
- *ptr = '\0';
-
/* Now extract the last two components of the MTA host name
* as domain and tld
*/
- token = mta;
while ((ptr = strsep (token, delim)) != NULL) {
if (*ptr == '\0')
continue;
--
1.6.6.1
--
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [PATCH v2] notmuch.el: add functionality in notmuch search mode to add or remove tags by region
On Tue, 16 Feb 2010 19:07:40 -0500, Jesse Rosenthal jrosent...@jhu.edu wrote: This patch adds `-region' versions of the `notmuch-search-' commands to find properties. It also splits up `notmuch-add/remove-tags' into both a `-thread' and a `-region' version. (This makes us modify `notmuch-search-archive-thread' to use the `notmuch-search-remove-tag-thread' function, instead of `notmuch-search-remove-tag', for consistency.) The add/remove-tag command called by pressing `+' or `-' will then choose accordingly, based on whether region is active. This version fixes a couple of errors in the first version, which led to incorrect marking of some tags in the search view (though the actual tagging was still correct). It's also based on current master. I'm not sure any more if region selection is actually the correct way to do this, or if a mutt-style message-marking method would be better. But I didn't want a buggy incorrect version out there. I think this feature is very useful, and that the region is definitely an appropriate way to implement it, (doing region-based operations is very natural for emacs users). Mutt-style marking could be implemented as well, but that would be separate I think. I tested this patch a bit and added one small cleanup to the documentation (see below). I also don't like the duplication of code in notmuch-search-add-tag-thread and notmuch-search-add-tag-region, (and the same in the remove case). Fortunately, I think this easy to avoid by simply making notmuch-search-add-tag-thread call: (notmuch-search-add-tag-region tag (point) (point)) and the same in the remove case. But I haven't pushed this patch yet for a flaw in the case of selecting beyond the last thread, (such as selecting to the line that includes the End of search results). If I try an operation on that line, it will act like it works, (it displays the new tags by all threads), but then a refresh makes them all disappear again. Presumably the notmuch tag command is failing, this isn't being noticed, and the code marches on to update the representation of the tags. And presumably the notmuch tag is failing because no thread ID is found for the last line, so the mapconcat call is sticking an extra or onto the end of the search string. And Xapian doesn't like that: $ notmuch search tag:inbox or A Xapian exception occurred performing query: Syntax: expression OR expression Query string was: tag:inbox or Things behave even worse if I make the region be the entire buffer, (including the last blank line). Then the commands hang. I got nervous that this was then adding or or and trying to add/remove a tag to every message containing the word or. But I haven't looked closely. If we can fix this bug, then I'd like to apply this patch. I'd even like to fix the * binding to be implemented in terms of something like these functions so that we could get visual updates of the tag state From that command. (But that will take some reworking of the interface as the current implementation can't support multiple tags added/removed as * current expects). I'd appreciate any help fixing up the patch. -Carl From fec5622add1a4e9f305c16e96143439ee22a5c58 Mon Sep 17 00:00:00 2001 From: Carl Worth cwo...@cworth.org Date: Wed, 7 Apr 2010 13:15:27 -0700 Subject: [PATCH] emacs: Correct the documentation for notmuch-search-add-tag (and -remove-tag) These commands act on all messages in the thread, not simply those that match the search. (There are use case for both behaviors, but the documentation must match the behavior that's actually implemented). --- emacs/notmuch.el |9 - 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index 64f3e3d..517c53a 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -532,12 +532,11 @@ and will also appear in a buffer named \*Notmuch errors*\. (notmuch-search-set-tags (delete tag (notmuch-search-get-tags))) (forward-line)) - (defun notmuch-search-add-tag (tag) Add a tag to the currently selected thread or region. -The tag is added to messages in the currently selected thread or -region which match the current search terms. +The tag is added to all messages in the currently selected thread +or threads in the current region. (interactive (list (notmuch-select-tag-with-completion Tag to add: ))) (save-excursion @@ -550,8 +549,8 @@ region which match the current search terms. (defun notmuch-search-remove-tag (tag) Remove a tag from the currently selected thread or region. -The tag is removed from all messages in the currently selected thread -or region which match the current search terms. +The tag is removed from all messages in the currently selected +thread or threads in the current region. (interactive (list (notmuch-select-tag-with-completion Tag to remove: -- 1.7.0 pgp41vW41l44Q.pgp Description: PGP signature
Re: [notmuch] [PATCH] notmuch-new: Respect maildir flags when importing a new message
On Mon, 1 Mar 2010 14:28:56 +0100, Sebastian Spaeth sebast...@sspaeth.de wrote: When importing a new mail do check for maildir tags and assign corresponding notmuch tags. I think this is a useful thing to support, as obviously new users have *some* state that's interesting to import (which messages have been seen for example), and simply importing their entire email archive with both the inbox and unread tags is not helpful. So I'd like to figure out how to support this. Do note that this will only add tags when importing a really new message, and will not do anything when detecting a file rename (although someone should really make it honor file renames as well). Deleteing an existing message in another IMAP client will therefore not trigger tagging (as it counts as a file rename). But I think we really need to fix that if we're going to claim that notmuch supports maildir flags in any sense. It's a fairly tricky issue though since we can have multiple files that have the same message ID, but then have different maildir flags. And it's the matter of arbitrary ordering which one of these files appears as new and which one appears as a rename. It's not obvious to me what we can do here unless we make some assumptions, (such as mails always start without the seen flag, and once it appears it can't be removed or so). But I'd love some input From someone who's thought harder about this than I have. -Carl pgpBtB2rYwe91.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [Sebastian Spaeth] Pull requests
On Mon, 01 Mar 2010 15:57:00 +0100, Sebastian Spaeth sebast...@sspaeth.de wrote: From git repository git://github.com/spaetz/notmuch-all-feature.git I would like to advocate the following branches for quick pulling. Each contains 1 or 2 patches. They have all been based on todays cworth/master, so it should be really painless. Thanks Sebastian, both for pulling these together and mentioning them here. I've now gone through everything in this list and either merged the patch or asked for further work, (and in either case I've replied to one of the original messages proposing the patch). Keep up the good work! -Carl pgpp9GgjlgbM4.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [notmuch] [Sebastian Spaeth] Pull requests
On Thu, 25 Mar 2010 22:50:52 -0400, micah anderson mi...@riseup.net wrote: The only other patch that I find absolutely crucial, that you do not include, is the 'Preserve folder information when indexing' patch which, although not perfect, does significantly change my life. This, (along with allow mailing-list headers to be indexed), is near the top of my mental todo list for notmuch. The trick with these is to smoothly do the re-indexing for people that aren't building an index From scratch, (or providing a notmuch upgrade command to do that when convenient or so). I'll have to give that some thought. -Carl pgpTI6ogJau8S.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Plans for the 0.2 release (this week)
We've obviously got a lot of interest in notmuch, and a huge pile of features that need to be merged. I think that means we're in a state where we can have extremely regular releases, with continually improving feature sets. I'm thinking releases once per week or so. With each release, I expect people to remind me of their favorite features that haven't been merged, (while I'll continue to work through any backlog on my own). For the upcoming 0.2 release, here are some things that I would like to have in place: * Any further changes from the Sebastian's repository. Sebastian, I worked through one list I saw recently. Do you have another list to propose yet? * The big batch of emacs-client improvements from David E.'s repository. David, do you have particular things to recommend here? * Changes to indexing, (addition of body:, folder:, list:, etc.). This is stuff that I'll work on. * Some library additions (move_to_first for the iterators, and perhaps a notmuch_database_add_message_with_data which Srinivasa requested to support integration of notmuch into evolution). I'll work on these as well, (I know that there are patches for some of these on the list already). * Anything else that people want, (especially things that already exist and that you're already using). Support for maildir flags on import would be great here. I'm still waiting to see a complete solution I think. So keep the patches coming, and the pointers to patches that you want me to look at. -Carl pgpR9r5IVd67N.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Plans for the 0.2 release (this week)
On Wed, 07 Apr 2010 15:12:44 -0700, Carl Worth cwo...@cworth.org wrote: * Anything else that people want, (especially things that already exist and that you're already using). Support for maildir flags on import would be great here. I'm still waiting to see a complete solution I think. id:1268515677-12692-1-git-send-email-jw+deb...@jameswestby.net I've been running with this locally since then with no apparent issues. It will make anyone who suffers from this problem regularly pretty happy, as they can return to the world of a thread-based mail client. Thanks, James ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Derive version numbers from git
On Tue, 06 Apr 2010 18:11:28 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: On Tue, 06 Apr 2010, Sebastian Spaeth wrote: But, there are people without git installed that download the release tarball. So if this patch makes it, we need to replace this with a static version number when baking a release tar. Right, here is an updated patch. It's more complicated than the previous one, but it solves the issue. I like this idea, definitely. But the other piece needed here is a way for me to be able to specify a version in order to release. In my current release instructions (notmuch/RELEASING) I do that by manually incrementing the version number in the Makefile. Then a tag is created later when the make release target runs. It would be possible for me to instead create the tag to specify the version, but there's a few things I don't like about this: 1. After I increment the version number (early in the release process) I often find one or two little things I need to change to make the release perfect. So there are likely more commits later, but I obviously don't want some git-describe version to end up in the final tar file. 2. I don't actually want to create a tag, (I *especially* don't want to push it), until the release actually happens. That's the point of the tag in my view, (to say *this* is what I released), so making the tag early seems wrong, (and leaves the door open to make mistakes). Any suggestion for this part? +include Makefile.version + +.PHONY: Makefile.version +Makefile.version: + echo VERSION=$(if $(wildcard version),`cat version`,`git describe --dirty`) $@ Could that be simplified to just use $(shell) rather than a separate file and an include? I suppose what we could do is to just have the creation of the version file be part of the release process. That would be simple enough. Then we could drop this rule: +version: + git describe $@ What do you think? -Carl pgpi44BjuRLiB.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Fix code extracting the MTA from Received: headers
On Wed, 07 Apr 2010 13:38:29 -0700, Dirk Hohndel hohn...@infradead.org wrote: The previous code made too many assumptions about the (sadly not standardized) format of the Received headers. This version should be more robust to deal with different variations. Thanks for maintaining this. I'll have to fiddle with my mail setup before this feature is useful for me. So I haven't tested this, (other than to verify that it hasn't broken notmuch reply for me). But I've pushed this now at least. -Carl pgpF2JAnApaj7.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Fix the default value for --includedir.
On Wed, 7 Apr 2010 11:48:31 -0400, Mike Kelly pi...@pioto.org wrote:
-includedir = ${INCLUDEDIR:=\$(prefix)/lib}
+includedir = ${INCLUDEDIR:=\$(prefix)/include}
Yikes! That's pretty embarrassing.
(I probably would have noticed in the Debian package, but debhelper
automatically passes an explicit --includedir that happens to match what
should have been the default here before).
Thanks for this fix. This is pushed.
-Carl
pgp9wrBsfoP4G.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] notmuch.el: 'F' in search mode takes us to a list of folders.
On Sat, 27 Feb 2010 08:49:06 +0100, Sebastian Spaeth sebast...@sspaeth.de wrote: From: David Edmondson d...@dme.org --- Dear Carl, I start out notmuch in my inbox search, but find myself navigating to the notmuch-folder view quite often. Therefore the key binding 'F' to open a notmuch-folder is really handy. I agree that a single-key binding for this is really handy. I'm actually currently using super-n (a personal customization I have) to get to notmuch-folder view from *any* buffer in emacs. And I want to make a (cleaned-up) version of notmuch-folder be the starting point for notmuch, (rather than the inbox view). And I also want to make the 'q' binding more clever so that instead of just closing the current view it will actually return to the parent view. That would make 'q' be a single-key binding from most search views (unfiltered ones at least) to the notmuch-folder view. But that's all future ideas---back to the current patch. I don't really like the keybinding of 'F' for this. We've mostly avoided capitalized bindings so far, (we have quite a few lowercase bindings available after all). The few we have are all alternate versions of the lowercase version, (N = next message vs. 'n' = next unread message). Since F = folder-view is unrelated to 'f' = filter, I'd like to avoid that. Also, I think we need a better name for notmuch-folder view anyway. We have an outstanding patch to make the filesystem-directory of mail messages available with a search syntax of folder:. So there's a conceptual clash of folder there already. So maybe this view needs a name like home or even just notmuch? Like I said, I would like to make my cleaned-up version (see TODO for a mockup) be the view that one gets with M-x notmuch. -Carl pgp4j5wuac6ok.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
