* bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed
@ 2015-03-06 19:15 Drew Adams
2019-10-09 2:12 ` Lars Ingebrigtsen
0 siblings, 1 reply; 12+ messages in thread
From: Drew Adams @ 2015-03-06 19:15 UTC (permalink / raw)
To: 20020
In my case, Info buffers (*info* and *info<N>*) are in dedicated
windows. I expect `info-display-manual' to select such an existing
window. That is, if the Calc manual is already displayed in an Info
buffer and I use `M-x info-display-manual' from some other buffer, I
expect the existing window showing that manual to be selected (and its
frame raised and focused, if necessary).
Instead, `info-display-manual' displays the manual in the same window
where I invoke it, resulting in two windows (and frames in my case)
showing the same Info manual.
In GNU Emacs 25.0.50.1 (i686-pc-mingw32)
of 2015-02-27 on LEG570
Bzr revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --host=i686-pc-mingw32 --enable-checking=yes,glyphs'
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed
2015-03-06 19:15 bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed Drew Adams
@ 2019-10-09 2:12 ` Lars Ingebrigtsen
2019-10-09 16:54 ` Eli Zaretskii
2019-10-09 20:38 ` Juri Linkov
0 siblings, 2 replies; 12+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-09 2:12 UTC (permalink / raw)
To: Drew Adams; +Cc: 20020
Drew Adams <drew.adams@oracle.com> writes:
> In my case, Info buffers (*info* and *info<N>*) are in dedicated
> windows. I expect `info-display-manual' to select such an existing
> window. That is, if the Calc manual is already displayed in an Info
> buffer and I use `M-x info-display-manual' from some other buffer, I
> expect the existing window showing that manual to be selected (and its
> frame raised and focused, if necessary).
>
> Instead, `info-display-manual' displays the manual in the same window
> where I invoke it, resulting in two windows (and frames in my case)
> showing the same Info manual.
Makes sense. I've now done this in Emacs 27, but while writing the
code, it struck me that there has to be a ready-made function for this
somewhere already. I had a peek through the plethora of
switch-to/pop-to functions, but I didn't find anything that did exactly
this...
Does anybody know? In short: If there's a window that has the buffer,
then that window should be selected, and its frame popped to the top
(and given focus). If not, it should work like `switch-to-buffer'.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed
2019-10-09 2:12 ` Lars Ingebrigtsen
@ 2019-10-09 16:54 ` Eli Zaretskii
2019-10-09 17:51 ` Lars Ingebrigtsen
2019-10-09 20:38 ` Juri Linkov
1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2019-10-09 16:54 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 20020
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Wed, 09 Oct 2019 04:12:52 +0200
> Cc: 20020@debbugs.gnu.org
>
> Drew Adams <drew.adams@oracle.com> writes:
>
> > In my case, Info buffers (*info* and *info<N>*) are in dedicated
> > windows. I expect `info-display-manual' to select such an existing
> > window. That is, if the Calc manual is already displayed in an Info
> > buffer and I use `M-x info-display-manual' from some other buffer, I
> > expect the existing window showing that manual to be selected (and its
> > frame raised and focused, if necessary).
> >
> > Instead, `info-display-manual' displays the manual in the same window
> > where I invoke it, resulting in two windows (and frames in my case)
> > showing the same Info manual.
>
> Makes sense. I've now done this in Emacs 27, but while writing the
> code, it struck me that there has to be a ready-made function for this
> somewhere already. I had a peek through the plethora of
> switch-to/pop-to functions, but I didn't find anything that did exactly
> this...
>
> Does anybody know?
I don't really understand what you did and what was the original
problem, because info-display-manual already behaves for me like the
OP wanted. It has behaved like that from day one, because I wrote it
to do so. It only displays in *info* if there's not already an
*info*<N> buffer showing the requested manual (and in my Emacs
sessions, I never have *info* for long, I either kill it or rename to
*info*<N>.
Maybe the problem is that the OP did this in dedicated windows?
That's the only factor I could think of that is different from what I
do.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed
2019-10-09 16:54 ` Eli Zaretskii
@ 2019-10-09 17:51 ` Lars Ingebrigtsen
2019-10-09 18:08 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-09 17:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 20020
Eli Zaretskii <eliz@gnu.org> writes:
> I don't really understand what you did and what was the original
> problem, because info-display-manual already behaves for me like the
> OP wanted. It has behaved like that from day one, because I wrote it
> to do so. It only displays in *info* if there's not already an
> *info*<N> buffer showing the requested manual (and in my Emacs
> sessions, I never have *info* for long, I either kill it or rename to
> *info*<N>.
Yes, it reuses the buffer. But the bug report is about window
behaviour.
> Maybe the problem is that the OP did this in dedicated windows?
> That's the only factor I could think of that is different from what I
> do.
Try this in Emacs 26:
M-: (info-display-manual "Coreutils")
C-x 2
C-x b *scratch*
M-: (info-display-manual "Coreutils")
You'll now have two windows displaying the same Info buffer, and that
was what the user didn't want (and I agree that it's not optimal
behaviour). In the user's case, it was exacerbated by having the window
displayed in a different frame, but that's just a detail.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed
2019-10-09 17:51 ` Lars Ingebrigtsen
@ 2019-10-09 18:08 ` Eli Zaretskii
2019-10-11 8:07 ` Lars Ingebrigtsen
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2019-10-09 18:08 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 20020
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: drew.adams@oracle.com, 20020@debbugs.gnu.org
> Date: Wed, 09 Oct 2019 19:51:29 +0200
>
> M-: (info-display-manual "Coreutils")
> C-x 2
> C-x b *scratch*
> M-: (info-display-manual "Coreutils")
>
> You'll now have two windows displaying the same Info buffer, and that
> was what the user didn't want (and I agree that it's not optimal
> behaviour). In the user's case, it was exacerbated by having the window
> displayed in a different frame, but that's just a detail.
If this is the change, then I think it should be an opt-in change. We
don't behave like that with any other buffers, why should Info buffers
be an exception by default?
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed
2019-10-09 18:08 ` Eli Zaretskii
@ 2019-10-11 8:07 ` Lars Ingebrigtsen
2019-10-11 9:18 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-11 8:07 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 20020
Eli Zaretskii <eliz@gnu.org> writes:
> If this is the change, then I think it should be an opt-in change. We
> don't behave like that with any other buffers, why should Info buffers
> be an exception by default?
That's true. Off the top of my head, I can't recall any other commands
that work this way, so it's odd for `info-display-manual' to do so.
Should I just revert the change?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed
2019-10-11 8:07 ` Lars Ingebrigtsen
@ 2019-10-11 9:18 ` Eli Zaretskii
2019-10-13 18:22 ` Lars Ingebrigtsen
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2019-10-11 9:18 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 20020
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: drew.adams@oracle.com, 20020@debbugs.gnu.org
> Date: Fri, 11 Oct 2019 10:07:30 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > If this is the change, then I think it should be an opt-in change. We
> > don't behave like that with any other buffers, why should Info buffers
> > be an exception by default?
>
> That's true. Off the top of my head, I can't recall any other commands
> that work this way, so it's odd for `info-display-manual' to do so.
>
> Should I just revert the change?
It'd be fine with me, but probably not with Drew. having an opt-in
defcustom is a good compromise, I think.
Thanks.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed
2019-10-11 9:18 ` Eli Zaretskii
@ 2019-10-13 18:22 ` Lars Ingebrigtsen
0 siblings, 0 replies; 12+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-13 18:22 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 20020
Eli Zaretskii <eliz@gnu.org> writes:
>> > If this is the change, then I think it should be an opt-in change. We
>> > don't behave like that with any other buffers, why should Info buffers
>> > be an exception by default?
>>
>> That's true. Off the top of my head, I can't recall any other commands
>> that work this way, so it's odd for `info-display-manual' to do so.
>>
>> Should I just revert the change?
>
> It'd be fine with me, but probably not with Drew. having an opt-in
> defcustom is a good compromise, I think.
I don't know much about how dedicated windows work, but couldn't Drew
set that up to have Emacs pop up that window instead of having special
code for this in `info-display-manual'? I had forgotten about that when
I wrote the patch.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed
2019-10-09 2:12 ` Lars Ingebrigtsen
2019-10-09 16:54 ` Eli Zaretskii
@ 2019-10-09 20:38 ` Juri Linkov
2019-10-10 9:16 ` martin rudalics
1 sibling, 1 reply; 12+ messages in thread
From: Juri Linkov @ 2019-10-09 20:38 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 20020
>> In my case, Info buffers (*info* and *info<N>*) are in dedicated
>> windows. I expect `info-display-manual' to select such an existing
>> window. That is, if the Calc manual is already displayed in an Info
>> buffer and I use `M-x info-display-manual' from some other buffer, I
>> expect the existing window showing that manual to be selected (and its
>> frame raised and focused, if necessary).
>>
>> Instead, `info-display-manual' displays the manual in the same window
>> where I invoke it, resulting in two windows (and frames in my case)
>> showing the same Info manual.
>
> Makes sense. I've now done this in Emacs 27, but while writing the
> code, it struck me that there has to be a ready-made function for this
> somewhere already. I had a peek through the plethora of
> switch-to/pop-to functions, but I didn't find anything that did exactly
> this...
>
> Does anybody know? In short: If there's a window that has the buffer,
> then that window should be selected, and its frame popped to the top
> (and given focus). If not, it should work like `switch-to-buffer'.
I'm not sure, maybe Martin could confirm this, but very likely
you can use display-buffer-reuse-window here.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed
2019-10-09 20:38 ` Juri Linkov
@ 2019-10-10 9:16 ` martin rudalics
2019-10-11 8:09 ` Lars Ingebrigtsen
0 siblings, 1 reply; 12+ messages in thread
From: martin rudalics @ 2019-10-10 9:16 UTC (permalink / raw)
To: Juri Linkov, Lars Ingebrigtsen; +Cc: 20020
>> Does anybody know? In short: If there's a window that has the buffer,
>> then that window should be selected, and its frame popped to the top
>> (and given focus). If not, it should work like `switch-to-buffer'.
>
> I'm not sure, maybe Martin could confirm this, but very likely
> you can use display-buffer-reuse-window here.
The basic ingredient is a suitable 'reusable-frames' ALIST entry which
should specify the frames on which to search for such a window. Apart
from that, plain 'pop-to-buffer' should work.
martin
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed
2019-10-10 9:16 ` martin rudalics
@ 2019-10-11 8:09 ` Lars Ingebrigtsen
2019-10-11 8:26 ` martin rudalics
0 siblings, 1 reply; 12+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-11 8:09 UTC (permalink / raw)
To: martin rudalics; +Cc: 20020, Juri Linkov
martin rudalics <rudalics@gmx.at> writes:
> The basic ingredient is a suitable 'reusable-frames' ALIST entry which
> should specify the frames on which to search for such a window. Apart
> from that, plain 'pop-to-buffer' should work.
Or perhaps `pop-to-buffer-same-window', since the command uses
`switch-to-window' presently?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed
2019-10-11 8:09 ` Lars Ingebrigtsen
@ 2019-10-11 8:26 ` martin rudalics
0 siblings, 0 replies; 12+ messages in thread
From: martin rudalics @ 2019-10-11 8:26 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 20020, Juri Linkov
> Or perhaps `pop-to-buffer-same-window', since the command uses
> `switch-to-window' presently?
If I'm not mistaken, this would prefer the selected window to a window
on another frame. So probably use 'display-buffer-reuse-window' as
first choice and 'display-buffer-same-window' as second choice. With
a suitable 'reusable-frames' and an 'inhibit-same-window' nil alist
entries.
martin
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-10-13 18:22 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-06 19:15 bug#20020: 25.0.50; `info-display-manual' should reuse existing window where buffer is displayed Drew Adams
2019-10-09 2:12 ` Lars Ingebrigtsen
2019-10-09 16:54 ` Eli Zaretskii
2019-10-09 17:51 ` Lars Ingebrigtsen
2019-10-09 18:08 ` Eli Zaretskii
2019-10-11 8:07 ` Lars Ingebrigtsen
2019-10-11 9:18 ` Eli Zaretskii
2019-10-13 18:22 ` Lars Ingebrigtsen
2019-10-09 20:38 ` Juri Linkov
2019-10-10 9:16 ` martin rudalics
2019-10-11 8:09 ` Lars Ingebrigtsen
2019-10-11 8:26 ` 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).