From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.devel Subject: Re: select-frame-set-input-focus fails to raise the frame Date: Sat, 16 Dec 2017 13:57:34 -0500 Message-ID: References: <20171213204737.GA1621@breton.holly.idiocy.org> <20171213222634.GA2144@breton.holly.idiocy.org> <831sjwt1jf.fsf@gnu.org> <83tvwrsouc.fsf@gnu.org> <83d13espny.fsf@gnu.org> <83a7yisl6t.fsf@gnu.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113d7018780930056079b28f" X-Trace: blaine.gmane.org 1513450707 32444 195.159.176.226 (16 Dec 2017 18:58:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Dec 2017 18:58:27 +0000 (UTC) Cc: Alan Third , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 16 19:58:18 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eQHf7-0007gd-TS for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 19:58:18 +0100 Original-Received: from localhost ([::1]:51740 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQHfD-0008PM-Dp for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 13:58:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQHf0-0008P3-2u for emacs-devel@gnu.org; Sat, 16 Dec 2017 13:58:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQHew-0002Jy-Ol for emacs-devel@gnu.org; Sat, 16 Dec 2017 13:58:10 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37470) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQHew-0002Ju-Kt for emacs-devel@gnu.org; Sat, 16 Dec 2017 13:58:06 -0500 Original-Received: from mail-qt0-f174.google.com ([209.85.216.174]:44499) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1eQHev-0002qZ-My; Sat, 16 Dec 2017 13:58:06 -0500 Original-Received: by mail-qt0-f174.google.com with SMTP id m59so15785216qte.11; Sat, 16 Dec 2017 10:58:05 -0800 (PST) X-Gm-Message-State: AKGB3mLb7QX9A33tPeLneR1JH93YLIIxdL3W1iszigwXrvgzeBerdBUz 4y2p50XsCVLvgNt3INtxszCvpZ49uE+MqiBCEsE= X-Google-Smtp-Source: ACJfBovwNqTy2oWeeGzpSyDKlEbfjuoX4wZVEODW/9uT3/guSMUU/cKFKKotnMo79kRQGrd82Pf2We2sTGwUJHY19Fc= X-Received: by 10.200.51.143 with SMTP id c15mr28808214qtb.46.1513450685071; Sat, 16 Dec 2017 10:58:05 -0800 (PST) Original-Received: by 10.200.55.124 with HTTP; Sat, 16 Dec 2017 10:57:34 -0800 (PST) In-Reply-To: <83a7yisl6t.fsf@gnu.org> X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:221143 Archived-At: --001a113d7018780930056079b28f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 16, 2017 at 11:15 AM, Eli Zaretskii wrote: > > From: Robert Weiner > > > =E2=80=8BOk, that is an example of why I am advocating for a potentiall= y > > new function that let's a programmer say "display the latest > > contents of this window with no other Emacs window or frame > > obscuring it". > > That cannot be done in general, because redisplaying a window could > very well affect other windows. One example of that is TTY frame > display; =E2=80=8BOnly one frame is visible on a tty at a time, so in my use case, this would have to be the frame that displays the window. Why is this a problem? =E2=80=8B=E2=80=8B > another is a case where the window was shrunk. =E2=80=8BWhy can a shrunk window not be displayed within the topmost frame? You are giving examples without explaining why they conflict with the desired goal? =E2=80=8B > =E2=80=8B=E2=80=8B > And there are > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > other, more subtle use cases. > =E2=80=8BSo you are saying Emacs provides no way for the programmer to ensure that a window is wholly displayed on screen and fully updated even when Emacs is the only application in use? =E2=80=8B > =E2=80=8B > > =E2=80=8B=E2=80=8B > In general, Lisp programs shouldn't dictate the display engine what to > =E2=80=8B=E2=80=8B > do or not to do, because they can easily make mistakes, being unaware > =E2=80=8B=E2=80=8B > of all the subtleties. Instead, it should be the job of the display > =E2=80=8B=E2=80=8B > engine to determine what and when to redraw, and Lisp can at most > =E2=80=8B=E2=80=8B > provide hints. > =E2=80=8BRight, this is what we do most of the time. =E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > I don't think Elisp programmers should have to > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > master the intricacies of windows, frames, the > =E2=80=8B=E2=80=8B > redisplay engine, > =E2=80=8B=E2=80=8B > > and window managers to do that. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > They don't. But note that your code > =E2=80=8B=E2=80=8B > attempted to do just that, at > =E2=80=8B=E2=80=8B > least indirectly. > =E2=80=8B=E2=80=8B > =E2=80=8BI am trying to do just what I stated above plus ensure the displayed frame receives input focus.=E2=80=8B =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8BOn top of th > =E2=80=8B=E2=80=8B > at, when and how a new frame appears on display is not > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8Bonly up to E > =E2=80=8B=E2=80=8B > macs: the WM has a lot to do with that. > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > =E2=80=8BYes, but Emacs sends commands to the WM. Now if the WM ignores > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > those commands not much can be done > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > The problem is, many popular WMs do ignore our hints. So reliable > =E2=80=8B=E2=80=8B > behavior cannot be built on top of this flaky basis. > Under what window managers is Emacs unable to raise a frame or set input focus reliably? That sounds like a platform where multi-frame use would be generally unreliable. =E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > Take raise-frame for example. Should we not expect > =E2=80=8B=E2=80=8B > > this to make the given frame the topmost? The doc string says we > =E2=80=8B=E2=80=8B > > should. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Martin will tell, but I personally am not sure we can rely on that, > =E2=80=8B=E2=80=8B > the doc string notwithstanding. > =E2=80=8BIf you cannot put a frame in front of all others then you can't see the contents of its windows when frames overlap and again multi-frame=E2=80=8B use would not be viable except for non-overlapping frames. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8BThe doc strings try very hard to tell the story comp= letely and > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8Baccurately, but it isn't easy, because the underlyin= g behavior is > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8Bextremely complex, and needs to cater to some very d= ifferent use > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8Bcases. > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > > =E2=80=8BI'm mainly asking that obvious gotchas like those demonstrated > =E2=80=8B=E2=80=8B > > by my sample code be mentioned in doc strings, not a deep dive > =E2=80=8B=E2=80=8B > > into all special case technicalities. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > But the doc strings need to provide information for much more complex > =E2=80=8B=E2=80=8B > code as well, not just for simple codes. > =E2=80=8BI'm not against documenting more involved scenarios, just saying I think some of this documentation could be added with a few sentences without diving deeply into many special cases. If this covered 90% of the cases, it would still be very helpful despite not being wholly complete. You yourself said earlier that that is an unreasonable expectation of the doc. =E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8BCalling 'redisplay' with last argument non-nil is th= e o > =E2=80=8B=E2=80=8B > nly way to > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8Bactually ensure redisplay, so if you must, use only = th > =E2=80=8B=E2=80=8B > at. > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > =E2=80=8BIt sounds like that is the only way since I need to see the curr= ent > contents > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > of the new frame's only window. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > A > =E2=80=8B=E2=80=8B > nd what's wrong with that? You don't need more than one way, as long > =E2=80=8B=E2=80=8B > a > =E2=80=8B=E2=80=8B > s it works. > =E2=80=8BIt is fine. I had just dealt with many multi-frame scenarios before and never had to call redisplay directly so it seemed odd that I had to now. So I looked for other techniques to give redisplay hints as you said and was surprised when these hints were insufficient.=E2=80=8B Bob --001a113d7018780930056079b28f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 16, 2= 017 at 11:15 AM, Eli Zaretskii <e= liz@gnu.org> wro= te:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">> From: Robert Weiner <rsw@gnu.org>

> =E2=80=8BOk, that is an example of why I am advocating for a potential= ly
> new function that let's a programmer say "display the latest<= br> > contents of this window with no other Emacs window or frame
> obscuring it".

That cannot be done in general, because redisplaying a window could<= br> very well affect other windows.=C2=A0 One example of that is TTY frame
display;

=E2=80=8BOnly one frame is visible on a tty= at a time, so in
my use case, this would have to be the frame that
<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">displ= ays the window.=C2=A0 Why is this a problem?

=E2=80=8B=E2=80=8B
another is a case where t= he window was shrunk.

=E2=80=8BWhy can a shrunk wind= ow not be displayed within the
topmost frame?=C2=A0 You are giving example= s without explaining
why they conflict with the desired goal?
=E2=80=8B
=E2=80=8B=E2=80=8B
=C2= =A0 And there are
=E2=80=8B=E2=80=8B
=E2=80=8B=E2= =80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80= =8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
other, more subtle use cases.

=E2=80=8BSo you are saying Emacs provides no way for the p= rogrammer
to ensure that a window is wholly displayed on screen and
<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">fully= updated even when Emacs is the only application in use?
=E2=80=8B
=E2=80=8B

=E2=80=8B=E2=80=8B
In general, Lisp programs shouldn't = dictate the display engine what to
=E2=80=8B=E2=80=8B
do or not to do, because they can easily= make mistakes, being unaware
=E2=80=8B=E2=80=8B
of all the subtleties.=C2=A0 Instead, it= should be the job of the display
=E2=80=8B=E2=80=8B
engine to determine what and when to red= raw, and Lisp can at most
=E2=80=8B=E2=80=8B
provide hints.

