Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[zhang cc]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

1. start emacs with “emacs -Q”
2. eval the following form:
(progn
  (setq ddd-tm (current-time))
  (switch-to-buffer-other-window "*Messages*")
  (message "ddd: %ss"  (float-time (time-subtract (current-time) ddd-tm))))

The result is lager than 0.1s on my machine. This makes undo-tree running too slowly, because it calls switch-to-buffer-other-window twice per undo.

The emacs 25 has no such problem.

OS: Centos 7.4 x86_64
Emacs: 26.0.91
GTK version: 2.24.31


[-- Attachment #2: Type: text/html, Size: 1144 bytes --]

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Eli Zaretskii]

> From: zhang cc <ccsmile2008@outlook.com>
> Date: Mon, 26 Mar 2018 10:12:33 +0000
> 
> 1. start emacs with “emacs -Q” 
> 2. eval the following form:
> (progn
>   (setq ddd-tm (current-time))
>   (switch-to-buffer-other-window "*Messages*")
>   (message "ddd: %ss"  (float-time (time-subtract (current-time) ddd-tm))))
> 
> The result is lager than 0.1s on my machine. This makes undo-tree running too slowly, because it calls
> switch-to-buffer-other-window twice per undo.

I cannot reproduce this.  I get zero seconds.

Does this happen in "emacs -Q -nw"?

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[zhang cc]

[-- Attachment #1: Type: text/plain, Size: 208 bytes --]


On 26 Mar 2018, 11:16 PM +0800, Eli Zaretskii <eliz@gnu.org>, wrote:

I cannot reproduce this. I get zero seconds.

Does this happen in "emacs -Q -nw”?

No. It doesn’t happen in “emacs -nw”.

[-- Attachment #2: Type: text/html, Size: 701 bytes --]

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[zhang cc]

[-- Attachment #1: Type: text/plain, Size: 331 bytes --]


On 26 Mar 2018, 11:22 PM +0800, HaiJun zhang <ccsmile2008@outlook.com>, wrote:

On 26 Mar 2018, 11:16 PM +0800, Eli Zaretskii <eliz@gnu.org>, wrote:

I cannot reproduce this. I get zero seconds.

Does this happen in "emacs -Q -nw”?

No. It doesn’t happen in “emacs -nw”.

And also doesn’t happen on macOS.


[-- Attachment #2: Type: text/html, Size: 1393 bytes --]

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Eli Zaretskii]

> From: zhang cc <ccsmile2008@outlook.com>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Mon, 26 Mar 2018 15:25:55 +0000
> 
> On 26 Mar 2018, 11:22 PM +0800, HaiJun zhang <ccsmile2008@outlook.com>, wrote:
> 
>  On 26 Mar 2018, 11:16 PM +0800, Eli Zaretskii <eliz@gnu.org>, wrote:
> 
>  I cannot reproduce this. I get zero seconds.
> 
>  Does this happen in "emacs -Q -nw”? 
> 
>  No. It doesn’t happen in “emacs -nw”. 
> 
> And also doesn’t happen on macOS.

So maybe it's GTK-specific?  Or specific to something local to your
system?

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: zhang cc <ccsmile2008@outlook.com>
>> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>> Date: Mon, 26 Mar 2018 15:25:55 +0000
>> 
>> On 26 Mar 2018, 11:22 PM +0800, HaiJun zhang <ccsmile2008@outlook.com>, wrote:
>> 
>>  On 26 Mar 2018, 11:16 PM +0800, Eli Zaretskii <eliz@gnu.org>, wrote:
>> 
>>  I cannot reproduce this. I get zero seconds.
>> 
>>  Does this happen in "emacs -Q -nw”? 
>> 
>>  No. It doesn’t happen in “emacs -nw”. 
>> 
>> And also doesn’t happen on macOS.
>
> So maybe it's GTK-specific?  Or specific to something local to your
> system?

I get the same: 0.1 seconds under GTK, 0.000446348s under -nw

Robert

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Clément Pit-Claudel]

On 2018-03-26 12:09, Robert Pluim wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
>>> From: zhang cc <ccsmile2008@outlook.com>
>>> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>>> Date: Mon, 26 Mar 2018 15:25:55 +0000
>>>
>>> On 26 Mar 2018, 11:22 PM +0800, HaiJun zhang <ccsmile2008@outlook.com>, wrote:
>>>
>>>  On 26 Mar 2018, 11:16 PM +0800, Eli Zaretskii <eliz@gnu.org>, wrote:
>>>
>>>  I cannot reproduce this. I get zero seconds.
>>>
>>>  Does this happen in "emacs -Q -nw”? 
>>>
>>>  No. It doesn’t happen in “emacs -nw”. 
>>>
>>> And also doesn’t happen on macOS.
>>
>> So maybe it's GTK-specific?  Or specific to something local to your
>> system?
> 
> I get the same: 0.1 seconds under GTK, 0.000446348s under -nw

ddd: 0.10295418s here on GTK.

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Robert Pluim]

Robert Pluim <rpluim@gmail.com> writes:

> I get the same: 0.1 seconds under GTK, 0.000446348s under -nw

And profiling pointed at window--maybe-raise-frame. Testing then
pointed at make-frame-visible. Disabling the call to that in
window--maybe-raise-frame makes the test virtually instantaneous for
me. Looks like x_make_frame_visible is the culprit.

Robert

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Noam Postavsky]

