Re: What do people use for calendar invites?

[Brian Sniffen]

I don’t have an answer that lives in Emacs; I just let another imap client 
(Apple Calendar) read the mailbox for invitations and maintain my calendar. I 
just have to make sure getmail doesn’t delete the invitation messages. 

-- 
Brian Sniffen

> On Jan 21, 2021, at 4:49 AM, David Mazieres 
>  wrote:
> 
> Calendar invites and the text/calendar mime type seem to be getting
> increasingly important.  I asked about this five years ago and didn't
> get a good response, so I apologize for the repeat question, but I'm
> wondering if anything has changed since then.
> 
> If you have found a good solution for integrating your calendar with
> notmuchmail, would you mind sharing what you are doing?  Some specific
> questions:
> 
>  * What's a good way to generate text/calendar attachments from within
>notmuch (especially the emacs interface, which I use)?
> 
>  * What's a good way to apply text/calendar attachments to a calendar
>from within notmuch?
> 
>  * For those of us who hate gmail and love notmuch, but are still stuck
>using and hating google calendar, what alternative solutions should
>we be considering?
> 
> Thanks,
> David
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Attach public key and encrypt by default

[Brian Sniffen]

Two ideas:

echo “-- “ > ~/.signature
gpg -a -e $USER >> !$

This is hardly polite, but at least the signature will be stripped off by many 
archives and replies. 

Alternatively, 

