GNU bug report logs -
#21649
25.0.50; [PATCH] Allow M-x man to reuse an existing window
Previous Next
Reported by: Nicolas Richard <youngfrog <at> members.fsf.org>
Date: Thu, 8 Oct 2015 15:56:01 UTC
Severity: wishlist
Tags: patch
Found in version 25.0.50
Done: Nicolas Richard <youngfrog <at> members.fsf.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21649 in the body.
You can then email your comments to 21649 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Thu, 08 Oct 2015 15:56:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Nicolas Richard <youngfrog <at> members.fsf.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 08 Oct 2015 15:56:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.)
[0001-Allow-M-x-man-to-reuse-an-existing-window.patch (text/x-diff, inline)]
From 2b812b1c9f91af2cf6116f1d4e334154ae44c724 Mon Sep 17 00:00:00 2001
From: Nicolas Richard <youngfrog <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Fri, 09 Oct 2015 14:38:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 21649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
)
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Mon, 12 Oct 2015 15:07:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 21649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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 <at> 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
> )
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Tue, 13 Oct 2015 22:11:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 21649 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Tue, 13 Oct 2015 22:21:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 21649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 <at> 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.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Wed, 14 Oct 2015 08:51:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 21649 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Thu, 22 Oct 2015 15:35:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 21649 <at> debbugs.gnu.org (full text, mbox):
> 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 <at> debbugs.gnu.org from the list of recipients!
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Thu, 22 Oct 2015 19:22:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 21649 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> 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 <at> debbugs.gnu.org from the list of recipients!
That was not intended. I probably hit R instead of F, sorry about that.
Nico.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Fri, 23 Oct 2015 08:03:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 21649 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Tue, 27 Oct 2015 11:32:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 21649 <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Wed, 28 Oct 2015 09:56:03 GMT)
Full text and
rfc822 format available.
Message #35 received at 21649 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Tue, 01 Mar 2016 15:50:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 21649 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
martin rudalics <rudalics <at> 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 ?
[0001-Add-new-function-display-buffer-reuse-mode-window.patch (text/x-diff, inline)]
From 1623ed372ffce726c4f5b20ca2f333a9e5ba6f92 Mon Sep 17 00:00:00 2001
From: Nicolas Richard <youngfrog <at> 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
[Message part 3 (text/plain, inline)]
--
Nicolas.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Tue, 01 Mar 2016 17:05:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 21649 <at> debbugs.gnu.org (full text, mbox):
> 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
Reply sent
to
Nicolas Richard <youngfrog <at> members.fsf.org>:
You have taken responsibility.
(Thu, 10 Mar 2016 09:57:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Nicolas Richard <youngfrog <at> members.fsf.org>:
bug acknowledged by developer.
(Thu, 10 Mar 2016 09:57:02 GMT)
Full text and
rfc822 format available.
Message #46 received at 21649-done <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Thu, 10 Mar 2016 10:34:02 GMT)
Full text and
rfc822 format available.
Message #49 received at 21649-done <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21649; Package
emacs.
(Thu, 10 Mar 2016 13:51:01 GMT)
Full text and
rfc822 format available.
Message #52 received at 21649-done <at> debbugs.gnu.org (full text, mbox):
martin rudalics <rudalics <at> gmx.at> writes:
> Please add a NEWS entry for this.
Sure. Done.
Nicolas.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 08 Apr 2016 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 75 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.