From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: x-display-pixel-width/height inconsistency Date: Sat, 6 Jul 2013 12:25:58 -0700 (PDT) Message-ID: <7be66382-af02-4eae-a672-281cbe51a6a6@default> References: <83vc6tcqss.fsf@gnu.org> <83haibdipo.fsf@gnu.org> <837gj7co0l.fsf@gnu.org> <8338tvcjlp.fsf@gnu.org> <83wqr7b3h6.fsf@gnu.org> <51D12678.5090806@gmx.at> <51D2ADAA.9000805@gmx.at> <51D2D180.6050002@gmx.at> <51D3EE69.9080808@gmx.at> <51D41CA2.8000206@gmx.at> <51D541B6.1000908@gmx.at> <8F67C4E1-0640-4912-A73B-1B120C8E8F0B@swipnet.se> <7B61DAF3-584E-44B1-8CA7-D6B0CEF83E7A@swipnet.se> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1373138781 2969 80.91.229.3 (6 Jul 2013 19:26:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Jul 2013 19:26:21 +0000 (UTC) Cc: martin rudalics , =?utf-8?B?SmFuIERqw6Rydg==?= , YAMAMOTO Mitsuharu , Emacs developers To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jul 06 21:26:20 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UvY7e-00050b-ER for ged-emacs-devel@m.gmane.org; Sat, 06 Jul 2013 21:26:18 +0200 Original-Received: from localhost ([::1]:37921 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvY7d-0002mr-PD for ged-emacs-devel@m.gmane.org; Sat, 06 Jul 2013 15:26:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50925) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvY7Z-0002md-CM for emacs-devel@gnu.org; Sat, 06 Jul 2013 15:26:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UvY7V-0002gg-Lp for emacs-devel@gnu.org; Sat, 06 Jul 2013 15:26:13 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:38152) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UvY7V-0002gU-Cq for emacs-devel@gnu.org; Sat, 06 Jul 2013 15:26:09 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r66JQ44P023434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 6 Jul 2013 19:26:04 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r66JQ2i4025256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Jul 2013 19:26:02 GMT Original-Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r66JQ143025235; Sat, 6 Jul 2013 19:26:01 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.7 (607090) [OL 12.0.6668.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:161681 Archived-At: > > No - please, dear Emacs, learn to help lost users. ;-) >=20 > 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"... >=20 > 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. >=20 > 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. >=20 > 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. >=20 > > 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.= ) >=20 > 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.