(add-hook ‘message-setup-hook (lambda () (mml-attach-file “path/to/pubkey.gpg”))

But this still puts kilobytes of useless crud on every message. Please don’t. 
Maybe a URL to your key in your signature would be enough?

-- 
Brian Sniffen

> On Dec 16, 2019, at 10:52 PM, Carolyn Lynn Knight-Serrano 
>  wrote:
> 
> Oh! I figured out how to encrypt by default. I still can't figure out how to 
> attach my public key by default though. 
> 
>> On December 16, 2019 10:57:12 PM UTC, "Carolyn "Lynn" Knight-Serrano" 
>>  wrote:
>> I have two feature requests/questions for notmuch-emacs? One would it
>> be possible to add or configure in support for automatically adding
>> your gpg public key to messages? Second, could there be a feature that
>> checks if there's a gpg key for the recipient of a message and if there
>> is, turn on encryption by default? Thanks! 
>> -/-\-/-\-/-
>> 
>> Carolyn "Lynn" Knight-Serrano [xe/xem/xyr/xemself]
>> 
>> PGP Fingerprint: 0xf02b733b4382e451c8c2fff550858748146544cb
>> 
>> Fediverse: @gigavinyl@catgirl.science 
>> ___
>> notmuch mailing list
>> notmuch@notmuchmail.org
>> https://notmuchmail.org/mailman/listinfo/notmuch
> 
> -/-\-/-\-/-
> 
> Carolyn "Lynn" Knight-Serrano [xe/xem/xyr/xemself]
> 
> PGP Fingerprint: 0xf02b733b4382e451c8c2fff550858748146544cb
> 
> Fediverse: @gigavinyl@catgirl.science 
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Workaround for Exchange-corrupted PGP/Mime structure

[Brian Sniffen]

Carl Worth  writes:

> On Wed, Nov 20 2019, Carl Worth wrote:
>> I'll update my notmuch and give this a try.
>
> Just a "git pull; make; make install" and my problem went away.
>
> Thanks again for the fixes, Daniel.

Yeah, these have been fantastic for me too.  MSFT has no intention of
fixing PGP or MIME support; it's been well over a decade.  
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Can not view messages in deeply nested threads (emacs)

[Brian Sniffen]

Consider changing your html tenderer to anything other than ‘shr. Its handling 
of nested blocks is unsane. 

-- 
Brian Sniffen

> On Apr 8, 2019, at 3:27 PM, Landry, Walter  wrote:
> 
> Hi Everyone,
> 
> Back in January, I posted about a problem I had when viewing large
> threads.  The workaround was to use tree view.  That worked until today.
> Now, when I try to view a new email in either tree view or the regular
> view, I get the message
> 
>  Re-entering top level after C stack overflow
> 
> I am guessing that the thread depth got too deep?  The message is 294
> (?!?!?) levels deep.  I can look at messages that are in the same
> thread, but not as deep.  After some searching, it seems that this
> happens because I have
> 
>  max-specpdl-size
> 
> set too large.  However, if I try setting it smaller, tree view is
> unable to display the thread.
> 
> I also have astroid and alot installed.  Astroid tends to freeze a lot
> whenever I try to look at these messages.  Alot is slow, but works.  The
> command line client works without issues.
> 
> Is there any way that I can look at these messages in emacs?
> 
> Thank you,
> Walter Landry
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Reply to content of "List-Post" header?

[Brian Sniffen]

You can set message-subscribed-addresses or its cousins; then 
message-to-list-only will work for you. 

-- 
Brian Sniffen

> On Mar 2, 2019, at 10:00 AM, Ralph Seichter  wrote:
> 
> * Gregor Zattler:
> 
>> I do "R" for reply-to-all and then C-c C-l for message-to-list-only
>> which reduces the To: and Cc: to the mailing list address.
> 
> I tried both "C-c C-l" and "M-x message-to-list-only" on several
> messages, but it does not seem to have any effect. I don't see any
> error reports, but nothing happens.
> 
>> I don't know how this works, though. I assume it evaluates List-
>> headers.
> 
> According to http://www.gnus.org/manual/big-message.html , Emacs Message
> mode processes the "Mail-Followup-To" header, which seems to be a rarity
> these days. "List-Post" et al apparently don't factor into it.
> 
> -Ralph
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: emacs slow with large threads

[Brian Sniffen]

I think that becomes buffer local when set. Are you sure it me a difference?

-- 
Brian Sniffen

> On Jan 21, 2019, at 7:39 AM, Emilio Francesquini  
> wrote:
> 
> Hello there,
> 
> I recently ran into the same (slowness) problem when viewing long threads.
> After some profiling I found out that disabling indentation did the trick for 
> me. In my case it went from unusable (>5 minutes) to ~3 seconds for large 
> threads.
> 
> (setq notmuch-show-indent-content nil)
> 
> Hope it helps.
> 
>> On Mon, Jan 21, 2019 at 9:07 AM Dan Čermák  wrote:
>> "Landry, Walter"  writes:
>> 
>> > Dan Čermák  writes:
>> >
>> >> Hi Landry,
>> >>
>> >> I am afraid this is a common limitation of emacs: if you start opening
>> >> large files (especially with long lines) it becomes very slow.
>> >>
>> >> A viable workaround is to open the offending thread in the tree view
>> >> (bound to 'z' by default) and then only view individual messages.
>> >
>> > Tree view works well [1].  Everything is fast, and I kind of prefer that
>> > view anyway.
>> >
>> > Thanks,
>> > Walter Landry
>> >
>> > [1] I have been using notmuch for almost a year, and I did not realize
>> > that there is a separate tree view.
>> 
>> I have been using notmuch for about two years and iirc didn't realize
>> tree view existed until about half a year ago. Should really have read
>> the manual and all the key bindings at first.
>> 
>> > ___
>> > notmuch mailing list
>> > notmuch@notmuchmail.org
>> > https://notmuchmail.org/mailman/listinfo/notmuch
>> ___
>> notmuch mailing list
>> notmuch@notmuchmail.org
>> https://notmuchmail.org/mailman/listinfo/notmuch
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: emacs slow with large threads

[Brian Sniffen]

This is much worse than normal problems with large files or long lines. There’s 
something worse-than-quadratic in the nesting and indenting elisp. I’ve been 
meaning to get around to figuring out what, but no luck yet. 

-- 
Brian Sniffen

> On Jan 18, 2019, at 7:03 PM, Landry, Walter  wrote:
> 
> Hello Everyone,
> 
> I am using the emacs frontend to notmuch.  It has mostly been a pleasant
> experience, but I am having a problem with large threads.  Essentially,
> when I try to view a large thread, the machine locks up for many
> minutes.  The problem seems very similar to these posts.
> 
>  https://notmuchmail.org/pipermail/notmuch/2013/014811.html
>  https://notmuchmail.org/pipermail/notmuch/2015/020379.html
> 
> I tried turning off html rendering by setting mm-text-html-renderer to
> nil.  That helped, but it is still taking at least 10 minutes to render
> a thread.  I killed it when I ran out of patience.
> 
> The thread has 231 messages, and running
> 
>  notmuch show thread:d637 | wc -l
> 
> shows that it is 46918 lines long.  Running that on the command line is
> fast, taking 0.123 seconds.  As a comparison, I tried opening the thread
> with astroid.  It was not instantaneous, but it only took about 3
> seconds.
> 
> I am guessing that the emacs mode is trying to process the result.  I
> can work around this a bit by opening individual messages with "C-u RET"
> instead of "RET".  But then I lose context.
> 
> Is there anything else I can do to make this work?
> 
> Thanks,
> Walter Landry
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: How do you synchronize your notmuch tags across multiple machines?

[Brian Sniffen]

I had the same problem. I found a solution: dispense with imap. This can be in 
two ways:

For work, I use getmail (and imap) to read messages from an Exchange server and 
drop them in a maildir. Muchsync then coordinates those. 

For personal mail, I just use muchsync to directly manipulate Dovecot’s 
maildir. 

Both work fine. In the “work” case, changes are not pushed back up to the 
server. 

-- 
Brian Sniffen

> On Jan 3, 2019, at 5:27 PM, Dan Čermák  wrote:
> 
> I have just given muchsync a try and it synchronizes email and tags very
> quickly. I am quite impressed by it!
> 
> Unfortunately, I have hit exactly the same problem that you describe: I
> have to have a single machine that pulls in my email via offlineimap and
> then sync to the others via muchsync. That is a little inconvenient, as
> I was hoping that I could switch the "master" depending on which machine
> I am currently using and not having it up and online at all times.
> 
> I am afraid that that's not going to be easy to accomplish, as it
> requires muchsync and a maildir synchronization program (in my case
> offlineimap) to play together. The problem with offlineimap seems to be
> that it expects the maildir filenames to have a different form and does
> not recognize those that muchsync created (and it instead tries to clone
> all my inboxes again). In case I'll manage to get muchsync to work
> without a dedicated master, I'll let the list know.
> 
> 
> Cheers,
> 
> Dan
> 
> Tom Hirschowitz  writes:
> 
>> I also use muchsync. Had a few issues with it in the beginning but the
>> author, David Mazières, was quite efficient in fixing them, and patient
>> with me being awkwardly incompetent. It's been working like a charm
>> since then.
>> 
>> It took me some time to figure out a working set up though. My mail is
>> now fetched first on the same machine everytime, and then synchronised
>> from other machines through muchsync. This is a bit annoying, and I'd be
>> curious if anyone had a better way.
>> 
>> Tom
>> 
>>> * Dan Čermák:
>>> 
>>>> I have found muchsync, but unfortunately very little reports about how
>>>> well it works, which isn't necessarily a bad thing.
>>> 
>>> Muchsync works well for me, although I only need to sync between two
>>> machines. It is quite fast after the initial synchronisation, and I
>>> did not have any problems yet. I reported a small error in the
>>> documentation, but that should be fixed by now.
>>> 
>>> -Ralph
>>> ___
>>> notmuch mailing list
>>> notmuch@notmuchmail.org
>>> https://notmuchmail.org/mailman/listinfo/notmuch
>> ___
>> notmuch mailing list
>> notmuch@notmuchmail.org
>> https://notmuchmail.org/mailman/listinfo/notmuch
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: tip: how to not forget attachments

[Brian Sniffen]

Throw your function name, catch it outside the save-excursion, and raise an 
error there?

-- 
Brian Sniffen

> On Mar 19, 2018, at 4:16 PM, Antoine Beaupré <anar...@orangeseeds.org> wrote:
> 
>> On 2018-03-19 15:57:05, Brian Sniffen wrote:
>> `error` doesn’t do any unwinding; it leaves the program state wherever it 
>> was for analysis.  You probably want throw/catch, as described at 
>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Catch-and-Throw.html#Catch-and-Throw
> 
> Wait, but what tag would I throw? message-send doesn't do any catching
> around the hook calls...
> 
> a.
> 
> -- 
> The United States is a nation of laws:
> badly written and randomly enforced.
>- Frank Zappa

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: tip: how to not forget attachments

[Brian Sniffen]

`error` doesn’t do any unwinding; it leaves the program state wherever it was 
for analysis.  You probably want throw/catch, as described at 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Catch-and-Throw.html#Catch-and-Throw

-- 
Brian Sniffen

> On Mar 19, 2018, at 3:25 PM, Antoine Beaupré <anar...@orangeseeds.org> wrote:
> 
>> On 2018-03-19 13:56:54, Antoine Beaupré wrote:
>> PS: don't we have a "you forgot to actually attach the damn file" plugin
>> when we detect the word "attachment" and there's no attach? :p
> 
> So I figured that one out, I think. Before adding it to the wiki, I'd
> like a review of the code (attached) from more adept elisp programmers.
> 
> I'm particularly surprised that save-excursion doesn't work the way I
> expect: when I answer "no" to the question, I go back to the email
> buffer, but the point is invariably at the end of the buffer, whereas I
> would expect it to be where it was when I send the message. It looks
> like something else moves the mark before my hook, but I'm not sure
> what...
> 
> How else than (error) or (keyboard-quit) am I supposed to abort email
> sending? (message-send) uses the latter but it would seem better to use
> an actual error message than to just "beep" our way out here..
> 
> Other advice? (save-excursion) + (goto-char (point-min)) +
> (re-search-forward), is that idiomatic? or is there something more
> clever that should be done?
> 
> thanks!
> 
> -- 
> Tu connaîtras la vérité de ton chemin à ce qui te rend heureux.
>- Aristote
> 
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: a temporary nmweb view of notmuch mailing list archive

[Brian Sniffen]

show_thread_nav = True , and take through 
https://github.com/briansniffen/notmuch/commit/021c914fc5cc1029778794cc5630373041066889

-- 
Brian Sniffen

> On Feb 15, 2018, at 11:06 AM, Daniel Kahn Gillmor <d...@fifthhorseman.net> 
> wrote:
> 
>> On Sun 2018-02-11 15:03:05 -0500, Daniel Kahn Gillmor wrote:
>>> On Sat 2018-02-10 13:57:34 -0500, Brian Sniffen wrote:
>>> It looks like you have thread next/pref turned off. Is there a reason,
>>> including the reason that I hadn’t documented it?
>> 
>> nope, i just didn't fiddle with it much beyond setting it up and trying
>> to make sure the system integration didn't seem wildly dangerous.  happy
>> to tweak it further, and will take any recommendations. :)
> 
> hm, looking into this a little bit, i don't actually see how to turn it
> on.  if you've got pointers or documentation, i would be happy to read
> it.
> 
>--dkg
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: a temporary nmweb view of notmuch mailing list archive