On 26 March 2018 at 12:34, Robert Pluim <rpluim@gmail.com> wrote:
> Robert Pluim <rpluim@gmail.com> writes:
>
>> I get the same: 0.1 seconds under GTK, 0.000446348s under -nw
>
> And profiling pointed at window--maybe-raise-frame. Testing then
> pointed at make-frame-visible. Disabling the call to that in
> window--maybe-raise-frame makes the test virtually instantaneous for
> me. Looks like x_make_frame_visible is the culprit.

Does changing x-wait-for-event-timeout affect this?

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Robert Pluim]

Noam Postavsky <npostavs@gmail.com> writes:

> On 26 March 2018 at 12:34, Robert Pluim <rpluim@gmail.com> wrote:
>> Robert Pluim <rpluim@gmail.com> writes:
>>
>>> I get the same: 0.1 seconds under GTK, 0.000446348s under -nw
>>
>> And profiling pointed at window--maybe-raise-frame. Testing then
>> pointed at make-frame-visible. Disabling the call to that in
>> window--maybe-raise-frame makes the test virtually instantaneous for
>> me. Looks like x_make_frame_visible is the culprit.
>
> Does changing x-wait-for-event-timeout affect this?

Yes. 0.001990967s with that let-bound to nil. The time increases as I increase
x-wait-for-event-timeout.

Robert

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Date: Mon, 26 Mar 2018 18:59:06 +0200
> Cc: zhang cc <ccsmile2008@outlook.com>, Emacs developers <emacs-devel@gnu.org>
> 
> Noam Postavsky <npostavs@gmail.com> writes:
> 
> > On 26 March 2018 at 12:34, Robert Pluim <rpluim@gmail.com> wrote:
> >> Robert Pluim <rpluim@gmail.com> writes:
> >>
> >>> I get the same: 0.1 seconds under GTK, 0.000446348s under -nw
> >>
> >> And profiling pointed at window--maybe-raise-frame. Testing then
> >> pointed at make-frame-visible. Disabling the call to that in
> >> window--maybe-raise-frame makes the test virtually instantaneous for
> >> me. Looks like x_make_frame_visible is the culprit.
> >
> > Does changing x-wait-for-event-timeout affect this?
> 
> Yes. 0.001990967s with that let-bound to nil. The time increases as I increase
> x-wait-for-event-timeout.

Right.  Then I guess this is expected, and users who are annoyed by
the additional 100 msec on the one hand, and see no adverse effects
when it is nil OTOH, should do that, and be done.

IOW, the default is sub-optimal, but safe, and we couldn't find a
better solution at the time.

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Stefan Monnier]

> Right.  Then I guess this is expected, and users who are annoyed by

Is it, really?  Even tho we're just switching from one window to another
in the same frame?


        Stefan

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 26 Mar 2018 13:49:54 -0400
> 
> > Right.  Then I guess this is expected, and users who are annoyed by
> 
> Is it, really?  Even tho we're just switching from one window to another
> in the same frame?

If you can change x_make_frame_visible to not wait for MapNotify event
in this case, or if you can avoid calling make-frame-visible in
window--maybe-raise-frame, then maybe we could avoid that.  But such
changes are not for Emacs 26.1 anymore.

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Stefan Monnier]

> If you can change x_make_frame_visible to not wait for MapNotify event
> in this case, or if you can avoid calling make-frame-visible in
> window--maybe-raise-frame, then maybe we could avoid that.  But such
> changes are not for Emacs 26.1 anymore.

I'm definitely not talking about 26.1, indeed.

But I think in the case where we move from window A to window B and both
are on the same frame we should either not call
window--maybe-raise-frame or else that function should do nothing in
that case.  Basically, I feel like if the movement is intra-frame than
no frame-level operations should be involved.


        Stefan

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: emacs-devel@gnu.org
> Date: Mon, 26 Mar 2018 14:26:46 -0400
> 
> But I think in the case where we move from window A to window B and both
> are on the same frame we should either not call
> window--maybe-raise-frame or else that function should do nothing in
> that case.  Basically, I feel like if the movement is intra-frame than
> no frame-level operations should be involved.

I actually don't understand why we wait for MapNotify inside
x_make_frame_visible when the frame was already visible.  And the fact
that it takes almost exactly 100 msec tells me that we never get the
event anyway.  I'm not an expert on X events -- do we even need to
wait in this case?

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Stefan Monnier]

> I actually don't understand why we wait for MapNotify inside
> x_make_frame_visible when the frame was already visible.

Indeed!


        Stefan

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[martin rudalics]

 > But I think in the case where we move from window A to window B and both
 > are on the same frame we should either not call
 > window--maybe-raise-frame or else that function should do nothing in
 > that case.  Basically, I feel like if the movement is intra-frame than
 > no frame-level operations should be involved.

There's no guarantee that the selected frame is visible at the time
`display-buffer' is called.  And my GTK Emacs notoriously lies about
the visibility of frames anyway.

martin

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Eli Zaretskii]

> Date: Mon, 26 Mar 2018 20:46:57 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: emacs-devel@gnu.org
> 
> And my GTK Emacs notoriously lies about the visibility of frames
> anyway.

You mean, FRAME_VISIBLE_P is not reliable in your GTK Emacs?

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[martin rudalics]

 > You mean, FRAME_VISIBLE_P is not reliable in your GTK Emacs?

Yes.  See also the thread starting here:

https://lists.nongnu.org/archive/html/emacs-devel/2017-02/msg00133.html

martin

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Eli Zaretskii]

> Date: Mon, 26 Mar 2018 21:16:52 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> 
>  > You mean, FRAME_VISIBLE_P is not reliable in your GTK Emacs?
> 
> Yes.  See also the thread starting here:
> 
> https://lists.nongnu.org/archive/html/emacs-devel/2017-02/msg00133.html

For the purposes of this discussion, I'll settle with a subset of my
question, viz.: when FRAME_VISIBLE_P returns non-zero, is it possible
that the frame is in fact not visible?

If a non-zero value of FRAME_VISIBLE_P reliably tells us that the
frame is visible, then we can avoid waiting for MapNotify when
FRAME_VISIBLE_P returns non-zero at entry into x_make_frame_visible.
(This is what the original code circa Emacs 21 did, AFAIR.)

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[martin rudalics]

 > For the purposes of this discussion, I'll settle with a subset of my
 > question, viz.: when FRAME_VISIBLE_P returns non-zero, is it possible
 > that the frame is in fact not visible?
 >
 > If a non-zero value of FRAME_VISIBLE_P reliably tells us that the
 > frame is visible, then we can avoid waiting for MapNotify when
 > FRAME_VISIBLE_P returns non-zero at entry into x_make_frame_visible.
 > (This is what the original code circa Emacs 21 did, AFAIR.)

I mentioned my concerns because I obviously had the same idea.  My
answer is simple: I think it's possible that FRAME_VISIBLE_P lies and
we should disregard that.  If it lies, it's a good occasion to find
out and think of a fix for Emacs 27.

And obviously I have no good ideas for Emacs 26.

martin

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Eli Zaretskii]

> Date: Mon, 26 Mar 2018 23:41:57 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> 
>  > For the purposes of this discussion, I'll settle with a subset of my
>  > question, viz.: when FRAME_VISIBLE_P returns non-zero, is it possible
>  > that the frame is in fact not visible?
>  >
>  > If a non-zero value of FRAME_VISIBLE_P reliably tells us that the
>  > frame is visible, then we can avoid waiting for MapNotify when
>  > FRAME_VISIBLE_P returns non-zero at entry into x_make_frame_visible.
>  > (This is what the original code circa Emacs 21 did, AFAIR.)
> 
> I mentioned my concerns because I obviously had the same idea.  My
> answer is simple: I think it's possible that FRAME_VISIBLE_P lies and
> we should disregard that.  If it lies, it's a good occasion to find
> out and think of a fix for Emacs 27.
> 
> And obviously I have no good ideas for Emacs 26.

We are not talking about Emacs 26.1 in any case.

It seems to me that if FRAME_VISIBLE_P can return non-zero when a
frame is not visible, we are toast anyhow, because we have no
reasonable way of telling whether a frame is or isn't visible.
Waiting for 100 msec is not a guarantee for having the frame visible
afterwards, certainly not if we don't make sure it is so at the end of
the wait.

So I'd like to see some evidence of such grave problems, before we go
on with such a problematic assumption.

FWIW, the original wait loop did use FRAME_VISIBLE_P as an indication
of whether we need the wait at all: it would not enter the loop if
FRAME_VISIBLE_P returned non-zero.

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[martin rudalics]

 > It seems to me that if FRAME_VISIBLE_P can return non-zero when a
 > frame is not visible, we are toast anyhow, because we have no
 > reasonable way of telling whether a frame is or isn't visible.
 > Waiting for 100 msec is not a guarantee for having the frame visible
 > afterwards, certainly not if we don't make sure it is so at the end of
 > the wait.
 >
 > So I'd like to see some evidence of such grave problems, before we go
 > on with such a problematic assumption.

All I meant was that if FRAME_VISIBLE_P says that the frame is visible
we should use that and we will find out soon enough if it doesn't tell
us the truth.

 > FWIW, the original wait loop did use FRAME_VISIBLE_P as an indication
 > of whether we need the wait at all: it would not enter the loop if
 > FRAME_VISIBLE_P returned non-zero.

So x_make_frame_visible should not enter the loop when FRAME_VISIBLE_P
returns non-zero but cannot rely on FRAME_VISIBLE_P to return non-zero
in order to decide whether it's safe to leave the loop.

martin

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Eli Zaretskii]

> Date: Tue, 27 Mar 2018 09:23:47 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org
> 
>  > It seems to me that if FRAME_VISIBLE_P can return non-zero when a
>  > frame is not visible, we are toast anyhow, because we have no
>  > reasonable way of telling whether a frame is or isn't visible.
>  > Waiting for 100 msec is not a guarantee for having the frame visible
>  > afterwards, certainly not if we don't make sure it is so at the end of
>  > the wait.
>  >
>  > So I'd like to see some evidence of such grave problems, before we go
>  > on with such a problematic assumption.
> 
> All I meant was that if FRAME_VISIBLE_P says that the frame is visible
> we should use that and we will find out soon enough if it doesn't tell
> us the truth.

Yes, agreed.

Noam, would you like to push a change like that to master, please?

>  > FWIW, the original wait loop did use FRAME_VISIBLE_P as an indication
>  > of whether we need the wait at all: it would not enter the loop if
>  > FRAME_VISIBLE_P returned non-zero.
> 
> So x_make_frame_visible should not enter the loop when FRAME_VISIBLE_P
> returns non-zero but cannot rely on FRAME_VISIBLE_P to return non-zero
> in order to decide whether it's safe to leave the loop.

The original code did rely on FRAME_VISIBLE_P in both cases.  Since we
no longer process X events asynchronously, FRAME_VISIBLE_P cannot
change its value while we are inside the loop, I think.  But we do
know whether pselect that waits for MapNotify succeeded or not, if we
want/need that.

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Noam Postavsky]

On 29 March 2018 at 05:37, Eli Zaretskii <eliz@gnu.org> wrote:

>> All I meant was that if FRAME_VISIBLE_P says that the frame is visible
>> we should use that and we will find out soon enough if it doesn't tell
>> us the truth.
>
> Yes, agreed.
>
> Noam, would you like to push a change like that to master, please?

Yup, done.

[1: 2a192e21cf]: 2018-03-29 19:11:47 -0400
  Don't wait for visible frames to become visible
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=2a192e21cf3b04b7f830b4971c1508c611e13a3c

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Noam Postavsky]

On 29 March 2018 at 19:15, Noam Postavsky <npostavs@gmail.com> wrote:

> [1: 2a192e21cf]: 2018-03-29 19:11:47 -0400
>   Don't wait for visible frames to become visible
>   https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=2a192e21cf3b04b7f830b4971c1508c611e13a3c

Of course, I managed to make a mistake even in this trivial change
(test *then* push, dammit).

[00c1f771f2]: 2018-03-29 19:17:34 -0400
  * src/xterm.c (x_make_frame_visible): Fix typo in previous change.
  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=00c1f771f2a51ffa675ec5a07ea330f2605cd302

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@gmail.com>
> Date: Thu, 29 Mar 2018 19:15:02 -0400
> Cc: martin rudalics <rudalics@gmx.at>, Stefan Monnier <monnier@iro.umontreal.ca>, 
> 	Emacs developers <emacs-devel@gnu.org>, Ken Brown <kbrown@cornell.edu>
> 
> On 29 March 2018 at 05:37, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > Noam, would you like to push a change like that to master, please?
> 
> Yup, done.

Thanks.

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Stefan Monnier]

>> But I think in the case where we move from window A to window B and both
>> are on the same frame we should either not call
>> window--maybe-raise-frame or else that function should do nothing in
>> that case.  Basically, I feel like if the movement is intra-frame than
>> no frame-level operations should be involved.
> There's no guarantee that the selected frame is visible at the time
> `display-buffer' is called.

