* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
@ 2015-10-08 15:54 Nicolas Richard
2015-10-09 14:37 ` Kaushal Modi
2015-10-27 11:30 ` Nicolas Richard
0 siblings, 2 replies; 16+ messages in thread
From: Nicolas Richard @ 2015-10-08 15:54 UTC (permalink / raw)
To: 21649
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
When running M-x man RET man RET, then C-x o to select the newly created
window and then running M-x man RET sed RET, what you get is: two "man"
windows side by side. It would make sense to re-use the existing one.
How to best do that I do not know. If modifying the code is necessary,
here's an attempt at adding an option in Man-notify-method. (I'm not
attached to this implementation, and even less attached to the silly
name `manly' that I chose, btw.)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Allow-M-x-man-to-reuse-an-existing-window.patch --]
[-- Type: text/x-diff, Size: 2031 bytes --]
From 2b812b1c9f91af2cf6116f1d4e334154ae44c724 Mon Sep 17 00:00:00 2001
From: Nicolas Richard <youngfrog@members.fsf.org>
Date: Thu, 8 Oct 2015 10:50:07 +0200
Subject: [PATCH] Allow M-x man to reuse an existing window
* man.el (Man-notify-when-ready): add `manly' option.
(Man-notify-method): augment docstring accordingly.
---
lisp/man.el | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/lisp/man.el b/lisp/man.el
index c5dbcba..a02ee79 100644
--- a/lisp/man.el
+++ b/lisp/man.el
@@ -91,6 +91,8 @@
(require 'ansi-color)
(require 'cl-lib)
(require 'button)
+(require 'subr-x)
+(require 'seq)
(defgroup man nil
"Browse UNIX manual pages."
@@ -162,6 +164,8 @@ (defcustom Man-notify-method (if (boundp 'Man-notify) Man-notify 'friendly)
bully -- make the manpage the current buffer and only window (sf)
aggressive -- make the manpage the current buffer in the other window (sf)
friendly -- display manpage in the other window but don't make current (sf)
+manly -- like `friendly' but re-use a window displaying a man page if
+ possible (sf)
polite -- don't display manpage, but prints message and beep when ready
quiet -- like `polite', but don't beep
meek -- make no indication that the manpage is ready
@@ -1166,6 +1170,16 @@ (defun Man-notify-when-ready (man-buffer)
(and (frame-live-p saved-frame)
(select-frame saved-frame))
(display-buffer man-buffer 'not-this-window))
+ (`manly
+ (and (frame-live-p saved-frame)
+ (select-frame saved-frame))
+ (if-let ((window (seq-some-p
+ (lambda (window)
+ (with-current-buffer (window-buffer window)
+ (derived-mode-p 'Man-mode)))
+ (window-list))))
+ (set-window-buffer window man-buffer)
+ (display-buffer man-buffer)))
(`polite
(beep)
(message "Manual buffer %s is ready" (buffer-name man-buffer)))
--
2.4.6
^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
2015-10-08 15:54 bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window Nicolas Richard
@ 2015-10-09 14:37 ` Kaushal Modi
[not found] ` <86r3l09t3u.fsf@members.fsf.org>
2015-10-27 11:30 ` Nicolas Richard
1 sibling, 1 reply; 16+ messages in thread
From: Kaushal Modi @ 2015-10-09 14:37 UTC (permalink / raw)
To: 21649, youngfrog
[-- Attachment #1: Type: text/plain, Size: 402 bytes --]
You can do the window control by customizing the `display-buffer-alist`
variable. That's a suggestion if you haven't yet looked at it.
Personally, I use the shackle package which is an interface to
customization of that variable. I mention this because I control where the
man/woman buffers open using this package (
https://github.com/kaushalmodi/.emacs.d/blob/master/setup-files/setup-shackle.el
)
[-- Attachment #2: Type: text/html, Size: 553 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
[not found] ` <86r3l09t3u.fsf@members.fsf.org>
@ 2015-10-12 15:06 ` Kaushal Modi
2015-10-13 22:10 ` Nicolas Richard
0 siblings, 1 reply; 16+ messages in thread
From: Kaushal Modi @ 2015-10-12 15:06 UTC (permalink / raw)
To: Nicolas Richard, 21649@debbugs.gnu.org
[-- Attachment #1: Type: text/plain, Size: 1948 bytes --]
Here is the order in which the functions are called
M-x man -> Man-getpage-in-background -> Man-notify-when-ready ->
display-buffer (if Man-notify-method variable is set to 'friendly, which is
its default value)
You will get help about display-buffer-alist when you do `C-h f
display-buffer`.
You can also do `C-h v display-buffer-alist` and that will point you to the
`display-buffer` function documentation.
You can learn more about Display Action Functions by evaluating (info
"(elisp) Display Action Functions") or doing `C-h i g (elisp) Display
Action Functions`.
Using the shackle package allows you to set the display actions from a
higher level without having to customize the display-buffer-alist manually.
If you are interested in customizing display-buffer-alist manually, there
are few examples on emacs.stackexchange.com which might help you:
- http://emacs.stackexchange.com/a/12757/115
- http://emacs.stackexchange.com/a/2195/115
- http://emacs.stackexchange.com/a/338/115
On Mon, Oct 12, 2015 at 8:19 AM Nicolas Richard <youngfrog@members.fsf.org>
wrote:
> Hi,
>
> Thanks for the hint. I haven't looked into it yet, indeed.
> display-buffer-alist is not very user-friendly (and isn't mentionned in
> the docstring of `man'). Your shackle config file looks easier but I
> don't see an obvious way to say "re use an existing window which
> displays a buffer of the same mode". Maybe I should just try it and
> see...
>
> Nicolas Richard.
>
>
> Kaushal Modi <kaushal.modi@gmail.com> writes:
> > You can do the window control by customizing the `display-buffer-alist`
> variable. That's a suggestion if you haven't
> > yet looked at it.
> >
> > Personally, I use the shackle package which is an interface to
> customization of that variable. I mention this because
> > I control where the man/woman buffers open using this package (
> >
> https://github.com/kaushalmodi/.emacs.d/blob/master/setup-files/setup-shackle.el
> )
>
[-- Attachment #2: Type: text/html, Size: 2934 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
2015-10-12 15:06 ` Kaushal Modi
@ 2015-10-13 22:10 ` Nicolas Richard
2015-10-13 22:19 ` Kaushal Modi
0 siblings, 1 reply; 16+ messages in thread
From: Nicolas Richard @ 2015-10-13 22:10 UTC (permalink / raw)
To: Kaushal Modi; +Cc: 21649@debbugs.gnu.org
Hello Kaushal,
Thanks for the pointers.
What I mean is that customizing display-buffer-alist is not very
user-friendly even though I know how to use it. It is also not
mentionned in (info "(emacs) Window Choice"). OTOH it is a defcustom, so
I have mixed feelings about this variable.
Anyway, a possible way to achieve the effect I asked for is to add a
suitable entry in display-buffer-alist, but it requires writing an elisp
function (the predefined ones don't fit the bill). I'll be happy to
provide such a function if that is the preferred route.
Nicolas.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
2015-10-13 22:10 ` Nicolas Richard
@ 2015-10-13 22:19 ` Kaushal Modi
2015-10-14 8:49 ` martin rudalics
0 siblings, 1 reply; 16+ messages in thread
From: Kaushal Modi @ 2015-10-13 22:19 UTC (permalink / raw)
To: Nicolas Richard, martin rudalics, cyd; +Cc: 21649@debbugs.gnu.org
[-- Attachment #1: Type: text/plain, Size: 845 bytes --]
Based on
http://git.savannah.gnu.org/cgit/emacs.git/log/?qt=grep&q=display-buffer-alist
copying Martin Rudalics and Chong Yidong for their comments.
--
Kaushal Modi
On Tue, Oct 13, 2015 at 6:10 PM, Nicolas Richard <youngfrog@members.fsf.org>
wrote:
> Hello Kaushal,
>
> Thanks for the pointers.
>
> What I mean is that customizing display-buffer-alist is not very
> user-friendly even though I know how to use it. It is also not
> mentionned in (info "(emacs) Window Choice"). OTOH it is a defcustom, so
> I have mixed feelings about this variable.
>
> Anyway, a possible way to achieve the effect I asked for is to add a
> suitable entry in display-buffer-alist, but it requires writing an elisp
> function (the predefined ones don't fit the bill). I'll be happy to
> provide such a function if that is the preferred route.
>
> Nicolas.
>
[-- Attachment #2: Type: text/html, Size: 1803 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
2015-10-13 22:19 ` Kaushal Modi
@ 2015-10-14 8:49 ` martin rudalics
[not found] ` <86wpufc8n8.fsf@members.fsf.org>
0 siblings, 1 reply; 16+ messages in thread
From: martin rudalics @ 2015-10-14 8:49 UTC (permalink / raw)
To: Kaushal Modi, Nicolas Richard, cyd; +Cc: 21649@debbugs.gnu.org
> http://git.savannah.gnu.org/cgit/emacs.git/log/?qt=grep&q=display-buffer-alist
>
> copying Martin Rudalics and Chong Yidong for their comments.
You probably might want to follow up the thread "display-buffer-alist
simplifications" on emacs-devel.
martin
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
[not found] ` <86wpufc8n8.fsf@members.fsf.org>
@ 2015-10-22 15:34 ` martin rudalics
2015-10-22 19:21 ` Nicolas Richard
0 siblings, 1 reply; 16+ messages in thread
From: martin rudalics @ 2015-10-22 15:34 UTC (permalink / raw)
To: Nicolas Richard; +Cc: 21649@debbugs.gnu.org
> Thanks for the hint. That's a very long thread however. I read the first
> few messages but gave up for now for the following reason : I'd like to
> address my bug report first, and it isn't about how difficult
> display-buffer-alist is, even though I did mention that.
That thread explains why ‘display-buffer’ works as it does now. It's
not useful to explain how ‘display-buffer’ works now. So you did good
to give up soon ;-)
> My concern is about making a *Man ...* window reusable. It can be done:
> - by adding a new choice to Man-notify-method (which is what my patch does)
> - by asking the user to customize display-buffer-alist, but in this case
> I think someone has to write a new function (similar to
> display-buffer-reuse-window except that it's not the same buffer, but
> another *Man ...* buffer -- e.g.
> display-buffer-reuse-window-with-matching-major-mode).
> - maybe some other way
>
> If the question is of interest, which answer is the best ? If it's the
> second, I could write such a function. Then we also somehow need to
> advertise display-buffer-alist in the docstring of Man-notify-method.
Sorry, I must have missed your patch. Probably I got confused by the
current state of emacs-devel. Also I hardly ever use ‘man’ so I'm not
very competent to comment such an addition anyway.
How about writing an action function, say ‘man-display-buffer-my-way’, and
adding a clause like
(`my-way
(and (frame-live-p saved-frame)
(select-frame saved-frame))
(display-buffer man-buffer
'((man-display-buffer-my-way ...)
. nil)))
to ‘Man-notify-when-ready’? This would hardly harm, satisfy anyone
asking for customization and likely introduce the first instance of an
action function outside of window.el.
And please don't drop 21649@debbugs.gnu.org from the list of recipients!
martin
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
2015-10-22 15:34 ` martin rudalics
@ 2015-10-22 19:21 ` Nicolas Richard
2015-10-23 8:01 ` martin rudalics
0 siblings, 1 reply; 16+ messages in thread
From: Nicolas Richard @ 2015-10-22 19:21 UTC (permalink / raw)
To: martin rudalics; +Cc: 21649@debbugs.gnu.org
martin rudalics <rudalics@gmx.at> writes:
> Sorry, I must have missed your patch.
Here's most of the patch :
+ (`manly
+ (and (frame-live-p saved-frame)
+ (select-frame saved-frame))
+ (if-let ((window (seq-some-p
+ (lambda (window)
+ (with-current-buffer (window-buffer window)
+ (derived-mode-p 'Man-mode)))
+ (window-list))))
+ (set-window-buffer window man-buffer)
+ (display-buffer man-buffer)))
> How about writing an action function, say ‘man-display-buffer-my-way’, and
> adding a clause like
>
> (`my-way
> (and (frame-live-p saved-frame)
> (select-frame saved-frame))
> (display-buffer man-buffer
> '((man-display-buffer-my-way ...)
> . nil)))
Sure, why not!
> And please don't drop 21649@debbugs.gnu.org from the list of recipients!
That was not intended. I probably hit R instead of F, sorry about that.
Nico.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
2015-10-22 19:21 ` Nicolas Richard
@ 2015-10-23 8:01 ` martin rudalics
2016-03-01 15:49 ` Nicolas Richard
0 siblings, 1 reply; 16+ messages in thread
From: martin rudalics @ 2015-10-23 8:01 UTC (permalink / raw)
To: Nicolas Richard; +Cc: 21649@debbugs.gnu.org
> Here's most of the patch :
>
> + (`manly
> + (and (frame-live-p saved-frame)
> + (select-frame saved-frame))
> + (if-let ((window (seq-some-p
> + (lambda (window)
> + (with-current-buffer (window-buffer window)
> + (derived-mode-p 'Man-mode)))
> + (window-list))))
> + (set-window-buffer window man-buffer)
> + (display-buffer man-buffer)))
>
>> How about writing an action function, say ‘man-display-buffer-my-way’, and
>> adding a clause like
>>
>> (`my-way
>> (and (frame-live-p saved-frame)
>> (select-frame saved-frame))
>> (display-buffer man-buffer
>> '((man-display-buffer-my-way ...)
>> . nil)))
>
> Sure, why not!
Maybe we could add something like ‘display-buffer-reuse-mode-window’ to
window.el. In that case I'd proceed as follows:
(1) The frame(s) to scan for a suitable window should be determined by a
‘reusable-frames’ entry just as in ‘display-buffer-reuse-window’.
(2) Allow to specify the desired (parent) mode via an ALIST ‘mode’
entry. As value we could allow a single mode or a list of modes. Then
a window showing a buffer in the same mode as the buffer we want to
display should maybe given preference to a window showing a buffer in
another mode, derived from the same parent mode. If a same-mode-window
exists on another and a derived-mode-window exists on the selected
frame, one of these should be given preference consistently.
(3) Not use functions like ‘if-let’ and ‘seq-some-p’. window.el is
preloaded and if not utterly necessary I'd prefer not loading subr-x.el
there. BTW, I have no idea from where you get ‘seq-some-p’. Did you
compile your patched man.el with emacs -Q?
WDYT?
martin
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
2015-10-08 15:54 bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window Nicolas Richard
2015-10-09 14:37 ` Kaushal Modi
@ 2015-10-27 11:30 ` Nicolas Richard
2015-10-28 9:55 ` martin rudalics
1 sibling, 1 reply; 16+ messages in thread
From: Nicolas Richard @ 2015-10-27 11:30 UTC (permalink / raw)
To: martin rudalics; +Cc: 21649@debbugs.gnu.org
martin rudalics <rudalics@gmx.at> writes:
> Maybe we could add something like ‘display-buffer-reuse-mode-window’ to
> window.el. In that case I'd proceed as follows:
>
> (1) The frame(s) to scan for a suitable window should be determined by a
> ‘reusable-frames’ entry just as in ‘display-buffer-reuse-window’.
>
> (2) Allow to specify the desired (parent) mode via an ALIST ‘mode’
> entry. As value we could allow a single mode or a list of modes. Then
> a window showing a buffer in the same mode as the buffer we want to
> display should maybe given preference to a window showing a buffer in
> another mode, derived from the same parent mode. If a same-mode-window
> exists on another and a derived-mode-window exists on the selected
> frame, one of these should be given preference consistently.
Looks ok ! I'll give it a try and provide a patch based on your
suggestion.
> BTW, I have no idea from where you get ‘seq-some-p’. Did you
> compile your patched man.el with emacs -Q?
It is from seq.el, but apparently it was a slightly out of date emacs
build. From the ChangeLog:
ChangeLog.2: Rename seq-some-p to seq-some and seq-contains-p to seq-contains
Nico.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
2015-10-27 11:30 ` Nicolas Richard
@ 2015-10-28 9:55 ` martin rudalics
0 siblings, 0 replies; 16+ messages in thread
From: martin rudalics @ 2015-10-28 9:55 UTC (permalink / raw)
To: Nicolas Richard; +Cc: 21649@debbugs.gnu.org
> I'll give it a try and provide a patch based on your
> suggestion.
Fine. If you have any questions, please don't hesitate to ask.
Thanks, martin
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
2015-10-23 8:01 ` martin rudalics
@ 2016-03-01 15:49 ` Nicolas Richard
2016-03-01 17:04 ` martin rudalics
0 siblings, 1 reply; 16+ messages in thread
From: Nicolas Richard @ 2016-03-01 15:49 UTC (permalink / raw)
To: martin rudalics; +Cc: 21649@debbugs.gnu.org
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
martin rudalics <rudalics@gmx.at> writes:
> (2) Allow to specify the desired (parent) mode via an ALIST ‘mode’
> entry. As value we could allow a single mode or a list of modes. Then
> a window showing a buffer in the same mode as the buffer we want to
> display should maybe given preference to a window showing a buffer in
> another mode, derived from the same parent mode. If a same-mode-window
> exists on another and a derived-mode-window exists on the selected
> frame, one of these should be given preference consistently.
Well, it took a bit of time but here I am ! Could you please review the
following patch ?
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-new-function-display-buffer-reuse-mode-window.patch --]
[-- Type: text/x-diff, Size: 5198 bytes --]
From 1623ed372ffce726c4f5b20ca2f333a9e5ba6f92 Mon Sep 17 00:00:00 2001
From: Nicolas Richard <youngfrog@members.fsf.org>
Date: Tue, 1 Mar 2016 12:33:05 +0100
Subject: [PATCH] Add new function display-buffer-reuse-mode-window
* lisp/window.el (display-buffer-reuse-mode-window): New function.
* doc/lispref/windows.texi (Display Action Functions): Document it.
---
doc/lispref/windows.texi | 17 ++++++++++++
lisp/window.el | 68 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 85 insertions(+)
diff --git a/doc/lispref/windows.texi b/doc/lispref/windows.texi
index 7186791..c52bf0e 100644
--- a/doc/lispref/windows.texi
+++ b/doc/lispref/windows.texi
@@ -2395,6 +2395,23 @@ Display Action Functions
entry (@pxref{Choosing Window Options}), raises that frame if necessary.
@end defun
+@defun display-buffer-reuse-mode-window buffer alist
+This function tries to display @var{buffer} by finding a window
+that is displaying a buffer in a given mode.
+
+If @var{alist} contains a @code{mode} entry, its value is a major mode
+(a symbol) or a list of major modes. If @var{alist} contains no
+@code{mode} entry, the current major mode of @var{buffer} is used. A
+window is a candidate if it displays a buffer that derives from one of
+the given modes.
+
+The behaviour is also controlled by entries for
+@code{inhibit-same-window}, @code{reusable-frames} and
+@code{inhibit-switch-frame} as is done in the function
+@code{display-buffer-reuse-window}.
+
+@end defun
+
@defun display-buffer-pop-up-frame buffer alist
This function creates a new frame, and displays the buffer in that
frame's window. It actually performs the frame creation by calling
diff --git a/lisp/window.el b/lisp/window.el
index 620f4ed..4586994 100644
--- a/lisp/window.el
+++ b/lisp/window.el
@@ -6721,6 +6721,74 @@ display-buffer-reuse-window
(unless (cdr (assq 'inhibit-switch-frame alist))
(window--maybe-raise-frame (window-frame window)))))))
+(defun display-buffer-reuse-mode-window (buffer alist)
+ "Return a window based on the mode of the buffer it displays.
+Display BUFFER in the returned window. Return nil if no usable
+window is found.
+
+If ALIST contains a `mode' entry, its value is a major mode (a
+symbol) or a list of modes. A window is a candidate if it
+displays a buffer that derives from one of the given modes. When
+ALIST contains no `mode' entry, the current major mode of BUFFER
+is used.
+
+The behaviour is also controlled by entries for
+`inhibit-same-window', `reusable-frames' and
+`inhibit-switch-frame' as is done in the function
+`display-buffer-reuse-window'."
+ (let* ((alist-entry (assq 'reusable-frames alist))
+ (alist-mode-entry (assq 'mode alist))
+ (frames (cond (alist-entry (cdr alist-entry))
+ ((if (eq pop-up-frames 'graphic-only)
+ (display-graphic-p)
+ pop-up-frames)
+ 0)
+ (display-buffer-reuse-frames 0)
+ (t (last-nonminibuffer-frame))))
+ (inhibit-same-window-p (cdr (assq 'inhibit-same-window alist)))
+ (windows (window-list-1 nil 'nomini frames))
+ (buffer-mode (with-current-buffer buffer major-mode))
+ (allowed-modes (if alist-mode-entry
+ (cdr alist-mode-entry)
+ buffer-mode))
+ (curwin (selected-window))
+ (curframe (selected-frame)))
+ (unless (listp allowed-modes)
+ (setq allowed-modes (list allowed-modes)))
+ (let (same-mode-same-frame
+ same-mode-other-frame
+ derived-mode-same-frame
+ derived-mode-other-frame)
+ (dolist (window windows)
+ (let ((window-mode (with-current-buffer
+ (window-buffer window)
+ major-mode))
+ mode? frame?)
+ (setq mode?
+ (cond ((memq window-mode allowed-modes)
+ 'same)
+ ((let ((major-mode window-mode))
+ (derived-mode-p allowed-modes))
+ 'derived)))
+ (when (and mode?
+ (not (and inhibit-same-window-p
+ (eq window curwin))))
+ (if (eq curframe (window-frame window))
+ (if (eq mode? 'same)
+ (push window same-mode-same-frame)
+ (push window derived-mode-same-frame))
+ (if (eq mode? 'same)
+ (push window same-mode-other-frame)
+ (push window derived-mode-other-frame))))))
+ (let ((window (first (nconc same-mode-same-frame
+ same-mode-other-frame
+ derived-mode-same-frame
+ derived-mode-other-frame))))
+ (when (window-live-p window)
+ (prog1 (window--display-buffer buffer window 'reuse alist)
+ (unless (cdr (assq 'inhibit-switch-frame alist))
+ (window--maybe-raise-frame (window-frame window)))))))))
+
(defun display-buffer--special-action (buffer)
"Return special display action for BUFFER, if any.
If `special-display-p' returns non-nil for BUFFER, return an
--
2.4.5
[-- Attachment #3: Type: text/plain, Size: 14 bytes --]
--
Nicolas.
^ permalink raw reply related [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
2016-03-01 15:49 ` Nicolas Richard
@ 2016-03-01 17:04 ` martin rudalics
2016-03-10 9:55 ` Nicolas Richard
0 siblings, 1 reply; 16+ messages in thread
From: martin rudalics @ 2016-03-01 17:04 UTC (permalink / raw)
To: Nicolas Richard; +Cc: 21649@debbugs.gnu.org
> Well, it took a bit of time but here I am ! Could you please review the
> following patch ?
Thanks for the patch!
+(defun display-buffer-reuse-mode-window (buffer alist)
+ "Return a window based on the mode of the buffer it displays.
+Display BUFFER in the returned window. Return nil if no usable
^
+window is found.
+
+If ALIST contains a `mode' entry, its value is a major mode (a
+symbol) or a list of modes. A window is a candidate if it
+displays a buffer that derives from one of the given modes. When
^
+ALIST contains no `mode' entry, the current major mode of BUFFER
+is used.
Please consistently use two spaces after each sentence in doc-strings,
comments etc.
+ (dolist (window windows)
+ (let ((window-mode (with-current-buffer
+ (window-buffer window)
+ major-mode))
+ mode? frame?)
+ (setq mode?
+ (cond ((memq window-mode allowed-modes)
+ 'same)
+ ((let ((major-mode window-mode))
+ (derived-mode-p allowed-modes))
+ 'derived)))
It's not nice to bind a buffer-local variable like ‘major-mode’ in a
completely unrelated buffer just for calling ‘derived-mode-p’. Please
do that either within the ‘with-current-buffer’ form above, somehow like
(dolist (window windows)
(let (window-mode window-derived-mode mode? frame?)
(with-current-buffer (window-buffer window)
(setq window-mode major-mode)
(setq window-derived-mode (derived-mode-p allowed-modes)))
(setq mode?
(cond ((memq window-mode allowed-modes)
'same)
(window-derived-mode
'derived)))
or simply write
((with-current-buffer (window-buffer window))
(derived-mode-p allowed-modes))
'derived)))
instead.
+ (let ((window (first (nconc same-mode-same-frame
This gets me
In end of data:
window.el:8617:1:Warning: the function ‘first’ is not known to be defined.
here.
Thanks again, martin
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
2016-03-01 17:04 ` martin rudalics
@ 2016-03-10 9:55 ` Nicolas Richard
2016-03-10 10:32 ` martin rudalics
0 siblings, 1 reply; 16+ messages in thread
From: Nicolas Richard @ 2016-03-10 9:55 UTC (permalink / raw)
To: martin rudalics; +Cc: 21649-done
Thanks for your review, martin. I pushed the modified commit to master
as 2d382515bfdb44d585bda6515f8d03f9056a83ef.
I'm marking this bug as done since one can now do
(setq display-buffer-alist
(list
(cons "\\`\\*Man .*\\*\\'"
(cons
#'display-buffer-reuse-mode-window
'((inhibit-same-window . nil))))))
to get the effect mentionned in the initial report.
--
Nicolas.
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
2016-03-10 9:55 ` Nicolas Richard
@ 2016-03-10 10:32 ` martin rudalics
2016-03-10 13:49 ` Nicolas Richard
0 siblings, 1 reply; 16+ messages in thread
From: martin rudalics @ 2016-03-10 10:32 UTC (permalink / raw)
To: Nicolas Richard; +Cc: 21649-done
> I'm marking this bug as done since one can now do
> (setq display-buffer-alist
> (list
> (cons "\\`\\*Man .*\\*\\'"
> (cons
> #'display-buffer-reuse-mode-window
> '((inhibit-same-window . nil))))))
> to get the effect mentionned in the initial report.
Please add a NEWS entry for this.
Thanks, martin
^ permalink raw reply [flat|nested] 16+ messages in thread
* bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window
2016-03-10 10:32 ` martin rudalics
@ 2016-03-10 13:49 ` Nicolas Richard
0 siblings, 0 replies; 16+ messages in thread
From: Nicolas Richard @ 2016-03-10 13:49 UTC (permalink / raw)
To: martin rudalics; +Cc: 21649-done
martin rudalics <rudalics@gmx.at> writes:
> Please add a NEWS entry for this.
Sure. Done.
Nicolas.
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2016-03-10 13:49 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-08 15:54 bug#21649: 25.0.50; [PATCH] Allow M-x man to reuse an existing window Nicolas Richard
2015-10-09 14:37 ` Kaushal Modi
[not found] ` <86r3l09t3u.fsf@members.fsf.org>
2015-10-12 15:06 ` Kaushal Modi
2015-10-13 22:10 ` Nicolas Richard
2015-10-13 22:19 ` Kaushal Modi
2015-10-14 8:49 ` martin rudalics
[not found] ` <86wpufc8n8.fsf@members.fsf.org>
2015-10-22 15:34 ` martin rudalics
2015-10-22 19:21 ` Nicolas Richard
2015-10-23 8:01 ` martin rudalics
2016-03-01 15:49 ` Nicolas Richard
2016-03-01 17:04 ` martin rudalics
2016-03-10 9:55 ` Nicolas Richard
2016-03-10 10:32 ` martin rudalics
2016-03-10 13:49 ` Nicolas Richard
2015-10-27 11:30 ` Nicolas Richard
2015-10-28 9:55 ` martin rudalics
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.