[Nicholas D Steeves] Bug#927315: elpa-notmuch: please fix notmuch-tag's limitation of spaces in tag name (+this_tag form is too strict)
--- Begin Message --- Package: elpa-notmuch Version: 0.28.3-1 Severity: minor From within *notmuch-search-tag:Red label* I expected one of +"Red label", +'Red label', +"Red\ label", and +'Red\ label', plus variations with the '+' inside quotes would work, but it doesn't seem to. notmuch tag +"Bogus Test Tag" tag:"Red Label" works 100% fine. The issue seems to be that the regex and form of notmuch-tag.el:L466-67 is too strict. I would imagine that this primarily affects users who are using or migrating away from GMail, who often spaces in their GMail label names. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.34 (SMP w/2 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages elpa-notmuch depends on: ii emacsen-common 3.0.4 elpa-notmuch recommends no packages. elpa-notmuch suggests no packages. -- no debconf information signature.asc Description: PGP signature --- End Message --- ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Accidentally unsubscribed?
Pierre Neidhardt writes: > Hi, > > I've just received an email: > > --8<---cut here---start->8--- > notmuch-boun...@notmuchmail.org (25 mins. ago) (inbox) > Subject: You have been unsubscribed from the notmuch mailing list > --8<---cut here---end--->8--- > > I suspect this is because of the antispam of my email server. Can > someone confirm and maybe send me the faulty .eml so that I fix this? I replied offlist with some details of bounce. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
* David Bremner: > I could imagine more levels of quiet, but I don't know if it is worth > the trouble. I currently redirect stderr to /dev/null because the actual number of these "ignoring non-mail file" notices is much higher, but that means I don't get to see actual errors which is quite a disadvantage. An option like --veryquiet or --errorsonly would be helpful, but I can understand you asking if it would be worth the effort. For somebody like me who uses Dovecot as a backend it would be. ;-) > Could it maybe a wrapper script or hook invoked by notmuch new? Ah! The post-new hook called umask and caused the output. Thanks. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
Ralph Seichter writes: > * David Bremner: > >> I could imagine more levels of quiet, but I don't know if it is worth >> the trouble. > > I currently redirect stderr to /dev/null because the actual number of > these "ignoring non-mail file" notices is much higher, but that means I > don't get to see actual errors which is quite a disadvantage. > Unfortunately its not very easy for notmuch to distinguish between different kinds of parsing failures (at least, not easy to do so quickly). The recommended solution for things like dovecot index files is to set to set "new.ignore" (see notmuch-config(1)). > An option like --veryquiet or --errorsonly would be helpful, but I can > understand you asking if it would be worth the effort. For somebody like > me who uses Dovecot as a backend it would be. ;-) I guess if you have a simple way of distinguishing the cases which you want to consider as errrors, we can revisit the idea. ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
* David Bremner: > I guess if you have a simple way of distinguishing the cases which you > want to consider as errrors, we can revisit the idea. Personally, I'd go with these decreasing levels of severity: Fatal: Execution must stop immediately to prevent damage, error message may or may not be displayed before exiting the process. Error: Serious trouble, program may or may not be able to recover, user intervention required. Warning: Minor trouble, program will recover without user intervention. Notice: Inform the user of a less-than-ideal situation (non-mail file found, deprecated functionality used, etc). Program will ignore the cause and carry on. I don't know if this is a fit for Notmuch, but it would be great if I could prevent warnings and notices from being reported by using a command line option. -Ralph ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Unexpected output of "notmuch new --quiet"
Ralph Seichter writes: > * David Bremner: > >> I guess if you have a simple way of distinguishing the cases which you >> want to consider as errrors, we can revisit the idea. > > Personally, I'd go with these decreasing levels of severity: [snip] > I don't know if this is a fit for Notmuch, but it would be great if I > could prevent warnings and notices from being reported by using a > command line option. > Just to be clear, I was referring in the question of deciding for specific messages, which ones are serious and which ones are not. Are there warnings that you want to suppress that are not handleable with the new.ignore facility? d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH 1/2] CLI/reindex: fix memory leak
David Bremner writes: > Since message is owned by messages, it was held for the entire run of > the program. This in turn means that the Xapian::Document objects are > not freed, and thus one ends up with (effectively) a copy of one's > entire mailstore in memory when running Pushed this one to master. People may be wanting to do a complete reindex to take advantage of body: searches. d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
