* 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
[parent not found: <86r3l09t3u.fsf@members.fsf.org>]
* 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
[parent not found: <86wpufc8n8.fsf@members.fsf.org>]
* 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-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
* 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
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 public inbox https://git.savannah.gnu.org/cgit/emacs.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).