[PATCH 1/1] cli/show: avoid empty write to stdout in format_part_raw
Previously (at least) if the input was exactly 4096 bytes long,
notmuch would attempt to fwrite nothing to stdout, but still expected
fwrite to return 1, causing a failure that looked like this:
$ notmuch show --format=raw id:87o96f1cya@codeaurora.org
...entire message shown as expected..
Error: Write failed
$ echo $?
1
To fix the problem don't call fwrite at all when there's nothing to
write.
---
Proposed for 0.28.4 -- thanks.
notmuch-show.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index c3a3783a..98b85352 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -851,7 +851,7 @@ format_part_raw (unused (const void *ctx), unused
(sprinter_t *sp),
return NOTMUCH_STATUS_FILE_ERROR;
}
- if (fwrite (buf, size, 1, stdout) != 1) {
+ if (size > 0 && fwrite (buf, size, 1, stdout) != 1) {
fprintf (stderr, "Error: Write failed\n");
fclose (file);
return NOTMUCH_STATUS_FILE_ERROR;
--
2.20.1
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/1] Store and search for canonical Unicode text [WIP]
Rob Browning <r...@defaultvalue.org> writes: > David Bremner <da...@tethera.net> writes: >> It seems plausible to specify UTF-8 input for the library, but what >> about the CLI? It seems like the canonicalization operation increases >> the chance of mangling user input in non-UTF-8 locales. > > Yes, the key question: what does notmuch intend? i.e. given a sequence > of bytes, how will notmuch interpret them? I think we should decide > that, and document it clearly somewhere. > > The commit message describes my understanding of how things currently > work, and if/when I get time, I'd like to propose some related > documentation updates (perhaps to notmuch-search-terms or > notmuch-insert/new?). > > Oh, and if I do understand things correctly, notmuch may already stand a > chance of mangling any bytes that aren't an invalid UTF-8 byte sequence, > but also aren't actually in UTF-8 (excepting encodings that are a strict > subset of UTF-8, like ASCII). > > For example (if I did this right), [0xd1 0xa1] is valid UTF-8, producing > omega "ѡ", and also valid Latin-1, producing "Ñ¡". So on this particular point, I'm perhaps too used to thinking about the general encoding problem, and wasn't thinking about our specific constraints. If (1) "normal" message bodies are required to be US-ASCII (which I'd neglected to remember might be the case), and (2) MIME handles the rest, then perhaps notmuch will only receive raw bytes via user input (i.e. query strings, etc.). In which case, we could just document that notmuch interprets user input as UTF-8 (and we might or might not mention the Latin-1 fallback). Later locale support could be added if desired, and none of this would involve the quite nasty problem of encoding detection. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/1] Store and search for canonical Unicode text [WIP]
David Bremner <da...@tethera.net> writes: > One way to break this up into more bite sized pieces would be to first > create one or more tests that fail with current notmuch, and mark those > as broken. Right - for the moment I just wanted to post what I had for consideration. I didn't want to spend too much more time on the approach if was uninteresting/inappropriate. One simple place to start might be the included T570-normalization.sh. Though perhaps that should be "canonicalization"? > Can you explain why notmuch is the right place to do this, and not > Xapian? I know we talked back and forth about this, but I never really > got a solid sense of what the conclusion was. Is it just dependencies? I have no strong opinion there, but to do the work in Xapian will require a new release at a minimum, and likely new dependencies. And generally speaking, I suppose I have a suspicion that application needs with respect to encoding "detection", tokenization, stemming, stop words, synonyms, phrase detection, etc. may be domain specific and complex enough that Xapian won't want to try to accommodate the broad array of possibilities, at least not in its core library. Though it might try to handle some or all of that by providing suitable customizability (presumably via callbacks or subclassing or...). And since I'm new to Xapian, I'm not completely sure what's already available. > It seems plausible to specify UTF-8 input for the library, but what > about the CLI? It seems like the canonicalization operation increases > the chance of mangling user input in non-UTF-8 locales. Yes, the key question: what does notmuch intend? i.e. given a sequence of bytes, how will notmuch interpret them? I think we should decide that, and document it clearly somewhere. The commit message describes my understanding of how things currently work, and if/when I get time, I'd like to propose some related documentation updates (perhaps to notmuch-search-terms or notmuch-insert/new?). Oh, and if I do understand things correctly, notmuch may already stand a chance of mangling any bytes that aren't an invalid UTF-8 byte sequence, but also aren't actually in UTF-8 (excepting encodings that are a strict subset of UTF-8, like ASCII). For example (if I did this right), [0xd1 0xa1] is valid UTF-8, producing omega "ѡ", and also valid Latin-1, producing "Ñ¡". > I suppose some upgrade code to canonicalize all the terms? That sounds > pretty slow. Perhaps, or I suppose you could just document that older indexed data might not be canonicalized, and that you should reindex if that matters to you. Although I suppose anyone with affected characters might well want to reindex if the canonical form isn't the one people normally receive (which seemed possible). Hmm, another question -- for terms, does notmuch store ordinal positions, Unicode character offsets, input byte offsets, or...? Canonicalization will of course change the latter. I imagine it might be possible to traverse the index terms and just detect and merge those affected, but no idea if that would be reasonable. > I really didn't look at the code very closely, but there were a > surprising number of calls to talloc_free. But those kind of details can > wait. Right, I wasn't sure what the policies were, so in most cases, I just tried to release the data when it was no longer needed. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/1] Store and search for canonical Unicode text [WIP]
private_status);
@@ -1212,10 +1227,14 @@ notmuch_message_remove_tag (notmuch_message_t *message,
const char *tag)
if (tag == NULL)
return NOTMUCH_STATUS_NULL_POINTER;
-if (strlen (tag) > NOTMUCH_TAG_MAX)
+const char *u8_tag = notmuch_bytes_to_utf8 (message, tag, -1);
+if (strlen (u8_tag) > NOTMUCH_TAG_MAX) {
+ talloc_free ((char *) u8_tag);
return NOTMUCH_STATUS_TAG_TOO_LONG;
+}
-private_status = _notmuch_message_remove_term (message, "tag", tag);
+private_status = _notmuch_message_remove_term (message, "tag", u8_tag);
+talloc_free ((char *) u8_tag);
if (private_status) {
INTERNAL_ERROR ("_notmuch_message_remove_term return unexpected value:
%d\n",
private_status);
diff --git a/lib/notmuch.h b/lib/notmuch.h
index b1f5bfa..6e13eb1 100644
--- a/lib/notmuch.h
+++ b/lib/notmuch.h
@@ -1759,6 +1759,9 @@ notmuch_filenames_move_to_next (notmuch_filenames_t
*filenames);
void
notmuch_filenames_destroy (notmuch_filenames_t *filenames);
+char *
+notmuch_bytes_to_utf8 (const void *ctx, const char *bytes, const size_t len);
+
/* @} */
NOTMUCH_END_DECLS
diff --git a/lib/query.cc b/lib/query.cc
index 5275b5a..e48f06a 100644
--- a/lib/query.cc
+++ b/lib/query.cc
@@ -86,7 +86,7 @@ notmuch_query_create (notmuch_database_t *notmuch,
query->notmuch = notmuch;
-query->query_string = talloc_strdup (query, query_string);
+query->query_string = notmuch_bytes_to_utf8 (query, query_string, -1);
query->sort = NOTMUCH_SORT_NEWEST_FIRST;
@@ -125,7 +125,9 @@ notmuch_query_get_sort (notmuch_query_t *query)
void
notmuch_query_add_tag_exclude (notmuch_query_t *query, const char *tag)
{
-char *term = talloc_asprintf (query, "%s%s", _find_prefix ("tag"), tag);
+const char *u8_tag = notmuch_bytes_to_utf8 (query, tag, -1);
+char *term = talloc_asprintf (query, "%s%s", _find_prefix ("tag"), u8_tag);
+talloc_free ((char *) u8_tag);
_notmuch_string_list_append (query->exclude_terms, term);
}
diff --git a/lib/text-util.cc b/lib/text-util.cc
new file mode 100644
index 000..9dfd31f
--- /dev/null
+++ b/lib/text-util.cc
@@ -0,0 +1,82 @@
+/* text-util.cc - notmuch text processing utility functions
+ *
+ * Copyright (C) 2015 Rob Browning
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/ .
+ *
+ * Author: Rob Browning
+ *
+ */
+
+#include "notmuch.h"
+
+#include
+#include
+#include
+#include
+#include
+
+static gsize
+_notmuch_decompose_to_utf8 (const gunichar uc, gchar *out)
+{
+gunichar dc[G_UNICHAR_MAX_DECOMPOSITION_LENGTH];
+// This currently performs canonical decomposition.
+const gsize dcn =
+ g_unichar_fully_decompose (uc, FALSE, dc,
+ G_UNICHAR_MAX_DECOMPOSITION_LENGTH);
+gsize utf8_len = 0;
+for (gsize i = 0; i < dcn; i++)
+{
+ const gint dc_bytes = g_unichar_to_utf8 (dc[i], out);
+ utf8_len += dc_bytes;
+ if (out != NULL)
+ out += dc_bytes;
+}
+return utf8_len;
+}
+
+/* Convert a sequence of bytes to UTF-8, handling input encodings as
+ * Xapian does, but produce the canonical encoding.
+ */
+char *
+notmuch_bytes_to_utf8(const void *ctx, const char *bytes, const size_t len)
+{
+// FIXME: try/catch to convert to error status messages? Can the
+// iterator throw?
+Xapian::Utf8Iterator it;
+gsize u8_len = 0;
+
+// Compute the utf-8 length
+if (len == (size_t) -1)
+ it.assign (bytes, strlen(bytes));
+else
+ it.assign (bytes, len);
+for (unsigned uc = *it; uc != unsigned(-1); it++, uc = *it)
+ u8_len += _notmuch_decompose_to_utf8 (uc, NULL);
+
+// Convert to utf-8
+if (len == (size_t) -1)
+ it.assign (bytes, strlen(bytes));
+else
+ it.assign (bytes, len);
+char *result = talloc_array (ctx, char, u8_len + 1);
+gsize u8_i = 0;
+for (unsigned uc = *it; uc != unsigned(-1); it++, uc = *it) {
+ const gsize dc_bytes = _notmuch_decompose_to_utf8 (uc, &(result[u8_i]));
+ u8_i += dc_bytes;
+}
+assert (u8_i == u8_len);
+result[u8_i] = '\0';
+return result;
+}
diff --git a/test/Makefile.local b/test/Makefile.local
index 2331ceb..fd6d06d 100644
--- a/test/Makefile.local
+++ b/test
WARNING: database upgrade coming
Jani Nikula writes: > Something like this? Just insert text that makes sense to the user. ;) If you decide to go this route, I wonder if it might also be worth adding the text about interruption being OK. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: WARNING: database upgrade coming
Jani Nikula j...@nikula.org writes: Something like this? Just insert text that makes sense to the user. ;) If you decide to go this route, I wonder if it might also be worth adding the text about interruption being OK. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[DRAFT PATCH] notmuch new: do not ignore '.notmuch' in non-toplevel directories
Mark Walters writes:
> An alternative would be to ignore any .notmuch path with a xapian
> sub-directory. This would mean if a user indexed some subset of their
> mail before trying to index the whole thing they wouldn't accidentally
> index the old xapian database.
If you wanted to be fairly careful, perhaps test for
exists(".notmuch/.xapian/flintlock" or ".notmuch/.xapian/iamchert"), or
some other very specific test.
> I think the above was suggested by rlb on irc but I don't think it got
> any reply.
Not sure. Though I'm wondering if I may have suggested we could add a
notmuch specific token file, i.e. .notmuch/this-really-is-a-notmuch-dir,
which lead to someone else suggesting we could just use .xapian.
Of course broadly speaking, ".xapian" might be a legitimate maildir too,
but ".notmuch/.xapian" seems fairly unlikely.
In any case, while I might prefer a very narrow test (as long as it
wasn't unduly expensive), all of the proposed solutions would have
handled my situation.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: [DRAFT PATCH] notmuch new: do not ignore '.notmuch' in non-toplevel directories
Mark Walters markwalters1...@gmail.com writes: An alternative would be to ignore any .notmuch path with a xapian sub-directory. This would mean if a user indexed some subset of their mail before trying to index the whole thing they wouldn't accidentally index the old xapian database. If you wanted to be fairly careful, perhaps test for exists(.notmuch/.xapian/flintlock or .notmuch/.xapian/iamchert), or some other very specific test. I think the above was suggested by rlb on irc but I don't think it got any reply. Not sure. Though I'm wondering if I may have suggested we could add a notmuch specific token file, i.e. .notmuch/this-really-is-a-notmuch-dir, which lead to someone else suggesting we could just use .xapian. Of course broadly speaking, .xapian might be a legitimate maildir too, but .notmuch/.xapian seems fairly unlikely. In any case, while I might prefer a very narrow test (as long as it wasn't unduly expensive), all of the proposed solutions would have handled my situation. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[BUG] Putting "tags=;" into .notmuch-config will create empty tags
In the [new] section, "tags=;" will cause notmuch to create empty tags that are fairly hard to remove from the command line. After some help on #bup, here's what I came up with to remove them, though it assumes that the empty tag "+ " will always be first in dump's output: notmuch dump --format=batch-tag 'tag:""' | perl -pe 's/^\+ //' \ | notmuch restore --format=batch-tag And note that you have to use restore, "notmuch tag --batch" doesn't appear to accept "- " as a tag, even though dump will produce "+ ". Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
[BUG] notmuch excludes .notmuch anywhere in the tree
This might or might not be considered a bug, or at least it might just be wishlist severity, but in my case, I have path=/home/rlb/notmuch and notmuch contained: /home/rlb/notmuch/.notmuch /home/rlb/notmuch/Maildir -> /home/Maildir I arranged things like that so I could easily drop other mail-ish trees into notmuch/ if I liked, and also so that I wouldn't have to worry about the fact that maildir++ is going to name the directory for the notmuch list's folder ".notmuch". However, I outsmarted myself because notmuch ignored both "[path]/.notmuch", and "[path]/Maildir/.notmuch". Though this isn't a critical problem for me. For now, I just rewrote my procmail rules and renamed the directory to .notmuchmail. Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
[BUG] notmuch excludes .notmuch anywhere in the tree
This might or might not be considered a bug, or at least it might just be wishlist severity, but in my case, I have path=/home/rlb/notmuch and notmuch contained: /home/rlb/notmuch/.notmuch /home/rlb/notmuch/Maildir - /home/Maildir I arranged things like that so I could easily drop other mail-ish trees into notmuch/ if I liked, and also so that I wouldn't have to worry about the fact that maildir++ is going to name the directory for the notmuch list's folder .notmuch. However, I outsmarted myself because notmuch ignored both [path]/.notmuch, and [path]/Maildir/.notmuch. Though this isn't a critical problem for me. For now, I just rewrote my procmail rules and renamed the directory to .notmuchmail. Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[BUG] Putting tags=; into .notmuch-config will create empty tags
In the [new] section, tags=; will cause notmuch to create empty tags that are fairly hard to remove from the command line. After some help on #bup, here's what I came up with to remove them, though it assumes that the empty tag + will always be first in dump's output: notmuch dump --format=batch-tag 'tag:' | perl -pe 's/^\+ //' \ | notmuch restore --format=batch-tag And note that you have to use restore, notmuch tag --batch doesn't appear to accept - as a tag, even though dump will produce + . Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 0/5] lib: make folder: prefix literal
Austin Clements writes:
> The simple algorithm of taking the relative path and stripping
> {new,cur} (if present) does a good job of supporting both Maildir and
> non-Maildir stores (while balancing this support with simplicity,
> predictability, and usability).
Unless, of course, the user has legitimate folders named cur and new,
but perhaps that'll just end up a "don't do that then" FAQ...
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: [PATCH 0/5] lib: make folder: prefix literal
Austin Clements amdra...@mit.edu writes:
The simple algorithm of taking the relative path and stripping
{new,cur} (if present) does a good job of supporting both Maildir and
non-Maildir stores (while balancing this support with simplicity,
predictability, and usability).
Unless, of course, the user has legitimate folders named cur and new,
but perhaps that'll just end up a don't do that then FAQ...
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 0/5] lib: make folder: prefix literal
Austin Clements writes: > However, it seems like this is overloading one prefix for two > meanings. Oh, and I agree here. I think that ideally, there would be at least one very-literal way to identify a specific directory (or tree, perhaps via **), and then some other less-precise, but more friendly term(s). -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
[PATCH 0/5] lib: make folder: prefix literal
Austin Clements writes:
> folder: could work the way I suggested (simply the path to the file,
> with {cur,new} stripped off).
Hmm, so would notmuch try to guess whether or not it's dealing with a
maildir++ tree, and if so convert folder:foo to a search of .foo, and/or
folder:foo/bar to .foo.bar? Or would the user just need to know to say
folder:.foo and folder:.foo.bar?
And if we're only planning special treatment for for maildir-like
stores, then I wonder if the term should just be maildir:?
Though folder: would make more sense if the long-term goal was to have a
"DTRT" term. But in that case, I wonder if it might eventually be
expected to support mixed trees, i.e. say a tree containing maildir++
and mh subdirs, and if so, how that should be handled.
> many shells support "**" for recursive path matching and people are
> already quite familiar with glob patterns for paths, so why not simply
> adopt this?
rsync too.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: [PATCH 0/5] lib: make folder: prefix literal
Austin Clements amdra...@mit.edu writes:
folder: could work the way I suggested (simply the path to the file,
with {cur,new} stripped off).
Hmm, so would notmuch try to guess whether or not it's dealing with a
maildir++ tree, and if so convert folder:foo to a search of .foo, and/or
folder:foo/bar to .foo.bar? Or would the user just need to know to say
folder:.foo and folder:.foo.bar?
And if we're only planning special treatment for for maildir-like
stores, then I wonder if the term should just be maildir:?
Though folder: would make more sense if the long-term goal was to have a
DTRT term. But in that case, I wonder if it might eventually be
expected to support mixed trees, i.e. say a tree containing maildir++
and mh subdirs, and if so, how that should be handled.
many shells support ** for recursive path matching and people are
already quite familiar with glob patterns for paths, so why not simply
adopt this?
rsync too.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/5] test: fix insert folder: searches
Austin Clements writes: > This is the other reason I disagree with including cur/new. If we strip > it, people's existing folder: searches will mostly continue to work. If > we include it, such saved searches, scripted searches, and post-new > hooks are guaranteed to break. What about Maildir++'s ".folder" vs an mh (or other) "folder"? And it might be deemed unimportant, but always unifying cur/new will make it impossible for someone not using Maildir to independently refer to legitimate directories named cur and new. If it were feasible to rewrite queries, I'd be tempted to consider adding a fully literal path:, and then building a "more magic" maildir: or folder: on top, via rewriting. Regardless, I suspect that in the long run it might make sense to support literal searches somehowm, in addition to any more "friendly" option (that perhaps guesses about the mailstore type, etc.). One possibility might be to change the current literal folder: proposal to present itself as path: (leaving folder: alone). Then any rework of folder: (as the friendlier term) could be considered independently. But I don't feel very strongly about any of this. I'll be happy with any reasonable way to specify specific "folders" in a Maildir++ tree (with or without cur/new unification, etc.). Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: [PATCH 2/5] test: fix insert folder: searches
Austin Clements amdra...@mit.edu writes: This is the other reason I disagree with including cur/new. If we strip it, people's existing folder: searches will mostly continue to work. If we include it, such saved searches, scripted searches, and post-new hooks are guaranteed to break. What about Maildir++'s .folder vs an mh (or other) folder? And it might be deemed unimportant, but always unifying cur/new will make it impossible for someone not using Maildir to independently refer to legitimate directories named cur and new. If it were feasible to rewrite queries, I'd be tempted to consider adding a fully literal path:, and then building a more magic maildir: or folder: on top, via rewriting. Regardless, I suspect that in the long run it might make sense to support literal searches somehowm, in addition to any more friendly option (that perhaps guesses about the mailstore type, etc.). One possibility might be to change the current literal folder: proposal to present itself as path: (leaving folder: alone). Then any rework of folder: (as the friendlier term) could be considered independently. But I don't feel very strongly about any of this. I'll be happy with any reasonable way to specify specific folders in a Maildir++ tree (with or without cur/new unification, etc.). Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Build system
Carl Worth writes: > This isn't ideal since it means that a non-srcdir build won't get access > to updated emacs nor test-suite bits without re-running configure. If > someone would like to do work to fix either or both of these cases, that > would be helpful. If you're willing to depend on GNU coreutils, would "cp -rl ..." work? -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
[Review] Re: new "crypto" branch providing full PGP/MIME support
Jameson Rollins writes: > If folks have suggestions for disambiguating tag names that don't > themselves create further confusion on some other front, then I'm > inclined to just go with the simplest and most straightforward tag name. Are persistent tags required here? The original question at least, seemed to just be asking for a visual indicator that a message has encrypted or signed bits. So I wondered if that might be accomplished without actual tags. Just curious. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: [Review] Re: new crypto branch providing full PGP/MIME support
Jameson Rollins jroll...@finestructure.net writes: If folks have suggestions for disambiguating tag names that don't themselves create further confusion on some other front, then I'm inclined to just go with the simplest and most straightforward tag name. Are persistent tags required here? The original question at least, seemed to just be asking for a visual indicator that a message has encrypted or signed bits. So I wondered if that might be accomplished without actual tags. Just curious. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Hiding HTML mime-parts and/or scrubbing (gmail's) HTML-based citation
Daniel Kahn Gillmor writes:
> On 02/22/2011 02:42 PM, Albin Stjerna wrote:
>> On Tue, 22 Feb 2011 13:33:56 -0500, Daniel Kahn Gillmor > fifthhorseman.net> wrote:
>>> i think the correct solution would have nothing to do with text/html vs
>>> text/plain, but would have to do with whether the message is
>>> multipart/mixed or multipart/alternative.
>>
>> Thanks for pointing that out ? I see my poor knowledge of MIME is showing.
>>
>> Of course, that sounds like the correct thing to do. However, I'm
>> looking for a (reasonably) quick fix, and what you're suggesting sounds
>> like a re-design of at least a part of the MUA. Isn't there an easier way?
>
> this is how i like it, though it appears i'm only able to save the
> text/html part to a file, rather than force it through whatever html
> renderer notmuch would otherwise use (even with M-x
> notmuch-show-view-all-mime-parts, which surprises me a bit).
The "Display Customization" section in the emacs/mime info pages might
also be interesting. i.e. at the moment I use
mm-discouraged-alternatives like this (via Gnus):
(setq mm-discouraged-alternatives
'("text/html" "text/richtext")
mm-automatic-display
(remove "text/html" mm-automatic-display))
Though it's been so long since I set that up, I can't describe exactly
what it does off the top of my head, but I originally set it up to help
quash the display of html alternatives.
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: Hiding HTML mime-parts and/or scrubbing (gmail's) HTML-based citation
Daniel Kahn Gillmor d...@fifthhorseman.net writes: On 02/22/2011 02:42 PM, Albin Stjerna wrote: On Tue, 22 Feb 2011 13:33:56 -0500, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: i think the correct solution would have nothing to do with text/html vs text/plain, but would have to do with whether the message is multipart/mixed or multipart/alternative. Thanks for pointing that out — I see my poor knowledge of MIME is showing. Of course, that sounds like the correct thing to do. However, I'm looking for a (reasonably) quick fix, and what you're suggesting sounds like a re-design of at least a part of the MUA. Isn't there an easier way? this is how i like it, though it appears i'm only able to save the text/html part to a file, rather than force it through whatever html renderer notmuch would otherwise use (even with M-x notmuch-show-view-all-mime-parts, which surprises me a bit). The Display Customization section in the emacs/mime info pages might also be interesting. i.e. at the moment I use mm-discouraged-alternatives like this (via Gnus): (setq mm-discouraged-alternatives '(text/html text/richtext) mm-automatic-display (remove text/html mm-automatic-display)) Though it's been so long since I set that up, I can't describe exactly what it does off the top of my head, but I originally set it up to help quash the display of html alternatives. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Folder search semantics
Rob Browning writes: > And personally, I think I'd prefer that folder: be anchored by default, > so that folder:work means "the top-level folder named work", but it's > not a big deal to me as long as there's a fairly easy way to specify > exactly what I want. Oh, and in part, the reason why I suspect anchored might be a better default is that it's more conservative. For example, someone who mistakenly assumes that folder: is anchored by default doesn't do any unexpected damage with something like this: $ notmuch tag +deleted folder:misc $ notmuch search tag:deleted ... | xargs rm FWIW -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Folder search semantics
Austin Clements writes: > As a consequence, all folders are subfolders of the inbox. With > recursive search, a search for your inbox folder returns *all* of your > messages. I wasn't trying to say that we shouldn't support recursive > search (I'm all for flexibility), but it's a confusing default for > Maildir++ because of this. > > Maildir++ has the added twist that the inbox folder has no name. As a > result, currently notmuch can't search for a Maildir++ inbox folder, > which needs to be addressed somehow. The least surprising approach > would compatibility with the Maildir++ convention of calling the > top-level folder INBOX, the subfolder INBOX.work, etc. Just adding my agreement here. With recursion and no anchors, "folder:" really won't work for the inbox for Maildir++. > Maildir++ issues aside, I submit that rooted, non-recursive folder > searches are a more natural default with a more conventional syntactic > extension to non-rooted/recursive searches. In > id:87aaiy3u65.fsf at yoom.home.cworth.org, you mentioned that you > implemented non-rooted folder search to mimic subject search. But file > system paths are not natural language like subject lines. File system > paths are hierarchical and rooted. > > Of course, special query operators like ^ and $ can mitigate this, but > these queries *aren't* regexps and, furthermore, people don't usually > apply regexps to file names. They apply globs. Glob syntax has the > added benefit of congruity with Xapian wildcard syntax. This naturally > leads to a rooted, non-recursive syntax by default (like globs), where a > * at the end means recursive and a * at the beginning means non-rooted. > In fact, we could easily generalize this to arbitrary shell globs. I agree with all of this. Something like fnmatch() sounds appropriate to me. In fact, I'd suggest that we implement this very much like fnmatch() with folder references like paths -- where "/" is always the separator, regardless of how things are handled in the underlying storage. So depending on the backend, foo/bar could refer to "Maildir/foo/bar" or "Maildir/.foo.bar". And personally, I think I'd prefer that folder: be anchored by default, so that folder:work means "the top-level folder named work", but it's not a big deal to me as long as there's a fairly easy way to specify exactly what I want. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
RFC: Dovecot locking
Rob Browning writes: > It looks like dovecot's interval is 10 seconds, so for this to work > right, notmuch will need to call lockfile_touch() more often than that. > > /* How often to touch the uidlist lock file when it's locked. > This is done both when using KEEP_LOCKED flag and when syncing a large > maildir. */ > #define MAILDIR_LOCK_TOUCH_SECS 10 > > As yet, I don't know if that's likely to be easy to add. OK, Austin just pointed out that we probably don't need this, at least with the current code. I was just being overly conservative. Since we only hold the lock for the duration of a rename, I don't think there's any need for lockfile_touch(). Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
RFC: Dovecot locking
Rob Browning writes: > Rob Browning writes: > >> This is an unfinished patch to handle Dovecot locking, which is useful >> if we'd like to support running notmuch directly on a Dovecot Maildir: >> >> http://wiki.dovecot.org/MailboxFormat/Maildir#Locking >> >> For now, I'm interested in general comments, i.e. is this desirable, is >> it a reasonable approach, etc. As you can see, there's no config >> handling yet, so -llockfile is added unconditionally. > > Oh, and as Austin reminded me, I forgot to mention that liblockfile may > or may not be appropriate (algorithmically). I'm planning to check and > see how Dovecot handles stale files -- lockfile_create() assumes that > any file older than five minutes is stale. It looks like dovecot's interval is 10 seconds, so for this to work right, notmuch will need to call lockfile_touch() more often than that. /* How often to touch the uidlist lock file when it's locked. This is done both when using KEEP_LOCKED flag and when syncing a large maildir. */ #define MAILDIR_LOCK_TOUCH_SECS 10 As yet, I don't know if that's likely to be easy to add. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: Folder search semantics
Rob Browning r...@defaultvalue.org writes: And personally, I think I'd prefer that folder: be anchored by default, so that folder:work means the top-level folder named work, but it's not a big deal to me as long as there's a fairly easy way to specify exactly what I want. Oh, and in part, the reason why I suspect anchored might be a better default is that it's more conservative. For example, someone who mistakenly assumes that folder: is anchored by default doesn't do any unexpected damage with something like this: $ notmuch tag +deleted folder:misc $ notmuch search tag:deleted ... | xargs rm FWIW -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RFC: Dovecot locking
Rob Browning writes: > This is an unfinished patch to handle Dovecot locking, which is useful > if we'd like to support running notmuch directly on a Dovecot Maildir: > > http://wiki.dovecot.org/MailboxFormat/Maildir#Locking > > For now, I'm interested in general comments, i.e. is this desirable, is > it a reasonable approach, etc. As you can see, there's no config > handling yet, so -llockfile is added unconditionally. Oh, and as Austin reminded me, I forgot to mention that liblockfile may or may not be appropriate (algorithmically). I'm planning to check and see how Dovecot handles stale files -- lockfile_create() assumes that any file older than five minutes is stale. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
RFC: Dovecot locking
This is an unfinished patch to handle Dovecot locking, which is useful if we'd like to support running notmuch directly on a Dovecot Maildir: http://wiki.dovecot.org/MailboxFormat/Maildir#Locking For now, I'm interested in general comments, i.e. is this desirable, is it a reasonable approach, etc. As you can see, there's no config handling yet, so -llockfile is added unconditionally. -- next part -- A non-text attachment was scrubbed... Name: tmp.diff Type: text/x-diff Size: 2263 bytes Desc: rfc-dovecot-locking.diff URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110216/880ef3f6/attachment.diff> -- next part -- -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
RFC: Dovecot locking
This is an unfinished patch to handle Dovecot locking, which is useful
if we'd like to support running notmuch directly on a Dovecot Maildir:
http://wiki.dovecot.org/MailboxFormat/Maildir#Locking
For now, I'm interested in general comments, i.e. is this desirable, is
it a reasonable approach, etc. As you can see, there's no config
handling yet, so -llockfile is added unconditionally.
diff --git a/Makefile.local b/Makefile.local
index 38ead11..c102688 100644
--- a/Makefile.local
+++ b/Makefile.local
@@ -40,7 +40,7 @@ endif
ifeq ($(LIBDIR_IN_LDCONFIG),0)
FINAL_NOTMUCH_LDFLAGS += $(RPATH_LDFLAGS)
endif
-FINAL_LIBNOTMUCH_LDFLAGS = $(LDFLAGS) $(AS_NEEDED_LDFLAGS) $(CONFIGURE_LDFLAGS)
+FINAL_LIBNOTMUCH_LDFLAGS = $(LDFLAGS) $(AS_NEEDED_LDFLAGS) $(CONFIGURE_LDFLAGS) -llockfile
.PHONY: all
all: notmuch notmuch-shared notmuch.1.gz
diff --git a/lib/message.cc b/lib/message.cc
index 979fad5..6a6a7a5 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -23,7 +23,9 @@
#include stdint.h
+#include glib.h
#include gmime/gmime.h
+#include lockfile.h
struct _notmuch_message {
notmuch_database_t *notmuch;
@@ -1222,8 +1224,36 @@ notmuch_message_tags_to_maildir_flags (notmuch_message_t *message)
if (strcmp (filename, filename_new)) {
int err;
notmuch_status_t new_status;
+char *msg_dir = g_path_get_dirname (filename);
+char *maildir = g_path_get_dirname (msg_dir);
+char *dovecot_lock = NULL;
+char *dovecot_uidlist = talloc_asprintf (filename_new, %s/%s,
+ maildir,
+ dovecot-uidlist);
+
+g_free (msg_dir);
+g_free (maildir);
+msg_dir = NULL;
+if (access (dovecot_uidlist, F_OK) == 0) {
+dovecot_lock = talloc_asprintf (filename_new, %s.lock,
+dovecot_uidlist);
+if (lockfile_create (dovecot_lock, 0, 0) != L_SUCCESS) {
+fprintf (stderr, Unable to lock %s\n, dovecot_lock);
+status = NOTMUCH_STATUS_FILE_ERROR;
+continue;
+}
+}
err = rename (filename, filename_new);
+
+if (dovecot_lock) {
+if (lockfile_remove (dovecot_lock) != L_SUCCESS) {
+fprintf (stderr, Unable to unlock %s: %s\n,
+ dovecot_lock, strerror (errno));
+status = NOTMUCH_STATUS_FILE_ERROR;
+}
+}
+
if (err)
continue;
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Return error status from notmuch_message_tags_to_maildir_flags().
Signed-off-by: Rob Browning --- lib/message.cc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/message.cc b/lib/message.cc index 0590f76..979fad5 100644 --- a/lib/message.cc +++ b/lib/message.cc @@ -1252,7 +1252,7 @@ notmuch_message_tags_to_maildir_flags (notmuch_message_t *message) talloc_free (to_set); talloc_free (to_clear); -return NOTMUCH_STATUS_SUCCESS; +return status; } notmuch_status_t -- 1.7.2.3
[PATCH] *** SUBJECT HERE ***
The function notmuch_message_tags_to_maildir_flags() unconditionally returns NOTMUCH_STATUS_SUCCESS, but it looks like it should probably return status. Rob Browning (1): Return error status from notmuch_message_tags_to_maildir_flags(). lib/message.cc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- 1.7.2.3
[PATCH] Return error status from notmuch_message_tags_to_maildir_flags().
Signed-off-by: Rob Browning r...@defaultvalue.org --- lib/message.cc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/message.cc b/lib/message.cc index 0590f76..979fad5 100644 --- a/lib/message.cc +++ b/lib/message.cc @@ -1252,7 +1252,7 @@ notmuch_message_tags_to_maildir_flags (notmuch_message_t *message) talloc_free (to_set); talloc_free (to_clear); -return NOTMUCH_STATUS_SUCCESS; +return status; } notmuch_status_t -- 1.7.2.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] *** SUBJECT HERE ***
The function notmuch_message_tags_to_maildir_flags() unconditionally returns NOTMUCH_STATUS_SUCCESS, but it looks like it should probably return status. Rob Browning (1): Return error status from notmuch_message_tags_to_maildir_flags(). lib/message.cc |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- 1.7.2.3 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Spam and mailing list filtering?
Ben Gamari writes: > I simply run new mail through bogofilter in my sorting script and tag > junk with a junk tag. I then add "not tag:junk" to each of my saved searches. > >> 2) Is there any way (actual or planned) to filter on X-List-Id or >> similar so that I can filter mailing list stuff more accurately Also note that if you're already filtering via procmail or similar, I believe you should be able to use notmuch-deliver to add tags based on the headers it finds. Alternately, if you already deliver all spam to a particular folder, the new "folder:" support might help. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: Spam and mailing list filtering?
Ben Gamari bgamari.f...@gmail.com writes: I simply run new mail through bogofilter in my sorting script and tag junk with a junk tag. I then add not tag:junk to each of my saved searches. 2) Is there any way (actual or planned) to filter on X-List-Id or similar so that I can filter mailing list stuff more accurately Also note that if you're already filtering via procmail or similar, I believe you should be able to use notmuch-deliver to add tags based on the headers it finds. Alternately, if you already deliver all spam to a particular folder, the new folder: support might help. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/3] new: Do not defer maildir flag synchronization during the first run
Austin Clements writes: > Sure. I've been wanting to take a crack at notmuch new's atomicity for > a while. Though you'll have to get through some of my outstanding > patches. I can only keep so many branches in my head. ]:--8) > > rlb, you expressed an interest in solving this problem, too. Did you > make any headway? No, I haven't done anything there yet. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: [PATCH 1/3] new: Do not defer maildir flag synchronization during the first run
Austin Clements amdra...@mit.edu writes: Sure. I've been wanting to take a crack at notmuch new's atomicity for a while. Though you'll have to get through some of my outstanding patches. I can only keep so many branches in my head. ]:--8) rlb, you expressed an interest in solving this problem, too. Did you make any headway? No, I haven't done anything there yet. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Have to configure and build inside the source directory.
Carl Worth writes: > What do other build systems generally do when running configure from > some other directory? Copy/link the Makefiles and then construct them > carefully such that they can find all the source files? I think the use of GNU make VPATH is fairly common. For example, I believe the autotools build a tree that matches the srcdir structure and add Makefiles that contain something like this: VPATH = ../../wherever/notmuch/thisdir ... Of course, given that, the build tree doesn't include any source files. FWIW -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: [PATCH] Have to configure and build inside the source directory.
Carl Worth cwo...@cworth.org writes: What do other build systems generally do when running configure from some other directory? Copy/link the Makefiles and then construct them carefully such that they can find all the source files? I think the use of GNU make VPATH is fairly common. For example, I believe the autotools build a tree that matches the srcdir structure and add Makefiles that contain something like this: VPATH = ../../wherever/notmuch/thisdir ... Of course, given that, the build tree doesn't include any source files. FWIW -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Folder-based searching
Carl Worth writes: > This works in a similar way to 'subject:"some phrase"', (though more > people seem to be asking about these details for folder: than have ever > asked for subject:). I'm not surprised. Imagine: /misc /debian/misc If I understand correctly, right now you'd have to say folder:misc and not folder:debian/misc which is not nearly as handy as folder:^misc and at first, a lot of people may not even realize that they need the "and not" clauses. I'd be tempted to consider making folder: searches rooted by default. I wonder how often people really want "all folders named misc"? > That will require a little care to get some additional terms indexed to > support the rooting, then the in-development custom query parser to > allow mapping symbols like '^' and '$' to these new symbols. Sounds good. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: Folder-based searching
Carl Worth cwo...@cworth.org writes: This works in a similar way to 'subject:some phrase', (though more people seem to be asking about these details for folder: than have ever asked for subject:). I'm not surprised. Imagine: /misc /debian/misc If I understand correctly, right now you'd have to say folder:misc and not folder:debian/misc which is not nearly as handy as folder:^misc and at first, a lot of people may not even realize that they need the and not clauses. I'd be tempted to consider making folder: searches rooted by default. I wonder how often people really want all folders named misc? That will require a little care to get some additional terms indexed to support the rooting, then the in-development custom query parser to allow mapping symbols like '^' and '$' to these new symbols. Sounds good. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Folder-based searching
Carl Worth writes: > Someone bringing in mail from such a system might want to migrate from > information in directory names to instead be information in notmuch > tags. That might look something like this: > > notmuch tag +important folder:important Nice. So what are the path semantics? For example, is the path case sensitive or insensitive? Can you say folder:foo/bar, and if so, is the path rooted, or can it match path sub-segments? i.e. which of these, if any, is "folder:foo/bar" like? (.*/)?foo/bar(/.*)? ^foo/bar$ ^foo/bar(/.*)? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: Folder-based searching
Carl Worth cwo...@cworth.org writes: Someone bringing in mail from such a system might want to migrate from information in directory names to instead be information in notmuch tags. That might look something like this: notmuch tag +important folder:important Nice. So what are the path semantics? For example, is the path case sensitive or insensitive? Can you say folder:foo/bar, and if so, is the path rooted, or can it match path sub-segments? i.e. which of these, if any, is folder:foo/bar like? (.*/)?foo/bar(/.*)? ^foo/bar$ ^foo/bar(/.*)? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Difference between search and filter
Rob Browning writes: > Though I'm also used to 'f' and 'F' for "followup" commands (as compared > to 'r' and 'R' for reply commands), so I'd have to get used to 'f' as > something else, regardless. Also, is notmuch planning to support both followup and reply? If so, then it might make sense to start thinking about the desired keybindings. For example, at least in gnus, 'F' (followup with quoted original) is one of the commands I use most offten. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Difference between search and filter
Xavier Maillard writes: > Yes and no ;) In fact I'd rather have 'f' does a 'f'orward of current > thread/message rather than refine the current search. We could also consider a prefix for less common commands. For example, I'm used to C-c C-f for forward, which I only use occasionally. Though I'm also used to 'f' and 'F' for "followup" commands (as compared to 'r' and 'R' for reply commands), so I'd have to get used to 'f' as something else, regardless. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: Difference between search and filter
Xavier Maillard x...@gnu.org writes: Yes and no ;) In fact I'd rather have 'f' does a 'f'orward of current thread/message rather than refine the current search. We could also consider a prefix for less common commands. For example, I'm used to C-c C-f for forward, which I only use occasionally. Though I'm also used to 'f' and 'F' for followup commands (as compared to 'r' and 'R' for reply commands), so I'd have to get used to 'f' as something else, regardless. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Difference between search and filter
Rob Browning r...@defaultvalue.org writes: Though I'm also used to 'f' and 'F' for followup commands (as compared to 'r' and 'R' for reply commands), so I'd have to get used to 'f' as something else, regardless. Also, is notmuch planning to support both followup and reply? If so, then it might make sense to start thinking about the desired keybindings. For example, at least in gnus, 'F' (followup with quoted original) is one of the commands I use most offten. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
C coding conventions for notmuch
Daniel Kahn Gillmor writes: > attached is a .dir-locals.el file; placed in the root of the notmuch > source tree, it makes emacs pick the default coding style (at least, > using the style i see in notmuch-show.c today). Carl also suggested he might want to folow "linux" style in general, so perhaps: ((c-mode . ((c-file-style "linux") (indent-tabs-mode . t) (tab-width . 8) (c-basic-offset . 4 -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: C coding conventions for notmuch
Daniel Kahn Gillmor d...@fifthhorseman.net writes: attached is a .dir-locals.el file; placed in the root of the notmuch source tree, it makes emacs pick the default coding style (at least, using the style i see in notmuch-show.c today). Carl also suggested he might want to folow linux style in general, so perhaps: ((c-mode . ((c-file-style linux) (indent-tabs-mode . t) (tab-width . 8) (c-basic-offset . 4 -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] compatibility with emacs22
Carl Worth writes: > But perhaps getting access to that single, entire file will be easier > than getting access to these two little functions. Assuming the current emacs-23 version will work: wget -O json.el \ 'http://repo.or.cz/w/emacs.git/blob_plain/emacs-23:/lisp/json.el' -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: [notmuch] [PATCH] compatibility with emacs22
Carl Worth cwo...@cworth.org writes: But perhaps getting access to that single, entire file will be easier than getting access to these two little functions. Assuming the current emacs-23 version will work: wget -O json.el \ 'http://repo.or.cz/w/emacs.git/blob_plain/emacs-23:/lisp/json.el' -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Notmuch Ruby bindings
Andreas Amann writes: > After a number of embarrassing mails I use the attached patch, which > changes the default behaviour of "r" to "reply to sender only". Usual > reply to everybody is "R". Maybe you prefer reversed binding? At least in gnus: r - start reply to author R - start reply to author, including a copy of the original f - start reply to all F - start reply to all, including a copy of the original I believe f/F probably respect Mail-Followup-To. FWIW -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: Notmuch Ruby bindings
Andreas Amann am...@physik.tu-berlin.de writes: After a number of embarrassing mails I use the attached patch, which changes the default behaviour of r to reply to sender only. Usual reply to everybody is R. Maybe you prefer reversed binding? At least in gnus: r - start reply to author R - start reply to author, including a copy of the original f - start reply to all F - start reply to all, including a copy of the original I believe f/F probably respect Mail-Followup-To. FWIW -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RFC: [PATCH] emacs: Improve the definition and use of `notmuch-fcc-dirs'.
David Edmondson writes: > After wanting to be able to set `notmuch-fcc-dirs' to `nil' using > custom, I got sucked in. If you're going to go that far, you might want to allow a function (or form) too (a-la gnus). As an example, that can be handy when you want to file mail based on the year: (setq gnus-message-archive-group '((list (concat "all-" (format-time-string "%Y") That tells gnus that the archive group should be "all-". (Section 5.5 in "info gnus" has all the gory details if you want to see what's been done there.) -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: RFC: [PATCH] emacs: Improve the definition and use of `notmuch-fcc-dirs'.
David Edmondson d...@dme.org writes: After wanting to be able to set `notmuch-fcc-dirs' to `nil' using custom, I got sucked in. If you're going to go that far, you might want to allow a function (or form) too (a-la gnus). As an example, that can be handy when you want to file mail based on the year: (setq gnus-message-archive-group '((list (concat all- (format-time-string %Y) That tells gnus that the archive group should be all-. (Section 5.5 in info gnus has all the gory details if you want to see what's been done there.) -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Adding support for "notmuch new ... PATH"
I'm working on support for something like notmuch new [--] [PATH ..] where PATH can be any path (file or dir) within the mail directory, and I had a couple of questions: 1) What happens if you call notmuch_database_add_message() for a path that's already in the database. Is that OK? 2) Does add_files_recursive() assume it always sees all paths? i.e. is it safe to call it with just a sub-directory of the mail directory? I haven't finished investigating the code, but some bits made me wonder. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Adding support for notmuch new ... PATH
I'm working on support for something like notmuch new [--] [PATH ..] where PATH can be any path (file or dir) within the mail directory, and I had a couple of questions: 1) What happens if you call notmuch_database_add_message() for a path that's already in the database. Is that OK? 2) Does add_files_recursive() assume it always sees all paths? i.e. is it safe to call it with just a sub-directory of the mail directory? I haven't finished investigating the code, but some bits made me wonder. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: First draft of logging functionality.
da...@tethera.net writes: The patches following this message are my first attempt at implementing atomic logging for notmuch. The idea is that such logs could be useful in synchronizing notmuch instances. For this to be completely safe, I suspect it may need to be adjusted to do write ahead logging or something similar. Otherwise operations could be lost. i.e. notmuch would atomically and safely write the intended (tag) operation to the log, then perform the tag. On startup, notmuch would need to scan the log to detect and apply operations that hadn't been fully completed (presumably due to a crash). More generally, while thinking about sync/logging a few days ago, I wondered about using sqlite. That would help with atomicity, rollback, synchronizing multiple readers/writers, etc. It might also make operations more efficient once we implement all the features we want. For example, with the log information in sqlite, a separate notmuch sync to another machine could be reading from the log (and with limitations, writing) in parallel with normal notmuch operations. Depending on how we decide to handle sync with multiple peers, the log may also need to track which peers have seen what, prune appropriately, etc. Of course sqlite may not be appropriate, and would require performance testing, etc., but we should probably think about the features we'll eventually want, and consider how much work they're likely to require with any given approach, regardless. Hope this helps -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Would a more sophisticated notmuch-fcc-dirs be acceptable?
Rob Browning writes: > I'd also like to fcc to a directory outside of message-directory At least for this part, one possiblity would be to just use the chosen directory literally (don't prepend message-directory) whenever it's an absolute path according to file-name-absolute-p. For example: diff --git a/emacs/notmuch-maildir-fcc.el b/emacs/notmuch-maildir-fcc.el index 32e7d0d..3c5d6c4 100644 --- a/emacs/notmuch-maildir-fcc.el +++ b/emacs/notmuch-maildir-fcc.el @@ -87,11 +87,13 @@ ;; if we found no hit, use the first entry as default fallback (unless subdir (setq subdir (car (car notmuch-fcc-dirs) - ;; if there is no fcc header yet, add ours - (unless (message-fetch-field "fcc") -(message-add-header (concat "Fcc: " -(file-name-as-directory message-directory) -subdir))) + ;; if there is no fcc header yet, add ours + (unless (message-fetch-field "fcc") +(let ((path (if (file-name-absolute-p subdir) +subdir + (concat (file-name-as-directory message-directory) + subdir + (message-add-header (concat "Fcc: " path ;; finally test if fcc points to a valid maildir (let ((fcc-header (message-fetch-field "fcc"))) If this seems reasonable, I'd be happy to work up a formal patch. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Would a more sophisticated notmuch-fcc-dirs be acceptable?
I'd like to be able to archive to a destination based on the year, i.e.: (concat "sent-" (format-time-string "%Y")) and I'd like for that string to be recomputed for each outgoing message. I'd also like to fcc to a directory outside of message-directory, and I imagine that sometimes it might be useful to fcc to more than one location. If I have time to work on it, would patches for this sort of thing be interesting? Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
notmuchsync: handling of the deleted tag
Sebastian Spaeth writes: > On 2010-09-21, Rob Browning wrote: >> Conceptually what I'd like for it to do, is reference count -- only mark >> the message deleted if every occurrence (across all maildirs) is marked >> trashed (T). > > Right, but that is trickier than might appear at first sight. In general, I think that until/unless notmuchsync can be more assured of doing the right thing, and in particular, if the deleted tag is likely to become official, notmuchsync should default to not setting it. ...or at least, I'd prefer that. Then I can add --tag-deleted if/when I want to. Of course defaulting to --tag-deleted would also be OK, as long as there's a --no-tag-deleted. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: notmuchsync: handling of the deleted tag
Sebastian Spaeth sebast...@sspaeth.de writes: On 2010-09-21, Rob Browning wrote: Conceptually what I'd like for it to do, is reference count -- only mark the message deleted if every occurrence (across all maildirs) is marked trashed (T). Right, but that is trickier than might appear at first sight. In general, I think that until/unless notmuchsync can be more assured of doing the right thing, and in particular, if the deleted tag is likely to become official, notmuchsync should default to not setting it. ...or at least, I'd prefer that. Then I can add --tag-deleted if/when I want to. Of course defaulting to --tag-deleted would also be OK, as long as there's a --no-tag-deleted. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
notmuchsync: handling of the deleted tag
Sebastian Spaeth writes: > I am unsure how to handle this in a better way. What should notmuchsync > --prune do if it finds multiple mail files that are associated with a > "deleted" tag? Conceptually what I'd like for it to do, is reference count -- only mark the message deleted if every occurrence (across all maildirs) is marked trashed (T). Though even there I can imagine corner cases: imagine that notmuch doesn't initially see all your maildirs -- perhaps because you're using a folder filter in offlineimap, and so there are untrashed copies in the maildirs it hasn't seen yet. But reference counting of everything you can see is probably still better than what we have now, if it's feasible. > And what should --revsync do when it finds a mail file that is marked > as expired. Actually revsync is all I use so far, so that's what I'm talking about above. > If notmuch gave me at least all filenames that are associated with a > mail id, I could introduce a command line option "--prune --safe" which would > Sebastian Looks like you got cut off there. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: notmuchsync: handling of the deleted tag
Sebastian Spaeth sebast...@sspaeth.de writes: I am unsure how to handle this in a better way. What should notmuchsync --prune do if it finds multiple mail files that are associated with a deleted tag? Conceptually what I'd like for it to do, is reference count -- only mark the message deleted if every occurrence (across all maildirs) is marked trashed (T). Though even there I can imagine corner cases: imagine that notmuch doesn't initially see all your maildirs -- perhaps because you're using a folder filter in offlineimap, and so there are untrashed copies in the maildirs it hasn't seen yet. But reference counting of everything you can see is probably still better than what we have now, if it's feasible. And what should --revsync do when it finds a mail file that is marked as expired. Actually revsync is all I use so far, so that's what I'm talking about above. If notmuch gave me at least all filenames that are associated with a mail id, I could introduce a command line option --prune --safe which would Sebastian Looks like you got cut off there. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] loss of duplicate messages
jrollins at finestructure.net (Jameson Rollins) writes: > I'm not exactly sure what the correct behavior is here, but I would > actually like to see my messages sent to the list returned to me. > It's a way of verifying that they did go to the list, as well as > getting a feeling for the round trip time. I personally wouldn't mind > just seeing both copies of the message returned by notmuch, as I can > just delete one of them if I don't want it to turn up again. Would > this behavior be problematic in any way? Do folks have suggestions of > other behaviors that might get around this problem? I'm not sure what the current plan is, but please consider this a belated agreement. It doesn't necessarily need to be the default (and perhaps shouldn't be), but I'd like to have some way to ask notmuch for *all* matching messages (regardless of message id) -- perhaps via an --include-duplicates argument to search/show/count, etc. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: [notmuch] loss of duplicate messages
jrollins at finestructure.net (Jameson Rollins) writes: I'm not exactly sure what the correct behavior is here, but I would actually like to see my messages sent to the list returned to me. It's a way of verifying that they did go to the list, as well as getting a feeling for the round trip time. I personally wouldn't mind just seeing both copies of the message returned by notmuch, as I can just delete one of them if I don't want it to turn up again. Would this behavior be problematic in any way? Do folks have suggestions of other behaviors that might get around this problem? I'm not sure what the current plan is, but please consider this a belated agreement. It doesn't necessarily need to be the default (and perhaps shouldn't be), but I'd like to have some way to ask notmuch for *all* matching messages (regardless of message id) -- perhaps via an --include-duplicates argument to search/show/count, etc. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Move notmuch-fcc-header-setup to message-header-setup-hook.
Call notmuch-fcc-header-setup from message-header-setup-hook rather than message-send-hook. This allows you to see what's going to happen, and to make manual adjustments if desired. Gnus does something similar. Signed-off-by: Rob Browning --- emacs/notmuch-maildir-fcc.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) -- next part -- A non-text attachment was scrubbed... Name: 0001-Move-notmuch-fcc-header-setup-to-message-header-setu.patch Type: text/x-patch Size: 590 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100912/1951228c/attachment.bin>
[PATCH] Move notmuch-fcc-header-setup to message-header-setup-hook.
Here's a small patch to move notmuch-fcc-header-setup from message-send-hook to message-header-setup-hook. This is nice because it allows you to see what's going to happen and make adjustments if you like. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Strings vs symbols in notmuch-search-result-format
I've started to look at the elisp, and wondered why
notmuch-search-result-format expected strings rather than symbols for
the field names, i.e.:
(("date" . "%s ")
("count" . "%-7s ")
("authors" . "%-20s ")
("subject" . "%s ")
("tags" . "(%s)"))
instead of
((date . "%s ")
(count . "%-7s ")
(authors . "%-20s ")
(subject . "%s ")
(tags . "(%s)"))
Perhaps there's a good argument for strings, but if not, the latter is
more idiomatic, and a bit more efficient too (comparisons will just be
pointer compares (via assq) rather than something like a strcmp (assoc)).
In any case, I imagine this might not be something you'd want to change
at this point -- I'm just trying to make sure I understand the current
code.
Thanks
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Mail summary comparison with Gnus
Does notmuch-search-result-format allow multiple-line formats? i.e.: [5/5] [notmuch] an other ready-to-use store option for notmuch : CouchDB Paul R., Jed Brown, martin f. krafft, James Westby (f//notmuch unread) [2/2] [notmuch] [PATCH] Do not segfault on empty mime parts martin f. krafft, Carl Worth (f//notmuch unread) I didn't seem to work but I thought I'd check in case I wasn't configuring it correctly. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Mail summary comparison with Gnus
Now that I'm able to start using notmuch with my actual mail, I thought I might provide some impressions from the perspective of a Gnus user. Here's what a recent bit of the notmuch list looks like in my notmuch buffer: May 03 [7/7] (null) [PATCH] Customize saved search ord May 04 [2/2] (null) [PATCH] emacs: Pretty print the nu May 04 [4/4] (null) [PATCH] emacs: More functionality May 07 [4/4] (null) Use of "notmuch count" in notmuch- May 08 [1/1] (null) Fix missing References from broken May 10 [1/1] (null) rfc: improved MIME handling (multi and here's what it looks like in my Gnus summary buffer with threads expanded, which is my default: [ 39: Keith Packard ] [PATCH] Customize saved search order separ [ 19: David Edmondson] [ 65: Carl Worth ] [ 13: Michal Sojka ] [ 92: Michal Sojka ] [PATCH RFC] notmuch-hello: What's [ 45: David Edmondson] [PATCH] Customize saved search order [ 25: David Edmondson] [ 100: David Edmondson] [PATCH] emacs: Pretty print the numbers of [ 17: Carl Worth ] [ 34: David Edmondson] [PATCH] emacs: More functionality for `not [ 18: David Edmondson] [ 37: David Edmondson] [ 22: Carl Worth ] [ 35: Jason White] Use of "notmuch count" in notmuch-hello.el [ 24: Jameson Rollins] [ 7: Jason White] [ 34: Carl Worth ] [ 23: Arvid Picciani ] Fix missing References from broken muas. [ 33: David Edmondson] rfc: improved MIME handling (multipart) [ 50: Michal Sojka ] [PATCH v2 0/5] Git-based modularization of [ 874: Michal Sojka ] [PATCH v2 2/5] Update test framework for [ 444: Michal Sojka ] [PATCH v2 5/5] test: Set all times to UT [1655: Michal Sojka ] [PATCH v2 1/5] Copy test framework from [ 109: Michal Sojka ] [PATCH v2 3/5] test: Update helper funct [2235: Michal Sojka ] [PATCH v2 4/5] Convert the actual tests (Any articles I've replied to would have an 'A' in the far left column, flagged messages would have an exclamation point, and would have red text by default, etc.) The notmuch output probably doesn't have authors because I pulled this mail in via the mail archives (using Gnus 'G f'). I assume that Gnus must be able to parse the obfuscated "keithp at keithp.com (Keith Packard)" style addresses in the archive. I might see if I can add that to notmuch. The notmuch output is definitely more compact, but for me, it favors information that I don't normally care as much about. I'd rather see more subject and author information, and less date. Though perhaps that's just me, and I can always customize it. Also, while I'm not saying that the Gnus approach is ideal, it does make it easy to get a rough impression at a glance about who's talking, to whom, and about what, and you can instantaneously collapse/expand threads (or toggle threading altogether). That might eventually be a nice feature for notmuch. Note too, that Gnus tracks subject changes (at least in this case) within the thread. Whether that's what you really want or not is another question. (Gnus has a lot of information about how it threads and how threading can be adjusted in its info pages (c.f. info gnus "3.9 Threading...")). Hope this is useful -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Mail summary comparison with Gnus
Now that I'm able to start using notmuch with my actual mail, I thought I might provide some impressions from the perspective of a Gnus user. Here's what a recent bit of the notmuch list looks like in my notmuch buffer: May 03 [7/7] (null) [PATCH] Customize saved search ord May 04 [2/2] (null) [PATCH] emacs: Pretty print the nu May 04 [4/4] (null) [PATCH] emacs: More functionality May 07 [4/4] (null) Use of notmuch count in notmuch- May 08 [1/1] (null) Fix missing References from broken May 10 [1/1] (null) rfc: improved MIME handling (multi and here's what it looks like in my Gnus summary buffer with threads expanded, which is my default: [ 39: Keith Packard ] [PATCH] Customize saved search order separ [ 19: David Edmondson] [ 65: Carl Worth ] [ 13: Michal Sojka ] [ 92: Michal Sojka ] [PATCH RFC] notmuch-hello: What's [ 45: David Edmondson] [PATCH] Customize saved search order [ 25: David Edmondson] [ 100: David Edmondson] [PATCH] emacs: Pretty print the numbers of [ 17: Carl Worth ] [ 34: David Edmondson] [PATCH] emacs: More functionality for `not [ 18: David Edmondson] [ 37: David Edmondson] [ 22: Carl Worth ] [ 35: Jason White] Use of notmuch count in notmuch-hello.el [ 24: Jameson Rollins] [ 7: Jason White] [ 34: Carl Worth ] [ 23: Arvid Picciani ] Fix missing References from broken muas. [ 33: David Edmondson] rfc: improved MIME handling (multipart) [ 50: Michal Sojka ] [PATCH v2 0/5] Git-based modularization of [ 874: Michal Sojka ] [PATCH v2 2/5] Update test framework for [ 444: Michal Sojka ] [PATCH v2 5/5] test: Set all times to UT [1655: Michal Sojka ] [PATCH v2 1/5] Copy test framework from [ 109: Michal Sojka ] [PATCH v2 3/5] test: Update helper funct [2235: Michal Sojka ] [PATCH v2 4/5] Convert the actual tests (Any articles I've replied to would have an 'A' in the far left column, flagged messages would have an exclamation point, and would have red text by default, etc.) The notmuch output probably doesn't have authors because I pulled this mail in via the mail archives (using Gnus 'G f'). I assume that Gnus must be able to parse the obfuscated keithp at keithp.com (Keith Packard) style addresses in the archive. I might see if I can add that to notmuch. The notmuch output is definitely more compact, but for me, it favors information that I don't normally care as much about. I'd rather see more subject and author information, and less date. Though perhaps that's just me, and I can always customize it. Also, while I'm not saying that the Gnus approach is ideal, it does make it easy to get a rough impression at a glance about who's talking, to whom, and about what, and you can instantaneously collapse/expand threads (or toggle threading altogether). That might eventually be a nice feature for notmuch. Note too, that Gnus tracks subject changes (at least in this case) within the thread. Whether that's what you really want or not is another question. (Gnus has a lot of information about how it threads and how threading can be adjusted in its info pages (c.f. info gnus 3.9 Threading...)). Hope this is useful -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Mail summary comparison with Gnus
Does notmuch-search-result-format allow multiple-line formats? i.e.: [5/5] [notmuch] an other ready-to-use store option for notmuch : CouchDB Paul R., Jed Brown, martin f. krafft, James Westby (f//notmuch unread) [2/2] [notmuch] [PATCH] Do not segfault on empty mime parts martin f. krafft, Carl Worth (f//notmuch unread) I didn't seem to work but I thought I'd check in case I wasn't configuring it correctly. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Xapian exceptions "Key too long" during notmuch new
Michal Sojka writes: > please try the version from git. I do not have the problem you report > with this message. It seems that it was fixed after 0.3.1 release in > > commit 7b78eb4af6e87532795d09bd82152002ab4a74b1 Indeed. About 10 hours and 1.3M messages later, everything seems fine. Thanks for the help. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Re: Xapian exceptions Key too long during notmuch new
Michal Sojka sojk...@fel.cvut.cz writes: please try the version from git. I do not have the problem you report with this message. It seems that it was fixed after 0.3.1 release in commit 7b78eb4af6e87532795d09bd82152002ab4a74b1 Indeed. About 10 hours and 1.3M messages later, everything seems fine. Thanks for the help. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Xapian exceptions "Key too long" during notmuch new
Jameson Rollins writes: > Hey, Rob. I've never seen this error before. I wonder if these > messages have some really long header names? If it's not too onerous, > can you find the messages where this occurred? There's a verbose > option, that might be useful. > > jamie. OK, it looks like this is the first message that caused the exception: -- next part -- An embedded and charset-unspecified text was scrubbed... Name: bad-mail.txt URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100906/4bc7abd4/attachment.txt> -- next part -- -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Xapian exceptions "Key too long" during notmuch new
Jameson Rollins writes: > Hey, Rob. I've never seen this error before. I wonder if these > messages have some really long header names? If it's not too onerous, > can you find the messages where this occurred? There's a verbose > option, that might be useful. OK, if I remember, I'll recreate the index tonight. BTW, it doesn't look like --verbose is mentioned in the manpage. Also, I think it may have been mentioned before, but it'd be nice if I could tell new to write the index somewhere else so that I can keep using notmuch while it's busy, i.e. notmuch new --verbose -o ~/new-notmuch-index or similar. Thanks for the help -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Xapian exceptions "Key too long" during notmuch new
After quite a bit of time (issues with offlineimap and large maildirs), I finally got the point where I could run notmuch new, and although it did finish, there were two errrors that I wanted to ask about. Are these important? $ notmuch new [...] A Xapian exception occurred adding message: Key too long: length was 370 bytes, maximum length of a key is 252 bytes. Error: A Xapian exception occurred. Halting processing. [...] A Xapian exception occurred adding message: Key too long: length was 269 bytes, maximum length of a key is 252 bytes. Error: A Xapian exception occurred. Halting processing. Processed 1373303 total files in 10h 47m 31s (35 files/sec.). Added 1292042 new messages to the database. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
Xapian exceptions Key too long during notmuch new
After quite a bit of time (issues with offlineimap and large maildirs), I finally got the point where I could run notmuch new, and although it did finish, there were two errrors that I wanted to ask about. Are these important? $ notmuch new [...] A Xapian exception occurred adding message: Key too long: length was 370 bytes, maximum length of a key is 252 bytes. Error: A Xapian exception occurred. Halting processing. [...] A Xapian exception occurred adding message: Key too long: length was 269 bytes, maximum length of a key is 252 bytes. Error: A Xapian exception occurred. Halting processing. Processed 1373303 total files in 10h 47m 31s (35 files/sec.). Added 1292042 new messages to the database. Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Xapian exceptions Key too long during notmuch new
Jameson Rollins jroll...@finestructure.net writes: Hey, Rob. I've never seen this error before. I wonder if these messages have some really long header names? If it's not too onerous, can you find the messages where this occurred? There's a verbose option, that might be useful. OK, if I remember, I'll recreate the index tonight. BTW, it doesn't look like --verbose is mentioned in the manpage. Also, I think it may have been mentioned before, but it'd be nice if I could tell new to write the index somewhere else so that I can keep using notmuch while it's busy, i.e. notmuch new --verbose -o ~/new-notmuch-index or similar. Thanks for the help -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Xapian exceptions Key too long during notmuch new
rsync_module(int f_in, int f_
exit_cleanup(RERR_UNSUPPORTED);
}
- if (lp_timeout(i))
+ if (lp_timeout(i)) {
io_timeout = lp_timeout(i);
+ if (io_timeout io_timeout select_timeout)
+ select_timeout = io_timeout;
+ }
start_server(f_in, f_out, argc, argp);
--jI8keyz6grp/JLjh
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
--jI8keyz6grp/JLjh--
--
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