=
=E2=80=8BRight, this is what we do most of the time.
=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> I don't think Elisp programmers= should have to
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> master the intricacies of windows, = frames, the
=E2=80=8B=E2=80=8B
redisplay engine,
=E2=80=8B=E2=80=8B
> and window managers to do that.=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
They don't.=C2=A0 But note th= at your code
=E2=80=8B=E2=80=8B
attempted to do just that, = at
=E2=80=8B=E2=80=8B
least indirectly.
=E2=80=8B=E2= =80=8B

=E2=80=8BI am trying to do just what I= stated above plus ensure
the displayed frame receives input focus.=E2=80= =8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
>=C2=A0 =E2=80=8B=E2=80=8BOn top of t= h
=E2=80=8B=E2=80=8B
at, when and how a new frame appears on= display is not
=E2=80=8B=E2=80=8B
>=C2=A0 =E2=80=8B=E2=80=8Bonly up to = E
=E2=80=8B=E2=80=8B
macs: the WM has a lot to do with that.=
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B =E2=80=8BYes, but Emacs sends commands to the WM.=C2=A0 Now if the WM ign= ores
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B those commands not much can be done
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
The problem is, many popular WMs = do ignore our hints.=C2=A0 So reliable
=E2=80=8B=E2=80=8B
behavior cannot be built on top of this = flaky basis.

Under what window managers is Emacs= unable to raise
a frame or set input focus reliably?=C2=A0 That sounds li= ke
a platform where multi-frame use would be generally
unreliable.
<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">=E2= =80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> Take raise-frame for example.=C2=A0= Should we not expect
=E2=80=8B=E2=80=8B
> this to make the given frame the to= pmost?=C2=A0 The doc string says we
=E2=80=8B=E2=80=8B
> should.
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
Martin will tell, but I personall= y am not sure we can rely on that,
=E2=80=8B=E2=80=8B
the doc string notwithstanding.

=E2=80=8BIf you cannot put a frame in front of all other= s then
you can't see the contents of its windows when frames
overlap = and again multi-frame=E2=80=8B use would not be viable
except for non-over= lapping frames.

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
>=C2=A0 =E2=80=8B=E2=80=8BThe doc str= ings try very hard to tell the story completely and
=E2=80=8B=E2=80=8B
>=C2=A0 =E2=80=8B=E2=80=8Baccurately,= but it isn't easy, because the underlying behavior is
=E2=80=8B=E2=80=8B
>=C2=A0 =E2=80=8B=E2=80=8Bextremely c= omplex, and needs to cater to some very different use
=E2=80=8B=E2=80=8B
>=C2=A0 =E2=80=8B=E2=80=8Bcases.
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B
> =E2=80=8BI'm mainly asking that= obvious gotchas like those demonstrated
=E2=80=8B=E2=80=8B
> by my sample code be mentioned in d= oc strings, not a deep dive
=E2=80=8B=E2=80=8B
> into all special case technicalitie= s.
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
But the doc strings need to provi= de information for much more complex
=E2=80=8B=E2=80=8B
code as well, not just for simple codes.=

=E2=80=8BI'm not against documenting more i= nvolved scenarios,
just saying I think some of this documentation could
b= e added with a few sentences without diving deeply
into many special cases= .=C2=A0 If this covered 90% of the
cases, it would still be very helpful = despite not being
wholly complete.=C2=A0 You yourself said earlier that th= at
is an unreasonable expectation of the doc.
=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
>=C2=A0 =E2=80=8B=E2=80=8BCalling = 9;redisplay' with last argument non-nil is the o
=E2=80=8B=E2= =80=8B
nly way to
=E2=80=8B=E2=80=8B
>=C2=A0 =E2=80=8B=E2=80=8Bactually en= sure redisplay, so if you must, use only th
=E2=80=8B=E2=80=8Bat.
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B =E2=80=8BIt sounds like that is the only way since I need to see the curr= ent contents
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B of the new frame's only window.
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
A
=E2=80=8B=E2=80=8Bnd what's wrong with that?=C2=A0 You don't need more than one wa= y, as long
=E2=80=8B=E2=80=8B
a
=E2=80=8B=E2=80=8B
s it= works.

=E2=80=8BIt is fine.=C2=A0 I had just = dealt with many multi-frame scenarios
before and never had to call redispl= ay directly so it seemed
odd that I had to now.=C2=A0 So I looked for othe= r techniques to
give redisplay hints as you said and was surprised when th= ese
hints were insufficient.=E2=80=8B

Bob

--001a113d7018780930056079b28f--