[notmuch] JSON based emacs UI

[Sebastian Spaeth]

On Mon, 29 Mar 2010 10:17:01 +0100, David Edmondson  wrote:
> > I fear this is not correct. I cloned notmuch from Carl's git repository,
> > and whenever I press 'RET' while the point is over the subject line, the
> > result is the same as pressing 'h': the subject information gets toggled.
> 
> Is this considered a feature that blocks people from switching to the
> JSON based UI?

nahh, that is fine.

[notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

[spaetz]

hehe, this version compiles but has the logic inverted. Removing the ! from
your patch makes it actually work as intended :--).
-- 
View this message in context: 
http://n3.nabble.com/PATCH-Prevent-data-loss-caused-by-SIGINT-during-notmuch-new-tp677501p684691.html
Sent from the notmuch mailing list archive at Nabble.com.

[notmuch] JSON based emacs UI

[Aneesh Kumar K. V]

On Mon, 29 Mar 2010 10:17:01 +0100, David Edmondson  wrote:
> On Sun, 28 Mar 2010 14:03:44 -0300, Fernando Carrijo  yahoo.com.br> wrote:
> > David Edmondson  wrote:
> > > 'RET' anywhere in the message is supposed to toggle visibility of the
> > > message. That was not working perfectly - a little forced redisplay
> > > helped (just pushed).
> > > 
> > > Toggling the visibility of headers is done with 'h'. There's currently
> > > no way to do that by pressing 'RET' somewhere. (You can also toggle the
> > > body with 'b'.)
> > 
> > I fear this is not correct. I cloned notmuch from Carl's git repository,
> > and whenever I press 'RET' while the point is over the subject line, the
> > result is the same as pressing 'h': the subject information gets toggled.
> 
> Is this considered a feature that blocks people from switching to the
> JSON based UI?
> 

For me it is not an issue and i already switched to jason based ui. The
diff-mode for inline patch itself is a big motivation for me to switch.

-aneesh

[notmuch] JSON based emacs UI

[Fernando Carrijo]

David Edmondson  wrote:
> On Sun, 28 Mar 2010 14:03:44 -0300, Fernando Carrijo  yahoo.com.br> wrote:
> > David Edmondson  wrote:
> > > 'RET' anywhere in the message is supposed to toggle visibility of the
> > > message. That was not working perfectly - a little forced redisplay
> > > helped (just pushed).
> > > 
> > > Toggling the visibility of headers is done with 'h'. There's currently
> > > no way to do that by pressing 'RET' somewhere. (You can also toggle the
> > > body with 'b'.)
> > 
> > I fear this is not correct. I cloned notmuch from Carl's git repository,
> > and whenever I press 'RET' while the point is over the subject line, the
> > result is the same as pressing 'h': the subject information gets toggled.
> 
> Is this considered a feature that blocks people from switching to the
> JSON based UI?

As long as I'm concerned, no.

Not at all!

> 
> dme.
> -- 
> David Edmondson, http://dme.org

[notmuch] JSON based emacs UI

[Michal Sojka]

