RE: x-display-pixel-width/height inconsistency

[Drew Adams <drew.adams@oracle.com>]

> > No - please, dear Emacs, learn to help lost users. ;-)
> 
> Emacs should not be a generic Windows-learning tool,

I certainly don't disagree there - but no one suggested that.

I said nothing about Emacs teaching users the Windows solution for the
problem cited.  I proposed a simple Emacs solution for it - and not
dependent on the platform.

> and having a window displayed outside the monitor is uncommon,
> but absolutely not Emacs-specific.

Agreed again.

But if a user uses Emacs with multiple frames, and especially if s?he
restores things using Desktop (which might never be 100% perfect), s?he
could benefit from a simple Emacs command to bring a lost frame back
to the playground.  And especially if the desktop-restoring session
involves a different monitor setup, resolution, platform...

> > In addition, beyond Emacs, I would even guess that most Windows users
> > have no idea how to move a window back on screen.  Google "how to move
> > window back onto screen"...
> 
> So that's what they should do if they find themselves in that
> circumstance. Is what I did, after all...

As do I, each time it happens (which is rare, which is why I forget).

But just because Windows does not make it obvious how to do this
(Google does, but not MS Windows) is no reason why Emacs should not do
so.  Emacs is self-documenting in a way that Windows is not, and it
can be easy for a user to find the open-sesame for this if we provide
an Emacs command for it.

> > And they generally do not need such knowledge.  Losing a window
> > off-screen does not happen every 30 minutes.
> 
> Losing a window off-screen *because* of frame restoration should not
> happen every 30 minutes, either.

Agreed.  I don't see this potential problem or its solution as being
related only to desktop restoration.  It is somewhat related but
essentially OT.

> It will be uncommon unless you happen to save & restore often in
> quite different monitor configurations, and if that's the case,
> and even if desktop.el tries its best to help,

Yes, we agree about the cases where one might lose a frame off-screen.

> the user should be prepared to accept some oddities (or some .emacs
> tweaking).

That's where we disagree.  Well, I don't actually disagree with that
statement, but I think that wrt an off-screen frame we can trivially
do something to help.

> > I think you mentioned that your use of MS Windows is mainly
> > command-line use.
> 
> No, I'm a heavy user of command line (for example, I almost never copy
> or move files with the Windows Explorer), but I'm also a heavy user of
> the Windows GUI.
> 
> >  That's great, but it is hardly the case of most Windows users.  (I
> > would even guess it is hardly the case for most Windows users of Emacs.)
> 
> That's an argument *for* them to know about moving windows back into
> the viewing area, not against.

No one argues that it is wrong or not useful for a user to know that.

What I disagree with is this previous statement of yours:

> But if a frame is off-screen and the user wants it on-screen, please
> dear user, learn to use Windows more effectively.

It can help the user to learn more about Windows, but that should not
be our only response.  Why?  Because Emacs can do better.  In this case,
better than Windows and just as well as Google.

I don't know whether the same problem of losing frames off screen exists
potentially for platforms besides Windows (I'm guessing yes).  But I do
know that there is a trivial, any-platform Emacs solution for bringing
such stray frames back to the playground.

I don't see this (relatively minor) problem as a Windows problem.  I see
it as a potential (and minor) gotcha that an Emacs user might get bit by,
and one for which there is a simple Emacs solution.