thread-based email index, search, and tagging https://git.notmuchmail.org/git/notmuch/atom?h=master 2009-11-02T22:36:33Z 2009-11-02T22:36:33Z Carl Worth cworth@cworth.org 2009-11-02T22:36:33Z urn:sha1:fa226a7a10ba95f8d8a7ff92dbfc44f6404d9d4d 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. 2009-10-25T22:55:23Z Carl Worth cworth@cworth.org 2009-10-25T22:55:23Z urn:sha1:eb7b8cf31a8378784e97966204559f1b270ac3e9 Need to be const-clean when handling string literals. 2009-10-19T20:35:29Z Carl Worth cworth@cworth.org 2009-10-19T20:35:29Z urn:sha1:fa562fa22b214a7d253e80c62d4f4c97138a6155 With all the de-glib-ification out of the way, we can now use it to allow for date-based sorting of Xapian search results. 2009-10-19T20:24:12Z Carl Worth cworth@cworth.org 2009-10-19T20:24:12Z urn:sha1:401c6cc5793331773c0230e8ae00e8c4b0c63a5e The obvious thing to do is to treat a missing date as the beginning of time. Also, remove a useless cast from another return of 0. 2009-10-19T20:24:07Z Carl Worth cworth@cworth.org 2009-10-19T20:21:58Z urn:sha1:8e4e0559e74262c3e24f832e5cf729287be205c7 Now completing the process of making this function "our own". The documentation is deleted here, because we already have the documentation we want in notmuch-private.h. 2009-10-19T20:19:37Z Carl Worth cworth@cworth.org 2009-10-19T20:19:37Z urn:sha1:747f610901f979c30dafe22f46e4f0b802c2f901 The original code expected this to be set by running configure. We'll just manually set it here for now. This isn't as portable as if we were doing some compile-time examination of the current system, but I don't need portability now. When someone comes along that wants to port notmuch to another system, they will already have all the #ifdefs in place and will simply need to add the appropriate machinery to set the defines. 2009-10-19T20:14:37Z Carl Worth cworth@cworth.org 2009-10-19T20:14:37Z urn:sha1:c2c50d50c572fcd2a015aeba87d33a8ccf5a76b8 This change is gratuitous. For now, notmuch is still linking against glib, so I don't have any requirement to remove this, (unlike the last few changes where good taste really did require the changes). The motivation here is two-fold: 1. I'm considering switching away from all glib-based allocation soon so that I can more easily verify that the memory management is solid. I want valgrind to say "no leaks are possible" not "there is tons of memory still allocated, but probably reachable so who knows if there are leaks or not?". And glib seems to make that impossible. 2. I don't think there's anything performance-sensitive about the allocation here. (In fact, if there is, then the right answer would be to do this parsing without any allocation whatsoever.) 2009-10-19T20:11:57Z Carl Worth cworth@cworth.org 2009-10-19T20:11:57Z urn:sha1:c777524834a805476d0dce81b42342dca4702893 While this is surely one of the most innocent typedefs, it still annoys me to have basic types like 'int' re-defined like this. It just makes it harder to copy the code between projects, with very little benefit in readability. For readability, predicate functions and variables should be obviously Boolean-natured by their actual *names*. 2009-10-19T20:09:19Z Carl Worth cworth@cworth.org 2009-10-19T20:09:19Z urn:sha1:dbadca9a63ce9e97dc2d80fb0fee7ba2f8640316 That's got to be one of the hardest macro names to read, ever, (it's phrased with an implicit negative in the condition, rather than something simple like "assert"). Plus, it's evil, since it's a macro with a return in it. And finally, it's actually *longer* than just typing "if" and "return". So what's the point of this ugly idiom? 2009-10-19T20:07:58Z Carl Worth cworth@cworth.org 2009-10-19T20:07:58Z urn:sha1:9f3649370cefe3d4a28b0df7cb3fea32ded9251a Never know when the children might be reading over my shoulder, for example. :-)