| Age | Commit message (Collapse) | Author |
|---|
|
This way, the user gets a steady (but bursty) stream of reults. We
double the chunk size each time since each successive chunk has to
redo work from all previous chunks.
Of course, the overall time is thereby slower, as the price we pay for
increased responsiveness. With a search returning about 17000 thread
results I measured a total time of 48.8 seconds before this change and
58.4 seconds afterwards.
|
|
The rudimentary aspect here is that the date ranges are specified with
UNIX timestamp values (number of seconds since 1970-01-01 UTC). One
thing that can help here is using the date program to determins
timestamps, such as:
$(date +%s -d 2009-10-01)..$(date +%s)
Long-term, we'll probably need to do our own query parsing to be able
to support directly-specified dates and also relative expressions like
"since:'2 months ago'".
|
|
This is an idea I've had "forever" (and is commented as such in the
code already), but just came up on the mailing list. So note it here.
|
|
I had these notes sitting in an uncommitted file that was cluttering
up my "git status" output. This cleans that up, and also shares the
ideas with the wider community.
|
|
Hopefully soon I can start implementing ideas rather than just writing
them down.
|
|
We're not likely to run out of work to do anytime soon...
|
|
These are from email messages on the notmuch mailing list and from
IRC conversations in #notmuch.
|
|
So get these out of my mind and out to the user community.
|
|
And correspondingly, READONLY to READ_ONLY.
|
|
It's better to have things in TODO rather than mails with a todo
tag in my notmuch database.
|
|
|
|
I'm throwing away a half-finished fix of this now, and just want to
ensure I don't forget about it.
|
|
This note was described in the previous commit message, but mistakenly
not committed:
The note about making "notmuch setup" faster is now rewritten to apply
to "notmuch new" since "notmuch setup" no longer does any mail
indexing.
|
|
We recently added support for "notmuch reply" and also made (most of)
the hidden components self documenting.
The note about making "notmuch setup" faster is now rewritten to apply
to "notmuch new" since "notmuch setup" no longer does any mail
indexing.
|
|
A recent "notmuch restore" command took *forever* for me. Obviously,
we need to fix the underlying performance bug in Xapian, but in the
meantime, a progress indicator would help.
|
|
The magic space bar is nice, but sometimes there's a message with a
long attachment that I just want to skip, but still consider the
message marked as read.
|
|
Of course, technically, we're removing the "unread" tag, but you
get the idea. :-)
|
|
The display of the header can be toggled with the 'h' key.
|
|
I mentioned the read-only directory optimization to Keith, and he
liked it but wanted to be able to configure it to be fully automated.
|
|
There are conceptually three different projects here, so it helps
to keep the tasks for each separated.
|
|
One more baby step toward something that's pleasant to use.
|
|
There's no undo still, but at least you can see what you are doing
now.
|
|
This can allow for the client to hide undesired MIME parts
such as text/html.
|
|
These are the things that are actively preventing me from being able
to use notmuch as an email-reading client.
|
|
By pulling content out of notmuch help, and also the messages
printed by "notmuch setup".
|
|
I had noticed several times earlier that having a talloc context
passed in would make things more convenient. I'm not exercising
that convenience yet, but the context is there now, (and there's
one fewer item on our TODO list).
|
|
Shorter naming without being any less clear. A definite win.
|
|
These are things we'll want done before any big announcement.
|
|
The timestamp stuff we'll want to do soon, since it's a database
change, (though not a major one---at worst a handful of stale
timestamp documents would be left in the database).
|
|
The optimization idea removed here doesn't make sense anymore with
full-text indexing happening up front.
|
|
It's time to put full-text indexing back, and we might want to
experiment with optimization the original thread-stitching phase.
|
|
"notmuch tag" is implemented now and seems to work great (and fast).
As for the race condition, as noted in the description we're removing
it's not exposed directly in the API, but only in a client that
allows for looping over search results and removing the inbox tag
from all of them. But then, that's exactly what the "notmuch tag"
command does. So, as discussed, we've now documented that command
to highlight the issue. Problem resolved, (as well as we can).
|
|
Some of these are simple little code cleanups, but it's nice to write them
down rather than trying to remember them.
|
|
Interstingly, it's our simple "notmuch" client that's going to be the
most difficult to fix. There's just not as much information preserved
in the textual representation from "notmuch search" as there is in the
objects returned from notmuch_query_search_threads.
|
|
The archive-thread race condition doesn't even exist now because there's
no command for modifying tags at the level of a thread (just individual
messages).
|
|
This means that the restore operation will now properly pick up the
removal of tags indicated by the tag just not being present in the
dump file.
We added a few new public functions in order to support this:
notmuch_message_freeze
notmuch_message_remove_all_tags
notmuch_message_thaw
|
|
I've been maintaining this for a while now, so I might as well
start tracking it with revision control as well.
|
