bug in emacs-ui ?
On Tue, 21 Jun 2011 02:01:17 +0200, Sebastien Binet wrote: > and I checked there were no lingering .el files... > > so... > any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie > when comes to hacking lisp) Hey, Sebastien. You can determine the loaded version of a library from within emacs with the follow command: M-x locate-library notmuch It's also good to know how many notmuch instances are installed on your system. For instance, I have a system-wide installation, a "personal" installation, the build currently in the source tree, etc. Depending on the options I supply to emacs at startup, I could run a variety of versions. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/05e5ee70/attachment-0001.pgp>
[PATCH] fix sum moar typos
Various typo fixes in docs, docstrings, comments, etc...
Signed-off-by: Pieter Praet
---
Rebased to current master (12d6f90e)
NEWS | 10 +-
TODO |4 ++--
compat/README|2 +-
completion/Makefile |2 +-
configure|4 ++--
emacs/Makefile |2 +-
emacs/notmuch-hello.el |2 +-
emacs/notmuch-lib.el |2 +-
emacs/notmuch-maildir-fcc.el |2 +-
emacs/notmuch-show.el|6 +++---
emacs/notmuch-wash.el|2 +-
emacs/notmuch.el |6 +++---
gmime-filter-headers.h |2 +-
lib/Makefile |2 +-
lib/Makefile.local |2 +-
lib/database.cc | 12 ++--
lib/libsha1.c|2 +-
lib/libsha1.h|2 +-
lib/message.cc |4 ++--
lib/notmuch.h|4 ++--
notmuch-config.c |2 +-
notmuch-new.c|2 +-
notmuch-reply.c |4 ++--
notmuch.1|6 +++---
notmuch.c|2 +-
packaging/debian |4 ++--
test/Makefile|2 +-
test/README |6 +++---
test/crypto |2 +-
test/maildir-sync|2 +-
test/multipart |2 +-
test/test-lib.sh |2 +-
test/uuencode|4 ++--
vim/README |2 +-
vim/plugin/notmuch.vim |4 ++--
35 files changed, 60 insertions(+), 60 deletions(-)
diff --git a/NEWS b/NEWS
index 5a1778e..dae7832 100644
--- a/NEWS
+++ b/NEWS
@@ -112,15 +112,15 @@ Allow for notmuch-fcc-dirs to have a value of nil.
string. Instead it's now a list of cons cells where the car of each
cell is a regular expression to be matched against the sender
address, and the cdr is the name of a folder to use for an FCC. So
- the old fallback behavior can be achieved by including a fineal cell
+ the old fallback behavior can be achieved by including a final cell
of (".*" . "default-fcc-folder").
Vim interface improvements
--
Felipe Contreras provided a number of updates for the vim interface.
- These include optimiations, support for newer versions of vim, fixed
- support for sending mail on modern systmms, new commands, and
+ These include optimizations, support for newer versions of vim, fixed
+ support for sending mail on modern systems, new commands, and
various cleanups.
New bindings
@@ -606,7 +606,7 @@ Fix to compile against GMime 2.6
Fix configure script to accept (and ignore) various standard options.
- For example, those that the gentoo build scripts expect configure to
+ For example, those that the Gentoo build scripts expect configure to
accept are now all accepted.
Test suite
@@ -714,7 +714,7 @@ tags by region.
Selective bulk tagging is now possible by selecting a region of
threads and then using either the '+' or '-' keybindings. Bulk
tagging is still available for all threads matching the current
- search with th '*' binding.
+ search with the '*' binding.
More meaningful buffer names for thread-view buffers.
diff --git a/TODO b/TODO
index 260ffe1..14dfa55 100644
--- a/TODO
+++ b/TODO
@@ -29,7 +29,7 @@ Make 'notmuch-show-pipe-message have a private history.
Add support for a delete keybinding that adds a "deleted" tag to the
current message/thread and make searches not return deleted messages
-by default, (unless the user asks explicitly for deleted messags in
+by default, (unless the user asks explicitly for deleted messages in
the search query).
Add keybindings for next/previous thread.
@@ -119,7 +119,7 @@ Allow configuration for filename patterns that should be
ignored when
indexing.
Replace the "notmuch part --part=id" command with "notmuch show
---part=id", (David Edmonson wants to rewrite some of "notmuch show" to
+--part=id", (David Edmondson wants to rewrite some of "notmuch show" to
provide more MIME-structure information in its output first).
Replace the "notmuch search-tags" command with "notmuch search
diff --git a/compat/README b/compat/README
index cd32c56..38e2e14 100644
--- a/compat/README
+++ b/compat/README
@@ -1,4 +1,4 @@
-notmuch/comapt
+notmuch/compat
This directory consists of two things:
diff --git a/completion/Makefile b/completion/Makefile
index b6859ea..de492a7 100644
--- a/completion/Makefile
+++ b/completion/Makefile
@@ -1,4 +1,4 @@
-# See Makfefile.local for the list of files to be compiled in this
+# See Makefile.local for the list of files to be compiled in this
# directory.
all:
$(MAKE) -C .. all
diff --git a/configure b/configure
index cf525c9..3999ce8 100755
--- a/configure
+++ b/configure
@@ -22,7 +22,7 @@ if [ "$srcdir" != "." ]; then
fi
# Set several defaults (optionally specified by the user in
-# environemnt variables)
+#
bug in emacs-ui ?
On Mon, 20 Jun 2011 12:53:37 -0700, Jameson Graef Rollins wrote: Non-text part: multipart/mixed Non-text part: multipart/signed > On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet > wrote: > > > You didn't try forwarding the email to the list ;) > > ah! that easy, heh ? > > > Attachment: > 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S > (application/octet-stream) > > Hi, Sebastien. I don't seem to have any problems viewing this message > with notmuch emacs. Is it possible that the notmuch emacs code you're > running is out-of-sync with your notmuch binary? [...] +1. Stale notmuch binary was indeed the culprit. > [..] I think that's a > common source of problems like this. Make sure that you're pointed to > the version of the notmuch emacs libraries that corresponds to your > notmuch binary, and that you've restarted your emacs session. Hopefully > that will fix things. > > jamie. Non-text part: application/pgp-signature > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch Peace -- Pieter
bug in emacs-ui ?
On Mon, 20 Jun 2011 21:06:09 +0200, Sebastien Binet wrote: Non-text part: multipart/mixed Non-text part: multipart/signed > On Mon, 20 Jun 2011 11:18:11 -0700, Jameson Graef Rollins finestructure.net> wrote: > Non-text part: multipart/signed > > On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet > gmail.com> wrote: > > > > You didn't try forwarding the email to the list ;) > > > ah! that easy, heh ? > > > > > > Attachment: > > > 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S > > > (application/octet-stream) > > > > Are you sure this is the right message? This message doesn't include > > any signature section that looks like the one that you posted before. > > The one you posted in your previous message was: > > > > ___ > > Message sent via/by LCG Savannah > > http://savannah.cern.ch/ > > > > This one is: > > > > ___ > > announce mailing list > > announce at open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/announce > > it is indeed another message but one which presents the same problem > (the other one was from a semi-private mailing list...) Appears to occur with *every* message which - has a collapsed signature - is last in a thread I'm awake longer than I care to admit, so don't take my word for it, but notmuch-show.el:1128 (on master, 12d6f90e) should be where it's at. Most probably an unfortunate side-effect of Dmitry's (excellent) recent visibility patches. > > > > Also (unrelated) I notice that the above attached message is not > > content-type "message/rfc822". Specifying the right content type helps > > receivers handle the messages a little better. > duly noted. > > -s > -- > # > # Dr. Sebastien Binet > # Laboratoire de l'Accelerateur Lineaire > # Universite Paris-Sud XI > # Batiment 200 > # 91898 Orsay > # Non-text part: application/pgp-signature > ___ > notmuch mailing list > notmuch at notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch Peace -- Pieter
bug in emacs-ui ?
On Mon, 20 Jun 2011 11:18:11 -0700, Jameson Graef Rollins wrote: Non-text part: multipart/signed > On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet > wrote: > > > You didn't try forwarding the email to the list ;) > > ah! that easy, heh ? > > > > Attachment: > > 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S > > (application/octet-stream) > > Are you sure this is the right message? This message doesn't include > any signature section that looks like the one that you posted before. > The one you posted in your previous message was: > > ___ > Message sent via/by LCG Savannah > http://savannah.cern.ch/ > > This one is: > > ___ > announce mailing list > announce at open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/announce it is indeed another message but one which presents the same problem (the other one was from a semi-private mailing list...) > > Also (unrelated) I notice that the above attached message is not > content-type "message/rfc822". Specifying the right content type helps > receivers handle the messages a little better. duly noted. -s -- # # Dr. Sebastien Binet # Laboratoire de l'Accelerateur Lineaire # Universite Paris-Sud XI # Batiment 200 # 91898 Orsay # -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/fb2bc4e1/attachment.pgp>
bug in emacs-ui ?
On Mon, 20 Jun 2011 09:17:32 -0700, Jameson Graef Rollins wrote: Non-text part: multipart/signed > On Mon, 20 Jun 2011 17:52:03 +0200, Sebastien Binet > wrote: > > it is only when the signature is lumped like below, that I get the error: > > [ 4-line signature. Click/Enter to show. ] > > > > also, it's only happening to the last message of a thread. > > Ah, ok. Have you tried looking at the raw message? Are there any > strange characters or content after the signatures? nope. at least none that I can see. > > > > If you feel comfortable doing so, it might help to forward the suspect > > > message to the list. > > > > I tried all the above, to no avail (ie: nothing on stderr.) > > You didn't try forwarding the email to the list ;) ah! that easy, heh ? -- next part -- A non-text attachment was scrubbed... Name: 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S Type: application/octet-stream Size: 5943 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/c7b11f13/attachment-0002.obj> -- next part -- here is also the json dump of that message: -- next part -- A non-text attachment was scrubbed... Name: tmp.openmpi.message.json Type: application/octet-stream Size: 1680 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/c7b11f13/attachment-0003.obj> -- next part -- hth, -s -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/c7b11f13/attachment-0001.pgp>
bug in emacs-ui ?
Jamie, On Mon, 20 Jun 2011 08:16:00 -0700, Jameson Graef Rollins wrote: Non-text part: multipart/signed > On Mon, 20 Jun 2011 09:15:06 +0200, Sebastien Binet > wrote: > > recently, using the head of notmuch-git: > > > > git://notmuchmail.org/git/notmuch > > > > when a mail ends with an url and is recognized as a signature: > ... > > I can't hit [space] to go to the next thread and I get the following > > error: > > End of buffer > > Hey, Sebastien. I'm guessing that it is probably the *next* message in > the thread that is the problem, not the end of the one that you're > seeing. I (naively) don't think so: I don't get the error (which looks like that in the *Messages* buffer: notmuch-show-advance-and-archive: End of buffer ) if I unravel the signature: [ 4-line signature. Click/Enter to hide. ] ___ Message sent via/by LCG Savannah http://savannah.cern.ch/ => all is fine. it is only when the signature is lumped like below, that I get the error: [ 4-line signature. Click/Enter to show. ] also, it's only happening to the last message of a thread. > If you can determine the message id's of this message and the > next one in the thread it will probably help with debugging. > > If you haven't yet, it usually helps in debugging to view the messages > in the terminal? You can copy the thread-id into the clipboard by > hitting "c i" when the cursor is over this thread in the notmuch search > buffer, and then you can view the thread on the command line with: > > notmuch show thread: > > It might be hard to see if there are any problems in the output, but you > can at least see gmime is throwing an error by redirecting stdout to > /dev/null: > > notmuch show thread: >/dev/null > > You can try determining the message-ids with something like: > > notmuch show thread: | grep id > > You can then view the raw messages with: > > notmuch show --format=raw id: > > If you feel comfortable doing so, it might help to forward the suspect > message to the list. I tried all the above, to no avail (ie: nothing on stderr.) > > > this does not show up when using the 'release-candidate/0.6' branch of: > > git://finestructure.net/notmuch > > The release-candidate/0.6 is a bit out-of-date at the moment, as most of > it's features have been incorporate into notmuch/master, and I doubt > that the ones that haven't would be related to the issue you're > seeing. hum... I could try to bisect (but I've never done that before!) -s -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/e775388c/attachment.pgp>
bug in emacs-ui ?
On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet wrote: > > You didn't try forwarding the email to the list ;) > ah! that easy, heh ? > Attachment: 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S (application/octet-stream) Hi, Sebastien. I don't seem to have any problems viewing this message with notmuch emacs. Is it possible that the notmuch emacs code you're running is out-of-sync with your notmuch binary? I think that's a common source of problems like this. Make sure that you're pointed to the version of the notmuch emacs libraries that corresponds to your notmuch binary, and that you've restarted your emacs session. Hopefully that will fix things. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/a88c1832/attachment.pgp>
[python] segfaults at Message.get_date
Quoth Sebastian Spaeth on Jun 20 at 9:29 am: > On Sun, 19 Jun 2011 19:51:11 -0400, Austin Clements > wrote: > > A double will precisely represent integers up to 2^53, so this > > conversion shouldn't be a problem until the year 285422109 or so. > > But given that it works, is it actually necessary, that xapian > apparently pulls an int from the database, returns a std::string to > libnotmuch, which calls a helper function to unserialize it to a double > and casts it to time_t before handing it to the user how probably uses > it as a long? > > Can't we easily put in longs and get longs back? Xapian only knows about strings, so there has to be serialization somewhere and the serialized form has to have the same collation order as the numerical order of the original numbers. You could do this by storing the bytes of the long in big-endian form, but that's basically what sortable_serialise does: roughly, the first byte stores the number of bits needed to represent the number, followed by enough bytes to hold those bits in big-endian. Since POSIX permits a wide range of types to implement time_t, sortable_serialise also has the major advantage that it can handle any of them. So, taking portability and time_t as assumptions, there are no unnecessary conversion steps here (and, really, it's just string->double->time_t on Linux and just string->time_t on a platform that uses floating point time_t's). Alternatively, notmuch could switch to using long instead of time_t for dates, but that seems like a lot of effort for little gain and results in portability friction whenever notmuch wants to use the standard C time API's.
bug in emacs-ui ?
On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet wrote: > > You didn't try forwarding the email to the list ;) > ah! that easy, heh ? > > Attachment: > 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S > (application/octet-stream) Are you sure this is the right message? This message doesn't include any signature section that looks like the one that you posted before. The one you posted in your previous message was: ___ Message sent via/by LCG Savannah http://savannah.cern.ch/ This one is: ___ announce mailing list announce at open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/announce Also (unrelated) I notice that the above attached message is not content-type "message/rfc822". Specifying the right content type helps receivers handle the messages a little better. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/633ea7f9/attachment.pgp>
[PATCH 2/2] Do not import notmuch in setup.py.
On Sun, 19 Jun 2011 16:53:43 -0300, david at tethera.net wrote: > From: David Bremner > > Importing notmuch loads the notmuch shared library. When building > without a system install of notmuch, this requires e.g. setting > LD_LIBRARY_PATH for building and fails completely for cleaning. Yes, doing it this way in setup.py seems sane and fine to me. setup.py still works. Given that this is /bindings/python/* material, I took the liberty to merge this patch. The debian/control part, I would prefer it some maintainer would nod off/merge that one. Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/a2e67292/attachment.pgp>
[PATCH 1/2] Build debian package for python-bindings.
On Sun, 19 Jun 2011 16:53:42 -0300, david at tethera.net wrote: > From: David Bremner Signed-off-by: Sebastian Spaeth Looks good and nice to me (couldn't test it yet) if you are willing to include python as build time dependency for everyone. Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/cef27606/attachment-0001.pgp>
[python] segfaults at Message.get_date
On Sun, 19 Jun 2011 19:51:11 -0400, Austin Clements wrote: > A double will precisely represent integers up to 2^53, so this > conversion shouldn't be a problem until the year 285422109 or so. But given that it works, is it actually necessary, that xapian apparently pulls an int from the database, returns a std::string to libnotmuch, which calls a helper function to unserialize it to a double and casts it to time_t before handing it to the user how probably uses it as a long? Can't we easily put in longs and get longs back? Sebastian -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/331d05f0/attachment.pgp>
bug in emacs-ui ?
On Mon, 20 Jun 2011 17:52:03 +0200, Sebastien Binet wrote: > it is only when the signature is lumped like below, that I get the error: > [ 4-line signature. Click/Enter to show. ] > > also, it's only happening to the last message of a thread. Ah, ok. Have you tried looking at the raw message? Are there any strange characters or content after the signatures? > > If you feel comfortable doing so, it might help to forward the suspect > > message to the list. > > I tried all the above, to no avail (ie: nothing on stderr.) You didn't try forwarding the email to the list ;) jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/ee16d15a/attachment.pgp>
bug in emacs-ui ?
hi there, recently, using the head of notmuch-git: git://notmuchmail.org/git/notmuch when a mail ends with an url and is recognized as a signature: == This item URL is: <http://savannah.cern.ch/bugs/?83337> [ 4-line signature. Click/Enter to hide. ] ___ Message sent via/by LCG Savannah http://savannah.cern.ch/ I can't hit [space] to go to the next thread and I get the following error: End of buffer this does not show up when using the 'release-candidate/0.6' branch of: git://finestructure.net/notmuch -s -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/a4e41524/attachment.pgp>
bug in emacs-ui ?
On Mon, 20 Jun 2011 09:15:06 +0200, Sebastien Binet wrote: > recently, using the head of notmuch-git: > > git://notmuchmail.org/git/notmuch > > when a mail ends with an url and is recognized as a signature: ... > I can't hit [space] to go to the next thread and I get the following > error: > End of buffer Hey, Sebastien. I'm guessing that it is probably the *next* message in the thread that is the problem, not the end of the one that you're seeing. If you can determine the message id's of this message and the next one in the thread it will probably help with debugging. If you haven't yet, it usually helps in debugging to view the messages in the terminal? You can copy the thread-id into the clipboard by hitting "c i" when the cursor is over this thread in the notmuch search buffer, and then you can view the thread on the command line with: notmuch show thread: It might be hard to see if there are any problems in the output, but you can at least see gmime is throwing an error by redirecting stdout to /dev/null: notmuch show thread: >/dev/null You can try determining the message-ids with something like: notmuch show thread: | grep id You can then view the raw messages with: notmuch show --format=raw id: If you feel comfortable doing so, it might help to forward the suspect message to the list. > this does not show up when using the 'release-candidate/0.6' branch of: > git://finestructure.net/notmuch The release-candidate/0.6 is a bit out-of-date at the moment, as most of it's features have been incorporate into notmuch/master, and I doubt that the ones that haven't would be related to the issue you're seeing. hth. jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110620/d08983f4/attachment.pgp>
bug in emacs-ui ?
hi there, recently, using the head of notmuch-git: git://notmuchmail.org/git/notmuch when a mail ends with an url and is recognized as a signature: == This item URL is: http://savannah.cern.ch/bugs/?83337 [ 4-line signature. Click/Enter to hide. ] ___ Message sent via/by LCG Savannah http://savannah.cern.ch/ I can't hit [space] to go to the next thread and I get the following error: End of buffer this does not show up when using the 'release-candidate/0.6' branch of: git://finestructure.net/notmuch -s pgpyHLAUOL8pq.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [python] segfaults at Message.get_date
Quoth Sebastian Spaeth on Jun 20 at 9:29 am: On Sun, 19 Jun 2011 19:51:11 -0400, Austin Clements amdra...@mit.edu wrote: A double will precisely represent integers up to 2^53, so this conversion shouldn't be a problem until the year 285422109 or so. But given that it works, is it actually necessary, that xapian apparently pulls an int from the database, returns a std::string to libnotmuch, which calls a helper function to unserialize it to a double and casts it to time_t before handing it to the user how probably uses it as a long? Can't we easily put in longs and get longs back? Xapian only knows about strings, so there has to be serialization somewhere and the serialized form has to have the same collation order as the numerical order of the original numbers. You could do this by storing the bytes of the long in big-endian form, but that's basically what sortable_serialise does: roughly, the first byte stores the number of bits needed to represent the number, followed by enough bytes to hold those bits in big-endian. Since POSIX permits a wide range of types to implement time_t, sortable_serialise also has the major advantage that it can handle any of them. So, taking portability and time_t as assumptions, there are no unnecessary conversion steps here (and, really, it's just string-double-time_t on Linux and just string-time_t on a platform that uses floating point time_t's). Alternatively, notmuch could switch to using long instead of time_t for dates, but that seems like a lot of effort for little gain and results in portability friction whenever notmuch wants to use the standard C time API's. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: bug in emacs-ui ?
On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet seb.bi...@gmail.com wrote: You didn't try forwarding the email to the list ;) ah! that easy, heh ? Attachment: 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S (application/octet-stream) Are you sure this is the right message? This message doesn't include any signature section that looks like the one that you posted before. The one you posted in your previous message was: ___ Message sent via/by LCG Savannah http://savannah.cern.ch/ This one is: ___ announce mailing list annou...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/announce Also (unrelated) I notice that the above attached message is not content-type message/rfc822. Specifying the right content type helps receivers handle the messages a little better. jamie. pgp8moO987ORJ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: bug in emacs-ui ?
On Mon, 20 Jun 2011 11:18:11 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: Non-text part: multipart/signed On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet seb.bi...@gmail.com wrote: You didn't try forwarding the email to the list ;) ah! that easy, heh ? Attachment: 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S (application/octet-stream) Are you sure this is the right message? This message doesn't include any signature section that looks like the one that you posted before. The one you posted in your previous message was: ___ Message sent via/by LCG Savannah http://savannah.cern.ch/ This one is: ___ announce mailing list annou...@open-mpi.org http://www.open-mpi.org/mailman/listinfo.cgi/announce it is indeed another message but one which presents the same problem (the other one was from a semi-private mailing list...) Also (unrelated) I notice that the above attached message is not content-type message/rfc822. Specifying the right content type helps receivers handle the messages a little better. duly noted. -s -- # # Dr. Sebastien Binet # Laboratoire de l'Accelerateur Lineaire # Universite Paris-Sud XI # Batiment 200 # 91898 Orsay # pgpGH0OoyYZ7I.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: bug in emacs-ui ?
On Mon, 20 Jun 2011 12:53:37 -0700, Jameson Graef Rollins jroll...@finestructure.net wrote: Non-text part: multipart/mixed Non-text part: multipart/signed On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet seb.bi...@gmail.com wrote: You didn't try forwarding the email to the list ;) ah! that easy, heh ? Attachment: 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S (application/octet-stream) Hi, Sebastien. I don't seem to have any problems viewing this message with notmuch emacs. Is it possible that the notmuch emacs code you're running is out-of-sync with your notmuch binary? [...] +1. Stale notmuch binary was indeed the culprit. [..] I think that's a common source of problems like this. Make sure that you're pointed to the version of the notmuch emacs libraries that corresponds to your notmuch binary, and that you've restarted your emacs session. Hopefully that will fix things. jamie. Non-text part: application/pgp-signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch Peace -- Pieter ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] fix sum moar typos
Various typo fixes in docs, docstrings, comments, etc... Signed-off-by: Pieter Praet pie...@praet.org --- Rebased to current master (12d6f90e) NEWS | 10 +- TODO |4 ++-- compat/README|2 +- completion/Makefile |2 +- configure|4 ++-- emacs/Makefile |2 +- emacs/notmuch-hello.el |2 +- emacs/notmuch-lib.el |2 +- emacs/notmuch-maildir-fcc.el |2 +- emacs/notmuch-show.el|6 +++--- emacs/notmuch-wash.el|2 +- emacs/notmuch.el |6 +++--- gmime-filter-headers.h |2 +- lib/Makefile |2 +- lib/Makefile.local |2 +- lib/database.cc | 12 ++-- lib/libsha1.c|2 +- lib/libsha1.h|2 +- lib/message.cc |4 ++-- lib/notmuch.h|4 ++-- notmuch-config.c |2 +- notmuch-new.c|2 +- notmuch-reply.c |4 ++-- notmuch.1|6 +++--- notmuch.c|2 +- packaging/debian |4 ++-- test/Makefile|2 +- test/README |6 +++--- test/crypto |2 +- test/maildir-sync|2 +- test/multipart |2 +- test/test-lib.sh |2 +- test/uuencode|4 ++-- vim/README |2 +- vim/plugin/notmuch.vim |4 ++-- 35 files changed, 60 insertions(+), 60 deletions(-) diff --git a/NEWS b/NEWS index 5a1778e..dae7832 100644 --- a/NEWS +++ b/NEWS @@ -112,15 +112,15 @@ Allow for notmuch-fcc-dirs to have a value of nil. string. Instead it's now a list of cons cells where the car of each cell is a regular expression to be matched against the sender address, and the cdr is the name of a folder to use for an FCC. So - the old fallback behavior can be achieved by including a fineal cell + the old fallback behavior can be achieved by including a final cell of (.* . default-fcc-folder). Vim interface improvements -- Felipe Contreras provided a number of updates for the vim interface. - These include optimiations, support for newer versions of vim, fixed - support for sending mail on modern systmms, new commands, and + These include optimizations, support for newer versions of vim, fixed + support for sending mail on modern systems, new commands, and various cleanups. New bindings @@ -606,7 +606,7 @@ Fix to compile against GMime 2.6 Fix configure script to accept (and ignore) various standard options. - For example, those that the gentoo build scripts expect configure to + For example, those that the Gentoo build scripts expect configure to accept are now all accepted. Test suite @@ -714,7 +714,7 @@ tags by region. Selective bulk tagging is now possible by selecting a region of threads and then using either the '+' or '-' keybindings. Bulk tagging is still available for all threads matching the current - search with th '*' binding. + search with the '*' binding. More meaningful buffer names for thread-view buffers. diff --git a/TODO b/TODO index 260ffe1..14dfa55 100644 --- a/TODO +++ b/TODO @@ -29,7 +29,7 @@ Make 'notmuch-show-pipe-message have a private history. Add support for a delete keybinding that adds a deleted tag to the current message/thread and make searches not return deleted messages -by default, (unless the user asks explicitly for deleted messags in +by default, (unless the user asks explicitly for deleted messages in the search query). Add keybindings for next/previous thread. @@ -119,7 +119,7 @@ Allow configuration for filename patterns that should be ignored when indexing. Replace the notmuch part --part=id command with notmuch show ---part=id, (David Edmonson wants to rewrite some of notmuch show to +--part=id, (David Edmondson wants to rewrite some of notmuch show to provide more MIME-structure information in its output first). Replace the notmuch search-tags command with notmuch search diff --git a/compat/README b/compat/README index cd32c56..38e2e14 100644 --- a/compat/README +++ b/compat/README @@ -1,4 +1,4 @@ -notmuch/comapt +notmuch/compat This directory consists of two things: diff --git a/completion/Makefile b/completion/Makefile index b6859ea..de492a7 100644 --- a/completion/Makefile +++ b/completion/Makefile @@ -1,4 +1,4 @@ -# See Makfefile.local for the list of files to be compiled in this +# See Makefile.local for the list of files to be compiled in this # directory. all: $(MAKE) -C .. all diff --git a/configure b/configure index cf525c9..3999ce8 100755 --- a/configure +++ b/configure @@ -22,7 +22,7 @@ if [ $srcdir != . ]; then fi # Set several defaults (optionally specified by the user in -# environemnt variables)
[PATCH] notmuch-new.c infinite recursion symlink bug
If a symlink points to . then there will be an infinite recursion. The
included patch fixes that.
--- notmuch-new.c.orig 2011-06-10 00:03:09.0 -0500
+++ notmuch-new.c 2011-06-10 02:10:37.0 -0500
@@ -233,6 +233,8 @@
struct stat st;
notmuch_bool_t is_maildir, new_directory;
const char **tag;
+char lpath[PATH_MAX], filepath[PATH_MAX];
+size_t len;
if (stat (path, st)) {
fprintf (stderr, Error reading directory %s: %s\n,
@@ -296,6 +298,14 @@
*/
/* XXX: Eventually we'll want more sophistication to let the
* user specify files to be ignored. */
+
+ if (entry-d_type == DT_LNK) {
+ snprintf(filepath, sizeof(filepath), %s/%s, path, entry-d_name);
+ if ((len = readlink(filepath, lpath, sizeof(lpath))) 0)
+ if (strncmp(lpath, ., len-1) == 0)
+ continue;
+ }
+
if (strcmp (entry-d_name, .) == 0 ||
strcmp (entry-d_name, ..) == 0 ||
(is_maildir strcmp (entry-d_name, tmp) == 0) ||
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] notmuch-new.c infinite recursion symlink bug
On 06/10/11 at 02:32P, Taylor Carpenter wrote:
If a symlink points to . then there will be an infinite recursion. The
included patch fixes that.
I did not realize this was needed in the count function as well. New
patch included that does both.
--- notmuch-new.c.orig 2011-06-10 00:03:09.0 -0500
+++ notmuch-new.c 2011-06-10 02:46:18.0 -0500
@@ -233,6 +233,8 @@
struct stat st;
notmuch_bool_t is_maildir, new_directory;
const char **tag;
+char lpath[PATH_MAX], filepath[PATH_MAX];
+size_t len;
if (stat (path, st)) {
fprintf (stderr, Error reading directory %s: %s\n,
@@ -296,6 +298,14 @@
*/
/* XXX: Eventually we'll want more sophistication to let the
* user specify files to be ignored. */
+
+ if (entry-d_type == DT_LNK) {
+ snprintf(filepath, sizeof(filepath), %s/%s, path, entry-d_name);
+ if ((len = readlink(filepath, lpath, sizeof(lpath))) 0)
+ if (strncmp(lpath, ., len-1) == 0)
+ continue;
+ }
+
if (strcmp (entry-d_name, .) == 0 ||
strcmp (entry-d_name, ..) == 0 ||
(is_maildir strcmp (entry-d_name, tmp) == 0) ||
@@ -615,6 +625,8 @@
struct dirent **fs_entries = NULL;
int num_fs_entries = scandir (path, fs_entries, 0, dirent_sort_inode);
int i = 0;
+char lpath[PATH_MAX], filepath[PATH_MAX];
+size_t len;
if (num_fs_entries == -1) {
fprintf (stderr, Warning: failed to open directory %s: %s\n,
@@ -633,6 +645,13 @@
*/
/* XXX: Eventually we'll want more sophistication to let the
* user specify files to be ignored. */
+ if (entry-d_type == DT_LNK) {
+ snprintf(filepath, sizeof(filepath), %s/%s, path, entry-d_name);
+ if ((len = readlink(filepath, lpath, sizeof(lpath))) 0)
+ if (strncmp(lpath, ., len-1) == 0)
+ continue;
+ }
+
if (strcmp (entry-d_name, .) == 0 ||
strcmp (entry-d_name, ..) == 0 ||
strcmp (entry-d_name, .notmuch) == 0)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Turn Turnsole into a generic mail client
Hi William and others, As Turnsole is a great mail interface, I was thinking about having it generic to multiple servers or mail sources, to fit many use cases. Explicitely, the Turnsole::Client class ( https://github.com/wmorgan/turnsole/blob/master/lib/turnsole/client.rb) could be turned into a Turnsole::Client module instead, which implements the necessary abstract methods for the interface, and which needs to be included in every client adapters (like DataMapper adapters are working for instance). Built-in Turnsole adapters would be in lib/turnsole/client/. That way, we could easily implement Turnsole adapters for many sources, such as: Heliotrope (for sure, the official adapter), IMAP (direct connection), Gmail (simpler adapter using the IMAP adapter), Maildir/Mbox, NotMuchMail (which is a great Sup-like email back-end), upasfs, etc. The main reason why I'm posting that, is that I really like the Turnsole ncurses based interface, but sometimes I'd like to check emails directly from imap (when not on my computer for instance). I also know that NotMuch is missing a good ncurses-based client (that's why I've Cc'd them). What do you think? Is there limitations I didn't think about? -- Vivien Didelot, vivien.didelot.org ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Turn Turnsole into a generic mail client
Hi Vivien, Reformatted excerpts from Vivien Didelot's message of 2011-06-19: As Turnsole is a great mail interface, I was thinking about having it generic to multiple servers or mail sources, to fit many use cases. Explicitely, the Turnsole::Client class ( https://github.com/wmorgan/turnsole/blob/master/lib/turnsole/client.rb) could be turned into a Turnsole::Client module instead, The server portion of turnsole, heliotrope, is explicitly designed to support multiple clients and provides a JSON-over-HTTP interface for that purpose. The specifics of the protocol are still subject to change, but see e.g. https://github.com/wmorgan/heliotrope/blob/master/lib/heliotrope-client.rb for the ruby client that turnsole uses to communicate with the server. -- William wmorgan-...@masanjin.net ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: bug in emacs-ui ?
hi, On Mon, Jun 20, 2011 at 9:53 PM, Jameson Graef Rollins jroll...@finestructure.net wrote: On Mon, 20 Jun 2011 18:43:01 +0200, Sebastien Binet seb.bi...@gmail.com wrote: You didn't try forwarding the email to the list ;) ah! that easy, heh ? Attachment: 1300323326_0.6276.farnsworth,U=250482,FMD5=af1cd994dfcb9286c394d142687ff5a0:2,S (application/octet-stream) Hi, Sebastien. I don't seem to have any problems viewing this message with notmuch emacs. Is it possible that the notmuch emacs code you're running is out-of-sync with your notmuch binary? I think that's a common source of problems like this. Make sure that you're pointed to the version of the notmuch emacs libraries that corresponds to your notmuch binary, and that you've restarted your emacs session. Hopefully that will fix things. no joy: $ `which notmuch` --version notmuch 0.5-238-gc39b492 $ pacman -Ql notmuch-git notmuch-git /etc/ notmuch-git /etc/bash_completion.d/ notmuch-git /etc/bash_completion.d/notmuch notmuch-git /usr/ notmuch-git /usr/bin/ notmuch-git /usr/bin/notmuch notmuch-git /usr/include/ notmuch-git /usr/include/notmuch.h notmuch-git /usr/lib/ notmuch-git /usr/lib/libnotmuch.so notmuch-git /usr/lib/libnotmuch.so.1 notmuch-git /usr/lib/libnotmuch.so.1.3.0 notmuch-git /usr/lib/python2.7/ [other python files elided] notmuch-git /usr/share/ notmuch-git /usr/share/emacs/ notmuch-git /usr/share/emacs/site-lisp/ notmuch-git /usr/share/emacs/site-lisp/coolj.el notmuch-git /usr/share/emacs/site-lisp/coolj.elc notmuch-git /usr/share/emacs/site-lisp/notmuch-address.el notmuch-git /usr/share/emacs/site-lisp/notmuch-address.elc notmuch-git /usr/share/emacs/site-lisp/notmuch-crypto.el notmuch-git /usr/share/emacs/site-lisp/notmuch-crypto.elc notmuch-git /usr/share/emacs/site-lisp/notmuch-hello.el notmuch-git /usr/share/emacs/site-lisp/notmuch-hello.elc notmuch-git /usr/share/emacs/site-lisp/notmuch-lib.el notmuch-git /usr/share/emacs/site-lisp/notmuch-lib.elc notmuch-git /usr/share/emacs/site-lisp/notmuch-logo.png notmuch-git /usr/share/emacs/site-lisp/notmuch-maildir-fcc.el notmuch-git /usr/share/emacs/site-lisp/notmuch-maildir-fcc.elc notmuch-git /usr/share/emacs/site-lisp/notmuch-message.el notmuch-git /usr/share/emacs/site-lisp/notmuch-message.elc notmuch-git /usr/share/emacs/site-lisp/notmuch-mua.el notmuch-git /usr/share/emacs/site-lisp/notmuch-mua.elc notmuch-git /usr/share/emacs/site-lisp/notmuch-query.el notmuch-git /usr/share/emacs/site-lisp/notmuch-query.elc notmuch-git /usr/share/emacs/site-lisp/notmuch-show.el notmuch-git /usr/share/emacs/site-lisp/notmuch-show.elc notmuch-git /usr/share/emacs/site-lisp/notmuch-wash.el notmuch-git /usr/share/emacs/site-lisp/notmuch-wash.elc notmuch-git /usr/share/emacs/site-lisp/notmuch.el notmuch-git /usr/share/emacs/site-lisp/notmuch.elc notmuch-git /usr/share/man/ notmuch-git /usr/share/man/man1/ notmuch-git /usr/share/man/man1/notmuch.1.gz notmuch-git /usr/share/vim/ notmuch-git /usr/share/vim/vimfiles/ notmuch-git /usr/share/vim/vimfiles/plugin/ notmuch-git /usr/share/vim/vimfiles/plugin/notmuch.vim notmuch-git /usr/share/vim/vimfiles/syntax/ notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-compose.vim notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-folders.vim notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-git-diff.vim notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-search.vim notmuch-git /usr/share/vim/vimfiles/syntax/notmuch-show.vim notmuch-git /usr/share/zsh/ notmuch-git /usr/share/zsh/functions/ notmuch-git /usr/share/zsh/functions/Completion/ notmuch-git /usr/share/zsh/functions/Completion/Unix/ notmuch-git /usr/share/zsh/functions/Completion/Unix/_notmuch and I checked there were no lingering .el files... so... any way to tell which notmuch-emacs-ui I am actually using ? (I am a newbie when comes to hacking lisp) -s ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
