Re: select-frame-set-input-focus fails to raise the frame

[Robert Weiner]

On Sat, Dec 16, 2017 at 11:15 AM, Eli Zaretskii <address@hidden> wrote:

> From: Robert Weiner <address@hidden>

> ​Ok, that is an example of why I am advocating for a potentially
> 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;

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

​​

another is a case where the window was shrunk.

​Why can a shrunk window not be displayed within the

topmost frame?  You are giving examples without explaining

why they conflict with the desired goal?

​

​​

  And there are

​​

​​

​​

​​

​​

​​

​​

​​

other, more subtle use cases.

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

​

​

​​

In general, Lisp programs shouldn't dictate the display engine what to

​​

do or not to do, because they can easily make mistakes, being unaware

​​

of all the subtleties.  Instead, it should be the job of the display

​​

engine to determine what and when to redraw, and Lisp can at most

​​

provide hints.

​Right, this is what we do most of the time.

​

​​

​​

> I don't think Elisp programmers should have to

​​

​​

> master the intricacies of windows, frames, the

​​

redisplay engine,

​​

> and window managers to do that.

​​

​​

​​

They don't.  But note that your code

​​

attempted to do just that, at

​​

least indirectly.

​​

​I am trying to do just what I stated above plus ensure

the displayed frame receives input focus.​

​​

​​

>  ​​On top of th

​​

at, when and how a new frame appears on display is not

​​

>  ​​only up to E

​​

macs: the WM has a lot to do with that.

​​

>

​​

​​

>

​​

​Yes, but Emacs sends commands to the WM.  Now if the WM ignores

​​

>

​​

those commands not much can be done

​​

​​

The problem is, many popular WMs do ignore our hints.  So reliable

​​

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.

​

​​

​​

> Take raise-frame for example.  Should we not expect

​​

> this to make the given frame the topmost?  The doc string says we

​​

> should.

​​

​​

Martin will tell, but I personally am not sure we can rely on that,

​​

the doc string notwithstanding.

​If 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​ use would not be viable

except for non-overlapping frames.

​​

​​

>  ​​The doc strings try very hard to tell the story completely and

​​

>  ​​accurately, but it isn't easy, because the underlying behavior is

​​

>  ​​extremely complex, and needs to cater to some very different use

​​

>  ​​cases.

​​

>

​​

> ​I'm mainly asking that obvious gotchas like those demonstrated

​​

> by my sample code be mentioned in doc strings, not a deep dive

​​

> into all special case technicalities.

​​

​​

But the doc strings need to provide information for much more complex

​​

code as well, not just for simple codes.

​I'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.

​

​​

​​

>  ​​Calling 'redisplay' with last argument non-nil is the o

​​

nly way to

​​

>  ​​actually ensure redisplay, so if you must, use only th

​​

at.

​​

>

​​

​​

>

​​

​It sounds like that is the only way since I need to see the current contents

​​

>

​​

of the new frame's only window.

​​

​​

A

​​

nd what's wrong with that?  You don't need more than one way, as long

​​

a

​​

s it works.

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

Bob