Re: Is there a prefix that performs from: and to: simultaneously?

2017-09-21 Thread Attic Hermit 

> +john +friend -- tag:new AND (to:j...@example.tld OR
> from:j...@example.tld)

First did I tried that form, but I felt that wasn't up to snuff because
I still have to write the same address two times.

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

Re: Is there a prefix that performs from: and to: simultaneously?

2017-09-21 Thread David Bremner 
Attic Hermit  writes:

> Batch file of my initial tagging script includes queries like below:
>
> +john +friend -- tag:new AND from:j...@example.tld
> +john +friend -- tag:new AND to:j...@example.tld
>
> But I want to compress the above in one line like:
>
> +john +friend -- tag:new AND from_or_to:j...@example.tld
>

How about

+john +friend -- tag:new AND (to:j...@example.tld OR from:j...@example.tld)

?

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

Re: Washing GitHub emails to include inline patch?

2017-09-21 Thread Kyle Meyer 
William Casarin writes:

> Most of the patches I review these days comes in as GitHub emails that
> look like this:
>
>
> You can view, comment on, or merge this pull request online at:

[...]

> -- Patch Links --
>
> https://github.com/monstercat/iris/pull/52.patch
> https://github.com/monstercat/iris/pull/52.diff

[...]

> I wonder if it would be be possible to wash this email by downloading
> the patch and present it inline like git-send-email. This would allow me
> to review patches without having to click around the GitHub interface.
> Has anyone done this?

I have a command in my Emacs configuration that I think gets close to
what you want.

--8<---cut here---start->8---
(defun km/open-github-patch (buffer)
  "Find GitHub patch link in BUFFER and show it in a new buffer."
  (let ((url
 (with-current-buffer buffer
   (save-excursion
 (goto-char (point-min))
 (if (re-search-forward "https://github.com/.*\\.patch; nil t)
 (match-string-no-properties 0)
   (user-error "No patch found"))
(with-current-buffer (get-buffer-create
  (generate-new-buffer-name "*mail-github-patch*"))
  (url-insert-file-contents url)
  (diff-mode)
  (view-mode 1)
  (pop-to-buffer (current-buffer)

(defun km/notmuch-show-open-github-patch ()
  "Open patch from GitHub email."
  (interactive)
  (with-current-notmuch-show-message
   (km/open-github-patch (current-buffer
--8<---cut here---end--->8---

The km/open-github-patch helper function exists because I made a slow
transition from gnus to notmuch and have a gnus variant that also calls
km/open-github-patch.  If km/notmuch-show-open-github-patch is the only
caller, there's not much point in having a separate helper function.

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

Is there a prefix that performs from: and to: simultaneously?

2017-09-21 Thread Attic Hermit 
Batch file of my initial tagging script includes queries like below:

+john +friend -- tag:new AND from:j...@example.tld
+john +friend -- tag:new AND to:j...@example.tld

But I want to compress the above in one line like:

+john +friend -- tag:new AND from_or_to:j...@example.tld

I know that I can achieve it approximately by querying without prefix,
but it'll also include the mails that include the string
"j...@example.tld".

I look through the manual, man:notmuch-search-terms, but I couldn't find
the prefix I want.

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

Re: [PATCH 0/9] argument parsing fixes and improvements

2017-09-21 Thread Daniel Kahn Gillmor 
On Thu 2017-09-21 20:07:30 +0300, Jani Nikula wrote:
> So I think I'd prefer either strict booleans where the default is one or
> the other, or an explicit tristate true|false|default. In your case,
> perhaps --try-decrypt=(true|false|database), where the default can be
> requested and clearly documented. And that's again not a bool, like
> notmuch search --exclude, but then neither is your proposed option. It
> has three options in reality, but you've hidden one.

being able to set a default in the database is definitely useful, rather
than having to find all the places that you (or some other tool) might
be invoking a notmuch indexing subcommand.

If you want to make it an explicit third variant as stated above, that's
fine, but then we don't get --no-try-decrypt from your series here,
which is itself a different kind of interface inconsistency. :/

I have plans for a few more boolean variables like this for indexing
that will store their defaults in the database.

Perhaps we should introduce a new tristate (true|false|database) type to
make that simpler to deal with internally, but could also implement
--no- prefixes?  If that was something you're interested in providing,
i'd be fine adjusting my patches to make use of it.

  --dkg


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

Re: notmuch.el: "wash" date in message display

2017-09-21 Thread Tomi Ollila 
On Wed, Sep 20 2017, Matt Armstrong wrote:

> I miss some of the Gnus "wash" functions available for message display.
> There was one that either reformatted the Date: header into my time
> zone, or displayed the Date in terms of elapsed time from now (e.g. 1
> hour ago, 1 day ago, etc.).  I don't remember which, but I'd be happy
> with either.

I personally use 

http://mid.mail-archive.com/1427132722-20346-1-git-send-email-tomi.ollila@iki.fi

-- this shows (date) in local time in addition to the default Date:
in case time zones differ...

>
> Has anybody integrated a feature like that into notmuch.el?  It wouldn't
> be hard, but I'd feel dumb if I did the work and there was some variable
> I could set to get a similar effect.

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

Re: [PATCH 0/9] argument parsing fixes and improvements

2017-09-21 Thread Jani Nikula 
On Wed, 20 Sep 2017, Daniel Kahn Gillmor  wrote:
> right, about the defaults: as i'm sure you're aware, i'm trying to
> introduce some boolean options whose default is "unset", meaning "do
> whatever is set in the database config".  In particular, --try-decrypt
> (for those subcommands which do indexing).  As you can see in
> id:20170912230153.4175-8-...@fifthhorseman.net, i handle this by
> declaring the internal variable as:
>
>int try_decrypt = -1;
>
> And then i decide to act on it with:
>
>if (try_decrypt == TRUE || try_decrypt = FALSE) {
>   /* act on it… */
>}
>
> Otherwise, i invoke the internal functions and let them behave as the
> database default does.

I think in general having stateful defaults are bad. See the code or
manual page for notmuch show. See how many defaults depend on some
*other* option, for absolutely no good reason. If you play with the
interface, you'll be surprised many times over how changing one knob
changes another as well. For example, switch output format, you'll get
entire threads as well. If you don't specify output format, choosing a
part will change the output format. Some unsupported combos result in
errors, some in warnings. It's a mess.

So I think I'd prefer either strict booleans where the default is one or
the other, or an explicit tristate true|false|default. In your case,
perhaps --try-decrypt=(true|false|database), where the default can be
requested and clearly documented. And that's again not a bool, like
notmuch search --exclude, but then neither is your proposed option. It
has three options in reality, but you've hidden one.

> This sort of goes against the trend of your
> id:5efab1e6d2250d87c909d9e5b435da5235efdc84.1505853159.git.j...@nikula.org,
> which prefers to use notmuch_bool_t for those declarations (and is maybe
> heading in the direction of stdbool.h).  How do you think we should
> implement a future boolean flag whose default value is "unset" if we
> head in this direction?

Indeed the direction is standard bools. I really see no reason to use
notmuch_bool_t except in the library interface for historical
reasons. Both sides of the interface could use stdbool.

I'm sure we could modify the argument parser to provide information
about options present and not, but given the above, I'm leaning towards
making the values explicit instead.

Further reading on orthogonality [1].

BR,
Jani.


[1] http://www.catb.org/esr/writings/taoup/html/ch04s02.html#orthogonality
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Washing GitHub emails to include inline patch?

2017-09-21 Thread William Casarin 

Hey team,

Most of the patches I review these days comes in as GitHub emails that
look like this:

--- Begin Message ---
You can view, comment on, or merge this pull request online at:
MIME-Version: 1.0
Content-Type: text/plain

  https://github.com/monstercat/iris/pull/52

-- Commit Summary --

  * Fix merge conflict putting location search into non-clean-ui iris

-- File Changes --

M bin/js/main.js (66)
M bin/js/users.js (71)
M html/head.html (2)
M templates/users.html (68)

-- Patch Links --

https://github.com/monstercat/iris/pull/52.patch
https://github.com/monstercat/iris/pull/52.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/monstercat/iris/pull/52
--- End Message ---


I wonder if it would be be possible to wash this email by downloading
the patch and present it inline like git-send-email. This would allow me
to review patches without having to click around the GitHub interface.
Has anyone done this?

Cheers,
William
 
-- 
https://jb55.com
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Default Tree View

2017-09-21 Thread Jani Nikula 
On Mon, Sep 18, 2017 at 11:42 AM, Moritz Scheuren  wrote:
> is there a possibility to set the tree view 
> (notmuch-tree-from-search-current-query)
> as default view in emacs? I couldn't find anything through google.

Use 'z' instead of 's' to get results in tree view. You can also
customize saved searches to display tree view by default.

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

Announcing Astroid v0.10

2017-09-21 Thread Gaute Hope 

Greetings,

Astroid v0.10 has been released!

 Astroid is a lightweight and fast graphical threads-with-tags email
 client for notmuch. Written in C++ using GTK+, WebKit and gmime.

Astroid can be acquired, along with usage and instructions for use, at:

   https://github.com/astroidmail/astroid

 once you get Astroid running press '?' to get a list of keybindings
 for the current context. For 'The Tour' check out:

   https://github.com/astroidmail/astroid/wiki


P.S.: Make sure you use the same GMime for notmuch and astroid!

## Some of the changes since v0.9.1

 * Support GMime 3 with backwards compatability with GMime 2. This orients us
   towards GMime 3, and support for GMime 2 will be dropped in the future.

 * Attach messages by mids with 'A' in new emails.

 * Colorful tags in tag editor and in searching

 * Tags in the tag editor is now separated by spaces (comma still works)

 * New configuration option 'signature_separate' determines if inline
   signatures will be separated from the message by a line containing '-- '.

 * Configurable query associated with account can be used to select account as
   From: when replying or forwarding e-mail.

 * Default clipboard target: CLIPBOARD since this is the only one 
   accessible by keyboard in GTK.


 * Select target for yank operations with '"'

 * Track focus changes manually

Regards, Gaute



pgp5DV2PjuYgF.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Default Tree View

2017-09-21 Thread Moritz Scheuren 
Hey

is there a possibility to set the tree view 
(notmuch-tree-from-search-current-query)
as default view in emacs? I couldn't find anything through google.

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