bug#50743: Emacsclient not tested vs. Local Variables prompt

[Jean Louis <bugs@gnu.support>]

* martin rudalics <rudalics@gmx.at> [2021-09-26 12:23]:
> > And if you set server-raise-frame to nil, the "problem" happens in
> > both cases, right?
> >
> > So I'm not sure this is a bug.  The user should switch to the correct
> > frame to answer the question.  On my system, there's a prominent
> > indication that the client frame needs my attention, but even if there
> > isn't, the user should be vigilant enough to type the response into
> > the right frame.
> >
> > If we do want to somehow raise the frame earlier, we should do it
> > conditioned by server-raise-frame, because some users don't want the
> > frame to raise and get input focus.  But it isn't clear to me where
> > would be the correct place to raise the frame "earlier".
> 
> Maybe 'server-raise-frame' does too much when it triggers
> 'select-frame-set-input-focus'.  Still I consider it a bug when the user
> gets prompted and the frame displaying the prompt doesn't have focus.

I can fully understand that viewpoint, though there are special users'
configuration where focus shall remain all time on specific window or
some windows should be always raised, like "on top of everything" and
anything else appearing would come under.

And I will know when it happens or if there is some problem I will
personally know, and I assume that users similar to me would not have
real problem with it.

Giving you just insights as I use such Window Manager options all the
time since years.

Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/