Ethan Glasser-Camp writes:
> I've modified the script so that it would run by mangling filenames,
> which is irreversible (the original tried to encode/decode filenames
> reversibly). Then I got a little carried away, adding --verbose and
> --dry-run options as well as removing a cou
Ethan Glasser-Camp ethan.glasser.c...@gmail.com writes:
I've modified the script so that it would run by mangling filenames,
which is irreversible (the original tried to encode/decode filenames
reversibly). Then I got a little carried away, adding --verbose and
--dry-run options as well
David Bremner writes:
> It's still a prototype, and there is not much error checking, and there
> are certain issues not dealt with at all (the ones I thought about are
> commented).
Hi everyone,
I'm very interested in running notmuch on all my laptops and having my
mail and its tags be
David Bremner da...@tethera.net writes:
It's still a prototype, and there is not much error checking, and there
are certain issues not dealt with at all (the ones I thought about are
commented).
Hi everyone,
I'm very interested in running notmuch on all my laptops and having my
mail and its
e difference between regular buttons and header buttons?
>
I guess you're right, that's the only place and it isn't worth worrying
about.
Ethan
-- next part --
An HTML attachment was scrubbed...
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20121119/d1cfa7
On Sun, Nov 18, 2012 at 7:10 PM, Aaron Ecay wrote:
> 2012ko azaroak 18an, Ethan Glasser-Camp-ek idatzi zuen:
> >
> > - You might want to use #' on lambdas.
>
> This is actually unnecessary ? as the info node "(elisp) Anonymous
> Functions" says, the forms
As for the rest, I'm not a zsh expert, but I looked at zmuch and
notmuch-colorize and they looked fine.
If Bremner is willing to put this package in contrib, I think he should
do so.
Ethan
tagger-make-body-link reads that it will work
"everywhere except in the header-line". Does this mean mode-line, menu
bar, or what? How about just "won't work in the header-line"?
- In patch 3:
+If tags the result of this function is to be used within the
I think this should just read "If the result".
Ethan
Ethan Glasser-Camp writes:
> - Patch 4 still has a subject line that ends in a period. I don't think
> this is mandatory for everyone but some people consider it best
> practice.
Best practice, of course, would be to remove the period at the end of
the subject line. Patch 12 als
david at tethera.net writes:
> which was revied by Tomi and Ethan. I think I implemented their
> suggestions.
Actually, I don't think you implemented all of mine.
- Patch 4 still has a subject line that ends in a period. I don't think
this is mandatory for everyone but some people co
h you might need to apply it with notmuch
show --format="mbox" :).
Ethan
Ethan Glasser-Camp writes:
> Writing this buffer using C-x C-w encodes it correctly too. So I think
> this is an emacs MIME problem. We call mm-save-part, which calls
> mm-save-part-to-file, which calls mm-with-unibyte-buffer. Hmm..
>
> Indeed, it seems that inserting this charac
uld limit it just to saving attachments (putting the let
around the with-current-notmuch-show-message). That feels like it could
be right, because intuitively saving an attachment should be done
without any conversions. Or even the above doesn't seem so bad. My vague
feeling is that messages should always be ASCII, or at least mm-* will
interpret it that way, so decoding them into any other character set
might cause problems. Anyone understand character sets?
Ethan
Ethan Glasser-Camp ethan.glasser.c...@gmail.com writes:
Writing this buffer using C-x C-w encodes it correctly too. So I think
this is an emacs MIME problem. We call mm-save-part, which calls
mm-save-part-to-file, which calls mm-with-unibyte-buffer. Hmm..
Indeed, it seems that inserting
da...@tethera.net writes:
which was revied by Tomi and Ethan. I think I implemented their
suggestions.
Actually, I don't think you implemented all of mine.
- Patch 4 still has a subject line that ends in a period. I don't think
this is mandatory for everyone but some people consider it best
Ethan Glasser-Camp ethan.glasser.c...@gmail.com writes:
- Patch 4 still has a subject line that ends in a period. I don't think
this is mandatory for everyone but some people consider it best
practice.
Best practice, of course, would be to remove the period at the end of
the subject line
except in the header-line. Does this mean mode-line, menu
bar, or what? How about just won't work in the header-line?
- In patch 3:
+If tags the result of this function is to be used within the
I think this should just read If the result.
Ethan
, I'm not a zsh expert, but I looked at zmuch and
notmuch-colorize and they looked fine.
If Bremner is willing to put this package in contrib, I think he should
do so.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman
On Sun, Nov 18, 2012 at 7:10 PM, Aaron Ecay aarone...@gmail.com wrote:
2012ko azaroak 18an, Ethan Glasser-Camp-ek idatzi zuen:
- You might want to use #' on lambdas.
This is actually unnecessary – as the info node (elisp) Anonymous
Functions says, the forms with and without
ot; are to make sure
> we start in a known state, and we leave the database in a known state
> for the next test.
OK, these LGTM.
Ethan
in a known state, and we leave the database in a known state
for the next test.
OK, these LGTM.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
vague
feeling is that messages should always be ASCII, or at least mm-* will
interpret it that way, so decoding them into any other character set
might cause problems. Anyone understand character sets?
Ethan
___
notmuch mailing list
notmuch
> +
> test_expect_success 'Restore with nothing to do, II' \
> - 'notmuch restore --accumulate --input=dump.expected &&
> + 'notmuch restore --input=dump.expected &&
> + notmuch restore --accumulate --input=dump.expected &&
>notmuch dump > dump.actual &&
>test_cmp dump.expected dump.actual'
Maybe change the name? "Accumulate with nothing to do", for instance?
Ethan
notmuch dump dump.actual
test_cmp dump.expected dump.actual'
Maybe change the name? Accumulate with nothing to do, for instance?
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
shr if it's
> available, html2text otherwise (which is built in), and do only a
> simple sanity check of the result.
This fixes the failing test on my machine.
Ethan
Austin Clements writes:
> This is v2 of id:"1351650561-7331-1-git-send-email-amdragon at mit.edu".
> This makes Jani's suggested additions to the regexp and adds support
> for RFC 2392 mid: links, as suggested by Sascha.
This series looks fine to me.
Ethan
t;)
... but it seems like "thread:..." is good enough for you.
> + (error \"We must be in notmch-show at this point but we are in %s.\"
> major-mode))
> +(push-button) ;; simulate a press on the RET key
> +(if (eq major-mode 'notmuch-search-mode)
> +t
> + (format \"We must be in notmch-search at this point but we are in
> %s.\" major-mode))"
s/notmch/notmuch/ here.
Otherwise I think the code looks fine. I think the design concerns
raised by Mark Walters are probably valid, though.
Ethan
-LIB)))
> `
>
> What do you think?
Why not just append it to the *end* of load-path? Then it won't shadow
anything.
Ethan
append it to the *end* of load-path? Then it won't shadow
anything.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
/notmch/notmuch/ here.
Otherwise I think the code looks fine. I think the design concerns
raised by Mark Walters are probably valid, though.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Austin Clements amdra...@mit.edu writes:
This is v2 of id:1351650561-7331-1-git-send-email-amdra...@mit.edu.
This makes Jani's suggested additions to the regexp and adds support
for RFC 2392 mid: links, as suggested by Sascha.
This series looks fine to me.
Ethan
if it's
available, html2text otherwise (which is built in), and do only a
simple sanity check of the result.
This fixes the failing test on my machine.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo
he bike shed and
into somebody else's kitchen.
Ethan
he code, perhaps by submitting an
issue or pull request on the github page for the project. I'm sure he'd
prefer a patch to the Vala source.
Ethan
d needs-review, added notmuch::trivial.
Ethan
, added notmuch::trivial.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
by submitting an
issue or pull request on the github page for the project. I'm sure he'd
prefer a patch to the Vala source.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
shed and
into somebody else's kitchen.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
ge-visibility.
I guess I jumped into this series halfway, but why are we doing this
with the wipe/redraw technique instead of just using invisible overlays,
like we do more generally with notmuch-show? I think I agree that
toggling individual parts is a good UI approach, and this isn't a bad
way to implement it, but I wonder if we could do it better/easier if we
used emacs's builtin functionality.
Thanks!
Ethan
gt; + (case notmuch-pick-process-state
This looks awfully familiar. Not looking too close, but why can't this
re-use the JSON parser from your other patch? Just not to rely on the
other patch series?
Still, let's get this pushed.
Ethan
Tomi Ollila writes:
> These 3 patches LGTM.
Me too. But I wouldn't be averse to some tests :)
Ethan
Tomi Ollila writes:
> LGTM (NEWS too)
Yep! Removing needs-review.
Ethan
Tomi Ollila tomi.oll...@iki.fi writes:
These 3 patches LGTM.
Me too. But I wouldn't be averse to some tests :)
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
close, but why can't this
re-use the JSON parser from your other patch? Just not to rely on the
other patch series?
Still, let's get this pushed.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
of just using invisible overlays,
like we do more generally with notmuch-show? I think I agree that
toggling individual parts is a good UI approach, and this isn't a bad
way to implement it, but I wonder if we could do it better/easier if we
used emacs's builtin functionality.
Thanks!
Ethan
Tomi Ollila tomi.oll...@iki.fi writes:
LGTM (NEWS too)
Yep! Removing needs-review.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Austin Clements writes:
> OpenBSD's build flags are identical to FreeBSD, except that libraries
> need to be explicitly linked against libc. No code changes are
> necessary.
>
> From: Cody Cutler
> ---
OK, looks fine.
Ethan
Austin Clements writes:
> Quoth Ethan Glasser-Camp on Oct 24 at 9:59 pm:
>> Austin Clements writes:
>
> Emacs seems to have as many ways to convert HTML to text as there are
> people trying to run this test. What's the value of
> mm-text-html-renderer for you in Emacs 24?
Austin Clements amdra...@mit.edu writes:
Quoth Ethan Glasser-Camp on Oct 24 at 9:59 pm:
Austin Clements amdra...@mit.edu writes:
Emacs seems to have as many ways to convert HTML to text as there are
people trying to run this test. What's the value of
mm-text-html-renderer for you in Emacs
Austin Clements amdra...@mit.edu writes:
OpenBSD's build flags are identical to FreeBSD, except that libraries
need to be explicitly linked against libc. No code changes are
necessary.
From: Cody Cutler ccut...@csail.mit.edu
---
OK, looks fine.
Ethan
?
Still, I'm excited that you're working on this so please let's get it
fixed!
Ethan
get it
fixed!
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
rse part of a JSON list object by setting this
variable to their JSON parser and calling
notmuch-json-parse-partial-list (which see)."
(Or whatever one is supposed to do with the parser object...)
Ethan
and calling
notmuch-json-parse-partial-list (which see).
(Or whatever one is supposed to do with the parser object...)
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
>
This seems like a really good idea generally. I think we should merge this
anyhow.
Ethan
-- next part --
An HTML attachment was scrubbed...
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20121021/90b9560e/attachment.html>
are the same.
Fix the failures by sorting the output of notmuch --debug and
comparing this to a hand-sorted version of its output.
Signed-off-by: Ethan Glasser-Camp
---
test/new | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/test/new b/test/new
index cc2af72..587aa11
rt.
If Tomi is OK with it, then I guess it's fine. And it's true that there
are a couple of places where braces are used with long conditions and
then-parts.
This series has my +1.
Ethan
Peter Wang writes:
> Update tests to expect content-length and content-transfer-encoding
> fields in show --format=json output, for leaf parts with omitted body
> content.
OK, this whole series looks good to me.
Ethan
Peter Wang noval...@gmail.com writes:
Update tests to expect content-length and content-transfer-encoding
fields in show --format=json output, for leaf parts with omitted body
content.
OK, this whole series looks good to me.
Ethan
___
notmuch
it's fine. And it's true that there
are a couple of places where braces are used with long conditions and
then-parts.
This series has my +1.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
are the same.
Fix the failures by sorting the output of notmuch --debug and
comparing this to a hand-sorted version of its output.
Signed-off-by: Ethan Glasser-Camp et...@betacantrips.com
---
test/new | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/test/new b/test/new
should merge this
anyhow.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
to handle the error IMO. On the other hand, it's
such a weird corner case that I don't even think it merits a FIXME
comment.
How about an assert instead of a return NULL?
Ethan
ss attempts to connect() to it. The --background option in
> smtp-dummy makes it to go background *after* it started to listen
> its server socket.
This looks fine to me, Michal Sojka's reviewed this version, and this
patch has been bouncing around for almost a year! I'm taking off
needs-review.
Ethan
ff needs-review.
Ethan
the function notmuch_database_commit, and have
it call the WritableDatabase::commit() method.
reopen() is a very very old method, seems like it has been around since
2004.
So I think Adrien is safe from having to do version checks, but we
should probably use commit() instead of flush().
Ethan
dom () % message_id_len + 1;
This looks odd. I'm pretty sure it's correct, but my brain keeps saying,
"Why are there no parentheses on (message_id_len + 1)?" Maybe just a
comment that message ids must be at least one character long, or the
ranges of values necessary for both of these variables.
Ethan
notmuch_database_commit, and have
it call the WritableDatabase::commit() method.
reopen() is a very very old method, seems like it has been around since
2004.
So I think Adrien is safe from having to do version checks, but we
should probably use commit() instead of flush().
Ethan
taking off needs-review.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
to connect() to it. The --background option in
smtp-dummy makes it to go background *after* it started to listen
its server socket.
This looks fine to me, Michal Sojka's reviewed this version, and this
patch has been bouncing around for almost a year! I'm taking off
needs-review.
Ethan
e, perhaps because my patch that moved some tests
to emacs-show was just pushed too.
Ethan
: [{\"id\": 1,
> \"content-type\": \"multipart/mixed\", \"content\": [{\"id\": 2,
> \"content-type\": \"text/plain\", \"content\": \"This is a test message with
> inline attachment with a filename\"}, {\"id\": 3, \"content-type\":
> \"application/octet-stream\", \"content-length\": 12392,
> \"content-transfer-encoding\": \"base64\", \"filename\": \"README\"}]}]},
> ["
This test fails for me. You're encoding the content-length of
test/README. test/README certainly hasn't changed in the last six months
so that seems like a reasonable thing to do... except then why is it
12392 on your machine, and 12380 on mine? I don't object to using
test/README as a simple file to test with, but then you certainly
shouldn't hard-code its length. You could pipe test/README through
base64 and then through wc -c to get an accurate length, but for my
machine a newline gets appended by base64 I think, and it gives me
12381.
I'm tagging this patch moreinfo but you would have my +1 if you fix
this.
Ethan
reviewed and then
obsoleted by the series in
id:"1344428872-12374-1-git-send-email-novalazy at gmail.com". I'm therefore
marking it notmuch::obsolete, and will review the other patch set.
Ethan
r-state becomes notmuch-json-state.
We also rearrange the json-error case but are careful to always call
error-function in the results buffer.
Ethan
(bbdb-snarf-region comma (point)) ; last entry
> + ))
Doesn't this cause snarf the comma into any of those entries? It seems
like point starts before the first entry but then goes before each
comma. Obviously this wouldn't be here if it didn't work. I thought
bbdb-snarf handled this kind of thing, but it doesn't. Could you explain
this?
Ethan
Ethan Glasser-Camp writes:
> It looks like you have better wording for patch 4/8 so I'd like to see
> you resend it.
>
> I'm marking patches 3, 4, and 7 as moreinfo. Please resubmit!
It turns out that patch 4 already has a v2 in the thread, but I didn't
see it due to some kind
this function
instead of in the display function. This opens you up to weird
situations if one of the multipart/alternatives should disappear from a
message or if some other function should change the alternative on
display for a given message, but both of these seem unlikely to me..
Ethan
Users who relied on notmuch-show-all-multipart/alternative-parts
might need to know that it is now buffer-local.
Signed-off-by: Ethan Glasser-Camp
---
Hi! I'm trying to figure out the status of this patch series, which
seems to have fallen through the cracks. It looks like Jani's solution
exists
, exclude_query);
> - else {
> + } else {
"House style" is to not put braces around one-line then-clauses. This is
the only place where you did that.
I'm marking patches 3, 4, and 7 as moreinfo. Please resubmit!
Ethan
d s/wraper/wrapper/.
Ethan
queue now and
it seems like this branch is just completely gone. I get 502 Bad Gateway
errors when I follow the first link. Did it move or is there a problem
with your site?
Ethan
Adrien Bustany writes:
> The code of the patches in unchanged, but the formatting issues are now
> hopefully fixed.
These look fine to me, and they're pretty trivial.
Ethan
Users who relied on notmuch-show-all-multipart/alternative-parts
might need to know that it is now buffer-local.
Signed-off-by: Ethan Glasser-Camp et...@betacantrips.com
---
Hi! I'm trying to figure out the status of this patch series, which
seems to have fallen through the cracks. It looks like
to this function
instead of in the display function. This opens you up to weird
situations if one of the multipart/alternatives should disappear from a
message or if some other function should change the alternative on
display for a given message, but both of these seem unlikely to me..
Ethan
Ethan Glasser-Camp ethan.glasser.c...@gmail.com writes:
It looks like you have better wording for patch 4/8 so I'd like to see
you resend it.
I'm marking patches 3, 4, and 7 as moreinfo. Please resubmit!
It turns out that patch 4 already has a v2 in the thread, but I didn't
see it due
starts before the first entry but then goes before each
comma. Obviously this wouldn't be here if it didn't work. I thought
bbdb-snarf handled this kind of thing, but it doesn't. Could you explain
this?
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
-parser-state becomes notmuch-json-state.
We also rearrange the json-error case but are careful to always call
error-function in the results buffer.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
was thoroughly reviewed and then
obsoleted by the series in
id:1344428872-12374-1-git-send-email-noval...@gmail.com. I'm therefore
marking it notmuch::obsolete, and will review the other patch set.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http
appended by base64 I think, and it gives me
12381.
I'm tagging this patch moreinfo but you would have my +1 if you fix
this.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
to emacs-show was just pushed too.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
that message ids must be at least one character long, or the
ranges of values necessary for both of these variables.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
On Thu, Oct 18, 2012 at 5:50 AM, Tomi Ollila wrote:
> On Thu, Oct 18 2012, Ethan Glasser-Camp wrote:
>
> > Ethan Glasser-Camp writes:
> >
> >> This patch, and its predecessors, all look great to me.
> >
> > But a note: many of the first lines in your
On Thu, Oct 18, 2012 at 5:50 AM, Tomi Ollila tomi.oll...@iki.fi wrote:
On Thu, Oct 18 2012, Ethan Glasser-Camp wrote:
Ethan Glasser-Camp ethan.glasser.c...@gmail.com writes:
This patch, and its predecessors, all look great to me.
But a note: many of the first lines in your commit
Adrien Bustany adr...@bustany.org writes:
The code of the patches in unchanged, but the formatting issues are now
hopefully fixed.
These look fine to me, and they're pretty trivial.
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http
502 Bad Gateway
errors when I follow the first link. Did it move or is there a problem
with your site?
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
then-clauses. This is
the only place where you did that.
I'm marking patches 3, 4, and 7 as moreinfo. Please resubmit!
Ethan
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
ually read: "test: emacs:
toggle processing of cryptographic MIME parts in `notmuch-show'".
See commit 19ec74c5.
- 5ea1dbe "test: emacs: toggle eliding of non-matching messages in
`notmuch-show'"
- 345faab "test: emacs: toggle thread content indentation in
`n
Ethan Glasser-Camp writes:
> This patch, and its predecessors, all look great to me.
But a note: many of the first lines in your commit messages ("{show,
hide} message headers") contain tabs. I hate tabs. Is this intentional?
I have noticed it on other patches you've sen
From: Pieter Praet <pie...@praet.org>
See commits 44a544ed, 866ce8b1, 668b66ec.
Signed-off-by: Ethan Glasser-Camp
---
I am embarrassed to admit I didn't try to apply these patches before I
removed the needs-review tag. This one didn't apply. Here's the
trivial fix. The tests are still
se calls flush() using exactly the same 86-character
line. I'd say "don't make it worse", but personally I think breaking
this line might be worse.
Ethan
1 - 100 of 239 matches
Mail list logo
