Re: correct way to search for only PDF attachments

2015-09-29 Thread Suvayu Ali
On Mon, Sep 28, 2015 at 07:00:13PM -0700, Carl Worth wrote:
> On Mon, Sep 28 2015, Xu Wang wrote:
> 
> > To understand more, what does the following search for?
> >
> > from:jongho attachment:.*pdf
> 
> Uhm, probably only strange things. There are some mechanisms for getting
> notmuch to emit some debugging information on what the final search
> terms end up being, (but I don't recall if they still require
> recompilation or not).

This should work:

  $ export NOTMUCH_DEBUG_QUERY=1
  $ notmuch count -- from:suvayu attachment:*.pdf
  Query string is:
  from:suvayu attachment:*.pdf
  Exclude query is:
  Xapian::Query()
  Final query is:
  Xapian::Query((Tmail AND ZXFROMsuvayu:(pos=1) AND Zattach:(pos=2) AND 
Zpdf:(pos=3)))
  217
  $ notmuch count -- from:suvayu attachment:pdf
  Query string is:
  from:suvayu attachment:pdf
  Exclude query is:
  Xapian::Query()
  Final query is:
  Xapian::Query((Tmail AND ZXFROMsuvayu:(pos=1) AND ZXATTACHMENTpdf:(pos=2)))
  151

I guess to answer the OP's question, the globbed form simply does a text
search of attach and pdf.  The keyword is not recognised at all.

Cheers,

-- 
Suvayu

Open source is the future. It sets us free.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: correct way to search for only PDF attachments

2015-09-29 Thread David Bremner
Suvayu Ali  writes:

> On Tue, Sep 29, 2015 at 08:00:18AM -0300, David Bremner wrote:
>>
>> Of course it is getting pretty big, I don't know what to do about
>> that.
>
> How about an overview in notmuch-search-terms with more detailed docs in
> an info page?  coreutils does this.  I don't think this will add any new
> build dependencies either, as sphinx supports info pages.  I see
> texinfo_documents is already defined in doc/conf.py.  Maybe that is an
> option?
>

I'm not really in favour of requiring anyone who is not already using
emacs to use info.  Of course we could provide the same long form docs
in other formats (most likely html).  I don't know if splitting into
shorter man pages plus a longer manual would really help, but it's
likely we could take better advantage of sphinx. I know that Patrick
Totzke started a rework of the docs

   https://github.com/pazz/notmuch/tree/docs

I don't think that's really in a state to contemplate merging (for one
thing it hasn't kept up with doc changes in master); but maybe somebody
wants to pick up where Patrick left off.

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


Re: [PATCH v4 0/5] notmuch-emacs-mua updates

2015-09-29 Thread David Bremner
Jani Nikula  writes:

> The main goal is to not force --create-frame on users who dislike
> it. Split to some hopefully less controversial prep patches.

series pushed.

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


Re: correct way to search for only PDF attachments

2015-09-29 Thread David Bremner
Carl Worth  writes:

> On Mon, Sep 28 2015, Xu Wang wrote:
>> I would look to look for all emails from a colleague jongho. I tried:
>>
>> from:jongho attachment:pdf
>>
>> which seems to do as I wanted.
>
> Good. That should work.

Another option is to use mimetype:pdf

man notmuch-search-terms is probably worth a look when facing these
kinds of puzzles. It contains both Carl's reply about term based search
and mine about the mimetype: prefix.  Of course it is getting pretty
big, I don't know what to do about that.

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


Re: correct way to search for only PDF attachments

2015-09-29 Thread Suvayu Ali
On Tue, Sep 29, 2015 at 08:00:18AM -0300, David Bremner wrote:
>
> Of course it is getting pretty big, I don't know what to do about
> that.

How about an overview in notmuch-search-terms with more detailed docs in
an info page?  coreutils does this.  I don't think this will add any new
build dependencies either, as sphinx supports info pages.  I see
texinfo_documents is already defined in doc/conf.py.  Maybe that is an
option?

-- 
Suvayu

Open source is the future. It sets us free.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] cli: use designated initializer to initialize add_files_state

2015-09-29 Thread David Bremner
Jani Nikula  writes:

> The side effect is that all of add_files_state will be initialized to
> zero, removing any lingering doubt that some of it might not be
> initialized. It's not a small struct, and the initialization is
> scattered around a bit, so this makes the code more readable.

pushed

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


Re: [PATCH v2] nmbug-status: add support for specifying sort order for each view

2015-09-29 Thread David Bremner
Jani Nikula  writes:

> Let each view have a "sort" key, typically used with values
> "oldest-first" or "newest-first" (although all values in Query.SORT
> are accepted), and sort the results accordingly. Oldest first remains
> the default.

pushed.

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


Re: [PATCH v4 5/5] notmuch-emacs-mua: do not create a frame by default with --client

2015-09-29 Thread Tomi Ollila
On Mon, Sep 28 2015, David Bremner  wrote:

> Tomi Ollila  writes:
>
>
>> if [ -n "$AUTO_DAEMON" -a -z "$CREATE_FRAME" ]; then
>> echo "$0: --auto-daemon is only applicable with --create-frame." >&2
>> exit 1   
>> fi
>>
>> without this one may execute ./notmuch-emacs-mua --client --auto-daemon
>> which yields starting emacs in daemon mode (in this example it is expected
>> emacs is not running; otherwise --auto-daemon has no use in this example)
>> -- but no ui to that newly-running emacs is provided. Similar behaviour
>> can be observed by the following
>>
>
> I think what you propose is fine for a followup patch; note that the
> scenario you worry about also needs --client to be a problem. Apparently
> nothing is uncontroversial here, but if auto-daemon only works with
> create frame, then perhaps the followup would be to have auto-daemon
> imply create-frame

Without --client --auto-daemon is no-op (as it is no-op in case emacs
server is already running). I am (only) concerned about user experience
when one runs --client --auto-daemon and user gets nothing (i.e. emacs
server is running in the background w/o any clients connected to it.

We could make --auto-daemon imply --create-frame, but then 

./notmuch-emacs-mua --auto-daemon (i.e. w/o --client) starts new mail
compose window to separate frame (even though user did not request
it w/ --create-frame)

(actually I already did the 'imply' option (easy, one line in script,
another in namual), just that testing it gave this thought...

... therefore I'd rather make ./notmuch-emacs-mua --auto-daemon
spit an error and exit -- but I can be convinced otherwise :)

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


Re: [PATCH v2] nmbug-status: add support for specifying sort order for each view

2015-09-29 Thread Tomi Ollila
On Tue, Sep 29 2015, David Bremner  wrote:

> Jani Nikula  writes:
>
>> Let each view have a "sort" key, typically used with values
>> "oldest-first" or "newest-first" (although all values in Query.SORT
>> are accepted), and sort the results accordingly. Oldest first remains
>> the default.
>
> pushed.

when can we expect nmbug status page update ? :D

>
> d

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