On Mon, 29 Mar 2010, Sebastian Spaeth wrote:
> On Sun, 28 Mar 2010 07:46:40 +0200, Michal Sojka  
> wrote:
> > I don't think this can be solved only in Makefile. From my look at dme's
> > repo, he adds a new subcomand 'part', which is used by the UI. So if you
> > want to use the new UI and your other features, you need to merge the
> > things together.
> 
> I agree that notmuch and notmuch.el need to be developed deployed in
> close cooperation. However, this bundling makes things a bit more
> complex to untangle. I am willing to e.g. add the -part improvement to
> my own branch of notmuch, but I want to follow dme's frontend closely.
> 
> > To build my version of notmuch, I use an ugly script
> > (http://rtime.felk.cvut.cz/gitweb/notmuch.git/blob/refs/heads/debian-wsh:/wsh-buildpackage)
> > which first does a big octopus merge to combine several features to one
> > branch and then I build notmuch from there. The current state of my
> > integration can be seen at
> > http://rtime.felk.cvut.cz/gitweb/notmuch.git/shortlog/refs/heads/integration/features.
> 
> Interesting, but a bit more complicated that I was originally thinking off.
> 
> > This approach has a disadvantage that integration/features branch is
> > often rewritten (whenever I add, remove or change a patch) so that
> > others cannot track the branch. On the other side, the advantage is that
> > others can easily see which patches I have applied on top of master. If
> > Carl updates master, I just rerun the script and the updated integration
> > branch is ready (unless there is a merge conflict).
> 
> Very nice.

Here is a simplified version of my script. It does only the merge. If
you want to use it, I recommend adding this script to a separate branch
so that you can track which branched were added or removed to your
features branch (you will modify the $branches variable in the script).

#!/bin/sh

branches="
decode-headers-in-reply
dme/citation-suffixes
no-self-bcc-on-reply
"

set -e

die()
{
echo >&2 "fatal: $*"
exit 1
}

if [ -z "$EXEC_OK" ]; then
# If this script is tracked by repository, checking out another
# branch could delete it so we copy it to tmp and run it from
# there.
script=$(mktemp -t notmuch-integrate.XX)
cp "$0" "$script"
EXEC_OK=1
export EXEC_OK
exec sh "$script" "$@"
fi

[ $EXEC_OK != 1 ] && die "Error: something went wrong"

trap "rm '$0'" EXIT

git branch -D integration/features || :
git checkout -b integration/features master
git merge $branches

[notmuch] [PATCH] Fix compilation when getline is not available

[Michal Sojka]

On Mon, 29 Mar 2010, Bhaskara Marthi wrote:
> Hi all, I'm trying to build notmuch on os x (master branch from today).  I
> got the ports for gmime and xapian, and installed talloc from source, with
> some minor hitches (just getting talloc alone from samba failed on autoconf
> due to lack of libreplace.m4, so I installed all of samba from a port; a
> pkg-config file for talloc was not put in the right place after that,
> though, so I had to make one).
> 
> Anyway, now compilation runs into the following error.  Looks like an issue
> with the makefile given that getline is in fact defined in compat/.  How
> should I fix this?

The following patch should fix it.
---
 Makefile  |2 +-
 compat/Makefile.local |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 46f001c..93c6b2b 100644
--- a/Makefile
+++ b/Makefile
@@ -46,7 +46,7 @@ subdirs = compat emacs lib
 global_deps = Makefile Makefile.config Makefile.local \
$(subdirs:%=%/Makefile) $(subdirs:%=%/Makefile.local)

-include Makefile.config Makefile.local $(subdirs:%=%/Makefile.local)
+include Makefile.config $(subdirs:%=%/Makefile.local) Makefile.local

 # The user has not set any verbosity, default to quiet mode and inform the
 # user how to enable verbose compiles.
diff --git a/compat/Makefile.local b/compat/Makefile.local
index 17b4514..9f84c5f 100644
--- a/compat/Makefile.local
+++ b/compat/Makefile.local
@@ -1,7 +1,7 @@
 dir := compat
 extra_cflags += -I$(dir)

-notmuch_compat_srcs =
+notmuch_compat_srcs :=

 ifneq ($(HAVE_GETLINE),1)
 notmuch_compat_srcs += $(dir)/getline.c $(dir)/getdelim.c
-- 
1.7.0.2

[notmuch] JSON based emacs UI

[David Edmondson]

On Sun, 28 Mar 2010 03:41:32 +0200, "Sebastian Spaeth"  wrote:
> It works really nice and I get the (unmeasured) feeling that it is
> faster too (but then it might just be the lack of my additional patches
> which slow things down :-)).

I'm not sure why it would be faster. If you have a long thread that
includes many text/html parts it is clearly slower.

> I have one question (which is more build related): now, I have to pull
> your branch and an make install-emacs will also always compile and
> install the notmuch binary from your branch, but I might want to keep my
> own notmuch binary. Is it possible to just use the notmuch frontend from
> your branch, but not having to install the binary? Is there such a make
> target, or any other way? Should we create a repo that just contains the
> frontend and not notmuch itself, so people can mix and match more
> easily? (not sure what the right answer is here).

