[PATCH] emacs: Cycle through notmuch buffers rather than jumping to the last.

[PATCH] emacs: Cycle through notmuch buffers rather than jumping to the last.

[David Edmondson]

As suggested by j4ni in #notmuch, rename
`notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and
have it behave accordingly.
---
 emacs/notmuch.el |   39 +++++++++++++++++++++++++++------------
 1 files changed, 27 insertions(+), 12 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index c678c93..4844385 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -1056,20 +1056,35 @@ current search results AND that are tagged with the given tag."
   (notmuch-hello))
 
 ;;;###autoload
-(defun notmuch-jump-to-recent-buffer ()
-  "Jump to the most recent notmuch buffer (search, show or hello).
+(defun notmuch-cycle-notmuch-buffers ()
+  "Cycle through any existing notmuch buffers (search, show or hello).
 
-If no recent buffer is found, run `notmuch'."
+If the current buffer is the only notmuch buffer, bury it. If no
+notmuch buffers exist, run `notmuch'."
   (interactive)
-  (let ((last
-	 (loop for buffer in (buffer-list)
-	       if (with-current-buffer buffer
-		    (memq major-mode '(notmuch-show-mode
-				       notmuch-search-mode
-				       notmuch-hello-mode)))
-	       return buffer)))
-    (if last
-	(switch-to-buffer last)
+
+  (let (start first)
+    ;; If the current buffer is a notmuch buffer, remember it and then
+    ;; bury it.
+    (when (memq major-mode '(notmuch-show-mode
+			     notmuch-search-mode
+			     notmuch-hello-mode))
+      (setq start (current-buffer))
+      (bury-buffer))
+
+    ;; Find the first notmuch buffer.
+    (setq first (loop for buffer in (buffer-list)
+		     if (with-current-buffer buffer
+			  (memq major-mode '(notmuch-show-mode
+					     notmuch-search-mode
+					     notmuch-hello-mode)))
+		     return buffer))
+
+    (if first
+	;; If the first one we found is any other than the starting
+	;; buffer, switch to it.
+	(unless (eq first start)
+	  (switch-to-buffer first))
       (notmuch))))
 
 (setq mail-user-agent 'notmuch-user-agent)
-- 
1.7.7.3

Re: [PATCH] emacs: Cycle through notmuch buffers rather than jumping to the last.

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]

On Tue, 27 Dec 2011 10:50:44 +0000, David Edmondson <dme@dme.org> wrote:
> As suggested by j4ni in #notmuch, rename
> `notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and
> have it behave accordingly.

This is the reason that I haven't mentioned
`notmuch-jump-to-recent-buffer' in the NEWS file - it should go away
soon after 0.11 ships.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] emacs: Cycle through notmuch buffers rather than jumping to the last.

[Jani Nikula]

On Tue, 27 Dec 2011 10:50:44 +0000, David Edmondson <dme@dme.org> wrote:
> As suggested by j4ni in #notmuch, rename
> `notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and
> have it behave accordingly.

Hi David, thanks for submitting this. It works nicely, and IMHO it's
*much* more useful than notmuch-jump-to-recent-buffer.

I'm wondering whether message-mode should be included. I tried it, and
it's useful in my interrupted-more-often-than-I'd-like-to workflow...

BR,
Jani.



> ---
>  emacs/notmuch.el |   39 +++++++++++++++++++++++++++------------
>  1 files changed, 27 insertions(+), 12 deletions(-)
> 
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index c678c93..4844385 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -1056,20 +1056,35 @@ current search results AND that are tagged with the given tag."
>    (notmuch-hello))
>  
>  ;;;###autoload
> -(defun notmuch-jump-to-recent-buffer ()
> -  "Jump to the most recent notmuch buffer (search, show or hello).
> +(defun notmuch-cycle-notmuch-buffers ()
> +  "Cycle through any existing notmuch buffers (search, show or hello).
>  
> -If no recent buffer is found, run `notmuch'."
> +If the current buffer is the only notmuch buffer, bury it. If no
> +notmuch buffers exist, run `notmuch'."
>    (interactive)
> -  (let ((last
> -	 (loop for buffer in (buffer-list)
> -	       if (with-current-buffer buffer
> -		    (memq major-mode '(notmuch-show-mode
> -				       notmuch-search-mode
> -				       notmuch-hello-mode)))
> -	       return buffer)))
> -    (if last
> -	(switch-to-buffer last)
> +
> +  (let (start first)
> +    ;; If the current buffer is a notmuch buffer, remember it and then
> +    ;; bury it.
> +    (when (memq major-mode '(notmuch-show-mode
> +			     notmuch-search-mode
> +			     notmuch-hello-mode))
> +      (setq start (current-buffer))
> +      (bury-buffer))
> +
> +    ;; Find the first notmuch buffer.
> +    (setq first (loop for buffer in (buffer-list)
> +		     if (with-current-buffer buffer
> +			  (memq major-mode '(notmuch-show-mode
> +					     notmuch-search-mode
> +					     notmuch-hello-mode)))
> +		     return buffer))
> +
> +    (if first
> +	;; If the first one we found is any other than the starting
> +	;; buffer, switch to it.
> +	(unless (eq first start)
> +	  (switch-to-buffer first))
>        (notmuch))))
>  
>  (setq mail-user-agent 'notmuch-user-agent)
> -- 
> 1.7.7.3
> 
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] emacs: Cycle through notmuch buffers rather than jumping to the last.

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 249 bytes --]

On Tue, 27 Dec 2011 21:23:25 +0200, Jani Nikula <jani@nikula.org> wrote:
> I'm wondering whether message-mode should be included. I tried it, and
> it's useful in my interrupted-more-often-than-I'd-like-to workflow...

Agreed. Updated patch coming.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

[PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.

[David Edmondson]

As suggested by j4ni in #notmuch, rename
`notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and
have it behave accordingly.

Consider `message-mode' buffers to be of interest.
---
 emacs/notmuch.el |   42 ++++++++++++++++++++++++++++++------------
 1 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index c678c93..6a44d49 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -1055,21 +1055,39 @@ current search results AND that are tagged with the given tag."
   (interactive)
   (notmuch-hello))
 
+(defun notmuch-interesting-buffer (b)
+  "Is the current buffer of interest to a notmuch user?"
+  (with-current-buffer b
+    (memq major-mode '(notmuch-show-mode
+		       notmuch-search-mode
+		       notmuch-hello-mode
+		       message-mode))))
+
 ;;;###autoload
-(defun notmuch-jump-to-recent-buffer ()
-  "Jump to the most recent notmuch buffer (search, show or hello).
+(defun notmuch-cycle-notmuch-buffers ()
+  "Cycle through any existing notmuch buffers (search, show or hello).
 
-If no recent buffer is found, run `notmuch'."
+If the current buffer is the only notmuch buffer, bury it. If no
+notmuch buffers exist, run `notmuch'."
   (interactive)
-  (let ((last
-	 (loop for buffer in (buffer-list)
-	       if (with-current-buffer buffer
-		    (memq major-mode '(notmuch-show-mode
-				       notmuch-search-mode
-				       notmuch-hello-mode)))
-	       return buffer)))
-    (if last
-	(switch-to-buffer last)
+
+  (let (start first)
+    ;; If the current buffer is a notmuch buffer, remember it and then
+    ;; bury it.
+    (when (notmuch-interesting-buffer (current-buffer))
+      (setq start (current-buffer))
+      (bury-buffer))
+
+    ;; Find the first notmuch buffer.
+    (setq first (loop for buffer in (buffer-list)
+		     if (notmuch-interesting-buffer buffer)
+		     return buffer))
+
+    (if first
+	;; If the first one we found is any other than the starting
+	;; buffer, switch to it.
+	(unless (eq first start)
+	  (switch-to-buffer first))
       (notmuch))))
 
 (setq mail-user-agent 'notmuch-user-agent)
-- 
1.7.7.3

Re: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 299 bytes --]

On Wed, 28 Dec 2011 08:29:58 +0000, David Edmondson <dme@dme.org> wrote:
> As suggested by j4ni in #notmuch, rename
> `notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and
> have it behave accordingly.
> 
> Consider `message-mode' buffers to be of interest.

Any reviewers?

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.

[Jani Nikula]

On Tue, 10 Jan 2012 16:55:07 +0000, David Edmondson <dme@dme.org> wrote:
> On Wed, 28 Dec 2011 08:29:58 +0000, David Edmondson <dme@dme.org> wrote:
> > As suggested by j4ni in #notmuch, rename
> > `notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and
> > have it behave accordingly.
> > 
> > Consider `message-mode' buffers to be of interest.
> 
> Any reviewers?

I don't feel qualified to review, but the patch works for me.

BR,
Jani.

Re: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.

[Pieter Praet]

On Tue, 10 Jan 2012 22:15:02 +0200, Jani Nikula <jani@nikula.org> wrote:
> I don't feel qualified to review,

Allow me to disagree: your feeling and reality appear to be disjoint ATM :)


Peace

-- 
Pieter

Re: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.

[Pieter Praet]

On Wed, 28 Dec 2011 08:29:58 +0000, David Edmondson <dme@dme.org> wrote:
> As suggested by j4ni in #notmuch, rename
> `notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and
> have it behave accordingly.
> 
> Consider `message-mode' buffers to be of interest.
> ---
>  emacs/notmuch.el |   42 ++++++++++++++++++++++++++++++------------
>  1 files changed, 30 insertions(+), 12 deletions(-)
> 
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index c678c93..6a44d49 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -1055,21 +1055,39 @@ current search results AND that are tagged with the given tag."
>    (interactive)
>    (notmuch-hello))
>  
> +(defun notmuch-interesting-buffer (b)
> +  "Is the current buffer of interest to a notmuch user?"
> +  (with-current-buffer b
> +    (memq major-mode '(notmuch-show-mode
> +		       notmuch-search-mode
> +		       notmuch-hello-mode
> +		       message-mode))))
> +
>  ;;;###autoload
> -(defun notmuch-jump-to-recent-buffer ()
> -  "Jump to the most recent notmuch buffer (search, show or hello).
> +(defun notmuch-cycle-notmuch-buffers ()
> +  "Cycle through any existing notmuch buffers (search, show or hello).
>  
> -If no recent buffer is found, run `notmuch'."
> +If the current buffer is the only notmuch buffer, bury it. If no
> +notmuch buffers exist, run `notmuch'."
>    (interactive)
> -  (let ((last
> -	 (loop for buffer in (buffer-list)
> -	       if (with-current-buffer buffer
> -		    (memq major-mode '(notmuch-show-mode
> -				       notmuch-search-mode
> -				       notmuch-hello-mode)))
> -	       return buffer)))
> -    (if last
> -	(switch-to-buffer last)
> +
> +  (let (start first)
> +    ;; If the current buffer is a notmuch buffer, remember it and then
> +    ;; bury it.
> +    (when (notmuch-interesting-buffer (current-buffer))
> +      (setq start (current-buffer))
> +      (bury-buffer))
> +
> +    ;; Find the first notmuch buffer.
> +    (setq first (loop for buffer in (buffer-list)
> +		     if (notmuch-interesting-buffer buffer)
> +		     return buffer))
> +
> +    (if first
> +	;; If the first one we found is any other than the starting
> +	;; buffer, switch to it.
> +	(unless (eq first start)
> +	  (switch-to-buffer first))
>        (notmuch))))
>  
>  (setq mail-user-agent 'notmuch-user-agent)
> -- 
> 1.7.7.3

Signed-off-by: Pieter Praet <pieter@praet.org>  !


Might I ask, to what key(chord) have you bound this ?  Due to its
usefulness, I'm inclined to bind it to [SPC], but on second though,
that might be a bit on the intense side...


Peace

-- 
Pieter

Re: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 355 bytes --]

On Sat, 14 Jan 2012 10:29:31 +0100, Pieter Praet <pieter@praet.org> wrote:
> Might I ask, to what key(chord) have you bound this ?  Due to its
> usefulness, I'm inclined to bind it to [SPC], but on second though,
> that might be a bit on the intense side...

C-c= globally. That's clobbered in a couple of major modes, but not
enough to bother me so far.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.

[Austin Clements]

Quoth David Edmondson on Jan 15 at 11:55 am:
> On Sat, 14 Jan 2012 10:29:31 +0100, Pieter Praet <pieter@praet.org> wrote:
> > Might I ask, to what key(chord) have you bound this ?  Due to its
> > usefulness, I'm inclined to bind it to [SPC], but on second though,
> > that might be a bit on the intense side...
> 
> C-c= globally. That's clobbered in a couple of major modes, but not
> enough to bother me so far.

Might it make sense to bind this across the notmuch mode maps by
default?  This would at least make this feature more visible as well
as quite useful to people who dedicate an Emacs instance to notmuch.

Re: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]

On Sun, 15 Jan 2012 22:01:05 -0500, Austin Clements <amdragon@MIT.EDU> wrote:
> Quoth David Edmondson on Jan 15 at 11:55 am:
> > On Sat, 14 Jan 2012 10:29:31 +0100, Pieter Praet <pieter@praet.org> wrote:
> > > Might I ask, to what key(chord) have you bound this ?  Due to its
> > > usefulness, I'm inclined to bind it to [SPC], but on second though,
> > > that might be a bit on the intense side...
> > 
> > C-c= globally. That's clobbered in a couple of major modes, but not
> > enough to bother me so far.
> 
> Might it make sense to bind this across the notmuch mode maps by
> default?  This would at least make this feature more visible as well
> as quite useful to people who dedicate an Emacs instance to notmuch.

The elisp manual says:

   * Don't define `C-c LETTER' as a key in Lisp programs.  Sequences
     consisting of `C-c' and a letter (either upper or lower case) are
     reserved for users; they are the *only* sequences reserved for
     users, so do not block them.

...

   * Sequences consisting of `C-c' followed by a control character or a
     digit are reserved for major modes.

   * Sequences consisting of `C-c' followed by `{', `}', `<', `>', `:'
     or `;' are also reserved for major modes.

   * Sequences consisting of `C-c' followed by any other punctuation
     character are allocated for minor modes.  Using them in a major
     mode is not absolutely prohibited, but if you do that, the major
     mode binding may be shadowed from time to time by minor modes.

which I read to mean that C-c= is allocated for use by minor modes. I
could easily be persuaded to change to C-c; and have that bound in our
major modes (and personally bind it globally).

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

[PATCH] [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

CLisp'ier version of `notmuch-cycle-notmuch-buffers', merged into `notmuch',
eliminating the need to hog yet another keybind.

FYI: causes 2 compile warnings due to requiring the cl package at runtime.
---
 emacs/notmuch.el |   34 ++++++++--------------------------
 1 files changed, 8 insertions(+), 26 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index ef4dcc7..60ab0b2 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -1067,7 +1067,14 @@ current search results AND that are tagged with the given tag."
 (defun notmuch ()
   "Run notmuch and display saved searches, known tags, etc."
   (interactive)
-  (notmuch-hello))
+  (let* ((old-buffer (current-buffer))
+	 (interesting-buffers (remove-if-not #'notmuch-interesting-buffer (buffer-list)))
+	 (next-buffer (first (member-if-not #'(lambda (b) (eq old-buffer b)) interesting-buffers))))
+    (if next-buffer
+    	(progn
+    	  (switch-to-buffer next-buffer)
+    	  (bury-buffer old-buffer))
+      (notmuch-hello))))
 
 (defun notmuch-interesting-buffer (b)
   "Is the current buffer of interest to a notmuch user?"
@@ -1078,31 +1085,6 @@ current search results AND that are tagged with the given tag."
 		       message-mode))))
 
 ;;;###autoload
-(defun notmuch-cycle-notmuch-buffers ()
-  "Cycle through any existing notmuch buffers (search, show or hello).
-
-If the current buffer is the only notmuch buffer, bury it. If no
-notmuch buffers exist, run `notmuch'."
-  (interactive)
-
-  (let (start first)
-    ;; If the current buffer is a notmuch buffer, remember it and then
-    ;; bury it.
-    (when (notmuch-interesting-buffer (current-buffer))
-      (setq start (current-buffer))
-      (bury-buffer))
-
-    ;; Find the first notmuch buffer.
-    (setq first (loop for buffer in (buffer-list)
-		     if (notmuch-interesting-buffer buffer)
-		     return buffer))
-
-    (if first
-	;; If the first one we found is any other than the starting
-	;; buffer, switch to it.
-	(unless (eq first start)
-	  (switch-to-buffer first))
-      (notmuch))))
 
 (setq mail-user-agent 'notmuch-user-agent)
 
-- 
1.7.8.1

Re: [PATCH] [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 633 bytes --]

On Mon, 16 Jan 2012 11:42:31 +0100, Pieter Praet <pieter@praet.org> wrote:
> CLisp'ier version of `notmuch-cycle-notmuch-buffers', merged into `notmuch',
> eliminating the need to hog yet another keybind.

The lisp-ier-ness changes are good.

I'm less sure about the functional change. Sometimes I want to go back
to where I was, other times I want to go to `notmuch-hello'. I suppose
that I can replace my binding for `notmuch' with one for
`notmuch-hello'.

Hmm, yes, that seems reasonable.

> FYI: causes 2 compile warnings due to requiring the cl package at runtime.

`cl' is still `eval-when-compile' though - won't that break?

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

On Mon, 16 Jan 2012 11:06:25 +0000, David Edmondson <dme@dme.org> wrote:
> On Mon, 16 Jan 2012 11:42:31 +0100, Pieter Praet <pieter@praet.org> wrote:
> > CLisp'ier version of `notmuch-cycle-notmuch-buffers', merged into `notmuch',
> > eliminating the need to hog yet another keybind.
> 
> The lisp-ier-ness changes are good.
> 
> I'm less sure about the functional change. Sometimes I want to go back
> to where I was, other times I want to go to `notmuch-hello'. [...]

Hmmm, true.  The path of least resistance is elusive.

> [...] I suppose
> that I can replace my binding for `notmuch' with one for
> `notmuch-hello'.
> 

Perhaps we could use `ido-completion-help', like Org-mode does with
`org-iswitchb' ?  OTOH, that would require an extra [RET].  Bah...

> Hmm, yes, that seems reasonable.
> 
> > FYI: causes 2 compile warnings due to requiring the cl package at runtime.
> 
> `cl' is still `eval-when-compile' though - won't that break?

Haven't noticed any issues here, apart from the complaints @ compilation.


Peace

-- 
Pieter

Re: [PATCH] [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

On Mon, 16 Jan 2012 12:28:06 +0100, Pieter Praet <pieter@praet.org> wrote:
> On Mon, 16 Jan 2012 11:06:25 +0000, David Edmondson <dme@dme.org> wrote:
> > On Mon, 16 Jan 2012 11:42:31 +0100, Pieter Praet <pieter@praet.org> wrote:
> > > CLisp'ier version of `notmuch-cycle-notmuch-buffers', merged into `notmuch',
> > > eliminating the need to hog yet another keybind.
> > 
> > The lisp-ier-ness changes are good.
> > 
> > I'm less sure about the functional change. Sometimes I want to go back
> > to where I was, other times I want to go to `notmuch-hello'. [...]
> 
> Hmmm, true.  The path of least resistance is elusive.
> 
> > [...] I suppose
> > that I can replace my binding for `notmuch' with one for
> > `notmuch-hello'.
> > 
> 
> Perhaps we could use `ido-completion-help', like Org-mode does with
> `org-iswitchb' ?  OTOH, that would require an extra [RET].  Bah...
> 

s/ido-completion-help/ido-completing-read

> > Hmm, yes, that seems reasonable.
> > 
> > > FYI: causes 2 compile warnings due to requiring the cl package at runtime.
> > 
> > `cl' is still `eval-when-compile' though - won't that break?
> 
> Haven't noticed any issues here, apart from the complaints @ compilation.
> 
> 
> Peace
> 
> -- 
> Pieter


Peace

-- 
Pieter

Re: [PATCH] [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

On Mon, 16 Jan 2012 12:28:06 +0100, Pieter Praet <pieter@praet.org> wrote:
> Perhaps we could use `ido-completion-help', like Org-mode does with
> `org-iswitchb' ?  OTOH, that would require an extra [RET].  Bah...

I'm a no-ido person.

> > Hmm, yes, that seems reasonable.
> > 
> > > FYI: causes 2 compile warnings due to requiring the cl package at runtime.
> > 
> > `cl' is still `eval-when-compile' though - won't that break?
> 
> Haven't noticed any issues here, apart from the complaints @ compilation.

If you load the compiled lisp into 'emacs -Q' and then attempt to call
the function, it doesn't complain? (I haven't tested.)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

On Mon, 16 Jan 2012 11:47:03 +0000, David Edmondson <dme@dme.org> wrote:
> On Mon, 16 Jan 2012 12:28:06 +0100, Pieter Praet <pieter@praet.org> wrote:
> > Perhaps we could use `ido-completion-help', like Org-mode does with
> > `org-iswitchb' ?  OTOH, that would require an extra [RET].  Bah...
> 
> I'm a no-ido person.
> 
> > > Hmm, yes, that seems reasonable.
> > > 
> > > > FYI: causes 2 compile warnings due to requiring the cl package at runtime.
> > > 
> > > `cl' is still `eval-when-compile' though - won't that break?
> > 
> > Haven't noticed any issues here, apart from the complaints @ compilation.
> 
> If you load the compiled lisp into 'emacs -Q' and then attempt to call
> the function, it doesn't complain? (I haven't tested.)

Good call !  No joy:
  Debugger entered--Lisp error: (void-function remove-if-not)

Should've known.

So let's just get rid of that cl requirement, shall we :)

Patch follows.


Peace

-- 
Pieter

[PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

Make `notmuch-cycle-notmuch-buffers' more Lispy and merge into `notmuch',
eliminating the need to hog yet another keybind.

---
 emacs/notmuch.el |   40 ++++++++++++++--------------------------
 1 files changed, 14 insertions(+), 26 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index ef4dcc7..539b3a0 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -1067,7 +1067,20 @@ current search results AND that are tagged with the given tag."
 (defun notmuch ()
   "Run notmuch and display saved searches, known tags, etc."
   (interactive)
-  (notmuch-hello))
+  (let* ((old-buffer (current-buffer))
+	 (interesting-buffers
+	  (delq nil (mapcar (lambda (b)
+			      (if (notmuch-interesting-buffer b) b))
+			    (buffer-list))))
+	 (next-buffer (first
+	  (delq nil (mapcar (lambda (b)
+			      (unless (eq old-buffer b) b))
+			    interesting-buffers)))))
+    (if next-buffer
+    	(progn
+    	  (switch-to-buffer next-buffer)
+    	  (bury-buffer old-buffer))
+      (notmuch-hello))))
 
 (defun notmuch-interesting-buffer (b)
   "Is the current buffer of interest to a notmuch user?"
@@ -1078,31 +1091,6 @@ current search results AND that are tagged with the given tag."
 		       message-mode))))
 
 ;;;###autoload
-(defun notmuch-cycle-notmuch-buffers ()
-  "Cycle through any existing notmuch buffers (search, show or hello).
-
-If the current buffer is the only notmuch buffer, bury it. If no
-notmuch buffers exist, run `notmuch'."
-  (interactive)
-
-  (let (start first)
-    ;; If the current buffer is a notmuch buffer, remember it and then
-    ;; bury it.
-    (when (notmuch-interesting-buffer (current-buffer))
-      (setq start (current-buffer))
-      (bury-buffer))
-
-    ;; Find the first notmuch buffer.
-    (setq first (loop for buffer in (buffer-list)
-		     if (notmuch-interesting-buffer buffer)
-		     return buffer))
-
-    (if first
-	;; If the first one we found is any other than the starting
-	;; buffer, switch to it.
-	(unless (eq first start)
-	  (switch-to-buffer first))
-      (notmuch))))
 
 (setq mail-user-agent 'notmuch-user-agent)
 
-- 
1.7.8.1

Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 1187 bytes --]

On Mon, 16 Jan 2012 17:46:55 +0100, Pieter Praet <pieter@praet.org> wrote:
> Make `notmuch-cycle-notmuch-buffers' more Lispy and merge into `notmuch',
> eliminating the need to hog yet another keybind.
...
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index ef4dcc7..539b3a0 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -1067,7 +1067,20 @@ current search results AND that are tagged with the given tag."
>  (defun notmuch ()
>    "Run notmuch and display saved searches, known tags, etc."
>    (interactive)
> -  (notmuch-hello))
> +  (let* ((old-buffer (current-buffer))
> +	 (interesting-buffers
> +	  (delq nil (mapcar (lambda (b)
> +			      (if (notmuch-interesting-buffer b) b))
> +			    (buffer-list))))
> +	 (next-buffer (first
> +	  (delq nil (mapcar (lambda (b)
> +			      (unless (eq old-buffer b) b))
> +			    interesting-buffers)))))

This feels _less_ lispy. Any occurrences of '(delq nil ...)' strike me
as odd. What's wrong with '(loop ... collect ...)'?

> +    (if next-buffer
> +    	(progn
> +    	  (switch-to-buffer next-buffer)
> +    	  (bury-buffer old-buffer))
> +      (notmuch-hello))))

Integrating with `notmuch' is fine with me.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

On Mon, 16 Jan 2012 17:03:44 +0000, David Edmondson <dme@dme.org> wrote:
> On Mon, 16 Jan 2012 17:46:55 +0100, Pieter Praet <pieter@praet.org> wrote:
> > Make `notmuch-cycle-notmuch-buffers' more Lispy and merge into `notmuch',
> > eliminating the need to hog yet another keybind.
> ...
> > diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> > index ef4dcc7..539b3a0 100644
> > --- a/emacs/notmuch.el
> > +++ b/emacs/notmuch.el
> > @@ -1067,7 +1067,20 @@ current search results AND that are tagged with the given tag."
> >  (defun notmuch ()
> >    "Run notmuch and display saved searches, known tags, etc."
> >    (interactive)
> > -  (notmuch-hello))
> > +  (let* ((old-buffer (current-buffer))
> > +	 (interesting-buffers
> > +	  (delq nil (mapcar (lambda (b)
> > +			      (if (notmuch-interesting-buffer b) b))
> > +			    (buffer-list))))
> > +	 (next-buffer (first
> > +	  (delq nil (mapcar (lambda (b)
> > +			      (unless (eq old-buffer b) b))
> > +			    interesting-buffers)))))
> 
> This feels _less_ lispy. [...]

True.  I simply re-implemented `delete-if-not' in order to
prevent having to require the `cl' package at runtime.
(why on Earth isn't there an equivalent function in plain Elisp ?!?)

  $ sed -e "s/C\?Lisp\(y\|'ier\)/Elispy/" $COMMIT_MSG


> [...] Any occurrences of '(delq nil ...)' strike me
> as odd. [...]

How so?  Lacking a flexible way to conditionally remove elements from a
list (that doesn't require the `cl' package in some way or another),
a combination of `mapcar' and `delq' seemed like the easiest approach.

(AFAIK;  Please correct me if (when) I'm wrong!)


> [...] What's wrong with '(loop ... collect ...)'?
> 

Nothing at all.  I was fixing my own patch [1] without resorting to
requiring the `cl' package at runtime :)  Would be nice if we could
get rid of the compile-time dependency as well, though.

Fresh patch to that effect follows.

Feel free to disregard it, just bikesheddin'...


> > +    (if next-buffer
> > +    	(progn
> > +    	  (switch-to-buffer next-buffer)
> > +    	  (bury-buffer old-buffer))
> > +      (notmuch-hello))))
> 
> Integrating with `notmuch' is fine with me.


Peace

-- 
Pieter

[1] id:"1326710551-23122-1-git-send-email-pieter@praet.org"

[RFC] [PATCH v3] emacs: rewrite `notmuch-cycle-notmuch-buffers'

[Pieter Praet]

Get rid of the compile-time `cl' requirement for this particular function.

---
 emacs/notmuch.el |   40 ++++++++++++++++++++++------------------
 1 files changed, 22 insertions(+), 18 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index ef4dcc7..2426c0a 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -1084,24 +1084,28 @@ current search results AND that are tagged with the given tag."
 If the current buffer is the only notmuch buffer, bury it. If no
 notmuch buffers exist, run `notmuch'."
   (interactive)
-
-  (let (start first)
-    ;; If the current buffer is a notmuch buffer, remember it and then
-    ;; bury it.
-    (when (notmuch-interesting-buffer (current-buffer))
-      (setq start (current-buffer))
-      (bury-buffer))
-
-    ;; Find the first notmuch buffer.
-    (setq first (loop for buffer in (buffer-list)
-		     if (notmuch-interesting-buffer buffer)
-		     return buffer))
-
-    (if first
-	;; If the first one we found is any other than the starting
-	;; buffer, switch to it.
-	(unless (eq first start)
-	  (switch-to-buffer first))
+  (let* ((old-buffer (current-buffer))
+	 (next-buffer (first
+	  ;; Find interesting buffers:
+	  ;; Loop over all existing buffers and return those that
+	  ;; satisfy the predicate (`notmuch-interesting-buffer' and
+	  ;; not `eq' to current buffer) integrally;  All others are
+	  ;; replaced with `nil'.  Then strip out all `nil's using
+	  ;; `delq'.  Basically a re-implementation of `cl' package's
+	  ;; `delete-if-not'.
+	  (delq nil
+	   (mapcar (lambda (b)
+		     (and (notmuch-interesting-buffer b)
+			  (not (eq old-buffer b))
+			  b))
+		   (buffer-list))))))
+
+    ;; If there's a next buffer, switch to it and bury the
+    ;; original current buffer.  Otherwise run `notmuch-hello'.
+    (if next-buffer
+    	(progn
+    	  (switch-to-buffer next-buffer)
+    	  (bury-buffer old-buffer))
       (notmuch))))
 
 (setq mail-user-agent 'notmuch-user-agent)
-- 
1.7.8.1

Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet <pieter@praet.org> wrote:
> > [...] What's wrong with '(loop ... collect ...)'?
> 
> Nothing at all.  I was fixing my own patch [1] without resorting to
> requiring the `cl' package at runtime :)  Would be nice if we could
> get rid of the compile-time dependency as well, though.

Can you explain why it's necessary at runtime?

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

On Wed, 18 Jan 2012 10:13:35 +0000, David Edmondson <dme@dme.org> wrote:
> On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet <pieter@praet.org> wrote:
> > > [...] What's wrong with '(loop ... collect ...)'?
> > 
> > Nothing at all.  I was fixing my own patch [1] without resorting to
> > requiring the `cl' package at runtime :)  Would be nice if we could
> > get rid of the compile-time dependency as well, though.
> 
> Can you explain why it's necessary at runtime?

Because otherwise `remove-if-not' and `member-if-not' would
be void, as you alluded to previously [1,2].


Peace

-- 
Pieter

[1] id:"cunvcob52ku.fsf@hotblack-desiato.hh.sledj.net"
[2] id:"cun1uqz50p4.fsf@hotblack-desiato.hh.sledj.net"

Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 726 bytes --]

On Wed, 18 Jan 2012 13:15:55 +0100, Pieter Praet <pieter@praet.org> wrote:
> On Wed, 18 Jan 2012 10:13:35 +0000, David Edmondson <dme@dme.org> wrote:
> > On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet <pieter@praet.org> wrote:
> > > > [...] What's wrong with '(loop ... collect ...)'?
> > > 
> > > Nothing at all.  I was fixing my own patch [1] without resorting to
> > > requiring the `cl' package at runtime :)  Would be nice if we could
> > > get rid of the compile-time dependency as well, though.
> > 
> > Can you explain why it's necessary at runtime?
> 
> Because otherwise `remove-if-not' and `member-if-not' would
> be void, as you alluded to previously [1,2].

Ah, not macros. Sorry for being slow.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

On Wed, 18 Jan 2012 13:03:06 +0000, David Edmondson <dme@dme.org> wrote:
> Hey, look - I deliberately pressed 'r' instead of 'R'!
> 

You have remarkably malleable muscle memory.

Care to donate some to the less fortunate ? :)

> On Wed, 18 Jan 2012 12:57:53 +0000, David Edmondson <dme@dme.org> wrote:
> > On Wed, 18 Jan 2012 13:15:55 +0100, Pieter Praet <pieter@praet.org> wrote:
> > > On Wed, 18 Jan 2012 10:13:35 +0000, David Edmondson <dme@dme.org> wrote:
> > > > On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet <pieter@praet.org> wrote:
> > > > > > [...] What's wrong with '(loop ... collect ...)'?
> > > > > 
> > > > > Nothing at all.  I was fixing my own patch [1] without resorting to
> > > > > requiring the `cl' package at runtime :)  Would be nice if we could
> > > > > get rid of the compile-time dependency as well, though.
> > > > 
> > > > Can you explain why it's necessary at runtime?
> > > 
> > > Because otherwise `remove-if-not' and `member-if-not' would
> > > be void, as you alluded to previously [1,2].
> > 
> > Ah, not macros. Sorry for being slow.
> 
> But, loop is a macro, so the loop collector variant (which I originally
> suggested) would be fine with just loading cl during compilation.

Absolutely.

My original intent of conserving a key(chord) [1] (which in
retrospect was a fairly pointless exercise in and of itself
[2,3]) seems to have inconspicuously morphed into an equally
questionable crusade [4] against the `cl' package.

As long there's other functions in Notmuch depending on
compile-time `cl', there's really no incentive whatsoever
to replace your perfectly fine solution.

So as said [5], feel free to disregard it, just bikesheddin'...


All of my patches in this thread belong in notmuch::obsolete.


Peace

-- 
Pieter

[1] id:"1326710551-23122-1-git-send-email-pieter@praet.org"
[2] id:"87wr8rc2ex.fsf@praet.org"
[3] id:"87ehuzl5fg.fsf@nikula.org"
[4] id:"87r4yza95m.fsf@praet.org"
[5] id:"87fwfd8h0i.fsf@praet.org"

Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Aaron Ecay]

On Wed, 18 Jan 2012 14:48:02 +0100, Pieter Praet <pieter@praet.org> wrote:
> My original intent of conserving a key(chord) [1] (which in
> retrospect was a fairly pointless exercise in and of itself
> [2,3]) seems to have inconspicuously morphed into an equally
> questionable crusade [4] against the `cl' package.
> 
> As long there's other functions in Notmuch depending on
> compile-time `cl', there's really no incentive whatsoever
> to replace your perfectly fine solution.

(This is not strictly related to the immediate issue of these patches,
but now seems as good a time as any to discuss it.)

Compile-time dependencies on ‘cl’ are absolutely not a problem.
Virtually every major elisp program depends on cl at compile time.
Runtime dependencies are not allowed in code distributed with emacs
because of RMS’s conservativism[1].

Since notmuch isn’t distributed with emacs and has no aspirations to
ever be, the project could decide to require cl at runtime.  Many
elisp programs do.  (A quick grep through my .emacs.d folder turns up
anything.el and clojure-mode as two large/“mainstream” projects that
do, as well as at least a dozen smaller utility files.)  So many emacs
users have cl loaded all the time when they are using emacs.  But
unless the project (i.e. us) decides explicitly “runtime cl is OK” (or
perhaps “it is not”), contributors will always go back and forth over
using it.  To avoid patch and review churn, we ought to decide which
of these we pick (and I vote for allowing runtime use.)

Aaron

Footnotes:
[1] He specifically objects to the way that the cl package uses keyword
    arguments, calling it un-Elisp-like.  He has resisted past efforts
    to merge cl functions into Elisp core, although they are slowly
    diffusing across the barrier.

-- 
Aaron Ecay

Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Austin Clements]

Quoth Aaron Ecay on Jan 18 at  5:18 pm:
> Compile-time dependencies on ‘cl’ are absolutely not a problem.
> Virtually every major elisp program depends on cl at compile time.
> Runtime dependencies are not allowed in code distributed with emacs
> because of RMS’s conservativism[1].
> 
> Since notmuch isn’t distributed with emacs and has no aspirations to
> ever be, the project could decide to require cl at runtime.  Many
> elisp programs do.  (A quick grep through my .emacs.d folder turns up
> anything.el and clojure-mode as two large/“mainstream” projects that
> do, as well as at least a dozen smaller utility files.)  So many emacs
> users have cl loaded all the time when they are using emacs.  But
> unless the project (i.e. us) decides explicitly “runtime cl is OK” (or
> perhaps “it is not”), contributors will always go back and forth over
> using it.  To avoid patch and review churn, we ought to decide which
> of these we pick (and I vote for allowing runtime use.)

I agree with Aaron.  There's no excuse for some of the functionality
that can only be found in cl to be missing from core Emacs and it's
ridiculous to re-implement it time and again (I count at least five
obvious reimplementations of remove-if in code shipped with Emacs).
There are a lot of compelling reasons to use cl and I'm not aware of
any good technical reasons why notmuch shouldn't.

Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[David Edmondson]

[-- Attachment #1: Type: text/plain, Size: 318 bytes --]

On Wed, 18 Jan 2012 17:18:48 -0500, Aaron Ecay <aaronecay@gmail.com> wrote:
> Runtime dependencies are not allowed in code distributed with emacs
> because of RMS’s conservativism[1].

Yow! Conservatism is such a pejorative term.

But, I generally agree. We should allow cl at runtime and document the
same.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

On Wed, 18 Jan 2012 17:18:48 -0500, Aaron Ecay <aaronecay@gmail.com> wrote:
> On Wed, 18 Jan 2012 14:48:02 +0100, Pieter Praet <pieter@praet.org> wrote:
> > My original intent of conserving a key(chord) [1] (which in
> > retrospect was a fairly pointless exercise in and of itself
> > [2,3]) seems to have inconspicuously morphed into an equally
> > questionable crusade [4] against the `cl' package.
> > 
> > As long there's other functions in Notmuch depending on
> > compile-time `cl', there's really no incentive whatsoever
> > to replace your perfectly fine solution.
> 
> (This is not strictly related to the immediate issue of these patches,
> but now seems as good a time as any to discuss it.)
> 
> Compile-time dependencies on ‘cl’ are absolutely not a problem.
> Virtually every major elisp program depends on cl at compile time.
> Runtime dependencies are not allowed in code distributed with emacs
> because of RMS’s conservativism[1].
> 
> Since notmuch isn’t distributed with emacs and has no aspirations to
> ever be, the project could decide to require cl at runtime.  Many
> elisp programs do.  (A quick grep through my .emacs.d folder turns up
> anything.el and clojure-mode as two large/“mainstream” projects that
> do, as well as at least a dozen smaller utility files.)  So many emacs
> users have cl loaded all the time when they are using emacs.  But
> unless the project (i.e. us) decides explicitly “runtime cl is OK” (or
> perhaps “it is not”), contributors will always go back and forth over
> using it.  To avoid patch and review churn, we ought to decide which
> of these we pick (and I vote for allowing runtime use.)
> 

Consider me thoroughly convinced :)

No point in trying to conserve resources if they're already spent.

+1 for explicitly allowing runtime `cl'.


> Aaron
> 
> Footnotes:
> [1] He specifically objects to the way that the cl package uses keyword
>     arguments, calling it un-Elisp-like.  He has resisted past efforts
>     to merge cl functions into Elisp core, although they are slowly
>     diffusing across the barrier.
> 
> -- 
> Aaron Ecay


Peace

-- 
Pieter

Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Jani Nikula]

On Mon, 16 Jan 2012 17:46:55 +0100, Pieter Praet <pieter@praet.org> wrote:
> Make `notmuch-cycle-notmuch-buffers' more Lispy and merge into `notmuch',
> eliminating the need to hog yet another keybind.

What does "merge" mean here? Will it still be possible for me to hit one
key to unconditionally get to notmuch-hello, and another to cycle
through the buffers? I wouldn't want to lose that ability.

> ---
>  emacs/notmuch.el |   40 ++++++++++++++--------------------------
>  1 files changed, 14 insertions(+), 26 deletions(-)
> 
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index ef4dcc7..539b3a0 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -1067,7 +1067,20 @@ current search results AND that are tagged with the given tag."
>  (defun notmuch ()
>    "Run notmuch and display saved searches, known tags, etc."
>    (interactive)
> -  (notmuch-hello))
> +  (let* ((old-buffer (current-buffer))
> +	 (interesting-buffers
> +	  (delq nil (mapcar (lambda (b)
> +			      (if (notmuch-interesting-buffer b) b))
> +			    (buffer-list))))
> +	 (next-buffer (first
> +	  (delq nil (mapcar (lambda (b)
> +			      (unless (eq old-buffer b) b))
> +			    interesting-buffers)))))
> +    (if next-buffer
> +    	(progn
> +    	  (switch-to-buffer next-buffer)
> +    	  (bury-buffer old-buffer))
> +      (notmuch-hello))))

notmuch-cycle-notmuch-buffers pretty much explains in the name what it
does, but additionally it has documentation, and explanatory
comments. Please don't drop those.