[Brian Sniffen]

It looks like you have thread next/pref turned off. Is there a reason, 
including the reason that I hadn’t documented it?

-- 
Brian Sniffen

> On Feb 8, 2018, at 11:28 PM, Daniel Kahn Gillmor <d...@fifthhorseman.net> 
> wrote:
> 
>> On Sun 2018-02-04 23:09:35 -0500, Daniel Kahn Gillmor wrote:
>> 
>> I did a bit of experimenting with Brian Sniffen's proposed notmuch-web
>> branch, and it's now (temporarily) publishing a view of the notmuch
>> mailing list here:
>> 
>>https://nmbug.notmuchmail.org/btsmail/
>> 
>> I DO NOT EXPECT THIS URL TO BE STABLE -- please do not use links to it
>> in permanent places, this is just for experimentation at the moment.
> 
> this is gradually getting better.  new messages to the list are
> automatically archived and visible here, and the archive doesn't
> spontaneously break in ways i can't predict.
> 
> it does still break every time an authorized user does "nmbug push"
> though, and i don't currently understand why.  I'm putting in place a
> workaround for it but if anyone has suggestions for debugging it
> server-side, i'm all ears.  nmbug is backed server-side by gitolite, and
> i don't know gitolite well enough to know how it sets umask or
> permissions by default.
> 
>   --dkg
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v2] cli/insert: new message file can be world-readable (rely on umask)

[Brian Sniffen]

If there’s a hidden danger in these modes, better to leave the switch requiring 
octal tunes!

-- 
Brian Sniffen

> On Feb 8, 2018, at 8:40 PM, Daniel Kahn Gillmor <d...@fifthhorseman.net> 
> wrote:
> 
>> On Tue 2018-02-06 14:43:56 -0500, Daniel Kahn Gillmor wrote:
>> There are legitimate cases (public archives) where a user might
>> actually want their archive to be readable to the world.
>> 
>> "notmuch insert" historically used mode 0600 (unreadable by group or
>> other), but that choice doesn't appear to have been specifically
>> justified (perhaps an abundance of caution?).
>> 
>> This patch also adjusts the default mode used for --create-folder, to
>> be mode 0755 before the application of the umask.
>> 
>> If the user wants "notmuch insert" to create files or folders that are
>> not readable by group or other, they can set their umask more
>> restrictively.
> 
> I'm now having second thoughts about this.
> 
> postfix's local delivery agent has apparently been delivering with mode
> 0600 for nearly 20 years:
> 
>
> https://github.com/vdukhovni/postfix/blame/master/postfix/src/local/maildir.c#L188
> 
> And dovecot's lda defaults to 0600 on delivery:
> 
>
> https://sources.debian.org/src/dovecot/1:2.2.33.2-1/src/lib-storage/mail-storage.c/?hl=2591#L2591
> 
> So maybe there's something i don't know about why a delivery agent would
> want to have this restrictive mask?
> 
> Perhaps a better way to fix this is with a new option to notmuch insert.
> 
> on IRC, bremner suggests something flexible like --mode=0600
> 
> I'm more inclined to keep it simpler and more usable (most people don't
> know octal, let alone unix permissions bits) and just have a boolean
> --world-readable which defaults to false (and switches between modes
> 0600 and 0644 for files, and 0700 and 0755 for directories).
> 
> Any thoughts?
> 
>--dkg
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: web interface to notmuch

[Brian Sniffen]

> Assuming that you had a sanitize_this_html_part() function available to
> you, do you think it would be possible to make this safe?  Have you
> considered proposing it for inclusion in contrib upstream?

Okay, https://github.com/briansniffen/notmuch/tree/nmweb is now rebased
onto the notmuchmail.org head as of this morning.  All of the changes
are under contrib/notmuch-web.

I haven't done this before, so: exactly how would you like this proposed
for upstream inclusion?  It looks from
https://notmuchmail.org/contributing/ like you'd like documentation,
tests, NEWS, and then `git send-email`.  Is that right?  

Do you want this crunched into one commit, "write an e-mail client"?

Thanks,
Brian
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: web interface to notmuch

[Brian Sniffen]

> On Oct 31, 2017, at 5:32 PM, Matthew Lear  wrote:
> 
> 
> FWIW this link 
> (https://nmweb.evenmere.org/show/CACMMjMLecmXopb8AATjE3UuCnNLOO%2B5Nmev5X8K-UostDEUdrQ%40mail.gmail.com)
>  has the tag attachment applied to the message, but there is no attachment 
> shown.  And another 
> (https://nmweb.evenmere.org/show/87d31artti.fsf%40inf-8657.int-evry.fr).

Funny thing, the text of those attachments was being emitted by the app 
server... but since an iframe tag used in showing text/html parts *wasn’t* 
being closed, that didn’t matter.

I’ll push some fixes to encoding to github later today.___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: web interface to notmuch

[Brian Sniffen]

> just remove it), but along the way of searching and viewing mail, I've
> encountered quite a few occurrences of failing to UnicodeEncode. An example
> backtrace looks like this:
>
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/dist-packages/web/application.py", line 239, in
> process
> return self.handle()
>   File "/usr/lib/python2.7/dist-packages/web/application.py", line 230, in
> handle
> return self._delegate(fn, self.fvars, args)
>   File "/usr/lib/python2.7/dist-packages/web/application.py", line 420, in
> _delegate
> return handle_class(cls)
>   File "/usr/lib/python2.7/dist-packages/web/application.py", line 396, in
> handle_class
> return tocall(*args)
>   File "/b/git/notmuch-brians.git/contrib/notmuch-web/nmweb.py", line 153,
> in GET
> sprefix=webprefix)
>   File "/usr/lib/python2.7/dist-packages/jinja2/environment.py", line 989,
> in render
> return self.environment.handle_exception(exc_info, True)
>   File "/usr/lib/python2.7/dist-packages/jinja2/environment.py", line 754,
> in handle_exception
> reraise(exc_type, exc_value, tb)
>   File "templates/show.html", line 1, in top-level template code
> {% extends "base.html" %}
>   File "templates/base.html", line 32, in top-level template code
> {% block content %}
>   File "templates/show.html", line 12, in block "content"
> {% for part in format_message(m.get_filename(),mid): %}{{ part|safe
> }}{% endfor %}
>   File "/b/git/notmuch-brians.git/contrib/notmuch-web/nmweb.py", line 245,
> in format_message_walk
> tags=safe_tags).encode(part.get_content_charset('ascii')))
> UnicodeEncodeError: 'latin-1' codec can't encode character u'\u201c' in
> position 1141: ordinal not in range(256)
>
> 127.0.0.1:60968 - - [31/Oct/2017 17:00:02] "HTTP/1.1 GET /show/
> 665d8c5c2b024898ae21951c4b8b4...@co2pr05mb747.namprd05.prod.outlook.com" -
> 500 Internal Server Error
>
> I'm no Python expert, but from a quick google it would seem like the cause
> of such an exception is related to not using utf-8.

Neat.  So to get there, this has to be a text/html part.  It has to have
been decoded, either with the declared content type or with ascii.  If a
\u201c (left double quote) showed up, it didn't get decoded as
ascii---and indeed, it looks like the content-type specifies latin-1.
But now when we try to encode back, using the same latin-1, it fails?
That's really neat.

> Brian - do you think something needs modifying in nmweb.py to cater for
> this type of thing, or is this somehow related my own mailstore (not sure
> why that would be as my messages haven't been modified).

Lots of mail has busted encoding.  I've done some defensive work against
that---look at decodeAnyway and shed a tear for purity---but clearly not
enough.  Can you send me a message that causes the problem?

In the mean time, I think like 245 ought to be, appropriately indented:

tags=safe_tags).encode(part.get_content_charset('ascii'),
'xmlcharrefreplace'))

Thanks for the report---investigating it showed me that the search box
doesn't tolerate that character either.

-Brian
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch does not find some mails which actually are part of a thread

[Brian Sniffen]

Try the first command prefixed with “echo”. You will see that your shell is 
interpreting the dollar signs. 

-- 
Brian Sniffen

> On Oct 28, 2017, at 2:43 PM, Gregor Zattler <telegr...@gmx.net> wrote:
> 
> Hi notmuch developers,
> 
> notmuch does not find some messages searched for with their
> Message-Id, while they are part of threads which can be shown
> with searches for Message-Ids of other mails in the very thread:
> 
> $ notmuch show --entire-thread=false  --format=raw --exclude=false -- 
> id:003601c7767f$99ed7a30$380a@Audrones
> Error: search term did not match precisely one message (matched 0 messages).
> 
> An email with this Message-Id exists in the mail store and it
> happens to be the first message in the following thread:
> 
> $ notmuch show  --entire-thread=true  --format=text --exclude=false --  
> id:69a0875ba022c84aba2dc975490de6810aa...@dissens-server.adk.dissens.de |grep 
> ^.message
> message{ id:003601c7767f$99ed7a30$380a@Audrones depth:0 match:0 
> excluded:0 
> filename:/home/grfz/Mail/dissens_e.V./cur/1175862594.14633_1751.pit:2,S
> message}
> message{ 
> id:69a0875ba022c84aba2dc975490de6810aa...@dissens-server.adk.dissens.de 
> depth:0 match:1 excluded:0 
> filename:/home/grfz/Mail/dissens_e.V./cur/1175863469.14633_3866.pit:2,S
> message}
> message{ id:004f01c776c2$a5587800$ef00a8c0@frauenservice39 depth:0 match:0 
> excluded:0 
> filename:/home/grfz/Mail/dissens_e.V./cur/1175862594.14633_1776.pit:2,S
> message}
> message{ 
> id:69a0875ba022c84aba2dc975490de6810aa...@dissens-server.adk.dissens.de 
> depth:0 match:0 excluded:0 
> filename:/home/grfz/Mail/dissens_e.V./cur/1175863469.14633_3881.pit:2,S
> message}
> 
> there are 4 messages in the thread, the 4 respective file names
> are correct.
> 
> The mails are special insofar as message 1 is essentially the
> same as message 2 which seems to be a bounced and somewhat
> mangled version of message 1, the same is true for messages 3 and
> 4 respective.
> 
> But nonetheless these are legitimate mails, but messages 1 and 3
> cannot be found with their respective Message-Ids.
> 
> 
> Any ideas why this happens?
> 
> Ciao; Gregor
> -- 
> -... --- .-. . -.. ..--.. ...-.-
> 
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: web interface to notmuch

[Brian Sniffen]

Daniel Kahn Gillmor <d...@fifthhorseman.net> writes:

> On Fri 2017-10-27 00:04:21 -0400, Brian Sniffen wrote:
>> With bleach integrated (all of five lines), I think this is safe enough
>> to let random notmuch users run it.
>
> hm, bleach might be a little too aggressive.
>
> jrollins just pointed toward:
>
> https://nmweb.evenmere.org/show/87innmvvam.fsf%40ligo.caltech.edu

That's fixed in 53403ecd, and there's some examples of bleach on a rope
at
https://nmweb.evenmere.org/show/20141107190321.GL23609%40odin.tremily.us

The mbox URL is linkified, the many other link-like texts aren't.


Next/prev links are at the bottom, and a thread listing.  I haven't
thought through how to get the body delivered immediately, but speed
seems acceptable.  Next up, some style revisions---and I'd love
proposals for something that looks less awful, or at least makes the
interface more clear.  UI design is a strong anti-specialty for me.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: web interface to notmuch

[Brian Sniffen]

Daniel Kahn Gillmor <d...@fifthhorseman.net> writes:

> On Wed 2017-10-25 18:03:01 -0400, Brian Sniffen wrote:
>> That's inspiring!  Now there's a demo of nmweb at
>>
>> https://nmweb.evenmere.org/
>
> this is very nice, Brian.

Thanks!  The part I'm happiest about is the speed: this is as fast as I
remember gmail being.  The Secret Ingredient is HTTP chunked encoding,
accessed through web.py's generators, and careful page design---almost
every byte from the server is renderable as it arrives, and later bytes
never disrupt placement of earlier objects.

> Your URL highlighter seems a bit trigger-happy though:
>
>https://nmweb.evenmere.org/show/8760s7zr47.fsf%40zancas.localnet
>
> I don't think bremner was trying to link to http://index.cc !

As a wise soul once told me, use a library and then blame them.  This is
the Mozilla Bleach library, used for both sanitizing text/html parts and
for linkifying text/plain parts.  But since that supports filtering:
sure, this can only linkify things starting with 'http[s]://'

>> It's possible to get it to dump the whole mbox by clicking through the
>> obvious links; please consider exploring at
>> https://nmweb.evenmere.org/search/monkey instead.
>
> this is interesting because it shows me threads where some messages have
> monkey in them, but i can't tell which messages actually have the
> relevant search term.  Maybe it could highlight the found messages?

Very careful examination would have shown that the em-dashes between
author and subject were red for matches.  Now matches are in italics.

> Also, once i'm looking at one message, i don't see an easy way to go
> "next" in the thread.

Yup.  The thread object isn't accessible by then: it existed in the
scope of the search query, and is gone by the time we show the message.
get_replies isn't available.  So what's the alternative?
get_thread_id(), search for that thread id, identify this message *in*
that thread id, and then link to the next message with a "next" link?
While doing it, why not show the thread structure at the bottom of the
message, I guess.

With bleach integrated (all of five lines), I think this is safe enough
to let random notmuch users run it.  The worst they'll do is expose
their mailstore on tcp/8080.  Any interest in taking this into the
upstream contrib directory?

-Brian
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: web interface to notmuch

[Brian Sniffen]

That's inspiring!  Now there's a demo of nmweb at

https://nmweb.evenmere.org/


It's possible to get it to dump the whole mbox by clicking through the
obvious links; please consider exploring at
https://nmweb.evenmere.org/search/monkey instead.  There are not many
monkeys in the inbox.

-Brian

Vladimir Panteleev  writes:

> Hi,
>
> Sorry to barge in, I noticed this thread and thought I'd try to have a 
> go at setting up a test DFeed instance.
>
> Here it is:
>
> http://dfeed-notmuch.k3.1azy.net/
>
> There is some more info on the help page:
>
> http://dfeed-notmuch.k3.1azy.net/help
>
> Posting is supported, but it is currently (intentionally) unconfigured 
> for now.
>
> What do you think?
>
> On 2017-10-21 22:21, Daniel Kahn Gillmor wrote:
>> On Sat 2017-10-21 23:00:00 +0300, Jani Nikula wrote:
>>> For the list archive, we could restrict to displaying text/plain only.
>> 
>> and text/x-diff, surely :)
>> 
>> But yeah, good point.
>> 
>> Brian, what do you think about such a constraint?  would that make your
>> implementation safe enough to put on the public Internet for a read-only
>> archive?
>> 
>>  --dkg
>> 
>> 
>> 
>> ___
>> notmuch mailing list
>> notmuch@notmuchmail.org
>> https://notmuchmail.org/mailman/listinfo/notmuch
>> 
>
> -- 
> Best regards,
>   Vladimir
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: web interface to notmuch

[Brian Sniffen]

> On Oct 19, 2017, at 12:55 PM, Daniel Kahn Gillmor <d...@fifthhorseman.net> 
> wrote:
> 
>> On Thu 2017-10-19 11:01:53 -0400, Brian Sniffen wrote:
>> I put together something like this, visible at
>> https://github.com/briansniffen/notmuch/tree/nmweb/contrib/notmuch-web
>> 
>> It's not much of a service.  I am pretty sure it is exploitable---that
>> content in text/html parts of messages can do Bad Things to your
>> session.
> 
> I think this is the crux of the problem, right?  I was noticing the
> other day that notmuch's own mail archives are published in pipermail,
> which is *absolutely terrible* compared to dealing with a mailstore with
> notmuch as a frontend.  I'd love to be able to expose the archive to the
> public this way.
> 
> Assuming that you had a sanitize_this_html_part() function available to
> you, do you think it would be possible to make this safe?  Have you
> considered proposing it for inclusion in contrib upstream?

I don’t think they can be sanitized. Web tech moves so fast. But maybe they can 
be isolated. GMail uses a separate domain for the content from the UI; I have 
hopes about response headers and iframe attributes. 

Also, if the whole site’s static—not just the nmweb part—you probably can’t 
hurt much. 
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: web interface to notmuch

[Brian Sniffen]

I put together something like this, visible at
https://github.com/briansniffen/notmuch/tree/nmweb/contrib/notmuch-web

It's not much of a service.  I am pretty sure it is exploitable---that
content in text/html parts of messages can do Bad Things to your
session.

I haven't thought nearly hard enough about how it will deal with
multiple users.

But it's < 250 lines of Python, so perhaps you can adapt it to what you
need.  It uses web.py, so you *could* run it standalone, but you'll
probably be happier with Apache or nginx or something in front of it,
handling TLS termination and that sort of thing.

It's only approach to sending mail is generating mailto: links that will
open in whatever client the user has configured.

-Brian

Matthew Lear  writes:

> Hello all. A little side project at work involves me trying to put together
> part of a knowledge share system where users can query and search email
> stored and indexed centrally (by offlineimap & notmuch). My intention is to
> provide a means to support multiple concurrent read-only accesses to the
> notmuch database from users' web browsers so they can query and search mail.
>
> Consider a few different email addresses being plugged into various
> systems, all receiving email on different topics. I'd like to build an
> application which presents a web frontend which I can run on the server
> which fetches and indexes the mail, and thus present a web interface to
> search all mail using notmuch.
>
> notmuch-web has not seen much development for a few years.
> noservice looks pretty nifty but I'm a little unsure of the status and if
> it's missing anything fundamental.
>
> I think my requirements are pretty basic:
>
> * Read-only access
> * Search and display mail only (no sending), including html mails
> * Freeform entry of search terms in accordance with notmuch-search-terms(7).
>
> Would anybody have any ideas about the best way to undertake such a project?
>
> notmuch-web and noservice definitively look like they could be leveraged,
> but I don't know if I'd be better trying to construct something from the
> ground up which is better suited / tailored to my requirements (which are
> much less than either of the above were intended to fulfil).
>
> A standalone app would be preferred rather than having to rely on a web
> server, although I'm not picky about infrastructure. Web based programming
> is not my forte so I'd appreciate any feedback relating also to
> implementation, currently available open source web frameworks which could
> be used / considered / leveraged, etc.
>
> Many thanks,
> --  Matt
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: change default for notmuch-crypto-process-mime to t

[Brian Sniffen]

Gpg is exposed to some zip bomb problems last I looked. But the worst that 
could do is fill your disk or crash your Emacs, right?  And I suspect the MIME 
library exposes similar issues in quantity. 

-- 
Brian Sniffen

> On Jul 10, 2017, at 4:42 PM, Daniel Kahn Gillmor <d...@fifthhorseman.net> 
> wrote:
> 
>> On Sun 2017-07-09 07:46:14 -0300, David Bremner wrote:
>> There are some cases like remote usage where this might cause
>> problems, but those users can easily customize the variable. The
>> inconvenience seems to be outweighed by the security benefit for most
>> users.
> 
> lgtm.  i'm not sure that this change is technically a "security
> benefit", though, it looks more like a "usability benefit", since the
> main use of process-crypto is likely to be decrypting messages.
> 
> for signature verification, there's some small security benefit, but
> since it's mainly exposure of interesting information to the user (as
> opposed to blocking users from doing unsafe things) it's still probably
> more on the usability side than security.
> 
> still, i think it's a good change.  If it uncovers performance problems
> on use cases that normal people care about, hopefully we can get
> examples of those use cases and get the performance problems fixed
> (rather than just encouraging those users to set the flag to nil).
> 
> --dkg
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: finding incoming messages in threads in which i've participated [was: Re: find threads where I and Jian participated but not Dave]

[Brian Sniffen]

Well, it's not quite *away* from Turing complete configuration... but it sounds 
like you might like the program that computes tags for new messages to get not 
only the message but also its thread id and read-only access to the database?  
Then both filtering "participated" and computing "participated" from "sent" 
become easy. And fancier ideas like computing tags from senders, list-id, the 
rest. 

-- 
Brian Sniffen

> On Jun 25, 2017, at 11:46 AM, Daniel Kahn Gillmor <d...@fifthhorseman.net> 
> wrote:
> 
> Hey all--
> 
> I really appreciate the thought and experimentation and research that's
> gone into this thread!
> 
>> On Thu 2017-06-22 17:00:58 -0700, Matt Armstrong wrote:
>> # All threads in which I participate get tag:participated
>> #  1) Find all threads with a message tagged new
>> # (finding all 'today' messages helps during testing,
>> # but isn't necessary)
>> #  2) Run through "xargs -s 2048 echo" to to group threads
>> # lines of about 2K in size.
>> #  3) For each line (2) produces, narrow the threads to
>> # those containing a message from me.
>> #  4) For each such thread, tag every message with +participated.
>> notmuch search --output=threads tag:new OR date:today | \
>>  xargs -s 2048 echo | \
>>  xargs -I '{}' notmuch search \
>>  --output=threads from:marmstrong AND \( '{}' \) | \
>>  sed -e 's,^,+participated -- ,' | \
>>  notmuch tag --batch
> 
> This makes sense to me, modulo the split into 2048-octet lines (magic
> numbers make me nervous, though i think i understand why you've included
> it).
> 
> That said, i've been trying to think lately about how to make notmuch a
> tool that's usable by normal humans, who probably won't want to
> understand all the moving pieces here.  I don't want yet another MUA
> that requires you to edit a turing-complete config file to get useful
> functionality -- we already have mutt for that :)
> 
> Is there a way that we can push this idea/functionality further into
> the core of notmuch in a way that makes it easier to use?
> 
> For example, would it make sense to have "notmuch new" (and "notmuch
> insert") do "thread-based propagation" of specific tags?  for example,
> consider the following (i've just made up the config options):
> 
>notmuch config set new.from_self_tags participated
>notmuch config set new.propagate_thread_tags participated
> 
> the idea is that "new.from_self_tags" would be applied by "notmuch new" or
> "notmuch insert" if the message was explicitly from: user.primary_email
> or user.other_email.
> 
> and additionally, if a message was inserted into a thread which has any
> of the new.propagated_thread_tags applied, the new message would also
> get those tags.
> 
> What do y'all think?
> 
>--dkg
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: find threads where I and Jian participated but not Dave

[Brian Sniffen]

David Bremner  writes:

> Xu Wang  writes:
>
>> I bump this. Actually more simple than that, how to search for thread
>> in which I have participated and Jian has participated? Excluding
>> threads in which Dave participated is perhaps more complicated.
>
> I don't know of an efficient way to do this. You could write a script
> something like
>
> notmuch search --output=threads from:Xu  > A
> notmuch search --output=threads from:Jian  > B
> comm -12 A B
>
> I think the output is sorted, but you might also have to sort A and B

I did test that part before posting mine, and the output is inverted.
--sort=oldest-first *also* gets it wrong, though in more subtle
ways. Piping through `sort -u` is the only way to be sure (I can't
imagine the -u helping, but I also can't imagine it hurting and it's
cheap). 
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Notmuch Emacs reply format=JSON

[Brian Sniffen]

You might like
[org-mime](http://orgmode.org/worg/org-contrib/org-mime.html) or
`mimedown`:

; For writing pretty mail
(defun mimedown ()
  (interactive)
  (save-excursion
(message-goto-body)
(mml-unsecure-message)
(let* ((sig-point (save-excursion (message-goto-signature) 
(forward-line -1) (point)))
   (orig-txt (buffer-substring-no-properties (point) sig-point)))
  (shell-command-on-region (point) sig-point "/usr/local/bin/pandoc 
--from markdown --to html --smart --standalone" nil t)
  (insert "\n")
  (insert orig-txt)
  (insert "
At least as seeds for your own work.  Mimedown copes smoothly with `>`
for replies, and was used for this message.  org-mime not so much---it
preserves line breaks, but leaves them as `>` prefixes, rather than
using a blockquote.

-Brian

bserrao  writes:

> Well, at work almost everyone uses Outlook (Exchange Server) and send HTML
> mails. I've made a script to convert mail to html before sending, but when
> replying emacs uses de '>' character has quotation and because of it the
> mail gets messed up when i do the conversion.
> From what i've read i've concluded that if using the format=json those HTML
> pieces were handled differently...maybe i'm wrong. I was just trying to
> find a solution/workaround to deal with this.
>
> Thanks, and sorry for my bad english.
>
> Bruno
>
> On Sat, Mar 11, 2017 at 5:17 PM David Bremner-2 [via notmuch] <
> ml-node+s198994n4037213...@n3.nabble.com> wrote:
>
>> bserrao <[hidden email]
>> > writes:
>>
>> > Hello,
>> >
>> > I need some help in changing the default reply format to JSON in
>> > notmuch-emacs.
>> > I've looked in the docs and there's this option:
>> >
>>
>> I'm afraid I don't understand what behaviour you want.  Internally
>> notmuch-emacs uses --format=sexp to communicate with the CLI, but this
>> output contains the same information --format=json.
>>
>> d
>> ___
>> notmuch mailing list
>> [hidden email] 
>> https://notmuchmail.org/mailman/listinfo/notmuch
>>
>>
>> --
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://notmuch.198994.n3.nabble.com/Notmuch-Emacs-reply-format-JSON-tp4037188p4037213.html
>> To unsubscribe from Notmuch Emacs reply format=JSON, click here
>> 
>> .
>> NAML
>> 
>>
>
>
>
>
> --
> View this message in context: 
> http://notmuch.198994.n3.nabble.com/Notmuch-Emacs-reply-format-JSON-tp4037188p4037238.html
> Sent from the notmuch mailing list archive at Nabble.com.
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: i do not have INBOX

[Brian Sniffen]

David Bremner  writes:

> David Belohrad  writes:
>
>>
>> my directory does not contain INBOX, as inside the Maildir folder is
>> directly /cur, /new, /tmp. How do I search in this particular one?
>
> Quoting notmuch-search-terms(7)
>
>The  exact  syntax for maildir folders depends on your mail configura‐
>tion. For maildir++, folder:"" matches the inbox folder (which is  the
>root  in  maildir++),  other  folder  names always start with ".", and
>nested folders are separated by "."s, such  as  folder:.classes.topol‐
>ogy.  For  "file  system" maildir, the inbox is typically folder:INBOX
>and   nested   folders   are   separated   by   slashes,suchas
>folder:classes/topology.
>
>> The question is related to usage of 'afew' to move all mails which
>> have 'deleted' tag into Trash folder (which I have under .Trash)
>
> Hopefully the above is enough to help you formulate the right query.
> You probably also want the options --format=text0 and --output=files for
> notmuch search.

The next paragraph of that man page has an important warning for anyone
planning on re-arranging files based on the results of notmuch:

   Both path: and folder: will find a message if any copy of that
   message  is  in  the specific directory/folder.

It's important to filter the names (e.g., `notmuch ...|grep -Fzv
/.|xargs -Ifoo mv foo $MAILDIR/.Trash/cur/`) before relying on them.

-Brian
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: converting attachments to text

[Brian Sniffen]

Sure!  Here's what I use for docx, and I think it could be adapted to
pdf with pdftotext or whatever you're already using there.  You need a
small shell script that reads from STDIN, writes to a file, and calls
pandoc or pdftotext or whatever, like ~/bin/antiwordx:

#!/bin/sh

tmpfile=$(mktemp /tmp/antiwordx.XX.docx)
trap 'rm -f -- "$tmpfile"' INT TERM HUP EXIT
cat > "$tmpfile"
pandoc --normalize -r docx -w markdown "$tmpfile"

You need a small handler function to call it from Elisp---see attached
file `inline-docx.el`, which assumed you have both the old `antiword`
for old-style .doc files and pandoc for new-style `docx`.

I apologize for the roughness of the code; it should probably use
customizable paths for pandoc and such.

-Brian



inline-docx.el
Description: application/emacs-lisp


Bart Bunting  writes:

> Hi,
>
> Just looking for some pointers.
>
> I have to deal with quite a few emails with attachments in either pdf or
> word format.
>
> I'm on a mac so can use applescript or something pdftotext or similar to
> convert them to text.
>
> I'm blind so use emacspeak as my primary interface.  Having an easy way
> to convert the notmuch attachments to text other than saving to a file
> and processing them would greatly speed up my workflow.
>
> Is there something in existance already to do this sort of thing?
>
> I have a little rudimentary lisp skill so can hack something up if
> someone can give me some pointers on a direction to head in.
>
> Any advice appreciated.
>
> Kind regards
>
> Bart
>
> Kind regards
> Bart
> -- 
>
> Bart Bunting - URSYS
> PH: 02 87452811
> Mbl: 0409560005
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: wildcards with path or folder

[Brian Sniffen]

One reason many people look for such is as part of a pipeline with 
--output=files and unlink. It is crucial to know that notmuch will tell you 
about every file name of every message that has any copy in those folders. You 
have to grep or otherwise restrict the list of paths to the folder you want, or 
lose data. 

-Brian
I know I can restore my Maildir from backups. Guess how?

-- 
Brian Sniffen

> On Dec 18, 2016, at 6:19 PM, Steven Allen <ste...@stebalien.com> wrote:
> 
> 
> Erik,
> 
> Erik Colson <e...@ecocode.net> writes:
>> hi,
>> 
>> How can I select all mails which are in a certain mail folder or
>> subfolders of it ?
> 
> You're probably looking for `path:path/to/folder/**` (e.g. `path:Archive/**`).
> 
> Documentation:
> 
> * man 7 notmuch-search-terms
> * https://notmuchmail.org/manpages/notmuch-search-terms-7/
> 
> - Steven
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] cli: consider files vanishing during notmuch new non-fatal

[Brian Sniffen]

> On Nov 12, 2016, at 11:10 AM, David Bremner <da...@tethera.net> wrote:
> 
> Brian Sniffen <b...@evenmere.org> writes:
> 
>>> 
>>> OK, but the patch proposed works both for people who want to be notified
>>> of this problem, and those that don't (with appropriate shell wrapping
>>> checking the return code).  
>> 
>> I think it will loop; how do I guarantee termination and indexing of all 
>> present messages if deletions cause errors?
> 
> stop deleting things? You can't guarantee termination and indexing of
> all present messages by ignoring deletions either.

That's hard, given dovecot pointed at the same maildir: it quickly moves files 
from new to cur. That makes notmuch insert pretty useless, and I rely on 
notmuch new to approach correctness. 

But maybe I misunderstand: is the idea that it will return an error but keep 
processing?  Or stop on that error?



___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] cli: consider files vanishing during notmuch new non-fatal

[Brian Sniffen]

> 
> OK, but the patch proposed works both for people who want to be notified
> of this problem, and those that don't (with appropriate shell wrapping
> checking the return code).  

I think it will loop; how do I guarantee termination and indexing of all 
present messages if deletions cause errors?

-Brian
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Emacs: postponing messages

[Brian Sniffen]

I just found this thread from June while looking to resume a draft saved
from another program (dovecot) and which was given the 'draft' tag by
synchronization from Maildir flags.  Mark, thanks!

I *think* all I have to do to deal with other clients accessing the
Maildir through IMAP is to remove 'Message-ID from message-deletable
headers, because other clients may be watching for that---though this
only matters if the draft is resumed and postponed again, rather than
deleted.

Does that sound right?

  (when draft
   (notmuch-message-unquote-some-mml))

One comment here: anyone using maildir flag synchronization will have
items with tag:draft but no quoted MML.  To help them reasonably
*discuss* quoted MML, even when working from a mix of notmuch and other
MUAs, can this use a distinct tag?  For example, tag:quoted-mml?

Thanks,
Brian
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Exchange mutilation of multipart/encrypted

[Brian Sniffen]

My employer uses an Exchange server in place of an MTA.  It mutilates
multipart/encrypted messages, so that when I receive a PGP/MIME message
the Emacs-notmuch interface shows me:

[ multipart/mixed ]
[ text/plain ]
[ ATT2: application/pgp-encrypted ]
[ msg.asc: application/octet-stream ]

When I used Gnus heavily, I wrote a little program to un-mutilate
PGP/MIME mail:

~~~
(defun repair-multipart-encrypted (article)
  Switch a multipart/mixed header to multipart/encrypted.
This helps cope with broken Exchange servers.
  (interactive (list (gnus-summary-article-number)))
  (gnus-with-article article
(message-narrow-to-head)
(goto-char (point-min))
(search-forward Content-Type)
(search-forward mixed)
(replace-match encrypted; protocol=\application/pgp-encrypted\ t t)
(widen))
  (let (gnus-mark-article-hook)
(gnus-summary-select-article t t nil article)))
~~~

I'd love to have a way to tell Emacs-notmuch to treat a part as of a
different type, and provide parameters.  Alternately, I'd be happy to
edit the file on disk and have it re-indexed---but that seems likely to
cause me regret.  Any advice?  I see
`notmuch-show-insert-bodypart-internal` and expect to call that
with a forced content-type.

Thanks,
Brian

-- 
Brian Sniffen
I reserve the right to evolve my views, and state that views I previously
 expressed may have been somehere along the spectrum from insufficiently
 nuanced through ill-informed to dead wrong.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Exchange mutilation of multipart/encrypted

[Brian Sniffen]

My employer uses an Exchange server in place of an MTA.  It mutilates
multipart/encrypted messages, so that when I receive a PGP/MIME message
the Emacs-notmuch interface shows me:

[ multipart/mixed ]
[ text/plain ]
[ ATT2: application/pgp-encrypted ]
[ msg.asc: application/octet-stream ]

When I used Gnus heavily, I wrote a little program to un-mutilate
PGP/MIME mail:

~~~
(defun repair-multipart-encrypted (article)
  "Switch a multipart/mixed header to multipart/encrypted.
This helps cope with broken Exchange servers."
  (interactive (list (gnus-summary-article-number)))
  (gnus-with-article article
(message-narrow-to-head)
(goto-char (point-min))
(search-forward "Content-Type")
(search-forward "mixed")
(replace-match "encrypted; protocol=\"application/pgp-encrypted\"" t t)
(widen))
  (let (gnus-mark-article-hook)
(gnus-summary-select-article t t nil article)))
~~~

I'd love to have a way to tell Emacs-notmuch to treat a part as of a
different type, and provide parameters.  Alternately, I'd be happy to
edit the file on disk and have it re-indexed---but that seems likely to
cause me regret.  Any advice?  I see
`notmuch-show-insert-bodypart-internal` and expect to call that
with a forced content-type.

Thanks,
Brian

-- 
Brian Sniffen
"I reserve the right to evolve my views, and state that views I previously
 expressed may have been somehere along the spectrum from insufficiently
 nuanced through ill-informed to dead wrong."

Re: Synchronization success stories?

[Brian Sniffen]

David Mazieres dm-list-email-notm...@scs.stanford.edu writes:

 David Bremner da...@tethera.net writes:

 Brian Sniffen bsnif...@akamai.com writes:

 I'm thrilled by using notmuch to manage my mail.  Low-latency search is
 very important to me.  But I use computers in a couple of
 places---several of which are laptops.  Has anyone stories to share of
 successful multi-computer notmuch sync, for a corpus of a
 quarter-million messages or so?  

 I use syncmaildir to sync the actual messages, and a copy of the output
 of notmuch dump in git to sync the metadata.

 It works OK. A bit slow; depends how often you need to fetch new mail.

 If you want to see my solution, it is here:

 http://www.scs.stanford.edu/~dm/muchsync-0.tar.gz

Thanks!  Much sync.  Wow.

It sounds like you're paying very careful attention to correctness and
performance, so I'm very glad to be able to start from that basis.

-Brian

 I'm a little embarrassed by this code, as I just started to test it a
 week ago then instantly became completely dependent on it.  I will
 probably change the name (from muchsync to syncmuch) and the database
 format before releasing.  But if you feel like beta-testing and giving
 me feedback, have a look.

 Beware that if you have been using notmuch dump, you may become
 instantly hooked on my solution...

 David

-- 
Brian Sniffen
Information Security
Akamai Technologies
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Synchronization success stories?

[Brian Sniffen]

David Mazieres  writes:

> David Bremner  writes:
>
>> Brian Sniffen  writes:
>>
>>> I'm thrilled by using notmuch to manage my mail.  Low-latency search is
>>> very important to me.  But I use computers in a couple of
>>> places---several of which are laptops.  Has anyone stories to share of
>>> successful multi-computer notmuch sync, for a corpus of a
>>> quarter-million messages or so?  
>>
>> I use syncmaildir to sync the actual messages, and a copy of the output
>> of "notmuch dump" in git to sync the metadata.
>>
>> It works OK. A bit slow; depends how often you need to fetch new mail.
>
> If you want to see my solution, it is here:
>
> http://www.scs.stanford.edu/~dm/muchsync-0.tar.gz

Thanks!  Much sync.  "Wow."

It sounds like you're paying very careful attention to correctness and
performance, so I'm very glad to be able to start from that basis.

-Brian

> I'm a little embarrassed by this code, as I just started to test it a
> week ago then instantly became completely dependent on it.  I will
> probably change the name (from muchsync to syncmuch) and the database
> format before releasing.  But if you feel like beta-testing and giving
> me feedback, have a look.
>
> Beware that if you have been using notmuch dump, you may become
> instantly hooked on my solution...
>
> David

-- 
Brian Sniffen
Information Security
Akamai Technologies

Synchronization success stories?

[Brian Sniffen]

I'm thrilled by using notmuch to manage my mail.  Low-latency search is
very important to me.  But I use computers in a couple of
places---several of which are laptops.  Has anyone stories to share of
successful multi-computer notmuch sync, for a corpus of a
quarter-million messages or so?  

I've tried offlineimap---it (and my Exchange sever) get grouchy with
mailboxes of that size.  I tried keeping ~/Maildir/ in Google Drive; it
took weeks to do the initial sync and I gave up.

I'm trying bittorrent-sync now, with no obivous failures.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Synchronization success stories?

[Brian Sniffen]

I'm thrilled by using notmuch to manage my mail.  Low-latency search is
very important to me.  But I use computers in a couple of
places---several of which are laptops.  Has anyone stories to share of
successful multi-computer notmuch sync, for a corpus of a
quarter-million messages or so?  

I've tried offlineimap---it (and my Exchange sever) get grouchy with
mailboxes of that size.  I tried keeping ~/Maildir/ in Google Drive; it
took weeks to do the initial sync and I gave up.

I'm trying bittorrent-sync now, with no obivous failures.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies