Re: [PATCH 0/4] Maildir synchronization v2

2010-12-09 Thread Mike Kelly 
On Wed, Oct 13, 2010 at 10:35:15AM -0400, Mike Kelly wrote:
 On Wed, 13 Oct 2010 10:24:25 -0400
 Mike Kelly pi...@pioto.org wrote:
 
  Looks like this may also require a newer xapian than i have now
  (xapian-core 1.0.18), as notmuch new aborts with:
  
terminate called after throwing an instance of
  'Xapian::InvalidArgumentError'
  
  I'll see if I can track down anything more concrete as a cause.

As a bit of a followup... I wasn't able to reproduce this on a different
FreeBSD 8.0 system, so I think my workstation must be subtly broken,
which is lame. And, if I set synchronize_flags=false in my
~/.notmuch-config, I don't get this error on my workstation, either.

-- 
Mike Kelly
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 0/4] Maildir synchronization v2

2010-10-22 Thread Michal Sojka 
On Mon, 18 Oct 2010, Mike Kelly wrote:
> Michal Sojka  wrote:
> > they are ready to be merged. They can be pulled by:
> > 
> > git pull git://rtime.felk.cvut.cz/notmuch maildir-sync-v2
> 
> I've tested these patches on Linux, and they seem to work as expected.
> However, I'd like to suggest/request that the level-4 syncing of a
> filename should happen in notmuch_(message|thread)_(add|remove)_tag(),
> not in notmuch-tag.cc. Otherwise, anyone using libnotmuch directly
> (e.g. alternative clients, things using python bindings, etc) will not
> benefit from this.

Hi, I'd agree but these pathes don't touch notmuch-tag.c in a
significant way. What's done there is to read the value from config and
to call a function (from libnotmuch) to setup an internal variable
accordingly. Other users of libnotmuch have probably different means of
configuration than notmuch itself and should call this function in a
similar way.

-Michal

[PATCH 0/4] Maildir synchronization v2

2010-10-18 Thread Mike Kelly 
On Wed, 13 Oct 2010 14:13:54 +0200
Michal Sojka  wrote:

> Hi,
> 
> this is an updated version of patches sent in
> id:1273580061-22580-1-git-send-email-sojkam1 at fel.cvut.cz. Only the
> last patch (tests) was actually updated to work with new test suite.
> These patches has already been tested by several people and I think
> they are ready to be merged. They can be pulled by:
> 
> git pull git://rtime.felk.cvut.cz/notmuch maildir-sync-v2

I've tested these patches on Linux, and they seem to work as expected.
However, I'd like to suggest/request that the level-4 syncing of a
filename should happen in notmuch_(message|thread)_(add|remove)_tag(),
not in notmuch-tag.cc. Otherwise, anyone using libnotmuch directly
(e.g. alternative clients, things using python bindings, etc) will not
benefit from this.

-- 
Mike Kelly

Re: [PATCH 0/4] Maildir synchronization v2

2010-10-18 Thread Mike Kelly 
On Wed, 13 Oct 2010 14:13:54 +0200
Michal Sojka sojk...@fel.cvut.cz wrote:

 Hi,
 
 this is an updated version of patches sent in
 id:1273580061-22580-1-git-send-email-sojk...@fel.cvut.cz. Only the
 last patch (tests) was actually updated to work with new test suite.
 These patches has already been tested by several people and I think
 they are ready to be merged. They can be pulled by:
 
 git pull git://rtime.felk.cvut.cz/notmuch maildir-sync-v2

I've tested these patches on Linux, and they seem to work as expected.
However, I'd like to suggest/request that the level-4 syncing of a
filename should happen in notmuch_(message|thread)_(add|remove)_tag(),
not in notmuch-tag.cc. Otherwise, anyone using libnotmuch directly
(e.g. alternative clients, things using python bindings, etc) will not
benefit from this.

-- 
Mike Kelly
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[PATCH 0/4] Maildir synchronization v2

2010-10-14 Thread Michal Sojka 
On Thu, 14 Oct 2010, Dirk Hohndel wrote:
> On Wed, 13 Oct 2010 22:34:34 +0200, Michal Sojka  
> wrote:
> > 
> >  ssh user at host notmuch "$@"
> 
> That to me is certainly a very elegant solution... so what's stopping us
> from implementing notmuch cat? No one taken the time to do it?

