| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
| |
A "make" invocation still works from the top-level, but not from
down inside the lib directory yet.
|
| |
|
|
| |
Shorter naming without being any less clear. A definite win.
|
| |
|
|
|
| |
The new function for formatting relative dates is nice enough that
we need to start using it more places. Here's one of them.
|
| |
|
|
|
|
|
| |
We're using a delimiter syntax that Keith is optimistic about
being able to easily parse in emacs. Note: We're not escaping
any occurrence of the delimiters in the message yet, so we'll
need to fix that.
|
| |
|
|
|
| |
And use this in "notmuch search" to display subject line as well as
thread ID.
|
| |
|
|
|
| |
And augment "notmuch search" to print tag values as well as thread ID
values. This tool is almost usable now.
|
| |
|
|
|
| |
If we were using a talloc-based resizing array then this wouldn't
have happened. Of course, thanks to valgrind for catching this.
|
| |
|
|
|
|
| |
We had documented both notmuch_thread_results_get and
notmuch_message_results_get to return NULL if (! has_more)
but we hadn't actually implemented that. Fix.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've now got a new notmuch_query_search_threads and a
notmuch_threads_result_t iterator. The thread object itself
doesn't do much yet, (just allows one to get the thread_id),
but that's at least enough to see that "notmuch search" is
actually doing something now, (since it has been converted
to print thread IDs instead of message IDs).
And maybe that's all we need. Getting the messages belonging
to a thread is as simple as a notmuch_query_search_messages
with a string of "thread:<thread-id>".
Though it would be convenient to add notmuch_thread_get_messages
which could use the existing notmuch_message_results_t iterator.
Now we just need an implementation of "notmuch show" and we'll
have something somewhat usable.
|
| |
|
|
|
|
|
|
|
|
| |
Along with renaming notmuch_results_t to notmuch_message_results_t.
The new type is quite a mouthful, but I don't expect it to be
used much other than the for-loop idiom in the documentation,
(which does at least fit nicely within 80 columns).
This is all in preparation for the addition of a new
notmuch_query_search_threads of course.
|
| |
|
|
|
|
| |
We were previously just doing fprintf;exit at each point, but I
wanted to add file and line-number details to all messages, so it
makes sense to use a single macro for that.
|
| |
|
|
| |
What a great feeling to remove an XXX comment.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, it's nice that for now we don't have any users yet, so we
can make incompatible changes to the database layout like this
without causing trouble. ;-)
There are a few reasons for this change. First, we now use value 0
uniformly as a timestamp for both mail and timestamp documents, (which
lets us cleanup an ugly and fragile bare 0 in the add_value and
get_value calls in the timestamp code).
Second, I want to drop the thread value entirely, so putting it at the
end of the list means we can drop it as compatible change in the
future. (I almost want to drop the message-ID value too, but it's nice
to be able to sort on it to get diff-able output from "notmuch dump".)
But the thread value we never use as a value, (we would never sort on
it, for example). And it's totally redundant with the thread terms we
store already. So expect it to disappear soon.
|
| |
|
|
|
|
| |
I'm planning to change prefix values soon, which would break code
like this. So eliminate the fragility by going through our existing
_find_prefix function.
|
| |
|
|
|
|
|
|
|
| |
Here's the big bug that was preventing any searches from working at
all like desired. I did the work to carefully pick out exactly the
flags that I wanted, and then I threw it away by trying to combine
them with & instead of | (so just passing 0 for flags instead).
Much better now.
|
| |
|
|
|
|
|
|
|
|
|
| |
It's nice that Xapian provides a little function to print a textual
representation of the entire query tree. So now, if you compile
like so:
make CFLAGS=-DDEBUG_QUERY
then you get a nice output of the query string received by the query
module, and the final query actually being sent to Xapian.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
To properly support sorting in notmuch_query we know use an
Enquire object. We also throw in a QueryParser too, so we're
really close to being able to support arbitrary full-text
searches.
I took a look at the supported QueryParser syntax and chose
a set of flags for everything I like, (such as supporting
Boolean operators in either case ("AND" or "and"), supporting
phrase searching, supporting + and - to include/preclude terms,
and supporting a trailing * on any term as a wildcard).
|
| |
|
|
|
|
|
| |
Using the address of a static char* was clever, but really
unnecessary. An empty string is much less magic, and even
easier to understand as the way to query everything from
the database.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
None of these are strictly necessary, (everything was leak-free
without them), but notmuch_message_destroy can actually be useful
for when one query has many message results, but only one is needed
to be live at a time.
The destroy functions for results and tags are fairly gratuitous, as
there's unlikely to be any benefit from calling them. But they're all
easy to add, (all of these functions are just wrappers for talloc_free),
and we do so for consistency and completeness.
|
| |
|
|
|
| |
I want to reserve the _destroy names for some public functions
I'm about to add.
|
|
|
This is a fairly big milestone for notmuch. It's our first command
to do anything besides building the index, so it proves we can
actually read valid results out from the index.
It also puts in place almost all of the API and infrastructure we
will need to allow searching of the database.
Finally, with this change we are now using talloc inside of notmuch
which is truly a delight to use. And now that I figured out how
to use C++ objects with talloc allocation, (it requires grotty
parts of C++ such as "placement new" and "explicit destructors"),
we are valgrind-clean for "notmuch dump", (as in "no leaks are
possible").
|
Carl Worth