As Michal says, you need the 'part' subcommand support. If you have a
patch to the Makefile to help achieve what you want I'd be happy to look
at it.

dme.
-- 
David Edmondson, http://dme.org

[notmuch] JSON based emacs UI

[David Edmondson]

On Sun, 28 Mar 2010 14:03:44 -0300, Fernando Carrijo  
wrote:
> David Edmondson  wrote:
> > 'RET' anywhere in the message is supposed to toggle visibility of the
> > message. That was not working perfectly - a little forced redisplay
> > helped (just pushed).
> > 
> > Toggling the visibility of headers is done with 'h'. There's currently
> > no way to do that by pressing 'RET' somewhere. (You can also toggle the
> > body with 'b'.)
> 
> I fear this is not correct. I cloned notmuch from Carl's git repository,
> and whenever I press 'RET' while the point is over the subject line, the
> result is the same as pressing 'h': the subject information gets toggled.

Is this considered a feature that blocks people from switching to the
JSON based UI?

dme.
-- 
David Edmondson, http://dme.org

[notmuch] JSON based emacs UI

[Sebastian Spaeth]

On Sun, 28 Mar 2010 07:46:40 +0200, Michal Sojka  wrote:
> I don't think this can be solved only in Makefile. From my look at dme's
> repo, he adds a new subcomand 'part', which is used by the UI. So if you
> want to use the new UI and your other features, you need to merge the
> things together.

I agree that notmuch and notmuch.el need to be developed deployed in
close cooperation. However, this bundling makes things a bit more
complex to untangle. I am willing to e.g. add the -part improvement to
my own branch of notmuch, but I want to follow dme's frontend closely.

