add and remove tags

[frasertweedale]

expose functions for add/remove tags. This depends on #10 (r/w database mode).

[frasertweedale]

Internally (i.e. behind the C pointer) a message points back to the database it came from. Currently we detach the Message from the Database. There is not yet any auto-finalisation of the DB nor any explicit way to do it in hs-notmuch.

It seems clear that we (a) need a legit way of closing DBs that are not in use and (b) need to associate Message values with the DB they came from. (Likewise Query and, presumably, Thread).

[romanofski]

I'm now realising that I'm blocking on closing purebred-mua/purebred#37 since I'll have to remove a tag from the mail once someone "reads" it. I'll keep it open or see if I can help out ...

[frasertweedale]

On Sat, Aug 12, 2017 at 11:08:16PM -0700, Roman Joost wrote:

I'm now realising that I'm blocking on closing purebred-mua/purebred#37 since I'll have to remove a tag from the mail once someone "reads" it. I'll keep it open or see if I can help out ...

Yeah I knew this was coming soon :)

It's gonna be quite challenging because the notmuch DB is open read-only be default. I thought about how to do a while back but now I mostly forgot :)

Anyhow I'll try and tackle it during this week.

[frasertweedale]

Getting close now. Just a few functions left to implement.

@romanofski I propose first to implement a wholesale "tag replacement" function, with the type:

messageSetTags
  :: Message RW       --  ^ Message tagged with RW database mode
  -> [Tag]                   -- ^ list of tags
  -> IO ()

This will atomically replace all the tags of a message.

After this, if we really do need separate add-tag, remove-all-tags, freeze and thaw functions we can expose them. I have a hunch that the single function above will be fine for our needs, though (i.e. it is a safe API for the common thing).

[romanofski]

Sounds good. Can't wait to try it out. If you'd want to support only adding it removing tags, you think the application should handle it? That is invoking the function with the right set of tags depending of the operation?

[frasertweedale]

On Tue, Aug 29, 2017 at 01:13:35AM -0700, Roman Joost wrote:

Sounds good. Can't wait to try it out. If you'd want to support only adding it removing tags, you think the application should handle it? That is invoking the function with the right set of tags depending of the operation?

Right. "replace all tags" can be used to implement add or remove functionality.

That said it may well be worth adding the individual add/remove functions. Can do later if we want it.

[frasertweedale]

@romanofski done. Refactor to new tip of master a221f7c46e25b715a7aae770c56c29bca0384e27. See program tools/TagMessage.hs for an example.

Quite a few types changed (mostly by adding type parameters).

General pattern is to open (a copy of) the database as R/W, do the work, and close the database. See Control.Exception.bracket - a useful function for doing this sort of resource management.

Let me know if you have any questions!

If you decide that you want standalone add/remove tag functions please open separate ticket.

[frasertweedale]

@romanofski see also example program tools/Files.hs for how to provide type annotation for opening the database read-only.

[frasertweedale]

@romanofski or use databaseOpenReadOnly convenience function that I just added ^_^ (257fa8c7beb515fb79906ddd72f5ea419fe8df49)

[romanofski]

\o/ w000t looking forward to try it out. Good stuff, mate!!