Re: Spacemacs, anyone?
"inwit" writes: >> IIRC there are some minor things that don't work so well, but I can't >> think of what they are right now. Possibly a figment of my imagination. > Have you ever tried to use the auto-completion layer? I'm having trouble > with it [1]. Autocompletion on my system is broken due to "my fault". I set it up to use "goobook-wrapper", and over the years that wrapper has stopped working. Need to fix this. I prefer to have some sort of local database rather then relying on Google. I am liking Google less and less lately. But haven't worked out how to do this yet. Ideally I would initially copy this from Google. I suspect it would work otherwise. > I also have trouble with frames that close when they shouldn't [1]. Not seen this myself. Although I did have problems like this when I switched to the main branch of spacemacs. View a list, view an email, and push 'q' to get back to the list to find I have completely closed out of notmuch. Switching back to the develop branch fixed this. > Would you be interested in contributing to notmuch layer? I see several > minor improvements that could serve others... Not great with LISP myself. Just remembered - the one key issue I have always had with spacemacs (and possibly emacs too) - and is very annoying, is if I click on a link in an email, and have the link load in Firefox, then there is a relatively high chance that the pull down menus in Firefox will stop working. As in I click a menu and nothing happens. I have to completely restart Firefox to fix. This has been happening for years now. For numerous versions of Debian (and I think others) and for numerous versions of Firefox. It does not happen if I load a link in Firefox from any other program. It does not happen if I load a link in Firefox using the Firefox CLI. It does not happen for other browsers such as Chrome. If I reset my profile in Firefox to default without any plugins it continues to happen. I have tried to debug how emacs is opening a Firefox tab, and get totally lost. I end up having to resort to hacks such as opening in Chrome first, or copying and pasting the link from notmuch (which often requires several attempts for reasons I don't understand as instead of one link that I marked I somehow get the entire document). I have reported this in various forums, but nobody has been able to help. -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: Spacemacs, anyone?
"inwit" writes: > Is anyone using notmuch within spacemacs? There's a fairly unmantained > "layer" for this, and i'm inclined to give it a spin. It'd be nice if we > could share our experiences. > > Yeah, I know, I should start building my own emacs config sometime soon. ;) I am doing that. Caveats: * I use notmuch from the elpa-notmuch package. * Need to use the develop branch of spacemacs. Otherwise it gets upset when it sees the system version of notmuch and tries to remove it. Which it can't, so it complains. I am a bit confused why the notmuch layer has never reached the main branch, but maybe I don't really understand the release process. IIRC there are some minor things that don't work so well, but I can't think of what they are right now. Possibly a figment of my imagination. -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: muchsync & sent mail
inasprecali writes: > Where are you storing your sent mail? Did you set the > notmuch-fcc-dirs Emacs variable? I don't think I changed this variable. It has the value "sent". -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: muchsync & sent mail
OK, I worked it out. I think. Seems like sent mail, while visible from notmuch, is not properly indexed until running "notmuch new". $ muchsync --nonew canidae.local [SERVER] [notmuch] No new mail. SUMMARY: received 0 messages, 0 link changes, 0 tag changes sent 0 messages, 0 link changes, 0 tag changes $ muchsync --nonew canidae.local [SERVER] [notmuch] No new mail. SUMMARY: received 0 messages, 0 link changes, 0 tag changes sent 0 messages, 0 link changes, 0 tag changes $ notmuch new No new mail. $ muchsync --nonew canidae.local [SERVER] [notmuch] No new mail. SUMMARY: received 0 messages, 0 link changes, 0 tag changes sent 1 messages, 0 link changes, 0 tag changes If I remove the "--nonew" option it will also do the same thing. What I find odd however is that "notmuch new" reports "No new mail" when it obviously found a new sent item. This is notmuch 0.31.4 (binary and emacs parts) -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: muchsync & sent mail
Martin Jambor writes: > This does not happen to me, the sent folder is synced just like any > other. Even drafts do. Hmmm. Weird. Looks like this worked for me in June last year (although I don't often send emails on this computer), but isn't working anymore. Wonder if upgrading to Debian/bullseye broke something. Can't imagine what though. Will continue to investigate. -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
muchsync & sent mail
Hello, I have noticed that my muchsync setup doesn't appear to sync my ~/Maildir/sent folder. Meaning mail sent on one system will not get synced to the other systems, despite running muchsync. Suspect this might apply to my other nested Maildirs too, but these aren't so important. Wondering how people handle this situation? Thanks -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: muchsync segfault
David Bremner writes: > Generic advice would be to run in gdb and get a backtrace, assuming you > have debugging symbols. Somebody else via private reply suggested I try the git version. So far it looks like that has solved the problem. Thanks -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
muchsync segfault
Hello all, muchsync is segfaulting when I run it on a particular box: $ muchsync -v silverfish.local [notmuch] No new mail. synchronizing muchsync database with Xapian... 0.011202 (+0.011202) starting scan of Xapian database... 0.011269 (+0.67) opened Xapian... 0.011611 (+0.000342) scanned message IDs... 0.162030 (+0.150420) scanned tags... 0.175126 (+0.013096) scanned directories in xapian... 0.175315 (+0.000189) scanned filenames in xapian... 0.175394 (+0.79) [SERVER] [notmuch] No new mail. adjusted link counts... 0.226647 (+0.051253) finished synchronizing muchsync database with Xapian... 0.235871 (+0.009224) received server's version vector... 0.877723 (+0.641851) received hashes of new files... 1.176468 (+0.298746) [1]64563 segmentation fault muchsync -v silverfish.local How do I resolve? I tried $ notmuch reindex '*' But this doesn't appear to have helped. Anything else I should try? Regards -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list -- notmuch@notmuchmail.org To unsubscribe send an email to notmuch-le...@notmuchmail.org
Re: timezone in notmuch
Tomi Ollila writes: > I use this: > > https://github.com/domo141/nottoomuch/blob/master/build/01-date-local.patch > > I've been thinking if some hook could be added to notmuch-emacs so > that such a custom date mangling can be done outside of the notmuch-emacs > source... I would like to see something like this without having to patch notmuch. As much as I like notmuch-show-relative-dates, occasionally, I just want to be able to see the exact time an email was sent in my timezone. -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Weird tagging issue
Daniel Kahn Gillmor writes: > Well, not if they're actually all the same message, right? > > Brian, can you confirm whether the body of these 4 messages are the same > or not? (e.g. you might have gotten different copies due to receiving > mail at different e-mail addresses, or through a mailing list, or just > through an SMTP hiccup) All emails appear to be different. I think bitbucket stuffed up. > What about for a message that References: its own Message-ID:? Do we > expect to handle that case sensibly? I'm not sure where i'd look in the > test suite to confirm that we intend to make that work OK, and i can > definitely imagine that being a goofy corner case when trying to > manipulate threads. I can't help here. I do have a vague recollection that I have seen this situation in the past (any easy way to search for such emails?), but I really can't remember how well notmuch copes (the fact I noticed such an issue might suggest I encountered difficulties - or maybe this was something else entirely). -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Weird tagging issue
Daniel Kahn Gillmor writes:
>> "1584434229.8921_0.wspdigital:2,S" -> {
>> "pr-wspdigital/bupaoshc/8...@bitbucket.org" }
>> "1584434231.8924_0.wspdigital:2,S" -> {
>> "pr-wspdigital/bupaoshc/8...@bitbucket.org" }
>> "1584434232.8927_0.wspdigital:2,S" -> {
>> "pr-wspdigital/bupaoshc/8...@bitbucket.org" }
>> "1584434234.8930_0.wspdigital:2,S" -> {
>> "pr-wspdigital/bupaoshc/8...@bitbucket.org" }
>
> The surprising thing about this output is that there appear to be 4
> copies of message that References: itself!
>
> And, many many other messages also reference that message too.
>
> Would you be willing to send me the full headers from one of the above 4
> files so i can verify that this is correct?
I suspect you only need the Message-ID and the References headers,
right? If not, can send more:
Message-ID:
References:
This applies to all 4 of those messages. Yes, they all look like they
have the same Message-ID
Also I am not seeing any duplicate headers or anything like that.
--
Brian May
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: Weird tagging issue
Daniel Kahn Gillmor writes: > This sounds really confusing, and i'm not sure how to help you debug. :/ > when you say "recreated the entire database", do you mean you dropped > all tags and everything, and reindexed the entire datastore? Yes, that is correct. I basically deleted "~/Maildir/.notmuch" and then ran "notmuch new". After confirming that the problem still existed, I then restored the backup of my tags, > Does the thread that you were working with contain any sensitive or > private messages? If not, can you isolate the specific files from the > maildir that compose the thread (e.g. with a manual grep) and try to > recreate the failure with a smaller maildir and dedicated notmuch > database? I know this is tedious, but if you can do it and share the > maildir, then it would help other folks reproduce the problem and dig > into it further. These are messages associated with a pull request for a private bitbucket repository owned by my employee, So I probably should not make them public :-( > if i was debugging this locally and i had a dedicated maildir that > demonstrated the problem, i'd probably try to inspect the xapian > database (e.g. with xapian-delve). There are several folks on the > #notmuch channel on freenode that can probably give pointers. Fortunately that particular pull request has been merged now, I probably don't have to worry anymore. However would be interested to know what happened. My suspicion is that bitbucket generated a bad email - maybe bad headers or something, which has totally confused things, The Message-ID values look fine. Although oddly enough there are several different formats, but this shouldn't be an issue: === cut === $ grep '^Message-ID' $(grep -ri -l 'Pull request #88: Add webdriver support' Maildir)Maildir/cur/1584486508.24564_0.wspdigital:2,S:Message-ID: Maildir/cur/1584486509.24570_0.wspdigital:2,S:Message-ID: Maildir/cur/1584487127.27595_0.wspdigital:2,S:Message-ID: Maildir/cur/1584487437.29402_0.wspdigital:2,S:Message-ID: Maildir/cur/1584494811.24972_0.wspdigital:2,S:Message-ID: Maildir/cur/1584494813.25016_0.wspdigital:2,S:Message-ID: Maildir/cur/1584567341.22359_0.wspdigital:2,S:Message-ID: Maildir/cur/1584505808.24160_0.wspdigital:2,S:Message-ID: Maildir/cur/1584506116.25523_0.wspdigital:2,S:Message-ID: [...] === cut === H. Maybe the References header is bad. I see a number of emails in this thread referencing "pr-wspdigital/bupaoshc/8...@bitbucket.org", e.g.: === cut === References: References: References: === cut === But "pr-wspdigital/bupaoshc/8...@bitbucket.org" doesn't have any information uniquely identifying a particular message for PR #88, and furthermore I don't see any message ids that look like this in this thread. I could imagine bad references might be confusing notmuch? I guess I should wait and see if the problem happens again. -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Weird tagging issue
Brian May writes: > I am having a problem with certain messages, in that I remove the tag > and it still shows up in search results. I just recreated the entire database, and I still get the same problem. -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Weird tagging issue
Hello, I am having a problem with certain messages, in that I remove the tag and it still shows up in search results. e.g. $ notmuch search tag:important [...] thread:aaff 40 mins. ago [37/38(43)] Lucas Liendo, Ricardo Perez; [Bitbucket] Pull request #88: Add webdriver support (wspdigital/bupaoshc) (important inbox unread) [...] but if I view the thread: $ notmuch show thread:aaff I see one message, it has no tags, and it is not the message referenced in the search results (i.e. it was sent hours ago, not 40 minutes). It only happens with this thread. Sometimes if I play around enough I can fix it, but the fix doesn't last. I get similar problems for other tags, such as inbox and important also. I suspect the root problem is it isn't showing the entire thread. I have tried: $ notmuch reindex thread:aaff $ notmuch reindex 'Pull request #88: Add webdriver support' But it doesn't help. The emacs reader is getting rather confused as a result. It says the message has the tags when it doesn't and won't let me see the entire thread. Is this a sign my tag database is corrupt? If so how do I fix? Or maybe there is some problem with the message - it looks OK to me. Was generated from bitbucket. It is not 100% important that I preserve my existing tags, but would like to know what is going on. This is notmuch version 0.28.4-1 from Debian buster using Maildir. Thanks -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: proposing "notmuch purge"
Daniel Kahn Gillmor writes: > So i'm proposing "notmuch purge", which could be something as simple as > the equivalent of: I can't help think it will only be a matter of time before somebody mistypes the search spec and accidentally deletes all their mail... Of course, this won't be a drama, because said user will revert to up-to-date backup, created just before manually entering risky command, right? ;-) -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: Working with 2FA-enabled mail (app password not possible)
Chris Coutinho writes: > My company recently made our Office365 mail service 2FA-enabled by > default and disallowed app-specific passwords. Before this, I used > Offlineimap to download my mail and index/search it using Notmuch. Now > that that's no longer possible, I'm looking to the community for > options. > > What do you use for syncing your mail to your local system(s) and > utilizing the power of Notmuch? Hmm. Wonder if this is the real reason IMAP suddenly stopped working for me on my work Office365 domain after updating my password. Although it does work for some people. Weird. OAuth is the solution for Google, and I suspect OAuth may be the solution for Microsoft too. If so, you need a program that supports IMAP using OAuth. gemail supports Google OAuth, I suspect it might be possible to get it to work with Microsoft too. However I don't know anything about how to register the Oauth app with Microsoft. http://www.bytereef.org/howto/oauth2/getmail.html Apparently OfflineIMAP also supports Oauth. Another option might be davmail. https://sourceforge.net/p/davmail/bugs/717/ -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Google Mail
and re-add your account. When you add it back, select “sign in with Google” to automatically use OAuth. Mac OS iOS mail app view Mac OS mail app view iOS Calendar If you use CalDAV to give an app or device access to your calendar, switch to a method that supports OAuth. We recommend the Google Calendar app [Web/iOS/Android] as the most secure app to use with your G Suite account. If your G Suite account is linked to the calendar app in iOS or MacOS and uses only a password to login, you'll need to remove and re-add your account to your device. When you add it back, select “sign in with Google” to automatically use OAuth. Read more Contacts If your G Suite account is syncing contacts to iOS or MacOS via CardDAV and uses only a password to login, you'll need to remove your account. When you add it back, select “sign in with Google” to automatically use OAuth. Read More If your G Suite account is syncing contacts to any other platform or app via CardDAV and uses only a password to login, switch to a method that supports OAuth. Note: If the app you are using does not support OAuth, you will need to switch to an app that offers OAuth, or ask your admin to contact the supplier of your app and request that they add OAuth as a way of connecting your Google account. Developer instructions To maintain compatibility with G Suite accounts, update your app to use OAuth 2.0 as a connection method. To get started, follow our developer guide on using OAuth 2.0 to access Google APIs. You can also refer to our guide on OAuth 2.0 for mobile & desktop apps. How can I get help? If you have additional questions or need assistance, please contact G Suite support. When you call or submit your support case, reference issue number 145694552. Thanks for choosing G Suite. —The G Suite Team Was this information helpful? YES NO © 2019 Google LLC 1600 Amphitheatre Parkway, Mountain View, CA 94043 You have received this important update about your G Suite account because you designated this email address as a primary or secondary contact for mandatory service communications in your Google Admin console profile. -- Brian May https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: New Python bindings (was: Crash with Python bindings)
David Bremner <da...@tethera.net> writes: > That's not an itch I personally have, but as I said in the next > paragraph, if someone want's to take on the project of maintaining a > wheel, we'll render the same kind of assistance we give *BSD/Linux/MacOS > package maintainers. We're happy to look at (reasonable) things we can > do to make downstream projects life easier. Fair enough. No problem. I am going to assume that the notmuch library is reasonable stable, and backward incompatable changes are kept to a minimum with proper updating of the shared library SONAME. If this is not the case, ignore the rest of this email. Ideally the python bindings should be in a git repository that is separate from the C library. This means you don't have to release new python bindings for every new source code release of notmuch. You only need to make a new release if supporting new features or a new release that breaks backword compatability. It also will make it easier to build the python libraries standalone using the installed versions of the C library, which I suspect might make pypi support a lot easier. I might be able to get time to look at this sometime myself, if nobody beats me to it. -- Brian May <br...@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: New Python bindings (was: Crash with Python bindings)
David Bremner <da...@tethera.net> writes: > We tried this before, and it didn't work out very well. Bindings tend to > depend on a strict matching of versions with the underlying library, so > distributing them seperately doesn't really make sense to me. You need > the underlying libraries, so why not get the matching bindings from the > same place? We found that the situation was exacerbated by the fact > that no-one cared about updating the bindings on pypi. I believe that is the purpose of Python Wheels. https://pythonwheels.com/ pypi is the defecto standard for distributing Python code for use in Python applications. It means packages that use notmuch just need to list it as a dependancy in 'requirements.txt' and a 'pip install -r requirements.txt' will install everything required (if inside a virtualenv no root access required even). There are also various solutions to get automatic deploys to pypi, for example through travis: https://docs.travis-ci.com/user/deployment/pypi/ Unfortunately, I think many people will not even consider using a python library unless it has up-to-date bindings available on pypi. -- Brian May <br...@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: New Python bindings (was: Crash with Python bindings)
Justus Winter <jus...@sequoia-pgp.org> writes: >> This is exactly what I have fixed in my alternative bindings which I >> created around the end of last year [0]. So we do have an idea of how >> to fix this, at the time I said I do believe that it's possible to also >> do this for the existing bindings even though it is a lot of work. >> After some talking between dkg and me we got to a way forward which >> proposed this, but I must admit that after messing a little with getting >> a pytest run integrated into the notmuch test-suite instead of using tox >> I lost momentum on the project and didn't advance any further. > > I'm sorry that I didn't speak up when you announced your work. I'm > actually excited about a new set of bindings for Python. I agree with > using cffi. I briefly looked at the code, and I believe it is much > nicer than what we currently have. I can into this thread late. However, my priorities for python bindings would be: * I don't care about anything less then Python 3.5. * Reliable Python 3.6 support important. * Packages should be available from pypi.python.org I have found the current official bindings unreliable with Python 3.x, and tend to cause aborts on exiting and/or fail to save updates. As such, for now I have downgraded to Python 2.7 for now. -- Brian May <br...@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: searching for multiple tags
David Bremner <da...@tethera.net> writes:
> There is a patch floating around [1] to support
>
> % notmuch search thread:{tag:important} and thread:{tag:unread}
>
> if that's the query you actually want.
I assume this means we search for threads where at least one message is
important and at least one message is unread.
That actually sounds like a very useful feature to have. I would most
definitely have uses for it. Is there any chance of this (or something
like it) being merged into notmuch?
Thanks
--
Brian May <br...@linuxpenguins.xyz>
https://linuxpenguins.xyz/brian/
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: searching for multiple tags
David Bremner <da...@tethera.net> writes: > This is a design-choice/quirk of the Xapian query parser, discussed > under "Operators" in man notmuch-search-terms; terms with a common > prefix are implicitely combined with an OR. > I don't think that documentation has changed since 0.23, but you can > compare with https://notmuchmail.org/manpages/notmuch-search-terms-7/ Ok, now I understand that text. Thanks. I tried using "tag:important and tag:unread" yesterday, and it didn't work either. Today I am wondering if maybe I had threads that had some messages marked important and some marked unread, but no individual messages marked both unread and important. Oh well, maybe this was the real reason I was having problems. Thanks for your response. -- Brian May <br...@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
searching for multiple tags
Hello, How do I search for emails containing multiple tags? I have tried: tag:unread tag:important However, this finds emails that contain either the unread tag or the important tag. Not emails that contain both. Am I doing something wrong? This is version 0.23.7-3 in Debian/stretch. Thanks -- Brian May <br...@linuxpenguins.xyz> https://linuxpenguins.xyz/brian/ ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
emacs email appears empty
On 29 September 2011 21:05, David Bremner wrote: > Any chance you could share such a message with us? Unfortunately the emails with this problem are private, I probably shouldn't repost without getting permission first from the sender. I think it might be emails sent with Zimbra web interface. Maybe the "- Original Message -" text? At least this is what the emails have in common. Unfortunately, my test messages all work fine. There is a copy below anyway. I also have attached an email with nothing but the signature. This email comes out completely blank without any option to see the signature. Not sure if this is expected or not. Fingers crossed gmail isn't going to mess with the line formatting... === cut === Return-Path: brian at vpac.org Received: from mail.vpac.org [2001:388:60ac::4] by aquitard with IMAP (fetchmail-6.3.18) for (single-drop); Tue, 11 Oct 2011 09:44:51 +1100 (EST) Received: from mail.vpac.org (LHLO mail.vpac.org) (202.158.218.6) by mail.vpac.org with LMTP; Tue, 11 Oct 2011 09:44:29 +1100 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.vpac.org (Postfix) with ESMTP id E23F2C0197372 for ; Tue, 11 Oct 2011 09:44:29 +1100 (EST) X-Virus-Scanned: amavisd-new at mail.vpac.org X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-10 required=5 tests=[BAYES_00=-1.9, HELO_NO_DOMAIN=0.001, RDNS_NONE=0.793] autolearn=no Received: from mail.vpac.org ([127.0.0.1]) by localhost (mail.vpac.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeztsuHiXzIh; Tue, 11 Oct 2011 09:44:29 +1100 (EST) Received: from mail.vpac.org (mail.vpac.org [202.158.218.6]) by mail.vpac.org (Postfix) with ESMTP id 3A2D6C0197369; Tue, 11 Oct 2011 09:44:29 +1100 (EST) Date: Tue, 11 Oct 2011 09:44:29 +1100 (EST) From: Brian May <br...@vpac.org> To: Brian May Cc: Brian May Message-ID: <1567978915.114359.1318286669223.JavaMail.root at mail.vpac.org> In-Reply-To:
Re: emacs email appears empty
On 29 September 2011 21:05, David Bremner da...@tethera.net wrote: Any chance you could share such a message with us? Unfortunately the emails with this problem are private, I probably shouldn't repost without getting permission first from the sender. I think it might be emails sent with Zimbra web interface. Maybe the - Original Message - text? At least this is what the emails have in common. Unfortunately, my test messages all work fine. There is a copy below anyway. I also have attached an email with nothing but the signature. This email comes out completely blank without any option to see the signature. Not sure if this is expected or not. Fingers crossed gmail isn't going to mess with the line formatting... === cut === Return-Path: br...@vpac.org Received: from mail.vpac.org [2001:388:60ac::4] by aquitard with IMAP (fetchmail-6.3.18) for brian@localhost (single-drop); Tue, 11 Oct 2011 09:44:51 +1100 (EST) Received: from mail.vpac.org (LHLO mail.vpac.org) (202.158.218.6) by mail.vpac.org with LMTP; Tue, 11 Oct 2011 09:44:29 +1100 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.vpac.org (Postfix) with ESMTP id E23F2C0197372 for br...@vpac.org; Tue, 11 Oct 2011 09:44:29 +1100 (EST) X-Virus-Scanned: amavisd-new at mail.vpac.org X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-10 required=5 tests=[BAYES_00=-1.9, HELO_NO_DOMAIN=0.001, RDNS_NONE=0.793] autolearn=no Received: from mail.vpac.org ([127.0.0.1]) by localhost (mail.vpac.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeztsuHiXzIh; Tue, 11 Oct 2011 09:44:29 +1100 (EST) Received: from mail.vpac.org (mail.vpac.org [202.158.218.6]) by mail.vpac.org (Postfix) with ESMTP id 3A2D6C0197369; Tue, 11 Oct 2011 09:44:29 +1100 (EST) Date: Tue, 11 Oct 2011 09:44:29 +1100 (EST) From: Brian May br...@vpac.org To: Brian May br...@microcomaustralia.com.au Cc: Brian May br...@vpac.org Message-ID: 1567978915.114359.1318286669223.javamail.r...@mail.vpac.org In-Reply-To: CAA0ZO6Avc1oQjvaXKJpi=vdtusk-4y+moxeewloxtzib-vn...@mail.gmail.com Subject: Re: test 2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [128.250.103.200] X-Mailer: Zimbra 6.0.13_GA_2918 (ZimbraWebClient - SAF3 (Linux)/6.0.13_GA_2918) - Original Message - This is a test. Proof is not attached. -- Brian May br...@microcomaustralia.com.au You don't have any proof do you? -- Brian May === cut === === cut === Return-Path: br...@microcomaustralia.com.au Received: from mail.vpac.org [2001:388:60ac::4] by aquitard with IMAP (fetchmail-6.3.18) for brian@localhost (single-drop); Tue, 11 Oct 2011 09:40:48 +1100 (EST) Received: from mail.vpac.org (LHLO mail.vpac.org) (202.158.218.6) by mail.vpac.org with LMTP; Tue, 11 Oct 2011 09:40:33 +1100 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.vpac.org (Postfix) with ESMTP id C218CC0197370 for br...@vpac.org; Tue, 11 Oct 2011 09:40:33 +1100 (EST) X-Virus-Scanned: amavisd-new at mail.vpac.org X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-10 required=5 tests=[AWL=0.236, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Authentication-Results: mail.vpac.org (amavisd-new); dkim=pass header.i=@microcomaustralia.com.au Received: from mail.vpac.org ([127.0.0.1]) by localhost (mail.vpac.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nF6unVC7D49c for br...@vpac.org; Tue, 11 Oct 2011 09:40:32 +1100 (EST) Received: from mail-ww0-f48.google.com (mail-ww0-f48.google.com [74.125.82.48]) by mail.vpac.org (Postfix) with ESMTPS id AB51AC0197369 for br...@vpac.org; Tue, 11 Oct 2011 09:40:31 +1100 (EST) Received: by wwe32 with SMTP id 32so9383984wwe.29 for br...@vpac.org; Mon, 10 Oct 2011 15:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microcomaustralia.com.au; s=google; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type; bh=x9j2t6NjG/AVcHxbwM/oIFlLTOFwF3y1ZW22PVeCbT0=; b=HSCTN2sYz7ixqfK08MeDu/0owkvqzMCzyyGEYuIq4htrxTM5Vlkd/MTkN79okgDWBx RpVG7GmIU4jf/xUVut4n002e6nTVRBUcM6VWMhaIZMPrmtHN/N2NobMDIQh2pqYKiO/1 T5pcHKqFp9TQNumFn/4FH0AGZfxbYLQvD+n58= MIME-Version: 1.0 Received: by 10.216.131.193 with SMTP id m43mr5932606wei.114.1318286427492; Mon, 10 Oct 2011 15:40:27 -0700 (PDT) Received: by 10.216.179.134 with HTTP; Mon, 10 Oct 2011 15:40:27 -0700 (PDT) X-Originating-IP: [128.250.103.200] Date: Tue, 11 Oct 2011 09:40:27 +1100 Message-ID: CAA0ZO6BLHKENNcs1jgC-MRH=weoa4mxbqi54jgqcgd2szqp...@mail.gmail.com Subject: test only From: Brian May br...@microcomaustralia.com.au To: Brian
emacs email appears empty
On 29 September 2011 11:21, Brian May wrote: > Have seen several cases now where the message appears blank in the > emacs interface. With nothing but the headers. > > Pushing Shift+V shows the entire raw message. Nothing special, just a > plain text email without any attachments. Also replying to this email quotes it correctly. Weird. -- Brian May
emacs email appears empty
Hello, Have seen several cases now where the message appears blank in the emacs interface. With nothing but the headers. Pushing Shift+V shows the entire raw message. Nothing special, just a plain text email without any attachments. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Any ideas? Thanks -- Brian May
emacs email appears empty
Hello, Have seen several cases now where the message appears blank in the emacs interface. With nothing but the headers. Pushing Shift+V shows the entire raw message. Nothing special, just a plain text email without any attachments. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Any ideas? Thanks -- Brian May br...@microcomaustralia.com.au ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: emacs email appears empty
On 29 September 2011 11:21, Brian May br...@microcomaustralia.com.au wrote: Have seen several cases now where the message appears blank in the emacs interface. With nothing but the headers. Pushing Shift+V shows the entire raw message. Nothing special, just a plain text email without any attachments. Also replying to this email quotes it correctly. Weird. -- Brian May br...@microcomaustralia.com.au ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
not much reply multipart/mixed
Hello, When I reply to a given email, instead of quoting the original text, I see: === cut === On Tue, 9 Aug 2011 01:39:30 -0600, tivoli_support at ecurep.ibm.com wrote: Non-text part: multipart/mixed Non-text part: text/html === cut === This is with the latest git master version. Thanks -- Brian May
not much reply multipart/mixed
Hello, When I reply to a given email, instead of quoting the original text, I see: === cut === On Tue, 9 Aug 2011 01:39:30 -0600, tivoli_supp...@ecurep.ibm.com wrote: Non-text part: multipart/mixed Non-text part: text/html === cut === This is with the latest git master version. Thanks -- Brian May br...@microcomaustralia.com.au ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Preventing the user shooting themself in the foot
On 30 June 2011 17:50, Pieter Praet wrote: > And AFAIK, "Archive" does *not* mark a message as read in GMail. > (see previous messages suggesting the inverse) gmail will mark all messages in the thread as read when looking at any part of the thread - so in practical terms whenever I click "Archive" the entire thread is marked as read - as I always click archive in the message view. Not absolutely convinced this is the best approach. I think it is important to appreciate the differences that different implementations have chosen. -- Brian May
Re: Preventing the user shooting themself in the foot
On 30 June 2011 17:50, Pieter Praet pie...@praet.org wrote: And AFAIK, Archive does *not* mark a message as read in GMail. (see previous messages suggesting the inverse) gmail will mark all messages in the thread as read when looking at any part of the thread - so in practical terms whenever I click Archive the entire thread is marked as read - as I always click archive in the message view. Not absolutely convinced this is the best approach. I think it is important to appreciate the differences that different implementations have chosen. -- Brian May br...@microcomaustralia.com.au ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Preventing the user shooting themself in the foot
On 30 June 2011 08:40, Carl Worth wrote: > The 'a' keybinding, (in turn), was designed for cases when you *know* > you don't want to read the rest of the thread. ... in which case it should also mark everything as read. IMHO. Are there any keyboard bindings to go forwards to the next message or backwards to the last message without marking anything as archived? Also, just something I have noticed it isn't really obvious that a thread has replies without scrolling down, and that takes time. Would be really good if there could be some big/highlighted visual indicator that there are still unread messages further down. -- Brian May
Re: Preventing the user shooting themself in the foot
On 30 June 2011 08:40, Carl Worth cwo...@cworth.org wrote: The 'a' keybinding, (in turn), was designed for cases when you *know* you don't want to read the rest of the thread. ... in which case it should also mark everything as read. IMHO. Are there any keyboard bindings to go forwards to the next message or backwards to the last message without marking anything as archived? Also, just something I have noticed it isn't really obvious that a thread has replies without scrolling down, and that takes time. Would be really good if there could be some big/highlighted visual indicator that there are still unread messages further down. -- Brian May br...@microcomaustralia.com.au ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[python] get all messages of a thread
On 2 June 2011 17:05, Sebastian Spaeth wrote: > What would be the best way to solve this (besides fixing the C api to > allow to reset the iterator ;-) ?) > > I am not really familiar with the code. So am I correct in making the following assumptions? * It is not easy to fix the C api to reset the iterator (what about repeating the search?) * The only accurate way to get the number of messages is to iterate through every search result and count them? If so, then len(...) I think might be very slow if there are a large number of elements. Maybe it might be easier/better to implement object.__nonzero__(self) instead of the object.__len__(self) method? http://docs.python.org/reference/datamodel.html object.__nonzero__(self) Called to implement truth value testing and the built-in operation bool(); should return False or True, or their integer equivalents 0 or 1. When this method is not defined, __len__() is called, if it is defined, and the object is considered true if its result is nonzero. If a class defines neither __len__() nor __nonzero__(), all its instances are considered true. object.__len__(self) Called to implement the built-in function len(). Should return the length of the object, an integer >= 0. Also, an object that doesn?t define a __nonzero__() method and whose __len__() method returns zero is considered to be false in a Boolean context. -- Brian May -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110602/9b854d5c/attachment.html>
Multiple sender identities (composing)
On 1 June 2011 16:42, Thomas Jost wrote: > There's a function that changes the signature according to the From > header in the message I sent on this list yesterday > (id:"87pqmznczk.fsf at thor.loria.fr", near the end of the message). > > Thanks for the pointer, it seems to work fine. -- Brian May -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110602/c7fceb25/attachment.html>
Re: [python] get all messages of a thread
On 2 June 2011 17:05, Sebastian Spaeth sebast...@sspaeth.de wrote: What would be the best way to solve this (besides fixing the C api to allow to reset the iterator ;-) ?) I am not really familiar with the code. So am I correct in making the following assumptions? * It is not easy to fix the C api to reset the iterator (what about repeating the search?) * The only accurate way to get the number of messages is to iterate through every search result and count them? If so, then len(...) I think might be very slow if there are a large number of elements. Maybe it might be easier/better to implement object.__nonzero__(self) instead of the object.__len__(self) method? http://docs.python.org/reference/datamodel.html object.__nonzero__(self) Called to implement truth value testing and the built-in operation bool(); should return False or True, or their integer equivalents 0 or 1. When this method is not defined, __len__() is called, if it is defined, and the object is considered true if its result is nonzero. If a class defines neither __len__() nor __nonzero__(), all its instances are considered true. object.__len__(self) Called to implement the built-in function len(). Should return the length of the object, an integer = 0. Also, an object that doesn’t define a __nonzero__() method and whose __len__() method returns zero is considered to be false in a Boolean context. -- Brian May br...@microcomaustralia.com.au ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Multiple sender identities (composing)
On 16 May 2011 19:29, Stewart Smith wrote: > Thought I'd share this bit of my .emacs snippet that may be useful to go > on the emacs tips page. > > This does the following: > - sets up a list of possible identities to have mail From > - on composing mail, it prompts you for who you want to send mail from > - pressing enter will give you the default (first in the list) > - otherwise you have tab completion > Is it possible to have it change the signature per identity also? -- Brian May -- next part -- An HTML attachment was scrubbed... URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110601/6047500c/attachment.html>
[python] get all messages of a thread
On 28 May 2011 23:18, Patrick Totzke wrote:
>if r: #because we cant iterate on NoneType
>
I don't understand why, but this line sets r._msgs to None. So it crashes,
because it has no message ids to look for.
If you change it to
if r is not None:
... then it works for me.
Oh, I see, for your code, there is a implied call to __len__, and the
__len__ function is completely broken for the reasons described in the
documentation:
.. note:: As this iterates over the messages, we will not be able to=
iterate over them again! So this will fail::
#THIS FAILS
msgs = Database().create_query('').search_message()
if len(msgs) > 0: #this 'exhausts' msgs
# next line raises
NotmuchError(STATUS.NOT_INITIALIZED)!!!
for msg in msgs: print msg
Most of the time, using the
:meth:`Query.count_messages` is therefore more
appropriate (and much faster). While not guaranteeing
that it will return the exact same number than len(),
in my tests it effectively always did so.
--
Brian May
-- next part --
An HTML attachment was scrubbed...
URL:
<http://notmuchmail.org/pipermail/notmuch/attachments/20110601/226b4f92/attachment.html>
Re: Multiple sender identities (composing)
On 1 June 2011 16:42, Thomas Jost schno...@schnouki.net wrote: There's a function that changes the signature according to the From header in the message I sent on this list yesterday (id:87pqmznczk@thor.loria.fr, near the end of the message). Thanks for the pointer, it seems to work fine. -- Brian May br...@microcomaustralia.com.au ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [python] get all messages of a thread
On 28 May 2011 23:18, Patrick Totzke patricktot...@googlemail.com wrote:
if r: #because we cant iterate on NoneType
I don't understand why, but this line sets r._msgs to None. So it crashes,
because it has no message ids to look for.
If you change it to
if r is not None:
... then it works for me.
Oh, I see, for your code, there is a implied call to __len__, and the
__len__ function is completely broken for the reasons described in the
documentation:
.. note:: As this iterates over the messages, we will not be able to=
iterate over them again! So this will fail::
#THIS FAILS
msgs = Database().create_query('').search_message()
if len(msgs) 0: #this 'exhausts' msgs
# next line raises
NotmuchError(STATUS.NOT_INITIALIZED)!!!
for msg in msgs: print msg
Most of the time, using the
:meth:`Query.count_messages` is therefore more
appropriate (and much faster). While not guaranteeing
that it will return the exact same number than len(),
in my tests it effectively always did so.
--
Brian May br...@microcomaustralia.com.au
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: Multiple sender identities (composing)
On 16 May 2011 19:29, Stewart Smith stew...@flamingspork.com wrote: Thought I'd share this bit of my .emacs snippet that may be useful to go on the emacs tips page. This does the following: - sets up a list of possible identities to have mail From - on composing mail, it prompts you for who you want to send mail from - pressing enter will give you the default (first in the list) - otherwise you have tab completion Is it possible to have it change the signature per identity also? -- Brian May br...@microcomaustralia.com.au ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
emacs crashes
On 18 February 2011 19:38, Michal Sojka wrote: > This should be already fixed -- see http://debbugs.gnu.org/6214. I'm not > sure whether the fix is available in an emacs release or only in the > development branch. It seems that Debian includes the fixes in its > packages (http://bugs.debian.org/586459). Ok, that says it is fixed in version 23.2+1-5; Should be fixed in the next release of Ubuntu. http://packages.ubuntu.com/natty/emacs23 Thanks for the references. -- Brian May
emacs crashes
Hello, I have found certain emails, when I try to view them with the emacs notmuch client, will cause emacs to crash (segmentation fault). Every time, 100% reproducible. A theory of have is maybe the emails are too big and the system can't cope, eg: brian at aquitard:~$ notmuch show thread:000104db | wc --bytes 943897 brian at aquitard:~$ notmuch show thread:fbab | wc --bytes 3262660 brian at aquitard:~$ These are emailed TSM Operational Reports, entirely ASCII (plus some non-ASCII rubbish), no attachments, with a large number of log entries. An alternative theory is perhaps the non-ASCII rubbish (from weird filenames some of our users have) is causing problems. Anybody else experienced similar results? Thanks -- Brian May
emacs crashes
Hello, I have found certain emails, when I try to view them with the emacs notmuch client, will cause emacs to crash (segmentation fault). Every time, 100% reproducible. A theory of have is maybe the emails are too big and the system can't cope, eg: brian@aquitard:~$ notmuch show thread:000104db | wc --bytes 943897 brian@aquitard:~$ notmuch show thread:fbab | wc --bytes 3262660 brian@aquitard:~$ These are emailed TSM Operational Reports, entirely ASCII (plus some non-ASCII rubbish), no attachments, with a large number of log entries. An alternative theory is perhaps the non-ASCII rubbish (from weird filenames some of our users have) is causing problems. Anybody else experienced similar results? Thanks -- Brian May br...@microcomaustralia.com.au ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