Yes. I plan to work on this during the next days.

-Michal

> Or is there a design issue left to be resolved?
> 
> /D

[PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Michal Sojka 
On Wed, 13 Oct 2010, Mike Kelly wrote:
> On Wed, 13 Oct 2010 10:24:25 -0400
> Mike Kelly  wrote:
> 
> > Looks like this may also require a newer xapian than i have now
> > (xapian-core 1.0.18), as notmuch new aborts with:
> > 
> >   terminate called after throwing an instance of
> > 'Xapian::InvalidArgumentError'
> > 
> > I'll see if I can track down anything more concrete as a cause.
> 
> Well, the full backtrace looks like this:

So you were able to compile it? What was the problem?

> 
>   #0  __cxa_throw (obj=0x2883d560, tinfo=0x8070278, dest=0x806132e 
> <~InvalidArgumentError>)
>   at ../../.././../gcc-4.4-20100309/libstdc++-v3/libsupc++/eh_throw.cc:67
>   header = (__cxxabiv1::__cxa_refcounted_exception *) 0x2883d500
>   #1  0x28353b72 in Xapian::Document::Internal::remove_term () from 
> /usr/local/lib/libxapian.so.21
>   No symbol table info available.
>   #2  0x28353c96 in Xapian::Document::remove_term () from 
> /usr/local/lib/libxapian.so.21
>   No symbol table info available.
>   #3  0x080604bc in _notmuch_message_remove_term (message=0x28a85c10, 
> prefix_name=0x806c887 "tag", value=0x806c564 "draft")
>   at lib/message.cc:737
>   term = 0x28806ab0 "Kdraft"
>   #4  0x0806086a in notmuch_message_remove_tag (message=0x28a85c10, 
> tag=0x806c564 "draft") at lib/message.cc:832
>   private_status = 134662454
>   status = NOTMUCH_STATUS_SUCCESS

I guess the problem would be that it removes nonexistent tag. I do not
experience such a problem on Linux with Xapian 1.2.3.

-Michal

[PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Michal Sojka 
On Wed, 13 Oct 2010, Servilio Afre Puentes wrote:
> On 13 October 2010 08:13, Michal Sojka  wrote:
> [...]
> > THERE IS CURRENTLY ONE KNOWN ISSUE: Viewing/storing of attachments of
> > unread messages doesn't work. The reason is that when you view the
> > message its unread tag is removed which causes the file to be renamed,
> > but Emacs still uses the original name to access the attachment. You can
> > workaround this by closing the message and opening it again. This issue
> > will be fixed after we (I) implement "notmuch cat" command. With this
> > command, emacs would not access the messages by the file name, but by
> > running notmuch cat id: which will always give the correct
> > content.
> 
> Wouldn't it be more efficient to query notmuch for the filename using
> the message ID we store in the DB? When network usage is implemented,
> tramp can give us transparent remote file access in emacs.

Tramp would not be available in non-emacs GUIs. Also, when notmuch cat
is implemented, emacs gui will be usable remotely by simply defining
notmuch-command variable to contain the name of the script containing:

 ssh user at host notmuch "$@"

-Michal

[PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Dirk Hohndel 
On Wed, 13 Oct 2010 22:34:34 +0200, Michal Sojka  wrote:
> On Wed, 13 Oct 2010, Servilio Afre Puentes wrote:
> > On 13 October 2010 08:13, Michal Sojka  wrote:
> > [...]
> > > THERE IS CURRENTLY ONE KNOWN ISSUE: Viewing/storing of attachments of
> > > unread messages doesn't work. The reason is that when you view the
> > > message its unread tag is removed which causes the file to be renamed,
> > > but Emacs still uses the original name to access the attachment. You can
> > > workaround this by closing the message and opening it again. This issue
> > > will be fixed after we (I) implement "notmuch cat" command. With this
> > > command, emacs would not access the messages by the file name, but by
> > > running notmuch cat id: which will always give the correct
> > > content.
> > 
> > Wouldn't it be more efficient to query notmuch for the filename using
> > the message ID we store in the DB? When network usage is implemented,
> > tramp can give us transparent remote file access in emacs.
> 
> Tramp would not be available in non-emacs GUIs. Also, when notmuch cat
> is implemented, emacs gui will be usable remotely by simply defining
> notmuch-command variable to contain the name of the script containing:
> 
>  ssh user at host notmuch "$@"

That to me is certainly a very elegant solution... so what's stopping us
from implementing notmuch cat? No one taken the time to do it? Or is
there a design issue left to be resolved?

/D

[PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Mike Kelly 
On Wed, 13 Oct 2010 22:59:49 +0200
Michal Sojka  wrote:

> So you were able to compile it? What was the problem?

I mentioned at the bottom of a previous message:

> This is with "gcc (GCC) 4.2.1 20070719  [FreeBSD]"
>
> Switching to gcc44 seems to allow it to compile correctly, however
> notmuch didn't used to have that dependency.

-- 
Mike Kelly

-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:

[PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread David Bremner 
On Wed, 13 Oct 2010 10:50:36 -0400, Servilio Afre Puentes  wrote:
> 
> Wouldn't it be more efficient to query notmuch for the filename using
> the message ID we store in the DB? When network usage is implemented,
> tramp can give us transparent remote file access in emacs.
> 

We can of course do both. From an implementation point of view, they
would both fall under "selective output in plain text" which various
people have been meaning to do, and I think one is no harder than the
other. On the other hand I doubt that there is an efficiency advantage
to using tramp, it is is more fragile (for example it depends on the
remote shell prompt).

d

[PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Michal Sojka 
Hi,

this is an updated version of patches sent in
id:1273580061-22580-1-git-send-email-sojkam1 at fel.cvut.cz. Only the last
patch (tests) was actually updated to work with new test suite. These
patches has already been tested by several people and I think they are
ready to be merged. They can be pulled by:

git pull git://rtime.felk.cvut.cz/notmuch maildir-sync-v2

These patches implement synchronization between maildir flags and
notmuch tags. The synchronization can be configured to not happen at
all (default), to set/unset tags when importing new (or new and
renamed) messages and to happen in both directions - set/unset tags
during importing and change maildir flags during tagging.

THERE IS CURRENTLY ONE KNOWN ISSUE: Viewing/storing of attachments of
unread messages doesn't work. The reason is that when you view the
message its unread tag is removed which causes the file to be renamed,
but Emacs still uses the original name to access the attachment. You can
workaround this by closing the message and opening it again. This issue
will be fixed after we (I) implement "notmuch cat" command. With this
command, emacs would not access the messages by the file name, but by
running notmuch cat id: which will always give the correct
content.

Michal Sojka (4):
  lib: Return added message even if it already was in the database
  Maildir synchronization
  Make maildir synchronization configurable
  Tests for maildir synchronization

 lib/database-private.h |2 +-
 lib/database.cc|   19 -
 lib/message.cc |  226 
 lib/notmuch-private.h  |4 +
 lib/notmuch.h  |   29 ++-
 notmuch-client.h   |7 ++
 notmuch-config.c   |   48 ++
 notmuch-new.c  |7 ++-
 notmuch-restore.c  |2 +
 notmuch-setup.c|   17 
 notmuch-tag.c  |2 +
 test/maildir-sync  |  216 +
 test/notmuch-test  |2 +-
 test/test-lib.sh   |   14 +++-
 14 files changed, 588 insertions(+), 7 deletions(-)
 create mode 100755 test/maildir-sync

[PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Servilio Afre Puentes 
On 13 October 2010 08:13, Michal Sojka  wrote:
[...]
> THERE IS CURRENTLY ONE KNOWN ISSUE: Viewing/storing of attachments of
> unread messages doesn't work. The reason is that when you view the
> message its unread tag is removed which causes the file to be renamed,
> but Emacs still uses the original name to access the attachment. You can
> workaround this by closing the message and opening it again. This issue
> will be fixed after we (I) implement "notmuch cat" command. With this
> command, emacs would not access the messages by the file name, but by
> running notmuch cat id: which will always give the correct
> content.

Wouldn't it be more efficient to query notmuch for the filename using
the message ID we store in the DB? When network usage is implemented,
tramp can give us transparent remote file access in emacs.

Regards,

Servilio

[PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Mike Kelly 
On Wed, 13 Oct 2010 10:24:25 -0400
Mike Kelly  wrote:

> Looks like this may also require a newer xapian than i have now
> (xapian-core 1.0.18), as notmuch new aborts with:
> 
>   terminate called after throwing an instance of
> 'Xapian::InvalidArgumentError'
> 
> I'll see if I can track down anything more concrete as a cause.

Well, the full backtrace looks like this:

  #0  __cxa_throw (obj=0x2883d560, tinfo=0x8070278, dest=0x806132e 
<~InvalidArgumentError>)
  at ../../.././../gcc-4.4-20100309/libstdc++-v3/libsupc++/eh_throw.cc:67
  header = (__cxxabiv1::__cxa_refcounted_exception *) 0x2883d500
  #1  0x28353b72 in Xapian::Document::Internal::remove_term () from 
/usr/local/lib/libxapian.so.21
  No symbol table info available.
  #2  0x28353c96 in Xapian::Document::remove_term () from 
/usr/local/lib/libxapian.so.21
  No symbol table info available.
  #3  0x080604bc in _notmuch_message_remove_term (message=0x28a85c10, 
prefix_name=0x806c887 "tag", value=0x806c564 "draft")
  at lib/message.cc:737
  term = 0x28806ab0 "Kdraft"
  #4  0x0806086a in notmuch_message_remove_tag (message=0x28a85c10, 
tag=0x806c564 "draft") at lib/message.cc:832
  private_status = 134662454
  status = NOTMUCH_STATUS_SUCCESS
  #5  0x08060a56 in notmuch_message_maildir_to_tags (message=0x28a85c10, 
  filename=0x28a860f0 
"/usr/home/staff/mike/mail/staff-support/cur/1286944232_2.71920.pit84.pair.com,U=26762,FMD5=74eb4e66bae4700f6b79b81477ef9cfa:2,S")
 at lib/message.cc:889
  flags = 0x28a8616e "S"
  i = 0
  status = NOTMUCH_STATUS_SUCCESS
  p = 0x28a8616f ""
  f = 83 'S'
  valid = true
  unread = true
  #6  0x08050bbe in add_files_recursive (notmuch=0x2881e7f0, path=0x2881ec70 
"/usr/home/staff/mike/mail/staff-support/cur", 
  state=0xbfbfe238) at notmuch-new.c:420
  err = 32
  dir = (DIR *) 0x0
  entry = (struct dirent *) 0x28a68640
  next = 0x28a860f0 
"/usr/home/staff/mike/mail/staff-support/cur/1286944232_2.71920.pit84.pair.com,U=26762,FMD5=74eb4e66bae4700f6b79b81477ef9cfa:2,S"
  fs_mtime = 1286978382
  db_mtime = 1286944232
  status = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID
  ret = NOTMUCH_STATUS_SUCCESS
  message = (notmuch_message_t *) 0x28a85c10
  fs_entries = (struct dirent **) 0x28a6f000
  i = 4915
  num_fs_entries = 4922
  directory = (notmuch_directory_t *) 0x288069f0
  db_files = (notmuch_filenames_t *) 0x28806af0
  db_subdirs = (notmuch_filenames_t *) 0x28806b30
  st = {st_dev = 89, st_ino = 4172664, st_mode = 16832, st_nlink = 2, 
st_uid = 1118, st_gid = 0, st_rdev = 16689352, 
st_atimespec = {tv_sec = 1286979943, tv_nsec = 0}, st_mtimespec = {tv_sec = 
1286978382, tv_nsec = 0}, st_ctimespec = {
  tv_sec = 1286978382, tv_nsec = 0}, st_size = 1205760, st_blocks = 2400, 
st_blksize = 4096, st_flags = 0, st_gen = 0, st_lspare = 0, 
st_birthtimespec = {tv_sec = 1264441077, tv_nsec = 0}}
  is_maildir = 0
  new_directory = 0
  tag = (const char **) 0x8069d62
  #7  0x08050780 in add_files_recursive (notmuch=0x2881e7f0, path=0x2881e790 
"/usr/home/staff/mike/mail/staff-support", state=0xbfbfe238)
  at notmuch-new.c:302
  dir = (DIR *) 0x0
  entry = (struct dirent *) 0x288cc5b0
  next = 0x2881ec70 "/usr/home/staff/mike/mail/staff-support/cur"
  fs_mtime = 1264003223
  db_mtime = 1264003223
  status = NOTMUCH_STATUS_SUCCESS
  ret = NOTMUCH_STATUS_SUCCESS
  message = (notmuch_message_t *) 0x0
  fs_entries = (struct dirent **) 0x2883d480
  i = 2
  num_fs_entries = 5
  directory = (notmuch_directory_t *) 0x28806870
  db_files = (notmuch_filenames_t *) 0x28806a30
  db_subdirs = (notmuch_filenames_t *) 0x28806a70
  st = {st_dev = 89, st_ino = 3889110, st_mode = 16832, st_nlink = 5, 
st_uid = 1118, st_gid = 0, st_rdev = 15524535, 
st_atimespec = {tv_sec = 1286979943, tv_nsec = 0}, st_mtimespec = {tv_sec = 
1264003223, tv_nsec = 0}, st_ctimespec = {
  tv_sec = 1264473647, tv_nsec = 0}, st_size = 512, st_blocks = 4, 
st_blksize = 4096, st_flags = 0, st_gen = 0, st_lspare = 0, 
st_birthtimespec = {tv_sec = 1264003223, tv_nsec = 0}}
  is_maildir = 1
  new_directory = 0
  tag = (const char **) 0x8069d62
  #8  0x08050780 in add_files_recursive (notmuch=0x2881e7f0, path=0x2881f680 
"/usr/home/staff/mike/mail", state=0xbfbfe238)
  at notmuch-new.c:302
  dir = (DIR *) 0x0
  entry = (struct dirent *) 0x28808900
  next = 0x2881e790 "/usr/home/staff/mike/mail/staff-support"
  fs_mtime = 1284781182
  db_mtime = 1284781182
  status = NOTMUCH_STATUS_SUCCESS
  ret = NOTMUCH_STATUS_SUCCESS
  message = (notmuch_message_t *) 0x0
  fs_entries = (struct dirent **)

[PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Mike Kelly 
On Wed, 13 Oct 2010 09:31:58 -0400
Mike Kelly  wrote:

> On Wed, 13 Oct 2010 14:13:54 +0200
> Michal Sojka  wrote:
> 
> > Hi,
> > 
> > this is an updated version of patches sent in
> > id:1273580061-22580-1-git-send-email-sojkam1 at fel.cvut.cz. Only the
> > last patch (tests) was actually updated to work with new test suite.
> > These patches has already been tested by several people and I think
> > they are ready to be merged. They can be pulled by:
> > 
> > git pull git://rtime.felk.cvut.cz/notmuch maildir-sync-v2
> 
> This sounds like just the sort of feature set I'd want from this sort
> of patch, except unfortunately it won't compile for me on FreeBSD:

Looks like this may also require a newer xapian than i have now
(xapian-core 1.0.18), as notmuch new aborts with:

  terminate called after throwing an instance of 'Xapian::InvalidArgumentError'

I'll see if I can track down anything more concrete as a cause.

-- 
Mike Kelly

[PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Mike Kelly 
On Wed, 13 Oct 2010 14:13:54 +0200
Michal Sojka  wrote:

> Hi,
> 
> this is an updated version of patches sent in
> id:1273580061-22580-1-git-send-email-sojkam1 at fel.cvut.cz. Only the
> last patch (tests) was actually updated to work with new test suite.
> These patches has already been tested by several people and I think
> they are ready to be merged. They can be pulled by:
> 
> git pull git://rtime.felk.cvut.cz/notmuch maildir-sync-v2

This sounds like just the sort of feature set I'd want from this sort
of patch, except unfortunately it won't compile for me on FreeBSD:

  gcc -c -DNOTMUCH_VERSION=0.3.1-96-g6e0dca9 -O2 -Wall -Wextra -Wwrite-strings 
-Wswitch-enum -Wmissing-declarations -DHAVE_GETLINE=1 -D_REENTRANT 
-I/usr/local/include/gmime-2.4 -I/usr/local/include/glib-2.0 
-I/usr/local/lib/glib-2.0/include   -I/usr/local/include   -DHAVE_VALGRIND=0  
-DHAVE_STRCASESTR=1  -Icompat -Ilib -fPIC notmuch-config.c -o notmuch-config.o
  notmuch-config.c:90: error: field 'maildir_sync' has incomplete type
  notmuch-config.c: In function 'notmuch_config_open':
  notmuch-config.c:241: error: 'NOTMUCH_MAILDIR_SYNC_INVALID' undeclared (first 
use in this function)
  notmuch-config.c:241: error: (Each undeclared identifier is reported only once
  notmuch-config.c:241: error: for each function it appears in.)
  notmuch-config.c:335: error: invalid use of undefined type 'enum 
notmuch_maildir_sync'
  notmuch-config.c:336: error: 'NOTMUCH_MAILDIR_SYNC_NONE' undeclared (first 
use in this function)
  notmuch-config.c:336: error: type of formal parameter 2 is incomplete
  notmuch-config.c: At top level:
  notmuch-config.c:596: error: return type is an incomplete type
  notmuch-config.c:596: error: conflicting types for 
'notmuch_config_get_maildir_sync'
  notmuch-client.h:195: error: previous declaration of 
'notmuch_config_get_maildir_sync' was here
  notmuch-config.c: In function 'notmuch_config_get_maildir_sync':
  notmuch-config.c:597: error: 'NOTMUCH_MAILDIR_SYNC_INVALID' undeclared (first 
use in this function)
  notmuch-config.c:602: warning: 'return' with a value, in function returning 
void
  notmuch-config.c: At top level:
  notmuch-config.c:607: error: parameter 2 ('maildir_sync') has incomplete type
  notmuch-config.c: In function 'notmuch_config_set_maildir_sync':
  notmuch-config.c:607: warning: unused parameter 'maildir_sync'
  gmake: *** [notmuch-config.o] Error 1

This is with "gcc (GCC) 4.2.1 20070719  [FreeBSD]"

Switching to gcc44 seems to allow it to compile correctly, however notmuch 
didn't used to have that dependency.

-- 
Mike Kelly

Re: [PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Mike Kelly 
On Wed, 13 Oct 2010 10:24:25 -0400
Mike Kelly pi...@pioto.org wrote:

 Looks like this may also require a newer xapian than i have now
 (xapian-core 1.0.18), as notmuch new aborts with:
 
   terminate called after throwing an instance of
 'Xapian::InvalidArgumentError'
 
 I'll see if I can track down anything more concrete as a cause.

Well, the full backtrace looks like this:

  #0  __cxa_throw (obj=0x2883d560, tinfo=0x8070278, dest=0x806132e 
~InvalidArgumentError)
  at ../../.././../gcc-4.4-20100309/libstdc++-v3/libsupc++/eh_throw.cc:67
  header = (__cxxabiv1::__cxa_refcounted_exception *) 0x2883d500
  #1  0x28353b72 in Xapian::Document::Internal::remove_term () from 
/usr/local/lib/libxapian.so.21
  No symbol table info available.
  #2  0x28353c96 in Xapian::Document::remove_term () from 
/usr/local/lib/libxapian.so.21
  No symbol table info available.
  #3  0x080604bc in _notmuch_message_remove_term (message=0x28a85c10, 
prefix_name=0x806c887 tag, value=0x806c564 draft)
  at lib/message.cc:737
  term = 0x28806ab0 Kdraft
  #4  0x0806086a in notmuch_message_remove_tag (message=0x28a85c10, 
tag=0x806c564 draft) at lib/message.cc:832
  private_status = 134662454
  status = NOTMUCH_STATUS_SUCCESS
  #5  0x08060a56 in notmuch_message_maildir_to_tags (message=0x28a85c10, 
  filename=0x28a860f0 
/usr/home/staff/mike/mail/staff-support/cur/1286944232_2.71920.pit84.pair.com,U=26762,FMD5=74eb4e66bae4700f6b79b81477ef9cfa:2,S)
 at lib/message.cc:889
  flags = 0x28a8616e S
  i = 0
  status = NOTMUCH_STATUS_SUCCESS
  p = 0x28a8616f 
  f = 83 'S'
  valid = true
  unread = true
  #6  0x08050bbe in add_files_recursive (notmuch=0x2881e7f0, path=0x2881ec70 
/usr/home/staff/mike/mail/staff-support/cur, 
  state=0xbfbfe238) at notmuch-new.c:420
  err = 32
  dir = (DIR *) 0x0
  entry = (struct dirent *) 0x28a68640
  next = 0x28a860f0 
/usr/home/staff/mike/mail/staff-support/cur/1286944232_2.71920.pit84.pair.com,U=26762,FMD5=74eb4e66bae4700f6b79b81477ef9cfa:2,S
  fs_mtime = 1286978382
  db_mtime = 1286944232
  status = NOTMUCH_STATUS_DUPLICATE_MESSAGE_ID
  ret = NOTMUCH_STATUS_SUCCESS
  message = (notmuch_message_t *) 0x28a85c10
  fs_entries = (struct dirent **) 0x28a6f000
  i = 4915
  num_fs_entries = 4922
  directory = (notmuch_directory_t *) 0x288069f0
  db_files = (notmuch_filenames_t *) 0x28806af0
  db_subdirs = (notmuch_filenames_t *) 0x28806b30
  st = {st_dev = 89, st_ino = 4172664, st_mode = 16832, st_nlink = 2, 
st_uid = 1118, st_gid = 0, st_rdev = 16689352, 
st_atimespec = {tv_sec = 1286979943, tv_nsec = 0}, st_mtimespec = {tv_sec = 
1286978382, tv_nsec = 0}, st_ctimespec = {
  tv_sec = 1286978382, tv_nsec = 0}, st_size = 1205760, st_blocks = 2400, 
st_blksize = 4096, st_flags = 0, st_gen = 0, st_lspare = 0, 
st_birthtimespec = {tv_sec = 1264441077, tv_nsec = 0}}
  is_maildir = 0
  new_directory = 0
  tag = (const char **) 0x8069d62
  #7  0x08050780 in add_files_recursive (notmuch=0x2881e7f0, path=0x2881e790 
/usr/home/staff/mike/mail/staff-support, state=0xbfbfe238)
  at notmuch-new.c:302
  dir = (DIR *) 0x0
  entry = (struct dirent *) 0x288cc5b0
  next = 0x2881ec70 /usr/home/staff/mike/mail/staff-support/cur
  fs_mtime = 1264003223
  db_mtime = 1264003223
  status = NOTMUCH_STATUS_SUCCESS
  ret = NOTMUCH_STATUS_SUCCESS
  message = (notmuch_message_t *) 0x0
  fs_entries = (struct dirent **) 0x2883d480
  i = 2
  num_fs_entries = 5
  directory = (notmuch_directory_t *) 0x28806870
  db_files = (notmuch_filenames_t *) 0x28806a30
  db_subdirs = (notmuch_filenames_t *) 0x28806a70
  st = {st_dev = 89, st_ino = 3889110, st_mode = 16832, st_nlink = 5, 
st_uid = 1118, st_gid = 0, st_rdev = 15524535, 
st_atimespec = {tv_sec = 1286979943, tv_nsec = 0}, st_mtimespec = {tv_sec = 
1264003223, tv_nsec = 0}, st_ctimespec = {
  tv_sec = 1264473647, tv_nsec = 0}, st_size = 512, st_blocks = 4, 
st_blksize = 4096, st_flags = 0, st_gen = 0, st_lspare = 0, 
st_birthtimespec = {tv_sec = 1264003223, tv_nsec = 0}}
  is_maildir = 1
  new_directory = 0
  tag = (const char **) 0x8069d62
  #8  0x08050780 in add_files_recursive (notmuch=0x2881e7f0, path=0x2881f680 
/usr/home/staff/mike/mail, state=0xbfbfe238)
  at notmuch-new.c:302
  dir = (DIR *) 0x0
  entry = (struct dirent *) 0x28808900
  next = 0x2881e790 /usr/home/staff/mike/mail/staff-support
  fs_mtime = 1284781182
  db_mtime = 1284781182
  status = NOTMUCH_STATUS_SUCCESS
  ret = NOTMUCH_STATUS_SUCCESS
  message = (notmuch_message_t *) 0x0
  fs_entries = (struct dirent **) 0x28825000

Re: [PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Servilio Afre Puentes 
On 13 October 2010 08:13, Michal Sojka sojk...@fel.cvut.cz wrote:
[...]
 THERE IS CURRENTLY ONE KNOWN ISSUE: Viewing/storing of attachments of
 unread messages doesn't work. The reason is that when you view the
 message its unread tag is removed which causes the file to be renamed,
 but Emacs still uses the original name to access the attachment. You can
 workaround this by closing the message and opening it again. This issue
 will be fixed after we (I) implement notmuch cat command. With this
 command, emacs would not access the messages by the file name, but by
 running notmuch cat id:message-id which will always give the correct
 content.

Wouldn't it be more efficient to query notmuch for the filename using
the message ID we store in the DB? When network usage is implemented,
tramp can give us transparent remote file access in emacs.

Regards,

Servilio
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread David Bremner 
On Wed, 13 Oct 2010 10:50:36 -0400, Servilio Afre Puentes servi...@gmail.com 
wrote:
 
 Wouldn't it be more efficient to query notmuch for the filename using
 the message ID we store in the DB? When network usage is implemented,
 tramp can give us transparent remote file access in emacs.
 

We can of course do both. From an implementation point of view, they
would both fall under selective output in plain text which various
people have been meaning to do, and I think one is no harder than the
other. On the other hand I doubt that there is an efficiency advantage
to using tramp, it is is more fragile (for example it depends on the
remote shell prompt).

d

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Michal Sojka 
On Wed, 13 Oct 2010, Mike Kelly wrote:
 On Wed, 13 Oct 2010 10:24:25 -0400
 Mike Kelly pi...@pioto.org wrote:
 
  Looks like this may also require a newer xapian than i have now
  (xapian-core 1.0.18), as notmuch new aborts with:
  
terminate called after throwing an instance of
  'Xapian::InvalidArgumentError'
  
  I'll see if I can track down anything more concrete as a cause.
 
 Well, the full backtrace looks like this:

So you were able to compile it? What was the problem?

 
   #0  __cxa_throw (obj=0x2883d560, tinfo=0x8070278, dest=0x806132e 
 ~InvalidArgumentError)
   at ../../.././../gcc-4.4-20100309/libstdc++-v3/libsupc++/eh_throw.cc:67
   header = (__cxxabiv1::__cxa_refcounted_exception *) 0x2883d500
   #1  0x28353b72 in Xapian::Document::Internal::remove_term () from 
 /usr/local/lib/libxapian.so.21
   No symbol table info available.
   #2  0x28353c96 in Xapian::Document::remove_term () from 
 /usr/local/lib/libxapian.so.21
   No symbol table info available.
   #3  0x080604bc in _notmuch_message_remove_term (message=0x28a85c10, 
 prefix_name=0x806c887 tag, value=0x806c564 draft)
   at lib/message.cc:737
   term = 0x28806ab0 Kdraft
   #4  0x0806086a in notmuch_message_remove_tag (message=0x28a85c10, 
 tag=0x806c564 draft) at lib/message.cc:832
   private_status = 134662454
   status = NOTMUCH_STATUS_SUCCESS

I guess the problem would be that it removes nonexistent tag. I do not
experience such a problem on Linux with Xapian 1.2.3.

-Michal
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Mike Kelly 
On Wed, 13 Oct 2010 22:59:49 +0200
Michal Sojka sojk...@fel.cvut.cz wrote:

 So you were able to compile it? What was the problem?

I mentioned at the bottom of a previous message:

 This is with gcc (GCC) 4.2.1 20070719  [FreeBSD]

 Switching to gcc44 seems to allow it to compile correctly, however
 notmuch didn't used to have that dependency.

-- 
Mike Kelly



signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 0/4] Maildir synchronization v2

2010-10-13 Thread Dirk Hohndel 
On Wed, 13 Oct 2010 22:34:34 +0200, Michal Sojka sojk...@fel.cvut.cz wrote:
 On Wed, 13 Oct 2010, Servilio Afre Puentes wrote:
  On 13 October 2010 08:13, Michal Sojka sojk...@fel.cvut.cz wrote:
  [...]
   THERE IS CURRENTLY ONE KNOWN ISSUE: Viewing/storing of attachments of
   unread messages doesn't work. The reason is that when you view the
   message its unread tag is removed which causes the file to be renamed,
   but Emacs still uses the original name to access the attachment. You can
   workaround this by closing the message and opening it again. This issue
   will be fixed after we (I) implement notmuch cat command. With this
   command, emacs would not access the messages by the file name, but by
   running notmuch cat id:message-id which will always give the correct
   content.
  
  Wouldn't it be more efficient to query notmuch for the filename using
  the message ID we store in the DB? When network usage is implemented,
  tramp can give us transparent remote file access in emacs.
 
 Tramp would not be available in non-emacs GUIs. Also, when notmuch cat
 is implemented, emacs gui will be usable remotely by simply defining
 notmuch-command variable to contain the name of the script containing:
 
  ssh u...@host notmuch $@

That to me is certainly a very elegant solution... so what's stopping us
from implementing notmuch cat? No one taken the time to do it? Or is
there a design issue left to be resolved?

/D
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch