From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#15174: 24.3.50; frame shrinks vertically when enlarge or shrink it horizontally Date: Sat, 24 Aug 2013 01:39:20 -0700 (PDT) Message-ID: <40f6eb16-0d79-4210-b1f9-206666aecac1@default> References: <<394ec688-cab0-443f-b74e-335c573efca0@default>> <<8338pzino6.fsf@gnu.org>> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1377333658 16248 80.91.229.3 (24 Aug 2013 08:40:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 24 Aug 2013 08:40:58 +0000 (UTC) Cc: 15174@debbugs.gnu.org, control@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 24 10:40:57 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1VD9Oz-0007v2-D4 for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Aug 2013 10:40:57 +0200 Original-Received: from localhost ([::1]:40793 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VD9Oy-0005rj-Rc for geb-bug-gnu-emacs@m.gmane.org; Sat, 24 Aug 2013 04:40:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49828) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VD9OI-0005pW-KS for bug-gnu-emacs@gnu.org; Sat, 24 Aug 2013 04:40:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VD9O7-0000RQ-6u for bug-gnu-emacs@gnu.org; Sat, 24 Aug 2013 04:40:14 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VD9O7-0000QH-2o for bug-gnu-emacs@gnu.org; Sat, 24 Aug 2013 04:40:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VD9O5-0002d6-QC for bug-gnu-emacs@gnu.org; Sat, 24 Aug 2013 04:40:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 24 Aug 2013 08:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15174 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15174-submit@debbugs.gnu.org id=B15174.137733356710063 (code B ref 15174); Sat, 24 Aug 2013 08:40:01 +0000 Original-Received: (at 15174) by debbugs.gnu.org; 24 Aug 2013 08:39:27 +0000 Original-Received: from localhost ([127.0.0.1]:51739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VD9NX-0002cB-1q for submit@debbugs.gnu.org; Sat, 24 Aug 2013 04:39:27 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:20248) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VD9NT-0002bs-00; Sat, 24 Aug 2013 04:39:23 -0400 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7O8dKK1029847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 24 Aug 2013 08:39:21 GMT Original-Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7O8dJV6005223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Aug 2013 08:39:20 GMT Original-Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7O8dJsd013827; Sat, 24 Aug 2013 08:39:19 GMT In-Reply-To: <<8338pzino6.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:77681 Archived-At: > > Use the mouse to make the frame narrow enough that the menu bar wraps t= o > > a second line. >=20 > Just don't do that. The menu bar is short enough and displays are > wide enough nowadays to make this an improbable situation. You can relegate the bug report to the dust bin, if there is no way to fix the bug now. I can understand, if that is the case. But for the record I completely disagree with the attitude or assessment that you just expressed. "The menu bar" is not something static, fixed once and for all when you open the Emacs box. It can vary wrt mode etc. And thank goodness for that. And "displays are wide enough" pretty much assumes that a frame is meant to consume lots of horizontal display space. I don't use frames that way. I typically make sure that a frame fits the width of its displayed buffer (typically one buffer per frame). Try this, in `emacs -Q': Open a directory in Dired mode. Hit `(' to hide details, showing only file names. Even if you have an extremely long file name it is no doubt much narrower than the width of the menu bar: `File Edit Options Buffers Tools Operate Mark Regex Immediate Subdir Help' -- oops, sorry, had to wrap it for this message ;-). ("Just don't do that", indeed.) Most file names are probably not even half as wide as that menu bar. "The menu bar is short enough", indeed! Don't you think some users might not want to waste all that white space to the right of the file names, by narrowing the frame, leaving room for something else in their display (another Emacs frame, perhaps)? Especially if they have a keyboard key that does just that: fits the frame to the displayed buffer width? Remember speed-bar? Oh, we had to make sure it doesn't have a menu bar or a tool bar, didn't we? And we its truncate file names too. Making a virtue out of necessity, perhaps? But maybe you get the point that there can be a use case for a frame with less than display-wide width. Now if Emacs had more sophisticated graphics support, so that there were other possibilities besides just a single, rudimentary menu bar that can only wrap, then there would be no problem. But we make do with what we have. Judging by appearance and behavior, unless I'm not noticing something, we have the same menu bar in Emacs 24 that we had in Emacs 20 (and likely before that). And essentially the same tool bar we had in Emacs 22, if not 21. I don't know about the tools (toolkit or whatever) available on MS Windows for developers to work with, but MS products themselves are not limited in 2013 to the same appearance and behavior they had in 2000 or 1995 wrt menu bars and tool bars. Not that MS is super innovative or the best model, but things have evolved some. > (The technical reason behind the problem is that Emacs doesn't know > enough about the size of the menu bar, which is created by the Windows > window manager.) And that presumably is the real reason behind your conclusions above that "the menu bar is short enough" and "displays are wide enough": As things stand now, the Emacs implementation is just not up to the task of fixing this bug. I can understand, if you say that this is a wishlist bug because the Emacs implementation doesn't currently know how to do any better, or cannot possibly do better given the building blocks it has to work with now. But it is a cop-out to blame that limitation on "the Windows window manager", as far as I can tell. Right now I'm using an MS Windows application from several years ago, Outlook 2007, and there is no such limitation wrt its menu bar or any of the other stuff it puts near the top of the "frame" (tool bar, ribbon, whatever). The menu bar in this and other MS Windows applications never wraps at all, no matter how severely you narrow the frame. Instead, its entries are gracefully abbreviated when horizontal space is scarce - each gets truncated separately. And the menu bar, tool bar, etc. disappear altogether when there is insufficient room. This appearance and behavior too are presumably based on "the Windows window manager", and they are completely different from what we have with Emacs. So OK, if we can't get this fixed now then it must go to the wishlist, for another decade or two, perhaps. But please, let's not pretend that the reason is either that (a) the menu bar is always sufficiently narrow and displays are sufficiently wide that wrapping is "an improbable situation" or (b) that's just the way "the Windows window manager" is. If our implementation is limited by the tools we currently have available to build it, then fine - let's just say that. Forget the it's-not-a-problem-AND-anyway-it's-Microsoft's-fault refrain.