On Tue, 15 Nov 2011, Thomas Schwinge wrote:
> Hi!
>
> On Thu, 10 Mar 2011 18:02:09 -0800, Carl Worth wrote:
>> On Thu, 3 Feb 2011 00:56:39 +0100, Thomas Schwinge > schwinge.name> wrote:
>> > This issue has been lying in ambush as of 2009-11-24's commit
>> > 93af7b574598637c2766dd1f8ef343962c9a8e
Hi!
On Thu, 10 Mar 2011 18:02:09 -0800, Carl Worth wrote:
> On Thu, 3 Feb 2011 00:56:39 +0100, Thomas Schwinge
> wrote:
> > This issue has been lying in ambush as of 2009-11-24's commit
> > 93af7b574598637c2766dd1f8ef343962c9a8efb.
>
> Thanks very much for tracking down this bug, Thomas. What
Hi!
On Thu, 10 Mar 2011 18:02:09 -0800, Carl Worth wrote:
> On Thu, 3 Feb 2011 00:56:39 +0100, Thomas Schwinge
> wrote:
> > This issue has been lying in ambush as of 2009-11-24's commit
> > 93af7b574598637c2766dd1f8ef343962c9a8efb.
>
> Thanks very much for tracking down this bug, Thomas. What
On Thu, 3 Feb 2011 12:06:20 -0500, Austin Clements wrote:
> Nice catch.
>
> Is there a reason you keep the remaining data in a string instead of
> taking the more idiomatic elisp approach of leaving it in the process
> buffer?
Thomas is excused since he was just modifying my code originally.
An
On Thu, 3 Feb 2011 12:06:20 -0500, Austin Clements wrote:
> Nice catch.
>
> Is there a reason you keep the remaining data in a string instead of
> taking the more idiomatic elisp approach of leaving it in the process
> buffer?
Thomas is excused since he was just modifying my code originally.
An
On Thu, 3 Feb 2011 00:56:39 +0100, Thomas Schwinge
wrote:
> This issue has been lying in ambush as of 2009-11-24's commit
> 93af7b574598637c2766dd1f8ef343962c9a8efb.
Thanks very much for tracking down this bug, Thomas. What a nasty bug to
have in notmuch!
Your fix seems to drop the last thread
On Thu, 3 Feb 2011 00:56:39 +0100, Thomas Schwinge
wrote:
> This issue has been lying in ambush as of 2009-11-24's commit
> 93af7b574598637c2766dd1f8ef343962c9a8efb.
Thanks very much for tracking down this bug, Thomas. What a nasty bug to
have in notmuch!
Your fix seems to drop the last thread
Hallo!
On Thu, 3 Feb 2011 12:06:20 -0500, Austin Clements wrote:
> Is there a reason you keep the remaining data in a string instead of
> taking the more idiomatic elisp approach of leaving it in the process
> buffer? In fact, the code would probably be simpler if you
> immediately appended the
Nice catch.
Is there a reason you keep the remaining data in a string instead of
taking the more idiomatic elisp approach of leaving it in the process
buffer? In fact, the code would probably be simpler if you
immediately appended the string to the process buffer like a normal
process-filter and
Hallo!
On Thu, 3 Feb 2011 12:06:20 -0500, Austin Clements wrote:
> Is there a reason you keep the remaining data in a string instead of
> taking the more idiomatic elisp approach of leaving it in the process
> buffer? In fact, the code would probably be simpler if you
> immediately appended the
Nice catch.
Is there a reason you keep the remaining data in a string instead of
taking the more idiomatic elisp approach of leaving it in the process
buffer? In fact, the code would probably be simpler if you
immediately appended the string to the process buffer like a normal
process-filter and
This issue has been lying in ambush as of 2009-11-24's commit
93af7b574598637c2766dd1f8ef343962c9a8efb.
Signed-off-by: Thomas Schwinge
---
emacs/notmuch.el | 70 +++--
1 files changed, 41 insertions(+), 29 deletions(-)
diff --git a/emacs/notmuch
This issue has been lying in ambush as of 2009-11-24's commit
93af7b574598637c2766dd1f8ef343962c9a8efb.
Signed-off-by: Thomas Schwinge
---
emacs/notmuch.el | 70 +++--
1 files changed, 41 insertions(+), 29 deletions(-)
diff --git a/emacs/notmuch
13 matches
Mail list logo
