Re: notmuch.el question: reading all messages in thread

[Kyle Meyer]

Matt Armstrong writes:

[...]
> I looked for a way to easily re-query a tree view buffer such that all
> messages in all threads shown are "open" but did not find it.  Does this
> exist?

I've wanted something like this too and will be happy if someone points
out an existing way to do it.  I'm not aware of one.

> I suppose I'm looking for the opposite of `notmuch-tree-filter'.  Maybe
> `notmuch-tree-widen-to-thread' that produces a new notmuch tree widened
> to the entire thread of the current message.

In show buffers, I remap notmuch-tree-from-show-current-query to a
custom function.  Like the original variant, it displays the tree for a
message's thread, but giving a prefix argument says to display all the
messages as "open".

I don't think that's exactly what you're asking for, but it still might
be useful (at least for adapting to something that behaves as you want).

--8<---cut here---start->8---
(defun km/notmuch-thread-id-from-message-id (message-id)
  (let ((threads (with-temp-buffer
   (call-process "notmuch" nil t nil
 "search" "--format=sexp" "--output=threads"
 message-id)
   (goto-char (point-min))
   (read (current-buffer)
(cl-case (length threads)
  (0
   (user-error "No thread found for %S" message-id))
  (1
   (concat "thread:" (car threads)))
  (t
   (error "Got multiple threads for %S" message-id)

;;;###autoload
(defun km/notmuch-tree-from-show-current-query ( ignore-context)
  (interactive "P")
  (let* ((mid (or (notmuch-show-get-message-id)
  (error "No message ID found")))
 (tid (if (and notmuch-show-thread-id
   ;; notmuch's variant works with
   ;; notmuch-show-thread-id ...
   (string-prefix-p "thread:" notmuch-show-thread-id))
  notmuch-show-thread-id
;; ... but there are cases where this is set to the
;; message ID, leading to the tree result that is
;; always narrowed to the message.  Try harder to get
;; the actual thread ID.
(km/notmuch-thread-id-from-message-id mid)))
 (notmuch-show-query-context (and (not ignore-context)
  notmuch-show-query-context)))
(notmuch-tree tid notmuch-show-query-context mid)))
--8<---cut here---end--->8---
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: Thanks for notmuch-lore

[Kyle Meyer]

Carl Worth writes:

> On Tue, Feb 01 2022, Tobias Waldekranz wrote:
>> I actually gave up on getting my mailinglists from my email provider,
>> now I just download it directly from lore. I hacked together a script
>> that will scrape a public-inbox repo and convert it to a Maildir:
>>
>> https://github.com/wkz/notmuch-lore
>
> Thanks for sharing this, Tobias. I needed exactly this today, and was
> happy to have found this.
>
> It looks like you've coded something to efficiently do the work that's
> needed periodically, (fetch new emails from the public-inbox git
> repository, convert them to maildir files, and prune away git state
> other than a pointer to what's been converted already).
>
> What I'm missing is the piece to convert over the entire archive from
> the past.

I may be missing something (I didn't know about notmuch-lore before
seeing it mentioned here), but it looks like the initialization step of
notmuch-lore's pre-new handles that already.  You just need to set
`since` far enough back:

--8<---cut here---start->8---
tmphome=$(mktemp -d "${TMPDIR:-/tmp}"/nm-lore-XXX)
cd "$tmphome"

HOME="$tmphome"
export HOME

mkdir mail
notmuch setup
notmuch new

mkdir -p mail/.notmuch/.lore  mail/.notmuch/hooks

cat >mail/.notmuch/.lore/sources <<'EOF'
[gwl]
url=https://yhetil.org/gwl/git
since=50 years ago
EOF

curl -fSsL \
 
https://raw.githubusercontent.com/wkz/notmuch-lore/3e2a13b32b178a4d3296cee6f69ee3491eebdb9f/pre-new
 \
 >mail/.notmuch/hooks/pre-new
chmod +x mail/.notmuch/hooks/pre-new
./mail/.notmuch/hooks/pre-new
--8<---cut here---end--->8---

That returns the number of messages I expect for that (small) archive:

  $ find mail/gwl -type f | wc -l
  288

Also, just to list some other options in this space, l2md and impibe are
mentioned at  as tools for
converting public-inbox archives into maildir format.  (I haven't used
either myself.)

Tobias, just a note of something I saw when looking over the script:

$git rev-list $3 | while read sha; do
  $git show $sha:m >$db/$1/new/$sha
done

This would error if it encounters a deleted message in the archive
because then the commit will have a "d" in the working tree instead of
an "m".  See .
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH v2] nmbug: write tags out to a temporary file, not 'nmbug.index'

[Kyle Meyer]

[ drive-by comment based on a past mistake :/ ]

Sean Whitton writes:

> -def _index_tags():
> -"Write notmuch tags to the nmbug.index."
> -path = _os.path.join(NMBGIT, 'nmbug.index')
> +(_, index) = _tempfile.mkstemp()
[...]
>  _git(
>  args=['read-tree', '--empty'],
> -additional_env={'GIT_INDEX_FILE': path}, wait=True)
> +additional_env={'GIT_INDEX_FILE': index}, wait=True)

It's better to put the temporary index in $GIT_DIR due to this bit noted
in git-read-tree(1):

  The file must allow to be rename(2)ed into from a temporary file
  that is created next to the usual index file; typically this means
  it needs to be on the same filesystem as the index file itself, and
  you need write permission to the directories the index file and
  index output file are located in.

So, assuming NMBGIT matches $GIT_DIR, perhaps change the above mkstemp
call to something like

  _tempfile.mkstemp(dir=NMBGIT, prefix="nmbug", suffix=".index")
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH v4] emacs: customizable names for search buffers

[Kyle Meyer]

Jose A Ortega Ruiz writes:

> In very recent emacs (i'm using its master branch, actually), if one M-x
> describe-function RET format-spec one sees in the help buffer:
>
>  Probably introduced at or before Emacs version 27.1.
>
> that's where my misconception came from.  

I see.  If I recall correctly, that help string is generated by
searching NEWS* files for the name of interest.  While that often works
okay, in this case format-spec is first mentioned in the NEWS for 27.1:

  $ git describe
  emacs-28.0.91-28-ge4886018496
  $ git grep -c format-spec -- 'etc/NEWS*'
  etc/NEWS:5
  etc/NEWS.27:1

> I guess that's potentially good news: i don't see an emacs version
> specified in notmuch's package: is it supposed to be compatible with
> emacs < 25.3?  If not, we can just forget about the regexp branch.

Here's the last statement about the minimum Emacs version I see in
Notmuch's NEWS (for v0.31):

  The minimum supported major version of GNU Emacs is now 25.1.

The example in my last message used 25.3 because that's the closest
version to 25.1 for which I had a local working tree checked out and
built.  But, as I mentioned, format-spec has been present since Emacs
21.1.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: [PATCH v4] emacs: customizable names for search buffers

[Kyle Meyer]

Jose A Ortega Ruiz writes:

> yeah, that's what i use and didn't notice my error above.  format-spec
> is much nicer than a plain regexp subs, one can use format specifiers
> like %3t and many others, but unfortunately seems to have been
> introduced in emacs 27.

format-spec has been present in Emacs since version 21.1, specifically
c113de23613 (2000-09-19).  (Some parameters have been added since then,
but you only use FORMAT and SPECIFICATION in your patch.)

Here's a test with Emacs 25, Notmuch's current minimum (if I grep
correctly):

  (emacs-version) ; => "GNU Emacs 25.3.50.1 ..."
  (require 'format-spec)
  (format-spec "%b" '((?b . "fine"))) ; => "fine"

At first I thought you were getting confused by the fact that
format-spec has been marked as autoloaded only recently, but it looks
like that was in 0185d76e742 (Fix and extend format-spec (bug#41758),
2020-06-18), which will be part of the 28.1 release.  So that's not
consistent with "introduced in emacs 27".
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

[PATCH] emacs/tree: fix docstrings for author faces

[Kyle Meyer]

The docstrings for notmuch-tree-match-author-face and
notmuch-tree-no-match-author-face incorrectly match the docstring of
notmuch-tree-match-date-face.
---
 emacs/notmuch-tree.el | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
index 7fa73d40..d7486904 100644
--- a/emacs/notmuch-tree.el
+++ b/emacs/notmuch-tree.el
@@ -179,7 +179,7 @@ (defface notmuch-tree-match-author-face
  (:foreground "dark blue"))
 (t
  (:bold t)))
-  "Face used in tree mode for the date in messages matching the query."
+  "Face used in tree mode for the author in messages matching the query."
   :group 'notmuch-tree
   :group 'notmuch-faces)
 
@@ -236,7 +236,7 @@ (defface notmuch-tree-no-match-tree-face
 
 (defface notmuch-tree-no-match-author-face
   nil
-  "Face used in tree mode for the date in messages matching the query."
+  "Face used in tree mode for non-matching authors."
   :group 'notmuch-tree
   :group 'notmuch-faces)
 

base-commit: f17d75b83c90ae4ea75f79377f3acb873b9e564e
-- 
2.34.0

___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: notmuch-emacs notmuch-tag configuration

[Kyle Meyer]

David Bremner writes:

> David Wen Riccardi-Zhu  writes:
>
>> I'm using notmuch 0.32.1, Emacs 27.2, and version 20210605.1839 of
>> notmuch-emacs. When I try to mark a message as read using a custom
>> keybinding, I'm getting the following error:
>
> Can you duplicate your problem with matching versions of notmuch and
> notmuch-emacs, i.e. either both 0.32.1 or both from git master? It's
> probably not the issue, but I don't really want to deal with melpa's
> creative version numbers.

While the offending code in the backtrace is from 319dcfb5 (emacs:
restore tag-changes and query bindings for tag hooks, 2021-05-15), to me
it smells like some sort of mixed installation (perhaps stale elc
files), so I think the above suggestion is a good one.  Also, looking at
the output of list-load-path-shadows might point to the problem.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: (wrong-type-argument keymapp notmuch-show-mode-map) in emacs on upgrade to notmuch from master

[Kyle Meyer]

Daniel Kahn Gillmor writes:

> I worry that this is due to one of the two following commits but my
> elisp-foo is weak enough that i don't know what the right next steps are:

It's due to the second commit, 05a436f7 (emacs: don't fset keymaps,
2020-11-11).  You could avoid the error by dropping the quote from the
keymap variable, changing

  (define-key 'notmuch-show-mode-map "j" 'dkg-notmuch-show-handle-junk)

to

  (define-key notmuch-show-mode-map "j" 'dkg-notmuch-show-handle-junk)
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

[PATCH] emacs: restore tag-changes and query bindings for tag hooks

[Kyle Meyer]

Matt Lundin writes:

> With the upgrade to notmuch 0.32, functions added to
> 'notmuch-after-tag-hook' or 'notmuch-before-tag-hook' no longer have
> access to the 'tag-changes' or 'query' variables advertised in the
> docstrings of both hooks. If I try to access either variable in a hook
> function, emacs throws an error. I believe this results from the
> addition of lexical binding in commit fc4cda07a9af.

The approach in the patch below is similar to some changes I've seen
Stefan Monnier do for lexical binding conversions.

-- >8 --
Subject: [PATCH] emacs: restore tag-changes and query bindings for tag hooks

notmuch-before-tag-hook and notmuch-after-tag-hook are supposed to
have access to two dynamic variables, tag-changes and query, but these
were lost with the switch to lexical binding in fc4cda07 (emacs: use
lexical-bindings in all libraries, 2021-01-13).

Add a variant of Emacs's dlet (not available until Emacs 28) and use
it in notmuch-tag to expose tag-changes and query to the hooks.
---
 emacs/notmuch-compat.el | 12 
 emacs/notmuch-tag.el|  8 ++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/emacs/notmuch-compat.el b/emacs/notmuch-compat.el
index ad134dfe..179bf59c 100644
--- a/emacs/notmuch-compat.el
+++ b/emacs/notmuch-compat.el
@@ -41,6 +41,18 @@ (defun notmuch-message--fold-long-headers ()
 (unless (fboundp 'message--fold-long-headers)
   (add-hook 'message-header-hook 'notmuch-message--fold-long-headers))
 
+;; `dlet' isn't available until Emacs 28.1.  Below is a copy, with the
+;; addition of `with-no-warnings'.
+(defmacro notmuch-dlet (binders  body)
+  "Like `let*' but using dynamic scoping."
+  (declare (indent 1) (debug let))
+  `(let (_)
+ (with-no-warnings  ; Quiet "lacks a prefix" warning.
+   ,@(mapcar (lambda (binder)
+  `(defvar ,(if (consp binder) (car binder) binder)))
+binders))
+ (let* ,binders ,@body)))
+
 (provide 'notmuch-compat)
 
 ;;; notmuch-compat.el ends here
diff --git a/emacs/notmuch-tag.el b/emacs/notmuch-tag.el
index f348d4ae..ebccb5a0 100644
--- a/emacs/notmuch-tag.el
+++ b/emacs/notmuch-tag.el
@@ -486,7 +486,9 @@ (defun notmuch-tag (query tag-changes)
   (unless query
 (error "Nothing to tag!"))
   (when tag-changes
-(run-hooks 'notmuch-before-tag-hook)
+(notmuch-dlet ((tag-changes tag-changes)
+  (query query))
+  (run-hooks 'notmuch-before-tag-hook))
 (if (<= (length query) notmuch-tag-argument-limit)
(apply 'notmuch-call-notmuch-process "tag"
   (append tag-changes (list "--" query)))
@@ -494,7 +496,9 @@ (defun notmuch-tag (query tag-changes)
   (let ((batch-op (concat (mapconcat #'notmuch-hex-encode tag-changes " ")
  " -- " query)))
(notmuch-call-notmuch-process :stdin-string batch-op "tag" "--batch")))
-(run-hooks 'notmuch-after-tag-hook)))
+(notmuch-dlet ((tag-changes tag-changes)
+  (query query))
+  (run-hooks 'notmuch-after-tag-hook
 
 (defun notmuch-tag-change-list (tags  reverse)
   "Convert TAGS into a list of tag changes.

base-commit: 63413a5563450bdedee4c077f2f998578e75083a
-- 
2.31.1
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org

Re: easy (?) elisp project for notmuch [it's mostly DONE]

[Kyle Meyer]

Jonas Bernoulli  writes:

> Nice to run into you.

You too :)

> Do you contribute to *all* the killer apps? ;D

Heh.  I think notmuch is great, but I haven't made any real
contributions.  Just a happy user and a lurker on the mailing list.

> Kyle Meyer  writes:

>> From there, you can easily download an mbox for a message or thread
>> from before you subscribed (e.g. to feed to 'notmuch insert').
>
> Do you already have some tooling that you could share?

Only very minimal.  I have a script that takes a public-inbox thread
mbox link, such as

  https://public-inbox.org/meta/20200406095621.5656-...@yhbt.net/t.mbox.gz

It uses mbox2maildir from Sean's mailscripts to convert the mbox to a
maildir and then calls 'notmuch insert' with each message.  There might
be a better approach, but it's been working fine for me.  My main use
case is that I follow some lists hosted on public-inbox.org and
lore.kernel.org via nntp; if I want to reply to something, I import a
thread into notmuch.

Note that it hard codes my folder.

--8<---cut here---start->8---
#!/bin/sh

if test  $# -ne 1
then
echo "$0 "
exit 1
fi

cd "$(mktemp -d ${TMPDIR:-/tmp}/notmuch-import-XXX)"
curl -fsS $1 | gunzip -c >t.mbox
mbox2maildir t.mbox mdir
for f in $(find mdir -type f)
do
notmuch insert --no-hooks --folder=kyleam/INBOX <$f
done
--8<---cut here---end--->8---

As a side note about tooling: David mentioned Sean's mailscripts in the
context of debbugs.  I haven't used that specific functionality yet, but
it has other scripts that are really nice for working with patch series.
mailscripts even gained some functionality for extracting a patch series
from an mbox that was inspired [^1] by Konstantin Ryabitsev's
get-lore-mbox.py [^2] tool for grabbing patch series from threads on
lore.kernel.org, which uses public-inbox.

All very exciting :)

[^1]: https://lore.kernel.org/workflows/87lfp38p7s@iris.silentflame.com/
[^2]: I think this tool was renamed recently, but I can't find that
  information at the moment.

> Kyle, have you considered mirroring emacs-devel and the Emacs debbugs
> as well?

I have... I dunno :/  The two higher-volume projects that I'm
considering creating public-inbox archives for are Emacs (devel and
debbugs) and Guix (patches, bugs, devel, user, ... they sure do like to
split up discussion ...).  It takes some work up front to create the
initial archives, but my main hesitation is due to uncertainty about how
my current VPS set up would fare.  So, I'm letting things settle a bit.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: easy (?) elisp project for notmuch [it's mostly DONE]

[Kyle Meyer]

Jonas Bernoulli  writes:

> (I cannot actually reply to "easy (?) elisp project for notmuch"
> because I wasn't subscribed yet when that was send.)

[ in case it's useful in the future ]

I've recently set up a public-inbox archive of notmuch here:

https://yhetil.org/notmuch/

>From there, you can easily download an mbox for a message or thread from
before you subscribed (e.g. to feed to 'notmuch insert').  As an
example, here's the one for your message:

https://yhetil.org/notmuch/875ze211gi@bernoul.li/raw

It might be possible to download a single message or thread from the
archive at , though looking
quickly it seems like downloads may only be available for messages over
a year time span.  (Also, FWIW the entire history is available at
.)
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Washing GitHub emails to include inline patch?

[Kyle Meyer]

William Casarin  writes:

> This worked pretty well, I've modified it a bit to support a generic
> github repo location which is parsed from the subject,

Great, glad you were able to tweak that test function into something
that works well with your setup.

> and origin/master instead of master:

Yep, that's better.

>  (defun km/notmuch-visit-pr-in-magit ( dont-fetch)
> @@ -39,4 +41,4 @@
>  ;; passing a more explicit refspec to the fetch call.
>  (unless dont-fetch
>(magit-call-git "fetch" "origin"))

Looking at what I wrote again, I'd change DONT-FETCH to FORCE-FETCH and
then do something like

(when (or force-fetch
  (not (magit-ref-exists-p local-ref)))
  (magit-call-git "fetch" "origin"))

where local-ref is bound to "refs/pull/origin/".  That way, "git
fetch" is only called if the ref doesn't already exist locally or when a
prefix argument is given, which would be useful for forced updates.

> -(magit-log (list (concat "master..refs/pull/origin/" pr)
> +(magit-log (list (concat "origin/master..refs/pull/origin/" pr)

Anyway, it's nice to see that you've been able to modify this into
something that might be useful to you.

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

Re: Washing GitHub emails to include inline patch?

[Kyle Meyer]

William Casarin  writes:

> I now mainly review GitHub PRs via the patch fetching snippet you sent,
> but there's a tedious disconnect between notmuch and magit. In the above
> scenario, I would have to:
>
>   1. cd to the project
>   2. open magit
>   2. fetch
>   3. checkout the branch
>   4. start reviewing
>
> If I want to start a review on GitHub:
>
>   5. go back to the mail buffer
>   6. open the GitHub link
>   7. try to find lines where I had a comment
>   8. make comment, start review
>
> Steps 1-4 are way too long for the number of code reviews I do at work
> and on public projects.

Fair enough.  5-8 are my pain points.

> Perhaps I could write a script that quickly jump from steps 1 to 4. I
> think this would still be too slow compared to simply fetching the patch
> and having a nicer view, at least until we have full magit code reviews.
> I guess I could just wait until that's finished.

I think you could get 1-4 nearly as quick as calling the patch fetching
command.  How about something like this?

--8<---cut here---start->8---

(defun km/notmuch-github-pr-number ()
  "Return the PR number for this message."
  (let (pr)
(with-current-notmuch-show-message
 (goto-char (point-min))
 (if (re-search-forward "https://github\\.com/.*/pull/\\([0-9]+\\)" nil t)
 (setq pr (match-string-no-properties 1))
   (user-error "Could not find PR number")))
pr))

;; This function could be anything that figures out the project based
;; on the current notmuch message.  Or, if you use projectile and
;; don't mind getting queried each time, it could just read a project
;; from `projectile-relevant-known-projects'.
(defun km/notmuch-repo-from-message ()
  "Return the repository that this message is associated with."
  (let ((fname (notmuch-show-get-filename)))
(or (and fname
 (string-match-p "magit-list" fname)
 "~/src/emacs/magit")
(user-error "Could not determine repo"

(defun km/notmuch-visit-pr-in-magit ( dont-fetch)
  "Show the Magit log for this message's PR.
If DONT-FETCH is non-nil, do not fetch first."
  (interactive "P")
  (let* ((pr (km/notmuch-github-pr-number))
 (repo (km/notmuch-repo-from-message))
 (default-directory repo))
;; "origin" is hard-coded below, but it could of course be
;; anything.  You could also have an alist that maps repo ->
;; remote.
;;
;; This assumes that you've added
;;
;;fetch = +refs/pull/*/head:refs/pull/origin/*
;;
;; to origin's in ".git/config".  You could drop that assumption
;; passing a more explicit refspec to the fetch call.
(unless dont-fetch
  (magit-call-git "fetch" "origin"))
(magit-log (list (concat "master..refs/pull/origin/" pr)
--8<---cut here---end--->8---

Call M-x km/notmuch-visit-pr-in-magit in a notmuch-show buffer for a
GitHub PR, modifying km/notmuch-repo-from-message so that it returns the
full path to the local repository.

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

Re: Washing GitHub emails to include inline patch?

[Kyle Meyer]

William Casarin  writes:

> I was wondering if you had any insight into what I'm thinking next. I
> would love to view these patches via the way magit handles hunks. I
> wonder if there was a way to get magit-style hunk browsing when viewing
> a patch file with a series of commits.
>
> Things like:
>
>   * Jump to the next/previous hunk/commit in a patch series

Diff mode has navigation commands to go to the next hunk/file, but not
the next commit.

>   * Collapse hunks/commits with tab

Hmm, yeah, I don't think Diff mode has commands for collapsing sections.
And I haven't checked, but I'd guess that Diff mode isn't really
recognizing the structure of the patch series; it's probably just
considering the next commit's header/message as context lines.

Magit doesn't have a mode for displaying a patch series.  Creating such
a mode shouldn't be too painful, at least if the command maps the patch
series to a local repository.

However, I personally haven't felt the need for such a command.  I
pretty frequently use the command I posted earlier in this thread to
take a quick look at PRs, but, for anything aside from the simplest
changes, I want to apply the commits locally to review/test.  If I
regularly review PRs for a GitHub repo, I have

fetch = +refs/pull/*/head:refs/pull/origin/*

in the GitHub remote's configuration section of ".git/config".  (GitLab
has an analogous merge request namespace.)  Then, after fetching from
the GitHub remote, I can view the PR in Magit like I would any other
ref.

> You get this for free with mailed patches + notmuch, but dealing with
> large patch series from GitHub is a bit annoying as it's one big buffer
> with no way to jump between commits.

I share your preference for mailed patches, but using the process above,
I don't find *viewing* GitHub PRs annoying.  I do find *reviewing*
GitHub PRs annoying and tedious compared to reviewing patches on a
mailing list.  At the moment, I typically do the review/commenting
locally and at the end open a browser and add my inline comments.

Jonas recently got a Kickstarter funded [1], and one of his goals is to
support code review from within Magit [2].  Not sure how that will turn
out, but it seems more promising than my current strategy of hoping
everyone will start sharing my preference for mail-based collaboration :)


[1] 
https://www.kickstarter.com/projects/1681258897/its-magit-the-magical-git-client
[2] https://github.com/magit/magit/issues/2972

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

Re: Washing GitHub emails to include inline patch?

[Kyle Meyer]

Tomi Ollila <tomi.oll...@iki.fi> writes:

> On Thu, Sep 21 2017, Kyle Meyer wrote:
>
>>
>> --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)
>
> Just a read-through thought -- would "https://github[.]com/.*[.]patch; work
> above ?

oops, good catch.  I didn't mean to match any single character with the
first period.

Either your suggestion or "https://github\\.com/.*\\.patch; should work.

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

Re: Washing GitHub emails to include inline patch?

[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

[PATCH] emacs: tree: drop repeated "of" from docstring

[Kyle Meyer]

---
 emacs/notmuch-tree.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
index 6812d7e9..55212626 100644
--- a/emacs/notmuch-tree.el
+++ b/emacs/notmuch-tree.el
@@ -832,7 +832,7 @@ (defun notmuch-tree-insert-forest (forest)
   (mapc 'notmuch-tree-insert-forest-thread forest))
 
 (define-derived-mode notmuch-tree-mode fundamental-mode "notmuch-tree"
-  "Major mode displaying messages (as opposed to threads) of of a notmuch 
search.
+  "Major mode displaying messages (as opposed to threads) of a notmuch search.
 
 This buffer contains the results of a \"notmuch tree\" of your
 email archives. Each line in the buffer represents a single
-- 
2.13.2

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