> To build my version of notmuch, I use an ugly script
> (http://rtime.felk.cvut.cz/gitweb/notmuch.git/blob/refs/heads/debian-wsh:/wsh-buildpackage)
> which first does a big octopus merge to combine several features to one
> branch and then I build notmuch from there. The current state of my
> integration can be seen at
> http://rtime.felk.cvut.cz/gitweb/notmuch.git/shortlog/refs/heads/integration/features.

Interesting, but a bit more complicated that I was originally thinking off.

> This approach has a disadvantage that integration/features branch is
> often rewritten (whenever I add, remove or change a patch) so that
> others cannot track the branch. On the other side, the advantage is that
> others can easily see which patches I have applied on top of master. If
> Carl updates master, I just rerun the script and the updated integration
> branch is ready (unless there is a merge conflict).

Very nice.

Sebastian

[notmuch] [PATCH] Fix compilation when getline is not available

[Bhaskara Marthi]

On Mon, Mar 29, 2010 at 1:43 AM, Michal Sojka  wrote:

> On Mon, 29 Mar 2010, Bhaskara Marthi wrote:
> > Hi all, I'm trying to build notmuch on os x (master branch from today).
>  I
> > got the ports for gmime and xapian, and installed talloc from source,
> with
> > some minor hitches (just getting talloc alone from samba failed on
> autoconf
> > due to lack of libreplace.m4, so I installed all of samba from a port; a
> > pkg-config file for talloc was not put in the right place after that,
> > though, so I had to make one).
> >
> > Anyway, now compilation runs into the following error.  Looks like an
> issue
> > with the makefile given that getline is in fact defined in compat/.  How
> > should I fix this?
>
> The following patch should fix it.
>

Works for me.  Thanks!
- Bhaskara



> ---
>  Makefile  |2 +-
>  compat/Makefile.local |2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 46f001c..93c6b2b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -46,7 +46,7 @@ subdirs = compat emacs lib
>  global_deps = Makefile Makefile.config Makefile.local \
>$(subdirs:%=%/Makefile) $(subdirs:%=%/Makefile.local)
>
> -include Makefile.config Makefile.local $(subdirs:%=%/Makefile.local)
> +include Makefile.config $(subdirs:%=%/Makefile.local) Makefile.local
>
>  # The user has not set any verbosity, default to quiet mode and inform the
>  # user how to enable verbose compiles.
> diff --git a/compat/Makefile.local b/compat/Makefile.local
> index 17b4514..9f84c5f 100644
> --- a/compat/Makefile.local
> +++ b/compat/Makefile.local
> @@ -1,7 +1,7 @@
>  dir := compat
>  extra_cflags += -I$(dir)
>
> -notmuch_compat_srcs =
> +notmuch_compat_srcs :=
>
>  ifneq ($(HAVE_GETLINE),1)
>  notmuch_compat_srcs += $(dir)/getline.c $(dir)/getdelim.c
> --
> 1.7.0.2
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20100329/654bca16/attachment.html>

[notmuch] [PATCH] notmuch-config: make new message tags configurable

[Sebastian Spaeth]

On Fri, 12 Mar 2010 17:13:26 -0500, Ben Gamari  
wrote:
>   /* success */
>   case NOTMUCH_STATUS_SUCCESS:
>   state->added_messages++;
> - tag_inbox_and_unread (message);
> + for (tag=state->new_tags; *tag != NULL; tag++)
> + notmuch_message_add_tag (message, *tag);

notmuch-new.c: In function 'add_files_recursive':
notmuch-new.c:465: warning: assignment from incompatible pointer typ

I was just trying to apply this (in addition to maildir based tagging)
to my branch, and I am getting a compiler warning. Any clue as to how to
fix this?

This is the exact commit:
http://github.com/spaetz/notmuch-all-feature/commit/9beead362971af818697412e9686f96078cdf925#L2R469

Sebastian

[notmuch] [PATCH] notmuch-config: make new message tags configurable

[Michal Sojka]

On Sun, 28 Mar 2010, Ben Gamari wrote:
> On Sun, 28 Mar 2010 07:57:30 +0200, Michal Sojka  
> wrote:
> > On Sun, 28 Mar 2010, Ben Gamari wrote:
> > > On Fri, 12 Mar 2010 17:13:26 -0500, Ben Gamari  > > gmail.com> wrote:
> > > > Add a new_tags option in the [messages] section of the configuration
> > > > file to allow the user to specify which tags should be added to new
> > > > messages by notmuch new.
> > > 
> > > Would anyone oppose this being merged? I've been running with it on a 
> > > daily
> > > basis for the last two weeks and I've had no issues. The migration path is
> > > quite clean as the current behavior is the default.
> > 
> > Hi,
> > 
> > I think that your patch is only a temporary solution. Some people
> > requests the ability to tag messages based on the maildir flags so the
> > question is how would your patch integrate with maildir-based tagging?
> > 
> I would argue that maildir-tagging and basic notmuch new tagging could be
> orthogonal. I think maildir flag tagging should be handled completely by the
> maildir mail store backend. I could be wrong though.
> 
> In fact, now that I think of it, perhaps this patch's functionality belongs in
> the mail store backend as well. I haven't tried your patchset, but it looks
> like it would be trivial to add this as a mailstore option.

I agree. I'll try to add your patch to my mailstore patch set. It will
be enabled only when the default mailstore (called files) is enabled.
I'll move the config option from [messages] to [mailstore] section and
rename it from new_tags to files.new_tags, to stress the fact, that it
applies only for files backed.

Do you agree?

Michal

[notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

[Sebastian Spaeth]

> Oh, sorry. I thought it is so trivial, that I didn't even compile it for
> master. The right version is here:

Thanks, that worked fine now. I pushed it to my branch.

Sebastian

[notmuch] os x getline issues

[Bhaskara Marthi]

Hi all, I'm trying to build notmuch on os x (master branch from today).  I
got the ports for gmime and xapian, and installed talloc from source, with
some minor hitches (just getting talloc alone from samba failed on autoconf
due to lack of libreplace.m4, so I installed all of samba from a port; a
pkg-config file for talloc was not put in the right place after that,
though, so I had to make one).

Anyway, now compilation runs into the following error.  Looks like an issue
with the makefile given that getline is in fact defined in compat/.  How
should I fix this?
- Bhaskara

g++ debugger.o gmime-filter-reply.o notmuch.o notmuch-config.o
notmuch-count.o notmuch-dump.o notmuch-new.o notmuch-reply.o
notmuch-restore.o notmuch-search.o notmuch-search-tags.o notmuch-setup.o
notmuch-show.o notmuch-tag.o notmuch-time.o query-string.o show-message.o
json.o lib/notmuch.a  -L/opt/local/lib -lgmime-2.4 -lz -lgobject-2.0
-lglib-2.0 -lintl -liconv   -L/opt/local/lib/samba3 -ltalloc
-L/opt/local/lib -lxapian -lz -L/opt/local/lib -o notmuch
Undefined symbols:
  "_getline", referenced from:
  _notmuch_restore_command in notmuch-restore.o
  _notmuch_restore_command in notmuch-restore.o
  _notmuch_setup_command in notmuch-setup.o
  _notmuch_setup_command in notmuch-setup.o
  _notmuch_setup_command in notmuch-setup.o
  _notmuch_setup_command in notmuch-setup.o
  _notmuch_setup_command in notmuch-setup.o
  _notmuch_message_file_get_header in notmuch.a(message-file.o)
  _notmuch_message_file_get_header in notmuch.a(message-file.o)
  _notmuch_message_file_get_header in notmuch.a(message-file.o)
  _notmuch_message_file_get_header in notmuch.a(message-file.o)
-- next part --
An HTML attachment was scrubbed...
URL: 

[notmuch] os x getline issues

[Bhaskara Marthi]

Hi all, I'm trying to build notmuch on os x (master branch from today).  I
got the ports for gmime and xapian, and installed talloc from source, with
some minor hitches (just getting talloc alone from samba failed on autoconf
due to lack of libreplace.m4, so I installed all of samba from a port; a
pkg-config file for talloc was not put in the right place after that,
though, so I had to make one).

Anyway, now compilation runs into the following error.  Looks like an issue
with the makefile given that getline is in fact defined in compat/.  How
should I fix this?
- Bhaskara

g++ debugger.o gmime-filter-reply.o notmuch.o notmuch-config.o
notmuch-count.o notmuch-dump.o notmuch-new.o notmuch-reply.o
notmuch-restore.o notmuch-search.o notmuch-search-tags.o notmuch-setup.o
notmuch-show.o notmuch-tag.o notmuch-time.o query-string.o show-message.o
json.o lib/notmuch.a  -L/opt/local/lib -lgmime-2.4 -lz -lgobject-2.0
-lglib-2.0 -lintl -liconv   -L/opt/local/lib/samba3 -ltalloc
-L/opt/local/lib -lxapian -lz -L/opt/local/lib -o notmuch
Undefined symbols:
  _getline, referenced from:
  _notmuch_restore_command in notmuch-restore.o
  _notmuch_restore_command in notmuch-restore.o
  _notmuch_setup_command in notmuch-setup.o
  _notmuch_setup_command in notmuch-setup.o
  _notmuch_setup_command in notmuch-setup.o
  _notmuch_setup_command in notmuch-setup.o
  _notmuch_setup_command in notmuch-setup.o
  _notmuch_message_file_get_header in notmuch.a(message-file.o)
  _notmuch_message_file_get_header in notmuch.a(message-file.o)
  _notmuch_message_file_get_header in notmuch.a(message-file.o)
  _notmuch_message_file_get_header in notmuch.a(message-file.o)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

[Sebastian Spaeth]

 Oh, sorry. I thought it is so trivial, that I didn't even compile it for
 master. The right version is here:

Thanks, that worked fine now. I pushed it to my branch.

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

Re: [notmuch] [PATCH] notmuch-config: make new message tags configurable

[Sebastian Spaeth]

On Fri, 12 Mar 2010 17:13:26 -0500, Ben Gamari bgamari.f...@gmail.com wrote:
   /* success */
   case NOTMUCH_STATUS_SUCCESS:
   state-added_messages++;
 - tag_inbox_and_unread (message);
 + for (tag=state-new_tags; *tag != NULL; tag++)
 + notmuch_message_add_tag (message, *tag);

notmuch-new.c: In function 'add_files_recursive':
notmuch-new.c:465: warning: assignment from incompatible pointer typ

I was just trying to apply this (in addition to maildir based tagging)
to my branch, and I am getting a compiler warning. Any clue as to how to
fix this?

This is the exact commit:
http://github.com/spaetz/notmuch-all-feature/commit/9beead362971af818697412e9686f96078cdf925#L2R469

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

[notmuch] [PATCH] Fix compilation when getline is not available

[Michal Sojka]

On Mon, 29 Mar 2010, Bhaskara Marthi wrote:
 Hi all, I'm trying to build notmuch on os x (master branch from today).  I
 got the ports for gmime and xapian, and installed talloc from source, with
 some minor hitches (just getting talloc alone from samba failed on autoconf
 due to lack of libreplace.m4, so I installed all of samba from a port; a
 pkg-config file for talloc was not put in the right place after that,
 though, so I had to make one).
 
 Anyway, now compilation runs into the following error.  Looks like an issue
 with the makefile given that getline is in fact defined in compat/.  How
 should I fix this?

The following patch should fix it.
---
 Makefile  |2 +-
 compat/Makefile.local |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 46f001c..93c6b2b 100644
--- a/Makefile
+++ b/Makefile
@@ -46,7 +46,7 @@ subdirs = compat emacs lib
 global_deps = Makefile Makefile.config Makefile.local \
$(subdirs:%=%/Makefile) $(subdirs:%=%/Makefile.local)
 
-include Makefile.config Makefile.local $(subdirs:%=%/Makefile.local)
+include Makefile.config $(subdirs:%=%/Makefile.local) Makefile.local
 
 # The user has not set any verbosity, default to quiet mode and inform the
 # user how to enable verbose compiles.
diff --git a/compat/Makefile.local b/compat/Makefile.local
index 17b4514..9f84c5f 100644
--- a/compat/Makefile.local
+++ b/compat/Makefile.local
@@ -1,7 +1,7 @@
 dir := compat
 extra_cflags += -I$(dir)
 
-notmuch_compat_srcs =
+notmuch_compat_srcs :=
 
 ifneq ($(HAVE_GETLINE),1)
 notmuch_compat_srcs += $(dir)/getline.c $(dir)/getdelim.c
-- 
1.7.0.2
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] JSON based emacs UI

[Michal Sojka]

On Mon, 29 Mar 2010, Sebastian Spaeth wrote:
 On Sun, 28 Mar 2010 07:46:40 +0200, Michal Sojka sojk...@fel.cvut.cz wrote:
  I don't think this can be solved only in Makefile. From my look at dme's
  repo, he adds a new subcomand 'part', which is used by the UI. So if you
  want to use the new UI and your other features, you need to merge the
  things together.
 
 I agree that notmuch and notmuch.el need to be developed deployed in
 close cooperation. However, this bundling makes things a bit more
 complex to untangle. I am willing to e.g. add the -part improvement to
 my own branch of notmuch, but I want to follow dme's frontend closely.
 
  To build my version of notmuch, I use an ugly script
  (http://rtime.felk.cvut.cz/gitweb/notmuch.git/blob/refs/heads/debian-wsh:/wsh-buildpackage)
  which first does a big octopus merge to combine several features to one
  branch and then I build notmuch from there. The current state of my
  integration can be seen at
  http://rtime.felk.cvut.cz/gitweb/notmuch.git/shortlog/refs/heads/integration/features.
 
 Interesting, but a bit more complicated that I was originally thinking off.
 
  This approach has a disadvantage that integration/features branch is
  often rewritten (whenever I add, remove or change a patch) so that
  others cannot track the branch. On the other side, the advantage is that
  others can easily see which patches I have applied on top of master. If
  Carl updates master, I just rerun the script and the updated integration
  branch is ready (unless there is a merge conflict).
 
 Very nice.

Here is a simplified version of my script. It does only the merge. If
you want to use it, I recommend adding this script to a separate branch
so that you can track which branched were added or removed to your
features branch (you will modify the $branches variable in the script).

#!/bin/sh

branches=
decode-headers-in-reply
dme/citation-suffixes
no-self-bcc-on-reply


set -e

die()
{
echo 2 fatal: $*
exit 1
}

if [ -z $EXEC_OK ]; then
# If this script is tracked by repository, checking out another
# branch could delete it so we copy it to tmp and run it from
# there.
script=$(mktemp -t notmuch-integrate.XX)
cp $0 $script
EXEC_OK=1
export EXEC_OK
exec sh $script $@
fi

[ $EXEC_OK != 1 ]  die Error: something went wrong

trap rm '$0' EXIT

git branch -D integration/features || :
git checkout -b integration/features master
git merge $branches
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] JSON based emacs UI

[David Edmondson]

On Sun, 28 Mar 2010 14:03:44 -0300, Fernando Carrijo fcarr...@yahoo.com.br 
wrote:
 David Edmondson d...@dme.org wrote:
  'RET' anywhere in the message is supposed to toggle visibility of the
  message. That was not working perfectly - a little forced redisplay
  helped (just pushed).
  
  Toggling the visibility of headers is done with 'h'. There's currently
  no way to do that by pressing 'RET' somewhere. (You can also toggle the
  body with 'b'.)
 
 I fear this is not correct. I cloned notmuch from Carl's git repository,
 and whenever I press 'RET' while the point is over the subject line, the
 result is the same as pressing 'h': the subject information gets toggled.

Is this considered a feature that blocks people from switching to the
JSON based UI?

dme.
-- 
David Edmondson, http://dme.org
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] JSON based emacs UI

