[PATCH 3/5] cli/count: add --output=modifications
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 Cascadian] Bug#795243: notmuch-emacs: reply-to encrypted messages in tree view fails to quote and defaults to unencrypted message
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 defaults to an | unencrypted message. | | If the point is in the currently viewed message, it behaves as | expected, quoting the message and defaulting to signencrypt. ` I can duplicate this behaviour in 20.2 d
[Vagrant Cascadian] Bug#795243: notmuch-emacs: reply-to encrypted messages in tree view fails to quote and defaults to unencrypted message
An embedded message was scrubbed... From: Vagrant Cascadian <vagr...@debian.org> Subject: Bug#795243: notmuch-emacs: reply-to encrypted messages in tree view fails to quote and defaults to unencrypted message Date: Wed, 12 Aug 2015 10:30:50 +0200 Size: 6210 URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20150812/ed4132c4/attachment.mht>
[PATCH 3/5] cli/count: add --output=modifications
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 metadata. Perversely this includes both lastmod and uuid > and what to do (and when) > if unknown key is used in request... Error out, I'd say, but if it's not one of our fake metadata items we can in general just ask xapian for that value of that metadata, and complain if it doesn't exist.
[PATCH 3/5] cli/count: add --output=modifications
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 "inconsistent" and don't please my aesthetic >> eye. >> >> One option (being it worse or better) could be that by default only >> lastmod value is printed and with separate option it is prefixed with >> database UUID (in every --output option). > > Can you think of any use case for the uuid with the other count outputs? > It feels pretty artificial to me. I don't... I just thought something consistent to be used w/ notmuch count... > Another option is to make a "notmuch metadata" command. I'm not really > sure about the syntax, but perhaps a uuid option makes more sense > there, so e.g. > >notmuch metadata --with-uuid lastmod or notmuch metadata key [key [key]], then (currently) we could have: $ notmuch metadata uuid $ notmuch metadata lastmod $ notmuch metadata uuid lastmod $ notmuch metadata lastmod uuid Now we can bikeshed whether this is good idea -- and what to do (and when) if unknown key is used in request... Tomi > I'm pretty convinced that we need report uuid and lastmod together (at > least optionally). I'm less sure we need a full get/set interface for > metadata, since people with that use case could use xapian-metadata. >
Re: [PATCH 3/5] cli/count: add --output=modifications
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 stored in xapian metadata. Perversely this includes both lastmod and uuid and what to do (and when) if unknown key is used in request... Error out, I'd say, but if it's not one of our fake metadata items we can in general just ask xapian for that value of that metadata, and complain if it doesn't exist. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[Vagrant Cascadian] Bug#795243: notmuch-emacs: reply-to encrypted messages in tree view fails to quote and defaults to unencrypted message
---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 doesn't contain any quoted content (even though decryption was successful), and defaults to an unencrypted message. If the point is in the currently viewed message, it behaves as expected, quoting the message and defaulting to signencrypt. It would be ideal if it would default to containing the quoted text of the replied to message and defaulting to encrypting in both cases, otherwise the user may accidentally send information unencrypted, or possibly even reply to the wrong message without realizing it. live well, vagrant -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (120, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages notmuch-emacs depends on: ii emacs24 24.4+1-5 ii emacsen-common 2.0.8 ii notmuch 0.18.2-1 notmuch-emacs recommends no packages. notmuch-emacs suggests no packages. -- no debconf information signature.asc Description: PGP signature ---End Message--- ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [Vagrant Cascadian] Bug#795243: notmuch-emacs: reply-to encrypted messages in tree view fails to quote and defaults to unencrypted message
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 defaults to an | unencrypted message. | | If the point is in the currently viewed message, it behaves as | expected, quoting the message and defaulting to signencrypt. ` I can duplicate this behaviour in 20.2 d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 3/5] cli/count: add --output=modifications
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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
