Re: [PATCH v3 0/7] Port notmuch-show's x/X bindings to notmuch-tree
On Sat 2019-12-28 10:01:17 -0500, William Casarin wrote: > These patches bring notmuch-tree more in line with the user experience > of notmuch-show by adding the x/X bindings. It looks like this series has been reviewed by dme, and is presumably approved by him, with the exception of patch 3/7, which id:m25zhyxasu@dme.org suggests some improvement on. William, would you be up for doing one last re-spin of this series to address dme's comments? it'd be nice to land this series unless someone raises objections. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: export notmuch_database_reopen
On Thu 2020-02-20 19:16:23 +0100, Reto wrote:
> On 20 February 2020 18:18:52 CET, Daniel Kahn Gillmor
> wrote:
>>if you have a read/write DB, then the changes you make to the DB are
>>also visible, right? it's not a static snapshot in that sense.
>
> Ehm, not the behavior I've seen while I was testing it out, but that may have
> been my fault then?
Just to confirm/clarify:
If i run the following python3 code against a database with your message
in it:
```
import notmuch2
db = notmuch2.Database(mode=notmuch2.Database.MODE.READ_WRITE)
print("before:")
for m in db.messages('tag:testing123'):
print(m.messageid)
db.find('95638E1C-E025-4863-9F6C-DAF7F8CD4B1A@labrat.space').tags.add('testing123')
print("after:")
for m in db.messages('tag:testing123'):
print(m.messageid)
db.find('95638E1C-E025-4863-9F6C-DAF7F8CD4B1A@labrat.space').tags.remove('testing123')
```
It prints:
```
before:
after:
95638E1C-E025-4863-9F6C-DAF7F8CD4B1A@labrat.space
```
The fact that "before:" shows nothing, and "after:" shows that the
message ID was tagged suggests to me that changes i make to a r/w
database object *are* reflected in subsequent queries to the same
database object.
Anyway, i agree that it'd be nice to be able to refresh a read-only
database object with a new view of the db if the underlying db has
changed. However, i wonder what happens to any existing message objects
that are hanging off of the database object at the time that the
database gets reopened. Should all of those objects all be refreshed as
well?
For example, consider a message object that you can use to enumerate
tags. When the associated database is reopened, should the enumerated
list of tags change for that message object?
--dkg
signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Forcing a sync of maildir flags?
Sean Whitton writes: > So, your hypothesis is that notmuch is opting not to add the Seen flag > in order to avoid having to move the message from new to cur, for the > sake of mutt, but that's a bug because I've explicitly requested adding > Seen, so it ought to go ahead and move it from new to cur? Yeah, I think that's the case. This is based only vague memories of when I wrote 0082a557. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Forcing a sync of maildir flags?
Hello David, Thank you for your reply. On Thu 20 Feb 2020 at 08:22AM -04, David Bremner wrote: > Sean Whitton writes: > >> I have this in my post-new hook: >> >> notmuch tag -unread -- folder:sent >> >> The idea is that copies of my sent mail which get returned to me and >> stored in my inbox, e.g. by mailing lists, would get maildir Seen tags >> added to them. But that does not happen. > > I guess this is most likely a bug. It would be nice to have a test in > T340-maildir-sync.sh that duplicated it. I suspect the problem is > related to messages in the new/ subdirectory. Some non-notmuch clients > (prominently mutt) interpret being in new/ has having user-visible > semantics, so notmuch tries not to move files out of there > unnecessarily, On the other hand the maildir spec says that files in > new/ cannot have flags, so they cannot have their unread tag removed > without moving the file to cur/ So, your hypothesis is that notmuch is opting not to add the Seen flag in order to avoid having to move the message from new to cur, for the sake of mutt, but that's a bug because I've explicitly requested adding Seen, so it ought to go ahead and move it from new to cur? >> This works: >> >> notmuch tag +unread -- folder:sent >> notmuch tag -unread -- folder:sent >> >> Is there some more elegant way to force a sync of maildir flags? Am I >> the only one that has copies of my own mail in my inbox folder, not >> marked as read from the point of view of anything except notmuch? > > I guess my workflow doesn't expose this problem as I leave many messages > unread (relying on the inbox flag). I'm not sure about the locking > implications, but having sent messages delivered to cur/ instead of to > new/ would probably workaround the problem. In this case it's mbsync downloading messages from IMAP, and there doesn't seem to be a way to configure it to deliver to cur instead of new. On Thu 20 Feb 2020 at 09:21AM -04, David Bremner wrote: > I guess the other thing is that I have > > [new] > tags=unread;inbox;new > > in .notmuch-config, which means that "notmuch new" moves things into > cur/. Maybe you can use that effect? To be honest that doesn't seem really better than the workaround I'm currently using. -- Sean Whitton ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] doc: add a hint about field processor support availability
On Sun 2020-01-12 17:13:59 +0200, Tomi Ollila wrote: > But, if we already made Xapian 1.4 minimun requirement in the next notmuch > release, there XAPIAN_FIELD_PROCESSOR is always supported and all these > conditionals could be removed (before even adding new)... I'd support making Xapian 1.4 a minimum requirement in the next notmuch release, particularly if someone does the work to provide a mostly-minus patchset that cleans up the legacy conditionals. fwiw, xapian 1.4 was part of debian oldstable (stretch), which was released in mid-2017. I don't think it's a problem to require a dependency of that vintage. --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 2/2] sprinter: change integer method to use int64_t
On Thu 2020-02-13 19:13:51 -0400, David Bremner wrote: > Peter Wang writes: > >> In particular, timestamps beyond 2038 could overflow the sprinter >> interface on systems where time_t is 64-bit but 'int' is a signed 32-bit >> integer type. > > Series pushed to master. I'm a bit slow following up on this, but just wanted to say thanks to Peter for his fix here. This kind of additional robustness is definitely appreciated, even well before Y2038. And especially in the face of malicious input, which is basically the only thing that notmuch deals with! --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: export notmuch_database_reopen
On 20 February 2020 18:18:52 CET, Daniel Kahn Gillmor wrote: >if you have a read/write DB, then the changes you make to the DB are >also visible, right? it's not a static snapshot in that sense. Ehm, not the behavior I've seen while I was testing it out, but that may have been my fault then? >I think you're asking about a situation where you have a read-only DB, >and someone else has modified the database in the meantime. Is that >correct? Yeah, something along those lines. >In that case, it might also be nice to be able to detect *when* some >other change has been made, so that you can perform such a reopen. That'd be great yes. Thanks for the follow up. Cheers, Reto ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: export notmuch_database_reopen
On Thu 2020-02-13 22:11:27 +0100, Reto wrote: > I'm trying to use the notmuch C library in a mail client. > Now, I learned that an open DB is essentially a snapshot at the time of > opening. > If I want the current state of the notmuch DB, I need to reopen the DB. if you have a read/write DB, then the changes you make to the DB are also visible, right? it's not a static snapshot in that sense. I think you're asking about a situation where you have a read-only DB, and someone else has modified the database in the meantime. Is that correct? In that case, it might also be nice to be able to detect *when* some other change has been made, so that you can perform such a reopen. I don't know xapian well enough to know whether that kind if inter-process signalling is possible, though. Maybe Olly can provide some guidance here? --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Forcing a sync of maildir flags?
David Bremner writes: >> This works: >> >> notmuch tag +unread -- folder:sent >> notmuch tag -unread -- folder:sent >> >> Is there some more elegant way to force a sync of maildir flags? Am I >> the only one that has copies of my own mail in my inbox folder, not >> marked as read from the point of view of anything except notmuch? > > I guess my workflow doesn't expose this problem as I leave many messages > unread (relying on the inbox flag). I'm not sure about the locking > implications, but having sent messages delivered to cur/ instead of to > new/ would probably workaround the problem. I guess the other thing is that I have [new] tags=unread;inbox;new in .notmuch-config, which means that "notmuch new" moves things into cur/. Maybe you can use that effect? d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Forcing a sync of maildir flags?
Sean Whitton writes: > I have this in my post-new hook: > > notmuch tag -unread -- folder:sent > > The idea is that copies of my sent mail which get returned to me and > stored in my inbox, e.g. by mailing lists, would get maildir Seen tags > added to them. But that does not happen. I guess this is most likely a bug. It would be nice to have a test in T340-maildir-sync.sh that duplicated it. I suspect the problem is related to messages in the new/ subdirectory. Some non-notmuch clients (prominently mutt) interpret being in new/ has having user-visible semantics, so notmuch tries not to move files out of there unnecessarily, On the other hand the maildir spec says that files in new/ cannot have flags, so they cannot have their unread tag removed without moving the file to cur/ > This works: > > notmuch tag +unread -- folder:sent > notmuch tag -unread -- folder:sent > > Is there some more elegant way to force a sync of maildir flags? Am I > the only one that has copies of my own mail in my inbox folder, not > marked as read from the point of view of anything except notmuch? I guess my workflow doesn't expose this problem as I leave many messages unread (relying on the inbox flag). I'm not sure about the locking implications, but having sent messages delivered to cur/ instead of to new/ would probably workaround the problem. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
