output file argument to notmuch dump.

2011-10-07 Thread Tomi Ollila
On Fri 07 Oct 2011 13:23, Jesse Rosenthal  writes:

> On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner  wrote:
>> 1) just delete the output file option from notmuch-dump, and use shell
>>redirection. So far I don't see a non-contrived example when writing
>>an output file directly is useful, but maybe that is just a failure
>>of imagination.
>> 
>> 2) delete the output file option and a global "--write" option that 
>>calls freopen(... stdout). As a bonus(?) this would work for any 
>>notmuch command.
>
> Either of these seem like the right approach to me. I might favor (1)
> just a bit so I don't have to choose between different ways of doing the
> same thing, but that's a small point. As Jamie said, they're pretty
> much the same.

The option 2, i.e. optional --write (or -o|--output) should be available;
someone may run notmuch without using environment that provides
redirections (or it is just plain simpler to give the command line option
instead of doing redirections).

> --Jesse

Tomi


[PATCH] emacs: Add callback functions to crypto sigstatus button.

2011-10-07 Thread Jameson Graef Rollins
On Fri, 07 Oct 2011 09:38:00 +0200, Thomas Schwinge  
wrote:
> Now, what happens on redisplay is that (apparently) all the current state
> is lost: the point jumps back to its original position (the beginning of
> the buffer, for example), messages/parts view toggles are reset, etc.  I
> guess that is just how the refresh function works -- but is it really
> what we want, and how difficult would it be to preserve that state?

Hi, Thomas.  I agree it would be nice to jump back to the same state in
the thread view that you were at previously.  There's not currently any
good way to do that, though, I don't think.  We would have to be
writing/saving a lot more of the current buffer state.  Suggestions and
patches are of course welcome.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20111007/532eb35b/attachment-0001.pgp>


output file argument to notmuch dump.

2011-10-07 Thread Jameson Graef Rollins
On Fri, 07 Oct 2011 14:15:39 +0300, Tomi Ollila  wrote:
> The option 2, i.e. optional --write (or -o|--output) should be available;
> someone may run notmuch without using environment that provides
> redirections (or it is just plain simpler to give the command line option
> instead of doing redirections).

If that were the case then none of the other notmuch commands would work
in the environment either.  If that's a concern, then notmuch should
have a generic --redirect option that works for all commands, as Tom
suggested out earlier.

jamie.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20111007/7e2c1a0d/attachment.pgp>


[PATCH] emacs: Add callback functions to crypto sigstatus button.

2011-10-07 Thread Thomas Schwinge
Hi!

On Tue, 31 May 2011 10:07:13 -0700, Jameson Graef Rollins  wrote:
> This adds two callback functions to the sigstatus button.  If the sig

First, thanks for this!

> status is "good", then clicking the button displays the output of "gpg
> --list-keys" on the key fingerprint.  If the sigstatus is "bad", then
> clicking the button will retrieve the key from the keyserver, and
> redisplay the current buffer.

Now, what happens on redisplay is that (apparently) all the current state
is lost: the point jumps back to its original position (the beginning of
the buffer, for example), messages/parts view toggles are reset, etc.  I
guess that is just how the refresh function works -- but is it really
what we want, and how difficult would it be to preserve that state?


Gr??e,
 Thomas
-- 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/20111007/44c81cd6/attachment.pgp>


tag sharing

2011-10-07 Thread Jesse Rosenthal
On Fri, 07 Oct 2011 07:36:30 -0400, Jesse Rosenthal  
wrote:
> What's the value added over just keeping a (compressed?) collection of
> diffs for each namespace?

Okay -- please don't bother answering this part. It was early in the
morning, and I forgot some of the obvious advantages of real version
control (we can roll back to a previous moment, etc). We still don't
need most of what git offers, but if it's the best tool for keeping
track of the move from the file in step (5) to the file in step (6),
then sure, let's use it.


tag sharing

2011-10-07 Thread Jesse Rosenthal
On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner  wrote:
Non-text part: multipart/signed
> On Thu, 06 Oct 2011 09:21:48 -0400, Jesse Rosenthal  
> wrote:
> > morning's project. In retrospect, I think the main issue was that I was
> > trying to figure out how history would be kept. By using git, though,
> > your idea would be that we get history for free, right?
> 
> Yeah. Of course, one would have to decide if the history of the current
> dump file format is intelligible, or if some alternative format should
> be used.

