* notcoal, filters not made from (char)coal / initial tagging system @ 2018-11-12 0:14 eaon 2018-11-12 13:29 ` Kim ALLAMANDOLA 0 siblings, 1 reply; 6+ messages in thread From: eaon @ 2018-11-12 0:14 UTC (permalink / raw) To: notmuch Hi notmuch list, I built a thing that maybe other people might be interested in: https://crates.io/crates/notcoal "notmuch filters, not made from (char)coal" notcoal provides both a library as well as a standalone binary. The latter can be used as an "initial tagging" system, the former may be integrated into a bigger e-mail client making use of https://crates.io/crates/notmuch If you have cargo set up already you can install it quite easily with: $ cargo install notcoal --features=standalone Cheers, eaon ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: notcoal, filters not made from (char)coal / initial tagging system 2018-11-12 0:14 notcoal, filters not made from (char)coal / initial tagging system eaon @ 2018-11-12 13:29 ` Kim ALLAMANDOLA 2018-11-12 17:59 ` David Bremner 2018-11-12 18:04 ` eaon 0 siblings, 2 replies; 6+ messages in thread From: Kim ALLAMANDOLA @ 2018-11-12 13:29 UTC (permalink / raw) To: notmuch Hi, being a new notmuch user (using it since around an year) I have a small, obscenely written, badly shaped, mixed language collection of homegrown scripts to automate my message handling / mail-based workflow. Most part are zsh wrappers to autotag (autorefile for now is done by IMAPFilter) and support manual delete/refile messages, a small part in an initial state is automation in the sense of extracting mime attachments (via uudeview) like periodic invoices and properly archive, renaming attachments etc in a personal docs taxonomy so having a more well-shaped and ready out-of-the box solution is really welcomed! The only part I do not like too much is the choice of json instead of something, *for me*, less ugly to write/read, less error-prone and more flexible like simple plain guile (GNU embeddable, lightweight scheme dialect). The re-write of notmuch in Rust, well... it's outside my scope since I use it as a "final product", I'm in general favourable to ditch "myths" like C and C++ and Java, ... for more comfortable languages but for me nor Rust nor Go really fell in that category, IMO the best paths is rediscover lisp/scheme languages even if I know that in some cases are harder to use (while far easier in other) however as said before I'm only a user so I have to thanks all notmuch and notmuch-related devs for their wonderful works, I'll try Rust port anyway :-) -- Kim ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: notcoal, filters not made from (char)coal / initial tagging system 2018-11-12 13:29 ` Kim ALLAMANDOLA @ 2018-11-12 17:59 ` David Bremner 2018-11-12 18:21 ` Kim ALLAMANDOLA 2018-11-12 18:04 ` eaon 1 sibling, 1 reply; 6+ messages in thread From: David Bremner @ 2018-11-12 17:59 UTC (permalink / raw) To: Kim ALLAMANDOLA, notmuch Kim ALLAMANDOLA <kim-nmml@kfx.fr> writes: > The only part I do not like too much is the choice of json instead of > something, *for me*, less ugly to write/read, less error-prone and more > flexible like simple plain guile (GNU embeddable, lightweight scheme > I don't know the context of this statement, but "notmuch show" and "notmuch search" support --format=sexp. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: notcoal, filters not made from (char)coal / initial tagging system 2018-11-12 17:59 ` David Bremner @ 2018-11-12 18:21 ` Kim ALLAMANDOLA 0 siblings, 0 replies; 6+ messages in thread From: Kim ALLAMANDOLA @ 2018-11-12 18:21 UTC (permalink / raw) To: notmuch Hi, > I don't know the context of this statement, but "notmuch show" and > "notmuch search" support --format=sexp. Oh, nice, I do not know that, thanks. It can be nice for some macro automation, I'll try it! -- Kim ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: notcoal, filters not made from (char)coal / initial tagging system 2018-11-12 13:29 ` Kim ALLAMANDOLA 2018-11-12 17:59 ` David Bremner @ 2018-11-12 18:04 ` eaon 2018-11-12 19:20 ` Kim ALLAMANDOLA 1 sibling, 1 reply; 6+ messages in thread From: eaon @ 2018-11-12 18:04 UTC (permalink / raw) To: Kim ALLAMANDOLA; +Cc: notmuch Hi Kim, On 12 Nov 08:29, Kim ALLAMANDOLA wrote: > … so having a more well-shaped and ready out-of-the box solution is really > welcomed! Thanks! Yeah, my organically grown python script really annoyed me too, but the segfault problems just pushed me over the edge to try and make something that may be useful to others too. There's still a couple features missing to have it be as useful as I'd like it to be, but it's a start. I'm certainly open to feedback! > The only part I do not like too much is the choice of json instead of > something, *for me*, less ugly to write/read, less error-prone and more > flexible like simple plain guile (GNU embeddable, lightweight scheme > dialect). I get it. The choice really mostly came down to https://serde.rs/ because it is such a nice library and very easy to use. It does support other data formats but I haven't tried any of them. So yeah, I can look into making the input format more flexible for sure. > The re-write of notmuch in Rust […] Ah, misunderstanding there, maybe. notmuch-rs is not a rewrite or port, it's just an interface/bindings for libnotmuch. A couple people have attempted that before, I just used the one that someone seemed to actively try to maintain and take patches for. As for language preferences, Rust is really just something I got into recently, and it's fun, the tooling around it is cool even though the centralisation of some of the infrastructure is something that annoys me a bit. But that is made up by the open welcoming community. eaon ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: notcoal, filters not made from (char)coal / initial tagging system 2018-11-12 18:04 ` eaon @ 2018-11-12 19:20 ` Kim ALLAMANDOLA 0 siblings, 0 replies; 6+ messages in thread From: Kim ALLAMANDOLA @ 2018-11-12 19:20 UTC (permalink / raw) To: eaon; +Cc: notmuch Hi, > There's still a couple features missing to have it be as useful as I'd > like it to be, but it's a start. I'm certainly open to feedback! For me it's already really nice, essentially overlap some afew features in a more flexible/extendable manner. My personal automation add mostly physical message manipulation that can be generalized only to a certain extent: for instance I have a script that look for mail from my mobile carrier invoices and automatically extract attached pdf to a specific taxonomy with a name generated from the invoice number and month pdfgrep-ed from the pdf itself, same for home ISP, another that look for "invoice notification" by EDF (home electricity provider) that do not offer invoices sent as attachments and so add a reminder to manually download them from EDF's portal in my agenda plus adding "periodic" self-reading consumption communication schedule/deadline, they also take care of archiving (mark unread) messages, delete some messages after a certain amount of time, "snooze" others (mark read upon arrival and at a certain point in time mark unread again), forge&send new message as a poor man's agenda notification when I'm not on my desktop (like on mobile)... I'll plan to add a cross-check from invoices to bank movements (ledger) to send a remainder if after a certain amount of time an invoice does not appear to be paid from my bank etc. Many of those function have some common points and can be cleaned up, unified in a single language (actually are a mix of zsh scripts, hy scripts, python scripts, horribly interconnect in "chain-calls") and inserted in a single library to create a generic tool flexible enough to be useful for others but they are essentially a sort of chaotic, primitive PIM suite around an email-centric workflow, the opposite of notmuch philosophy I suspect. Also many functionality are actually crude wrappers around other tools that can't be cleanly integrated in a new one (like IMAPFilter, alot, uudeview, pdfgrep, pdftotext, ledger, ...) so it's more than a simple cleanup and translation... >> The re-write of notmuch in Rust […] > Ah, misunderstanding there, maybe. notmuch-rs is not a rewrite or > port, it's just an interface/bindings for libnotmuch. Ops... Honestly I look only at notcoal page ignoring the rest leaving a remainder for next weekend to give a real try :-( -- Kim ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-11-12 21:56 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-11-12 0:14 notcoal, filters not made from (char)coal / initial tagging system eaon 2018-11-12 13:29 ` Kim ALLAMANDOLA 2018-11-12 17:59 ` David Bremner 2018-11-12 18:21 ` Kim ALLAMANDOLA 2018-11-12 18:04 ` eaon 2018-11-12 19:20 ` Kim ALLAMANDOLA
Code repositories for project(s) associated with this public inbox https://yhetil.org/notmuch.git/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).