utf-8 in author field
On Mon, 17 May 2010 09:56:27 +0200, Michal Sojka wrote: > On Fri, 14 May 2010, Igor Shenderovich wrote: > > What should one do to see the true list of authors? > > I encounter the same when headers are not encoded properly according to > RFC 2047. I commonly see the violation of section 5, paragraph (3), > sentence "An 'encoded-word' MUST NOT appear within a 'quoted-string'". > That is when the encoded word is enclosed in double quotes. I guess, the > "problem" is not only notmuch related, but all users of gmime library > must be affected. Thanks for that explanation, Michal. Igor, does that explanation seem correct for the situation you have? > I use the following patch for notmuch to sanitize headers from a popular > mailing list server in Czech republic: Obviously that patch is a little too specific to be considered for upstream notmuch. But I'm curious to know if there's anything general that we could do in notmuch? My guess is that the best we could do is to come up with some heuristics for recognizing a non-RFC-compliant header here and munging it. And the heuristics could then fail with messages that were RFC-compliant and intentionally including a string of characters that would match the heuristic, (which would presumably be rare, but not impossible---so perhaps we would then need some configuration). Anyway, if one of you could send an example of a misbehaving message, I might like to look at it and perhaps add it to the test suite to see if there's anything we can safely do about it. -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101029/10e5ea6f/attachment-0001.pgp>
[PATCH 0/4] Maildir synchronization
On Thu, 10 Jun 2010 06:59:02 +0200, Michal Sojka wrote: > This is a known limitation. > From id:1273580061-22580-3-git-send-email-sojkam1 at fel.cvut.cz: > >The reason is that when you view the message its unread tag is >removed which leads to rename of the file, but Emacs still uses the >original name to access the attachment. > >Workaround: close the message and open it again. Hi Michal, These patches do indeed look very interesting. But the above limitation is really too severe. It just breaks things to much. Let's get that fixed first. > IMHO, the final solution to this issue would be the "notmuch cat" > command. With this command, emacs would not access the messages by file > name, but by message id. Sounds like a great idea. Instead of "notmuch cat", how about we name this "notmuch show --format=raw"? That should be even easier to implement, too. Then, I think I'll be very interested in the maildir-synchronization patches, and further I'd like to have these enabled by default. After, all the #1 item in the TODO list for quite some time has been: 1. A new import is tagging all messages as "inbox" -- total pain And this has the potential to finally fix that. Finally, as for configuration, I don't like the numeric codes for this feature. Do we really need that much granularity in the functionality here? Other mail clients certainly don't. From what I can see, most mail clients just twiddle these flags unconditionally. I can imagine some people might want to be able to turn the feature off entirely, so maybe we'll need that. Or perhaps more importantly than configuration, we need the ability to easily migrate people to a synchronized state. For example, in my current mail store, most filenames have never been changed, so I've got a lot of files with flags that don't match my tags. What do you think would be the best way to resolve a situation like that? Looking forward to more here, -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101029/7c7fbeea/attachment.pgp>
rfc: improved MIME handling (multipart)
On Mon, 10 May 2010 11:33:03 +0100, David Edmondson wrote: > A (third) attempt at improved MIME handling, specifically for multipart, > is at: >http://github.com/dme/notmuch/tree/mp3 >git://github.com/dme/notmuch.git (branch 'mp3') Hi David, I went to pull this, but I couldn't find satisfactory commit messages. Things like "multipart: Fix part counting" aren't descriptive enough for me. What was broken? How was it fixed? A good test for a bug-fix commit message is "Could a reasonable person (skilled in the art) read my commit message and confidently create a test case for my fix?". If not, please add more detail. As for the non-bug-fix stuff here, similarly I can't tell exactly what the changes are. I can see from the commit messages that the part handling is changing. But under what situations does it now behave differently? If I wanted to stress this to see if it inadvertently breaks things, how might I do so? I'd like to have fairly good answers for questions like that from the commit messages, rather than having to reverse-engineer the answers from the patches themselves. Please feel free to resubmit these with some updated commit messages. Thanks! -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101029/e780ba53/attachment.pgp>
couple of naive questions about search patterns
On Fri, 16 Jul 2010 11:21:58 +0200, Michal Sojka wrote: > No, this is because 're:' in subject is not indexed. See > skip_re_in_subject() in index.cc. That's a correct explanation of the problem. But meanwhile, I don't have any good justification for that code. I wrote it originally because I was trying to create an indexer that would be term-for-term compatible with the indexer of sup. But since that's not a goal of notmuch, we could easily drop this code. Does anybody see a reason not to do that? > > BTW: Is it possible to specify beginning(^) or the end in subject > > search pattern? > > I don't think so. We don't currently have a way to do that, but I think it could be mighty handy if we did. It's conceivable that the notmuch indexer could be augmented to store special terms for beginning-of-line and end-of-line and then we could make the query parser understand '^' and '$' as mapping to these terms. That will be easier to consider after we have a custom query parser, which is something on my TODO list. -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101029/277834ca/attachment.pgp>
SpamAssassin or: why can't I search for »[«?
On Wed, 16 Jun 2010 13:55:10 +0200, Albin Stjerna wrote: > I've been trying to get notmuch to apply the tag ?spam? to these mails, > but it seems I can neither make it search for upper-case letters nor > ?[?/?]?. My current solution is to tag everything with ?spam? somewhere > in the subject header as spam, which leads to lots of false positives. Hi Albin, I'm sorry that nobody answered this fairly simple question of yours earlier. What's happening here is that Xapian (the indexer used by notmuch) looks for "word characters" and "non-word characters" that separate words[*]. Then, the words are indexed (with numeric information indicating their position) and the separators are thrown away. So there's no way to search for separators such as ?[?/?]?. As for case-sensitivity, Xapian does provide capabilities such that notmuch could offer optional case-sensitive searching. But that might require more storage space than notmuch is currently using. It would also require us to add some syntax to the search terms so that a user can request case-sensitive searches. Meanwhile, for a long-term fix for your problem, we plan to add the ability to allow you to use notmuch to search for a header such as "X-Spam-Flag: YES". This isn't currently possible, but when we implement that, it should be much more reliable than finding flagged spam by looking for words in the subject. > Also, and much less importantly, is there any way to have notmuch > harvest email addresses for BBDB? We haven't written code to do the "insinuate" into bbdb thing by default, but someone could do that. Early in my use of notmuch I wrote some scripts that ran notmuch commands, grepped out addresses, and stuffed them into bbdb. That was nice at first, but not usable in the long-term since the database didn't grow as new addresses appeared in emails. More recently, we've added support to do tab-based completion of addresses based on automatic searching through your notmuch mail store, (rather than something external like bbdb). This is quite nice, but currently a bit of effort to setup. See the "how to get email address completion" instructions here: http://notmuchmail.org/emacstips/ In the future, I'd like to get this address completion working by default without requiring the download of an additional tool, (like the current notmuch_addresses.py or addrlookup programs). Having more direct support for address completion within the notmuch database itself will make it faster as well, (the current tools are grubbing through actual mail files to find complete addresses). -Carl [*] I'm sure I'm using the wrong terminology for Xapian, and I might have some details wrong, but the basic idea is hopefully correct. -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101029/76a47413/attachment.pgp>
[PATCH] notmuch.pod: pod version of documentation, converted by rman, massaged by hand.
On Sun, 13 Jun 2010 12:01:30 -0300, david at tethera.net wrote: > We can also generate man pages and inline help from this file. I > didn't get that far yet, waiting for more encouraging noises :). Hi David, Having added some documentation recently, I do continue to be annoyed by the need to add it all in two places. So I am still interested in taking advantage of your work here. I know that you've already refreshed it more than once, so I won't ask you to do that again. But if you could implement the ability to actually generate the inline help and man page from this file (even just the version here would be fine), then I'd be quite happy to look at that. And then, if I'm happy with the result, I'd be willing to do the job of refreshing the documentation to the latest. Thanks again, -Carl PS. Or if you just want to drop this, that's fine too. I won't go insisting that you do additional work if you don't feel like it. ;-) -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101029/55080843/attachment.pgp>
fix problem with notmuch-hello-nice-number
On Thu, 10 Jun 2010 08:05:13 +0100, David Edmondson wrote: > On Wed, 09 Jun 2010 07:49:01 -0700, Dirk Hohndel > wrote: > > Without this little patch notmuch fails with current git if there's a > > saved search that has zero results > > How about: ... >(setq n (/ n 1000))) > +(setq result (or result '(0))) > (apply #'concat Thanks Dirk and David, I've just pushed this version (finally!) of this nearly-trivial patch
[PATCH] emacs: Re-work the implementation of highlighting in notmuch-search-mode.
On Mon, 7 Jun 2010 15:35:10 +0100, David Edmondson wrote: > Re-write `notmuch-search-color-line', with the following improvements: > - create overlays only if they will be needed, > - merge the properties specified for a tag on top of any matching a >previous tag. ... > +The attributes defined for matching tags are merged, with later > +attributes overriding earlier. A message having both \"delete\" > +and \"unread\" tags with the above settings would have a green > +foreground and blue background." Thanks David, That looks like a very useful change. All pushed now. (Though I don't yet have any automated tests to cover colors in emacs buffers. Anyone care to cook something up?) -Carl -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101029/d3db8a4e/attachment.pgp>
[PATCH 2/3] build: fix DSO dependencies
On Sat, 5 Jun 2010 14:05:14 +0300, Felipe Contreras wrote: > At least on Fedora 13, this doesn't link; the linker finds the > dependencies, and aborts saying we should include them. ... > We do need to link at least to what we really use, the linker resolves > the dependencies of our dependencies at loading time. So let's only > specify what we use directly. Hi Felipe, You're certainly right that the linking was bogus. The notmuch binary was only linking directly against libnotmuch (which in turned linked against GMime, Xapian, and talloc). But meanwhile, the notmuch binary is also directly using GMime and talloc so should be linking directly against those. > -ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1) > FINAL_NOTMUCH_LDFLAGS += $(CONFIGURE_LDFLAGS) > -FINAL_NOTMUCH_LINKER = CXX > -endif But the change above causes the notmuch binary to also link directly against Xapian, (which the binary does not use directly), so that's undesired. > - gmime_ldflags=$(pkg-config --libs $gmimepc) > + if [ $linker_resolves_library_dependencies = "1" ]; then > + gmime_ldflags="-lgmime-2.6 -lgobject-2.0 -lglib-2.0" > + else > + gmime_ldflags=$(pkg-config --libs $gmimepc) > + fi This part I don't understand. Why is it necessary to avoid using pkg-config in this case? That sounds to me like a maintenance nightmare. If the pkg-config information for GMime is wrong then we should get that fixed, and not workaround it. So, finally, I implemented a much more narrow fix for the linking problem, (simply adding $(GMIME_LDFLAGS) and $(TALLOC_LDFLAGS) to the FINAL_NOTMUCH_LDFLAGS assignement). I tested this by installing binutils-gold on my Debian system. This caused a compilation failure before my patch, but compilation succeeds after my patch. I'm optimistic that this means that a Fedora compilation will work as well now. Can you test that please? -Carl PS. For the other two patches you sent. I couldn't see that #1 (moving the platform-detection earlier in configure) is necessary. But #3 seems obviously correct, so I've pushed that now. I do apologize that it has been many months since you posted these patches, and that you got no review of them until now. But thanks indeed for sending them! -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101029/2cd9303d/attachment.pgp>
[PATCH] Don't involve the shell in notmuch searches
On Thu, 3 Jun 2010 20:29:32 -0400, David Benjamin wrote: > The shell isn't needed to interpret any of the arguments, so don't > bother using it at all. Thanks David, I refreshed this to the current master and pushed it. -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101029/2f261fc4/attachment.pgp>
Fix missing References from broken muas.
On Sat, 08 May 2010 14:36:26 +0200, Arvid Picciani wrote: > Most of my mail comes from the 50MLs i'm subscribed to. Unfortunately > some MUAs suck that much, they don't even respond in threads. > My idea how to fix them would be: People have previously asked for a feature to combine messages into the same thread. And it would actually be a fairly simple operation. Perhaps it could be something like: notmuch set-thread $(notmuch search --threads ) The bigger problem is that as soon as we have an operation to join threads, people are going to need an operation to split threads. (And some people want this already for cases where people reply when they should have composed a new message.) The split case is harder in that it will require some extra stashing of information about the intent of the split, (otherwise, the current logic will recombine things when a future message arrives that References: messages from two split threads). So I think we'd need a proposal to handle that before we could do splitting. The proposal I'm looking for here would be at the database level, not the command-line level. -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101029/93bd66ae/attachment.pgp>
[PATCH] notmuch-setup.c: Initialize getline(3) response_size to 0
On Thu, 14 Oct 2010 14:18:19 -0400, Mike Kelly wrote: > This appears to be necessary on FreeBSD. If this isn't done, we get a > nasty segfault. Thanks. I've pushed this out. I didn't have that initialized originally, because the documentation I have for getline on my Linux machine says explicitly: If *lineptr is NULL, then getline() will allocate a buffer for storing the line, which should be freed by the user program. (In this case, the value in *n is ignored.) But, oh well, it's easy enough to fix. Thanks again for the patch. -Carl -- carl.d.worth at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101029/32ce5436/attachment.pgp>
Notmuch scripters rejoice! New "notmuch search --output=(...)"
On 2010-10-28, Carl Worth wrote:
> I just added a new feature to notmuch that I've been wanting for a very
> long time. It's a new option to "notmuch search" as follows:
>
> --output=(summary|threads|messages|files|tags)
>
> The "summary" value is the default and behaves as "notmuch search"
> always has, (printing a one-line summary with a bunch of information
> about each thread).
>
> Each of the other options causes "notmuch search" to print only a single
> value, (thread ID, message ID, filename, or tag), one-per-line[*]. This
> is intended to be useful in scripts to do things as follows:
>
> for spamfile in $(notmuch search tag:spam); do
> rm $spamfile
> done
>
> Or what have you.
>
> I hope people find this useful. See "notmuch help search" for more
> details.
Going from :
my $notmuch = `notmuch show @ARGV`;
my @filenames = ();
while ($notmuch =~ /^\x{0c}message{ .+filename:(.+)$/mg) {
push @filenames, $1;
}
to :
my @filenames = split /\n/, `notmuch search --output=files @ARGV`;
Thanks, that will clearly enhance my script.
--
Fran?ois
Notmuch scripters rejoice! New "notmuch search --output=(...)"
On Thu, 28 Oct 2010 12:24:45 -0700, Carl Worth wrote: > --output=(summary|threads|messages|files|tags) > for spamfile in $(notmuch search tag:spam); do > rm $spamfile > done Wow, that is very useful thanks. This will creating scripts much easier indeed. As for count, I would leave that in, it's seems much nicer than a |wc -l Thanks! Keep the good stuff coming. Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20101029/b84a6926/attachment.pgp>
Where should I pull notmuch from?
On Wed, 27 Oct 2010, Christophe-Marie Duquesne wrote: > seen from older posts that some work has been done directly on > notmuch: > http://notmuch.198994.n3.nabble.com/PATCH-0-4-Maildir-synchronization-v2-td1694007.html#a1694007 > > Are this patches pulled on the official notmuch or should I use Michal > Sojka's git repository? Hi Christophe-Marie, these patches are not yet in the official repository, but I hope they appear there ASAP. In the mean time please use my repo. -Michal
Re: [PATCH] notmuch-setup.c: Initialize getline(3) response_size to 0
On Thu, 14 Oct 2010 14:18:19 -0400, Mike Kelly pi...@pioto.org wrote: This appears to be necessary on FreeBSD. If this isn't done, we get a nasty segfault. Thanks. I've pushed this out. I didn't have that initialized originally, because the documentation I have for getline on my Linux machine says explicitly: If *lineptr is NULL, then getline() will allocate a buffer for storing the line, which should be freed by the user program. (In this case, the value in *n is ignored.) But, oh well, it's easy enough to fix. Thanks again for the patch. -Carl -- carl.d.wo...@intel.com pgp7exiyPPyDh.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Fix missing References from broken muas.
On Sat, 08 May 2010 14:36:26 +0200, Arvid Picciani a...@exys.org wrote: Most of my mail comes from the 50MLs i'm subscribed to. Unfortunately some MUAs suck that much, they don't even respond in threads. My idea how to fix them would be: People have previously asked for a feature to combine messages into the same thread. And it would actually be a fairly simple operation. Perhaps it could be something like: notmuch set-thread $(notmuch search --threads parent) children The bigger problem is that as soon as we have an operation to join threads, people are going to need an operation to split threads. (And some people want this already for cases where people reply when they should have composed a new message.) The split case is harder in that it will require some extra stashing of information about the intent of the split, (otherwise, the current logic will recombine things when a future message arrives that References: messages from two split threads). So I think we'd need a proposal to handle that before we could do splitting. The proposal I'm looking for here would be at the database level, not the command-line level. -Carl -- carl.d.wo...@intel.com pgpbWKDLMVwMK.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: fix problem with notmuch-hello-nice-number
On Thu, 10 Jun 2010 08:05:13 +0100, David Edmondson d...@dme.org wrote: On Wed, 09 Jun 2010 07:49:01 -0700, Dirk Hohndel hohn...@infradead.org wrote: Without this little patch notmuch fails with current git if there's a saved search that has zero results How about: ... (setq n (/ n 1000))) +(setq result (or result '(0))) (apply #'concat Thanks Dirk and David, I've just pushed this version (finally!) of this nearly-trivial patch From so long ago. The bug hasn't been as important lately since by default notmuch doesn't even display saved searches with 0 results. But the bug was still present for anyone that set notmuch-show-empty-saved-searches to a non-nil value. I've also added a test to the test suite to ensure this case gets exercised there. Thanks again, -Carl -- carl.d.wo...@intel.com pgp5ElP4mZvze.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] build: fix DSO dependencies
From: Carl Worth cwo...@cworth.org At least on Fedora 13, this doesn't link; the linker finds the dependencies, and aborts saying we should include them. /usr/bin/ld: gmime-filter-reply.o: undefined reference to symbol 'g_mime_filter_set_size' /usr/bin/ld: note: 'g_mime_filter_set_size' is defined in DSO /usr/lib/libgmime-2.6.so.0 so try adding it to the linker command line /usr/lib/libgmime-2.6.so.0: could not read symbols: Invalid operation We do need to link at least to what we really use, the linker resolves the dependencies of our dependencies at loading time. For more information, see: https://fedoraproject.org/wiki/UnderstandingDSOLinkChange Reported by Felipe Contreras, rewrote by Carl Worth. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Makefile.local |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile.local b/Makefile.local index bc61a3c..9fed725 100644 --- a/Makefile.local +++ b/Makefile.local @@ -31,7 +31,7 @@ GPG_FILE=$(SHA1_FILE).asc # Smash together user's values with our extra values FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS) $(CONFIGURE_CFLAGS) $(extra_cflags) FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS) $(extra_cflags) $(extra_cxxflags) -FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch +FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch $(GMIME_LDFLAGS) $(TALLOC_LDFLAGS) FINAL_NOTMUCH_LINKER = CC ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1) FINAL_NOTMUCH_LDFLAGS += $(CONFIGURE_LDFLAGS) -- 1.7.3.2.2.g0dc5c ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/2] build: only link to what we really use
At least linux has the -Wl,--as-needed option. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- Makefile.local |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/Makefile.local b/Makefile.local index 9fed725..70c395a 100644 --- a/Makefile.local +++ b/Makefile.local @@ -33,7 +33,9 @@ FINAL_CFLAGS = -DNOTMUCH_VERSION=$(VERSION) $(CFLAGS) $(WARN_CFLAGS) $(CONFIGURE FINAL_CXXFLAGS = $(CXXFLAGS) $(WARN_CXXFLAGS) $(CONFIGURE_CXXFLAGS) $(extra_cflags) $(extra_cxxflags) FINAL_NOTMUCH_LDFLAGS = $(LDFLAGS) -Llib -lnotmuch $(GMIME_LDFLAGS) $(TALLOC_LDFLAGS) FINAL_NOTMUCH_LINKER = CC -ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1) +ifeq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1) +FINAL_NOTMUCH_LDFLAGS += -Wl,--as-needed +else FINAL_NOTMUCH_LDFLAGS += $(CONFIGURE_LDFLAGS) FINAL_NOTMUCH_LINKER = CXX endif -- 1.7.3.2.2.g0dc5c ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/3] build: fix DSO dependencies
Hello, On Sat, Oct 30, 2010 at 12:37 AM, Carl Worth cwo...@cworth.org wrote: On Sat, 5 Jun 2010 14:05:14 +0300, Felipe Contreras felipe.contre...@gmail.com wrote: At least on Fedora 13, this doesn't link; the linker finds the dependencies, and aborts saying we should include them. ... We do need to link at least to what we really use, the linker resolves the dependencies of our dependencies at loading time. So let's only specify what we use directly. You're certainly right that the linking was bogus. The notmuch binary was only linking directly against libnotmuch (which in turned linked against GMime, Xapian, and talloc). But meanwhile, the notmuch binary is also directly using GMime and talloc so should be linking directly against those. -ifneq ($(LINKER_RESOLVES_LIBRARY_DEPENDENCIES),1) FINAL_NOTMUCH_LDFLAGS += $(CONFIGURE_LDFLAGS) -FINAL_NOTMUCH_LINKER = CXX -endif But the change above causes the notmuch binary to also link directly against Xapian, (which the binary does not use directly), so that's undesired. Yes, I wanted to fix that in subsequent patches, but my first objective was to get it to build. - gmime_ldflags=$(pkg-config --libs $gmimepc) + if [ $linker_resolves_library_dependencies = 1 ]; then + gmime_ldflags=-lgmime-2.6 -lgobject-2.0 -lglib-2.0 + else + gmime_ldflags=$(pkg-config --libs $gmimepc) + fi This part I don't understand. Why is it necessary to avoid using pkg-config in this case? That sounds to me like a maintenance nightmare. If the pkg-config information for GMime is wrong then we should get that fixed, and not workaround it. Well, it's not possible: pkg-config is supposed to work on win32 and osx, so all the dependencies must be there, so: % pkg-config --libs gmime-2.6 -pthread -lgmime-2.6 -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 Means we would be linking to many libraries we are not going to use directly. Fortunately, I found the solution after writing that patch: -Wl,--as-needed. With this the linker would automatically figure out that we actually want to link only to -lgmime-2.6 -lgobject-2.0 -lglib-2.0. So, finally, I implemented a much more narrow fix for the linking problem, (simply adding $(GMIME_LDFLAGS) and $(TALLOC_LDFLAGS) to the FINAL_NOTMUCH_LDFLAGS assignement). I tested this by installing binutils-gold on my Debian system. This caused a compilation failure before my patch, but compilation succeeds after my patch. I'm optimistic that this means that a Fedora compilation will work as well now. Can you test that please? Patch #1 is not needed if gmime_ldflags in patch #2 are not changed conditionally, which can be achieved by --as-needed. I just sent my proposed updated patches. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: rfc: improved MIME handling (multipart)
On Mon, 10 May 2010 11:33:03 +0100, David Edmondson d...@dme.org wrote: A (third) attempt at improved MIME handling, specifically for multipart, is at: http://github.com/dme/notmuch/tree/mp3 git://github.com/dme/notmuch.git (branch 'mp3') Hi David, I went to pull this, but I couldn't find satisfactory commit messages. Things like multipart: Fix part counting aren't descriptive enough for me. What was broken? How was it fixed? A good test for a bug-fix commit message is Could a reasonable person (skilled in the art) read my commit message and confidently create a test case for my fix?. If not, please add more detail. As for the non-bug-fix stuff here, similarly I can't tell exactly what the changes are. I can see from the commit messages that the part handling is changing. But under what situations does it now behave differently? If I wanted to stress this to see if it inadvertently breaks things, how might I do so? I'd like to have fairly good answers for questions like that from the commit messages, rather than having to reverse-engineer the answers from the patches themselves. Please feel free to resubmit these with some updated commit messages. Thanks! -Carl -- carl.d.wo...@intel.com pgpkKK920DKXo.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 0/4] Maildir synchronization
On Thu, 10 Jun 2010 06:59:02 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: This is a known limitation. From id:1273580061-22580-3-git-send-email-sojk...@fel.cvut.cz: The reason is that when you view the message its unread tag is removed which leads to rename of the file, but Emacs still uses the original name to access the attachment. Workaround: close the message and open it again. Hi Michal, These patches do indeed look very interesting. But the above limitation is really too severe. It just breaks things to much. Let's get that fixed first. IMHO, the final solution to this issue would be the notmuch cat command. With this command, emacs would not access the messages by file name, but by message id. Sounds like a great idea. Instead of notmuch cat, how about we name this notmuch show --format=raw? That should be even easier to implement, too. Then, I think I'll be very interested in the maildir-synchronization patches, and further I'd like to have these enabled by default. After, all the #1 item in the TODO list for quite some time has been: 1. A new import is tagging all messages as inbox -- total pain And this has the potential to finally fix that. Finally, as for configuration, I don't like the numeric codes for this feature. Do we really need that much granularity in the functionality here? Other mail clients certainly don't. From what I can see, most mail clients just twiddle these flags unconditionally. I can imagine some people might want to be able to turn the feature off entirely, so maybe we'll need that. Or perhaps more importantly than configuration, we need the ability to easily migrate people to a synchronized state. For example, in my current mail store, most filenames have never been changed, so I've got a lot of files with flags that don't match my tags. What do you think would be the best way to resolve a situation like that? Looking forward to more here, -Carl -- carl.d.wo...@intel.com pgp1bh4vwhEwQ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: utf-8 in author field
On Mon, 17 May 2010 09:56:27 +0200, Michal Sojka sojk...@fel.cvut.cz wrote: On Fri, 14 May 2010, Igor Shenderovich wrote: What should one do to see the true list of authors? I encounter the same when headers are not encoded properly according to RFC 2047. I commonly see the violation of section 5, paragraph (3), sentence An 'encoded-word' MUST NOT appear within a 'quoted-string'. That is when the encoded word is enclosed in double quotes. I guess, the problem is not only notmuch related, but all users of gmime library must be affected. Thanks for that explanation, Michal. Igor, does that explanation seem correct for the situation you have? I use the following patch for notmuch to sanitize headers from a popular mailing list server in Czech republic: Obviously that patch is a little too specific to be considered for upstream notmuch. But I'm curious to know if there's anything general that we could do in notmuch? My guess is that the best we could do is to come up with some heuristics for recognizing a non-RFC-compliant header here and munging it. And the heuristics could then fail with messages that were RFC-compliant and intentionally including a string of characters that would match the heuristic, (which would presumably be rare, but not impossible---so perhaps we would then need some configuration). Anyway, if one of you could send an example of a misbehaving message, I might like to look at it and perhaps add it to the test suite to see if there's anything we can safely do about it. -Carl -- carl.d.wo...@intel.com pgpentmz4sZ5L.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
