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#456: menu-bar does not resize window Date: Sat, 21 Jun 2008 08:38:09 -0700 Message-ID: <004101c8d3b4$cf446840$0200a8c0@us.oracle.com> References: <4be34f530806202238w17121692g4b598cc8f0402333@mail.gmail.com> <485CB10E.1050307@gmx.at><4be34f530806210224w747c13eam7137dd6fe3e5b618@mail.gmail.com> <485CF670.3010602@gmx.at> Reply-To: Drew Adams , 456@emacsbugs.donarmstrong.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1214063260 16429 80.91.229.12 (21 Jun 2008 15:47:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Jun 2008 15:47:40 +0000 (UTC) To: "'martin rudalics'" , <456@emacsbugs.donarmstrong.com>, "'David Trallero'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Jun 21 17:48:24 2008 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KA5K9-0005bs-Om for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Jun 2008 17:48:23 +0200 Original-Received: from localhost ([127.0.0.1]:37645 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KA5JJ-0000Kr-H9 for geb-bug-gnu-emacs@m.gmane.org; Sat, 21 Jun 2008 11:47:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KA5JC-0000HA-9F for bug-gnu-emacs@gnu.org; Sat, 21 Jun 2008 11:47:22 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KA5J8-0000C7-2v for bug-gnu-emacs@gnu.org; Sat, 21 Jun 2008 11:47:20 -0400 Original-Received: from [199.232.76.173] (port=38434 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KA5J7-0000By-5Z for bug-gnu-emacs@gnu.org; Sat, 21 Jun 2008 11:47:17 -0400 Original-Received: from rzlab.ucr.edu ([138.23.92.77]:42052) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KA5J5-0002J4-Af for bug-gnu-emacs@gnu.org; Sat, 21 Jun 2008 11:47:16 -0400 Original-Received: from rzlab.ucr.edu (rzlab.ucr.edu [127.0.0.1]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m5LFl9O7031677; Sat, 21 Jun 2008 08:47:10 -0700 Original-Received: (from debbugs@localhost) by rzlab.ucr.edu (8.13.8/8.13.8/Submit) id m5LFj5jS030671; Sat, 21 Jun 2008 08:45:05 -0700 X-Loop: don@donarmstrong.com Resent-From: "Drew Adams" Resent-To: bug-submit-list@donarmstrong.com Resent-CC: Emacs Bugs Resent-Date: Sat, 21 Jun 2008 15:45:04 +0000 Resent-Message-ID: Resent-Sender: don@donarmstrong.com X-Emacs-PR-Message: report 456 X-Emacs-PR-Package: emacs X-Emacs-PR-Keywords: Original-Received: via spool by 456-submit@emacsbugs.donarmstrong.com id=B456.121406278029341 (code B ref 456); Sat, 21 Jun 2008 15:45:04 +0000 Original-Received: (at 456) by emacsbugs.donarmstrong.com; 21 Jun 2008 15:39:40 +0000 Original-Received: from rgminet01.oracle.com (rgminet01.oracle.com [148.87.113.118]) by rzlab.ucr.edu (8.13.8/8.13.8/Debian-3) with ESMTP id m5LFdYtp029335 for <456@emacsbugs.donarmstrong.com>; Sat, 21 Jun 2008 08:39:35 -0700 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id m5LFdNmK021424; Sat, 21 Jun 2008 09:39:23 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id m5LFZK8u031762; Sat, 21 Jun 2008 09:39:23 -0600 Original-Received: from inet-141-146-46-1.oracle.com by acsmt350.oracle.com with ESMTP id 3697384991214062687; Sat, 21 Jun 2008 08:38:07 -0700 Original-Received: from dradamslap1 (/24.5.171.3) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 21 Jun 2008 08:38:07 -0700 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <485CF670.3010602@gmx.at> Thread-Index: AcjToQqI1oIQIio3RCSnKQTklWdESwACZmPA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Resent-Date: Sat, 21 Jun 2008 11:47:20 -0400 X-BeenThere: bug-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:18481 Archived-At: > >>This happens by design. The driving idea behind is, that > >>the numbers of lines for displaying buffers should remain > >>unaltered when menu-/toolbars are added/removed. There were > >>discussions about the desired behavior in > >>the past but no conclusion as far as I recall. I don't agree that it happens by design, unless you mean that it happens just because it happens and no one has fixed it yet. ;-) AFAICT, it was agreed in the previous discussion that this bug should be fixed, but we haven't yet found the right time to do it. Eli mentioned also that it might be difficult to fix this (treat menu-bar like tool-bar) completely for some platforms because of the difference between handling pixels and chars. > > Oops! sorry then. I do not want to re-open the topic. > > You can't ;-) It's still unclosed, see > http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=25 > > > I personally think that behavior is not correct because > > many visual non-desired effects are produced. > > ISTR bad interaction with some window managers. AFAICT, people agreed that the menu-bar should be treated like the tool-bar is, but that might be difficult to do precisely (pixel vs char) for some platforms. Eli mentioned that he seemed to remember that the size of the menu-bar "may not be known to some toolkits, so resizing the text area might be tricky". He called the current behavior a "misfeature", and lamented the fact that this hadn't yet been fixed after several years (+ two more years now). The reason he gave for not fixing it, however, was just that fixing it then would have been ill-timed, so close to the release, especially on top of other display-related changes at that time. > > For example if you change to another buffer which has a > > bigger "tool-bar" that > > needs two lines, all text is moved up and down. > > Can you explain this in more detail? > > > Unfortunately, I do not know the reason why emacs is > > "line-oriented" instead of being "window-representa- > > tion independent". > > Quite often you want an exact text-layout within a window. > For example, you might want windows to display exactly 80 > columns of buffer text. > Adding/removing scroll-bars shouldn't change that. And what holds for > the width of windows should probably also hold for their height. That might be one use case, for some people. If so, it is also an argument against the current way of handling the tool-bar. You can't have it both ways. If there are such use cases, then we should let users decide the behavior using a user option. I and some others clearly have a different use case from that and prefer that the frame size be left alone - for menu-bar (bugged) as well as tool-bar (OK). We seem somehow to have wandered from "Yes, we'd all like to fix this but that would be difficult right now" to "No, it's the way it is by design, because some people want the number of displayed lines to remain constant." Let's be honest: This has been flagged as a bug that should be fixed for a long time. The current behavior obviously does not suit at least some people. David's example of the frame being resized larger than "maximum" so the minibuffer disappears is one more testimonial. If someone can fix this bug, then we should fix it. If some people actually prefer the bugged behavior, then we can create a user option so that users can decide for themselves. But let's not use the fact that some people might prefer the bugged behavior as a rationale not to fix the bug. And if this bug is just too difficult to fix - for whatever reason, then let's note that clearly, with the precise reasons, so revisionist history doesn't pop up from time to time. FWIW, the emacs-devel thread referring to this (there are apparently other, older threads also) in 2006-06 and 2007-07 is: "frame parameter menu-bar-lines changes height of frame".