| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
Also, take care to remove a final blank line to avoid the point
going beyond the last thread in the buffer.
|
|
There are conceptually three different projects here, so it helps
to keep the tasks for each separated.
|
|
Also add 'q' and 'x' keybindings to kill the current buffer.
|
|
Most all of the returned strings will now fill most of a 12-character
string, (depending on the length of the month).
|
|
The notmuch.c main program now uses GMime directly rather than using
these functions, and I'd rather not export any functions unless we
have good evidence that the functions are necessary.
|
|
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.
|
|
We had originally copied this function in at a time when notmuch
wasn't actually depending on the GMime library. Now that it does,
we might as well call the function that exists there rather
than having a private copy of it.
|
|
Additionally, print a part number for each MIME part so that the
client could (conceivably) ask for the contents of a specific
part by part number.
|
|
Use GMime function to decode message-header values according to
RFC 2047.
|
|
This can allow for the client to hide undesired MIME parts
such as text/html.
|
|
We now actually get text content rather than blocks of BASE64, etc.
|
|
These are the things that are actively preventing me from being able
to use notmuch as an email-reading client.
|
|
The README file was already referring to this, so we actually add it
now.
|
|
This is *not* based on autoconf. In fact, this doesn't actually
configure anything, (one can compile notmuch directly with just
"make" without running configure if the dependencies are all
satisfied).
The only thing that this configure script does is to check for the
presence of the various dependencies and provide some guidance to
the user if they are not all available.
|
|
I was about to refer to these names in some documentation, so I
wanted a slightly better name for them.
|
|
This is part of getting notmuch ready for a more public announcement.
|
|
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 have keybindings of '+', '-', and 'a'. The bug they have so
far is lack of visual feedback for their effect, and lack of undo.
(Also the fact that adding or removing a single tag for a thread
takes way too long--but that's as a Xapian issue as discussed here:
replace_document should make minimal changes to database file
http://trac.xapian.org/ticket/250
)
|
|
The shorter output is much nicer for something that might end up
in an emacs mini-buffer, for example.
|
|
Just looks a little neater that way.
|
|
It's remarkable how little code we need for a very functional GUI
here. I think we're doing something right.
|
|
All we have here so far is 'n' and 'p' for going to next and
previous lines respectively.
|
|
We now get the point staying right at the top where we want it.
We also don't get any extraneous noise about "Process notmuch
completed" or anything like that. Just the output in a read-only
buffer.
|
|
Compilation mode does a bunch of things that we don't want. Instead
of trying to tear it down to what we want, let's start at the other
end and build up only things that we really want.
|
|
This allows for entering a query string interactively.
|
|
I'm using that file as my reference here, so I'm likely to end up
copying some code here or there. Might as well be safe and just
copy the copyright statement.
|
|
Also add the copyright and licensing blurb.
|
|
Doesn't really do anything so far other than mark the buffer read-
only. This does have the benefit of giving us our own name rather
than "Compilation" for the mode.
|
|
As expected, there's not much done here yet---it simply displays the
output of "notmuch search" in a new window.
|
|
These are things we'll want done before any big announcement.
|
|
The more I do here, the less I see the need for autotools.
|
|
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).
|
|
We were aware of this bug when we wrote the function, (that a date
six days in the past would be treated as the "Friday" or as the
"Oct. 23" case depending on whether its time was before or after
the current time today). We thought it wouldn't be a problem, but
in practice it is. In scanning search results with this output,
the transition between formats makes it look like a day boundary,
(so it would be easy to mistakenly think "Oct. 23" is Thursday).
Fix this to avoid confusion, (still being careful to never print
"Thursday" for a date 7 days in the past when today is Thursday).
|
|
The new function for formatting relative dates is nice enough that
we need to start using it more places. Here's one of them.
|
|
The idea here is that a client could usefully display just this one
line while optionally hiding the other header fields.
|
|
This is for now a non-configurable list of Subject, From, To, Cc,
Bcc, and Date.
|
|
This is just the raw message body for now, (so any MIME parsing will
be up to the consumer). And this will likely change in the future.
|
|
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.
|
|
The optimization idea removed here doesn't make sense anymore with
full-text indexing happening up front.
|
|
We now store only a relative path inside the database so the database
is not nicely relocatable.
|
|
With the recent addition of full-text indexing, printing only once per
1000 files just isn't often enough. The new timer-based approach will
be reliable regardless of the speed of adding message.
|
|
Our old notmuch-index-message.cc code had this, but I originally
left it out when adding indexing back in. I was concerned primarily
with mistakenly detecting signature markers and omitting important
text, (for example, I often do long lines of "----" as section
separators).
But now I see that there's a performance benefit to skippint the
quotations, (about 120 files/sec. instead of 95 files/sec.). I mitigated
the bogus signature checking by recognizing nothing other than the
all-time classic "-- ".
|
|
This avoids us wasting a bunch of time doing an expensive SHA-1 over a large
file only to discover later that it doesn't even *look* like an email message.
|
|
Was neglecting to print the phrase "Internal error: " before, and for
the duplicate message-ID error it's nice to actually see the duplicate
IDs.
|
|
We put these is as a separate term so that they can be extracted.
We don't actually need this for searching, since typing an email
address in as a search term will already trigger a phrase search
that does exactly what's wanted.
|
|
This is based on the old notmuch-index-message.cc from early in
the history of notmuch, but considerably cleaned up now that
we have some experience with Xapian and know just what we want
to index, (rather than just blindly trying to index exactly
what sup does).
This does slow down notmuch_database_add_message a *lot*, but I've
got some ideas for getting some time back.
|