[Aneesh Kumar K. V]

On Mon, 29 Mar 2010 10:17:01 +0100, David Edmondson d...@dme.org wrote:
 On Sun, 28 Mar 2010 14:03:44 -0300, Fernando Carrijo fcarr...@yahoo.com.br 
 wrote:
  David Edmondson d...@dme.org wrote:
   'RET' anywhere in the message is supposed to toggle visibility of the
   message. That was not working perfectly - a little forced redisplay
   helped (just pushed).
   
   Toggling the visibility of headers is done with 'h'. There's currently
   no way to do that by pressing 'RET' somewhere. (You can also toggle the
   body with 'b'.)
  
  I fear this is not correct. I cloned notmuch from Carl's git repository,
  and whenever I press 'RET' while the point is over the subject line, the
  result is the same as pressing 'h': the subject information gets toggled.
 
 Is this considered a feature that blocks people from switching to the
 JSON based UI?
 

For me it is not an issue and i already switched to jason based ui. The
diff-mode for inline patch itself is a big motivation for me to switch.

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

Re: [notmuch] JSON based emacs UI

[Sebastian Spaeth]

On Mon, 29 Mar 2010 10:17:01 +0100, David Edmondson d...@dme.org wrote:
  I fear this is not correct. I cloned notmuch from Carl's git repository,
  and whenever I press 'RET' while the point is over the subject line, the
  result is the same as pressing 'h': the subject information gets toggled.
 
 Is this considered a feature that blocks people from switching to the
 JSON based UI?

nahh, that is fine.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [notmuch] [PATCH] Prevent data loss caused by SIGINT during notmuch new

[spaetz]

hehe, this version compiles but has the logic inverted. Removing the ! from
your patch makes it actually work as intended :--).
-- 
View this message in context: 
http://n3.nabble.com/PATCH-Prevent-data-loss-caused-by-SIGINT-during-notmuch-new-tp677501p684691.html
Sent from the notmuch mailing list archive at Nabble.com.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch