Re: [FEATURE] Purge ignored messages from index

2018-11-22 Thread Jeremy Nickurak
Don't they need to be in the index in order to match the ignore condition,
which then allows them to be excluded from usual activities?

What's the actual thing you're hoping to achieve by not having those
ignored messages be in the index?

On Thu, Nov 22, 2018 at 10:33 AM David Bremner  wrote:

> Markus Weimar  writes:
>
> > Indexed but subsequently ignored messages remain indexed. I suggest to
> purge them from the index as if the files were removed.
> >
> > Example:
> >
> > * Create index including spam directory
> > * Add spam directory to ignore list
> > * Neither ´new´ nor ´reindex 'folder:spam'´ purges the spam messages
> from the index
> >
>
> My first instinct would be to leave new as is, but change reindex to pay
> attention to some ignore parameter.
>
> d
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
>
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Emacs: render text/html by default and remove the multipart mime buttons?

2015-02-16 Thread Jeremy Nickurak
I have this in my .emacs:

(setq notmuch-multipart/alternative-discouraged '("text/plain" "text/html"))

In that order, it discourages text/plain in favor of text/html, but also
ends up discouraging text/html if there are other options. In particular,
if there's a text/calendar item, I generally want that one to be chosen
over other options.

On Sun, Feb 15, 2015 at 9:19 PM, Phil Crosby  wrote:

> Hey everyone,
>
> 1. Is it possible to configure Notmuch to show text/html parts by default,
> instead of text/plain? I've been looking through the source and it wasn't
> obvious to me.
>
> 2. Is it possible to hide the buttons which toggle multipart email
> visibility (and presumably unhide them via a command)? Most of my emails
> look like this screenshot; as you can see, the multipart buttons take up
> much of the email's real estate, especially for short emails, and they make
> the actual content of the email difficult to read.
>
> [image: Inline image 1]
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 163730 bytes
Desc: not available
URL: 



Feature suggestion. Indexing encrypted mail?

2014-04-07 Thread Jeremy Nickurak
Nonetheess, if you can tell from the index that a given message contains
the words "hotel" "wine" "wife" "secret" and "rendezvous", you can infer a
*lot* about the contents of encrypted contents of the message.


On Mon, Apr 7, 2014 at 9:57 AM, Jameson Graef Rollins <
jrollins at finestructure.net> wrote:

> On Mon, Apr 07 2014, john.wyzer at gmx.de wrote:
> >> confess i haven't been following closely), it wouldn't be much extra
> >> effort for someone to implement a filter that strips encryption from the
> >> message.  (this might still have the problem mentioned above about also
> >> stripping PGP/MIME signatures, but the signatures and the decrypted
> >> message itself would remain intact so they could be shown directly by
> >> notmuch show without trouble).
> >
> > I don't understand that. :-(
> > This sounds as if the view of the message is not generated from the
> > mail storage. Isn't the purpose of the index to find the appropriate
> > message file and everything else is generated from that file?
>
> I think that's exactly what Daniel is saying: what's viewed comes from
> the message directly, and not from the db.
>
> jamie.
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 



Re: Feature suggestion. Indexing encrypted mail?

2014-04-07 Thread Jeremy Nickurak
Nonetheess, if you can tell from the index that a given message contains
the words hotel wine wife secret and rendezvous, you can infer a
*lot* about the contents of encrypted contents of the message.


On Mon, Apr 7, 2014 at 9:57 AM, Jameson Graef Rollins 
jroll...@finestructure.net wrote:

 On Mon, Apr 07 2014, john.wy...@gmx.de wrote:
  confess i haven't been following closely), it wouldn't be much extra
  effort for someone to implement a filter that strips encryption from the
  message.  (this might still have the problem mentioned above about also
  stripping PGP/MIME signatures, but the signatures and the decrypted
  message itself would remain intact so they could be shown directly by
  notmuch show without trouble).
 
  I don't understand that. :-(
  This sounds as if the view of the message is not generated from the
  mail storage. Isn't the purpose of the index to find the appropriate
  message file and everything else is generated from that file?

 I think that's exactly what Daniel is saying: what's viewed comes from
 the message directly, and not from the db.

 jamie.

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


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


Feature suggestion. Indexing encrypted mail?

2014-04-05 Thread Jeremy Nickurak
Off the top of my head, you could have an encrypted index too, which you
can only search while able to decrypt. Certainly another level of
complexity.


On Sat, Apr 5, 2014 at 11:10 AM, David Bremner  wrote:

> john.wyzer at gmx.de writes:
>
> > Would it be possible to add the configurable option to also decrypt
> > encrypted messages on the fly while indexing to make them searchable,
> > too?
> >
> > That would be really great for people that consider gnupg  mainly an
> > encryption for transport or have their complete hard drive encrypted...
>
> As far I understand an attacker could reconstruct the message from the
> index, so one question is whether the extra complexity in notmuch is
> worth the minimal extra security over decrypting on delivery and storing
> plaintext on the (presumably encrypted) disk. Of course decrypting on
> delivery may be inconvenient (or impossible). I have CCed the two people
> who have implemented most of the crypto related stuff in notmuch so they
> can comment.
>
> d
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
-- next part --
An HTML attachment was scrubbed...
URL: 



Re: Feature suggestion. Indexing encrypted mail?

2014-04-05 Thread Jeremy Nickurak
Off the top of my head, you could have an encrypted index too, which you
can only search while able to decrypt. Certainly another level of
complexity.


On Sat, Apr 5, 2014 at 11:10 AM, David Bremner da...@tethera.net wrote:

 john.wy...@gmx.de writes:

  Would it be possible to add the configurable option to also decrypt
  encrypted messages on the fly while indexing to make them searchable,
  too?
 
  That would be really great for people that consider gnupg  mainly an
  encryption for transport or have their complete hard drive encrypted...

 As far I understand an attacker could reconstruct the message from the
 index, so one question is whether the extra complexity in notmuch is
 worth the minimal extra security over decrypting on delivery and storing
 plaintext on the (presumably encrypted) disk. Of course decrypting on
 delivery may be inconvenient (or impossible). I have CCed the two people
 who have implemented most of the crypto related stuff in notmuch so they
 can comment.

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

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


forwarding multiple messages from notmuch emacs

2013-04-24 Thread Jeremy Nickurak
Adam


On Tue, Apr 23, 2013 at 10:33 AM, Daniel Kahn Gillmor  wrote:

> hi notmuch folks--
>
> i'd like to be able to forward several messages from a given thread (up
> to and including the whole thread) to someone else.  I use
> notmuch-emacs.
>
> I don't think it's possible to do this at the moment;
> notmuch-show-forward-message just forwards the message where the point
> is located, even if the current region covers more than one message.
>
> I'd be happy to have a notmuch-show-forward-thread or
> notmuch-show-forward-all-expanded-messages or
> notmuch-show-forward-messages-from-region capability, but my elisp-fu is
> weak.  I'd be happy to test if someone wanted to send me a patch though
> :)
>
> Background: one of the reasons that people often give for the terrible
> e-mail practice of top-posting-with-all-previous-messages-trailing is
> that they want to be able to send a message to someone else and have
> them be able to see the whole thread (never mind that these kind of
> reverse-chronological forwarded messages are difficult to read).  I'd
> like to be able to respond to those claims with something like
> "reasonable MUAs should let you easily forward all messages in a thread
> if you want to catch someone up."
>
> I consider notmuch-emacs a reasonable MUA :)
>
> thanks everyone for notmuch,
>
> --dkg
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 



Re: forwarding multiple messages from notmuch emacs

2013-04-24 Thread Jeremy Nickurak
Adam


On Tue, Apr 23, 2013 at 10:33 AM, Daniel Kahn Gillmor d...@fifthhorseman.net
 wrote:

 hi notmuch folks--

 i'd like to be able to forward several messages from a given thread (up
 to and including the whole thread) to someone else.  I use
 notmuch-emacs.

 I don't think it's possible to do this at the moment;
 notmuch-show-forward-message just forwards the message where the point
 is located, even if the current region covers more than one message.

 I'd be happy to have a notmuch-show-forward-thread or
 notmuch-show-forward-all-expanded-messages or
 notmuch-show-forward-messages-from-region capability, but my elisp-fu is
 weak.  I'd be happy to test if someone wanted to send me a patch though
 :)

 Background: one of the reasons that people often give for the terrible
 e-mail practice of top-posting-with-all-previous-messages-trailing is
 that they want to be able to send a message to someone else and have
 them be able to see the whole thread (never mind that these kind of
 reverse-chronological forwarded messages are difficult to read).  I'd
 like to be able to respond to those claims with something like
 reasonable MUAs should let you easily forward all messages in a thread
 if you want to catch someone up.

 I consider notmuch-emacs a reasonable MUA :)

 thanks everyone for notmuch,

 --dkg

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


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


Re: forwarding multiple messages from notmuch emacs

2013-04-24 Thread Jeremy Nickurak
Sigh. Premature posting...

Adam Wolfe Gordon on here gave me a tip for this. It's not perfect, but it
works:

Start forwarding each of the emails, and just cut-and-paste the
#mml../#mml sections out of the buffers into a new email. That'll have
the effect of forwarding all the emails.


On Wed, Apr 24, 2013 at 12:09 PM, Jeremy Nickurak
not-m...@trk.nickurak.cawrote:

 Adam


 On Tue, Apr 23, 2013 at 10:33 AM, Daniel Kahn Gillmor 
 d...@fifthhorseman.net wrote:

 hi notmuch folks--

 i'd like to be able to forward several messages from a given thread (up
 to and including the whole thread) to someone else.  I use
 notmuch-emacs.

 I don't think it's possible to do this at the moment;
 notmuch-show-forward-message just forwards the message where the point
 is located, even if the current region covers more than one message.

 I'd be happy to have a notmuch-show-forward-thread or
 notmuch-show-forward-all-expanded-messages or
 notmuch-show-forward-messages-from-region capability, but my elisp-fu is
 weak.  I'd be happy to test if someone wanted to send me a patch though
 :)

 Background: one of the reasons that people often give for the terrible
 e-mail practice of top-posting-with-all-previous-messages-trailing is
 that they want to be able to send a message to someone else and have
 them be able to see the whole thread (never mind that these kind of
 reverse-chronological forwarded messages are difficult to read).  I'd
 like to be able to respond to those claims with something like
 reasonable MUAs should let you easily forward all messages in a thread
 if you want to catch someone up.

 I consider notmuch-emacs a reasonable MUA :)

 thanks everyone for notmuch,

 --dkg

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



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


gmail label support patch available for oflineimap

2012-11-28 Thread Jeremy Nickurak
Doing this on a directory basis is a non-starter for me. The reason that
Notmuch and gmail are a natural fit is that they both operate on
labels/tags instead of folders.
-- next part --
An HTML attachment was scrubbed...
URL: 



gmail label support in offlineimap - update

2012-11-28 Thread Jeremy Nickurak
As far as syncing flags to notmuch, it sounds like this would be easy to
achieve with an independent 3rd tool, or even a small script:
1) Find files in the maildir modified since the last check
2) Read their keywords headers
3) Update the notmuch tags accordingnly.

The other direction sounds like it would be trickier though, since there's
no obvious way to say "what notmuch tags have changed since time X?". Is
this something that notmuch could provide?

Alternatively, would it be a good idea to give notmuch a tags-changed hook,
so that an external tool could be called on a tag change? That sounds like
would solve this problem, keep the gmail/imap logic safely away from
notmuch, and probably provide some really interesting other opportunities
for automation of things by tags.
-- next part --
An HTML attachment was scrubbed...
URL: 



Re: gmail label support in offlineimap - update

2012-11-28 Thread Jeremy Nickurak
As far as syncing flags to notmuch, it sounds like this would be easy to
achieve with an independent 3rd tool, or even a small script:
1) Find files in the maildir modified since the last check
2) Read their keywords headers
3) Update the notmuch tags accordingnly.

The other direction sounds like it would be trickier though, since there's
no obvious way to say what notmuch tags have changed since time X?. Is
this something that notmuch could provide?

Alternatively, would it be a good idea to give notmuch a tags-changed hook,
so that an external tool could be called on a tag change? That sounds like
would solve this problem, keep the gmail/imap logic safely away from
notmuch, and probably provide some really interesting other opportunities
for automation of things by tags.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: gmail label support patch available for oflineimap

2012-11-28 Thread Jeremy Nickurak
Doing this on a directory basis is a non-starter for me. The reason that
Notmuch and gmail are a natural fit is that they both operate on
labels/tags instead of folders.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH v2] emacs: add function to toggle display of all multipart/alternative parts

2012-10-09 Thread Jeremy Nickurak
On Fri, Aug 10, 2012 at 1:10 AM, Mark Walters  
wrote:
>
> Some messages are sent as multipart/alternative but the alternatives
> contain different information. This allows the user to cycle which
> part to view. By default this is bound to 'W'.

I've started using this, and quite like it. Only thing missing I can
see would be a customizable way to say which types should be
preferred.


Re: [PATCH v2] emacs: add function to toggle display of all multipart/alternative parts

2012-10-09 Thread Jeremy Nickurak
On Fri, Aug 10, 2012 at 1:10 AM, Mark Walters markwalters1...@gmail.com wrote:

 Some messages are sent as multipart/alternative but the alternatives
 contain different information. This allows the user to cycle which
 part to view. By default this is bound to 'W'.

I've started using this, and quite like it. Only thing missing I can
see would be a customizable way to say which types should be
preferred.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH 0/2] emacs: per saved search sort order

2012-10-02 Thread Jeremy Nickurak
Would it be better to include sorting options in the query string?
Then it could just be stored in the saved search, and used outside
saved searches.

On Tue, Oct 2, 2012 at 2:18 PM, Jani Nikula  wrote:
> These (fairly unpolished) patches add support for defining the sort order
> for each saved search individually. The approach is very low-tech and
> simple; providing a separate alist which maps saved search names with sort
> order for the saved searches that should have a sort order overriding the
> default notmuch-search-oldest-first.
>
> Having this embedded directly in notmuch-saved-searches would be nicer, but
> also much more complicated due to backwards compatibility issues. I presume
> the diffstat would be at least an order of magnitude bigger.
>
> The patches may not be up to notmuch standards, but I'm providing them
> anyway should anyone find them useful.
>
> BR,
> Jani.
>
>
> Jani Nikula (2):
>   emacs: store sort order in the widgets in notmuch-hello
>   emacs: add support for defining custom sort order for saved searches
>
>  emacs/notmuch-hello.el |   10 +++---
>  emacs/notmuch-lib.el   |9 +
>  2 files changed, 16 insertions(+), 3 deletions(-)
>
> --
> 1.7.2.5
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 0/2] emacs: per saved search sort order

2012-10-02 Thread Jeremy Nickurak
Would it be better to include sorting options in the query string?
Then it could just be stored in the saved search, and used outside
saved searches.

On Tue, Oct 2, 2012 at 2:18 PM, Jani Nikula j...@nikula.org wrote:
 These (fairly unpolished) patches add support for defining the sort order
 for each saved search individually. The approach is very low-tech and
 simple; providing a separate alist which maps saved search names with sort
 order for the saved searches that should have a sort order overriding the
 default notmuch-search-oldest-first.

 Having this embedded directly in notmuch-saved-searches would be nicer, but
 also much more complicated due to backwards compatibility issues. I presume
 the diffstat would be at least an order of magnitude bigger.

 The patches may not be up to notmuch standards, but I'm providing them
 anyway should anyone find them useful.

 BR,
 Jani.


 Jani Nikula (2):
   emacs: store sort order in the widgets in notmuch-hello
   emacs: add support for defining custom sort order for saved searches

  emacs/notmuch-hello.el |   10 +++---
  emacs/notmuch-lib.el   |9 +
  2 files changed, 16 insertions(+), 3 deletions(-)

 --
 1.7.2.5

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


Better Gmail handling by not using Notmuch tags

2012-09-14 Thread Jeremy Nickurak
(Apologies for the double-post... got an email asking me to confirm my
address, which I thought meant I posted from the wrong address. Re-posted,
recieved another confirmation email. Confirmed one, and both got through.
Weird.)

On Fri, Sep 14, 2012 at 6:09 AM, Jeremy Nickurak
wrote:

> More relevant:
> https://developers.google.com/google-apps/gmail/imap_extensions
>
> On Fri, Sep 14, 2012 at 1:32 AM, Christophe-Marie Duquesne  chmd.fr>wrote:
>
>> You may want to have a look to the google mail API [1]
>>
>> [1]: https://developers.google.com/google-apps/email-settings/
>> ___
>> notmuch mailing list
>> notmuch at notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch
>>
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20120914/77d35b24/attachment.html>


Better Gmail handling by not using Notmuch tags

2012-09-14 Thread Jeremy Nickurak
More relevant:
https://developers.google.com/google-apps/gmail/imap_extensions

On Fri, Sep 14, 2012 at 1:32 AM, Christophe-Marie Duquesne wrote:

> You may want to have a look to the google mail API [1]
>
> [1]: https://developers.google.com/google-apps/email-settings/
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
-- next part --
An HTML attachment was scrubbed...
URL: 



Better Gmail handling by not using Notmuch tags

2012-09-14 Thread Jeremy Nickurak
More relevant:
https://developers.google.com/google-apps/gmail/imap_extensions

On Fri, Sep 14, 2012 at 1:32 AM, Christophe-Marie Duquesne wrote:

> You may want to have a look to the google mail API [1]
>
> [1]: https://developers.google.com/google-apps/email-settings/
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
-- next part --
An HTML attachment was scrubbed...
URL: 



Re: Better Gmail handling by not using Notmuch tags

2012-09-14 Thread Jeremy Nickurak
More relevant:
https://developers.google.com/google-apps/gmail/imap_extensions

On Fri, Sep 14, 2012 at 1:32 AM, Christophe-Marie Duquesne c...@chmd.frwrote:

 You may want to have a look to the google mail API [1]

 [1]: https://developers.google.com/google-apps/email-settings/
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch

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


Re: Better Gmail handling by not using Notmuch tags

2012-09-14 Thread Jeremy Nickurak
More relevant:
https://developers.google.com/google-apps/gmail/imap_extensions

On Fri, Sep 14, 2012 at 1:32 AM, Christophe-Marie Duquesne c...@chmd.frwrote:

 You may want to have a look to the google mail API [1]

 [1]: https://developers.google.com/google-apps/email-settings/
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch

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


Better Gmail handling by not using Notmuch tags

2012-09-13 Thread Jeremy Nickurak
Gmail doesn't have folders, of course, it has labels, which are
approximately equivalent to notmuch tags. The key difference being that a
message can only be in one folder, but it can have multiple tags/labels.

On Thu, Sep 13, 2012 at 8:35 AM, Damien Cassou wrote:

> Hi,
>
> I'm a Gmail user and would like to keep using Gmail web interface in
> parallel to Notmuch. Basically, I would like Notmuch to mimic Gmail's
> behavior. In the notmuch mailing list, users proposed to convert Gmail
> folders to Notmuch tags and back (e.g.,
> http://notmuchmail.org/pipermail/notmuch/2012/009280.html). However, I
> didn't see any out-of-the-box full implementation of this proposal.
>
> Another solution would be to work directly with folders from Notmuch.
> Adding a Notmuch tag would just copy the current mail file to a
> different folder. Removing a tag would just remove the current mail
> file from the folder. Would such a solution work? What would I loose?
>
> Thank you
>
> --
> Damien Cassou
> http://damiencassou.seasidehosting.st
>
> "Lambdas are relegated to relative obscurity until Java makes them
> popular by not having them." James Iry
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>
-- next part --
An HTML attachment was scrubbed...
URL: 



Re: Better Gmail handling by not using Notmuch tags

2012-09-13 Thread Jeremy Nickurak
Gmail doesn't have folders, of course, it has labels, which are
approximately equivalent to notmuch tags. The key difference being that a
message can only be in one folder, but it can have multiple tags/labels.

On Thu, Sep 13, 2012 at 8:35 AM, Damien Cassou damien.cas...@gmail.comwrote:

 Hi,

 I'm a Gmail user and would like to keep using Gmail web interface in
 parallel to Notmuch. Basically, I would like Notmuch to mimic Gmail's
 behavior. In the notmuch mailing list, users proposed to convert Gmail
 folders to Notmuch tags and back (e.g.,
 http://notmuchmail.org/pipermail/notmuch/2012/009280.html). However, I
 didn't see any out-of-the-box full implementation of this proposal.

 Another solution would be to work directly with folders from Notmuch.
 Adding a Notmuch tag would just copy the current mail file to a
 different folder. Removing a tag would just remove the current mail
 file from the folder. Would such a solution work? What would I loose?

 Thank you

 --
 Damien Cassou
 http://damiencassou.seasidehosting.st

 Lambdas are relegated to relative obscurity until Java makes them
 popular by not having them. James Iry
 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch

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


adding emacs-snapshot as alternative to emacs

2012-06-21 Thread Jeremy Nickurak
On Thu, Jun 21, 2012 at 10:25 AM, Rainer M Krug  wrote:

> I would like to install notmuch with emacs-snapshot on ubuntu, but it does
> not seem to be in the
> list of alternatives to emacs. I cmpiled the deb packages from source.
> I have one question and one suggestion:
>
> 1) what do I have to change to have emacs-snapshot as an alternative to
> emacs in the dependency
> list of the deb package?
>
> 2) Could emacs-snapshot be added as an alternative dependency into the
> source?
>

Here's what I'm using to get it to build right.
-- next part --
An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: 0001-debian-allow-emacs-snapshot-to-satisfy-build-depende.patch
Type: application/octet-stream
Size: 1249 bytes
Desc: not available
URL: 



Re: adding emacs-snapshot as alternative to emacs

2012-06-21 Thread Jeremy Nickurak
On Thu, Jun 21, 2012 at 10:25 AM, Rainer M Krug r.m.k...@gmail.com wrote:

 I would like to install notmuch with emacs-snapshot on ubuntu, but it does
 not seem to be in the
 list of alternatives to emacs. I cmpiled the deb packages from source.
 I have one question and one suggestion:

 1) what do I have to change to have emacs-snapshot as an alternative to
 emacs in the dependency
 list of the deb package?

 2) Could emacs-snapshot be added as an alternative dependency into the
 source?


Here's what I'm using to get it to build right.


0001-debian-allow-emacs-snapshot-to-satisfy-build-depende.patch
Description: Binary data
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] emacs: add a filter option to show

2012-04-24 Thread Jeremy Nickurak
Works-for-me, precisely as requested, thanks :)


Re: [PATCH] emacs: add a filter option to show

2012-04-24 Thread Jeremy Nickurak
Works-for-me, precisely as requested, thanks :)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


.. regarding opening the attached files ...

2012-04-16 Thread Jeremy Nickurak
No idea. I expect they don't use mailcap though... any KDE users here?

On Mon, Apr 16, 2012 at 10:54, David Belohrad  wrote:
> Does kde use the same database as gnome?
>
> Jeremy Nickurak napsal/a:
>
>>On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
>> wrote:
>>> Also, when the cursor is on the button you can hit 'o' to open with
>>> default mailcap app, 's' to save, and 'v' to view with a specified app.
>>
>>Is there any way of just getting it to ignore mailcap, and send
>>everything to xdg-open? It's always bothered me that there are 2
>>databases for file associations: mailcap (used only by Emacs, afaict),
>>and the xdg/gnome configuration (used by everything else).


.. regarding opening the attached files ...

2012-04-16 Thread Jeremy Nickurak
On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
 wrote:
> Also, when the cursor is on the button you can hit 'o' to open with
> default mailcap app, 's' to save, and 'v' to view with a specified app.

Is there any way of just getting it to ignore mailcap, and send
everything to xdg-open? It's always bothered me that there are 2
databases for file associations: mailcap (used only by Emacs, afaict),
and the xdg/gnome configuration (used by everything else).


Re: .. regarding opening the attached files ...

2012-04-16 Thread Jeremy Nickurak
On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
jroll...@finestructure.net wrote:
 Also, when the cursor is on the button you can hit 'o' to open with
 default mailcap app, 's' to save, and 'v' to view with a specified app.

Is there any way of just getting it to ignore mailcap, and send
everything to xdg-open? It's always bothered me that there are 2
databases for file associations: mailcap (used only by Emacs, afaict),
and the xdg/gnome configuration (used by everything else).
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: .. regarding opening the attached files ...

2012-04-16 Thread Jeremy Nickurak
No idea. I expect they don't use mailcap though... any KDE users here?

On Mon, Apr 16, 2012 at 10:54, David Belohrad da...@belohrad.ch wrote:
 Does kde use the same database as gnome?

 Jeremy Nickurak not-m...@trk.nickurak.canapsal/a:

On Mon, Apr 16, 2012 at 09:19, Jameson Graef Rollins
jroll...@finestructure.net wrote:
 Also, when the cursor is on the button you can hit 'o' to open with
 default mailcap app, 's' to save, and 'v' to view with a specified app.

Is there any way of just getting it to ignore mailcap, and send
everything to xdg-open? It's always bothered me that there are 2
databases for file associations: mailcap (used only by Emacs, afaict),
and the xdg/gnome configuration (used by everything else).
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


a DoS vulnerability associated with conflated Message-IDs?

2012-03-08 Thread Jeremy Nickurak
On Thu, Mar 8, 2012 at 10:16, Daniel Kahn Gillmor  
wrote:
> Any other suggestions or ideas?

What about representing the contents from both message in one apparent message?

- Aggregate the headers together, perhaps?
- Where headers disagree, display both
- If the bodies disagree, display both.


Re: a DoS vulnerability associated with conflated Message-IDs?

2012-03-08 Thread Jeremy Nickurak
On Thu, Mar 8, 2012 at 10:16, Daniel Kahn Gillmor d...@fifthhorseman.net 
wrote:
 Any other suggestions or ideas?

What about representing the contents from both message in one apparent message?

- Aggregate the headers together, perhaps?
- Where headers disagree, display both
- If the bodies disagree, display both.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


unexpected behavior for search

2012-02-10 Thread Jeremy Nickurak
What you'll probably find is that, of the messages in those threads,
some match tag:inbox, and some match tag:unread, but none match both.
Notmuch's search returns threads that have matching messages, not
matching threads.

On Fri, Feb 10, 2012 at 23:37, Bhaskara Marthi  wrote:
> Either I have the search syntax wrong or there's a bug somewhere.? Is this
> not how to combine multiple tags?? The output of the first invocation shows
> that there exist threads tagged both inbox and unread, but the second
> invocation does not find them.
> - Bhaskara
>
> $ notmuch search $(date +%s -d 2012-02-09)..$(date +%s) tag:inbox | grep
> unread
> thread:ff28? Today 12:41 [3/4] Mac Mason, Bhaskara Marthi; I'm
> getting a build failure (inbox unread)
> thread:ec68? Yest. 09:32 [1/6] Gon?alo Cabrita| Ken Conley;
> [ros-users] serial_communication release (inbox unread)
> $ notmuch search tag:inbox and tag:unread
> $
>
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch
>


Re: unexpected behavior for search

2012-02-10 Thread Jeremy Nickurak
What you'll probably find is that, of the messages in those threads,
some match tag:inbox, and some match tag:unread, but none match both.
Notmuch's search returns threads that have matching messages, not
matching threads.

On Fri, Feb 10, 2012 at 23:37, Bhaskara Marthi bhask...@gmail.com wrote:
 Either I have the search syntax wrong or there's a bug somewhere.  Is this
 not how to combine multiple tags?  The output of the first invocation shows
 that there exist threads tagged both inbox and unread, but the second
 invocation does not find them.
 - Bhaskara

 $ notmuch search $(date +%s -d 2012-02-09)..$(date +%s) tag:inbox | grep
 unread
 thread:ff28  Today 12:41 [3/4] Mac Mason, Bhaskara Marthi; I'm
 getting a build failure (inbox unread)
 thread:ec68  Yest. 09:32 [1/6] Gonçalo Cabrita| Ken Conley;
 [ros-users] serial_communication release (inbox unread)
 $ notmuch search tag:inbox and tag:unread
 $


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

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


[PATCH 3/6] emacs: make "+" and "-" tagging operations more robust

2012-01-28 Thread Jeremy Nickurak
Is it safe to assume that any reasonable seperator (comma, space,
semicolon, plus or minus sign, anything) won't show up in a tag name?

On Fri, Jan 27, 2012 at 21:41, Dmitry Kurochkin
 wrote:
> Before the change, "+" and "-" tagging operations in notmuch-search
> and notmuch-show views accepted only a single tag. ?The patch makes
> them use the recently added `notmuch-select-tags-with-completion'
> function, which allows to enter multiple tags with "+" and "-"
> prefixes. ?So after the change, "+" and "-" bindings allow to both add
> and remove multiple tags. ?The only difference between "+" and "-" is
> the minibuffer initial input ("+" and "-" respectively).
> ---
> ?emacs/notmuch-show.el | ? 65 +++
> ?emacs/notmuch.el ? ? ?| ?165 
> +
> ?2 files changed, 107 insertions(+), 123 deletions(-)
>
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 84ac624..03eadfb 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -38,8 +38,9 @@
>
> ?(declare-function notmuch-call-notmuch-process "notmuch" ( args))
> ?(declare-function notmuch-fontify-headers "notmuch" nil)
> -(declare-function notmuch-select-tag-with-completion "notmuch" (prompt  
> search-terms))
> +(declare-function notmuch-select-tags-with-completion "notmuch" ( 
> initial-input  search-terms))
> ?(declare-function notmuch-search-show-thread "notmuch" nil)
> +(declare-function notmuch-update-tags "notmuch" (current-tags changed-tags))
>
> ?(defcustom notmuch-message-headers '("Subject" "To" "Cc" "Date")
> ? "Headers that should be shown in a message, in this order.
> @@ -1267,7 +1268,7 @@ Some useful entries are:
>
> ?(defun notmuch-show-mark-read ()
> ? "Mark the current message as read."
> - ?(notmuch-show-remove-tag "unread"))
> + ?(notmuch-show-tag-message "-unread"))
>
> ?;; Functions for getting attributes of several messages in the current
> ?;; thread.
> @@ -1470,51 +1471,33 @@ than only the current message."
> ? ? ? ? ? ?(message (format "Command '%s' exited abnormally with code %d"
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? shell-command exit-code
>
> -(defun notmuch-show-add-tags-worker (current-tags add-tags)
> - ?"Add to `current-tags' with any tags from `add-tags' not
> -currently present and return the result."
> - ?(let ((result-tags (copy-sequence current-tags)))
> - ? ?(mapc (lambda (add-tag)
> - ? ? ? ? ? (unless (member add-tag current-tags)
> - ? ? ? ? ? ? (setq result-tags (push add-tag result-tags
> - ? ? ? ? ? add-tags)
> - ? ?(sort result-tags 'string<)))
> -
> -(defun notmuch-show-del-tags-worker (current-tags del-tags)
> - ?"Remove any tags in `del-tags' from `current-tags' and return
> -the result."
> - ?(let ((result-tags (copy-sequence current-tags)))
> - ? ?(mapc (lambda (del-tag)
> - ? ? ? ? ? (setq result-tags (delete del-tag result-tags)))
> - ? ? ? ? del-tags)
> - ? ?result-tags))
> -
> -(defun notmuch-show-add-tag ( toadd)
> - ?"Add a tag to the current message."
> - ?(interactive
> - ? (list (notmuch-select-tag-with-completion "Tag to add: ")))
> +(defun notmuch-show-tag-message ( changed-tags)
> + ?"Change tags for the current message.
>
> +`Changed-tags' is a list of tag operations for \"notmuch tag\",
> +i.e. a list of tags to change with '+' and '-' prefixes."
> ? (let* ((current-tags (notmuch-show-get-tags))
> - ? ? ? ?(new-tags (notmuch-show-add-tags-worker current-tags toadd)))
> -
> + ? ? ? ?(new-tags (notmuch-update-tags current-tags changed-tags)))
> ? ? (unless (equal current-tags new-tags)
> - ? ? ?(apply 'notmuch-tag (notmuch-show-get-message-id)
> - ? ? ? ? ? ?(mapcar (lambda (s) (concat "+" s)) toadd))
> + ? ? ?(apply 'notmuch-tag (notmuch-show-get-message-id) changed-tags)
> ? ? ? (notmuch-show-set-tags new-tags
>
> -(defun notmuch-show-remove-tag ( toremove)
> - ?"Remove a tag from the current message."
> - ?(interactive
> - ? (list (notmuch-select-tag-with-completion
> - ? ? ? ? "Tag to remove: " (notmuch-show-get-message-id
> +(defun notmuch-show-tag ( initial-input)
> + ?"Change tags for the current message, read input from the minibuffer."
> + ?(interactive)
> + ?(let ((changed-tags (notmuch-select-tags-with-completion
> + ? ? ? ? ? ? ? ? ? ? ?initial-input (notmuch-show-get-message-id
> + ? ?(apply 'notmuch-show-tag-message changed-tags)))
>
> - ?(let* ((current-tags (notmuch-show-get-tags))
> - ? ? ? ?(new-tags (notmuch-show-del-tags-worker current-tags toremove)))
> +(defun notmuch-show-add-tag ()
> + ?"Same as `notmuch-show-tag' but sets initial input to '+'."
> + ?(interactive)
> + ?(notmuch-show-tag "+"))
>
> - ? ?(unless (equal current-tags new-tags)
> - ? ? ?(apply 'notmuch-tag (notmuch-show-get-message-id)
> - ? ? ? ? ? ?(mapcar (lambda (s) (concat "-" s)) toremove))
> - ? ? ?(notmuch-show-set-tags new-tags
> +(defun notmuch-show-remove-tag ()
> + ?"Same as `notmuch-show-tag' but sets initial input to '-'."
> + ?(interactive)
> + ?(notmuch-show-tag "-"))
>
> ?(defun 

[PATCH] emacs: add default value to notmuch-search-line-faces

2012-01-26 Thread Jeremy Nickurak
On Thu, Jan 26, 2012 at 12:41, Austin Clements  wrote:
> As much as I would like this, many terminals don't visually
> distinguish between the default face and the default face in bold.

I've taken a shot at this under xterm, gnome-terminal, and a basic
linux VT. I figure that if something is broken in another terminal
that breaks in one of these, it's somebody-elses-problem :)

Xterm/gnome-terminal support bold just fine. With a Linux VT, emacs
just chooses i slightly lighter color, which is totally usable.


Re: [PATCH] emacs: add default value to notmuch-search-line-faces

2012-01-26 Thread Jeremy Nickurak
On Thu, Jan 26, 2012 at 12:41, Austin Clements amdra...@mit.edu wrote:
 As much as I would like this, many terminals don't visually
 distinguish between the default face and the default face in bold.

I've taken a shot at this under xterm, gnome-terminal, and a basic
linux VT. I figure that if something is broken in another terminal
that breaks in one of these, it's somebody-elses-problem :)

Xterm/gnome-terminal support bold just fine. With a Linux VT, emacs
just chooses i slightly lighter color, which is totally usable.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH v2 3/3] search: Support automatic tag exclusions

2012-01-16 Thread Jeremy Nickurak
On Mon, Jan 16, 2012 at 12:28, Austin Clements  wrote:
> Quoth David Edmondson on Jan 16 at ?9:12 am:
>> Having "deleted" and "spam" as default settings in the configuration
>> file might be more reasonable.
>
> Sorry, I'm confused. ?Are you saying deleted;spam should or should not
> be the default?

If I read correctly:

1) If no exclude options are in the config file, none should be used.
2) On notmuch setup, "deleted" and "spam" should be added to .notmuch-config


Re: [PATCH v2 3/3] search: Support automatic tag exclusions

2012-01-16 Thread Jeremy Nickurak
On Mon, Jan 16, 2012 at 12:28, Austin Clements amdra...@mit.edu wrote:
 Quoth David Edmondson on Jan 16 at  9:12 am:
 Having deleted and spam as default settings in the configuration
 file might be more reasonable.

 Sorry, I'm confused.  Are you saying deleted;spam should or should not
 be the default?

If I read correctly:

1) If no exclude options are in the config file, none should be used.
2) On notmuch setup, deleted and spam should be added to .notmuch-config
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [ANNOUNCE] mutt with notmuch support

2012-01-10 Thread Jeremy Nickurak
FWIW, here's the patch I ended up using to play with this:

diff --git a/mutt_notmuch.c b/mutt_notmuch.c
index 2f21407..a07b1ba 100644
--- a/mutt_notmuch.c
+++ b/mutt_notmuch.c
@@ -636,11 +636,15 @@ char *nm_uri_from_query(CONTEXT *ctx, char *buf,
size_t bufsz)
 static notmuch_message_t *get_nm_message(notmuch_database_t *db, HEADER *hdr)
 {
        notmuch_message_t *msg;
+       notmuch_status_t r;
+
        char *id = nm_header_get_id(hdr);

        dprint(2, (debugfile, nm: find message (%s)\n, id));

-       msg = id  db ? notmuch_database_find_message(db, id) : NULL;
+       if (id  db) {
+               r = notmuch_database_find_message(db, id, msg);
+       }

        FREE(id);
        return msg;
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[ANNOUNCE] mutt with notmuch support

2012-01-09 Thread Jeremy Nickurak
FWIW, here's the patch I ended up using to play with this:

diff --git a/mutt_notmuch.c b/mutt_notmuch.c
index 2f21407..a07b1ba 100644
--- a/mutt_notmuch.c
+++ b/mutt_notmuch.c
@@ -636,11 +636,15 @@ char *nm_uri_from_query(CONTEXT *ctx, char *buf,
size_t bufsz)
?static notmuch_message_t *get_nm_message(notmuch_database_t *db, HEADER *hdr)
?{
? ? ? ? notmuch_message_t *msg;
+ ? ? ? notmuch_status_t r;
+
? ? ? ? char *id = nm_header_get_id(hdr);

? ? ? ? dprint(2, (debugfile, "nm: find message (%s)\n", id));

- ? ? ? msg = id && db ? notmuch_database_find_message(db, id) : NULL;
+ ? ? ? if (id && db) {
+ ? ? ? ? ? ? ? r = notmuch_database_find_message(db, id, );
+ ? ? ? }

? ? ? ? FREE();
? ? ? ? return msg;


[PATCH v2 5/6] emacs: bind 'r' to reply-to-sender and 'R' to reply-to-all

2012-01-08 Thread Jeremy Nickurak
On Sun, Jan 8, 2012 at 16:32, Jameson Graef Rollins
 wrote:
> That's a good point. ?I think that maybe people are wanting to protect
> against the accidental reply to all when you only mean to reply to the
> sender.

Certainly a worthy cause. All I'm saying is I make the mistake in the
other direction more frequently ;)


[PATCH v2 5/6] emacs: bind 'r' to reply-to-sender and 'R' to reply-to-all

2012-01-08 Thread Jeremy Nickurak
On Sun, Jan 8, 2012 at 14:48, Jani Nikula  wrote:
> It seemed to me that most people wanted this, and nobody spoke for keeping
> the old binding now that we have reply-to-sender. This as a separate patch
> so it's easy to drop if needed.

FWIW, I generally prefer reply-all as the default. In my experience,
when a message is sent to a bunch of people, it's usually treated as a
"forum" discussion where everybody wants to be in on everything. Also,
once you've started composing, it's much easier to delete people you
don't want included than to add people who are no longer referenced in
the new buffer at all.


Re: [PATCH v2 5/6] emacs: bind 'r' to reply-to-sender and 'R' to reply-to-all

2012-01-08 Thread Jeremy Nickurak
On Sun, Jan 8, 2012 at 14:48, Jani Nikula j...@nikula.org wrote:
 It seemed to me that most people wanted this, and nobody spoke for keeping
 the old binding now that we have reply-to-sender. This as a separate patch
 so it's easy to drop if needed.

FWIW, I generally prefer reply-all as the default. In my experience,
when a message is sent to a bunch of people, it's usually treated as a
forum discussion where everybody wants to be in on everything. Also,
once you've started composing, it's much easier to delete people you
don't want included than to add people who are no longer referenced in
the new buffer at all.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v2 5/6] emacs: bind 'r' to reply-to-sender and 'R' to reply-to-all

2012-01-08 Thread Jeremy Nickurak
On Sun, Jan 8, 2012 at 16:32, Jameson Graef Rollins
jroll...@finestructure.net wrote:
 That's a good point.  I think that maybe people are wanting to protect
 against the accidental reply to all when you only mean to reply to the
 sender.

Certainly a worthy cause. All I'm saying is I make the mistake in the
other direction more frequently ;)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch