Maybe another consistent solution is to add a --format argument to
count, with JSON as one option. That way we could even add more
information to other count results (if that becomes needed at some
point) without breaking code using the JSON interface.
Best regards,
Daniel
Vagrant wrote:
,
| When in tree view mode, if I reply to an encrypted message and the point
| is the selected message in the threaded tree (as opposed to the
| currently viewed message), the message reply doesn't contain any quoted
| content (even though decryption was successful), and
pipermail/notmuch/attachments/20150812/ed4132c4/attachment.mht>
Tomi Ollila writes:
> $ notmuch metadata uuid
> $ notmuch metadata lastmod
> $ notmuch metadata uuid lastmod
> $ notmuch metadata lastmod uuid
>
> Now we can bikeshed whether this is good idea --
it seems OK. We will have some set of 'fake' metadata keys that are not
actually stored in xapian
On Tue, Aug 11 2015, David Bremner wrote:
> Tomi Ollila writes:
>
>> Currently, `notmuch count` outputs lines that contain just one integer;
>> this changes this by introducing output with uuid ([0-9a-f-]) and integer
>> delimited by tab character.
>>
>> To put it lightly, this looks
Tomi Ollila tomi.oll...@iki.fi writes:
$ notmuch metadata uuid
$ notmuch metadata lastmod
$ notmuch metadata uuid lastmod
$ notmuch metadata lastmod uuid
Now we can bikeshed whether this is good idea --
it seems OK. We will have some set of 'fake' metadata keys that are not
actually
---BeginMessage---
Package: notmuch-emacs
Version: 0.18.2-1
Severity: normal
Thanks for maintaining notmuch!
When in tree view mode, if I reply to an encrypted message and the
point is the selected message in the threaded tree (as opposed to the
currently viewed message), the message reply
Vagrant wrote:
,
| When in tree view mode, if I reply to an encrypted message and the point
| is the selected message in the threaded tree (as opposed to the
| currently viewed message), the message reply doesn't contain any quoted
| content (even though decryption was successful), and
Maybe another consistent solution is to add a --format argument to
count, with JSON as one option. That way we could even add more
information to other count results (if that becomes needed at some
point) without breaking code using the JSON interface.
Best regards,
Daniel
