Re: [notmuch] Bulk message tagging
On Sat, 10 Apr 2010 15:56:48 +0200, Xavier Maillard wrote: > On Tue, 6 Apr 2010 13:51:01 -0600, Mark Anderson > wrote: > > > > I think that '*' is definitely an awesome command, but I wonder if we > > shouldn't have another command for the notmuch-search buffer which means > > 'tag all the threads that I can see in this buffer'. > > This is exactly what my initial post asked for. '*' is not > totally satisfying for me due to the "limitations" you > exposed. Though It is a good and acceptable workaround for me. > As said, I just have to pay attention to redo my search query > before pressing the '*' key. The other bug with "*" is that it doesn't give any visual feedback, (the tag addition/deletion doesn't show up). We could fix all[*] the bugs of "*" by changing it to simply call the new region-based tagging function. The only concern I have with that is that it might be significantly slower, (it will execute N "notmuch tag" commands to tag the N threads in the current buffer, rather than just one "notmuch tag" command with the same search). But the command-line based "notmuch tag +/- " will always still be available for true "bulk" tagging, so maybe having "*" in emacs be implemented the slower way would be fine. I think the biggest concern I have with the performance is that if it *is* too slow, then the user might interrupt it with emacs, and with the current implementation that would lead to inconsistent display. That's not specific to "*" though---that's a bug with the current region-based implementation---it's just that "*" might make it much easier to hit. -Carl [*] Most all the bugs, at least. Even just a simple 'a' (or '+' or '-') on a single thread is already doing something subtly different than it should. It's tagging all messages in the thread, but that might be more messages than existed when the thread-summary was created. So you might see: [1/1] A. Bozo Boring topic... and decide to archive the thread, and never realize that what you archived away was several messages that would have been displayed as: [3/3] A Bozo, B Wizard, C WizardBoring topic... [**] if you had only refreshed first. So we really should fix that bug and only manipulate messages that were actually present when the search was performed. Note that 'a' inside of the show view does not have this bug---it does only affect messages displayed. I'm not currently afflicted by this bug only because I'm running "notmuch new" manually, before mail-reading sessions as opposed to inside a cron-job or similar. [**] This is similar to the "thread pattern" idea described by Joey Hess here: http://kitenet.net/~joey/blog/entry/thread_patterns/ Our current one-line presentation of threads does a really lousy job of letting the user see thread patterns like this. We should perhaps come up with something better. One "something better" I have in mind would be the ability to write searches that could identify and tag threads according to these patterns. Our current search syntax isn't powerful enough to express these kinds of relations about messages within threads, but I would be very interested in coming up with something that does. The parts that Xapian can't easily support here probably wouldn't have to be fast either---they could operate on the results of threads, which are generally "small". At least, I hope nobody has threads with hundreds of thousands of messages in them. pgpneUsDryEIx.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Bulk message tagging
On Sat, 10 Apr 2010 15:56:48 +0200, Xavier Maillard wrote: > On Tue, 6 Apr 2010 13:51:01 -0600, Mark Anderson > wrote: > > > > I think that '*' is definitely an awesome command, but I wonder if we > > shouldn't have another command for the notmuch-search buffer which means > > 'tag all the threads that I can see in this buffer'. > > This is exactly what my initial post asked for. '*' is not > totally satisfying for me due to the "limitations" you > exposed. Though It is a good and acceptable workaround for me. > As said, I just have to pay attention to redo my search query > before pressing the '*' key. The other bug with "*" is that it doesn't give any visual feedback, (the tag addition/deletion doesn't show up). We could fix all[*] the bugs of "*" by changing it to simply call the new region-based tagging function. The only concern I have with that is that it might be significantly slower, (it will execute N "notmuch tag" commands to tag the N threads in the current buffer, rather than just one "notmuch tag" command with the same search). But the command-line based "notmuch tag +/- " will always still be available for true "bulk" tagging, so maybe having "*" in emacs be implemented the slower way would be fine. I think the biggest concern I have with the performance is that if it *is* too slow, then the user might interrupt it with emacs, and with the current implementation that would lead to inconsistent display. That's not specific to "*" though---that's a bug with the current region-based implementation---it's just that "*" might make it much easier to hit. -Carl [*] Most all the bugs, at least. Even just a simple 'a' (or '+' or '-') on a single thread is already doing something subtly different than it should. It's tagging all messages in the thread, but that might be more messages than existed when the thread-summary was created. So you might see: [1/1] A. Bozo Boring topic... and decide to archive the thread, and never realize that what you archived away was several messages that would have been displayed as: [3/3] A Bozo, B Wizard, C WizardBoring topic... [**] if you had only refreshed first. So we really should fix that bug and only manipulate messages that were actually present when the search was performed. Note that 'a' inside of the show view does not have this bug---it does only affect messages displayed. I'm not currently afflicted by this bug only because I'm running "notmuch new" manually, before mail-reading sessions as opposed to inside a cron-job or similar. [**] This is similar to the "thread pattern" idea described by Joey Hess here: http://kitenet.net/~joey/blog/entry/thread_patterns/ Our current one-line presentation of threads does a really lousy job of letting the user see thread patterns like this. We should perhaps come up with something better. One "something better" I have in mind would be the ability to write searches that could identify and tag threads according to these patterns. Our current search syntax isn't powerful enough to express these kinds of relations about messages within threads, but I would be very interested in coming up with something that does. The parts that Xapian can't easily support here probably wouldn't have to be fast either---they could operate on the results of threads, which are generally "small". At least, I hope nobody has threads with hundreds of thousands of messages in them. -- 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/20100414/f9030af5/attachment.pgp>
Re: [notmuch] [PATCH] Store thread ids for messages that we haven't seen yet
On Tue, 13 Apr 2010 16:36:30 +0100, James Westby wrote: > Your choice. I prefer putting them in the same commit to be more > self-documenting, and then using the capabilities of my VCS to verify > the change if i desire. But that's my point. With it split, I can actually use "git checkout" to go to a state where the test exists, but the bug hasn't been fixed. With it combined, there's no such state. (I can checkout state with the bug, but then there's nothing in the test suite to exercise it.) > This would fix up threads for all existing messages? Yes. It seems un-right for notmuch to provide a feature on an arbitrary subset of messages, (those that happened to be added after the user switched to some particular version of notmuch). > Probably a good thing to have, but not that important to me. In my > case I can always open the bug in my browser if I want to see the full > conversation. I agree it's not totally essential. But it should be easy enough to pick up in the upcoming database upgrade, (which may actually end up being a full rebuild anyway---I've got a lot of things to change and a full rebuild might be the fastest thing to do). -Carl pgpSqnEEPjtyT.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] Store thread ids for messages that we haven't seen yet
On Tue, 13 Apr 2010 16:36:30 +0100, James Westby wrote: > Your choice. I prefer putting them in the same commit to be more > self-documenting, and then using the capabilities of my VCS to verify > the change if i desire. But that's my point. With it split, I can actually use "git checkout" to go to a state where the test exists, but the bug hasn't been fixed. With it combined, there's no such state. (I can checkout state with the bug, but then there's nothing in the test suite to exercise it.) > This would fix up threads for all existing messages? Yes. It seems un-right for notmuch to provide a feature on an arbitrary subset of messages, (those that happened to be added after the user switched to some particular version of notmuch). > Probably a good thing to have, but not that important to me. In my > case I can always open the bug in my browser if I want to see the full > conversation. I agree it's not totally essential. But it should be easy enough to pick up in the upcoming database upgrade, (which may actually end up being a full rebuild anyway---I've got a lot of things to change and a full rebuild might be the fastest thing to do). -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/20100414/b51d2e50/attachment.pgp>
Re: [PATCH] First tests for JSON output and UTF-8 in mail body and subject
On Tue, 13 Apr 2010 18:37:57 +0200, Gregor Hoffleit wrote:
> The test suite doesn't yet cover --format=json output nor UTF-8 in
> subject or body.
>
> This patch starts with test cases for 'search --format=json' and
> 'show --format=json'.
Thanks for the tests, Gregor!
I was about to push this, but first noticed that I hadn't run the test
suite in the last day and that it had recently broken (oops!). I fixed
that, but then also noticed that I got failures with your tests.
> +execute_expecting "show --format=json 'json-show-message'" '[[[{"id":
> "'${gen_msg_id}'", "match": true, "filename": "'${gen_msg_filename}'",
> "date_unix": 946728000, "date_relative": "2000-01-01", "tags":
...
> +printf " Search message: json...\t"
> +add_message '[subject]="json-search-subject"' '[date]="Sat, 01 Jan 2000
> 12:00:00 -"' '[body]="json-search-message"'
> +execute_expecting "search --format=json 'json-search-message'" '[{"thread":
> "XXX",
> +"timestamp": 946724400,
I'm getting a timestamp value here of 946756800 which is clearly an
interpretation of the above date as if it were my local time zone. That
is:
$ date -u +%s -d "Sat, 01 Jan 2000 12:00:00 -0800"
946756800
And the value you have appears to have been generated in your timezone:
$ date -u +%s -d "Sat, 01 Jan 2000 12:00:00 +0100"
946724400
Meanwhile, the value that should be printed here[*] is the value from
interpreting the original date in the timezone explicitly specified in
that date:
$ date -u +%s -d "Sat, 01 Jan 2000 12:00:00 -"
946728000
Note that the "notmuch show --format=json" test above does have the
correct timestamp.
So, a double thanks for this test, it seems to have uncovered another
bug.
-Carl
[*] I say "should" because I don't believe we have any actual
specification of the data coming out of the JSON output yet. One other
thing that seems odd is the name of "date_unix" in the show output and
"timestamp" in the search output for what is effectively the same
field.
pgphtAic9g2Ul.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] First tests for JSON output and UTF-8 in mail body and subject
On Tue, 13 Apr 2010 18:37:57 +0200, Gregor Hoffleit
wrote:
> The test suite doesn't yet cover --format=json output nor UTF-8 in
> subject or body.
>
> This patch starts with test cases for 'search --format=json' and
> 'show --format=json'.
Thanks for the tests, Gregor!
I was about to push this, but first noticed that I hadn't run the test
suite in the last day and that it had recently broken (oops!). I fixed
that, but then also noticed that I got failures with your tests.
> +execute_expecting "show --format=json 'json-show-message'" '[[[{"id":
> "'${gen_msg_id}'", "match": true, "filename": "'${gen_msg_filename}'",
> "date_unix": 946728000, "date_relative": "2000-01-01", "tags":
...
> +printf " Search message: json...\t"
> +add_message '[subject]="json-search-subject"' '[date]="Sat, 01 Jan 2000
> 12:00:00 -"' '[body]="json-search-message"'
> +execute_expecting "search --format=json 'json-search-message'" '[{"thread":
> "XXX",
> +"timestamp": 946724400,
I'm getting a timestamp value here of 946756800 which is clearly an
interpretation of the above date as if it were my local time zone. That
is:
$ date -u +%s -d "Sat, 01 Jan 2000 12:00:00 -0800"
946756800
And the value you have appears to have been generated in your timezone:
$ date -u +%s -d "Sat, 01 Jan 2000 12:00:00 +0100"
946724400
Meanwhile, the value that should be printed here[*] is the value from
interpreting the original date in the timezone explicitly specified in
that date:
$ date -u +%s -d "Sat, 01 Jan 2000 12:00:00 -"
946728000
Note that the "notmuch show --format=json" test above does have the
correct timestamp.
So, a double thanks for this test, it seems to have uncovered another
bug.
-Carl
[*] I say "should" because I don't believe we have any actual
specification of the data coming out of the JSON output yet. One other
thing that seems odd is the name of "date_unix" in the show output and
"timestamp" in the search output for what is effectively the same
field.
-- 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/20100414/d55ee234/attachment.pgp>
[PATCH] allow to not sort the search results
Sebastian Spaeth wrote: > previously we were always sorting the returned results by some string value, > but sometimes we might just be interested in the number of results, and don't > need any sorting. > > Also add a --sort=unsorted command line option to notmuch search to test this. Does this provide relevance-ranked search results? I think relevance ranking is the Xapian default if a sort order isn't specified. It would be useful to be able to obtain a relevance-ranked list of messages or threads that satisfy a query.
Re: [PATCH 3/4] Add infrastructure for building shared library on OS X.
On Wed, 14 Apr 2010 11:01:58 -0700, Carl Worth wrote: > > +printf "Checking for Mac OS X (for shared library)... " > > +if [ `uname` = "Darwin" ] ; then > > +printf "Yes.\n" > > +mac_os_x=1 > > +else > > +printf "No.\n" > > +mac_os_x=0 > > +fi > > + > > Instead of inventing a new mac_os_x variable, we should follow the GNU > configure conventions of build_cpu, build_vendor, build_os > variables. I've gone ahead and pushed the above. We can still fix to use build_os internally instead of mac_os_x, but that's fairly cosmetic. I also pushed out my own version of the fix for FINAL_NOTMUCH_LDFLAGS, (which does the extra linking on OS X, but not Linux). Please, anyone that's interested, test notmuch on your favorite platforms and let us know what's still broken. I did do a little testing and research with the OS X machine I could find here, but I'm no expert, nor do I have access to many other systems. -Carl pgp5KaTNYNPiJ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 3/4] Add infrastructure for building shared library on OS X.
On Wed, 14 Apr 2010 11:01:58 -0700, Carl Worth wrote: > > +printf "Checking for Mac OS X (for shared library)... " > > +if [ `uname` = "Darwin" ] ; then > > +printf "Yes.\n" > > +mac_os_x=1 > > +else > > +printf "No.\n" > > +mac_os_x=0 > > +fi > > + > > Instead of inventing a new mac_os_x variable, we should follow the GNU > configure conventions of build_cpu, build_vendor, build_os > variables. I've gone ahead and pushed the above. We can still fix to use build_os internally instead of mac_os_x, but that's fairly cosmetic. I also pushed out my own version of the fix for FINAL_NOTMUCH_LDFLAGS, (which does the extra linking on OS X, but not Linux). Please, anyone that's interested, test notmuch on your favorite platforms and let us know what's still broken. I did do a little testing and research with the OS X machine I could find here, but I'm no expert, nor do I have access to many other systems. -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/20100414/b61d1a1b/attachment.pgp>
[PATCH] Fix bug, and clean up code duplication, in adding or removing tag by region.
On Wed, 14 Apr 2010 10:14:46 -0700, Carl Worth wrote:
> The only real problem I see with this approach is that it's fragile in
> depending on the buffer having exactly 2 lines of non-thread text at the
> end. I can easily see myself wanting to remove the "End of Search
> Results" line at the end of the buffer. And if I do that, this code will
> break, (tag manipulations will miss the last message).
I was a bit worried about that myself. I hard-coded the 2 based on the
hard-coding in `notmuch-search-last-thread' (">"), which currently goes
to the bottom and then goes up two lines. But it seems like if there
were a more robust approach, it could be used in both.
> A more robust fix would check for the ability to read a thread
> ID. So making a single function such as
> notmuch-search-find-last-line-with-thread-id or so would do the trick
> here.
It occurs to me that the best way to do this would probably be to go to
point-max, and then (forward-line -1) until we hit a thread-id. That way
we wouldn't have to work all the way down long search indexes. I'll try
to code that up for the next release, and then have
notmuch-search-last-thread use it, as well as the region functions.
Best,
Jesse
[PATCH] Fix bug, and clean up code duplication, in adding or removing tag by region.
On Wed, 14 Apr 2010 12:50:50 -0500, Jesse Rosenthal wrote: > It occurs to me that the best way to do this would probably be to go to > point-max, and then (forward-line -1) until we hit a thread-id. That way > we wouldn't have to work all the way down long search indexes. I'll try > to code that up for the next release, and then have > notmuch-search-last-thread use it, as well as the region functions. This sounds great, just be careful if this command is run before the buffer has completed loading, as you could be in the middle of a search instead of the end. AFAIK, with the "asynchronous" buffer loading, there's no guarantee that point-max is the end of the search until the other thread has exited. Again, my lisp-fu is very poor, but just a concern I see. -Mark
Re: [PATCH] Fix bug, and clean up code duplication, in adding or removing tag by region.
On Wed, 14 Apr 2010 12:50:50 -0500, Jesse Rosenthal wrote: > It occurs to me that the best way to do this would probably be to go to > point-max, and then (forward-line -1) until we hit a thread-id. That way > we wouldn't have to work all the way down long search indexes. I'll try > to code that up for the next release, and then have > notmuch-search-last-thread use it, as well as the region functions. This sounds great, just be careful if this command is run before the buffer has completed loading, as you could be in the middle of a search instead of the end. AFAIK, with the "asynchronous" buffer loading, there's no guarantee that point-max is the end of the search until the other thread has exited. Again, my lisp-fu is very poor, but just a concern I see. -Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Next attempt to get guessing of From addresses correct in replies
On Wed, 14 Apr 2010 10:21:42 -0700, Carl Worth wrote:
> On Fri, 09 Apr 2010 15:53:04 -0700, Dirk Hohndel
> wrote:
> > + * WARNING - if the caller is asking for a header that could occur
> > + * multiple times than they MUST first call this function with a
> > + * a value of NULL for header_desired to ensure that all of the
> > + * headers are parsed and concatenated before a match is returned
> ...
> > + } else {
> > + /* not sure this makes sense for all headers that can occur
> > +* multiple times, but for now just concatenate headers
> > +*/
> > + newhdr = strlen(decoded_value);
> > + hdrsofar = strlen(header_sofar);
>
> I'm a little nervous about this semantic change.
So am I - but I haven't found a message where this would have bitten me.
> For example, I know that my mail collection contains at least some
> messages with multiple Message-ID headers, (I'm not sure that's legal,
> but they are there).
No, that is absolutely NOT RFC compliant. Wonder what creates those
messages...
> I found those when doing detailed comparisons of
> the database created by sup with that created by very early versions of
> what became the indexing code for notmuch. [Sup prefers the
> last-encountered Message-Id in the file, while Notmuch prefers the
> first.]
Actually, prior to another fix that I sent (and that you already
applied), notmuch would use the first if you came across this header for
the first time when searching for it (but since you'd search for
Message-Id fairly early on, that's likely what happened). But if your
header was remembered "en-passant" while searching for a different
header later in the file, notmuch would actually remember the last.
But again, I fixed that before making the change to concatenate
duplicates instead.
> So I'm concerned about the change above introducing subtle problems that
> might be hard to notice.
Yes, absolutely - a concatenated Message-Id would SUCK.
> How about an argument that asks explicitly for concatenated header
> values, (and this could just trigger a rescan of the headers and ignore
> the hash). I think that will be fine for your use case where you're just
> opening this message file to get this one concatenated header out,
> right?
That would work just fine. And avoid the potential unintended side
effects.
I'm about to head for the airport - do you want to make that
modification yourself or should I do it tonight?
/D
--
Dirk Hohndel
Intel Open Source Technology Center
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Next attempt to get guessing of From addresses correct in replies
On Wed, 14 Apr 2010 10:21:42 -0700, Carl Worth wrote:
> On Fri, 09 Apr 2010 15:53:04 -0700, Dirk Hohndel
> wrote:
> > + * WARNING - if the caller is asking for a header that could occur
> > + * multiple times than they MUST first call this function with a
> > + * a value of NULL for header_desired to ensure that all of the
> > + * headers are parsed and concatenated before a match is returned
> ...
> > + } else {
> > + /* not sure this makes sense for all headers that can occur
> > +* multiple times, but for now just concatenate headers
> > +*/
> > + newhdr = strlen(decoded_value);
> > + hdrsofar = strlen(header_sofar);
>
> I'm a little nervous about this semantic change.
So am I - but I haven't found a message where this would have bitten me.
> For example, I know that my mail collection contains at least some
> messages with multiple Message-ID headers, (I'm not sure that's legal,
> but they are there).
No, that is absolutely NOT RFC compliant. Wonder what creates those
messages...
> I found those when doing detailed comparisons of
> the database created by sup with that created by very early versions of
> what became the indexing code for notmuch. [Sup prefers the
> last-encountered Message-Id in the file, while Notmuch prefers the
> first.]
Actually, prior to another fix that I sent (and that you already
applied), notmuch would use the first if you came across this header for
the first time when searching for it (but since you'd search for
Message-Id fairly early on, that's likely what happened). But if your
header was remembered "en-passant" while searching for a different
header later in the file, notmuch would actually remember the last.
But again, I fixed that before making the change to concatenate
duplicates instead.
> So I'm concerned about the change above introducing subtle problems that
> might be hard to notice.
Yes, absolutely - a concatenated Message-Id would SUCK.
> How about an argument that asks explicitly for concatenated header
> values, (and this could just trigger a rescan of the headers and ignore
> the hash). I think that will be fine for your use case where you're just
> opening this message file to get this one concatenated header out,
> right?
That would work just fine. And avoid the potential unintended side
effects.
I'm about to head for the airport - do you want to make that
modification yourself or should I do it tonight?
/D
--
Dirk Hohndel
Intel Open Source Technology Center
[PATCH] emacs: when archiving move the cursor depending on the sort order.
On 2010-04-14, Michal Sojka wrote: > On Tue, 13 Apr 2010, Servilio Afre Puentes wrote: > > The current hardcoded behaviour will not take you to the next unread > > thread when the sort order is set to newer-first from the default of > > older-first. > > Is this really what we want? If I sort messages by newest first, it > menas that I want to process my emails from the newest to the oldest. > I'm satisfied with the current behavour. Agreed, I would be very surprised to get a different behavior.
[PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header
On 2010-04-14, David Edmondson wrote: > This really should be done with `define-mail-user-agent' and associated > paraphernalia. Which might be correct but beyond what I can provide :). So, either we take this and get a followup patch, or someone improves it, or we drop it. Sebastian
Re: [PATCH 3/4] Add infrastructure for building shared library on OS X.
On Wed, 14 Apr 2010 11:01:58 -0700, Carl Worth wrote: > On Sun, 11 Apr 2010 19:44:53 -0400, Aaron Ecay wrote: > > -include $(subdirs:%=%/Makefile.local) Makefile.local > > +include Makefile.config $(subdirs:%=%/Makefile.local) Makefile.local > > This first hunk looks unrelated to what's described in the commit > message. Indeed, on further testing this looks like it should have been part of the previous commit that includes the sub-directory Makefile.local files before the top-level Makefile.local. Without this piece, I was seeing the various compat/*.c files being compiled unconditionally. > But I'd be willing to accept that if necessary---should just remove the > include of Makefile.config from Makefile.local then I think. I've gone ahead and done that now. I moved everything concerning Makefile.config, (dependency, include, and generation), from Makefile.local up to the top-level Makefile. -Carl pgpq5m9BvnVEh.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 3/4] Add infrastructure for building shared library on OS X.
On Wed, 14 Apr 2010 11:01:58 -0700, Carl Worth wrote: > On Sun, 11 Apr 2010 19:44:53 -0400, Aaron Ecay wrote: > > -include $(subdirs:%=%/Makefile.local) Makefile.local > > +include Makefile.config $(subdirs:%=%/Makefile.local) Makefile.local > > This first hunk looks unrelated to what's described in the commit > message. Indeed, on further testing this looks like it should have been part of the previous commit that includes the sub-directory Makefile.local files before the top-level Makefile.local. Without this piece, I was seeing the various compat/*.c files being compiled unconditionally. > But I'd be willing to accept that if necessary---should just remove the > include of Makefile.config from Makefile.local then I think. I've gone ahead and done that now. I moved everything concerning Makefile.config, (dependency, include, and generation), from Makefile.local up to the top-level Makefile. -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/20100414/86b68882/attachment.pgp>
Re: [PATCH] Add strcasestr v.3 - add compat implementation of strcasestr
On Tue, 13 Apr 2010 13:05:08 -0700, Dirk Hohndel wrote:
> On Tue, 13 Apr 2010 20:47:02 +0200, Tomas Carnecky wrote:
> > On 4/13/10 6:47 PM, Dirk Hohndel wrote:
> > > v.3 of this patch, now with the changes to makefiles, configure script
> > > compat.h and all new files that I need
> > > Please test on platforms lacking strcasestr
...
> > Tested-by: Tomas Carnecky
>
> Thanks Tomas, I really appreciate it.
Thanks to both Dirk and Thomas for this portability fix.
I've pushed it now, with a few minor changes:
* Delete trailing whitespace
* Add include of "compat.h" from strcasestr.c
* Use original commit message from Dirk
Dirk, the commit message you sent with version 1 of the patch was
perfect. When you send followup patches, please leave a good commit
message as the initial content of the email. Then add any explanatory
text, ("v.3 of this patch...", "Please test..."), in the email *after*
the "---" separator (just before the diffstat). That way it won't become
part of the commit message and our indelible history.
For now, I manually touched things up, but it would be nice to not have
to do that in the future.
Thanks!
-Carl
pgpfa8cEQzk6u.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add strcasestr v.3 - add compat implementation of strcasestr
On Tue, 13 Apr 2010 13:05:08 -0700, Dirk Hohndel
wrote:
> On Tue, 13 Apr 2010 20:47:02 +0200, Tomas Carnecky
> wrote:
> > On 4/13/10 6:47 PM, Dirk Hohndel wrote:
> > > v.3 of this patch, now with the changes to makefiles, configure script
> > > compat.h and all new files that I need
> > > Please test on platforms lacking strcasestr
...
> > Tested-by: Tomas Carnecky
>
> Thanks Tomas, I really appreciate it.
Thanks to both Dirk and Thomas for this portability fix.
I've pushed it now, with a few minor changes:
* Delete trailing whitespace
* Add include of "compat.h" from strcasestr.c
* Use original commit message from Dirk
Dirk, the commit message you sent with version 1 of the patch was
perfect. When you send followup patches, please leave a good commit
message as the initial content of the email. Then add any explanatory
text, ("v.3 of this patch...", "Please test..."), in the email *after*
the "---" separator (just before the diffstat). That way it won't become
part of the commit message and our indelible history.
For now, I manually touched things up, but it would be nice to not have
to do that in the future.
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/20100414/4e92d887/attachment.pgp>
[PATCH 1/1] Stores the folder (directory name) of the message in the database as a term with folder prefix.
This patch was originally sent by Andreas Kl?ckner in:
id:200912141421.52561.lists at informa.tiker.net. It was then
subsequently updated by Michal Sojka in:
id:1264692317-9175-2-git-send-email-sojkam1 at fel.cvut.cz and then
further improved again by Michal Sojka in:
id:1265122868-12133-1-git-send-email-sojkam1 at fel.cvut.cz
This is a rebase of the latest patch off of the current git HEAD.
. The differences from the original patch are:
- Rebased off of current git HEAD
- Folder name is taken from strings generated during travesal. It no
longer uses glib nor it allocates additional memory to determine the
base name. The same approach as in
id:87fx8bygi7.fsf at linux.vnet.ibm.com was used.
- Removed unrelated change which was submitted separately as
id:1264691584-8290-2-git-send-email-sojkam1 at fel.cvut.cz
- Changed the comment describing database schema.
TODO (see Carl's email: id:87zl5k0w6s.fsf at yoom.home.cworth.org):
- Support hierarchical folders: this patch is only storing the final
directory component. This should be hooked in differently with
filename storage so the whole filename is indexed as text to
provide arbitrary search phrases such as "folder:'foo/bar/baz'"
---
lib/database.cc | 13 +
lib/notmuch.h |1 +
notmuch-new.c | 39 +--
3 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index c91e97c..6364623 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -84,9 +84,9 @@ typedef struct {
* MESSAGE_ID: The unique ID of the mail mess (see "id" above)
*
* In addition, terms from the content of the message are added with
- * "from", "to", "attachment", and "subject" prefixes for use by the
- * user in searching. But the database doesn't really care itself
- * about any of these.
+ * "from", "to", "attachment", "subject" and "folder" prefixes for use
+ * by the user in searching. But the database doesn't really care
+ * itself about any of these.
*
* The data portion of a mail document is empty.
*
@@ -155,7 +155,8 @@ prefix_t PROBABILISTIC_PREFIX[]= {
{ "from", "XFROM" },
{ "to","XTO" },
{ "attachment","XATTACHMENT" },
-{ "subject", "XSUBJECT"}
+{ "subject", "XSUBJECT"},
+{ "folder","XFOLDER"}
};
int
@@ -1362,6 +1363,7 @@ _notmuch_database_link_message (notmuch_database_t
*notmuch,
notmuch_status_t
notmuch_database_add_message (notmuch_database_t *notmuch,
const char *filename,
+ const char *folder_name,
notmuch_message_t **message_ret)
{
notmuch_message_file_t *message_file;
@@ -1477,6 +1479,9 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
date = notmuch_message_file_get_header (message_file, "date");
_notmuch_message_set_date (message, date);
+ if (folder_name != NULL)
+ _notmuch_message_gen_terms (message, "folder", folder_name);
+
_notmuch_message_index_file (message, filename);
} else {
ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 88da078..ce81565 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -264,6 +264,7 @@ notmuch_database_get_directory (notmuch_database_t
*database,
notmuch_status_t
notmuch_database_add_message (notmuch_database_t *database,
const char *filename,
+ const char *folder_name,
notmuch_message_t **message);
/* Remove a message from the given notmuch database.
diff --git a/notmuch-new.c b/notmuch-new.c
index 44b50aa..6ad3c09 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -21,6 +21,7 @@
#include "notmuch-client.h"
#include
+#include
typedef struct _filename_node {
char *filename;
@@ -169,6 +170,35 @@ _entries_resemble_maildir (struct dirent **entries, int
count)
return 0;
}
+static char*
+_get_folder_base_name(const char *path)
+{
+ gchar *full_folder_name = NULL;
+ gchar *folder_base_name = NULL;
+
+ /* Find name of "folder" containing the email. */
+ full_folder_name = g_strdup(path);
+ while (1) {
+folder_base_name = g_path_get_basename(full_folder_name);
+
+if (strcmp(folder_base_name, "cur") == 0
+ || strcmp(folder_base_name, "new") == 0) {
+ gchar *parent_name = g_path_get_dirname(full_folder_name);
+ g_free(full_folder_name);
+ full_folder_name = parent_name;
+} else
+ break;
+ }
+
+ g_free(full_folder_name);
+
+ if (strcmp(folder_base_name, ".") == 0) {
+g_free(folder_base_name);
+folder_base_name = NULL;
+ }
+ return folder_base_name;
+}
+
/* Examine 'path' recursively as follows:
*
* o Ask the filesystem for the mtime of 'path' (fs_mtime)
@@
Re: [PATCH 4/4] Add CONFIGURE_LDFLAGS to the notmuch-shared buld command line.
On Sun, 11 Apr 2010 19:44:54 -0400, Aaron Ecay wrote: > Otherwise, symbol not found errors result on OS X. I am not sure > this is the correct solution for the problem, but it gets the build > working. ... > -FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch > +FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch $(CONFIGURE_LDFLAGS) > FINAL_LIBNOTMUCH_LDFLAGS = $(LDFLAGS) $(CONFIGURE_LDFLAGS) As I mentioned earlier in the thread, this isn't the correct solution for Linux. Previously we had just FINAL_LDFLAGS that were used for both the binary and the library. We split this into FINAL_NOTMUCH_LDFLAGS and FINAL_LIBNOTMUCH_LDFLAGS precisely to avoid excess library dependencies on Linux. So the above patch would undo that which is not what we want. -Carl pgpWnorvI0vy8.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 4/4] Add CONFIGURE_LDFLAGS to the notmuch-shared buld command line.
On Sun, 11 Apr 2010 19:44:54 -0400, Aaron Ecay wrote: > Otherwise, symbol not found errors result on OS X. I am not sure > this is the correct solution for the problem, but it gets the build > working. ... > -FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch > +FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch $(CONFIGURE_LDFLAGS) > FINAL_LIBNOTMUCH_LDFLAGS = $(LDFLAGS) $(CONFIGURE_LDFLAGS) As I mentioned earlier in the thread, this isn't the correct solution for Linux. Previously we had just FINAL_LDFLAGS that were used for both the binary and the library. We split this into FINAL_NOTMUCH_LDFLAGS and FINAL_LIBNOTMUCH_LDFLAGS precisely to avoid excess library dependencies on Linux. So the above patch would undo that which is not what we want. -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/20100414/d2cb10f4/attachment.pgp>
Re: [PATCH 3/4] Add infrastructure for building shared library on OS X.
On Sun, 11 Apr 2010 19:44:53 -0400, Aaron Ecay wrote: > This patch adds a configure check for OS X (actually Darwin), > and sets up the Makefiles to build a proper shared library on > that platform. ... > -include $(subdirs:%=%/Makefile.local) Makefile.local > +include Makefile.config $(subdirs:%=%/Makefile.local) Makefile.local This first hunk looks unrelated to what's described in the commit message. It also results in Makefile.config being included from both the toplevel Makefile and the toplevel Makefile.local, so that seems wrong. I had wanted to keep the top-level Makefile totally generic, (so that if a project wanted to imitate the notmuch flat-Makefile build system that would be easy). And perhaps including Makefile.config here violates that. But I'd be willing to accept that if necessary---should just remove the include of Makefile.config from Makefile.local then I think. > +printf "Checking for Mac OS X (for shared library)... " > +if [ `uname` = "Darwin" ] ; then > +printf "Yes.\n" > +mac_os_x=1 > +else > +printf "No.\n" > +mac_os_x=0 > +fi > + Instead of inventing a new mac_os_x variable, we should follow the GNU configure conventions of build_cpu, build_vendor, build_os variables. We're already allowing the user to assign to these by passing a --build option to configure (though not yet doing anything with the values). But now that you've got something you actually do want to do with the values, we should use those same variables. It might not even be crazy to copy in config.guess (or pieces of it). Though, frankly, it's not doing anything for Darwin unlike you're doing above, so you might as well just use your own code as you have. > libnotmuch_c_srcs = \ > + $(notmuch_compat_srcs) \ > $(dir)/libsha1.c\ > $(dir)/message-file.c \ > $(dir)/messages.c \ This again looks like an independent fix that should be in a separate commit. -Carl pgpRr4Gde4RbD.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 3/4] Add infrastructure for building shared library on OS X.
On Sun, 11 Apr 2010 19:44:53 -0400, Aaron Ecay wrote: > This patch adds a configure check for OS X (actually Darwin), > and sets up the Makefiles to build a proper shared library on > that platform. ... > -include $(subdirs:%=%/Makefile.local) Makefile.local > +include Makefile.config $(subdirs:%=%/Makefile.local) Makefile.local This first hunk looks unrelated to what's described in the commit message. It also results in Makefile.config being included from both the toplevel Makefile and the toplevel Makefile.local, so that seems wrong. I had wanted to keep the top-level Makefile totally generic, (so that if a project wanted to imitate the notmuch flat-Makefile build system that would be easy). And perhaps including Makefile.config here violates that. But I'd be willing to accept that if necessary---should just remove the include of Makefile.config from Makefile.local then I think. > +printf "Checking for Mac OS X (for shared library)... " > +if [ `uname` = "Darwin" ] ; then > +printf "Yes.\n" > +mac_os_x=1 > +else > +printf "No.\n" > +mac_os_x=0 > +fi > + Instead of inventing a new mac_os_x variable, we should follow the GNU configure conventions of build_cpu, build_vendor, build_os variables. We're already allowing the user to assign to these by passing a --build option to configure (though not yet doing anything with the values). But now that you've got something you actually do want to do with the values, we should use those same variables. It might not even be crazy to copy in config.guess (or pieces of it). Though, frankly, it's not doing anything for Darwin unlike you're doing above, so you might as well just use your own code as you have. > libnotmuch_c_srcs = \ > + $(notmuch_compat_srcs) \ > $(dir)/libsha1.c\ > $(dir)/message-file.c \ > $(dir)/messages.c \ This again looks like an independent fix that should be in a separate commit. -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/20100414/b0bce721/attachment.pgp>
Re: [PATCH] Fix bug, and clean up code duplication, in adding or removing tag by region.
On Wed, 14 Apr 2010 10:14:46 -0700, Carl Worth wrote:
> The only real problem I see with this approach is that it's fragile in
> depending on the buffer having exactly 2 lines of non-thread text at the
> end. I can easily see myself wanting to remove the "End of Search
> Results" line at the end of the buffer. And if I do that, this code will
> break, (tag manipulations will miss the last message).
I was a bit worried about that myself. I hard-coded the 2 based on the
hard-coding in `notmuch-search-last-thread' (">"), which currently goes
to the bottom and then goes up two lines. But it seems like if there
were a more robust approach, it could be used in both.
> A more robust fix would check for the ability to read a thread
> ID. So making a single function such as
> notmuch-search-find-last-line-with-thread-id or so would do the trick
> here.
It occurs to me that the best way to do this would probably be to go to
point-max, and then (forward-line -1) until we hit a thread-id. That way
we wouldn't have to work all the way down long search indexes. I'll try
to code that up for the next release, and then have
notmuch-search-last-thread use it, as well as the region functions.
Best,
Jesse
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/4] Mailstore abstraction interface
On Tue, 13 Apr 2010, Carl Worth wrote:
> On Thu, 8 Apr 2010 16:42:43 +0200, Michal Sojka
> wrote:
> > The goal of mailstore abstraction is to allow notmuch to store tags
> > together with email messages. The abstract interface is needed because
> > people want to use different ways of storing their emails. Currently,
> > there exists implementation for two types of mailstore - plain files
> > and maildir. It is expected that additional git-based mailstore will
> > be developed later.
>
> I don't agree with the approach being taken here.
>
> I don't think that the expectation of future need is a good basis for
> adding a level of abstraction now. This gives us current costs without
> benefit.
Thanks for the review, Carl. Since I'm interested in further development
of mailstore abstraction until it is really useful, I'd like to make the
patch series as small as possible to reduce maintenance burden. I think
I can extract some "real features" such as cat subcommand from my
patches and send them separately, perhaps in 0.3 merge window.
> Meanwhile, the two different mail stores that you are currently support
> ("plain" and "maildir") aren't really different types. We do already
> have code within notmuch to detect whether any particular directory is a
> maildir, (with the heuristic of looking for child directories named
> "cur", "new", and "tmp"). So I think we can and should support both
> maildir and non-maildir mail storage just fine.
>
> The question of "once you have maildir storage, should you synchronize
> that tags" is quite separate. The answer there might be "yes", "no", or
> "let the user decide". But if it is configurable, then the configuration
> should be something like
>
> [maildir]
> synchronize_flags=yes
>
> rather than
>
> [mailstore]
> type=maildir
Yes, these two mail stores share a lot of code and there is only a small
difference between them. I agree that it is cleaner for users to see
them as a single mailstore type and use configuration options to change
the behavior.
-Michal
Re: [PATCH 2/4] Fix up Makefile for build.
On Sun, 11 Apr 2010 19:44:52 -0400, Aaron Ecay wrote: > Must set extra_c(xx)flags before including subdir Makefile.local's, > so that there is a blank slate that the subdirs can add on to. That part looks just fine, but it's intermixed with: > Must include subdir Makefile.local's before global one, otherwise > the compat sources are not added to the list of those to be > compiled. This part, which seems not ideal. I would have preferred it if we could have avoided fiddly ordering issues with our Makefile includes. The concept is that we are writing a single, flat Makefile but just maintaining it in pieces. And traditional Makefile rules don't depend on ordering so much. But the change of this variable assignment: But the patch switches to an order-dependent variable assignment for notmuch_compat_srcs here: > -notmuch_compat_srcs = > +notmuch_compat_srcs := And testing this a bit, it does seem necessary to do this since we are already using the order-dependent $(dir) variable in the expansion of notmuch_compat_srcs. So I've convinced myself, and pushed this patch as well. (I even tested by manually setting HAVE_GETLINE to 0 in Makefile.config) -Carl pgpZXOANKSuog.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/4] Fix up Makefile for build.
On Sun, 11 Apr 2010 19:44:52 -0400, Aaron Ecay wrote: > Must set extra_c(xx)flags before including subdir Makefile.local's, > so that there is a blank slate that the subdirs can add on to. That part looks just fine, but it's intermixed with: > Must include subdir Makefile.local's before global one, otherwise > the compat sources are not added to the list of those to be > compiled. This part, which seems not ideal. I would have preferred it if we could have avoided fiddly ordering issues with our Makefile includes. The concept is that we are writing a single, flat Makefile but just maintaining it in pieces. And traditional Makefile rules don't depend on ordering so much. But the change of this variable assignment: But the patch switches to an order-dependent variable assignment for notmuch_compat_srcs here: > -notmuch_compat_srcs = > +notmuch_compat_srcs := And testing this a bit, it does seem necessary to do this since we are already using the order-dependent $(dir) variable in the expansion of notmuch_compat_srcs. So I've convinced myself, and pushed this patch as well. (I even tested by manually setting HAVE_GETLINE to 0 in Makefile.config) -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/20100414/811366d4/attachment.pgp>
Re: [PATCH 1/4] Use C++ compiler to link notmuch binaries
On Sun, 11 Apr 2010 19:44:51 -0400, Aaron Ecay wrote: > Since the binaries contain C++ code, it is necessary to use the C++ > linker, or errors result on some platforms (OS X). Thanks. This one is merged and pushed. -Carl pgpGM3l7Vdhrk.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/4] Use C++ compiler to link notmuch binaries
On Sun, 11 Apr 2010 19:44:51 -0400, Aaron Ecay wrote: > Since the binaries contain C++ code, it is necessary to use the C++ > linker, or errors result on some platforms (OS X). Thanks. This one is merged and 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/20100414/33817edb/attachment-0001.pgp>
Re: Build problems on OS X
On Sun, 11 Apr 2010 19:43:27 -0400, Aaron Ecay wrote: > In the process of updating to the latest sources, I've discovered that notmuch > no longer builds on OS X. Hi Aaron, Thanks so much for following up here. This transition to building/installing a shared library (and not using libtool) is the big one as for as build-system portability goes. So I did expect to see a patch series here. I'm optimistic that going forward, we won't have constant breakage. Though I did have a suggestion to call ldconfig implicitly when doing "make install". Is that the same command on OS X or is it different? > As a reply to this email, I'll be sending 4 patches. I'll follow up to some of these individually. > The fourth patch I am not sure of. Even after adding the proper command line > flags to build the shared binary on OS X, I get symbol not found errors for > Glib/Gmime symbols. The shared binary links against the shared lib, which in > turn links against Glib and Gmime, but it appears that at least on OS X the > linker won't follow these second-order links, and the notmuch shared binary > must be linked against Glib/Gmime directly. This patch fixes the build for > me, but it may not be correct on Linux/other Unices. You're correct that it is incorrect on Linux. :-) Debian's program for checking package correctness (lintian) complains if a binary is linked directly against a library when the binary doesn't actually reference any symbols from that library, (but instead references symbols from other libraries that in turn reference the library). So we do want to avoid this excess linking. > I can resubmit this patch to add the extra linker flags only when > building for OS X. If anyone knows how to get the OS X linker to > behave like the Linux one in this regard, that will likely be a better > solution. Reworking that patch would be great. I don't have any suggestion for fixing the linker though. :-P -Carl pgp5wPOrhBk2j.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Build problems on OS X
On Sun, 11 Apr 2010 19:43:27 -0400, Aaron Ecay wrote: > In the process of updating to the latest sources, I've discovered that notmuch > no longer builds on OS X. Hi Aaron, Thanks so much for following up here. This transition to building/installing a shared library (and not using libtool) is the big one as for as build-system portability goes. So I did expect to see a patch series here. I'm optimistic that going forward, we won't have constant breakage. Though I did have a suggestion to call ldconfig implicitly when doing "make install". Is that the same command on OS X or is it different? > As a reply to this email, I'll be sending 4 patches. I'll follow up to some of these individually. > The fourth patch I am not sure of. Even after adding the proper command line > flags to build the shared binary on OS X, I get symbol not found errors for > Glib/Gmime symbols. The shared binary links against the shared lib, which in > turn links against Glib and Gmime, but it appears that at least on OS X the > linker won't follow these second-order links, and the notmuch shared binary > must be linked against Glib/Gmime directly. This patch fixes the build for > me, but it may not be correct on Linux/other Unices. You're correct that it is incorrect on Linux. :-) Debian's program for checking package correctness (lintian) complains if a binary is linked directly against a library when the binary doesn't actually reference any symbols from that library, (but instead references symbols from other libraries that in turn reference the library). So we do want to avoid this excess linking. > I can resubmit this patch to add the extra linker flags only when > building for OS X. If anyone knows how to get the OS X linker to > behave like the Linux one in this regard, that will likely be a better > solution. Reworking that patch would be great. I don't have any suggestion for fixing the linker though. :-P -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/20100414/9dac5e4d/attachment.pgp>
[PATCH] emacs: when archiving move the cursor depending on the sort order.
On Tue, 13 Apr 2010, Servilio Afre Puentes wrote: > The current hardcoded behaviour will not take you to the next unread > thread when the sort order is set to newer-first from the default of > older-first. Is this really what we want? If I sort messages by newest first, it menas that I want to process my emails from the newest to the oldest. I'm satisfied with the current behavour. -Michal
[PATCH] emacs: when archiving move the cursor depending on the sort order.
On 14 April 2010 05:53, Sebastian Spaeth wrote: > On 2010-04-14, Michal Sojka wrote: >> On Tue, 13 Apr 2010, Servilio Afre Puentes wrote: >> > The current hardcoded behaviour will not take you to the next unread >> > thread when the sort order is set to newer-first from the default of >> > older-first. >> >> Is this really what we want? If I sort messages by newest first, it >> menas that I want to process my emails from the newest to the oldest. >> I'm satisfied with the current behavour. > > Agreed, I would be very surprised to get a different behavior. Hmmm, interesting. I still want to process my messages from oldest to newest but prefer them to be shown with the newest at the top. I will create and send a second version of the patch later today that takes this into account... Servilio
Re: [PATCH] Next attempt to get guessing of From addresses correct in replies
On Fri, 09 Apr 2010 15:53:04 -0700, Dirk Hohndel wrote:
> + * WARNING - if the caller is asking for a header that could occur
> + * multiple times than they MUST first call this function with a
> + * a value of NULL for header_desired to ensure that all of the
> + * headers are parsed and concatenated before a match is returned
...
> + } else {
> + /* not sure this makes sense for all headers that can occur
> + * multiple times, but for now just concatenate headers
> + */
> + newhdr = strlen(decoded_value);
> + hdrsofar = strlen(header_sofar);
I'm a little nervous about this semantic change.
For example, I know that my mail collection contains at least some
messages with multiple Message-ID headers, (I'm not sure that's legal,
but they are there). I found those when doing detailed comparisons of
the database created by sup with that created by very early versions of
what became the indexing code for notmuch. [Sup prefers the
last-encountered Message-Id in the file, while Notmuch prefers the
first.]
So I'm concerned about the change above introducing subtle problems that
might be hard to notice.
How about an argument that asks explicitly for concatenated header
values, (and this could just trigger a rescan of the headers and ignore
the hash). I think that will be fine for your use case where you're just
opening this message file to get this one concatenated header out,
right?
-Carl
pgpaaaFmNK3bs.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Next attempt to get guessing of From addresses correct in replies
On Fri, 09 Apr 2010 15:53:04 -0700, Dirk Hohndel
wrote:
> + * WARNING - if the caller is asking for a header that could occur
> + * multiple times than they MUST first call this function with a
> + * a value of NULL for header_desired to ensure that all of the
> + * headers are parsed and concatenated before a match is returned
...
> + } else {
> + /* not sure this makes sense for all headers that can occur
> + * multiple times, but for now just concatenate headers
> + */
> + newhdr = strlen(decoded_value);
> + hdrsofar = strlen(header_sofar);
I'm a little nervous about this semantic change.
For example, I know that my mail collection contains at least some
messages with multiple Message-ID headers, (I'm not sure that's legal,
but they are there). I found those when doing detailed comparisons of
the database created by sup with that created by very early versions of
what became the indexing code for notmuch. [Sup prefers the
last-encountered Message-Id in the file, while Notmuch prefers the
first.]
So I'm concerned about the change above introducing subtle problems that
might be hard to notice.
How about an argument that asks explicitly for concatenated header
values, (and this could just trigger a rescan of the headers and ignore
the hash). I think that will be fine for your use case where you're just
opening this message file to get this one concatenated header out,
right?
-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/20100414/6243e524/attachment.pgp>
Re: [PATCH] Fix bug, and clean up code duplication, in adding or removing tag by region.
On Tue, 13 Apr 2010 14:47:19 -0400, Jesse Rosenthal wrote:
> There was a bug in notmuch-search-{add,remove}-tag-region, which would
> not behave correctly if the region went beyond the last message. Now,
> instead of simply iterating to the last line of the region, these
> functions will iterate to the minimum of the last line of the region
> and the last possible line, i.e.
Thanks, Jesse!
I tested this and it works great.
> (- (line-number-at-pos (point-max)) 2)
The only real problem I see with this approach is that it's fragile in
depending on the buffer having exactly 2 lines of non-thread text at the
end. I can easily see myself wanting to remove the "End of Search
Results" line at the end of the buffer. And if I do that, this code will
break, (tag manipulations will miss the last message).
A more robust fix would check for the ability to read a thread
ID. So making a single function such as
notmuch-search-find-last-line-with-thread-id or so would do the trick
here.
> Also clean up code duplication, as per Carl's suggestion, by making
> notmuch-search-{add/remove}-tag-thread a special case of the -region
> commands, where the region in question is between (point) and (point).
A very nice change as well. My internal alarm on "also" in a commit
message fired, so I took advantage of "git add -p" and "git rebase -i"
to split this portion into a separate commit.
All pushed now.
-Carl
pgpN8cqte0yOx.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Fix bug, and clean up code duplication, in adding or removing tag by region.
On Tue, 13 Apr 2010 14:47:19 -0400, Jesse Rosenthal
wrote:
> There was a bug in notmuch-search-{add,remove}-tag-region, which would
> not behave correctly if the region went beyond the last message. Now,
> instead of simply iterating to the last line of the region, these
> functions will iterate to the minimum of the last line of the region
> and the last possible line, i.e.
Thanks, Jesse!
I tested this and it works great.
> (- (line-number-at-pos (point-max)) 2)
The only real problem I see with this approach is that it's fragile in
depending on the buffer having exactly 2 lines of non-thread text at the
end. I can easily see myself wanting to remove the "End of Search
Results" line at the end of the buffer. And if I do that, this code will
break, (tag manipulations will miss the last message).
A more robust fix would check for the ability to read a thread
ID. So making a single function such as
notmuch-search-find-last-line-with-thread-id or so would do the trick
here.
> Also clean up code duplication, as per Carl's suggestion, by making
> notmuch-search-{add/remove}-tag-thread a special case of the -region
> commands, where the region in question is between (point) and (point).
A very nice change as well. My internal alarm on "also" in a commit
message fired, so I took advantage of "git add -p" and "git rebase -i"
to split this portion into a separate commit.
All pushed now.
-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/20100414/93bc32ab/attachment.pgp>
See only unread message in a thread ?
On Wed, 14 Apr 2010 00:43:16 +0200, Xavier Maillard wrote: > Is it done automatically ? Or do I need to do something special > in order to unset the unread tag ? > > I see there is 'a' and 'x' when in notmuch-show but I am not sure > I have to explicitely press on of these keys. > > Currently, when in a notmuch-search buffer, I press RET to visit > the thread and then I play with 'n' to go next message till I > read the whole thread. Then, I press 'q' to go back to the > notmuch-search buffer. Is this the way to do ? That should be removing the 'unread' tag. Therefore it sounds like you want to be using a search including 'tag:unread' to get the behaviour that you want. Obviously that might not show you all the threads that you want. There is a notmuch-show-next-unread-message, but it's not bound to anything by default. That might also be useful to you. Thanks, James
See only unread message in a thread ?
On Tue, 13 Apr 2010 19:29:29 -0400, Jameson Rollins wrote: > On Tue, 13 Apr 2010 23:19:37 +0100, James Westby jameswestby.net> wrote: > > On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard wrote: > > > Say I have a thread with A-B-C. I visit the thread and read the > > > whole thread. Let's say after 'notmuch new' a post has entered > > > the thread: A-B-C-D. Is there an easy way to just have one of > > > these behaviour: > > > > > > - only show the new message (with an option to toggle display of > > > the old messages) > > > - display the whole thread with the 3 read messages 'collapsed' > > > and only the unread message 'expanded' > > > > This is the default behaviour in my experience. > > I agree this is the behavior I see, but there is a caveat that may be > the cause of confusion: > > > Reading a message unsets the 'unread' tag. > > > > The default search if for 'inbox' + 'unread'. > > Actually, the default search is for just "tag:inbox", which will also > display any messages in the inbox that have "tag:unread" as well. But > remember that if you are coming from a search for "tag:inbox", when you > view a thread all the message with "tag:inbox" will be visible > (uncollapsed), whether or not they have "tag:unread" not. Just reading > a message will not cause it to collapse when coming from a "tag:inbox" > search. I think this might be where the confusion is coming from. If > you want to view just the messages in your inbox that are unread, then > you need to search for "tag:inbox and tag:unread", or type 'f' in > notmuch mode to filter your inbox search with the "tag:unread" search. > Make sense? Yes, thanks for clarifying. I realise now that I lied about the behaviour that I was seeing. I use the default tag:inbox search, but archive all the mails 'a' as I read them, using other tags to keep track of things I want to come back to. That means that 'inbox' behaves the way I described 'unread' to behave for me. I see the new messages as the old ones had their 'inbox' tag removed. Thanks, James
[PATCH] allow to not sort the search results
On 2010-04-14, Jason White wrote: > > Also add a --sort=unsorted command line option to notmuch search to test > > this. > > Does this provide relevance-ranked search results? I think relevance ranking > is the Xapian default if a sort order isn't specified. Yes, by default it is using sort_by_relevance, so "unsorted" implies just that. (in fact, a previous incarnation of this patch called it --sort=relevance) However, given that many of our terms, are boolean, relevance only really comes into play when including terms within the body of a message. (and *I* have not found the relevance sorting to be much useful yet when I cared about some sort order, but that might just be me). > It would be useful to be able to obtain a relevance-ranked list of messages or > threads that satisfy a query. I would be happy to have it called --sort=relevance too, the unsorted points out potential performance improvements a bit better, IMHO (although they seem to be really small with a warm cache). Sebastian
[PATCH] RFC: User-Agent header
On 2010-04-13, Carl Worth wrote: > > OK, final post from me on this issue. > No, wait! I want more from you. :-) Sigh, they always want more :-) > Would you care to put together a solution that does this from within > notmuch*.el ? I really want things usable by default without people > having to hack up their .emacs files. See the "sister mail" to this thread, in which I simply added the whole shebang to notmuch.el (not using a lambda function). Is that what you had in mind. Mind you, my elisp knowledge borders close to 0, so I would be surprised if I did not botch up things. However, I have tested the patch, and the User-Agent header got inserted. > Of course, we could also easily add a variable to make this not happen, > (but that can be added in a follow-on patch by anyone). Some don't want it, but it cannot be disabled in this patch, so that would indeed need to be a followup patch. This gets now inserted (message mode automatically wrapped the header like this): User-Agent: notmuch version 0.1-107-g553feae (Emacs 23.1.1/x86_64-pc-linux-gnu) Is that an acceptable format? I would have preferred to not include the "version" string, but notmuch --version spits that out, and it was just easier to leave it in. Is that "version" really needed, BTW? Why can't notmuch --version not just say: notmuch 0.1-107-g553feae Sebastian
[PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header
This adds a function (and a hook) to have notmuch insert a User-Agent header
into composed mails (even if invoked from not-notmuch ways, such as with
ctrl-x m. This is invariably added for now without the possibility to
turn it off, a task left as a homework for others.
Signed-off-by: Sebastian Spaeth
---
emacs/notmuch.el | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 517c53a..8a7df15 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -54,6 +54,30 @@
(require 'notmuch-lib)
(require 'notmuch-show)
+(defun notmuch-set-user-agent-header ()
+ "Sets variables so that message mode inserts a notmuch User-Agent
+ header into send mails"
+ ;; check if User-Agent is a 'required' mail header and set it if not
+ (if (not (memq 'User-Agent message-required-mail-headers))
+ (setq message-required-mail-headers
+(append message-required-mail-headers '(User-Agent
+ ;; hide the User-Agent header when composing a mail
+ (if (not (memq '"^User-Agent:" message-hidden-headers))
+ (setq message-hidden-headers
+(append message-hidden-headers '("^User-Agent:"
+ ;; create the notmuch user agent string
+ (let ((notmuch-user-agent (concat
+ (substring (shell-command-to-string
+ (concat notmuch-command
+ " --version")) 0 -1)
+ " (Emacs " emacs-version "/"
+ system-configuration ")")))
+(setq message-newsreader notmuch-user-agent)))
+
+;; set the User-Agent string whenever we invoke message mode
+;; TODO: use a variable that allows disabling.
+(add-hook 'message-mode-hook 'notmuch-set-user-agent-header)
+
(defun notmuch-select-tag-with-completion (prompt &rest search-terms)
(let ((tag-list
(with-output-to-string
--
1.6.3.3
[PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header
On Wed, 14 Apr 2010 09:38:05 +0200, Sebastian Spaeth wrote: > This adds a function (and a hook) to have notmuch insert a User-Agent header > into composed mails (even if invoked from not-notmuch ways, such as with > ctrl-x m. This is invariably added for now without the possibility to > turn it off, a task left as a homework for others. This really should be done with `define-mail-user-agent' and associated paraphernalia. dme. -- David Edmondson, http://dme.org
[PATCH 1/1] Stores the folder (directory name) of the message in the database as a term with folder prefix.
This patch was originally sent by Andreas Klöckner in:
id:200912141421.52561.li...@informa.tiker.net. It was then
subsequently updated by Michal Sojka in:
id:1264692317-9175-2-git-send-email-sojk...@fel.cvut.cz and then
further improved again by Michal Sojka in:
id:1265122868-12133-1-git-send-email-sojk...@fel.cvut.cz
This is a rebase of the latest patch off of the current git HEAD.
. The differences from the original patch are:
- Rebased off of current git HEAD
- Folder name is taken from strings generated during travesal. It no
longer uses glib nor it allocates additional memory to determine the
base name. The same approach as in
id:87fx8bygi7@linux.vnet.ibm.com was used.
- Removed unrelated change which was submitted separately as
id:1264691584-8290-2-git-send-email-sojk...@fel.cvut.cz
- Changed the comment describing database schema.
TODO (see Carl's email: id:87zl5k0w6s@yoom.home.cworth.org):
- Support hierarchical folders: this patch is only storing the final
directory component. This should be hooked in differently with
filename storage so the whole filename is indexed as text to
provide arbitrary search phrases such as "folder:'foo/bar/baz'"
---
lib/database.cc | 13 +
lib/notmuch.h |1 +
notmuch-new.c | 39 +--
3 files changed, 47 insertions(+), 6 deletions(-)
diff --git a/lib/database.cc b/lib/database.cc
index c91e97c..6364623 100644
--- a/lib/database.cc
+++ b/lib/database.cc
@@ -84,9 +84,9 @@ typedef struct {
* MESSAGE_ID: The unique ID of the mail mess (see "id" above)
*
* In addition, terms from the content of the message are added with
- * "from", "to", "attachment", and "subject" prefixes for use by the
- * user in searching. But the database doesn't really care itself
- * about any of these.
+ * "from", "to", "attachment", "subject" and "folder" prefixes for use
+ * by the user in searching. But the database doesn't really care
+ * itself about any of these.
*
* The data portion of a mail document is empty.
*
@@ -155,7 +155,8 @@ prefix_t PROBABILISTIC_PREFIX[]= {
{ "from", "XFROM" },
{ "to","XTO" },
{ "attachment","XATTACHMENT" },
-{ "subject", "XSUBJECT"}
+{ "subject", "XSUBJECT"},
+{ "folder","XFOLDER"}
};
int
@@ -1362,6 +1363,7 @@ _notmuch_database_link_message (notmuch_database_t
*notmuch,
notmuch_status_t
notmuch_database_add_message (notmuch_database_t *notmuch,
const char *filename,
+ const char *folder_name,
notmuch_message_t **message_ret)
{
notmuch_message_file_t *message_file;
@@ -1477,6 +1479,9 @@ notmuch_database_add_message (notmuch_database_t *notmuch,
date = notmuch_message_file_get_header (message_file, "date");
_notmuch_message_set_date (message, date);
+ if (folder_name != NULL)
+ _notmuch_message_gen_terms (message, "folder", folder_name);
+
_notmuch_message_index_file (message, filename);
} else {
ret = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID;
diff --git a/lib/notmuch.h b/lib/notmuch.h
index 88da078..ce81565 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -264,6 +264,7 @@ notmuch_database_get_directory (notmuch_database_t
*database,
notmuch_status_t
notmuch_database_add_message (notmuch_database_t *database,
const char *filename,
+ const char *folder_name,
notmuch_message_t **message);
/* Remove a message from the given notmuch database.
diff --git a/notmuch-new.c b/notmuch-new.c
index 44b50aa..6ad3c09 100644
--- a/notmuch-new.c
+++ b/notmuch-new.c
@@ -21,6 +21,7 @@
#include "notmuch-client.h"
#include
+#include
typedef struct _filename_node {
char *filename;
@@ -169,6 +170,35 @@ _entries_resemble_maildir (struct dirent **entries, int
count)
return 0;
}
+static char*
+_get_folder_base_name(const char *path)
+{
+ gchar *full_folder_name = NULL;
+ gchar *folder_base_name = NULL;
+
+ /* Find name of "folder" containing the email. */
+ full_folder_name = g_strdup(path);
+ while (1) {
+folder_base_name = g_path_get_basename(full_folder_name);
+
+if (strcmp(folder_base_name, "cur") == 0
+ || strcmp(folder_base_name, "new") == 0) {
+ gchar *parent_name = g_path_get_dirname(full_folder_name);
+ g_free(full_folder_name);
+ full_folder_name = parent_name;
+} else
+ break;
+ }
+
+ g_free(full_folder_name);
+
+ if (strcmp(folder_base_name, ".") == 0) {
+g_free(folder_base_name);
+folder_base_name = NULL;
+ }
+ return folder_base_name;
+}
+
/* Examine 'path' recursively as follows:
*
* o Ask the filesystem for the mtime of 'path' (fs_mtime)
@@ -222,6 +252,
[PATCH] allow to not sort the search results
previously we were always sorting the returned results by some string value,
but sometimes we might just be interested in the number of results, and don't
need any sorting.
Also add a --sort=unsorted command line option to notmuch search to test this.
A search that matches 1200 messages, returns in default sort in 0.982 seconds
and unsorted in 0.978 seconds with very little variance (with a warm cache).
Xapian contributor Olly Betts says that the speed gains for a cold cache are
likely to be much higher though.
Signed-off-by: Sebastian Spaeth
---
lib/notmuch.h|3 ++-
lib/query.cc |2 ++
notmuch-search.c |2 ++
3 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/lib/notmuch.h b/lib/notmuch.h
index a7e66dd..bae48a6 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -346,7 +346,8 @@ notmuch_query_create (notmuch_database_t *database,
typedef enum {
NOTMUCH_SORT_OLDEST_FIRST,
NOTMUCH_SORT_NEWEST_FIRST,
-NOTMUCH_SORT_MESSAGE_ID
+NOTMUCH_SORT_MESSAGE_ID,
+NOTMUCH_SORT_UNSORTED
} notmuch_sort_t;
/* Specify the sorting desired for this query. */
diff --git a/lib/query.cc b/lib/query.cc
index 10f8dc8..4148f9b 100644
--- a/lib/query.cc
+++ b/lib/query.cc
@@ -148,6 +148,8 @@ notmuch_query_search_messages (notmuch_query_t *query)
case NOTMUCH_SORT_MESSAGE_ID:
enquire.set_sort_by_value (NOTMUCH_VALUE_MESSAGE_ID, FALSE);
break;
+case NOTMUCH_SORT_UNSORTED:
+ break;
}
#if DEBUG_QUERY
diff --git a/notmuch-search.c b/notmuch-search.c
index 4e3514b..854a9ae 100644
--- a/notmuch-search.c
+++ b/notmuch-search.c
@@ -217,6 +217,8 @@ notmuch_search_command (void *ctx, int argc, char *argv[])
sort = NOTMUCH_SORT_OLDEST_FIRST;
} else if (strcmp (opt, "newest-first") == 0) {
sort = NOTMUCH_SORT_NEWEST_FIRST;
+ } else if (strcmp (opt, "unsorted") == 0) {
+ sort = NOTMUCH_SORT_UNSORTED;
} else {
fprintf (stderr, "Invalid value for --sort: %s\n", opt);
return 1;
--
1.6.3.3
Re: [PATCH] emacs: when archiving move the cursor depending on the sort order.
On 14 April 2010 05:53, Sebastian Spaeth wrote: > On 2010-04-14, Michal Sojka wrote: >> On Tue, 13 Apr 2010, Servilio Afre Puentes wrote: >> > The current hardcoded behaviour will not take you to the next unread >> > thread when the sort order is set to newer-first from the default of >> > older-first. >> >> Is this really what we want? If I sort messages by newest first, it >> menas that I want to process my emails from the newest to the oldest. >> I'm satisfied with the current behavour. > > Agreed, I would be very surprised to get a different behavior. Hmmm, interesting. I still want to process my messages from oldest to newest but prefer them to be shown with the newest at the top. I will create and send a second version of the patch later today that takes this into account... Servilio ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/4] Mailstore abstraction v4
On Thu, 8 Apr 2010 16:42:42 +0200, Michal Sojka wrote: > My biggest question relates to the first patch, which does an > incompatible change to libnotmuch API. After reading RELEASING file, I > found that this change is probably not what Carl wants to merge (and I > understand that) so I'd like to get some feedback on my suggestion in > that patch. [I composed this message a while ago, but failed to get it through the mailing-list moderation until now. It may be largely irrelevant in light of my more recent review of the mailstore abstraction, but here it is.] I haven't looked closely at the implementation here, but a quick glance at the API/ABI change suggests an easy answer: Why not just add a new function that accepts the mailstore type, and preserve the original function, (which would then simply call the new function with an argument of "files" for the mailstore type). -Carl pgpGY9OS6Qai1.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: when archiving move the cursor depending on the sort order.
On 2010-04-14, Michal Sojka wrote: > On Tue, 13 Apr 2010, Servilio Afre Puentes wrote: > > The current hardcoded behaviour will not take you to the next unread > > thread when the sort order is set to newer-first from the default of > > older-first. > > Is this really what we want? If I sort messages by newest first, it > menas that I want to process my emails from the newest to the oldest. > I'm satisfied with the current behavour. Agreed, I would be very surprised to get a different behavior. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header
On 2010-04-14, David Edmondson wrote: > This really should be done with `define-mail-user-agent' and associated > paraphernalia. Which might be correct but beyond what I can provide :). So, either we take this and get a followup patch, or someone improves it, or we drop it. Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: See only unread message in a thread ?
On Wed, 14 Apr 2010 00:43:16 +0200, Xavier Maillard wrote: > Is it done automatically ? Or do I need to do something special > in order to unset the unread tag ? > > I see there is 'a' and 'x' when in notmuch-show but I am not sure > I have to explicitely press on of these keys. > > Currently, when in a notmuch-search buffer, I press RET to visit > the thread and then I play with 'n' to go next message till I > read the whole thread. Then, I press 'q' to go back to the > notmuch-search buffer. Is this the way to do ? That should be removing the 'unread' tag. Therefore it sounds like you want to be using a search including 'tag:unread' to get the behaviour that you want. Obviously that might not show you all the threads that you want. There is a notmuch-show-next-unread-message, but it's not bound to anything by default. That might also be useful to you. Thanks, James ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: See only unread message in a thread ?
On Tue, 13 Apr 2010 19:29:29 -0400, Jameson Rollins wrote: > On Tue, 13 Apr 2010 23:19:37 +0100, James Westby > wrote: > > On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard wrote: > > > Say I have a thread with A-B-C. I visit the thread and read the > > > whole thread. Let's say after 'notmuch new' a post has entered > > > the thread: A-B-C-D. Is there an easy way to just have one of > > > these behaviour: > > > > > > - only show the new message (with an option to toggle display of > > > the old messages) > > > - display the whole thread with the 3 read messages 'collapsed' > > > and only the unread message 'expanded' > > > > This is the default behaviour in my experience. > > I agree this is the behavior I see, but there is a caveat that may be > the cause of confusion: > > > Reading a message unsets the 'unread' tag. > > > > The default search if for 'inbox' + 'unread'. > > Actually, the default search is for just "tag:inbox", which will also > display any messages in the inbox that have "tag:unread" as well. But > remember that if you are coming from a search for "tag:inbox", when you > view a thread all the message with "tag:inbox" will be visible > (uncollapsed), whether or not they have "tag:unread" not. Just reading > a message will not cause it to collapse when coming from a "tag:inbox" > search. I think this might be where the confusion is coming from. If > you want to view just the messages in your inbox that are unread, then > you need to search for "tag:inbox and tag:unread", or type 'f' in > notmuch mode to filter your inbox search with the "tag:unread" search. > Make sense? Yes, thanks for clarifying. I realise now that I lied about the behaviour that I was seeing. I use the default tag:inbox search, but archive all the mails 'a' as I read them, using other tags to keep track of things I want to come back to. That means that 'inbox' behaves the way I described 'unread' to behave for me. I see the new messages as the old ones had their 'inbox' tag removed. Thanks, James ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/4] Mailstore abstraction interface
On Tue, 13 Apr 2010, Carl Worth wrote:
> On Thu, 8 Apr 2010 16:42:43 +0200, Michal Sojka wrote:
> > The goal of mailstore abstraction is to allow notmuch to store tags
> > together with email messages. The abstract interface is needed because
> > people want to use different ways of storing their emails. Currently,
> > there exists implementation for two types of mailstore - plain files
> > and maildir. It is expected that additional git-based mailstore will
> > be developed later.
>
> I don't agree with the approach being taken here.
>
> I don't think that the expectation of future need is a good basis for
> adding a level of abstraction now. This gives us current costs without
> benefit.
Thanks for the review, Carl. Since I'm interested in further development
of mailstore abstraction until it is really useful, I'd like to make the
patch series as small as possible to reduce maintenance burden. I think
I can extract some "real features" such as cat subcommand from my
patches and send them separately, perhaps in 0.3 merge window.
> Meanwhile, the two different mail stores that you are currently support
> ("plain" and "maildir") aren't really different types. We do already
> have code within notmuch to detect whether any particular directory is a
> maildir, (with the heuristic of looking for child directories named
> "cur", "new", and "tmp"). So I think we can and should support both
> maildir and non-maildir mail storage just fine.
>
> The question of "once you have maildir storage, should you synchronize
> that tags" is quite separate. The answer there might be "yes", "no", or
> "let the user decide". But if it is configurable, then the configuration
> should be something like
>
> [maildir]
> synchronize_flags=yes
>
> rather than
>
> [mailstore]
> type=maildir
Yes, these two mail stores share a lot of code and there is only a small
difference between them. I agree that it is cleaner for users to see
them as a single mailstore type and use configuration options to change
the behavior.
-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: when archiving move the cursor depending on the sort order.
On Tue, 13 Apr 2010, Servilio Afre Puentes wrote: > The current hardcoded behaviour will not take you to the next unread > thread when the sort order is set to newer-first from the default of > older-first. Is this really what we want? If I sort messages by newest first, it menas that I want to process my emails from the newest to the oldest. I'm satisfied with the current behavour. -Michal ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] RFC: User-Agent header
On Tue, 13 Apr 2010 10:44:03 -0700, Carl Worth wrote: > On Mon, 12 Apr 2010 10:30:54 +0200, "Sebastian Spaeth" SSpaeth.de> wrote: > > > > OK, final post from me on this issue. > > No, wait! I want more from you. :-) > > Would you care to put together a solution that does this from within > notmuch*.el ? I really want things usable by default without people > having to hack up their .emacs files. +1 > Of course, we could also easily add a variable to make this not happen, > (but that can be added in a follow-on patch by anyone). +1 Xavier
Re: [PATCH] allow to not sort the search results
On 2010-04-14, Jason White wrote: > > Also add a --sort=unsorted command line option to notmuch search to test > > this. > > Does this provide relevance-ranked search results? I think relevance ranking > is the Xapian default if a sort order isn't specified. Yes, by default it is using sort_by_relevance, so "unsorted" implies just that. (in fact, a previous incarnation of this patch called it --sort=relevance) However, given that many of our terms, are boolean, relevance only really comes into play when including terms within the body of a message. (and *I* have not found the relevance sorting to be much useful yet when I cared about some sort order, but that might just be me). > It would be useful to be able to obtain a relevance-ranked list of messages or > threads that satisfy a query. I would be happy to have it called --sort=relevance too, the unsorted points out potential performance improvements a bit better, IMHO (although they seem to be really small with a warm cache). Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header
On Wed, 14 Apr 2010 09:38:05 +0200, Sebastian Spaeth wrote: > This adds a function (and a hook) to have notmuch insert a User-Agent header > into composed mails (even if invoked from not-notmuch ways, such as with > ctrl-x m. This is invariably added for now without the possibility to > turn it off, a task left as a homework for others. This really should be done with `define-mail-user-agent' and associated paraphernalia. dme. -- David Edmondson, http://dme.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] RFC: User-Agent header
On 2010-04-13, Carl Worth wrote: > > OK, final post from me on this issue. > No, wait! I want more from you. :-) Sigh, they always want more :-) > Would you care to put together a solution that does this from within > notmuch*.el ? I really want things usable by default without people > having to hack up their .emacs files. See the "sister mail" to this thread, in which I simply added the whole shebang to notmuch.el (not using a lambda function). Is that what you had in mind. Mind you, my elisp knowledge borders close to 0, so I would be surprised if I did not botch up things. However, I have tested the patch, and the User-Agent header got inserted. > Of course, we could also easily add a variable to make this not happen, > (but that can be added in a follow-on patch by anyone). Some don't want it, but it cannot be disabled in this patch, so that would indeed need to be a followup patch. This gets now inserted (message mode automatically wrapped the header like this): User-Agent: notmuch version 0.1-107-g553feae (Emacs 23.1.1/x86_64-pc-linux-gnu) Is that an acceptable format? I would have preferred to not include the "version" string, but notmuch --version spits that out, and it was just easier to leave it in. Is that "version" really needed, BTW? Why can't notmuch --version not just say: notmuch 0.1-107-g553feae Sebastian ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
See only unread message in a thread ?
On Tue, 13 Apr 2010 23:19:37 +0100, James Westby wrote: > On Wed, 14 Apr 2010 00:11:50 +0200, Xavier Maillard wrote: > > Hi, > > > > maybe I missread the "manual" but I can't find an easy way to do > > something simple in notmuch.el. > > > > Say I have a thread with A-B-C. I visit the thread and read the > > whole thread. Let's say after 'notmuch new' a post has entered > > the thread: A-B-C-D. Is there an easy way to just have one of > > these behaviour: > > > > - only show the new message (with an option to toggle display of > > the old messages) > > - display the whole thread with the 3 read messages 'collapsed' > > and only the unread message 'expanded' > > This is the default behaviour in my experience. > > Reading a message unsets the 'unread' tag. Is it done automatically ? Or do I need to do something special in order to unset the unread tag ? I see there is 'a' and 'x' when in notmuch-show but I am not sure I have to explicitely press on of these keys. Currently, when in a notmuch-search buffer, I press RET to visit the thread and then I play with 'n' to go next message till I read the whole thread. Then, I press 'q' to go back to the notmuch-search buffer. Is this the way to do ? Thank you Xavier
[PATCH 13/13] notmuch.el: Add a function to insert a notmuch user-agent header
This adds a function (and a hook) to have notmuch insert a User-Agent header
into composed mails (even if invoked from not-notmuch ways, such as with
ctrl-x m. This is invariably added for now without the possibility to
turn it off, a task left as a homework for others.
Signed-off-by: Sebastian Spaeth
---
emacs/notmuch.el | 24
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 517c53a..8a7df15 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -54,6 +54,30 @@
(require 'notmuch-lib)
(require 'notmuch-show)
+(defun notmuch-set-user-agent-header ()
+ "Sets variables so that message mode inserts a notmuch User-Agent
+ header into send mails"
+ ;; check if User-Agent is a 'required' mail header and set it if not
+ (if (not (memq 'User-Agent message-required-mail-headers))
+ (setq message-required-mail-headers
+(append message-required-mail-headers '(User-Agent
+ ;; hide the User-Agent header when composing a mail
+ (if (not (memq '"^User-Agent:" message-hidden-headers))
+ (setq message-hidden-headers
+(append message-hidden-headers '("^User-Agent:"
+ ;; create the notmuch user agent string
+ (let ((notmuch-user-agent (concat
+ (substring (shell-command-to-string
+ (concat notmuch-command
+ " --version")) 0 -1)
+ " (Emacs " emacs-version "/"
+ system-configuration ")")))
+(setq message-newsreader notmuch-user-agent)))
+
+;; set the User-Agent string whenever we invoke message mode
+;; TODO: use a variable that allows disabling.
+(add-hook 'message-mode-hook 'notmuch-set-user-agent-header)
+
(defun notmuch-select-tag-with-completion (prompt &rest search-terms)
(let ((tag-list
(with-output-to-string
--
1.6.3.3
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
See only unread message in a thread ?
Hi, maybe I missread the "manual" but I can't find an easy way to do something simple in notmuch.el. Say I have a thread with A-B-C. I visit the thread and read the whole thread. Let's say after 'notmuch new' a post has entered the thread: A-B-C-D. Is there an easy way to just have one of these behaviour: - only show the new message (with an option to toggle display of the old messages) - display the whole thread with the 3 read messages 'collapsed' and only the unread message 'expanded' Thank you Xavier
