pkg-config zlib check in 3c13bc
On Thu, May 08 2014, David Bremner wrote:
> Tomi Ollila writes:
>
>>
>> But, I'd like suggest alternate option to create a test c program
>> and test whether it compiles (analogous to what there is already
>> done with many other checks) -- this same would apply to fdatasync()
>> case too.
>>
>
> I agree in principle, but I'm not sure it's detectable at compile time,
> since the option we need is passed as a string (boo!).
>
> I guess the ZLIB_VERNUM hack would be preferable to adding platform
> specific checks to configure. But note you'd need somehow to find
> zlib.h.
Actually my suggestion would be that if that pkg-config line for
zlib does not work (btw why does it not work) try an option
where zlib_cflags is expected to be empty and and zlib_ldflags -lz
-- and try compile and run test program with those options
then the test program is something like
int main(void)
{
return(ZLIB_VERNUM >= 0x1252);
}
(perhaps we could manage the same value in slightly different
formats in 2 tests and remember to update those in sync ..
or we could try:
zv1=1 zv2=2 zv3=5 zv4=
if pkg-config --atleast-version=$zv1.$zv2.$zv3.$zv4 zlib; then
and
return(ZLIB_VERNUM >= 0x$zv1$zv2$zv3$zv4);
>
> d
Tomi
pkg-config zlib check in 3c13bc
David Bremner wrote: > X?c? writes: > > As a side note, is there any rationale for the hand-made configure? Not > > that I am a big fan of autoconf/cmake/whatever either... > > Carl Worth had a lot of (negative) experience with autoconf when he > started the project, which motivated him to roll his own. Personally I > don't really think any of the alternatives are convincingly better than > autoconf. Of course it's one of those very subjective things. I think Makefiles are superior to autoconf. What we have is fine. -- Felipe Contreras
[PATCH] Fallback check for zlib.
---
compat/have_zlib.c | 6 ++
configure | 21 -
2 files changed, 22 insertions(+), 5 deletions(-)
create mode 100644 compat/have_zlib.c
diff --git a/compat/have_zlib.c b/compat/have_zlib.c
new file mode 100644
index 000..998c697
--- /dev/null
+++ b/compat/have_zlib.c
@@ -0,0 +1,6 @@
+#include
+
+int main(void)
+{
+return zlibVersion()[0] != ZLIB_VERSION[0] || ZLIB_VERNUM < MINVER;
+}
diff --git a/configure b/configure
index 9bde2eb..7a11ded 100755
--- a/configure
+++ b/configure
@@ -340,16 +340,27 @@ else
errors=$((errors + 1))
fi
-printf "Checking for zlib (>= 1.2.5.2)... "
+zv1=1 zv2=2 zv3=5 zv4=1
+printf "Checking for zlib (>= $zv1.$zv2.$zv3.$zv4)... "
have_zlib=0
-if pkg-config --atleast-version=1.2.5.2 zlib; then
+if pkg-config --atleast-version=$zv1.$zv2.$zv3.$zv4 zlib; then
printf "Yes.\n"
have_zlib=1
zlib_cflags=$(pkg-config --cflags zlib)
zlib_ldflags=$(pkg-config --libs zlib)
else
-printf "No.\n"
-errors=$((errors + 1))
+# Try finding zlib directly (e.g. on FreeBSD)
+zlib_cflags=
+zlib_ldflags=-lz
+if ${CC} ${zlib_cflags} -DMINVER=0x$zv1$zv2$zv3$zv4 -o compat/have_zlib
"$srcdir"/compat/have_zlib.c ${zlib_ldflags} > /dev/null 2>&1 &&
./compat/have_zlib
+then
+printf "Yes.\n"
+have_zlib=1
+else
+printf "No.\n"
+errors=$((errors + 1))
+fi
+rm -f compat/have_zlib
fi
printf "Checking for talloc development files... "
@@ -509,7 +520,7 @@ EOF
echo " http://xapian.org/";
fi
if [ $have_zlib -eq 0 ]; then
- echo " zlib library (>= version 1.2.5.2, including development files
such as headers)"
+ echo " zlib library (>= version $zv1.$zv2.$zv3.$zv4, including
development files such as headers)"
echo " http://zlib.net/";
echo
fi
--
1.9.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Fallback check for zlib
Added the fallback check for zlib. Tested on FreeBSD stable/10. C test checks for major zlib compatibility (see zlib doc/examples). Xīcò (1): Fallback check for zlib. compat/have_zlib.c | 6 ++ configure | 21 - 2 files changed, 22 insertions(+), 5 deletions(-) create mode 100644 compat/have_zlib.c -- 1.9.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Fallback check for zlib.
---
compat/have_zlib.c | 6 ++
configure | 21 -
2 files changed, 22 insertions(+), 5 deletions(-)
create mode 100644 compat/have_zlib.c
diff --git a/compat/have_zlib.c b/compat/have_zlib.c
new file mode 100644
index 000..998c697
--- /dev/null
+++ b/compat/have_zlib.c
@@ -0,0 +1,6 @@
+#include
+
+int main(void)
+{
+return zlibVersion()[0] != ZLIB_VERSION[0] || ZLIB_VERNUM < MINVER;
+}
diff --git a/configure b/configure
index 9bde2eb..7a11ded 100755
--- a/configure
+++ b/configure
@@ -340,16 +340,27 @@ else
errors=$((errors + 1))
fi
-printf "Checking for zlib (>= 1.2.5.2)... "
+zv1=1 zv2=2 zv3=5 zv4=1
+printf "Checking for zlib (>= $zv1.$zv2.$zv3.$zv4)... "
have_zlib=0
-if pkg-config --atleast-version=1.2.5.2 zlib; then
+if pkg-config --atleast-version=$zv1.$zv2.$zv3.$zv4 zlib; then
printf "Yes.\n"
have_zlib=1
zlib_cflags=$(pkg-config --cflags zlib)
zlib_ldflags=$(pkg-config --libs zlib)
else
-printf "No.\n"
-errors=$((errors + 1))
+# Try finding zlib directly (e.g. on FreeBSD)
+zlib_cflags=
+zlib_ldflags=-lz
+if ${CC} ${zlib_cflags} -DMINVER=0x$zv1$zv2$zv3$zv4 -o compat/have_zlib
"$srcdir"/compat/have_zlib.c ${zlib_ldflags} > /dev/null 2>&1 &&
./compat/have_zlib
+then
+printf "Yes.\n"
+have_zlib=1
+else
+printf "No.\n"
+errors=$((errors + 1))
+fi
+rm -f compat/have_zlib
fi
printf "Checking for talloc development files... "
@@ -509,7 +520,7 @@ EOF
echo " http://xapian.org/";
fi
if [ $have_zlib -eq 0 ]; then
- echo " zlib library (>= version 1.2.5.2, including development files
such as headers)"
+ echo " zlib library (>= version $zv1.$zv2.$zv3.$zv4, including
development files such as headers)"
echo " http://zlib.net/";
echo
fi
--
1.9.2
[PATCH] Fallback check for zlib
Added the fallback check for zlib. Tested on FreeBSD stable/10. C test checks for major zlib compatibility (see zlib doc/examples). X?c? (1): Fallback check for zlib. compat/have_zlib.c | 6 ++ configure | 21 - 2 files changed, 22 insertions(+), 5 deletions(-) create mode 100644 compat/have_zlib.c -- 1.9.2
Re: Github?
On Fri, May 9, 2014 at 6:21 PM, David Bremner wrote: > Felipe Contreras writes: > >> Amadeusz Żołnowski wrote: >>> The same goes for Travis. There's already a build bot. Why bother >>> with Travis? >> >> I've never seen any buildbot results. TravisCI's interface is just >> simple and easy. And all it requires is one file. >> > > Not to take a position on travis at the moment, but just to point out > that buildbot results go to #notmuch on freenode irc. > If you check out my latest patch that I sent, Travis also send notification to both this list and IRC but only on failures or change (failed to pass), please discuss on that thread if this is not desired. > d -- Wael Nasreddine | Software Engineer | wael.nasredd...@gmail.com | (650) 735-1773 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Github?
On Fri, May 9, 2014 at 6:21 PM, David Bremner wrote: > Felipe Contreras writes: > >> Amadeusz ?o?nowski wrote: >>> The same goes for Travis. There's already a build bot. Why bother >>> with Travis? >> >> I've never seen any buildbot results. TravisCI's interface is just >> simple and easy. And all it requires is one file. >> > > Not to take a position on travis at the moment, but just to point out > that buildbot results go to #notmuch on freenode irc. > If you check out my latest patch that I sent, Travis also send notification to both this list and IRC but only on failures or change (failed to pass), please discuss on that thread if this is not desired. > d -- Wael Nasreddine | Software Engineer | wael.nasreddine at gmail.com | (650) 735-1773
Re: pkg-config zlib check in 3c13bc
David Bremner wrote: > Xīcò writes: > > As a side note, is there any rationale for the hand-made configure? Not > > that I am a big fan of autoconf/cmake/whatever either... > > Carl Worth had a lot of (negative) experience with autoconf when he > started the project, which motivated him to roll his own. Personally I > don't really think any of the alternatives are convincingly better than > autoconf. Of course it's one of those very subjective things. I think Makefiles are superior to autoconf. What we have is fine. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: pkg-config zlib check in 3c13bc
Xīcò writes:
> On Sat, May 10, 2014 at 09:46:00AM +0900, David Bremner wrote:
>> > int main(void)
>> > {
>> > return(ZLIB_VERNUM >= 0x1252);
>> > }
>>
>> OK, that sounds like it could work. Ideally, somebody on FreeBSD could
>> check...
>>
>> d
>
> Such check will work on FreeBSD, and would be great!
>
Great. Now somebody just needs to make it.
> As a side note, is there any rationale for the hand-made configure? Not
> that I am a big fan of autoconf/cmake/whatever either...
Carl Worth had a lot of (negative) experience with autoconf when he
started the project, which motivated him to roll his own. Personally I
don't really think any of the alternatives are convincingly better than
autoconf. Of course it's one of those very subjective things.
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: pkg-config zlib check in 3c13bc
On Sat, May 10, 2014 at 09:46:00AM +0900, David Bremner wrote:
> > int main(void)
> > {
> > return(ZLIB_VERNUM >= 0x1252);
> > }
>
> OK, that sounds like it could work. Ideally, somebody on FreeBSD could
> check...
>
> d
Such check will work on FreeBSD, and would be great!
As a side note, is there any rationale for the hand-made configure? Not
that I am a big fan of autoconf/cmake/whatever either...
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
pkg-config zlib check in 3c13bc
On Sat, May 10, 2014 at 09:46:00AM +0900, David Bremner wrote:
> > int main(void)
> > {
> > return(ZLIB_VERNUM >= 0x1252);
> > }
>
> OK, that sounds like it could work. Ideally, somebody on FreeBSD could
> check...
>
> d
Such check will work on FreeBSD, and would be great!
As a side note, is there any rationale for the hand-made configure? Not
that I am a big fan of autoconf/cmake/whatever either...
Re: Github?
Felipe Contreras writes: > Amadeusz Żołnowski wrote: >> The same goes for Travis. There's already a build bot. Why bother >> with Travis? > > I've never seen any buildbot results. TravisCI's interface is just > simple and easy. And all it requires is one file. > Not to take a position on travis at the moment, but just to point out that buildbot results go to #notmuch on freenode irc. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add Travis-CI config file.
On Fri, May 09 2014, "Wael M. Nasreddine" wrote: > --- Could this work so, that there is separate repo whete .travis.yml resides and notmuch is there as a git submodule ? To my eyes this approach looks pretty intrusive: the repository root directory is polluted with specific .travis.yml file and the content is (apparently) specific to https://travis-ci.org/ (some version of ubuntu) That said, I won't be against the inclusion of this in case there are users that like it (provided that a patch with proper commit message(*) is available). Tomi (*) http://notmuchmail.org/contributing/ > .travis.yml | 10 ++ > 1 file changed, 10 insertions(+) > create mode 100644 .travis.yml > > diff --git a/.travis.yml b/.travis.yml > new file mode 100644 > index 000..8d92cdc > --- /dev/null > +++ b/.travis.yml > @@ -0,0 +1,10 @@ > +language: c > +before_install: > + - sudo apt-get update -qq > + - wget > 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb' > + - wget > 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb' > + - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb > zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb > + - sudo apt-get install -f > + - sudo apt-get install dtach libxapian-dev libgmime-2.6-dev libtalloc-dev > python-sphinx > + > +script: make test > -- > 1.9.1.423.g4596e3a
Re: pkg-config zlib check in 3c13bc
Tomi Ollila writes:
>
> Actually my suggestion would be that if that pkg-config line for
> zlib does not work (btw why does it not work)
I guess because FreeBSD (and maybe other systems) have a distinction
between the "base system" and "add on packages" and pkg-config only
works for the latter
> try an option
> where zlib_cflags is expected to be empty and and zlib_ldflags -lz
> -- and try compile and run test program with those options
> then the test program is something like
>
> int main(void)
> {
> return(ZLIB_VERNUM >= 0x1252);
> }
OK, that sounds like it could work. Ideally, somebody on FreeBSD could
check...
d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add Travis-CI config file.
On Fri, May 9, 2014 at 9:35 AM, Felipe Contreras wrote: > Wael M. Nasreddine wrote: >> On Fri, May 9, 2014 at 8:24 AM, Felipe Contreras >> wrote: >> > I had to manually find the build. In case anybody wants to check it out: >> > >> > https://travis-ci.org/notmuch/notmuch/builds >> >> To be specific it's build #2 you see the error right here >> https://travis-ci.org/notmuch/notmuch/builds/24681333#L193 > > Yes, I saw the error. I guess there's no way around that for now. > Unfortunately no, I am waiting for #2046[1] to get resolved and I'll update the .travis.yml accordingly. > -- > Felipe Contreras [1]: https://github.com/travis-ci/travis-ci/issues/2046 -- Wael Nasreddine | Software Engineer | wael.nasreddine at gmail.com | (650) 735-1773 -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140509/7b0478cf/attachment-0001.html>
[RFC PATCH] emacs: show: mark messages unread if seen in buffer
On Fri, May 09 2014, Mark Walters wrote: > To use set notmuch-show-mark-read-function to #'notmuch-show-do-seen I haven't test this function, but I'd expect it to be an option when manipulating `notmuch-show-mark-read-function' using custom.
[RFC PATCH] emacs: show: mark messages unread if seen in buffer
This adds a function that marks messages unread if they are "seen" that is a user configurable amount of them has been visible in the buffer. To use set notmuch-show-mark-read-function to #'notmuch-show-do-seen --- This adds the functionality to do my previous mark unread logic (see id:139593-13297-1-git-send-email-markwalters1009 at gmail.com) as an option. It applies on top of the parent series. This is not intended to be applied as is, but people can see whether they prefer this or the logic introduced in patch 2. I think we might as well include the patch 2 logic as an option regardless as some people will prefer it, and it is very small. This functionality could go in notmuch-show if many people prefer it, it could go in contrib if a rather small number like it, or it could just go on the wiki. Indeed, a user can have this functionality by loading a file with this diffs contents (doesn't need to be in the notmuch tree) and setting notmuch-show-mark-function. Best wishes Mark emacs/notmuch-show.el | 67 + 1 file changed, 67 insertions(+) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 2620f84..3f45830 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1550,6 +1550,73 @@ (defun notmuch-show-mark-read (&optional unread) (apply 'notmuch-show-tag-message (notmuch-tag-change-list notmuch-show-mark-read-tags unread +(defcustom notmuch-show-seen-lines-needed 0.75 + "Control which messages get marked seen. + +A message is marked seen if both the top of the message and a +point far \"enough\" down in the message have each been visible +in the buffer at some point. This parameter controls the +definition of enough. Seeing the bottom of message is always +deemed enough. Additionally, it is deemed enough if a point n +lines into the message has been visible in the window where n is +this variable if this variable is an integer and n is this +variable times the height of the window if this variable is a +float." + :type 'number + :group 'notmuch-show) + +(defun notmuch-show-update-seen (top-or-bottom) + "Update seen status of current message + +Mark that we have seen the TOP-OR-BOTTOM of current message." + (let ((current (notmuch-show-get-prop :seen))) +(unless (or (eq current 'both) (eq current top-or-bottom)) + (if (not current) + (notmuch-show-set-prop :seen top-or-bottom) + (notmuch-show-set-prop :seen 'both) + (notmuch-show-mark-read) + +(defun notmuch-show-do-message-seen (start end) + "Update seen status for the current message. + +A message is seen if both the top and enough of the rest of the +message have been visible in the buffer. Enough means either the +bottom of the message or a point in the message more than +LINES-NEEDED lines into the message. LINES-NEEDED is +`notmuch-show-seen-lines-needed` if that is an integer and that +times the current window height if it is a float." + (let* ((lines-needed (if (integerp notmuch-show-seen-lines-needed) + notmuch-show-seen-lines-needed +(truncate (* notmuch-show-seen-lines-needed (window-body-height) +(top (notmuch-show-message-top)) +(bottom (notmuch-show-message-bottom))) +(when (notmuch-show-message-visible-p) + (when (>= top start) + (notmuch-show-update-seen 'top)) + (when (or (<= bottom end) + (> (count-screen-lines top end) lines-needed)) + (notmuch-show-update-seen 'bottom) + +(defun notmuch-show-do-seen (start end) + "Update seen status for all messages between start and end. + +We mark the top (bottom) of a message seen if the top (enough of +the rest of the message) respectively have been visible in the +buffer. See `notmuch-show-do-message-seen` for the definition of +enough. When both the top and bottom have been seen we mark the +message read." + (save-excursion +(goto-char start) +(notmuch-show-do-message-seen start end) +(while (and (< (notmuch-show-message-bottom) end) + (notmuch-show-goto-message-next)) + (notmuch-show-do-message-seen start end)) +;; This is a work around because emacs gives weird answers for +;; window-end if the buffer ends with invisible text. +(when (and (pos-visible-in-window-p (point-max)) + (notmuch-show-message-visible-p)) + (notmuch-show-update-seen 'bottom + (defun notmuch-show-seen-current-message (start end) "Mark the current message read if it is open. -- 1.7.10.4
[PATCH] Add Travis-CI config file.
On 05/09/2014 11:19 AM, Wael M. Nasreddine wrote: > --- > .travis.yml | 10 ++ > 1 file changed, 10 insertions(+) > create mode 100644 .travis.yml > > diff --git a/.travis.yml b/.travis.yml > new file mode 100644 > index 000..8d92cdc > --- /dev/null > +++ b/.travis.yml > @@ -0,0 +1,10 @@ > +language: c > +before_install: > + - sudo apt-get update -qq > + - wget > 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb' > + - wget > 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb' > + - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb > zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb The above strikes me as a problem waiting to happen. If there are specific versions of zlib that need to be installed, and we know what the package is that needs to be installed, at the very least, the scripts to fetch each package should verify a strong cryptographic digest of the package before directly installing it from the network. if the digest doesn't match, then the script should abort with a failure, before installing the packages. --dkg -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140509/6d480033/attachment.pgp>
[PATCH v1 0/3] emacs: Allow saving of threads and messages
On Fri, May 09 2014, Mark Walters wrote: > The first two patches are fine, although I think I like constructing a > query then quoting rather than quoting bits of a query and bolting them > together (even the both work). Agreed. I've no idea what I was thinking. > My concern is that the current approach gives the user no warning if > they are about to overwrite an existing file, and that this is true > regardless of any emacs settings. > > Could we do these saves by loading into a temporary buffer and then > using the normal emacs save buffer functions? That way we get the > benefit of emacs's normal query-overwrite, and respect any user > customizations of that. Yes, that is a better approach. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 310 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140509/c9427931/attachment.pgp>
[PATCH] Add Travis-CI config file.
On Travis Zlib is old and notmuch configure script exits with a failure, please see the Travis build #1 On Friday, May 9, 2014 7:52:44 AM, Felipe Contreras < felipe.contreras at gmail.com> wrote: > Wael M. Nasreddine wrote: > > --- > > .travis.yml | 10 ++ > > 1 file changed, 10 insertions(+) > > create mode 100644 .travis.yml > > > > diff --git a/.travis.yml b/.travis.yml > > new file mode 100644 > > index 000..8d92cdc > > --- /dev/null > > +++ b/.travis.yml > > @@ -0,0 +1,10 @@ > > +language: c > > +before_install: > > + - sudo apt-get update -qq > > + - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/ > zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb' > > + - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/ > zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb' > > + - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb > zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb > > What's wrong with zlib? > > > + - sudo apt-get install -f > > + - sudo apt-get install dtach libxapian-dev libgmime-2.6-dev > libtalloc-dev python-sphinx > > + > > +script: make test > > -- > Felipe Contreras > -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140509/4e359687/attachment.html>
Submodules for language bindings (was: Github?)
On Fri, May 09, 2014 at 07:40:27AM -0500, Felipe Contreras wrote:
> Suvayu Ali wrote:
>
> > To explain my point with RPM specifics, if I were to
> > use separate spec files, python-notmuch would have:
> >
> > Requires: notmuch >=
> >
> > As you can see this only allows for tracking dependency based on
> > official version numbers. With more bindings, many with different
> > version dependencies, this becomes quite cumbersome;
>
> No, it doesn't:
>
> %package notmuch-ruby
> Requires: notmuch = %{version}-%{release}, ruby
Doesn't that work when you have one spec file for all sub-packages (as I
do now)? I was responding to Trevor's suggestion about not having
sub-packages, IOW, different spec files for different packages.
--
Suvayu
Open source is the future. It sets us free.
Github?
Hi, Wael Nasreddine writes: > I was a bit disappointed that the project is not living (or at least > mirrored) to Github, it would have made my search much easier. How GitHub would help with this? I believe that most of search engines reach Notmuch home page. GitHub is not the center of the world. I have a GitHub account, too and I use it to host some stuff, but I have never given a single thought about encouraging project I use or contribute to to move/mirror on GitHub just because I use it. The same goes for Travis. There's already a build bot. Why bother with Travis? I wonder when a next person is going to be _disappointed_ that there's no mirror on Bitbucket, or that he/she couldn't find Notmuch on Facebook/Google+/whatever... This can be a never ending story. Just my 0.02 PLN. Best regards, -- Amadeusz ?o?nowski -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 489 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140509/3157ffb4/attachment.pgp>
Re: [PATCH] Add Travis-CI config file.
On 05/09/2014 11:19 AM, Wael M. Nasreddine wrote: > --- > .travis.yml | 10 ++ > 1 file changed, 10 insertions(+) > create mode 100644 .travis.yml > > diff --git a/.travis.yml b/.travis.yml > new file mode 100644 > index 000..8d92cdc > --- /dev/null > +++ b/.travis.yml > @@ -0,0 +1,10 @@ > +language: c > +before_install: > + - sudo apt-get update -qq > + - wget > 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb' > + - wget > 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb' > + - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb > zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb The above strikes me as a problem waiting to happen. If there are specific versions of zlib that need to be installed, and we know what the package is that needs to be installed, at the very least, the scripts to fetch each package should verify a strong cryptographic digest of the package before directly installing it from the network. if the digest doesn't match, then the script should abort with a failure, before installing the packages. --dkg signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v4 0/2] emacs: show: redesign unread/read logic
On Fri, May 09 2014, Mark Walters wrote: >> Just to confirm: you can get your desired behaviour by writing an >> alternative `notmuch-show-mark-read-function'? > > Yes I can confirm that. So if this went in I can get the behaviour of > the earlier series without needing to patch notmuch. > > We can decide later if we want to include it (and other possible mark > read functions) as an option, or as a contrib file, or just on the > wiki. I think that it would be convenient to include a function that implements your preferred behaviour so that others can decide how they would like it to behave. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 310 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140509/07794693/attachment.pgp>
Submodules for language bindings (was: Github?)
Hi Trevor, On Thu, May 08, 2014 at 04:35:30PM -0700, W. Trevor King wrote: > On Fri, May 09, 2014 at 12:45:27AM +0200, Suvayu Ali wrote: > > On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote: > > > On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote: > > > > One of my TODOs is to also package the ruby bindings, and > > > > notmuch-vim. The only thing preventing me now is my > > > > unfamiliarty with ruby, and Fedora packaging guidelines for > > > > ruby-gems. > > > > > > I think this is one argument argument in favor of submodules, > > > because they make it easy to treat the bindings as separate > > > packages. Once you have separate packages, it's easy to delegate > > > packaging (e.g. ?I don't use the Ruby bindings, so I'm not going > > > to maintain the Ruby-binding package. I'll leave that to Alice, > > > who likes Ruby, but is less familiar with $distro's Python > > > packaging?). > > > > Well as far as my understanding of rpm goes, sub-packages are > > prefered here rather than independent packages. I believe the > > reason is again easier dependency tracking[1]; all sub-packages > > share the same source rpm, so no explicit `Requires' in the spec > > file. > > It looks like sub-packages share a single spec file with the main > package [1]. That means you'll have to have authors with the full > range of binding-language expertise to bump that spec file (assuming > there are any changes that require bumps). For example, Gentoo's > Python eclasses have gone through a few revisions in the last year or > two, and I wouldn't expect one person to stay on top of the latest > packaging styles for every language with notmuch bindings. I think > the benefit of having separate packages (and spec files, or ebuilds, > or whatever) is that you can release notmuch-0.18 without worrying > about all those bindings, and leave it to the other maintainers (who > might include you) to independently package notmuch-python-0.18, > notmuch-ruby-0.18, notmuch-go-0.18, ?. With only three sets of > bindings, it doesn't really matter, but I think you'll want the weaker > coupling of stand-alone packages by the time you hit a dozen > languages. ?Bump an explicit 'Requires'? certainly seems like a lower > barrier than ?package Go bindings idiomatically for Fedora? ;). You have a point, however I would still disagree. You seem to use Gentoo, and I think what you say works better for Gentoo because it is a source distribution. For binary distributions, this is a bit harder (and limiting). To explain my point with RPM specifics, if I were to use separate spec files, python-notmuch would have: Requires: notmuch >= As you can see this only allows for tracking dependency based on official version numbers. With more bindings, many with different version dependencies, this becomes quite cumbersome; more so when you are doing snapshots (as I do for my repo[1]). As a packager, I think I would prefer to learn different packaging guidelines, setup my spec file and forget about it rather than continually follow all changes. But I guess this is where you would argue with different responsible people, I would not have to do all the thinking :-p. Anyway, whichever way the devs choose to go, I (and other packagers) will adapt. Cheers, Footnotes: [1] I would love to know if anyone here uses it. I announced it here when I started it, but for all I know I could be the only user! :-p -- Suvayu Open source is the future. It sets us free.
[PATCH v1 0/3] emacs: Allow saving of threads and messages
Hi
I think the functionality is well worth having ("|" cat - > a-file is
ugly!). However, I am not sure about this approach.
The first two patches are fine, although I think I like constructing a
query then quoting rather than quoting bits of a query and bolting them
together (even the both work).
My concern is that the current approach gives the user no warning if
they are about to overwrite an existing file, and that this is true
regardless of any emacs settings.
Could we do these saves by loading into a temporary buffer and then
using the normal emacs save buffer functions? That way we get the
benefit of emacs's normal query-overwrite, and respect any user
customizations of that.
The only potential problem is to make sure we don't do any accidental
charset conversion. I guess this functionality is probably easy to test
at least!
Best wishes
Mark
On Fri, 09 May 2014, David Edmondson wrote:
> emacs: Allow saving of threads and messages
>
> Similar to the pipe (|) support, allow saving of threads and messages.
>
>
> David Edmondson (3):
> emacs: Fix indentation.
> emacs: Minor re-work of `notmuch-show-pipe-message'
> emacs: Add `notmuch-show-save-message' to save messages
>
> emacs/notmuch-show.el | 161
> --
> 1 file changed, 91 insertions(+), 70 deletions(-)
>
> --
> 2.0.0.rc0
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
Re: pkg-config zlib check in 3c13bc
On Thu, May 08 2014, David Bremner wrote:
> Tomi Ollila writes:
>
>>
>> But, I'd like suggest alternate option to create a test c program
>> and test whether it compiles (analogous to what there is already
>> done with many other checks) -- this same would apply to fdatasync()
>> case too.
>>
>
> I agree in principle, but I'm not sure it's detectable at compile time,
> since the option we need is passed as a string (boo!).
>
> I guess the ZLIB_VERNUM hack would be preferable to adding platform
> specific checks to configure. But note you'd need somehow to find
> zlib.h.
Actually my suggestion would be that if that pkg-config line for
zlib does not work (btw why does it not work) try an option
where zlib_cflags is expected to be empty and and zlib_ldflags -lz
-- and try compile and run test program with those options
then the test program is something like
int main(void)
{
return(ZLIB_VERNUM >= 0x1252);
}
(perhaps we could manage the same value in slightly different
formats in 2 tests and remember to update those in sync ..
or we could try:
zv1=1 zv2=2 zv3=5 zv4=
if pkg-config --atleast-version=$zv1.$zv2.$zv3.$zv4 zlib; then
and
return(ZLIB_VERNUM >= 0x$zv1$zv2$zv3$zv4);
>
> d
Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: folder and path completely broken in HEAD?
On Sat, May 03 2014, dm-list-email-notm...@scs.stanford.edu wrote: > First, are there people out there who do not use a collection of maildir > directories, with all mail in cur and new? o/ I completely abandoned the usage of separate mail "folders" since I started using notmuch. All my mail now just goes into a single maildir. I consider this one of notmuch's awesome features. It's honestly been a bit perplexing to me that folks have put so much work into parsing/indexing paths and folders given that it seems to me that notmuch has utterly obviated the need to worry about such things (thank god!). jamie. pgpRJXuRxDyWc.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
folder and path completely broken in HEAD?
On Sat, May 03 2014, dm-list-email-notmuch at scs.stanford.edu wrote: > First, are there people out there who do not use a collection of maildir > directories, with all mail in cur and new? o/ I completely abandoned the usage of separate mail "folders" since I started using notmuch. All my mail now just goes into a single maildir. I consider this one of notmuch's awesome features. It's honestly been a bit perplexing to me that folks have put so much work into parsing/indexing paths and folders given that it seems to me that notmuch has utterly obviated the need to worry about such things (thank god!). jamie. -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 818 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140509/868729c7/attachment.pgp>
Log of tagging actions
On Fri, May 09 2014, Istvan Marko wrote: > Sebastian Fischmeister writes: > >> Is there a possibility to log all tagging actions done in notmuch? > > I use a shell wrapper around notmuch to get this: > > #! /bin/sh > echo "notmuch $@" >>$HOME/logs/notmuch.log > /usr/local/bin/notmuch "$@" You could make the last line 'exec /usr/local/bin/notmuch "$@"' :D (and if you use debian, #!/bin/dash...) I use a C wrapper to do the same (with date prefixes like 2014-05-09 (Fri) 12:47:19) -- I originally did it to do argument conversions around .. to have date-based searches before those came to notmuch (and I am still using it, as I don't have to type date: prefix) > Would be nice to be able to log all operations done via libnotmuch too > though. IIRC someone suggested/asked whether we'd get logs where all Message-ID:s affected were logged. That could be useful (and produce lot of log when one does notmuch tag +foobar '*') That means to do logging with this granularity may prove problematic... > -- > Istvan Tomi
[PATCH v4 0/2] emacs: show: redesign unread/read logic
On Fri, 09 May 2014, David Edmondson wrote: > On Fri, May 09 2014, Mark Walters wrote: >> This is v4 of this set. v3 is at >> id:139593-13297-1-git-send-email-markwalters1009 at gmail.com >> >> David (dme) was not keen on the logic in the previous patch so I have >> tried to make it rather more customisable and made this version much >> closer to the existing logic. >> >> This version marks the current message read if it is open. It doesn't >> care how you get there: whether it is notmuch commands n/N/p/P next >> message etc, emacs commands like scroll up, mouse clicks etc. >> >> The only proviso is it will only mark a message read once (in a single >> buffer and between refreshes) as otherwise it is impossible for a user >> to choose to mark a message unread. > > This version looks good to me, thanks for considering the feedback. Hi Thanks for looking and testing. >> I, personally, like my previous logic much more. But with this setup >> that can be customized easily in my .emacs (we may choose to add other >> options into mainline later). Also I think this series fixes all of >> the problems with the current read/unread logic mentioned in >> id:87a9atmpkf.fsf at qmul.ac.uk are fixed. > > Just to confirm: you can get your desired behaviour by writing an > alternative `notmuch-show-mark-read-function'? Yes I can confirm that. So if this went in I can get the behaviour of the earlier series without needing to patch notmuch. We can decide later if we want to include it (and other possible mark read functions) as an option, or as a contrib file, or just on the wiki. Best wishes Mark
[PATCH] Add Travis-CI config file.
Wael M. Nasreddine wrote: > On Fri, May 9, 2014 at 8:24 AM, Felipe Contreras > wrote: > > I had to manually find the build. In case anybody wants to check it out: > > > > https://travis-ci.org/notmuch/notmuch/builds > > To be specific it's build #2 you see the error right here > https://travis-ci.org/notmuch/notmuch/builds/24681333#L193 Yes, I saw the error. I guess there's no way around that for now. -- Felipe Contreras
[PATCH] Add Travis-CI config file.
Wael Nasreddine wrote: > On Travis Zlib is old and notmuch configure script exits with a > failure, please see the Travis build #1 Please do not top-post. I had to manually find the build. In case anybody wants to check it out: https://travis-ci.org/notmuch/notmuch/builds -- Felipe Contreras
Re: [PATCH] Add Travis-CI config file.
On Fri, May 9, 2014 at 9:35 AM, Felipe Contreras wrote: > Wael M. Nasreddine wrote: >> On Fri, May 9, 2014 at 8:24 AM, Felipe Contreras >> wrote: >> > I had to manually find the build. In case anybody wants to check it out: >> > >> > https://travis-ci.org/notmuch/notmuch/builds >> >> To be specific it's build #2 you see the error right here >> https://travis-ci.org/notmuch/notmuch/builds/24681333#L193 > > Yes, I saw the error. I guess there's no way around that for now. > Unfortunately no, I am waiting for #2046[1] to get resolved and I'll update the .travis.yml accordingly. > -- > Felipe Contreras [1]: https://github.com/travis-ci/travis-ci/issues/2046 -- Wael Nasreddine | Software Engineer | wael.nasredd...@gmail.com | (650) 735-1773 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add Travis-CI config file.
Wael M. Nasreddine wrote: > --- > .travis.yml | 10 ++ > 1 file changed, 10 insertions(+) > create mode 100644 .travis.yml > > diff --git a/.travis.yml b/.travis.yml > new file mode 100644 > index 000..8d92cdc > --- /dev/null > +++ b/.travis.yml > @@ -0,0 +1,10 @@ > +language: c > +before_install: > + - sudo apt-get update -qq > + - wget > 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb' > + - wget > 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb' > + - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb > zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb What's wrong with zlib? > + - sudo apt-get install -f > + - sudo apt-get install dtach libxapian-dev libgmime-2.6-dev libtalloc-dev > python-sphinx > + > +script: make test -- Felipe Contreras
Re: [PATCH] Add Travis-CI config file.
Wael M. Nasreddine wrote: > On Fri, May 9, 2014 at 8:24 AM, Felipe Contreras > wrote: > > I had to manually find the build. In case anybody wants to check it out: > > > > https://travis-ci.org/notmuch/notmuch/builds > > To be specific it's build #2 you see the error right here > https://travis-ci.org/notmuch/notmuch/builds/24681333#L193 Yes, I saw the error. I guess there's no way around that for now. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v4 0/2] emacs: show: redesign unread/read logic
On Fri, May 09 2014, Mark Walters wrote: > This is v4 of this set. v3 is at > id:139593-13297-1-git-send-email-markwalters1009 at gmail.com > > David (dme) was not keen on the logic in the previous patch so I have > tried to make it rather more customisable and made this version much > closer to the existing logic. > > This version marks the current message read if it is open. It doesn't > care how you get there: whether it is notmuch commands n/N/p/P next > message etc, emacs commands like scroll up, mouse clicks etc. > > The only proviso is it will only mark a message read once (in a single > buffer and between refreshes) as otherwise it is impossible for a user > to choose to mark a message unread. This version looks good to me, thanks for considering the feedback. > I, personally, like my previous logic much more. But with this setup > that can be customized easily in my .emacs (we may choose to add other > options into mainline later). Also I think this series fixes all of > the problems with the current read/unread logic mentioned in > id:87a9atmpkf.fsf at qmul.ac.uk are fixed. Just to confirm: you can get your desired behaviour by writing an alternative `notmuch-show-mark-read-function'? -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 310 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140509/84a15507/attachment.pgp>
[PATCH v1 3/3] emacs: Add `notmuch-show-save-message' to save messages
Following `notmuch-show-pipe-message', add a binding 'S' to save either the current or all open messages, depending on prefix argument. --- emacs/notmuch-show.el | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 62c0be6..851e968 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1285,6 +1285,7 @@ reset based on the original query." (define-key map "f" 'notmuch-show-forward-message) (define-key map "r" 'notmuch-show-reply-sender) (define-key map "R" 'notmuch-show-reply) +(define-key map "S" 'notmuch-show-save-message) (define-key map "|" 'notmuch-show-pipe-message) (define-key map "w" 'notmuch-show-save-attachments) (define-key map "V" 'notmuch-show-view-raw-message) @@ -1769,6 +1770,24 @@ to show, nil otherwise." (set-buffer-modified-p nil) (view-buffer buf 'kill-buffer-if-not-modified))) +(put 'notmuch-show-save-message 'notmuch-doc + "Save the contents of the current message to a file.") +(put 'notmuch-show-save-message 'notmuch-prefix-doc + "Save the thread as an mbox to a file.") +(defun notmuch-show-save-message (entire-thread file) + "Save the contents of the current message (or thread) to FILE. + +If ENTIRE-THREAD is non-nil (or when invoked with a prefix +argument), FILE will contain all open messages in the current +thread (formatted as an mbox) rather than only the current +message." + (interactive (let ((prompt (if current-prefix-arg +"Save all open messages to file: " + "Save message to command: "))) +(list current-prefix-arg (read-file-name prompt + + (notmuch-show-pipe-message-internal entire-thread (concat " > " file))) + (put 'notmuch-show-pipe-message 'notmuch-doc "Pipe the contents of the current message to a command.") (put 'notmuch-show-pipe-message 'notmuch-prefix-doc @@ -1789,6 +1808,9 @@ message." "Pipe message to command: "))) (list current-prefix-arg (read-string prompt + (notmuch-show-pipe-message-internal entire-thread (concat " | " command))) + +(defun notmuch-show-pipe-message-internal (entire-thread command-tail) (let ((shell-command (concat notmuch-command " show" (if entire-thread @@ -1796,7 +1818,7 @@ message." (mapconcat #'shell-quote-argument (notmuch-show-get-message-ids-for-open-messages) " OR ")) (concat " --format=raw " (shell-quote-argument (notmuch-show-get-message-id -" | " command)) +command-tail)) (cwd default-directory) (buf (get-buffer-create (concat "*notmuch-pipe*" (with-current-buffer buf -- 2.0.0.rc0
[PATCH v1 2/3] emacs: Minor re-work of `notmuch-show-pipe-message'
Stylistic only - no functional change. --- emacs/notmuch-show.el | 59 +-- 1 file changed, 29 insertions(+), 30 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 2ed221a..62c0be6 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1784,36 +1784,35 @@ If ENTIRE-THREAD is non-nil (or when invoked with a prefix argument), COMMAND will receive all open messages in the current thread (formatted as an mbox) rather than only the current message." - (interactive (let ((query-string (if current-prefix-arg - "Pipe all open messages to command: " -"Pipe message to command: "))) -(list current-prefix-arg (read-string query-string - (let (shell-command) -(if entire-thread - (setq shell-command - (concat notmuch-command " show --format=mbox --exclude=false " - (shell-quote-argument - (mapconcat 'identity (notmuch-show-get-message-ids-for-open-messages) " OR ")) - " | " command)) - (setq shell-command - (concat notmuch-command " show --format=raw " - (shell-quote-argument (notmuch-show-get-message-id)) " | " command))) -(let ((cwd default-directory) - (buf (get-buffer-create (concat "*notmuch-pipe*" - (with-current-buffer buf - (setq buffer-read-only nil) - (erase-buffer) - ;; Use the originating buffer's working directory instead of - ;; that of the pipe buffer. - (cd cwd) - (let ((exit-code (call-process-shell-command shell-command nil buf))) - (goto-char (point-max)) - (set-buffer-modified-p nil) - (setq buffer-read-only t) - (unless (zerop exit-code) - (switch-to-buffer-other-window buf) - (message (format "Command '%s' exited abnormally with code %d" -shell-command exit-code + (interactive (let ((prompt (if current-prefix-arg +"Pipe all open messages to command: " + "Pipe message to command: "))) +(list current-prefix-arg (read-string prompt + + (let ((shell-command +(concat notmuch-command " show" +(if entire-thread +(concat " --format=mbox --exclude=false " +(mapconcat #'shell-quote-argument (notmuch-show-get-message-ids-for-open-messages) " OR ")) + (concat " --format=raw " + (shell-quote-argument (notmuch-show-get-message-id +" | " command)) + (cwd default-directory) + (buf (get-buffer-create (concat "*notmuch-pipe*" +(with-current-buffer buf + (setq buffer-read-only nil) + (erase-buffer) + ;; Use the originating buffer's working directory instead of + ;; that of the pipe buffer. + (cd cwd) + (let ((exit-code (call-process-shell-command shell-command nil buf))) + (goto-char (point-max)) + (set-buffer-modified-p nil) + (setq buffer-read-only t) + (unless (zerop exit-code) + (switch-to-buffer-other-window buf) + (message (format "Command '%s' exited abnormally with code %d" + shell-command exit-code))) (defun notmuch-show-tag-message (&rest tag-changes) "Change tags for the current message. -- 2.0.0.rc0
[PATCH v1 1/3] emacs: Fix indentation.
Fix the indentation of `notmuch-show-mode-map'. --- emacs/notmuch-show.el | 80 +-- 1 file changed, 40 insertions(+), 40 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 10fc872..2ed221a 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1275,46 +1275,46 @@ reset based on the original query." (fset 'notmuch-show-part-map notmuch-show-part-map) (defvar notmuch-show-mode-map - (let ((map (make-sparse-keymap))) - (set-keymap-parent map notmuch-common-keymap) - (define-key map "Z" 'notmuch-tree-from-show-current-query) - (define-key map (kbd "") 'widget-backward) - (define-key map (kbd "M-TAB") 'notmuch-show-previous-button) - (define-key map (kbd "") 'notmuch-show-previous-button) - (define-key map (kbd "TAB") 'notmuch-show-next-button) - (define-key map "f" 'notmuch-show-forward-message) - (define-key map "r" 'notmuch-show-reply-sender) - (define-key map "R" 'notmuch-show-reply) - (define-key map "|" 'notmuch-show-pipe-message) - (define-key map "w" 'notmuch-show-save-attachments) - (define-key map "V" 'notmuch-show-view-raw-message) - (define-key map "c" 'notmuch-show-stash-map) - (define-key map "h" 'notmuch-show-toggle-visibility-headers) - (define-key map "*" 'notmuch-show-tag-all) - (define-key map "-" 'notmuch-show-remove-tag) - (define-key map "+" 'notmuch-show-add-tag) - (define-key map "X" 'notmuch-show-archive-thread-then-exit) - (define-key map "x" 'notmuch-show-archive-message-then-next-or-exit) - (define-key map "A" 'notmuch-show-archive-thread-then-next) - (define-key map "a" 'notmuch-show-archive-message-then-next-or-next-thread) - (define-key map "N" 'notmuch-show-next-message) - (define-key map "P" 'notmuch-show-previous-message) - (define-key map "n" 'notmuch-show-next-open-message) - (define-key map "p" 'notmuch-show-previous-open-message) - (define-key map (kbd "M-n") 'notmuch-show-next-thread-show) - (define-key map (kbd "M-p") 'notmuch-show-previous-thread-show) - (define-key map (kbd "DEL") 'notmuch-show-rewind) - (define-key map " " 'notmuch-show-advance-and-archive) - (define-key map (kbd "M-RET") 'notmuch-show-open-or-close-all) - (define-key map (kbd "RET") 'notmuch-show-toggle-message) - (define-key map "#" 'notmuch-show-print-message) - (define-key map "!" 'notmuch-show-toggle-elide-non-matching) - (define-key map "$" 'notmuch-show-toggle-process-crypto) - (define-key map "<" 'notmuch-show-toggle-thread-indentation) - (define-key map "t" 'toggle-truncate-lines) - (define-key map "." 'notmuch-show-part-map) - map) - "Keymap for \"notmuch show\" buffers.") + (let ((map (make-sparse-keymap))) +(set-keymap-parent map notmuch-common-keymap) +(define-key map "Z" 'notmuch-tree-from-show-current-query) +(define-key map (kbd "") 'widget-backward) +(define-key map (kbd "M-TAB") 'notmuch-show-previous-button) +(define-key map (kbd "") 'notmuch-show-previous-button) +(define-key map (kbd "TAB") 'notmuch-show-next-button) +(define-key map "f" 'notmuch-show-forward-message) +(define-key map "r" 'notmuch-show-reply-sender) +(define-key map "R" 'notmuch-show-reply) +(define-key map "|" 'notmuch-show-pipe-message) +(define-key map "w" 'notmuch-show-save-attachments) +(define-key map "V" 'notmuch-show-view-raw-message) +(define-key map "c" 'notmuch-show-stash-map) +(define-key map "h" 'notmuch-show-toggle-visibility-headers) +(define-key map "*" 'notmuch-show-tag-all) +(define-key map "-" 'notmuch-show-remove-tag) +(define-key map "+" 'notmuch-show-add-tag) +(define-key map "X" 'notmuch-show-archive-thread-then-exit) +(define-key map "x" 'notmuch-show-archive-message-then-next-or-exit) +(define-key map "A" 'notmuch-show-archive-thread-then-next) +(define-key map "a" 'notmuch-show-archive-message-then-next-or-next-thread) +(define-key map "N" 'notmuch-show-next-message) +(define-key map "P" 'notmuch-show-previous-message) +(define-key map "n" 'notmuch-show-next-open-message) +(define-key map "p" 'notmuch-show-previous-open-message) +(define-key map (kbd "M-n") 'notmuch-show-next-thread-show) +(define-key map (kbd "M-p") 'notmuch-show-previous-thread-show) +(define-key map (kbd "DEL") 'notmuch-show-rewind) +(define-key map " " 'notmuch-show-advance-and-archive) +(define-key map (kbd "M-RET") 'notmuch-show-open-or-close-all) +(define-key map (kbd "RET") 'notmuch-show-toggle-message) +(define-key map "#" 'notmuch-show-print-message) +(define-key map "!" 'notmuch-show-toggle-elide-non-matching) +(define-key map "$" 'notmuch-show-toggle-process-crypto) +(define-key map "<" 'notmuch-show-toggle-thread-indentation) +(define-key map
[PATCH v1 0/3] emacs: Allow saving of threads and messages
emacs: Allow saving of threads and messages Similar to the pipe (|) support, allow saving of threads and messages. David Edmondson (3): emacs: Fix indentation. emacs: Minor re-work of `notmuch-show-pipe-message' emacs: Add `notmuch-show-save-message' to save messages emacs/notmuch-show.el | 161 -- 1 file changed, 91 insertions(+), 70 deletions(-) -- 2.0.0.rc0
Re: [PATCH] Add Travis-CI config file.
On Fri, May 09, 2014 at 02:59:02PM +, Wael Nasreddine wrote: > On Travis Zlib is old and notmuch configure script exits with a > failure, please see the Travis build #1 I'm just dropping a cross-link to the recent old-zlib discussion here [1]. Cheers, Trevor [1]: id:1397809386-23356-1-git-send-email-tomi.oll...@iki.fi http://thread.gmane.org/gmane.mail.notmuch.general/17910/focus=17916 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add Travis-CI config file.
On Fri, May 09, 2014 at 02:59:02PM +, Wael Nasreddine wrote: > On Travis Zlib is old and notmuch configure script exits with a > failure, please see the Travis build #1 I'm just dropping a cross-link to the recent old-zlib discussion here [1]. Cheers, Trevor [1]: id:1397809386-23356-1-git-send-email-tomi.ollila at iki.fi http://thread.gmane.org/gmane.mail.notmuch.general/17910/focus=17916 -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140509/c83677d9/attachment.pgp>
Re: [RFC PATCH] emacs: show: mark messages unread if seen in buffer
On Fri, May 09 2014, Mark Walters wrote: > To use set notmuch-show-mark-read-function to #'notmuch-show-do-seen I haven't test this function, but I'd expect it to be an option when manipulating `notmuch-show-mark-read-function' using custom. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add Travis-CI config file.
On Fri, May 9, 2014 at 8:24 AM, Felipe Contreras wrote: > Wael Nasreddine wrote: >> On Travis Zlib is old and notmuch configure script exits with a >> failure, please see the Travis build #1 > > Please do not top-post. Apologies for that, I was dropping off my son at school and I replied from my phone. > > I had to manually find the build. In case anybody wants to check it out: > > https://travis-ci.org/notmuch/notmuch/builds To be specific it's build #2 you see the error right here https://travis-ci.org/notmuch/notmuch/builds/24681333#L193 > > -- > Felipe Contreras -- Wael Nasreddine | Software Engineer | wael.nasredd...@gmail.com | (650) 735-1773 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[RFC PATCH] emacs: show: mark messages unread if seen in buffer
This adds a function that marks messages unread if they are "seen" that is a user configurable amount of them has been visible in the buffer. To use set notmuch-show-mark-read-function to #'notmuch-show-do-seen --- This adds the functionality to do my previous mark unread logic (see id:139593-13297-1-git-send-email-markwalters1...@gmail.com) as an option. It applies on top of the parent series. This is not intended to be applied as is, but people can see whether they prefer this or the logic introduced in patch 2. I think we might as well include the patch 2 logic as an option regardless as some people will prefer it, and it is very small. This functionality could go in notmuch-show if many people prefer it, it could go in contrib if a rather small number like it, or it could just go on the wiki. Indeed, a user can have this functionality by loading a file with this diffs contents (doesn't need to be in the notmuch tree) and setting notmuch-show-mark-function. Best wishes Mark emacs/notmuch-show.el | 67 + 1 file changed, 67 insertions(+) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 2620f84..3f45830 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1550,6 +1550,73 @@ (defun notmuch-show-mark-read (&optional unread) (apply 'notmuch-show-tag-message (notmuch-tag-change-list notmuch-show-mark-read-tags unread +(defcustom notmuch-show-seen-lines-needed 0.75 + "Control which messages get marked seen. + +A message is marked seen if both the top of the message and a +point far \"enough\" down in the message have each been visible +in the buffer at some point. This parameter controls the +definition of enough. Seeing the bottom of message is always +deemed enough. Additionally, it is deemed enough if a point n +lines into the message has been visible in the window where n is +this variable if this variable is an integer and n is this +variable times the height of the window if this variable is a +float." + :type 'number + :group 'notmuch-show) + +(defun notmuch-show-update-seen (top-or-bottom) + "Update seen status of current message + +Mark that we have seen the TOP-OR-BOTTOM of current message." + (let ((current (notmuch-show-get-prop :seen))) +(unless (or (eq current 'both) (eq current top-or-bottom)) + (if (not current) + (notmuch-show-set-prop :seen top-or-bottom) + (notmuch-show-set-prop :seen 'both) + (notmuch-show-mark-read) + +(defun notmuch-show-do-message-seen (start end) + "Update seen status for the current message. + +A message is seen if both the top and enough of the rest of the +message have been visible in the buffer. Enough means either the +bottom of the message or a point in the message more than +LINES-NEEDED lines into the message. LINES-NEEDED is +`notmuch-show-seen-lines-needed` if that is an integer and that +times the current window height if it is a float." + (let* ((lines-needed (if (integerp notmuch-show-seen-lines-needed) + notmuch-show-seen-lines-needed +(truncate (* notmuch-show-seen-lines-needed (window-body-height) +(top (notmuch-show-message-top)) +(bottom (notmuch-show-message-bottom))) +(when (notmuch-show-message-visible-p) + (when (>= top start) + (notmuch-show-update-seen 'top)) + (when (or (<= bottom end) + (> (count-screen-lines top end) lines-needed)) + (notmuch-show-update-seen 'bottom) + +(defun notmuch-show-do-seen (start end) + "Update seen status for all messages between start and end. + +We mark the top (bottom) of a message seen if the top (enough of +the rest of the message) respectively have been visible in the +buffer. See `notmuch-show-do-message-seen` for the definition of +enough. When both the top and bottom have been seen we mark the +message read." + (save-excursion +(goto-char start) +(notmuch-show-do-message-seen start end) +(while (and (< (notmuch-show-message-bottom) end) + (notmuch-show-goto-message-next)) + (notmuch-show-do-message-seen start end)) +;; This is a work around because emacs gives weird answers for +;; window-end if the buffer ends with invisible text. +(when (and (pos-visible-in-window-p (point-max)) + (notmuch-show-message-visible-p)) + (notmuch-show-update-seen 'bottom + (defun notmuch-show-seen-current-message (start end) "Mark the current message read if it is open. -- 1.7.10.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add Travis-CI config file.
On Fri, May 9, 2014 at 8:16 AM, Tomi Ollila wrote: > On Fri, May 09 2014, "Wael M. Nasreddine" wrote: > >> --- > > Could this work so, that there is separate repo whete .travis.yml resides > and notmuch is there as a git submodule ? > > To my eyes this approach looks pretty intrusive: the repository root > directory is polluted with specific .travis.yml file and the content is > (apparently) specific to https://travis-ci.org/ (some version of ubuntu) > Unfortunately no, Travis expects it to be there. The other alternative would be for me to maintain a repo (under my user on Github) with the appropriate file but it seems extreme considering that this patch only adds one file that has no chance of conflicting with other patches. > That said, I won't be against the inclusion of this in case there are users > that like it (provided that a patch with proper commit message(*) is > available). > Did I not use a proper message? > Tomi > > (*) http://notmuchmail.org/contributing/ > >> .travis.yml | 10 ++ >> 1 file changed, 10 insertions(+) >> create mode 100644 .travis.yml >> >> diff --git a/.travis.yml b/.travis.yml >> new file mode 100644 >> index 000..8d92cdc >> --- /dev/null >> +++ b/.travis.yml >> @@ -0,0 +1,10 @@ >> +language: c >> +before_install: >> + - sudo apt-get update -qq >> + - wget >> 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb' >> + - wget >> 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb' >> + - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb >> zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb >> + - sudo apt-get install -f >> + - sudo apt-get install dtach libxapian-dev libgmime-2.6-dev libtalloc-dev >> python-sphinx >> + >> +script: make test >> -- >> 1.9.1.423.g4596e3a -- Wael Nasreddine | Software Engineer | wael.nasredd...@gmail.com | (650) 735-1773 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add Travis-CI config file.
On Fri, May 9, 2014 at 8:24 AM, Felipe Contreras wrote: > Wael Nasreddine wrote: >> On Travis Zlib is old and notmuch configure script exits with a >> failure, please see the Travis build #1 > > Please do not top-post. Apologies for that, I was dropping off my son at school and I replied from my phone. > > I had to manually find the build. In case anybody wants to check it out: > > https://travis-ci.org/notmuch/notmuch/builds To be specific it's build #2 you see the error right here https://travis-ci.org/notmuch/notmuch/builds/24681333#L193 > > -- > Felipe Contreras -- Wael Nasreddine | Software Engineer | wael.nasreddine at gmail.com | (650) 735-1773
[PATCH] Add Travis-CI config file.
On Fri, May 9, 2014 at 8:16 AM, Tomi Ollila wrote: > On Fri, May 09 2014, "Wael M. Nasreddine" > wrote: > >> --- > > Could this work so, that there is separate repo whete .travis.yml resides > and notmuch is there as a git submodule ? > > To my eyes this approach looks pretty intrusive: the repository root > directory is polluted with specific .travis.yml file and the content is > (apparently) specific to https://travis-ci.org/ (some version of ubuntu) > Unfortunately no, Travis expects it to be there. The other alternative would be for me to maintain a repo (under my user on Github) with the appropriate file but it seems extreme considering that this patch only adds one file that has no chance of conflicting with other patches. > That said, I won't be against the inclusion of this in case there are users > that like it (provided that a patch with proper commit message(*) is > available). > Did I not use a proper message? > Tomi > > (*) http://notmuchmail.org/contributing/ > >> .travis.yml | 10 ++ >> 1 file changed, 10 insertions(+) >> create mode 100644 .travis.yml >> >> diff --git a/.travis.yml b/.travis.yml >> new file mode 100644 >> index 000..8d92cdc >> --- /dev/null >> +++ b/.travis.yml >> @@ -0,0 +1,10 @@ >> +language: c >> +before_install: >> + - sudo apt-get update -qq >> + - wget >> 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb' >> + - wget >> 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb' >> + - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb >> zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb >> + - sudo apt-get install -f >> + - sudo apt-get install dtach libxapian-dev libgmime-2.6-dev libtalloc-dev >> python-sphinx >> + >> +script: make test >> -- >> 1.9.1.423.g4596e3a -- Wael Nasreddine | Software Engineer | wael.nasreddine at gmail.com | (650) 735-1773
emacs reply fills X clipboard with reply message body
Jameson Graef Rollins writes: > On Thu, May 08 2014, David Edmondson wrote: >> [ I'm cycling around back through some old mail. ] >> >> On Tue, Sep 17 2013, Jameson Graef Rollins wrote: >>> I've just started noticing that when I reply to messages from the emacs >>> UI, my X clipboard is filled with the body of the reply message, >>> displacing whatever was in there previously. >> >> This doesn't happen to me today. Is it still a problem for other people? > > This was fixed a while back, although I don't remember which series it > was that fixed it. The amazing Mark Walters and commit 4eb151e26ce0 ? d
Github?
David Bremner writes: > Wael Nasreddine writes: > >> I didn't see the previous email about it, thank you Jani for the link. It >> looks like you guys have your hands full and everything setup the way you >> like it, so here's what I'll do myself (if it's acceptable with you, >> otherwise I'll just remove everything): >> >> - Revert my changes (except for the CI) >> - Set a cron job to update the mirror hourly for the Github user wanting to >> fork. >> - Remove the Issues, Pull Request and the Wiki >> - Add a "mirror of .." to the description on top of the page >> - Manually update the contrib/ bindings/ as they change in here and maybe >> automate it later. >> >> For the automatic pusher, I'll have to skip the README changes. > > I think the concensus among the devs is that if there is going to be a > "notmuch" organization on github then it should be owned by and > controlled by us. > Let me expand on that comment a bit. It's great that you want to run a CI instance (we already have one, but who knows, maybe this will catch some problems our current instance does not). It's also fine that you want to run a mirror, or even (obviously) distribute modified versions of notmuch. The main point that many of us are sensitive about is people confusing these modified versions (and yeah, I consider splitting the repo modification) with the official one. The other point is that by admining the "notmuch" project on github, you are somehow officially representing the project to the outside world. Maybe if we get to know you, and we develop the appropriate communications channels, we'd think that would be a great idea, but it seems like too much to entrust to somebody we just "met". d -- next part ------ A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 647 bytes Desc: not available URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140509/7d713f07/attachment.pgp>
RE: [PATCH] Add Travis-CI config file.
Wael Nasreddine wrote: > On Travis Zlib is old and notmuch configure script exits with a > failure, please see the Travis build #1 Please do not top-post. I had to manually find the build. In case anybody wants to check it out: https://travis-ci.org/notmuch/notmuch/builds -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Add Travis-CI config file.
On Fri, May 09 2014, "Wael M. Nasreddine" wrote: > --- Could this work so, that there is separate repo whete .travis.yml resides and notmuch is there as a git submodule ? To my eyes this approach looks pretty intrusive: the repository root directory is polluted with specific .travis.yml file and the content is (apparently) specific to https://travis-ci.org/ (some version of ubuntu) That said, I won't be against the inclusion of this in case there are users that like it (provided that a patch with proper commit message(*) is available). Tomi (*) http://notmuchmail.org/contributing/ > .travis.yml | 10 ++ > 1 file changed, 10 insertions(+) > create mode 100644 .travis.yml > > diff --git a/.travis.yml b/.travis.yml > new file mode 100644 > index 000..8d92cdc > --- /dev/null > +++ b/.travis.yml > @@ -0,0 +1,10 @@ > +language: c > +before_install: > + - sudo apt-get update -qq > + - wget > 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb' > + - wget > 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb' > + - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb > zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb > + - sudo apt-get install -f > + - sudo apt-get install dtach libxapian-dev libgmime-2.6-dev libtalloc-dev > python-sphinx > + > +script: make test > -- > 1.9.1.423.g4596e3a ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Submodules for language bindings (was: Github?)
Suvayu Ali wrote:
> On Fri, May 09, 2014 at 07:40:27AM -0500, Felipe Contreras wrote:
> > Suvayu Ali wrote:
> >
> > > To explain my point with RPM specifics, if I were to
> > > use separate spec files, python-notmuch would have:
> > >
> > > Requires: notmuch >=
> > >
> > > As you can see this only allows for tracking dependency based on
> > > official version numbers. With more bindings, many with different
> > > version dependencies, this becomes quite cumbersome;
> >
> > No, it doesn't:
> >
> > %package notmuch-ruby
> > Requires: notmuch = %{version}-%{release}, ruby
>
> Doesn't that work when you have one spec file for all sub-packages (as I
> do now)? I was responding to Trevor's suggestion about not having
> sub-packages, IOW, different spec files for different packages.
Ah. I don't see why anybody would want different spec files for
different subpackages.
--
Felipe Contreras
RE: [PATCH] Add Travis-CI config file.
On Travis Zlib is old and notmuch configure script exits with a failure, please see the Travis build #1 On Friday, May 9, 2014 7:52:44 AM, Felipe Contreras < felipe.contre...@gmail.com> wrote: > Wael M. Nasreddine wrote: > > --- > > .travis.yml | 10 ++ > > 1 file changed, 10 insertions(+) > > create mode 100644 .travis.yml > > > > diff --git a/.travis.yml b/.travis.yml > > new file mode 100644 > > index 000..8d92cdc > > --- /dev/null > > +++ b/.travis.yml > > @@ -0,0 +1,10 @@ > > +language: c > > +before_install: > > + - sudo apt-get update -qq > > + - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/ > zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb' > > + - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/ > zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb' > > + - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb > zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb > > What's wrong with zlib? > > > + - sudo apt-get install -f > > + - sudo apt-get install dtach libxapian-dev libgmime-2.6-dev > libtalloc-dev python-sphinx > > + > > +script: make test > > -- > Felipe Contreras > ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
RE: [PATCH] Add Travis-CI config file.
Wael M. Nasreddine wrote: > --- > .travis.yml | 10 ++ > 1 file changed, 10 insertions(+) > create mode 100644 .travis.yml > > diff --git a/.travis.yml b/.travis.yml > new file mode 100644 > index 000..8d92cdc > --- /dev/null > +++ b/.travis.yml > @@ -0,0 +1,10 @@ > +language: c > +before_install: > + - sudo apt-get update -qq > + - wget > 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb' > + - wget > 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb' > + - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb > zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb What's wrong with zlib? > + - sudo apt-get install -f > + - sudo apt-get install dtach libxapian-dev libgmime-2.6-dev libtalloc-dev > python-sphinx > + > +script: make test -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Submodules for language bindings (was: Github?)
Suvayu Ali wrote:
> You have a point, however I would still disagree. You seem to use
> Gentoo, and I think what you say works better for Gentoo because it is
> a source distribution. For binary distributions, this is a bit harder
> (and limiting).
No, it's not harder.
> To explain my point with RPM specifics, if I were to
> use separate spec files, python-notmuch would have:
>
> Requires: notmuch >=
>
> As you can see this only allows for tracking dependency based on
> official version numbers. With more bindings, many with different
> version dependencies, this becomes quite cumbersome;
No, it doesn't:
%package notmuch-ruby
Requires: notmuch = %{version}-%{release}, ruby
--
Felipe Contreras
Github?
Wael Nasreddine writes: > I didn't see the previous email about it, thank you Jani for the link. It > looks like you guys have your hands full and everything setup the way you > like it, so here's what I'll do myself (if it's acceptable with you, > otherwise I'll just remove everything): > > - Revert my changes (except for the CI) > - Set a cron job to update the mirror hourly for the Github user wanting to > fork. > - Remove the Issues, Pull Request and the Wiki > - Add a "mirror of .." to the description on top of the page > - Manually update the contrib/ bindings/ as they change in here and maybe > automate it later. > > For the automatic pusher, I'll have to skip the README changes. I think the concensus among the devs is that if there is going to be a "notmuch" organization on github then it should be owned by and controlled by us. I'm sure your intentions are good, but reasonable people can differ about the best way to do things; in particular it makes no sense to me have a mirror where the history has been rewritten, meaning that people can't merge to or from the offical repo. Of course what you do as your own github user is up to you. d
Github?
Amadeusz ?o?nowski wrote: > The same goes for Travis. There's already a build bot. Why bother > with Travis? I've never seen any buildbot results. TravisCI's interface is just simple and easy. And all it requires is one file. -- Felipe Contreras
[PATCH] Add Travis-CI config file.
--- .travis.yml | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 .travis.yml diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 000..8d92cdc --- /dev/null +++ b/.travis.yml @@ -0,0 +1,10 @@ +language: c +before_install: + - sudo apt-get update -qq + - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb' + - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb' + - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb + - sudo apt-get install -f + - sudo apt-get install dtach libxapian-dev libgmime-2.6-dev libtalloc-dev python-sphinx + +script: make test -- 1.9.1.423.g4596e3a ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] Add Travis-CI config file.
--- .travis.yml | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 .travis.yml diff --git a/.travis.yml b/.travis.yml new file mode 100644 index 000..8d92cdc --- /dev/null +++ b/.travis.yml @@ -0,0 +1,10 @@ +language: c +before_install: + - sudo apt-get update -qq + - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb' + - wget 'https://launchpad.net/ubuntu/+archive/primary/+files/zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb' + - sudo dpkg -i zlib1g-dev_1.2.8.dfsg-1ubuntu1_amd64.deb zlib1g_1.2.8.dfsg-1ubuntu1_amd64.deb + - sudo apt-get install -f + - sudo apt-get install dtach libxapian-dev libgmime-2.6-dev libtalloc-dev python-sphinx + +script: make test -- 1.9.1.423.g4596e3a
Re: [PATCH v1 0/3] emacs: Allow saving of threads and messages
On Fri, May 09 2014, Mark Walters wrote: > The first two patches are fine, although I think I like constructing a > query then quoting rather than quoting bits of a query and bolting them > together (even the both work). Agreed. I've no idea what I was thinking. > My concern is that the current approach gives the user no warning if > they are about to overwrite an existing file, and that this is true > regardless of any emacs settings. > > Could we do these saves by loading into a temporary buffer and then > using the normal emacs save buffer functions? That way we get the > benefit of emacs's normal query-overwrite, and respect any user > customizations of that. Yes, that is a better approach. signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 2/5] configure, test: Added variables for paths to true and false.
Charles Celerier writes: > I will be the first too admit that I do not know much about configure > scripts, but adding a TRUE variable seemed straightforward. configure is already big enough, I'd prefer not to add new things unless they are needed. This is not likely to be something the user wants to change, and (as you note below) it's pretty easy for the the Makefile or tests to guess. > You could use `$(which true)` in test/Makefile.local, but I felt the > code repetition there was unecessary since you could just create a > TRUE variable in the configure script. well, it's not really code repetition because it is only used in that one place. > An alternative is to change the tests so that the location of true > (and false) is no longer an issue. Sure, that would be fine too. d
[PATCH v2 5/5] T360-symbol-hiding: Use nm instead of objdump.
Charles Celerier writes:
> David Bremner writes:
>
>> Charles Celerier writes:
>>> test_begin_subtest 'comparing existing to exported symbols'
>>> -objdump -t $TEST_DIRECTORY/../lib/*.o | awk '$4 == ".text" && $6 ~
>>> "^notmuch" {print $6}' | sort | uniq > ACTUAL
>>> +nm -g $TEST_DIRECTORY/../lib/*.o | sed -n
>>> 's/.*\s\+T\s\+_\(notmuch_.*\)/\1/p' | sort | uniq > ACTUAL
>>> sed -n 's/[[:blank:]]*\(notmuch_[^;]*\);/\1/p'
>>> $TEST_DIRECTORY/../notmuch.sym | sort | uniq > EXPORTED
>>
>> Hmm. It seems like the _ there is wrong. It grabs all of the symbols
>> starting with _notmuch, which are symbols we _don't_ want exported.
>> It makes me wonder what ends up in "notmuch.sym" on MacOS, if that test
>> passes for you.
>
> Ok. Apologies in advance for the verbose content of this email. Here is my
> notmuch.sym:
Actually, that's perfect. I think I finally understand what's going on,
if not completely how to fix it yet.
>
> $ cat notmuch.sym
> {
> global:
this looks fine; only mangled C++ stuff is different.
> The output of the test in question (T360-symbol-hiding) after
> applying all of the patches in this series is
>
> T360-symbol-hiding: Testing exception symbol hiding
> PASS running test
> PASS checking output
> FAIL comparing existing to exported symbols
> --- T360-symbol-hiding.3.EXPORTED 2014-05-08
> 14:48:52.0 +
> +++ T360-symbol-hiding.3.ACTUAL 2014-05-08 14:48:52.0
> +
> @@ -26,7 +26,11 @@
>notmuch_filenames_valid
>notmuch_message_add_tag
>notmuch_message_destroy
> +notmuch_message_file_close
> +notmuch_message_file_get_header
> +notmuch_message_file_open
>
OK, what's happening here is that your version of the test, I guess
using nm, is not skipping hidden symbols. This should probably be better
documented in the existing test, but in the case of hidden symbols,
$6 is ".hidden". I don't know if nm understands symbol visibility at
all; I'd guess not.
So as a more portable workaround, I agree we could start being more
rigorous about not naming things "^notmuch_.*" unless they are intended
to be exported.
> This output was a clear motivation for the patch in
> id:1399402716-13714-1-git-send-email-cceleri at cs.stanford.edu.
I see that now. I think I'd prefer a more minimal patch that only adds _
to the front of symbols currently starting with notmuch.
> Here is some of output of the matches made on the output of nm:
>
> $ nm -g test/../lib/*.o | sed -n '/.*\s\+T\s\+_\(notmuch_.*\)/p'
> 28c0 T _notmuch_database_add_message
> 2280 T _notmuch_database_begin_atomic
> 1af0 T _notmuch_database_close
> 1de0 T _notmuch_database_compact
With GNU nm, there is no leading _ in front of notmuch here, which is
what causes your version of the test to fail for me.
d
Re: Submodules for language bindings (was: Github?)
Suvayu Ali wrote:
> On Fri, May 09, 2014 at 07:40:27AM -0500, Felipe Contreras wrote:
> > Suvayu Ali wrote:
> >
> > > To explain my point with RPM specifics, if I were to
> > > use separate spec files, python-notmuch would have:
> > >
> > > Requires: notmuch >=
> > >
> > > As you can see this only allows for tracking dependency based on
> > > official version numbers. With more bindings, many with different
> > > version dependencies, this becomes quite cumbersome;
> >
> > No, it doesn't:
> >
> > %package notmuch-ruby
> > Requires: notmuch = %{version}-%{release}, ruby
>
> Doesn't that work when you have one spec file for all sub-packages (as I
> do now)? I was responding to Trevor's suggestion about not having
> sub-packages, IOW, different spec files for different packages.
Ah. I don't see why anybody would want different spec files for
different subpackages.
--
Felipe Contreras
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v4 0/2] emacs: show: redesign unread/read logic
On Fri, May 09 2014, Mark Walters wrote: >> Just to confirm: you can get your desired behaviour by writing an >> alternative `notmuch-show-mark-read-function'? > > Yes I can confirm that. So if this went in I can get the behaviour of > the earlier series without needing to patch notmuch. > > We can decide later if we want to include it (and other possible mark > read functions) as an option, or as a contrib file, or just on the > wiki. I think that it would be convenient to include a function that implements your preferred behaviour so that others can decide how they would like it to behave. signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Submodules for language bindings (was: Github?)
On Fri, May 09, 2014 at 07:40:27AM -0500, Felipe Contreras wrote:
> Suvayu Ali wrote:
>
> > To explain my point with RPM specifics, if I were to
> > use separate spec files, python-notmuch would have:
> >
> > Requires: notmuch >=
> >
> > As you can see this only allows for tracking dependency based on
> > official version numbers. With more bindings, many with different
> > version dependencies, this becomes quite cumbersome;
>
> No, it doesn't:
>
> %package notmuch-ruby
> Requires: notmuch = %{version}-%{release}, ruby
Doesn't that work when you have one spec file for all sub-packages (as I
do now)? I was responding to Trevor's suggestion about not having
sub-packages, IOW, different spec files for different packages.
--
Suvayu
Open source is the future. It sets us free.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Submodules for language bindings (was: Github?)
Suvayu Ali wrote:
> You have a point, however I would still disagree. You seem to use
> Gentoo, and I think what you say works better for Gentoo because it is
> a source distribution. For binary distributions, this is a bit harder
> (and limiting).
No, it's not harder.
> To explain my point with RPM specifics, if I were to
> use separate spec files, python-notmuch would have:
>
> Requires: notmuch >=
>
> As you can see this only allows for tracking dependency based on
> official version numbers. With more bindings, many with different
> version dependencies, this becomes quite cumbersome;
No, it doesn't:
%package notmuch-ruby
Requires: notmuch = %{version}-%{release}, ruby
--
Felipe Contreras
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Github?
Amadeusz Żołnowski wrote: > The same goes for Travis. There's already a build bot. Why bother > with Travis? I've never seen any buildbot results. TravisCI's interface is just simple and easy. And all it requires is one file. -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Github?
Hi, Wael Nasreddine writes: > I was a bit disappointed that the project is not living (or at least > mirrored) to Github, it would have made my search much easier. How GitHub would help with this? I believe that most of search engines reach Notmuch home page. GitHub is not the center of the world. I have a GitHub account, too and I use it to host some stuff, but I have never given a single thought about encouraging project I use or contribute to to move/mirror on GitHub just because I use it. The same goes for Travis. There's already a build bot. Why bother with Travis? I wonder when a next person is going to be _disappointed_ that there's no mirror on Bitbucket, or that he/she couldn't find Notmuch on Facebook/Google+/whatever... This can be a never ending story. Just my 0.02 PLN. Best regards, -- Amadeusz Żołnowski pgpoOdZZjxYdQ.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v1 0/3] emacs: Allow saving of threads and messages
Hi
I think the functionality is well worth having ("|" cat - > a-file is
ugly!). However, I am not sure about this approach.
The first two patches are fine, although I think I like constructing a
query then quoting rather than quoting bits of a query and bolting them
together (even the both work).
My concern is that the current approach gives the user no warning if
they are about to overwrite an existing file, and that this is true
regardless of any emacs settings.
Could we do these saves by loading into a temporary buffer and then
using the normal emacs save buffer functions? That way we get the
benefit of emacs's normal query-overwrite, and respect any user
customizations of that.
The only potential problem is to make sure we don't do any accidental
charset conversion. I guess this functionality is probably easy to test
at least!
Best wishes
Mark
On Fri, 09 May 2014, David Edmondson wrote:
> emacs: Allow saving of threads and messages
>
> Similar to the pipe (|) support, allow saving of threads and messages.
>
>
> David Edmondson (3):
> emacs: Fix indentation.
> emacs: Minor re-work of `notmuch-show-pipe-message'
> emacs: Add `notmuch-show-save-message' to save messages
>
> emacs/notmuch-show.el | 161
> --
> 1 file changed, 91 insertions(+), 70 deletions(-)
>
> --
> 2.0.0.rc0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Submodules for language bindings (was: Github?)
Hi Trevor, On Thu, May 08, 2014 at 04:35:30PM -0700, W. Trevor King wrote: > On Fri, May 09, 2014 at 12:45:27AM +0200, Suvayu Ali wrote: > > On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote: > > > On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote: > > > > One of my TODOs is to also package the ruby bindings, and > > > > notmuch-vim. The only thing preventing me now is my > > > > unfamiliarty with ruby, and Fedora packaging guidelines for > > > > ruby-gems. > > > > > > I think this is one argument argument in favor of submodules, > > > because they make it easy to treat the bindings as separate > > > packages. Once you have separate packages, it's easy to delegate > > > packaging (e.g. “I don't use the Ruby bindings, so I'm not going > > > to maintain the Ruby-binding package. I'll leave that to Alice, > > > who likes Ruby, but is less familiar with $distro's Python > > > packaging”). > > > > Well as far as my understanding of rpm goes, sub-packages are > > prefered here rather than independent packages. I believe the > > reason is again easier dependency tracking[1]; all sub-packages > > share the same source rpm, so no explicit `Requires' in the spec > > file. > > It looks like sub-packages share a single spec file with the main > package [1]. That means you'll have to have authors with the full > range of binding-language expertise to bump that spec file (assuming > there are any changes that require bumps). For example, Gentoo's > Python eclasses have gone through a few revisions in the last year or > two, and I wouldn't expect one person to stay on top of the latest > packaging styles for every language with notmuch bindings. I think > the benefit of having separate packages (and spec files, or ebuilds, > or whatever) is that you can release notmuch-0.18 without worrying > about all those bindings, and leave it to the other maintainers (who > might include you) to independently package notmuch-python-0.18, > notmuch-ruby-0.18, notmuch-go-0.18, …. With only three sets of > bindings, it doesn't really matter, but I think you'll want the weaker > coupling of stand-alone packages by the time you hit a dozen > languages. “Bump an explicit 'Requires'” certainly seems like a lower > barrier than “package Go bindings idiomatically for Fedora” ;). You have a point, however I would still disagree. You seem to use Gentoo, and I think what you say works better for Gentoo because it is a source distribution. For binary distributions, this is a bit harder (and limiting). To explain my point with RPM specifics, if I were to use separate spec files, python-notmuch would have: Requires: notmuch >= As you can see this only allows for tracking dependency based on official version numbers. With more bindings, many with different version dependencies, this becomes quite cumbersome; more so when you are doing snapshots (as I do for my repo[1]). As a packager, I think I would prefer to learn different packaging guidelines, setup my spec file and forget about it rather than continually follow all changes. But I guess this is where you would argue with different responsible people, I would not have to do all the thinking :-p. Anyway, whichever way the devs choose to go, I (and other packagers) will adapt. Cheers, Footnotes: [1] I would love to know if anyone here uses it. I announced it here when I started it, but for all I know I could be the only user! :-p -- Suvayu Open source is the future. It sets us free. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v4 0/2] emacs: show: redesign unread/read logic
On Fri, 09 May 2014, David Edmondson wrote: > On Fri, May 09 2014, Mark Walters wrote: >> This is v4 of this set. v3 is at >> id:139593-13297-1-git-send-email-markwalters1...@gmail.com >> >> David (dme) was not keen on the logic in the previous patch so I have >> tried to make it rather more customisable and made this version much >> closer to the existing logic. >> >> This version marks the current message read if it is open. It doesn't >> care how you get there: whether it is notmuch commands n/N/p/P next >> message etc, emacs commands like scroll up, mouse clicks etc. >> >> The only proviso is it will only mark a message read once (in a single >> buffer and between refreshes) as otherwise it is impossible for a user >> to choose to mark a message unread. > > This version looks good to me, thanks for considering the feedback. Hi Thanks for looking and testing. >> I, personally, like my previous logic much more. But with this setup >> that can be customized easily in my .emacs (we may choose to add other >> options into mainline later). Also I think this series fixes all of >> the problems with the current read/unread logic mentioned in >> id:87a9atmpkf@qmul.ac.uk are fixed. > > Just to confirm: you can get your desired behaviour by writing an > alternative `notmuch-show-mark-read-function'? Yes I can confirm that. So if this went in I can get the behaviour of the earlier series without needing to patch notmuch. We can decide later if we want to include it (and other possible mark read functions) as an option, or as a contrib file, or just on the wiki. Best wishes Mark ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: Log of tagging actions
On Fri, May 09 2014, Istvan Marko wrote: > Sebastian Fischmeister writes: > >> Is there a possibility to log all tagging actions done in notmuch? > > I use a shell wrapper around notmuch to get this: > > #! /bin/sh > echo "notmuch $@" >>$HOME/logs/notmuch.log > /usr/local/bin/notmuch "$@" You could make the last line 'exec /usr/local/bin/notmuch "$@"' :D (and if you use debian, #!/bin/dash...) I use a C wrapper to do the same (with date prefixes like 2014-05-09 (Fri) 12:47:19) -- I originally did it to do argument conversions around .. to have date-based searches before those came to notmuch (and I am still using it, as I don't have to type date: prefix) > Would be nice to be able to log all operations done via libnotmuch too > though. IIRC someone suggested/asked whether we'd get logs where all Message-ID:s affected were logged. That could be useful (and produce lot of log when one does notmuch tag +foobar '*') That means to do logging with this granularity may prove problematic... > -- > Istvan Tomi ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Github?
Actually you can't have the .Travis.yml file in a separate branch, Travis require it present in the context that it is testing (commits to all branches) On Thursday, May 8, 2014 7:53:52 PM, Felipe Contreras < felipe.contreras at gmail.com> wrote: > W. Trevor King wrote: > > On Thu, May 08, 2014 at 11:18:23PM +, Wael Nasreddine wrote: > > > Well like I said in my first email, if you guys are interested in > owning > > > and maintaining the GitHub repo it is yours, besides I have not done > > > anything with the history I only added one commit which will never > conflict > > > with upstream unless you add a .Travis.yml file :) > > > > I don't think merge conflicts are the problem here. If the GitHub > > mirror claims to be a mirror but adds an additional commit B: > > > > -o---o---o---A notmuch/master > > \ > > B github/master > > > > Someone who takes the ?mirror? claim at face value may use > > github/master as the base for some feature: > > > > -o---o---o---A notmuch/master > > \ > > B github/master > > \ > >C---o---o some-feature > > That wouldn't be a problem if HEAD didn't point to 'master' but to > 'upstream' which would be 'notmuch/master'. > > Or if the branch with the modifications was called something else, like > 'travis-ci'. > > -- > Felipe Contreras -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140509/a6838aa3/attachment.html>
Re: [PATCH v4 0/2] emacs: show: redesign unread/read logic
On Fri, May 09 2014, Mark Walters wrote: > This is v4 of this set. v3 is at > id:139593-13297-1-git-send-email-markwalters1...@gmail.com > > David (dme) was not keen on the logic in the previous patch so I have > tried to make it rather more customisable and made this version much > closer to the existing logic. > > This version marks the current message read if it is open. It doesn't > care how you get there: whether it is notmuch commands n/N/p/P next > message etc, emacs commands like scroll up, mouse clicks etc. > > The only proviso is it will only mark a message read once (in a single > buffer and between refreshes) as otherwise it is impossible for a user > to choose to mark a message unread. This version looks good to me, thanks for considering the feedback. > I, personally, like my previous logic much more. But with this setup > that can be customized easily in my .emacs (we may choose to add other > options into mainline later). Also I think this series fixes all of > the problems with the current read/unread logic mentioned in > id:87a9atmpkf@qmul.ac.uk are fixed. Just to confirm: you can get your desired behaviour by writing an alternative `notmuch-show-mark-read-function'? signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v1 2/3] emacs: Minor re-work of `notmuch-show-pipe-message'
Stylistic only - no functional change. --- emacs/notmuch-show.el | 59 +-- 1 file changed, 29 insertions(+), 30 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 2ed221a..62c0be6 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1784,36 +1784,35 @@ If ENTIRE-THREAD is non-nil (or when invoked with a prefix argument), COMMAND will receive all open messages in the current thread (formatted as an mbox) rather than only the current message." - (interactive (let ((query-string (if current-prefix-arg - "Pipe all open messages to command: " -"Pipe message to command: "))) -(list current-prefix-arg (read-string query-string - (let (shell-command) -(if entire-thread - (setq shell-command - (concat notmuch-command " show --format=mbox --exclude=false " - (shell-quote-argument - (mapconcat 'identity (notmuch-show-get-message-ids-for-open-messages) " OR ")) - " | " command)) - (setq shell-command - (concat notmuch-command " show --format=raw " - (shell-quote-argument (notmuch-show-get-message-id)) " | " command))) -(let ((cwd default-directory) - (buf (get-buffer-create (concat "*notmuch-pipe*" - (with-current-buffer buf - (setq buffer-read-only nil) - (erase-buffer) - ;; Use the originating buffer's working directory instead of - ;; that of the pipe buffer. - (cd cwd) - (let ((exit-code (call-process-shell-command shell-command nil buf))) - (goto-char (point-max)) - (set-buffer-modified-p nil) - (setq buffer-read-only t) - (unless (zerop exit-code) - (switch-to-buffer-other-window buf) - (message (format "Command '%s' exited abnormally with code %d" -shell-command exit-code + (interactive (let ((prompt (if current-prefix-arg +"Pipe all open messages to command: " + "Pipe message to command: "))) +(list current-prefix-arg (read-string prompt + + (let ((shell-command +(concat notmuch-command " show" +(if entire-thread +(concat " --format=mbox --exclude=false " +(mapconcat #'shell-quote-argument (notmuch-show-get-message-ids-for-open-messages) " OR ")) + (concat " --format=raw " + (shell-quote-argument (notmuch-show-get-message-id +" | " command)) + (cwd default-directory) + (buf (get-buffer-create (concat "*notmuch-pipe*" +(with-current-buffer buf + (setq buffer-read-only nil) + (erase-buffer) + ;; Use the originating buffer's working directory instead of + ;; that of the pipe buffer. + (cd cwd) + (let ((exit-code (call-process-shell-command shell-command nil buf))) + (goto-char (point-max)) + (set-buffer-modified-p nil) + (setq buffer-read-only t) + (unless (zerop exit-code) + (switch-to-buffer-other-window buf) + (message (format "Command '%s' exited abnormally with code %d" + shell-command exit-code))) (defun notmuch-show-tag-message (&rest tag-changes) "Change tags for the current message. -- 2.0.0.rc0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v1 3/3] emacs: Add `notmuch-show-save-message' to save messages
Following `notmuch-show-pipe-message', add a binding 'S' to save either the current or all open messages, depending on prefix argument. --- emacs/notmuch-show.el | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index 62c0be6..851e968 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -1285,6 +1285,7 @@ reset based on the original query." (define-key map "f" 'notmuch-show-forward-message) (define-key map "r" 'notmuch-show-reply-sender) (define-key map "R" 'notmuch-show-reply) +(define-key map "S" 'notmuch-show-save-message) (define-key map "|" 'notmuch-show-pipe-message) (define-key map "w" 'notmuch-show-save-attachments) (define-key map "V" 'notmuch-show-view-raw-message) @@ -1769,6 +1770,24 @@ to show, nil otherwise." (set-buffer-modified-p nil) (view-buffer buf 'kill-buffer-if-not-modified))) +(put 'notmuch-show-save-message 'notmuch-doc + "Save the contents of the current message to a file.") +(put 'notmuch-show-save-message 'notmuch-prefix-doc + "Save the thread as an mbox to a file.") +(defun notmuch-show-save-message (entire-thread file) + "Save the contents of the current message (or thread) to FILE. + +If ENTIRE-THREAD is non-nil (or when invoked with a prefix +argument), FILE will contain all open messages in the current +thread (formatted as an mbox) rather than only the current +message." + (interactive (let ((prompt (if current-prefix-arg +"Save all open messages to file: " + "Save message to command: "))) +(list current-prefix-arg (read-file-name prompt + + (notmuch-show-pipe-message-internal entire-thread (concat " > " file))) + (put 'notmuch-show-pipe-message 'notmuch-doc "Pipe the contents of the current message to a command.") (put 'notmuch-show-pipe-message 'notmuch-prefix-doc @@ -1789,6 +1808,9 @@ message." "Pipe message to command: "))) (list current-prefix-arg (read-string prompt + (notmuch-show-pipe-message-internal entire-thread (concat " | " command))) + +(defun notmuch-show-pipe-message-internal (entire-thread command-tail) (let ((shell-command (concat notmuch-command " show" (if entire-thread @@ -1796,7 +1818,7 @@ message." (mapconcat #'shell-quote-argument (notmuch-show-get-message-ids-for-open-messages) " OR ")) (concat " --format=raw " (shell-quote-argument (notmuch-show-get-message-id -" | " command)) +command-tail)) (cwd default-directory) (buf (get-buffer-create (concat "*notmuch-pipe*" (with-current-buffer buf -- 2.0.0.rc0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v1 0/3] emacs: Allow saving of threads and messages
emacs: Allow saving of threads and messages Similar to the pipe (|) support, allow saving of threads and messages. David Edmondson (3): emacs: Fix indentation. emacs: Minor re-work of `notmuch-show-pipe-message' emacs: Add `notmuch-show-save-message' to save messages emacs/notmuch-show.el | 161 -- 1 file changed, 91 insertions(+), 70 deletions(-) -- 2.0.0.rc0 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v4 2/2] emacs: show: add an update seen function to post-command-hook
Add a function for updating seen messages to the
post-command-hook. This function calls a customizable (by eg
defcustom) function with parameters the start and end of the current
window and that function can decide what to mark read based on that
and the current point.
Since this is in the post-command-hook it should get called after most
user actions (exceptions include user resizing the window) so it
should be possible to make sure the seen status gets updated whether
the user uses notmuch commands like next-message or normal emacs
commands like scroll-up.
It removes all of the old mark read/seen points but introduces a
simple example function that just marks the current message read if it
is open. This function has one small subtlety: it makes sure it
doesn't mark the same message read twice (in the same instance of the
same buffer); otherwise the post-command-hook makes it impossible for
a user to manually mark a message unread.
This fixes the current bugs (imo) that closed messages can be marked
read, and that opening a closed message does not mark it read.
Another advantage of using the post-command-hook any programmatic use
with point passing through a message will not mark it read.
---
emacs/notmuch-show.el | 43 ---
1 file changed, 28 insertions(+), 15 deletions(-)
diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 10fc872..2620f84 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -222,6 +222,10 @@ (defcustom notmuch-show-mark-read-tags '("-unread")
:type '(repeat string)
:group 'notmuch-show)
+(defcustom notmuch-show-mark-read-function #'notmuch-show-seen-current-message
+ "Function to control which messages are marked read."
+ :type 'function
+ :group 'notmuch-show)
(defmacro with-current-notmuch-show-message (&rest body)
"Evaluate body with current buffer set to the text of current message"
@@ -1156,6 +1160,8 @@ (defun notmuch-show-build-buffer ()
(let ((inhibit-read-only t))
(notmuch-show-mode)
+(add-hook 'post-command-hook #'notmuch-show-command-hook nil t)
+
;; Don't track undo information for this buffer
(set 'buffer-undo-list t)
@@ -1544,6 +1550,23 @@ (defun notmuch-show-mark-read (&optional unread)
(apply 'notmuch-show-tag-message
(notmuch-tag-change-list notmuch-show-mark-read-tags unread
+(defun notmuch-show-seen-current-message (start end)
+ "Mark the current message read if it is open.
+
+We only mark it read once: if it is changed back then that is a
+user decision and we should not override it."
+ (when (and (notmuch-show-message-visible-p)
+(not (notmuch-show-get-prop :seen)))
+ (notmuch-show-mark-read)
+ (notmuch-show-set-prop :seen t)))
+
+(defun notmuch-show-command-hook ()
+ (when (eq major-mode 'notmuch-show-mode)
+;; We need to redisplay to get window-start and window-end correct.
+(redisplay)
+(save-excursion
+ (funcall notmuch-show-mark-read-function (window-start) (window-end)
+
;; Functions for getting attributes of several messages in the current
;; thread.
@@ -1679,9 +1702,7 @@ (defun notmuch-show-next-message (&optional pop-at-end)
thread, navigate to the next thread in the parent search buffer."
(interactive "P")
(if (notmuch-show-goto-message-next)
- (progn
- (notmuch-show-mark-read)
- (notmuch-show-message-adjust))
+ (notmuch-show-message-adjust)
(if pop-at-end
(notmuch-show-next-thread)
(goto-char (point-max)
@@ -1692,7 +1713,6 @@ (defun notmuch-show-previous-message ()
(if (= (point) (notmuch-show-message-top))
(notmuch-show-goto-message-previous)
(notmuch-show-move-to-message-top))
- (notmuch-show-mark-read)
(notmuch-show-message-adjust))
(defun notmuch-show-next-open-message (&optional pop-at-end)
@@ -1707,9 +1727,7 @@ (defun notmuch-show-next-open-message (&optional
pop-at-end)
(while (and (setq r (notmuch-show-goto-message-next))
(not (notmuch-show-message-visible-p
(if r
- (progn
- (notmuch-show-mark-read)
- (notmuch-show-message-adjust))
+ (notmuch-show-message-adjust)
(if pop-at-end
(notmuch-show-next-thread)
(goto-char (point-max
@@ -1722,9 +1740,7 @@ (defun notmuch-show-next-matching-message ()
(while (and (setq r (notmuch-show-goto-message-next))
(not (notmuch-show-get-prop :match
(if r
- (progn
- (notmuch-show-mark-read)
- (notmuch-show-message-adjust))
+ (notmuch-show-message-adjust)
(goto-char (point-max)
(defun notmuch-show-open-if-matched ()
@@ -1735,8 +1751,7 @@ (defun notmuch-show-open-if-matched ()
(defun notmuch-show-goto-first-wanted-message ()
"Move to the first open message and mark it read"
(goto-char (point-min))
- (if (notmuch-show-message-visible-p)
- (notmuch-show-mark-read)
+ (unless (notmuch-show-message-vis
[PATCH v4 1/2] test: make test_emacs call post-command-hook
From: David Bremner
The unread/read changes will use the post-command-hook. test_emacs
does not call the post-command-hook. This adds a notmuch-test-progn
which takes a list of commands as argument and executes them in turn
but runs the post-command-hook after each one.
The caller can batch operations (ie to stop post-command-hook from
being interleaved) by wrapping the batch of operations inside a progn.
We also explicitly run the post-command-hook before getting the output
from a test; this makes sense as this will be a place the user would
be seeing the information.
---
test/test-lib.el | 11 +++
test/test-lib.sh |2 +-
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/test/test-lib.el b/test/test-lib.el
index 437f83f..36afe63 100644
--- a/test/test-lib.el
+++ b/test/test-lib.el
@@ -52,11 +52,13 @@ (defun notmuch-test-wait ()
(defun test-output (&optional filename)
"Save current buffer to file FILENAME. Default FILENAME is OUTPUT."
+ (notmuch-post-command)
(write-region (point-min) (point-max) (or filename "OUTPUT")))
(defun test-visible-output (&optional filename)
"Save visible text in current buffer to file FILENAME. Default
FILENAME is OUTPUT."
+ (notmuch-post-command)
(let ((text (visible-buffer-string)))
(with-temp-file (or filename "OUTPUT") (insert text
@@ -166,6 +168,15 @@ (defun notmuch-test-expect-equal (output expected)
(t
(notmuch-test-report-unexpected output expected)
+(defun notmuch-post-command ()
+ (run-hooks 'post-command-hook))
+
+(defmacro notmuch-test-progn (&rest body)
+ (cons 'progn
+ (mapcar
+(lambda (x) `(prog1 ,x (notmuch-post-command)))
+body)))
+
;; For historical reasons, we hide deleted tags by default in the test
;; suite
(setq notmuch-tag-deleted-formats
diff --git a/test/test-lib.sh b/test/test-lib.sh
index 8697d6a..e6403e5 100644
--- a/test/test-lib.sh
+++ b/test/test-lib.sh
@@ -1139,7 +1139,7 @@ test_emacs () {
rm -f OUTPUT
touch OUTPUT
- ${TEST_EMACSCLIENT} --socket-name="$EMACS_SERVER" --eval "(progn $@)"
+ ${TEST_EMACSCLIENT} --socket-name="$EMACS_SERVER" --eval
"(notmuch-test-progn $@)"
}
test_python() {
--
1.7.10.4
[PATCH v4 0/2] emacs: show: redesign unread/read logic
This is v4 of this set. v3 is at id:139593-13297-1-git-send-email-markwalters1009 at gmail.com David (dme) was not keen on the logic in the previous patch so I have tried to make it rather more customisable and made this version much closer to the existing logic. This version marks the current message read if it is open. It doesn't care how you get there: whether it is notmuch commands n/N/p/P next message etc, emacs commands like scroll up, mouse clicks etc. The only proviso is it will only mark a message read once (in a single buffer and between refreshes) as otherwise it is impossible for a user to choose to mark a message unread. I, personally, like my previous logic much more. But with this setup that can be customized easily in my .emacs (we may choose to add other options into mainline later). Also I think this series fixes all of the problems with the current read/unread logic mentioned in id:87a9atmpkf.fsf at qmul.ac.uk are fixed. The first patch is unchanged. Since the new mark-read function is small it folded neatly into the patch removing the old unread logic. Finally, as with previous versions, all tests pass. Best wishes Mark Mark Walters (2): test: make test_emacs call post-command-hook emacs: show: add an update seen function to post-command-hook emacs/notmuch-show.el | 43 --- test/test-lib.el | 11 +++ test/test-lib.sh |2 +- 3 files changed, 40 insertions(+), 16 deletions(-) -- 1.7.10.4
Re: Log of tagging actions
Sebastian Fischmeister writes: > Is there a possibility to log all tagging actions done in notmuch? I use a shell wrapper around notmuch to get this: #! /bin/sh echo "notmuch $@" >>$HOME/logs/notmuch.log /usr/local/bin/notmuch "$@" Would be nice to be able to log all operations done via libnotmuch too though. -- Istvan ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Log of tagging actions
Sebastian Fischmeister writes: > Is there a possibility to log all tagging actions done in notmuch? I use a shell wrapper around notmuch to get this: #! /bin/sh echo "notmuch $@" >>$HOME/logs/notmuch.log /usr/local/bin/notmuch "$@" Would be nice to be able to log all operations done via libnotmuch too though. -- Istvan
Submodules for language bindings (was: Github?)
On Thu, May 08, 2014 at 03:29:31PM -0700, W. Trevor King wrote: > On Fri, May 09, 2014 at 12:00:46AM +0200, Suvayu Ali wrote: > > One of my TODOs is to also package the ruby bindings, and > > notmuch-vim. The only thing preventing me now is my unfamiliarty > > with ruby, and Fedora packaging guidelines for ruby-gems. > > I think this is one argument argument in favor of submodules, because > they make it easy to treat the bindings as separate packages. Once > you have separate packages, it's easy to delegate packaging (e.g. ?I > don't use the Ruby bindings, so I'm not going to maintain the > Ruby-binding package. I'll leave that to Alice, who likes Ruby, but > is less familiar with $distro's Python packaging?). Well as far as my understanding of rpm goes, sub-packages are prefered here rather than independent packages. I believe the reason is again easier dependency tracking[1]; all sub-packages share the same source rpm, so no explicit `Requires' in the spec file. Cheers, Footnotes: [1] yum and it's ilk don't do that by magic, the packager needs to add instructions in the spec file for that to work correctly. With sub-packages, this becomes redundant. -- Suvayu Open source is the future. It sets us free.
Github?
I understand. Maybe we should convert the current Github to a real mirror, mirroring all the branches and tags as is and a) add .Travis.yml upstream or b) maintain a separate fork (maybe under my own profile) for Travis integration Would you be willing to add Travis.yml upstream? In any case, all what I'm trying to do is help, help you with more CI visibility, your users with a more familiar interface and hopefully attract more hackers. I really do appreciate all the work done, this is am amazing project! On Thursday, May 8, 2014 4:49:47 PM, W. Trevor King wrote: > On Thu, May 08, 2014 at 11:18:23PM +, Wael Nasreddine wrote: > > Well like I said in my first email, if you guys are interested in owning > > and maintaining the GitHub repo it is yours, besides I have not done > > anything with the history I only added one commit which will never > conflict > > with upstream unless you add a .Travis.yml file :) > > I don't think merge conflicts are the problem here. If the GitHub > mirror claims to be a mirror but adds an additional commit B: > > -o---o---o---A notmuch/master > \ > B github/master > > Someone who takes the ?mirror? claim at face value may use > github/master as the base for some feature: > > -o---o---o---A notmuch/master > \ > B github/master > \ >C---o---o some-feature > > Now when they submit the patches to this list, they might send a patch > series that drags in B (probably not what the some-feature author > wanted). Alternatively, they might send a patch series starting with > C and say ?this is based on B?, and anyone who's only following the > main repo thinks, ?What is B? I don't have that commit.?. > > You'll also have to continuously rebase github/master to keep A on top > of notmuch/master, which means any feature branches built on > github/master will *also* have to be continuously rebased: > > -o---o---o---A---D notmuch/master > \ > A' github/master > \ >B'---o---o some-feature > > Keeping a fork with commits that aren't upstream is fine, and > maintaining a fork with an additional .Travis.yml file will probably > be pretty easy, but calling that fork a mirror is going to cause > needless confusion. > > Cheers, > Trevor > > -- > This email may be signed or encrypted with GnuPG (http://www.gnupg.org). > For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy > -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20140509/89808ba7/attachment.html>
Github?
On Thu, May 08, 2014 at 08:01:56PM -0700, W. Trevor King wrote: > Agreed. The only problem I'd have is that you'd want to say that the > GitHub repo was a mirror, since the primary repo would still be > git://notmuchmail.org/git/notmuch. If it's a mirror, I think it > should mirror all refs on the main repo [1] without adding new ones. > I'm happy for 'travis-ci' branches and whatnot in repositories that > don't claim to mirror the notmuchmail.org repo. I'm also happy to > have the Travis config upstream (in any branch), in which case it > would show up in the mirror. I just don't think it's a good idea to > have tweaks on a ?mirror? that aren't upstream, even if it doesn't > effect any upstream refs. Then just email support at github.com and I'm sure they will be happy to setup the repo as a mirror like they've did for some apache projects like cordova[1]. [1]:https://github.com/apache/cordova-cli -- qmx
Github?
On Thu, May 08, 2014 at 11:21:00PM +0200, guyzmo wrote: > On Thu, May 08, 2014 at 10:30:19PM +0200, Suvayu Ali wrote: > > On Thu, May 08, 2014 at 01:14:51PM -0700, Wael M. Nasreddine wrote: > > > On Thu, May 8, 2014 at 12:54 PM, Wael Nasreddine > > > wrote: > [...] > > > Can you guys at least consider splitting contrib/ and bindings/ into their > > > own repo? It will make it easier for people to use the go bindings (for > > > example) or to include the vim plugin as a submodule (or Vundle bundle). > > > > What is the problem if contrib and bindings are part of the main repo? > > In fact I would argue it is undesirable to split them. If there are > > major changes in libnotmuch, or the cli, it is much easier to make the > > corresponding changes in bindings to keep everything working. If there > > is a separate repo, communicating this dependency, although not > > impossible, is difficult. I would also like to point out almost all > > FOSS projects I follow, or contribute to practises this. > > do you know about git submodules? It's actually there to be able to > track changes on remote repositories that are closely related, while > keeping a sane separation. I do, hence the "although not impossible". It's still adding complexity that is not needed for something like language bindings. What is so hard to package them when part of the project repo? In fact, I package notmuch along with its python bindings and a few utilities from contrib for Fedora[1]. The default Fedora packages are horribly outdated. One of my TODOs is to also package the ruby bindings, and notmuch-vim. The only thing preventing me now is my unfamiliarty with ruby, and Fedora packaging guidelines for ruby-gems. Footnotes: [1] http://copr-be.cloud.fedoraproject.org/results/fatka/notmuch/fedora-20-x86_64/notmuch-0.18-5.20140506.git.8ecc7db3.fc20/ -- Suvayu Open source is the future. It sets us free.
