-- next part --
A non-text attachment was scrubbed...
Name: agalinis_aur.jpg
Type: image/jpeg
Size: 99667 bytes
Desc: agalinis auriculata
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110915/229a34e8/attachment-0001.jpg>
-- next part --
This seems like a symptom of a much bigger problem. Shouldn't the
bindings be checking or coercing the type of *every* argument that
gets passed from the caller through to a ctypes-wrapped libnotmuch
function? Otherwise, a simple type error in a caller, like passing a
number instead of a string t
On Tue, Sep 13, 2011 at 11:55 PM, Martin Owens wrote:
> Hello Again,
>
> I notice in the lib code notmuch_database_open(),
> notmuch_database_create() these functions use const char *path for the
> directory path input. Is this unicode safe?
>
> The python bindings (and ctype docs) seem to suggest
nicode.patch
Type: text/x-patch
Size: 6195 bytes
Desc: not available
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110915/cd193020/attachment-0001.bin>
It looks like the python variables do include null, my investigations
show that the problem also effects tag names.
The symptoms can be seen when trying to use the python interface and
using unicode tag names or paths. Instead of seeing 'mytag1' we see 'm'
and instead of '/my/path/to/mail' we see
This seems like a symptom of a much bigger problem. Shouldn't the
bindings be checking or coercing the type of *every* argument that
gets passed from the caller through to a ctypes-wrapped libnotmuch
function? Otherwise, a simple type error in a caller, like passing a
number instead of a string t
On Tue, Sep 13, 2011 at 11:55 PM, Martin Owens wrote:
> Hello Again,
>
> I notice in the lib code notmuch_database_open(),
> notmuch_database_create() these functions use const char *path for the
> directory path input. Is this unicode safe?
>
> The python bindings (and ctype docs) seem to suggest
Hello Sebastian,
I've attached a diff for some proposed changes to help make dealing with
unicode and strings in the bindings more regular. I noticed some of the
methods were protected and others were not.
Let me know.
Best Regards, Martin Owens
On Thu, 2011-09-08 at 15:45 +0200, Sebastian Spae
It looks like the python variables do include null, my investigations
show that the problem also effects tag names.
The symptoms can be seen when trying to use the python interface and
using unicode tag names or paths. Instead of seeing 'mytag1' we see 'm'
and instead of '/my/path/to/mail' we see
notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory "new/" to maildir directory "cur/", which makes messages lose
their "new" status in the MUA. However some users want to keep this "new"
status after, for instance, an auto-tagging of new messages.
However
From: Michal Sojka
Some MUA's like mutt show the difference between "new" emails living in maildir
directory new/, and "old" emails living in maildir directory cur/. However
notmuch tag unconditionally moves selected messages from new/ to cur/, even if
no maildir synchronized tag is changed.
Whi
The for loop right after already does the job.
Signed-off-by: Louis Rilling
---
lib/message.cc |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index cf651e5..b1b2942 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -1172,8 +1172,6 @@ _
Signed-off-by: Louis Rilling
---
lib/message.cc | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/lib/message.cc b/lib/message.cc
index d993cde..cf651e5 100644
--- a/lib/message.cc
+++ b/lib/message.cc
@@ -49,16 +49,16 @@ struct visible _notmuch_message {
struct
Hello,
Here is the updated series of fixes I have around maildir flags
synchronization. The first two patches are just cleanups that can be applied
independently.
The intent for the fourth patch (detailed in the commit log) is to allow mutt
users to keep using the "new" status, as long as notmuch
14 matches
Mail list logo