I've managed to reconstruct a bit of my thinking. I think it could work
with the current format if we went as follows. I also think we could use
git, but I'm not sure that wouldn't be overkill. Some of the steps are
in extreme slow motion, just to make sure we're on the same page. (I've
also replaced the real msg-ids to cut down on noise).

  1. David dumps the targeted messages (tags in namespace "my"), so we
 get a file like this:

  msg-id-1 at example.1 (my.foo inbox)
  msg-id-2 at example.2 (answered my.to-do inbox signed)

  2. David strips out everything but tags in the namespace and removes
 the namespace:

  msg-id-1 at example.1 (foo)
  msg-id-2 at example.2 (to-do)

  3. David makes it available, Jesse pulls.

  4. Jesse dumps the namespace he has associated with David ("bremner"):

  msg-id-3 at example.3 (bremner.bar)
  msg-id-4 at example.4 (bremner.bar unread)
  msg-id-1 at example.1 (bremner.foo inbox)
  msg-id-5 at example.5 (bremner.wishlist inbox)

  5. Jesse strips the tags:

  msg-id-3 at example.3 (bar)
  msg-id-4 at example.4 (bar)
  msg-id-1 at example.1 (foo)
  msg-id-5 at example.5 (wishlist)

  6. Jesse replaces this list with David's:

  msg-id-1 at example.1 (foo)
  msg-id-2 at example.2 (to-do)

  7. Jesse removes all tags with the "bremner" namespace from his
 database.

  8. Jesse adds the tags from the list in step (6), with the appropriate
 namespace, to his list of tags. The messages of interest now look like:

  msg-id-3 at example.3 ()
  msg-id-4 at example.4 (unread)
  msg-id-1 at example.1 (bremner.foo inbox)
  msg-id-5 at example.5 (inbox)
  msg-id-2 at example.2 (bremner.to-do someothertag)

  9. Jesse runs `notmuch restore`

The reason I went through this slowly is to highlight the fact that the
only thing that needs to be recorded in diffs somehow (in git, let's
say) are the files in steps (5) and (6). So if we integrated this with
git, there would be something along the lines of a commit (on Jesse's
computer) in step (5) and then another commit (again on Jesse's
computer) in step (6). 

Note that we don't actually need (5) to do tag-sharing. The only reason
it's there is for keeping history.

I'm pretty sure that we don't need a commit on David's computer in step
(1), because what the history would record is when the tag-sharing
utility changed your tags, not when you did.

Note also that all we would really be asking git to do here is keep an
ordered collection of diffs of a single file. Honest question: since
this is the barest possible form of version control, is git necessary?
Some of the features, like commit messages, don't seem to fit well with
this model; and others, like branching, seem pretty useless. What's the
value added over just keeping a (compressed?) collection of diffs for
each namespace?

Best,
Jesse


output file argument to notmuch dump.

2011-10-07 Thread Jesse Rosenthal
On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner  wrote:
> 1) just delete the output file option from notmuch-dump, and use shell
>redirection. So far I don't see a non-contrived example when writing
>an output file directly is useful, but maybe that is just a failure
>of imagination.
> 
> 2) delete the output file option and a global "--write" option that 
>calls freopen(... stdout). As a bonus(?) this would work for any 
>notmuch command.

Either of these seem like the right approach to me. I might favor (1)
just a bit so I don't have to choose between different ways of doing the
same thing, but that's a small point. As Jamie said, they're pretty
much the same.

--Jesse


output file argument to notmuch dump.

2011-10-07 Thread Dmitry Kurochkin
On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner  wrote:
> 
> I'd like to add a search term argument to notmuch dump (see
> id:"87wrcijn1w.fsf at zancas.localnet" and followup for context). The
> "notmuch" way would be to have
> 
> notmuch dump 
> 
> do the right thing, and that is easy enough _except_ that 
> 
>notmuch dump foo
> 
> writes the output to file foo.
> 
> I see several options.
> 
> 1) just delete the output file option from notmuch-dump, and use shell
>redirection. So far I don't see a non-contrived example when writing
>an output file directly is useful, but maybe that is just a failure
>of imagination.
> 
> 2) delete the output file option and a global "--write" option that 
>calls freopen(... stdout). As a bonus(?) this would work for any 
>notmuch command.
> 
> 3) leave the output option alone and implement a --query=foo option for 
>notmuch dump. This would be the most backward compatible of course,
>but also confusing for users.
> 
> Thoughts?
> 

IMHO 1[+2] is the way.  It breaks the dump command interface, but would
make it consistent with other commands.  Implementing the second option
(for all commands) is nice but independent and optional.  Also, perhaps
--output, --output-file or smth would a better name than --write.

Regards,
  Dmitry

> d
> 
> 
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: Add callback functions to crypto sigstatus button.

2011-10-07 Thread Thomas Schwinge
Hi!

On Tue, 31 May 2011 10:07:13 -0700, Jameson Graef Rollins 
jroll...@finestructure.net wrote:
 This adds two callback functions to the sigstatus button.  If the sig

First, thanks for this!

 status is good, then clicking the button displays the output of gpg
 --list-keys on the key fingerprint.  If the sigstatus is bad, then
 clicking the button will retrieve the key from the keyserver, and
 redisplay the current buffer.

Now, what happens on redisplay is that (apparently) all the current state
is lost: the point jumps back to its original position (the beginning of
the buffer, for example), messages/parts view toggles are reset, etc.  I
guess that is just how the refresh function works -- but is it really
what we want, and how difficult would it be to preserve that state?


Grüße,
 Thomas


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


Re: output file argument to notmuch dump.

2011-10-07 Thread Jesse Rosenthal
On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner brem...@unb.ca wrote:
 1) just delete the output file option from notmuch-dump, and use shell
redirection. So far I don't see a non-contrived example when writing
an output file directly is useful, but maybe that is just a failure
of imagination.
 
 2) delete the output file option and a global --write option that 
calls freopen(... stdout). As a bonus(?) this would work for any 
notmuch command.

Either of these seem like the right approach to me. I might favor (1)
just a bit so I don't have to choose between different ways of doing the
same thing, but that's a small point. As Jamie said, they're pretty
much the same.

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


Re: output file argument to notmuch dump.

2011-10-07 Thread Tomi Ollila
On Fri 07 Oct 2011 13:23, Jesse Rosenthal jrosent...@jhu.edu writes:

 On Thu, 06 Oct 2011 21:20:40 -0300, David Bremner brem...@unb.ca wrote:
 1) just delete the output file option from notmuch-dump, and use shell
redirection. So far I don't see a non-contrived example when writing
an output file directly is useful, but maybe that is just a failure
of imagination.
 
 2) delete the output file option and a global --write option that 
calls freopen(... stdout). As a bonus(?) this would work for any 
notmuch command.

 Either of these seem like the right approach to me. I might favor (1)
 just a bit so I don't have to choose between different ways of doing the
 same thing, but that's a small point. As Jamie said, they're pretty
 much the same.

The option 2, i.e. optional --write (or -o|--output) should be available;
someone may run notmuch without using environment that provides
redirections (or it is just plain simpler to give the command line option
instead of doing redirections).

 --Jesse

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


Re: tag sharing

2011-10-07 Thread Jesse Rosenthal
On Thu, 06 Oct 2011 11:18:51 -0300, David Bremner da...@tethera.net wrote:
Non-text part: multipart/signed
 On Thu, 06 Oct 2011 09:21:48 -0400, Jesse Rosenthal jrosent...@jhu.edu 
 wrote:
  morning's project. In retrospect, I think the main issue was that I was
  trying to figure out how history would be kept. By using git, though,
  your idea would be that we get history for free, right?
 
 Yeah. Of course, one would have to decide if the history of the current
 dump file format is intelligible, or if some alternative format should
 be used.

