How to index arbitrary headers?
On 4 October 2012 13:51, Nicol?s Reynolds wrote: > Austin Clements writes: > >> Quoth Petri Savolainen on Oct 01 at 3:39 pm: >>>Hello, >>>I could not find information anywhere in notmuch docs about what is >>>actually indexed - specifically, what email headers are indexed and >>>searchable? If a header is not indexed, does searching for its value >>> still >>>result in a search hit? >>>It would be nice if one could just provide the list of headers to be >>>indexed in some configuration file or something. >>>Thanks, >>> Petri >> >> notmuch doesn't currently implement this, though it is an >> oft-requested feature. One (not insurmountable) difficulty is that >> the database would have to be rebuilt if a user-configured list of >> headers changed and there are technical limitations that prevent us >> from simply indexing all headers. Out of curiosity, what headers are >> you interested in indexing? >> >> The currently indexed headers are described in man >> notmuch-search-terms. > > maybe related: is it possible to index only the headers and not the mail > body? > Checkout project `afew` which pipes complete emails and assigns tags based on the parse result. It may be sufficient for your purpose. Or you can modify notmuch to index the stuff you want. Regards, Dmitrijs.
How to index arbitrary headers?
On 3 October 2012 19:32, Petri Savolainen wrote: > Hi, > > thanks for your response. I am evaluating notmuch / xapian for building an > application for analyzing in various ways a fairly large number of emails > accumulated over several years. I am afraid the number of headers that would > ultimately need to be indexed is therefore quite a lot larger than what > notmuch currently indexes. > > Petri > > 2012/10/1 Austin Clements >> >> Quoth Petri Savolainen on Oct 01 at 3:39 pm: >> >Hello, >> >I could not find information anywhere in notmuch docs about what is >> >actually indexed - specifically, what email headers are indexed and >> >searchable? If a header is not indexed, does searching for its value >> > still >> >result in a search hit? >> >It would be nice if one could just provide the list of headers to be >> >indexed in some configuration file or something. >> >Thanks, >> > Petri >> >> notmuch doesn't currently implement this, though it is an >> oft-requested feature. One (not insurmountable) difficulty is that >> the database would have to be rebuilt if a user-configured list of >> headers changed and there are technical limitations that prevent us >> from simply indexing all headers. Out of curiosity, what headers are >> you interested in indexing? >> >> The currently indexed headers are described in man >> notmuch-search-terms. > Use mapreduce instead: hadoop or discoproject or haddop with dumbo should be faster. Regards, Dmitrijs.
Re: How to index arbitrary headers?
On 3 October 2012 19:32, Petri Savolainen pe...@koodaamo.fi wrote: Hi, thanks for your response. I am evaluating notmuch / xapian for building an application for analyzing in various ways a fairly large number of emails accumulated over several years. I am afraid the number of headers that would ultimately need to be indexed is therefore quite a lot larger than what notmuch currently indexes. Petri 2012/10/1 Austin Clements amdra...@mit.edu Quoth Petri Savolainen on Oct 01 at 3:39 pm: Hello, I could not find information anywhere in notmuch docs about what is actually indexed - specifically, what email headers are indexed and searchable? If a header is not indexed, does searching for its value still result in a search hit? It would be nice if one could just provide the list of headers to be indexed in some configuration file or something. Thanks, Petri notmuch doesn't currently implement this, though it is an oft-requested feature. One (not insurmountable) difficulty is that the database would have to be rebuilt if a user-configured list of headers changed and there are technical limitations that prevent us from simply indexing all headers. Out of curiosity, what headers are you interested in indexing? The currently indexed headers are described in man notmuch-search-terms. Use mapreduce instead: hadoop or discoproject or haddop with dumbo should be faster. Regards, Dmitrijs. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: How to index arbitrary headers?
On 4 October 2012 13:51, Nicolás Reynolds fa...@kiwwwi.com.ar wrote: Austin Clements amdra...@mit.edu writes: Quoth Petri Savolainen on Oct 01 at 3:39 pm: Hello, I could not find information anywhere in notmuch docs about what is actually indexed - specifically, what email headers are indexed and searchable? If a header is not indexed, does searching for its value still result in a search hit? It would be nice if one could just provide the list of headers to be indexed in some configuration file or something. Thanks, Petri notmuch doesn't currently implement this, though it is an oft-requested feature. One (not insurmountable) difficulty is that the database would have to be rebuilt if a user-configured list of headers changed and there are technical limitations that prevent us from simply indexing all headers. Out of curiosity, what headers are you interested in indexing? The currently indexed headers are described in man notmuch-search-terms. maybe related: is it possible to index only the headers and not the mail body? Checkout project `afew` which pipes complete emails and assigns tags based on the parse result. It may be sufficient for your purpose. Or you can modify notmuch to index the stuff you want. Regards, Dmitrijs. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Bug (?) difference 24.1 and 23.3.1
On 31 August 2012 15:45, Daniel Bergey wrote: > > Now I just have to get used to pictures in my email > I understand how disturbing that might be. Welcome to 2012... at least it's not full html5 & css3 animations. Maybe emacs will support that in couple of years. I have customized that functions with an empty one, so I don't see any pictures, but all of my email works. Regards, Dmitrijs.
multipart/alternative bug
On 13 August 2012 16:50, hellekin wrote: > > Hello, > > as I mentioned on IRC a few days ago, there are some cases where: > > - a thread only displays the first message > - key bindings do not work at all (except q) > Does this in ~/.emacs help ? (defvar gnus-inhibit-images nil "*testing") (set-variable 'gnus-inhibit-images nil) Don't ask why. I have no clue!
Re: multipart/alternative bug
On 13 August 2012 16:50, hellekin helle...@cepheide.org wrote: Hello, as I mentioned on IRC a few days ago, there are some cases where: - a thread only displays the first message - key bindings do not work at all (except q) Does this in ~/.emacs help ? (defvar gnus-inhibit-images nil *testing) (set-variable 'gnus-inhibit-images nil) Don't ask why. I have no clue! ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
adding emacs-snapshot as alternative to emacs
On 22/06/12 11:23, David Bremner wrote: > Rainer M Krug writes: > >> OK - I accept the reasoning behind not adding emacs-snapshot as an >> alternative to the defaults. But as I guess as quite a few are using >> emacs-snapshot and notmuch, it would make sense to just add a patch to >> the source which one could execute to add emacs-snapshot to the list >> of alternative dependencies. > Similar request was declined by Debian maintainer as well. As emacs-snapshot is a moving target, w.r.t. features, maybe we should ask emacs-snaphost packaging to add Provides: emacs22, emacs23, emacs24 And update those as necessary? Then no changes to all the external package would be needed. -- Regards, Dmitrijs.
Re: adding emacs-snapshot as alternative to emacs
On 22/06/12 11:23, David Bremner wrote: Rainer M Krug r.m.k...@gmail.com writes: OK - I accept the reasoning behind not adding emacs-snapshot as an alternative to the defaults. But as I guess as quite a few are using emacs-snapshot and notmuch, it would make sense to just add a patch to the source which one could execute to add emacs-snapshot to the list of alternative dependencies. Similar request was declined by Debian maintainer as well. As emacs-snapshot is a moving target, w.r.t. features, maybe we should ask emacs-snaphost packaging to add Provides: emacs22, emacs23, emacs24 And update those as necessary? Then no changes to all the external package would be needed. -- Regards, Dmitrijs. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
