[PATCH 5/6] cli: add global option "--db-revision"
Daniel Schoepe writes: > On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote: >> +``--db-revision=UUID`` >> + Enforce that the database revision is UUID. This is useful to >> + detect rollover in modification counts on messages. You can >> + find this UUID in the first column of output from >> + ``notmuch count --output=modifications`` > > I'm not sure if the wording here is entirely clear. When reading this > the first time, to me it sounded like it might give you a view of the > database from when the revision was UUID. Maybe we can clarify here that > this will result in notmuch exiting if the revision is not matched. Sure, no problem with expanding what "Enforce" means. Some improvment of the names as discussed in a previous message might help here also. d
[PATCH 2/6] lib: Add per-message last modification tracking
Daniel Schoepe writes:
> On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
>> +/* Prior to NOTMUCH_FEATURE_LAST_MOD, messages did not
>> + * track modification revisions. Give all messages a
>> + * revision of 1.
>> + */
>> +if (new_features & NOTMUCH_FEATURE_LAST_MOD)
>> +_notmuch_message_upgrade_last_mod (message);
>> [..]
>> +/* Upgrade a message to support NOTMUCH_FEATURE_LAST_MOD. The caller
>> + * must call _notmuch_message_sync. */
>> +void
>> +_notmuch_message_upgrade_last_mod (notmuch_message_t *message)
>> +{
>> +/* _notmuch_message_sync will update the last modification
>> + * revision; we just have to ask it to. */
>> +message->modified = TRUE;
>> +}
>> +
>
> The comment in the first part says that message without LAST_MOD get a
> revision of 1, but as far as I can tell, _notmuch_message_sync will
> actually put the next revision number on the message. If this is what's
> happening, either the comment or the behavior should be changed,
> depending on what's intended.
I think the behaviour is OK, but you're correct the comment is
wrong. I'll see if Austin has any comment on that. I guess it would be
harmless to initialize upgraded messages to some low revision number,
but I don't see the benefit.
[PATCH 6/6] lib: Add "lastmod:" queries for filtering by last modification
Daniel Schoepe writes: > > It might be helpful to describe why --db-revision is needed here. At > first glance, just using `notmuch search lastmod:UUID..' looks good > enough to get all changed messages since UUID. Indeed, it's not entirely > clear to me under what conditions just using this query causes problems. > Moreover, it would be quite nice and intuitive if that query did the job > without having to constrain the database revision manually as well. There are two notions of revision here, and I agree the naming could be clearer. I blame Austin ;). --db-revision refers to the major-revision/epoch ; this is only changed e.g. when the the database is re-created from scratch. lastmod:a..b refers to integers that increase with every database operation. Maybe --db-revision should be called --db-uuid ; this is at least consistent with the library API. In answer to why it's needed, the database changing UUID signals any externally stored modification information (e.g. for incremental backups) is now invalid. d
[PATCH] NEWS: emacs: notmuch-{cli,emacs}-version usage
Tomi Ollila writes: > News for notmuch-emacs-version usage in User-Agent header and > rename of function notmuch-version to notmuch-cli-version. > > While at it, made some minor (consistency) punctuation changes > to make news to wiki conversion work as expected. pushed. d
[PATCH] test: make script exit (1) if it "fails" to source (.) a file
Tomi Ollila writes: > At the end of all source (.) lines construct ' || exit 1' was added; pushed, d
[Bug] Force creating of Mail/sent on sending?
Bastien writes: > Hi all, > > I installed notmuch yesterday, when I heard David's talk at the GNU > hackers meeting -- great tool! Thanks for the work. > > My configuration is here: http://bzg.fr/emacs.html (browse down to the > notmuch section, click on it.) > > If I require 'notmuch, then sending from Gnus asks me whether I want > to create Mail/sent -- I don't want to, sent emails go to the current > group. > > Is there a way to avoid notmuch asking this? > Hi Bastien. I think this is finally fixed in notmuch master. The workaround should continue to work, but I thought you might like to know your bug report was not in vain ;). d
[PATCH 2/2] emacs: make modifications to message Fcc vars buffer-local
David Bremner writes: > > Oops, missed that part. Pushed both with edited commit messages. And a whitespace cleanup patch. d
[PATCH 2/2] emacs: make modifications to message Fcc vars buffer-local
Tomi Ollila writes: > capitalization could be consistent in the commit message. > > One thing come to my mind: would it be possible to use buffer-local > variable message-fcc-handler-function in notmuch-message-mode buffers so > that such wrapper functions defined below would not be needed. i.e. > > (make-local-variable 'message-fcc-handler-function) > (setq message-fcc-handler-function #'notmuch-fcc-handler) > > (or not? :D) > > one more thing (extra newline) inline below > Oops, missed that part. Pushed both with edited commit messages.
[PATCH 6/6] lib: Add "lastmod:" queries for filtering by last modification
On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote: > +The **lastmod:** prefix can be used to restrict the result by the > +database revision number of when messages were last modified (tags > +were added/removed or filenames changed). This is usually used in > +conjunction with the **--db-revision** argument to **notmuch search** > +to find messages that have changed since an earlier query. It might be helpful to describe why --db-revision is needed here. At first glance, just using `notmuch search lastmod:UUID..' looks good enough to get all changed messages since UUID. Indeed, it's not entirely clear to me under what conditions just using this query causes problems. Moreover, it would be quite nice and intuitive if that query did the job without having to constrain the database revision manually as well. Best regards, Daniel
[PATCH 5/6] cli: add global option "--db-revision"
On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote: > +``--db-revision=UUID`` > + Enforce that the database revision is UUID. This is useful to > + detect rollover in modification counts on messages. You can > + find this UUID in the first column of output from > + ``notmuch count --output=modifications`` I'm not sure if the wording here is entirely clear. When reading this the first time, to me it sounded like it might give you a view of the database from when the revision was UUID. Maybe we can clarify here that this will result in notmuch exiting if the revision is not matched. Best regards, Daniel
[PATCH 2/6] lib: Add per-message last modification tracking
Hi,
On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
> + /* Prior to NOTMUCH_FEATURE_LAST_MOD, messages did not
> + * track modification revisions. Give all messages a
> + * revision of 1.
> + */
> + if (new_features & NOTMUCH_FEATURE_LAST_MOD)
> + _notmuch_message_upgrade_last_mod (message);
> [..]
> +/* Upgrade a message to support NOTMUCH_FEATURE_LAST_MOD. The caller
> + * must call _notmuch_message_sync. */
> +void
> +_notmuch_message_upgrade_last_mod (notmuch_message_t *message)
> +{
> +/* _notmuch_message_sync will update the last modification
> + * revision; we just have to ask it to. */
> +message->modified = TRUE;
> +}
> +
The comment in the first part says that message without LAST_MOD get a
revision of 1, but as far as I can tell, _notmuch_message_sync will
actually put the next revision number on the message. If this is what's
happening, either the comment or the behavior should be changed,
depending on what's intended.
Best regards,
Daniel
[PATCH 2/2] emacs: make modifications to message Fcc vars buffer-local
On Thu, Aug 06 2015, David Bremner wrote: > Tomi Ollila writes: > >> >> One thing come to my mind: would it be possible to use buffer-local >> variable message-fcc-handler-function in notmuch-message-mode buffers so >> that such wrapper functions defined below would not be needed. i.e. >> >> (make-local-variable 'message-fcc-handler-function) >> (setq message-fcc-handler-function #'notmuch-fcc-handler) >> > > This was my first approach, and I actually filed > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21174 > > about why it doesn't work. > > Great minds think alike / Fools seldom differ, as they say ;) Uh ;/ You could add some note about buffer-local variables not applicable in this context for future archeologists to understand ;) -- either in commit message or in comment.. > > d Tomi
Re: [PATCH 2/6] lib: Add per-message last modification tracking
Daniel Schoepe dan...@schoepe.org writes:
On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
+/* Prior to NOTMUCH_FEATURE_LAST_MOD, messages did not
+ * track modification revisions. Give all messages a
+ * revision of 1.
+ */
+if (new_features NOTMUCH_FEATURE_LAST_MOD)
+_notmuch_message_upgrade_last_mod (message);
[..]
+/* Upgrade a message to support NOTMUCH_FEATURE_LAST_MOD. The caller
+ * must call _notmuch_message_sync. */
+void
+_notmuch_message_upgrade_last_mod (notmuch_message_t *message)
+{
+/* _notmuch_message_sync will update the last modification
+ * revision; we just have to ask it to. */
+message-modified = TRUE;
+}
+
The comment in the first part says that message without LAST_MOD get a
revision of 1, but as far as I can tell, _notmuch_message_sync will
actually put the next revision number on the message. If this is what's
happening, either the comment or the behavior should be changed,
depending on what's intended.
I think the behaviour is OK, but you're correct the comment is
wrong. I'll see if Austin has any comment on that. I guess it would be
harmless to initialize upgraded messages to some low revision number,
but I don't see the benefit.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 5/6] cli: add global option --db-revision
Daniel Schoepe dan...@schoepe.org writes: On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote: +``--db-revision=UUID`` + Enforce that the database revision is UUID. This is useful to + detect rollover in modification counts on messages. You can + find this UUID in the first column of output from + ``notmuch count --output=modifications`` I'm not sure if the wording here is entirely clear. When reading this the first time, to me it sounded like it might give you a view of the database from when the revision was UUID. Maybe we can clarify here that this will result in notmuch exiting if the revision is not matched. Sure, no problem with expanding what Enforce means. Some improvment of the names as discussed in a previous message might help here also. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 5/6] cli: add global option --db-revision
On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote: +``--db-revision=UUID`` + Enforce that the database revision is UUID. This is useful to + detect rollover in modification counts on messages. You can + find this UUID in the first column of output from + ``notmuch count --output=modifications`` I'm not sure if the wording here is entirely clear. When reading this the first time, to me it sounded like it might give you a view of the database from when the revision was UUID. Maybe we can clarify here that this will result in notmuch exiting if the revision is not matched. Best regards, Daniel ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 6/6] lib: Add lastmod: queries for filtering by last modification
On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote: +The **lastmod:** prefix can be used to restrict the result by the +database revision number of when messages were last modified (tags +were added/removed or filenames changed). This is usually used in +conjunction with the **--db-revision** argument to **notmuch search** +to find messages that have changed since an earlier query. It might be helpful to describe why --db-revision is needed here. At first glance, just using `notmuch search lastmod:UUID..' looks good enough to get all changed messages since UUID. Indeed, it's not entirely clear to me under what conditions just using this query causes problems. Moreover, it would be quite nice and intuitive if that query did the job without having to constrain the database revision manually as well. Best regards, Daniel ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/6] lib: Add per-message last modification tracking
Hi,
On Fri, 05 Jun 2015 19:28 +0200, David Bremner wrote:
+ /* Prior to NOTMUCH_FEATURE_LAST_MOD, messages did not
+ * track modification revisions. Give all messages a
+ * revision of 1.
+ */
+ if (new_features NOTMUCH_FEATURE_LAST_MOD)
+ _notmuch_message_upgrade_last_mod (message);
[..]
+/* Upgrade a message to support NOTMUCH_FEATURE_LAST_MOD. The caller
+ * must call _notmuch_message_sync. */
+void
+_notmuch_message_upgrade_last_mod (notmuch_message_t *message)
+{
+/* _notmuch_message_sync will update the last modification
+ * revision; we just have to ask it to. */
+message-modified = TRUE;
+}
+
The comment in the first part says that message without LAST_MOD get a
revision of 1, but as far as I can tell, _notmuch_message_sync will
actually put the next revision number on the message. If this is what's
happening, either the comment or the behavior should be changed,
depending on what's intended.
Best regards,
Daniel
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] emacs: make modifications to message Fcc vars buffer-local
Tomi Ollila tomi.oll...@iki.fi writes: capitalization could be consistent in the commit message. One thing come to my mind: would it be possible to use buffer-local variable message-fcc-handler-function in notmuch-message-mode buffers so that such wrapper functions defined below would not be needed. i.e. (make-local-variable 'message-fcc-handler-function) (setq message-fcc-handler-function #'notmuch-fcc-handler) (or not? :D) one more thing (extra newline) inline below Oops, missed that part. Pushed both with edited commit messages. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] NEWS: emacs: notmuch-{cli,emacs}-version usage
Tomi Ollila tomi.oll...@iki.fi writes: News for notmuch-emacs-version usage in User-Agent header and rename of function notmuch-version to notmuch-cli-version. While at it, made some minor (consistency) punctuation changes to make news to wiki conversion work as expected. pushed. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 6/6] lib: Add lastmod: queries for filtering by last modification
Daniel Schoepe dan...@schoepe.org writes: It might be helpful to describe why --db-revision is needed here. At first glance, just using `notmuch search lastmod:UUID..' looks good enough to get all changed messages since UUID. Indeed, it's not entirely clear to me under what conditions just using this query causes problems. Moreover, it would be quite nice and intuitive if that query did the job without having to constrain the database revision manually as well. There are two notions of revision here, and I agree the naming could be clearer. I blame Austin ;). --db-revision refers to the major-revision/epoch ; this is only changed e.g. when the the database is re-created from scratch. lastmod:a..b refers to integers that increase with every database operation. Maybe --db-revision should be called --db-uuid ; this is at least consistent with the library API. In answer to why it's needed, the database changing UUID signals any externally stored modification information (e.g. for incremental backups) is now invalid. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] emacs: make modifications to message Fcc vars buffer-local
David Bremner da...@tethera.net writes: Oops, missed that part. Pushed both with edited commit messages. And a whitespace cleanup patch. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [Bug] Force creating of Mail/sent on sending?
Bastien b...@altern.org writes: Hi all, I installed notmuch yesterday, when I heard David's talk at the GNU hackers meeting -- great tool! Thanks for the work. My configuration is here: http://bzg.fr/emacs.html (browse down to the notmuch section, click on it.) If I require 'notmuch, then sending from Gnus asks me whether I want to create Mail/sent -- I don't want to, sent emails go to the current group. Is there a way to avoid notmuch asking this? Hi Bastien. I think this is finally fixed in notmuch master. The workaround should continue to work, but I thought you might like to know your bug report was not in vain ;). d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] test: make script exit (1) if it fails to source (.) a file
Tomi Ollila tomi.oll...@iki.fi writes: At the end of all source (.) lines construct ' || exit 1' was added; pushed, d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] fixup! lib: Add per-message last modification tracking
--- Now that I take a second look at the code, I think Austin's original commit is correct, if a bit terse. Here is how I have expanded it in the revised series. lib/database.cc | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/lib/database.cc b/lib/database.cc index 0650c63..bab3334 100644 --- a/lib/database.cc +++ b/lib/database.cc @@ -1473,8 +1473,9 @@ notmuch_database_upgrade (notmuch_database_t *notmuch, _notmuch_message_upgrade_folder (message); /* Prior to NOTMUCH_FEATURE_LAST_MOD, messages did not -* track modification revisions. Give all messages a -* revision of 1. +* track modification revisions. Give all messages the +* next available revision; since we just started tracking +* revisions for this database, that will be 1. */ if (new_features NOTMUCH_FEATURE_LAST_MOD) _notmuch_message_upgrade_last_mod (message); -- 2.1.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