I've managed to reconstruct a bit of my thinking. I think it could work
with the current format if we went as follows. I also think we could use
git, but I'm not sure that wouldn't be overkill. Some of the steps are
in extreme slow motion, just to make sure we're on the same page. (I've
also replaced the real msg-ids to cut down on noise).

  1. David dumps the targeted messages (tags in namespace my), so we
 get a file like this:
  
  msg-id-1@example.1 (my.foo inbox)
  msg-id-2@example.2 (answered my.to-do inbox signed)

  2. David strips out everything but tags in the namespace and removes
 the namespace:

  msg-id-1@example.1 (foo)
  msg-id-2@example.2 (to-do)

  3. David makes it available, Jesse pulls.

  4. Jesse dumps the namespace he has associated with David (bremner):

  msg-id-3@example.3 (bremner.bar)
  msg-id-4@example.4 (bremner.bar unread)
  msg-id-1@example.1 (bremner.foo inbox)
  msg-id-5@example.5 (bremner.wishlist inbox)

  5. Jesse strips the tags:

  msg-id-3@example.3 (bar)
  msg-id-4@example.4 (bar)
  msg-id-1@example.1 (foo)
  msg-id-5@example.5 (wishlist)

  6. Jesse replaces this list with David's:

  msg-id-1@example.1 (foo)
  msg-id-2@example.2 (to-do)

  7. Jesse removes all tags with the bremner namespace from his
 database.

  8. Jesse adds the tags from the list in step (6), with the appropriate
 namespace, to his list of tags. The messages of interest now look like:

  msg-id-3@example.3 ()
  msg-id-4@example.4 (unread)
  msg-id-1@example.1 (bremner.foo inbox)
  msg-id-5@example.5 (inbox)
  msg-id-2@example.2 (bremner.to-do someothertag)

  9. Jesse runs `notmuch restore`

The reason I went through this slowly is to highlight the fact that the
only thing that needs to be recorded in diffs somehow (in git, let's
say) are the files in steps (5) and (6). So if we integrated this with
git, there would be something along the lines of a commit (on Jesse's
computer) in step (5) and then another commit (again on Jesse's
computer) in step (6). 

Note that we don't actually need (5) to do tag-sharing. The only reason
it's there is for keeping history.

I'm pretty sure that we don't need a commit on David's computer in step
(1), because what the history would record is when the tag-sharing
utility changed your tags, not when you did.

Note also that all we would really be asking git to do here is keep an
ordered collection of diffs of a single file. Honest question: since
this is the barest possible form of version control, is git necessary?
Some of the features, like commit messages, don't seem to fit well with
this model; and others, like branching, seem pretty useless. What's the
value added over just keeping a (compressed?) collection of diffs for
each namespace?

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


Re: tag sharing

2011-10-07 Thread Jesse Rosenthal
On Fri, 07 Oct 2011 07:36:30 -0400, Jesse Rosenthal jrosent...@jhu.edu wrote:
 What's the value added over just keeping a (compressed?) collection of
 diffs for each namespace?

Okay -- please don't bother answering this part. It was early in the
morning, and I forgot some of the obvious advantages of real version
control (we can roll back to a previous moment, etc). We still don't
need most of what git offers, but if it's the best tool for keeping
track of the move from the file in step (5) to the file in step (6),
then sure, let's use it.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: output file argument to notmuch dump.

2011-10-07 Thread Jameson Graef Rollins
On Fri, 07 Oct 2011 14:15:39 +0300, Tomi Ollila tomi.oll...@iki.fi wrote:
 The option 2, i.e. optional --write (or -o|--output) should be available;
 someone may run notmuch without using environment that provides
 redirections (or it is just plain simpler to give the command line option
 instead of doing redirections).

If that were the case then none of the other notmuch commands would work
in the environment either.  If that's a concern, then notmuch should
have a generic --redirect option that works for all commands, as Tom
suggested out earlier.

jamie.


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


Re: [PATCH] emacs: Add callback functions to crypto sigstatus button.

2011-10-07 Thread Jameson Graef Rollins
On Fri, 07 Oct 2011 09:38:00 +0200, Thomas Schwinge tho...@schwinge.name 
wrote:
 Now, what happens on redisplay is that (apparently) all the current state
 is lost: the point jumps back to its original position (the beginning of
 the buffer, for example), messages/parts view toggles are reset, etc.  I
 guess that is just how the refresh function works -- but is it really
 what we want, and how difficult would it be to preserve that state?

Hi, Thomas.  I agree it would be nice to jump back to the same state in
the thread view that you were at previously.  There's not currently any
good way to do that, though, I don't think.  We would have to be
writing/saving a lot more of the current buffer state.  Suggestions and
patches are of course welcome.

jamie.


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