If we're already on the destination frame, then I'd argue that if that
frame is not visible it's a pre-existing condition and there's no
particular reason to "fix" it at that time.

IOW I think that in window--maybe-raise-frame

              ;; Assume the selected frame is already visible enough.
	      (eq frame (selected-frame))

should apply not just to raise-frame but also to make-frame-visible.


        Stefan

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[martin rudalics]

 > frame is not visible it's a pre-existing condition and there's no
 > particular reason to "fix" it at that time.
 >
 > IOW I think that in window--maybe-raise-frame
 >
 >                ;; Assume the selected frame is already visible enough.
 > 	      (eq frame (selected-frame))
 >
 > should apply not just to raise-frame but also to make-frame-visible.

I always carefully tried to preserve that comment.  It carries so much
of the notion that 'display-buffer' is usually called interactively.
It goes without saying that your thinking will be correct in at least
99% of all cases.

martin

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> Date: Mon, 26 Mar 2018 16:09:07 -0400
> 
> IOW I think that in window--maybe-raise-frame
> 
>               ;; Assume the selected frame is already visible enough.
> 	      (eq frame (selected-frame))
> 
> should apply not just to raise-frame but also to make-frame-visible.

Is it impossible to make , say, iconified frame the selected one?

In any case, I think the basic problem here is that with some window
managers it takes time for a frame to actually become visible on the
screen, and the waiting loop in question is meant to make sure the
frame is really visible.

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Stefan Monnier]

>> IOW I think that in window--maybe-raise-frame
>>
>>               ;; Assume the selected frame is already visible enough.
>> 	      (eq frame (selected-frame))
>>
>> should apply not just to raise-frame but also to make-frame-visible.
>
> Is it impossible to make , say, iconified frame the selected one?

No, it's very much possible and easy, but if we're in such a situation
before display-buffer is called (i.e. it was not considered a problem
before we called display-buffer), why should we assume that
display-buffer should change it?

This reasoning is currently applied to raise-frame and I don't see why
we should use a different reasoning for make-frame-visible (after all,
a frame buried under other frames is just as invisible as an iconified
frame).


        Stefan

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[martin rudalics]

 > No, it's very much possible and easy, but if we're in such a situation
 > before display-buffer is called (i.e. it was not considered a problem
 > before we called display-buffer), why should we assume that
 > display-buffer should change it?

The caller of 'display-buffer' may have selected an invisible or
iconified frame.  We nowhere rule out such a possibility.

martin

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Stefan Monnier]

>> No, it's very much possible and easy, but if we're in such a situation
>> before display-buffer is called (i.e. it was not considered a problem
>> before we called display-buffer), why should we assume that
>> display-buffer should change it?
> The caller of 'display-buffer' may have selected an invisible or
> iconified frame.  We nowhere rule out such a possibility.

That's indeed what I said: "it's very much possible and easy".

And he just as well may have selected a frame that's deiconified but
hidden under tens of other frames (or other applications's windows).

Which is why I think the logic should be the same for "visible" as for
"raised".


        Stefan "not to mention the case of the frame being in another
                workspace"

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 26 Mar 2018 23:41:47 -0400
> 
> >> IOW I think that in window--maybe-raise-frame
> >>
> >>               ;; Assume the selected frame is already visible enough.
> >> 	      (eq frame (selected-frame))
> >>
> >> should apply not just to raise-frame but also to make-frame-visible.
> >
> > Is it impossible to make , say, iconified frame the selected one?
> 
> No, it's very much possible and easy, but if we're in such a situation
> before display-buffer is called (i.e. it was not considered a problem
> before we called display-buffer), why should we assume that
> display-buffer should change it?

Presumably, the result of display-buffer should be... ahem... to
display the buffer, right?

> This reasoning is currently applied to raise-frame and I don't see why
> we should use a different reasoning for make-frame-visible (after all,
> a frame buried under other frames is just as invisible as an iconified
> frame).

raise-frame isn't about frame's visibility, it's about the z-order.
It is quite possible, and even probable, that a frame be at least
partially visible without being on top.

So yes, raise-frame _is_ different, and I don't think the same
reasoning should be applied to the frame's visibility.

Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)

[martin rudalics]

 > Is it, really?  Even tho we're just switching from one window to another
 > in the same frame?

I suspect it happens because of that.  The frame is already visible
and we wait the whole timeout without ever receiving a notify event.
'switch-to-buffer-other-frame' should be considerably faster.

martin