Re: correct way to search for only PDF attachments

2015-09-28 Thread Xu Wang
On Mon, Sep 28, 2015 at 10:00 PM, Carl Worth  wrote:
> 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.
>
>> 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).
>
> I'm not testing now, but I wouldn't be surprised if that ended up doing
> something like searching for a phrase like "attachment pdf" anywhere
> within a message. (The Xapian parser can be somewhat unpredictable when
> you give it unexpected input.)
>
>> Also, how does the first one above know that I want only PDF
>> attachments and not an attachment called "pdformula.txt" ?
>
> It doesn't know that you want only PDF attachments. The key part is that
> the indexing is performed by breaking text up into individual terms, (at
> punctuation boundaries usually). So a search specification like
> "attachment:pdf" is searching for things that were indexed with the
> "pdf" term within the attachment prefix. So that won't match a filename
> like pdformula.txt, (which would be indexed as two terms, "pdformula"
> and "txt"), but it would match pdf.ormula.txt, (which would be indexed
> as three terms, "pdf", "ormula" and "txt").
>
> The Xapian documentation can be examined if you want more details.

This is highly useful. Thank for such an explanation!! Thank you, Carl.

Kind regards,

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


Re: [PATCH 2/3] lib: add interface to delete directory documents

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

>
> XXX: Should this also remove the files under it, or assume that's been
> done by the caller? Should this incorporate some or all of the
> functionality of _remove_directory() in notmuch-new.c?

1) The top level _remove_directory function does seem to make sense in
  the lib, however
2) it calls remove_filename, which reads and writes add_files_state in
  pseudo-OO style.
3) In particular it needs to read synchronize_flags, and write
  renamed_messages and removed_messages.
  
I guess one solution would be to pass through three arguments. A fancier
version would be to pass in a "visitor" function and closure pointer.

The cowardly solution would be to point at POSIX rmdir, and leave the
discussion immediately above for the future.

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-28 Thread David Bremner
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

>>  
>> +# Kill the terminal/frame if we're creating one.
>> +if [ -z "$USE_EMACSCLIENT" -o -n "$CREATE_FRAME" -o -n "$NO_WINDOW" ]; then
>> +ELISP="${ELISP} (setq message-exit-actions (list 
>> #'save-buffers-kill-terminal))"
>> +fi
>
> I am not very happy that message-exit-actions was added to $ELISP when
> not using emacsclient; when emacs is started its sole (initial) purpose is
> to serve mail sending (and not lending a frame in some other emacs) -- in
> this case it would be nice to be able to retrieve the sent mail buffer.

I'm somewhat less sympathetic here. AIUI, the goal of notmuch-emacs-mua
is to provide a drop in tool to replace mutt for sending mail in the
shell or from other programs. In this case, I think the most common
expectation is to terminate after sending mail (e.g. to return use of
the shell to the user, or allow the spawning program to continue).
However, it seems like this would be relatively easy to set up some
customization in notmuch-message-mode so that it could check if running
from the cli, and then either kill-or-not emacs depending on some
variable. So I think I'd like to keep the current behaviour as default,
and make it customizable at the emacs level.

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


Re: correct way to search for only PDF attachments

2015-09-28 Thread Carl Worth
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.

> 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).

I'm not testing now, but I wouldn't be surprised if that ended up doing
something like searching for a phrase like "attachment pdf" anywhere
within a message. (The Xapian parser can be somewhat unpredictable when
you give it unexpected input.)

> Also, how does the first one above know that I want only PDF
> attachments and not an attachment called "pdformula.txt" ?

It doesn't know that you want only PDF attachments. The key part is that
the indexing is performed by breaking text up into individual terms, (at
punctuation boundaries usually). So a search specification like
"attachment:pdf" is searching for things that were indexed with the
"pdf" term within the attachment prefix. So that won't match a filename
like pdformula.txt, (which would be indexed as two terms, "pdformula"
and "txt"), but it would match pdf.ormula.txt, (which would be indexed
as three terms, "pdf", "ormula" and "txt").

The Xapian documentation can be examined if you want more details.

-Carl


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


correct way to search for only PDF attachments

2015-09-28 Thread Xu Wang
Hi,

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.

To understand more, what does the following search for?

from:jongho attachment:.*pdf

I know it is incorrect as the results tell me, but what exactly does it do?

Also, how does the first one above know that I want only PDF
attachments and not an attachment called "pdformula.txt" ?

Kind regards,

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