Re: macOS and go language bindings
Hi both, I realize I am a bit late to the party, nevertheless here's some information. > I'm trying to build an email client (aerc) with support for notmuch > on macOS. aerc is written in go. I can't find an aerc package for brew > which includes notmuch headers/library files. Where can I get these > language bindings and how do I "install" them, or where do I place them > in the aerc source directory to get the notmuch library built and then > accessible to aerc? You are confusing things here. Aerc wrote their own go notmuch bindings which uses the C library directly. Stuff in contrib/ doesn't matter whatsoever. So you don't install the "language bindings", it's part of the aerc source already. All you need to make sure is that the C compiler go invokes finds the dependencies. Meaning you need libnotmuch installed or build from source. > GO111MODULE > Controls whether the go command runs in module-aware mode or GOPATH > mode. > May be "off", "on", or "auto". > See https://golang.org/ref/mod#mod-commands. > > So, I set my GO111MODULE to off with this command: > go env -w GO111MODULE="off" Do not mess with that, aerc is a proper module aware source. `Go build` will fetch the go dependencies it needs automatically. > I wonder if anyone proficient with Go might know how to get the source > to build against a Go 1.20+ version? If by source you mean aerc, make will do (within their source tree). However, you need to make sure that your C compiler is setup properly. Go will execute a C compiler / linker as usual. In your case, you basically need to setup 2 things: 1) notmuch.h in some include dir, normally /usr/include/notmuch.h or some such, which is needed by the compiler. 2) libnotmuch.so, which is normally located at /usr/lib/libnotmuch.so or some such, which is needed by the linker. I have no clue where brew stores those things, shouldn't be too hard to figure out though. Assuming that's not in some standard dir your C compiler / linker already look (else the build would work) you can override that by setting some env vars. CGO_CFLAGS: set that to "-I/usr/include" where /usr/include is the folder where notmuch.h resides CGO_LDFLAGS: set that tho "-L/usr/lib" where /usr/lib is the folder where libnotmuch.so resides. That will make the C side of things do what you expect. The rest is handled by go. Cheers, Reto ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Create tags from folders
On Mon, Aug 08, 2022 at 10:39:36PM -0300, David Bremner wrote: > e.g. query:python as > 'folder:reto@labrat.space/INBOX.lists.python-list' > This has the advantage that you don't have to retag when new files are > added, which is often the desired behaviour. Thanks, I do use queries for some things. I anyhow have a tagging script to do the initial tagging (also does some relatively naive spam removal, archiving of older messages, kill lists etc). Complicated queries just split the config in two then, some logic would be in the tagging script and other things in the config, which I find personally a step back rather than an improvement. Especially as I will have to archive the inboxes at one point or another, making the folder query fail (or me having to specify the archive dir in the folder query as well). Out of interest, how does your workflow look like? All based on folder queries? Greetings, Reto ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Create tags from folders
On Mon, Aug 08, 2022 at 05:30:29PM +0300, Tomi Ollila wrote: > On Sun, Aug 07 2022, Notmuch mailinglist wrote: > > It is kinda duplicate information to have mail tagged with same name > as the folder it is located in... but there may be reasons one would > like to do such a thing -- and at least I am interested (at least a bit) > why. Well, for starters folders may change (say archiving those on the imap side), the semantic tags do not. Second, I let notmuch index multiple email addresses in the same store, meaning my folder queries are then nested rather deep. So my lovely tag:python query amounts to `notmuch search 'folder:reto@labrat.space/INBOX.lists.python-list'` Which... is a mouthful. Regexes aren't a solution, just makes it now two problems as I have multiple python lists that could match ;) Cheers, Reto PS: not op, but also re-tagging even though I have emails filtered to dedicated folders via sieve. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Noob question about config
On Tue, Aug 17, 2021 at 12:15:59AM +0300, rrandom wrote: >Why notmuch needs user.name and user.primary_email variables? It's used by the emacs frontend for notmuch. >I use notmuch with neomutt to search mail, do I need these vars? Will it >somehow affect on anything? No, neomutt has its own config for things like aliases and addresses. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: should notmuch handle or generate message responses (RFC 9078) (or, "why can't i an e-mail message?")
On Fri, Aug 06, 2021 at 09:35:52AM +0200, Ralph Seichter wrote: > I believe that implementing this feature would be a waste of your > talents, but that is of course for you to decide. +1 :P ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Is there a reason why the trashed flag is not synced?
On Tue, May 11, 2021 at 08:48:45AM +0200, Michael J Gruber wrote: > If you sync gmail labels to exact copies in different folders then you're not > holding it right, sorry ;) > Gmail is not an IMAP service; it has an IMAP API which exposes labels as > folders, with all the caveats which this implies. That's why there are > better ways to sync Gmail with a notmuch mail store (gmailieer). Better is always a relative term. I prefer a standardized protocol over some homebrew stuff. > I don't think notmuch should break its design principle (1 message id, 1 > message) just to work around a problem caused by a wrong sync procedure: > that "delete instruction" is a result (merely: artifact) of speaking IMAP to > Gmail. It's not only gmail, really any IMAP server. If you have a message in multiple folders at the same time (which is entirely reasonable, think "todo" + where it actually should go after processing). They all have the same message ID. Only because you delete the copy from todo doesn't mean that you want it gone from other places as well. Sure, you could move instead of copying... But that means that you may now need to hunt through multiple folders instead of being able to grab the message from the actual mbox it should be in. IMAP doesn't impose a workflow, just because yours happens to be a certain way doesn't make it the gold standard ;) Cheers, Reto ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Is there a reason why the trashed flag is not synced?
On Mon, May 10, 2021 at 03:31:52PM +0200, Michael J Gruber wrote: > Deleting by chance is more harmful, yes. But is it more typical to clear > out duplicate files using "T" or to delete a message (i.e. all it's file > copies)? You have to be a bit careful here... imap is a relatively strange protocol. Consider a provider like gmail that uses a label system over normal imap folders. If you assign a message "inbox" and "vacation" and maybe "archive" and then want to remove the message from inbox and vacation folders you execute delete instructions. That however, certainly shouldn't propagate to the "archive" copy. So I'd argue that in fact no, what you mention is not the "typical" thing to do. At least not with those providers. Not all MUAs behave the same in regards to whether or not they set the trash flag first. Yes, you can tell neomutt to do almost anything, but if setting the Trash flag on one message starts deleting all other copies I'd be very much surprised. ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: notmuch release 0.32 now available
Awesome, thanks a lot for all your hard work. And with that I'd like to include anyone that contributed, naturally. Cheers, Reto ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH 02/19] lib: add stub for notmuch_database_open_with_config
On Sat, Aug 08, 2020 at 11:16:36AM -0300, David Bremner wrote: > +/* NOTMUCH_DEPRECATED(5, 4) */ > +notmuch_status_t > +notmuch_database_open_verbose (const char *path, > +notmuch_database_mode_t mode, > +notmuch_database_t **database, > +char **error_message); > + > +/** > + * Open an existing notmuch database located at 'database_path', using > + * configuration in 'config_path'. > + * > + * @param[in]database_path > + * @parblock > + * Path to existing database. > + * > + * A notmuch database is a Xapian database containing appropriate > + * metadata. > * > * The database should have been created at some time in the past, > * (not necessarily by this process), by calling > - * notmuch_database_create with 'path'. By default the database should be > - * opened for reading only. In order to write to the database you need to > - * pass the NOTMUCH_DATABASE_MODE_READ_WRITE mode. > + * notmuch_database_create. > + * > + * If 'database_path' is NULL, use the location specified > + * > + * - in the environment variable NOTMUCH_DATABASE, if non-empty > + * > + * - by $XDG_DATA_HOME/notmuch/$PROFILE where XDG_DATA_HOME defaults > + * to "$HOME/.local/share" and PROFILE as as discussed in > + * 'profile' > + * > + * If 'database_path' is non-NULL, but does not appear to be a Xapian > + * database, check for a directory '.notmuch/xapian' below > + * 'database_path' (this is the behavior of > + * notmuch_database_open_verbose pre-0.32). > + * > + * @endparblock > + * @param[in]mode > + * @parblock > + * Mode to open database. Use one of #NOTMUCH_DATABASE_MODE_READ_WRITE > + * or #NOTMUCH_DATABASE_MODE_READ_WRITE I think you want to have NOTMUCH_DATABASE_MODE_READ_ONLY here? Greetings, Reto ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: [PATCH] completion: remove "setup" from the list of possible completions
On Fri, Jun 19, 2020 at 12:40:49PM +0200, Łukasz Stelmach wrote: > Having "setup" in the set requires entering three instad of two characters > for "search". Since "setup" is rearly used it makes little sense to have > it in the set and cripple UX for much more frequently used "search". I very much disagree with this patch. The completions should contain all possible values, saving a single keystroke is certainly not a valid reason to remove a valid option from the completions. Write an alias into your bashrc if that bothers you so much... Then you can save much more keystrokes. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: notmuch and mailing lists
On Fri, May 01, 2020 at 12:30:28PM -0700, Sean Whitton wrote: > I've not yet used NNTP to read mailing lists myself, but I think there > are limitations to the way I currently read lists What are you missing exactly? If we know what your actual problems are there might be better solutions forthcoming. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Best practices for notmuch and neomutt
On Tue, Mar 03, 2020 at 11:13:47AM +, moonmaill...@firemail.cc wrote:
> I really want to know best practices or nice virtual-mailboxes, which aren't
> included in normal tutorials. Most tutorial just have 1 email address and
> only use tags like inbox, archive, deleted and spam. But there must be much
> better use cases and much more detailed notmuch queries or even hooks which
> are triggered to specific events.
I mean in the end you need to make up a system that works for you.
I personally just tag it by topic (notmuch / neomutt / distro related...)
possibilities are endless.
But the more tags you have the harder it gets to keep track and make sense of
them.
I dump all mails from 3 addresses into one notmuch db.
The necessary tricks to cope with that is in neomutt
```
set sendmail="/bin/msmtp --read-envelope-from"
set use_from=yes
set reverse_name
set envelope_from=no
# special case for lists, where we aren't explicitly on the to/cc headers
reply-hook . 'unmy_hdr From:'
reply-hook '~h"Delivered-To: asdf@gmail\.com"' my_hdr from: a...@gmail.com
reply-hook '~h"Delivered-To: xyz@stuff\.com"' my_hdr from: x...@stuff.com
```
While that may not be the most elegant solution, at least it works.
On the notmuch side I just use a after sync script containing all the tagging
```
#first put all in the inbox
notmuch tag +inbox -- tag:new
#temporary tag which will be removed at the end
for email in ${own_adresses[@]}; do
notmuch tag +to_me -- "to:${email} and tag:new"
done
for email in ${own_adresses[@]}; do
notmuch tag +sent -- "from:${email} and tag:new"
done
# then remove all the non inbox stuff one by one
# filter stuff we sent from the inbox if it isn't a self message
notmuch tag -inbox -- tag:sent and not tag:to_me
notmuch tag -inbox +lists +notmuch -- to:notmuch and tag:new
# kill muted threads
notmuch search --output=threads tag:muted | xargs -r -n1 notmuch tag +muted
#get rid of old clutter from mailing lists
notmuch tag +archive -- tag:lists and date:..30d and not tag:unread
#archived stuff should not be unread
notmuch tag -unread -- tag:unread and tag:archive
#finally remove the temporary tags
notmuch tag -new -to_me -- tag:new
```
Stuff like that...
Does this help?
Greetings,
Reto
___
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 13 February 2020 23:54:48 CET, David Bremner wrote: >Do you have any measurements of time or memory savings? No, but between not having to do a open/close cycle (including garbage collection on the go side) and having to do it, I expect it would be better if the DB can be reopened. The suggestion that _notmuch_database_reopen might be sensible to export actually stems from olly on IRC ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
export notmuch_database_reopen
Hi, 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. The client I'm running is interactive and can have long running processes. I'd like to avoid unnecessary create / destroy cycles of the DB, especially as I'm calling the C lib via a go wrapper. Would it be possible to export `_notmuch_database_reopen`? Then I could call that instead. I mostly have a read only DB open anyhow. Kind regards, Reto ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Segfault when tagging results of to: query
That's most probably xapians fault. Xapian 1.4.13 has a bug in it, there's a patch available but no new version has been released yet. You can find the issue here: https://trac.xapian.org/ticket/796#no1 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] devel: make printmimestructure py3 compatible
On Tue, Jun 12, 2018 at 11:35:09AM +0300, Tomi Ollila wrote: > -#!/usr/bin/env python > +#!/usr/bin/python > > just that 'python' should be able to run both python2 and python3 code. > > after the above change the code will not run on (those stupid) systems > that install python to e.g. /usr/local/bin/. > > While I am not against this change, the commit message is misleading. Remind me again why putting stuff in /usr/local is "stupid"? /usr/bin belongs to my package manager... If I manually compile python for whatever reason I put it in /usr/local/bin, as this is what the directory is for. So why would you switch from a shebang which works always to a shebang which only works on some very simple systems? This doesn't make sense for me. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
