Re: [PATCH] emacs: Add callback functions to crypto sigstatus button.
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 pgprHUsMq78kv.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: output file argument to notmuch dump.
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: output file argument to notmuch dump.
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: tag sharing
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@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
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. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: output file argument to notmuch dump.
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. 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.
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. pgpvxmyyu7ht4.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
output file argument to notmuch dump.
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
[PATCH] emacs: Add callback functions to crypto sigstatus button.
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>
output file argument to notmuch dump.
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.
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
tag sharing
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
tag sharing
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.
output file argument to notmuch dump.
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.
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>
