| Commit message (Collapse) | Author | Age |
|
|
|
|
| |
The notmuch_query_count_messages functions duplicates a lot of code
undesirably.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Similar to the way thread-viewing was broken after a thread was
archived, (and recently fixed), tag manipulation has also been broken
when the thread no longer matches the current search.
This also means that the behavior of '+' and '-' are now different
than that of '*'. The '+' and '-' bindings now return to the previous
behavior old affecting all messages in the thread, (and not simply
those matching the search).
I actually prefer this behavior, since otherwise a '-' operation on a
thread might not actually remove the tag from the thread, (since it
could operate on a subset of the thread and not hit all messages with
the given tag).
So I'd now like to fix '*' to be consistent with '+' and '-', for
which we add an item to TODO.
|
|
|
|
|
|
| |
This would provide support for "muted" threads, as well as allowing for negative
filtering based on messages not matched by the original search, (but present in
threads that do have at least one matched message).
|
|
|
|
|
| |
Marten Veldthuis pointed out on the mailing list that intentional
spoofing is something that the user should be told about.
|
|
|
|
|
|
|
|
| |
This bug was recently discussed on the mailing list:
id:878wdifu13.fsf@yoom.home.cworth.org
so note one idea for fixing it.
|
|
|
|
| |
Sometime I'll stop misspelling things so much, honets.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A new item from IRC discussion, (speeding up "notmuch restore"), as
well as a bug I just hit myself, (content from citations is not being
indexed).
While here, notce that several items have recently been completed ('?'
now displays documentation, not function names; we have a search
binding from notmush-show-mode; and "notmuch new" responds to SIGINT
by flushing). Finally, the item regarding optimizing chunky searching
is irrelevant since we dropped chunky searching in favor of the much
better streamed searching.
|
|
|
|
|
| |
It's unconditional for a very short time. We expect to soon be
building it only if necessary.
|
|
|
|
|
|
|
|
| |
Since we need to do this for portability, (some systems don't have a
strndup function), we might as well do it unconditionally. There's
almost no disadvantage to doing so, and this has the advantages of not
requiring a configure-time check nor having two different
implementations, one of which would often be less tested.
|
|
|
|
|
| |
It's a bug that processing currently stops when it hits a read-only
file. This is yet another case we'll want our test suite to cover.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|