BR,
Jani



>  
>  (defun notmuch-interesting-buffer (b)
>    "Is the current buffer of interest to a notmuch user?"
> @@ -1078,31 +1091,6 @@ current search results AND that are tagged with the given tag."
>  		       message-mode))))
>  
>  ;;;###autoload
> -(defun notmuch-cycle-notmuch-buffers ()
> -  "Cycle through any existing notmuch buffers (search, show or hello).
> -
> -If the current buffer is the only notmuch buffer, bury it. If no
> -notmuch buffers exist, run `notmuch'."
> -  (interactive)
> -
> -  (let (start first)
> -    ;; If the current buffer is a notmuch buffer, remember it and then
> -    ;; bury it.
> -    (when (notmuch-interesting-buffer (current-buffer))
> -      (setq start (current-buffer))
> -      (bury-buffer))
> -
> -    ;; Find the first notmuch buffer.
> -    (setq first (loop for buffer in (buffer-list)
> -		     if (notmuch-interesting-buffer buffer)
> -		     return buffer))
> -
> -    (if first
> -	;; If the first one we found is any other than the starting
> -	;; buffer, switch to it.
> -	(unless (eq first start)
> -	  (switch-to-buffer first))
> -      (notmuch))))
>  
>  (setq mail-user-agent 'notmuch-user-agent)
>  
> -- 
> 1.7.8.1
> 
> _______________________________________________
> notmuch mailing list
> notmuch@notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'

[Pieter Praet]

On Mon, 16 Jan 2012 23:10:27 +0200, Jani Nikula <jani@nikula.org> wrote:
> On Mon, 16 Jan 2012 17:46:55 +0100, Pieter Praet <pieter@praet.org> wrote:
> > Make `notmuch-cycle-notmuch-buffers' more Lispy and merge into `notmuch',
> > eliminating the need to hog yet another keybind.
> 
> What does "merge" mean here? [...]

"One function ought to be enough for anybody." ? :) [1]


> [...] Will it still be possible for me to hit one
> key to unconditionally get to notmuch-hello, and another to cycle
> through the buffers? I wouldn't want to lose that ability.
> 

Sure, but then your new key should be bound to `notmuch' instead
of `notmuch-cycle-notmuch-buffers', and the key originally bound
to `notmuch' should be remapped to `notmuch-hello'.


> > ---
> >  emacs/notmuch.el |   40 ++++++++++++++--------------------------
> >  1 files changed, 14 insertions(+), 26 deletions(-)
> > 
> > diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> > index ef4dcc7..539b3a0 100644
> > --- a/emacs/notmuch.el
> > +++ b/emacs/notmuch.el
> > @@ -1067,7 +1067,20 @@ current search results AND that are tagged with the given tag."
> >  (defun notmuch ()
> >    "Run notmuch and display saved searches, known tags, etc."
> >    (interactive)
> > -  (notmuch-hello))
> > +  (let* ((old-buffer (current-buffer))
> > +	 (interesting-buffers
> > +	  (delq nil (mapcar (lambda (b)
> > +			      (if (notmuch-interesting-buffer b) b))
> > +			    (buffer-list))))
> > +	 (next-buffer (first
> > +	  (delq nil (mapcar (lambda (b)
> > +			      (unless (eq old-buffer b) b))
> > +			    interesting-buffers)))))
> > +    (if next-buffer
> > +    	(progn
> > +    	  (switch-to-buffer next-buffer)
> > +    	  (bury-buffer old-buffer))
> > +      (notmuch-hello))))
> 
> notmuch-cycle-notmuch-buffers pretty much explains in the name what it
> does, but additionally it has documentation, and explanatory
> comments. Please don't drop those.
> 

Agreed.


Less intrusive patch available [2].


> BR,
> Jani
> 
> 
> 
> >  
> >  (defun notmuch-interesting-buffer (b)
> >    "Is the current buffer of interest to a notmuch user?"
> > @@ -1078,31 +1091,6 @@ current search results AND that are tagged with the given tag."
> >  		       message-mode))))
> >  
> >  ;;;###autoload
> > -(defun notmuch-cycle-notmuch-buffers ()
> > -  "Cycle through any existing notmuch buffers (search, show or hello).
> > -
> > -If the current buffer is the only notmuch buffer, bury it. If no
> > -notmuch buffers exist, run `notmuch'."
> > -  (interactive)
> > -
> > -  (let (start first)
> > -    ;; If the current buffer is a notmuch buffer, remember it and then
> > -    ;; bury it.
> > -    (when (notmuch-interesting-buffer (current-buffer))
> > -      (setq start (current-buffer))
> > -      (bury-buffer))
> > -
> > -    ;; Find the first notmuch buffer.
> > -    (setq first (loop for buffer in (buffer-list)
> > -		     if (notmuch-interesting-buffer buffer)
> > -		     return buffer))
> > -
> > -    (if first
> > -	;; If the first one we found is any other than the starting
> > -	;; buffer, switch to it.
> > -	(unless (eq first start)
> > -	  (switch-to-buffer first))
> > -      (notmuch))))
> >  
> >  (setq mail-user-agent 'notmuch-user-agent)
> >  
> > -- 
> > 1.7.8.1
> > 
> > _______________________________________________
> > notmuch mailing list
> > notmuch@notmuchmail.org
> > http://notmuchmail.org/mailman/listinfo/notmuch


Peace

-- 
Pieter

[1] http://www.computerworld.com/s/article/9101699
[2] id:"1326881084-25432-1-git-send-email-pieter@praet.org"

Re: [PATCH v2] emacs: Cycle through notmuch buffers rather than jumping to the last.

[David Bremner]

On Wed, 28 Dec 2011 08:29:58 +0000, David Edmondson <dme@dme.org> wrote:
> As suggested by j4ni in #notmuch, rename
> `notmuch-jump-to-recent-buffer' as `notmuch-cycle-notmuch-buffers' and
> have it behave accordingly.

pushed, 

d