Re: [PATCH] v2 [RFC] emacs: merge overhauled `notmuch-cycle-notmuch-buffers' into `notmuch'
On Wed, 18 Jan 2012 17:18:48 -0500, Aaron Ecay aarone...@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. pgpAUmSfE9EOk.pgp Description: PGP signature ___ 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'
On Wed, 18 Jan 2012 17:18:48 -0500, Aaron Ecay aarone...@gmail.com wrote: On Wed, 18 Jan 2012 14:48:02 +0100, Pieter Praet pie...@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 ___ 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'
On Mon, 16 Jan 2012 17:03:44 +, David Edmondson d...@dme.org wrote: On Mon, 16 Jan 2012 17:46:55 +0100, Pieter Praet pie...@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-pie...@praet.org ___ 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'
On Mon, 16 Jan 2012 23:10:27 +0200, Jani Nikula j...@nikula.org wrote: On Mon, 16 Jan 2012 17:46:55 +0100, Pieter Praet pie...@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-pie...@praet.org ___ 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'
On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet pie...@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? pgpBb36VLbqMG.pgp Description: PGP signature ___ 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'
On Wed, 18 Jan 2012 10:13:35 +, David Edmondson d...@dme.org wrote: On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet pie...@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@hotblack-desiato.hh.sledj.net [2] id:cun1uqz50p4@hotblack-desiato.hh.sledj.net ___ 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'
On Wed, 18 Jan 2012 13:15:55 +0100, Pieter Praet pie...@praet.org wrote: On Wed, 18 Jan 2012 10:13:35 +, David Edmondson d...@dme.org wrote: On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet pie...@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. pgpp0gnSDl9OJ.pgp Description: PGP signature ___ 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'
On Wed, 18 Jan 2012 13:03:06 +, David Edmondson d...@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 +, David Edmondson d...@dme.org wrote: On Wed, 18 Jan 2012 13:15:55 +0100, Pieter Praet pie...@praet.org wrote: On Wed, 18 Jan 2012 10:13:35 +, David Edmondson d...@dme.org wrote: On Wed, 18 Jan 2012 11:03:09 +0100, Pieter Praet pie...@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-pie...@praet.org [2] id:87wr8rc2ex@praet.org [3] id:87ehuzl5fg@nikula.org [4] id:87r4yza95m@praet.org [5] id:87fwfd8h0i@praet.org ___ 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'
On Wed, 18 Jan 2012 14:48:02 +0100, Pieter Praet pie...@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 ___ 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'
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. ___ 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'
On Mon, 16 Jan 2012 17:46:55 +0100, Pieter Praet pie...@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. pgpQYEK9fDOpl.pgp Description: PGP signature ___ 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'
On Mon, 16 Jan 2012 17:46:55 +0100, Pieter Praet pie...@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 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
