* [PATCH v4] emacs: customizable names for search buffers
@ 2022-01-10 18:16 jao
2022-01-13 6:05 ` Tomi Ollila
0 siblings, 1 reply; 10+ messages in thread
From: jao @ 2022-01-10 18:16 UTC (permalink / raw)
To: notmuch; +Cc: jao
Customizable names for buffers presenting search results, via two
custom variables (notmuch-search-buffer-name-format and
notmuch-saved-search-buffer-name-format), defaulting to values
currently used for plain searches and including too tree and
unthreaded search buffers.
---
This is a much improved version of the patch in
id:20220108204121.1053932-1-jao@gnu.org, according to discussion on
that thread.
This version fixes a doc string.
Signed-off-by: jao <jao@gnu.org>
---
emacs/notmuch-hello.el | 11 +++++----
emacs/notmuch-tree.el | 10 ++++-----
emacs/notmuch.el | 51 +++++++++++++++++++++++++++++++++---------
3 files changed, 53 insertions(+), 19 deletions(-)
diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
index fc007c4c..44341dd6 100644
--- a/emacs/notmuch-hello.el
+++ b/emacs/notmuch-hello.el
@@ -486,11 +486,14 @@ diagonal."
(defun notmuch-hello-widget-search (widget &rest _ignore)
(cl-case (widget-get widget :notmuch-search-type)
(tree
- (notmuch-tree (widget-get widget :notmuch-search-terms)
- nil nil nil nil nil nil
- (widget-get widget :notmuch-search-oldest-first)))
+ (let ((n (notmuch-search-format-buffer-name (widget-value widget) "tree" t)))
+ (notmuch-tree (widget-get widget :notmuch-search-terms)
+ nil nil n nil nil nil
+ (widget-get widget :notmuch-search-oldest-first))))
(unthreaded
- (notmuch-unthreaded (widget-get widget :notmuch-search-terms)))
+ (let ((n (notmuch-search-format-buffer-name (widget-value widget)
+ "unthreaded" t)))
+ (notmuch-unthreaded (widget-get widget :notmuch-search-terms) nil nil n)))
(t
(notmuch-search (widget-get widget :notmuch-search-terms)
(widget-get widget :notmuch-search-oldest-first)))))
diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
index d7486904..303c6fad 100644
--- a/emacs/notmuch-tree.el
+++ b/emacs/notmuch-tree.el
@@ -1191,11 +1191,11 @@ The arguments are:
(setq query (notmuch-read-query (concat "Notmuch "
(if unthreaded "unthreaded " "tree ")
"view search: "))))
- (let ((buffer (get-buffer-create (generate-new-buffer-name
- (or buffer-name
- (concat "*notmuch-"
- (if unthreaded "unthreaded-" "tree-")
- query "*")))))
+ (let* ((name
+ (or buffer-name
+ (notmuch-search-buffer-title query
+ (if unthreaded "unthreaded" "tree"))))
+ (buffer (get-buffer-create (generate-new-buffer-name name)))
(inhibit-read-only t))
(pop-to-buffer-same-window buffer))
;; Don't track undo information for this buffer
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 85a54706..afb0a115 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -915,7 +915,37 @@ See `notmuch-tag' for information on the format of TAG-CHANGES."
(notmuch-search-get-tags-region (point-min) (point-max)) "Tag all")))
(notmuch-search-tag tag-changes (point-min) (point-max) t))
-(defun notmuch-search-buffer-title (query)
+(defcustom notmuch-search-buffer-name-format "*notmuch-%t-%s*"
+ "Format for the name of search results buffers.
+
+In this spec, %s will be replaced by a description of the search
+query and %t by its type (search, tree or unthreaded).
+
+See also `notmuch-saved-search-buffer-name-format'"
+ :type 'string
+ :group 'notmuch-search)
+
+(defcustom notmuch-saved-search-buffer-name-format "*notmuch-saved-%t-%s*"
+ "Format for the name of search results buffers.
+
+In this spec, %s will be replaced by the saved search name and %t
+by its type (search, tree or unthreaded).
+
+See also `notmuch-search-buffer-name-format'"
+ :type 'string
+ :group 'notmuch-search)
+
+(defun notmuch-search-format-buffer-name (query type saved)
+ "Compose a buffer name for the given QUERY, TYPE (search, tree,
+unthreaded) and whether it's SAVED (t or nil)."
+ (let ((fmt (if saved
+ notmuch-saved-search-buffer-name-format
+ notmuch-search-buffer-name-format)))
+ (if (fboundp 'format-spec)
+ (format-spec fmt `((?t . ,(or type "search")) (?s . ,query))))
+ (format (replace-regexp-in-string "\\b%t\\b" (or type "search") fmt) query)))
+
+(defun notmuch-search-buffer-title (query &optional type)
"Returns the title for a buffer with notmuch search results."
(let* ((saved-search
(let (longest
@@ -930,19 +960,20 @@ See `notmuch-tag' for information on the format of TAG-CHANGES."
do (setq longest tuple))
longest))
(saved-search-name (notmuch-saved-search-get saved-search :name))
+ (saved-search-type (notmuch-saved-search-get saved-search :search-type))
(saved-search-query (notmuch-saved-search-get saved-search :query)))
(cond ((and saved-search (equal saved-search-query query))
;; Query is the same as saved search (ignoring case)
- (concat "*notmuch-saved-search-" saved-search-name "*"))
+ (notmuch-search-format-buffer-name saved-search-name
+ saved-search-type
+ t))
(saved-search
- (concat "*notmuch-search-"
- (replace-regexp-in-string
- (concat "^" (regexp-quote saved-search-query))
- (concat "[ " saved-search-name " ]")
- query)
- "*"))
- (t
- (concat "*notmuch-search-" query "*")))))
+ (let ((query (replace-regexp-in-string
+ (concat "^" (regexp-quote saved-search-query))
+ (concat "[ " saved-search-name " ]")
+ query)))
+ (notmuch-search-format-buffer-name query saved-search-type t)))
+ (t (notmuch-search-format-buffer-name query type nil)))))
(defun notmuch-read-query (prompt)
"Read a notmuch-query from the minibuffer with completion.
--
2.34.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH v4] emacs: customizable names for search buffers
2022-01-10 18:16 [PATCH v4] emacs: customizable names for search buffers jao
@ 2022-01-13 6:05 ` Tomi Ollila
2022-01-13 22:43 ` Jose A Ortega Ruiz
0 siblings, 1 reply; 10+ messages in thread
From: Tomi Ollila @ 2022-01-13 6:05 UTC (permalink / raw)
To: jao, notmuch
On Mon, Jan 10 2022, jao@gnu.org wrote:
> Customizable names for buffers presenting search results, via two
> custom variables (notmuch-search-buffer-name-format and
> notmuch-saved-search-buffer-name-format), defaulting to values
> currently used for plain searches and including too tree and
> unthreaded search buffers.
>
> ---
>
> This is a much improved version of the patch in
> id:20220108204121.1053932-1-jao@gnu.org, according to discussion on
> that thread.
>
> This version fixes a doc string.
>
> Signed-off-by: jao <jao@gnu.org>
> ---
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index 85a54706..afb0a115 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -915,7 +915,37 @@ See `notmuch-tag' for information on the format of TAG-CHANGES."
> (notmuch-search-get-tags-region (point-min) (point-max)) "Tag all")))
> (notmuch-search-tag tag-changes (point-min) (point-max) t))
>
> -(defun notmuch-search-buffer-title (query)
> +(defcustom notmuch-search-buffer-name-format "*notmuch-%t-%s*"
> + "Format for the name of search results buffers.
> +
> +In this spec, %s will be replaced by a description of the search
> +query and %t by its type (search, tree or unthreaded).
> +
> +See also `notmuch-saved-search-buffer-name-format'"
> + :type 'string
> + :group 'notmuch-search)
> +
> +(defcustom notmuch-saved-search-buffer-name-format "*notmuch-saved-%t-%s*"
> + "Format for the name of search results buffers.
> +
> +In this spec, %s will be replaced by the saved search name and %t
> +by its type (search, tree or unthreaded).
> +
> +See also `notmuch-search-buffer-name-format'"
> + :type 'string
> + :group 'notmuch-search)
> +
> +(defun notmuch-search-format-buffer-name (query type saved)
> + "Compose a buffer name for the given QUERY, TYPE (search, tree,
> +unthreaded) and whether it's SAVED (t or nil)."
> + (let ((fmt (if saved
> + notmuch-saved-search-buffer-name-format
> + notmuch-search-buffer-name-format)))
> + (if (fboundp 'format-spec)
> + (format-spec fmt `((?t . ,(or type "search")) (?s . ,query))))
> + (format (replace-regexp-in-string "\\b%t\\b" (or type "search") fmt) query)))
I am curious about this regexp, \b is matching word/non-word boundary -- so
I had to test it.
(replace-regexp-in-string "\\b%t\\b" "repl" "foo %t bar") ;; no replacement
(replace-regexp-in-string "\\b%t\\b" "repl" "foo-%t-bar") ;; no replacement
...
(replace-regexp-in-string "\\b%t\\b" "repl" "foox%t-bar") ;; replacement!
before % there is "word" character and after t there is "non-word" character.
I wonder whether that works... (or is it just something I don't
understand)..
Also tried (format-spec "foo-%t-bar" '((?t . "repl"))) ;; which works as
I'd expect.
Tomi
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] emacs: customizable names for search buffers
2022-01-13 6:05 ` Tomi Ollila
@ 2022-01-13 22:43 ` Jose A Ortega Ruiz
2022-01-14 0:57 ` Jose A Ortega Ruiz
2022-01-16 20:34 ` Kyle Meyer
0 siblings, 2 replies; 10+ messages in thread
From: Jose A Ortega Ruiz @ 2022-01-13 22:43 UTC (permalink / raw)
To: Tomi Ollila, notmuch
On Thu, Jan 13 2022, Tomi Ollila wrote:
[...]
> I am curious about this regexp, \b is matching word/non-word boundary -- so
> I had to test it.
>
> (replace-regexp-in-string "\\b%t\\b" "repl" "foo %t bar") ;; no replacement
> (replace-regexp-in-string "\\b%t\\b" "repl" "foo-%t-bar") ;; no replacement
> ...
> (replace-regexp-in-string "\\b%t\\b" "repl" "foox%t-bar") ;; replacement!
>
> before % there is "word" character and after t there is "non-word" character.
Ah, yes... i messed up, i think we want here
(replace-regexp-in-string "\\_<%t\\_>" "repl" "foo %t bar")
i.e. \_< .. \_> to correctly delimit beginning and end of word, not just
boundary (i always trip on this!).
> Also tried (format-spec "foo-%t-bar" '((?t . "repl"))) ;; which works as
> I'd expect.
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.
thanks for checking, and if you can confirm the above fix looks better,
i'll submit a new version.
cheers,
jao
--
A language that doesn't affect the way you think about programming, is
not worth knowing.
- Alan Perlis, Epigrams on Programming
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] emacs: customizable names for search buffers
2022-01-13 22:43 ` Jose A Ortega Ruiz
@ 2022-01-14 0:57 ` Jose A Ortega Ruiz
2022-01-16 19:42 ` Tomi Ollila
2022-01-16 20:34 ` Kyle Meyer
1 sibling, 1 reply; 10+ messages in thread
From: Jose A Ortega Ruiz @ 2022-01-14 0:57 UTC (permalink / raw)
To: Tomi Ollila, notmuch
on second thought, i think we could perhaps just go for the simpler
"%t", which would allow inserting the type anywhere, even in the middle
of a word... i think a problem here is that "word" or "symbol" (which is
what my suggestion used) constituent depend on the definition of what's
a word or symbol in the active mode.
although that would prevent fancy things like "%type: %t", but that's a
bit of a corner case, don't you think?
cheers,
jao
--
The surest way to corrupt a youth is to instruct him to hold in higher
esteem those who think alike than those who think
differently. -Friedrich Nietzsche, philosopher (1844-1900)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] emacs: customizable names for search buffers
2022-01-14 0:57 ` Jose A Ortega Ruiz
@ 2022-01-16 19:42 ` Tomi Ollila
2022-01-16 20:40 ` Jose A Ortega Ruiz
0 siblings, 1 reply; 10+ messages in thread
From: Tomi Ollila @ 2022-01-16 19:42 UTC (permalink / raw)
To: Jose A Ortega Ruiz, notmuch
On Fri, Jan 14 2022, Jose A. Ortega Ruiz wrote:
> on second thought, i think we could perhaps just go for the simpler
> "%t", which would allow inserting the type anywhere, even in the middle
> of a word... i think a problem here is that "word" or "symbol" (which is
> what my suggestion used) constituent depend on the definition of what's
> a word or symbol in the active mode.
>
> although that would prevent fancy things like "%type: %t", but that's a
> bit of a corner case, don't you think?
Yes, simpler; the cases where is breaks are (probably?) seldom enough.
Also for reference,
(replace-regexp-in-string "\\_<%t\\_>" "repl" "foo-%t-bar") ;; does not work
(replace-regexp-in-string "\\_<%t\\_>" "repl" "foo %%%t bar") ;; neither...
(replace-regexp-in-string "\\_<%t\\_>" "repl" "foo %t bar") ;; worked, but...
Tomi
>
> cheers,
> jao
> --
> The surest way to corrupt a youth is to instruct him to hold in higher
> esteem those who think alike than those who think
> differently. -Friedrich Nietzsche, philosopher (1844-1900)
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] emacs: customizable names for search buffers
2022-01-13 22:43 ` Jose A Ortega Ruiz
2022-01-14 0:57 ` Jose A Ortega Ruiz
@ 2022-01-16 20:34 ` Kyle Meyer
2022-01-16 22:25 ` Jose A Ortega Ruiz
1 sibling, 1 reply; 10+ messages in thread
From: Kyle Meyer @ 2022-01-16 20:34 UTC (permalink / raw)
To: Jose A Ortega Ruiz; +Cc: notmuch
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".
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] emacs: customizable names for search buffers
2022-01-16 19:42 ` Tomi Ollila
@ 2022-01-16 20:40 ` Jose A Ortega Ruiz
0 siblings, 0 replies; 10+ messages in thread
From: Jose A Ortega Ruiz @ 2022-01-16 20:40 UTC (permalink / raw)
To: Tomi Ollila, notmuch
On Sun, Jan 16 2022, Tomi Ollila wrote:
> On Fri, Jan 14 2022, Jose A. Ortega Ruiz wrote:
>> on second thought, i think we could perhaps just go for the simpler
>> "%t", which would allow inserting the type anywhere, even in the middle
>> of a word... i think a problem here is that "word" or "symbol" (which is
>> what my suggestion used) constituent depend on the definition of what's
>> a word or symbol in the active mode.
>>
>> although that would prevent fancy things like "%type: %t", but that's a
>> bit of a corner case, don't you think?
>
> Yes, simpler; the cases where is breaks are (probably?) seldom enough.
agreed then. v5 of the patch should be doing just that, if i didn't
mess up.
thanks,
jao
--
The enjoyment of one's tools is an essential ingredient of successful
work. – Donald E. Knuth\r
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] emacs: customizable names for search buffers
2022-01-16 20:34 ` Kyle Meyer
@ 2022-01-16 22:25 ` Jose A Ortega Ruiz
2022-01-16 23:06 ` Kyle Meyer
0 siblings, 1 reply; 10+ messages in thread
From: Jose A Ortega Ruiz @ 2022-01-16 22:25 UTC (permalink / raw)
To: Kyle Meyer; +Cc: notmuch
On Sun, Jan 16 2022, Kyle Meyer wrote:
> 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".
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 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.
Thanks a lot for checking,
jao
--
"The evil that is in the world almost always comes of ignorance, and
good intentions may do as much harm as malevolence if they lack understanding."
- Albert Camus
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] emacs: customizable names for search buffers
2022-01-16 22:25 ` Jose A Ortega Ruiz
@ 2022-01-16 23:06 ` Kyle Meyer
2022-01-16 23:51 ` Jose A Ortega Ruiz
0 siblings, 1 reply; 10+ messages in thread
From: Kyle Meyer @ 2022-01-16 23:06 UTC (permalink / raw)
To: Jose A Ortega Ruiz; +Cc: notmuch
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v4] emacs: customizable names for search buffers
2022-01-16 23:06 ` Kyle Meyer
@ 2022-01-16 23:51 ` Jose A Ortega Ruiz
0 siblings, 0 replies; 10+ messages in thread
From: Jose A Ortega Ruiz @ 2022-01-16 23:51 UTC (permalink / raw)
To: Kyle Meyer; +Cc: notmuch
On Sun, Jan 16 2022, Kyle Meyer wrote:
[...]
> 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.
Thanks for checking. v6 of the patch submitted.
Cheers,
jao
--
It is a truism of escape plans that the problem with going anywhere is
that you take yourself with you -- Emma Brockes
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-01-16 23:51 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-10 18:16 [PATCH v4] emacs: customizable names for search buffers jao
2022-01-13 6:05 ` Tomi Ollila
2022-01-13 22:43 ` Jose A Ortega Ruiz
2022-01-14 0:57 ` Jose A Ortega Ruiz
2022-01-16 19:42 ` Tomi Ollila
2022-01-16 20:40 ` Jose A Ortega Ruiz
2022-01-16 20:34 ` Kyle Meyer
2022-01-16 22:25 ` Jose A Ortega Ruiz
2022-01-16 23:06 ` Kyle Meyer
2022-01-16 23:51 ` Jose A Ortega Ruiz
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).