aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* README: Add a simple file explaining notmuch and pointing out resources.Carl Worth2009-11-02
| | | | This is part of getting notmuch ready for a more public announcement.
* Add a simple manual page for notmuch.Carl Worth2009-11-02
| | | | | By pulling content out of notmuch help, and also the messages printed by "notmuch setup".
* notmuch: Add a talloc context argument to each top-level command function.Carl Worth2009-10-31
| | | | | | | 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).
* Rename message_results/thread_results to messages/threads.Carl Worth2009-10-31
| | | | Shorter naming without being any less clear. A definite win.
* notmuch.el: Add commands to add tag, remove tag, and archive (== remove ↵Carl Worth2009-10-31
| | | | | | | | | | | | | | inbox tag) 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 )
* notmuch: Reference help, don't print it for unknown commands.Carl Worth2009-10-31
| | | | | The shorter output is much nicer for something that might end up in an emacs mini-buffer, for example.
* notmuch.el: Add final '*' to generated buffer names.Carl Worth2009-10-31
| | | | Just looks a little neater that way.
* notmuch.el: Enter now calls "notmuch show" on the current threadCarl Worth2009-10-31
| | | | | It's remarkable how little code we need for a very functional GUI here. I think we're doing something right.
* notmuch.el: Start fleshing out notmuch-search-mode with a custom keymapCarl Worth2009-10-31
| | | | | All we have here so far is 'n' and 'p' for going to next and previous lines respectively.
* notmuch.el: Switch from start-process to call-processCarl Worth2009-10-31
| | | | | | | 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.
* notmuch.el: Switch from compilation-start to start-processCarl Worth2009-10-30
| | | | | | 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.
* notmuch.el: Add notmuch-search command as well as notmuchCarl Worth2009-10-30
| | | | This allows for entering a query string interactively.
* notmuch.el: Copy copyright information from compilation.elCarl Worth2009-10-30
| | | | | | 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.
* notmuch.el: Rename from notmuch-mode.el to notmuch.elCarl Worth2009-10-30
| | | | Also add the copyright and licensing blurb.
* notmuch-mode: Add an actualy notmuch-search-mode as wellCarl Worth2009-10-30
| | | | | | 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.
* The very beginnings of an emacs mode for notmuch in notmuch-mode.el.Carl Worth2009-10-30
| | | | | As expected, there's not much done here yet---it simply displays the output of "notmuch search" in a new window.
* TODO: Add man page and compiling a libnotmuch library to the list.Carl Worth2009-10-30
| | | | These are things we'll want done before any big announcement.
* Makefile: Add a simple target for "make install".Carl Worth2009-10-30
| | | | The more I do here, the less I see the need for autotools.
* TODO: Note that "notmuch show" exists now and list several new ideas.Carl Worth2009-10-30
| | | | | | 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).
* Fix relative date formatting to not split one day into two formats.Carl Worth2009-10-29
| | | | | | | | | | | | | 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).
* notmuch search: Add (relative) date to search outputCarl Worth2009-10-29
| | | | | The new function for formatting relative dates is nice enough that we need to start using it more places. Here's one of them.
* notmuch show: Add a one-line summary of the message before the header.Carl Worth2009-10-29
| | | | | The idea here is that a client could usefully display just this one line while optionally hiding the other header fields.
* notmuch show: Trim down header list.Carl Worth2009-10-29
| | | | | This is for now a non-configurable list of Subject, From, To, Cc, Bcc, and Date.
* notmuch show: Add body of message as well.Carl Worth2009-10-29
| | | | | 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.
* notmuch show: Initial implementation (headers only)Carl Worth2009-10-29
| | | | | | | 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.
* TODO: Update now that full-text indexing is in.Carl Worth2009-10-28
| | | | | The optimization idea removed here doesn't make sense anymore with full-text indexing happening up front.
* Fix add_message and get_filename to strip/re-add the database path.Carl Worth2009-10-28
| | | | | We now store only a relative path inside the database so the database is not nicely relocatable.
* notmuch setup/new: Print progress once per second instead of after 1000 files.Carl Worth2009-10-28
| | | | | | 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.
* index: Don't bother indexing quoted portions of messages (and signatures).Carl Worth2009-10-28
| | | | | | | | | | | | | 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 "-- ".
* notmuch_database_add_message: Sanity check the file as the first thingCarl Worth2009-10-28
| | | | | 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.
* Tweak formatting of internal error messages.Carl Worth2009-10-28
| | | | | | 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.
* index: Store "Full Name <user@example.com>" addressses in the databaseCarl Worth2009-10-28
| | | | | | | 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.
* Add full-text indexing using the GMime library for parsing.Carl Worth2009-10-28
| | | | | | | | | | | 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.
* notmuch search: Clarify documentation of implicit Boolean operatorsCarl Worth2009-10-28
| | | | | | | | | The original documentation of implicit AND is what we want, but Xapian doesn't actually let us get that today. So be honest about what the user can actually expect. And let's hope the Xapian wizards give us the feature we want soon: http://trac.xapian.org/ticket/402
* TODO: A couple new items.Carl Worth2009-10-28
| | | | | It's time to put full-text indexing back, and we might want to experiment with optimization the original thread-stitching phase.
* TODO: Remove a couple of since-completed items.Carl Worth2009-10-28
| | | | | | | | | | | "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).
* notmuch help: Review and augment all of the "notmuch help" documentation.Carl Worth2009-10-28
| | | | | | The big addition here is the first description of the syntax for the query strings for "notmuch search", (and, by reference, for "notmuch tag").
* notmuch help: Be less verbose by default and support detailed helpCarl Worth2009-10-28
| | | | | | | | | | | Putting all of our documentation into a single help message was getting a bit unwieldy. Now, the simple output of "notmuch help" is a reasonable reminder and a quick reference. Then we now support a new syntax of: "notmuch help <command>" for the more detailed help messages. This gives us freedom to put more detailed caveats, etc. into some sub-commands without worrying about the usage statement getting too long.
* notmuch tag: Fix crash when removing a tag that didn't existCarl Worth2009-10-27
| | | | | Xapian is trying to be useful by reporting that the specified term didn't exist, but this is one case where we just don't care. :-)
* Fix segfault in case of the database lock not being available.Carl Worth2009-10-27
| | | | | | We were nicely reporting the lock-aquisition failure, but then marching along trying to use the database object and just crashing badly. So don't do that.
* Update prefix so that "thread:" can be used in search strings.Carl Worth2009-10-27
| | | | | | | | | | | It's convenient to be able to do things like: notmuch tag -inbox thread:<thread-id> (even though this can run into a race condition as noted in TODO--the fix for the race is simply to not run "notmuch new" between reading a thread with the (not yet existent) "notmuch show" and removing its inbox tag with a command like the above). So we now allow such a thing.
* Add new "notmuch tag" command for adding/removing tags.Carl Worth2009-10-27
| | | | | | | | | | This uses the same search functionality as "notmuch search" so it should be quite powerful. And this global search might be quick enough to be used for "automatic" adding of tags to new messages. Of course, this will all be a lot more useful when we can search for actual text of messages and not just tags.
* notmuch_database_add_message: Do not return a message on failure.Carl Worth2009-10-27
| | | | | | | The recent, disastrous failure of "notmuch new" would have been avoided with this change. The new_command function was basically assuming that it would only get a message object on success so wasn't destroying the message in the other cases.
* notmuch_database_close: Explicitly flush the Xapian database.Carl Worth2009-10-27
| | | | | | | | | | This would have helped with the recent bug causing "notmuch new" to not record any results in the database. I'm not sure why the explicit flush would be required, (shouldn't the destructor always ensure that things flush?), but perhaps some outstanding references from the leak prevented that. In any case, an explicit flush on close() seems to make sense.
* Merge branch to fix broken "notmuch setup" and "notmuch new"Carl Worth2009-10-27
|\ | | | | | | | | | | | | I'm trying to stick to a habit of fixing previously-introduced bugs on side branches off of the commit that introduced the bug. The idea here is to make it easy to find the commits to cherry pick if bisecting in the future lands on one of the broken commits.
| * Fix "notmuch new" (bad performance, and no committing of results).Carl Worth2009-10-27
| | | | | | | | | | | | | | | | | | | | | | | | | | We were incorrectly only destroying messages in the case of successful addition to the database, and not in other cases, (such as failure due to FILE_NOT_EMAIL). I'm still not entirely sure why this was performing abysmally, (as in making an operation that should take a small fraction of a second take 10 seconds), nor why it was causing the database to entirely fail to get new results. But fortunately, this all seems to work now.
| * Unbreak the "notmuch setup" command.Carl Worth2009-10-27
| | | | | | | | | | | | | | | | | | The recent addition of support for automatically adding tags to new messages for "notmuch new" caused "notmuch setup" to segfault. The fix is simple, (just need to move a destroy function to inside a nearby if block). Did I mention recently we need to add a test suite?
* | TODO: Several more ideas that have come to mind, that I don't want to forget.Carl Worth2009-10-27
| | | | | | | | | | Some of these are simple little code cleanups, but it's nice to write them down rather than trying to remember them.
* | TODO: More notes on archive-thread and race conditions.Carl Worth2009-10-27
| | | | | | | | | | | | | | 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.
* | TODO: Add "notmuch tag" and thoughts on avoiding races in archiving threads.Carl Worth2009-10-27
| | | | | | | | | | | | 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).
generated by cgit v1.2.3 (git 2.39.1) at 2024-06-29 09:44:49 +0000