all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
@ 2018-03-26 10:12 zhang cc
  2018-03-26 15:16 ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: zhang cc @ 2018-03-26 10:12 UTC (permalink / raw)
  To: emacs-devel@gnu.org

[-- 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 --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 10:12 Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s) zhang cc
@ 2018-03-26 15:16 ` Eli Zaretskii
  2018-03-26 15:22   ` zhang cc
       [not found]   ` <544b8346-bda9-45eb-9573-1d51d9f768b2@Spark>
  0 siblings, 2 replies; 35+ messages in thread
From: Eli Zaretskii @ 2018-03-26 15:16 UTC (permalink / raw)
  To: zhang cc; +Cc: emacs-devel

> 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"?



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 15:16 ` Eli Zaretskii
@ 2018-03-26 15:22   ` zhang cc
       [not found]   ` <544b8346-bda9-45eb-9573-1d51d9f768b2@Spark>
  1 sibling, 0 replies; 35+ messages in thread
From: zhang cc @ 2018-03-26 15:22 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel@gnu.org

[-- 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 --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
       [not found]   ` <544b8346-bda9-45eb-9573-1d51d9f768b2@Spark>
@ 2018-03-26 15:25     ` zhang cc
  2018-03-26 15:30       ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: zhang cc @ 2018-03-26 15:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel@gnu.org

[-- 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 --]

^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 15:25     ` zhang cc
@ 2018-03-26 15:30       ` Eli Zaretskii
  2018-03-26 16:09         ` Robert Pluim
  0 siblings, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2018-03-26 15:30 UTC (permalink / raw)
  To: zhang cc; +Cc: emacs-devel

> 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?



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 15:30       ` Eli Zaretskii
@ 2018-03-26 16:09         ` Robert Pluim
  2018-03-26 16:29           ` Clément Pit-Claudel
  2018-03-26 16:34           ` Robert Pluim
  0 siblings, 2 replies; 35+ messages in thread
From: Robert Pluim @ 2018-03-26 16:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, zhang cc

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



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 16:09         ` Robert Pluim
@ 2018-03-26 16:29           ` Clément Pit-Claudel
  2018-03-26 16:34           ` Robert Pluim
  1 sibling, 0 replies; 35+ messages in thread
From: Clément Pit-Claudel @ 2018-03-26 16:29 UTC (permalink / raw)
  To: emacs-devel

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.



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 16:09         ` Robert Pluim
  2018-03-26 16:29           ` Clément Pit-Claudel
@ 2018-03-26 16:34           ` Robert Pluim
  2018-03-26 16:37             ` Noam Postavsky
  1 sibling, 1 reply; 35+ messages in thread
From: Robert Pluim @ 2018-03-26 16:34 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 16:34           ` Robert Pluim
@ 2018-03-26 16:37             ` Noam Postavsky
  2018-03-26 16:59               ` Robert Pluim
  0 siblings, 1 reply; 35+ messages in thread
From: Noam Postavsky @ 2018-03-26 16:37 UTC (permalink / raw)
  To: Emacs developers

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?



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 16:37             ` Noam Postavsky
@ 2018-03-26 16:59               ` Robert Pluim
  2018-03-26 17:28                 ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: Robert Pluim @ 2018-03-26 16:59 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: zhang cc, Emacs developers

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



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 16:59               ` Robert Pluim
@ 2018-03-26 17:28                 ` Eli Zaretskii
  2018-03-26 17:49                   ` Stefan Monnier
  0 siblings, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2018-03-26 17:28 UTC (permalink / raw)
  To: Robert Pluim; +Cc: emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 17:28                 ` Eli Zaretskii
@ 2018-03-26 17:49                   ` Stefan Monnier
  2018-03-26 18:17                     ` Eli Zaretskii
  2018-03-26 18:46                     ` martin rudalics
  0 siblings, 2 replies; 35+ messages in thread
From: Stefan Monnier @ 2018-03-26 17:49 UTC (permalink / raw)
  To: emacs-devel

> 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




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 17:49                   ` Stefan Monnier
@ 2018-03-26 18:17                     ` Eli Zaretskii
  2018-03-26 18:26                       ` Stefan Monnier
  2018-03-26 18:46                     ` martin rudalics
  1 sibling, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2018-03-26 18:17 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 18:17                     ` Eli Zaretskii
@ 2018-03-26 18:26                       ` Stefan Monnier
  2018-03-26 18:33                         ` Eli Zaretskii
  2018-03-26 18:46                         ` martin rudalics
  0 siblings, 2 replies; 35+ messages in thread
From: Stefan Monnier @ 2018-03-26 18:26 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

> 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



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 18:26                       ` Stefan Monnier
@ 2018-03-26 18:33                         ` Eli Zaretskii
  2018-03-26 18:41                           ` Stefan Monnier
  2018-03-26 18:46                         ` martin rudalics
  1 sibling, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2018-03-26 18:33 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

> 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?



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 18:33                         ` Eli Zaretskii
@ 2018-03-26 18:41                           ` Stefan Monnier
  0 siblings, 0 replies; 35+ messages in thread
From: Stefan Monnier @ 2018-03-26 18:41 UTC (permalink / raw)
  To: emacs-devel

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

Indeed!


        Stefan




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 17:49                   ` Stefan Monnier
  2018-03-26 18:17                     ` Eli Zaretskii
@ 2018-03-26 18:46                     ` martin rudalics
  1 sibling, 0 replies; 35+ messages in thread
From: martin rudalics @ 2018-03-26 18:46 UTC (permalink / raw)
  To: Stefan Monnier, emacs-devel

 > 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



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 18:26                       ` Stefan Monnier
  2018-03-26 18:33                         ` Eli Zaretskii
@ 2018-03-26 18:46                         ` martin rudalics
  2018-03-26 18:58                           ` Eli Zaretskii
  2018-03-26 20:09                           ` Stefan Monnier
  1 sibling, 2 replies; 35+ messages in thread
From: martin rudalics @ 2018-03-26 18:46 UTC (permalink / raw)
  To: Stefan Monnier, Eli Zaretskii; +Cc: emacs-devel

 > 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



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 18:46                         ` martin rudalics
@ 2018-03-26 18:58                           ` Eli Zaretskii
  2018-03-26 19:16                             ` martin rudalics
  2018-03-26 20:09                           ` Stefan Monnier
  1 sibling, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2018-03-26 18:58 UTC (permalink / raw)
  To: martin rudalics; +Cc: monnier, emacs-devel

> 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?



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 18:58                           ` Eli Zaretskii
@ 2018-03-26 19:16                             ` martin rudalics
  2018-03-26 19:24                               ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: martin rudalics @ 2018-03-26 19:16 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: monnier, emacs-devel

 > 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





^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 19:16                             ` martin rudalics
@ 2018-03-26 19:24                               ` Eli Zaretskii
  2018-03-26 21:41                                 ` martin rudalics
  0 siblings, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2018-03-26 19:24 UTC (permalink / raw)
  To: martin rudalics; +Cc: monnier, emacs-devel

> 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.)



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 18:46                         ` martin rudalics
  2018-03-26 18:58                           ` Eli Zaretskii
@ 2018-03-26 20:09                           ` Stefan Monnier
  2018-03-26 21:42                             ` martin rudalics
  2018-03-27  2:45                             ` Eli Zaretskii
  1 sibling, 2 replies; 35+ messages in thread
From: Stefan Monnier @ 2018-03-26 20:09 UTC (permalink / raw)
  To: martin rudalics; +Cc: Eli Zaretskii, emacs-devel

>> 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



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 19:24                               ` Eli Zaretskii
@ 2018-03-26 21:41                                 ` martin rudalics
  2018-03-27  2:50                                   ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: martin rudalics @ 2018-03-26 21:41 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: monnier, emacs-devel

 > 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



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 20:09                           ` Stefan Monnier
@ 2018-03-26 21:42                             ` martin rudalics
  2018-03-27  2:45                             ` Eli Zaretskii
  1 sibling, 0 replies; 35+ messages in thread
From: martin rudalics @ 2018-03-26 21:42 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel

 > 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



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 20:09                           ` Stefan Monnier
  2018-03-26 21:42                             ` martin rudalics
@ 2018-03-27  2:45                             ` Eli Zaretskii
  2018-03-27  3:41                               ` Stefan Monnier
  1 sibling, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2018-03-27  2:45 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: rudalics, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-26 21:41                                 ` martin rudalics
@ 2018-03-27  2:50                                   ` Eli Zaretskii
  2018-03-27  7:23                                     ` martin rudalics
  0 siblings, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2018-03-27  2:50 UTC (permalink / raw)
  To: martin rudalics; +Cc: monnier, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-27  2:45                             ` Eli Zaretskii
@ 2018-03-27  3:41                               ` Stefan Monnier
  2018-03-27  7:23                                 ` martin rudalics
  2018-03-29  8:58                                 ` Eli Zaretskii
  0 siblings, 2 replies; 35+ messages in thread
From: Stefan Monnier @ 2018-03-27  3:41 UTC (permalink / raw)
  To: emacs-devel

>> 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




^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-27  2:50                                   ` Eli Zaretskii
@ 2018-03-27  7:23                                     ` martin rudalics
  2018-03-29  9:37                                       ` Eli Zaretskii
  0 siblings, 1 reply; 35+ messages in thread
From: martin rudalics @ 2018-03-27  7:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: monnier, emacs-devel

 > 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



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-27  3:41                               ` Stefan Monnier
@ 2018-03-27  7:23                                 ` martin rudalics
  2018-03-27 12:00                                   ` Stefan Monnier
  2018-03-29  8:58                                 ` Eli Zaretskii
  1 sibling, 1 reply; 35+ messages in thread
From: martin rudalics @ 2018-03-27  7:23 UTC (permalink / raw)
  To: Stefan Monnier, emacs-devel

 > 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



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-27  7:23                                 ` martin rudalics
@ 2018-03-27 12:00                                   ` Stefan Monnier
  0 siblings, 0 replies; 35+ messages in thread
From: Stefan Monnier @ 2018-03-27 12:00 UTC (permalink / raw)
  To: martin rudalics; +Cc: emacs-devel

>> 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"



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-27  3:41                               ` Stefan Monnier
  2018-03-27  7:23                                 ` martin rudalics
@ 2018-03-29  8:58                                 ` Eli Zaretskii
  1 sibling, 0 replies; 35+ messages in thread
From: Eli Zaretskii @ 2018-03-29  8:58 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-27  7:23                                     ` martin rudalics
@ 2018-03-29  9:37                                       ` Eli Zaretskii
  2018-03-29 23:15                                         ` Noam Postavsky
  0 siblings, 1 reply; 35+ messages in thread
From: Eli Zaretskii @ 2018-03-29  9:37 UTC (permalink / raw)
  To: martin rudalics, Noam Postavsky; +Cc: monnier, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-29  9:37                                       ` Eli Zaretskii
@ 2018-03-29 23:15                                         ` Noam Postavsky
  2018-03-29 23:20                                           ` Noam Postavsky
  2018-03-30  7:51                                           ` Eli Zaretskii
  0 siblings, 2 replies; 35+ messages in thread
From: Noam Postavsky @ 2018-03-29 23:15 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: martin rudalics, Stefan Monnier, Ken Brown, Emacs developers

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



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-29 23:15                                         ` Noam Postavsky
@ 2018-03-29 23:20                                           ` Noam Postavsky
  2018-03-30  7:51                                           ` Eli Zaretskii
  1 sibling, 0 replies; 35+ messages in thread
From: Noam Postavsky @ 2018-03-29 23:20 UTC (permalink / raw)
  To: Eli Zaretskii
  Cc: martin rudalics, Stefan Monnier, Ken Brown, Emacs developers

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



^ permalink raw reply	[flat|nested] 35+ messages in thread

* Re: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s)
  2018-03-29 23:15                                         ` Noam Postavsky
  2018-03-29 23:20                                           ` Noam Postavsky
@ 2018-03-30  7:51                                           ` Eli Zaretskii
  1 sibling, 0 replies; 35+ messages in thread
From: Eli Zaretskii @ 2018-03-30  7:51 UTC (permalink / raw)
  To: Noam Postavsky; +Cc: rudalics, monnier, kbrown, emacs-devel

> 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.



^ permalink raw reply	[flat|nested] 35+ messages in thread

end of thread, other threads:[~2018-03-30  7:51 UTC | newest]

Thread overview: 35+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-03-26 10:12 Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s) zhang cc
2018-03-26 15:16 ` Eli Zaretskii
2018-03-26 15:22   ` zhang cc
     [not found]   ` <544b8346-bda9-45eb-9573-1d51d9f768b2@Spark>
2018-03-26 15:25     ` zhang cc
2018-03-26 15:30       ` Eli Zaretskii
2018-03-26 16:09         ` Robert Pluim
2018-03-26 16:29           ` Clément Pit-Claudel
2018-03-26 16:34           ` Robert Pluim
2018-03-26 16:37             ` Noam Postavsky
2018-03-26 16:59               ` Robert Pluim
2018-03-26 17:28                 ` Eli Zaretskii
2018-03-26 17:49                   ` Stefan Monnier
2018-03-26 18:17                     ` Eli Zaretskii
2018-03-26 18:26                       ` Stefan Monnier
2018-03-26 18:33                         ` Eli Zaretskii
2018-03-26 18:41                           ` Stefan Monnier
2018-03-26 18:46                         ` martin rudalics
2018-03-26 18:58                           ` Eli Zaretskii
2018-03-26 19:16                             ` martin rudalics
2018-03-26 19:24                               ` Eli Zaretskii
2018-03-26 21:41                                 ` martin rudalics
2018-03-27  2:50                                   ` Eli Zaretskii
2018-03-27  7:23                                     ` martin rudalics
2018-03-29  9:37                                       ` Eli Zaretskii
2018-03-29 23:15                                         ` Noam Postavsky
2018-03-29 23:20                                           ` Noam Postavsky
2018-03-30  7:51                                           ` Eli Zaretskii
2018-03-26 20:09                           ` Stefan Monnier
2018-03-26 21:42                             ` martin rudalics
2018-03-27  2:45                             ` Eli Zaretskii
2018-03-27  3:41                               ` Stefan Monnier
2018-03-27  7:23                                 ` martin rudalics
2018-03-27 12:00                                   ` Stefan Monnier
2018-03-29  8:58                                 ` Eli Zaretskii
2018-03-26 18:46                     ` martin rudalics

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.