From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Anders Lindgren Newsgroups: gmane.emacs.bugs Subject: bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame Date: Mon, 14 Sep 2015 16:45:33 +0200 Message-ID: References: <55F5B9DF.5020001@gmx.at> <55F6860D.9060503@gmx.at> <55F6CE22.1070502@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11434d2026080e051fb61e48 X-Trace: ger.gmane.org 1442241980 7895 80.91.229.3 (14 Sep 2015 14:46:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Sep 2015 14:46:20 +0000 (UTC) Cc: Keith David Bershatsky , 21415@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Sep 14 16:46:12 2015 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 1ZbV1H-0002at-7b for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Sep 2015 16:46:11 +0200 Original-Received: from localhost ([::1]:41392 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbV1G-0003qp-AZ for geb-bug-gnu-emacs@m.gmane.org; Mon, 14 Sep 2015 10:46:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbV1B-0003o5-7K for bug-gnu-emacs@gnu.org; Mon, 14 Sep 2015 10:46:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbV18-0001Bp-Bu for bug-gnu-emacs@gnu.org; Mon, 14 Sep 2015 10:46:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39975) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbV18-0001Bf-93 for bug-gnu-emacs@gnu.org; Mon, 14 Sep 2015 10:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZbV17-0000VJ-Vx for bug-gnu-emacs@gnu.org; Mon, 14 Sep 2015 10:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Anders Lindgren Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Sep 2015 14:46:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21415 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21415-submit@debbugs.gnu.org id=B21415.14422419391907 (code B ref 21415); Mon, 14 Sep 2015 14:46:01 +0000 Original-Received: (at 21415) by debbugs.gnu.org; 14 Sep 2015 14:45:39 +0000 Original-Received: from localhost ([127.0.0.1]:60418 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbV0i-0000Uf-Sx for submit@debbugs.gnu.org; Mon, 14 Sep 2015 10:45:37 -0400 Original-Received: from mail-vk0-f49.google.com ([209.85.213.49]:36142) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZbV0g-0000UX-FN for 21415@debbugs.gnu.org; Mon, 14 Sep 2015 10:45:35 -0400 Original-Received: by vkfp126 with SMTP id p126so60134743vkf.3 for <21415@debbugs.gnu.org>; Mon, 14 Sep 2015 07:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IraJYGBRgdUGAsB7QlvoP8cXqX1d0j6kURmrL7dvFlY=; b=sDrrSgU4e2EVli9fmC+Hv84Ty6HnlzwCGBTZSgnJMHFIIMzmdf/CPiGOl3MV20b/yV 4LAFcLeGM15N6fpqzxav3W/7NdvXl98F4yUgJCIMPHAWtTZKXw5Y8bYsYxYhECQIxkLF USWbq5/8cDQ1TSU4DUzshzbF0UvE6ydsutmkBm5RzfWHE6LheB8NWgffrsx0C1B+RNWM +gIXgCfMEd44r8x/T9TkHsRwbfdmmT/rsjcdcV4Dpm+Xn2eUpRc3QGkeuQDZuL3MVNDH v4Qg3mLYmgTbmleSwWWLXYwQTanFSY+TcgDD0G0TncXGO6EA2ZpdNWNVTJ50mjgLKANh MCtQ== X-Received: by 10.31.174.135 with SMTP id x129mr13708103vke.26.1442241933865; Mon, 14 Sep 2015 07:45:33 -0700 (PDT) Original-Received: by 10.31.139.21 with HTTP; Mon, 14 Sep 2015 07:45:33 -0700 (PDT) In-Reply-To: <55F6CE22.1070502@gmx.at> 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: 208.118.235.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:106536 Archived-At: --001a11434d2026080e051fb61e48 Content-Type: text/plain; charset=UTF-8 On Mon, Sep 14, 2015 at 3:39 PM, martin rudalics wrote: > >>> No, ns-auto-hide-menu-bar does not move the frame at all. > >> > >> OK. But doesn't it remove the constraint that a frame's rectangle must > >> start somehwere at or below (0, 0)? > > > > When the menu bar is visible, OS X doesn't allow windows above the menu > > bar. > > I'm not sure I understand: Do you mean here "OS X doesn't allow windows > above the top of the screen"? It's not possible to place a window above the top of the screen if the menu bar is visible. (If I remember correctly, I haven't worked in this for quite some time.) > However, OS X allows an application to place a window above the > > top of the screen -- the code in Emacs simply ensures that Emacs itself > > doesn't hinder this. > > Does this "OS X allows an application to place a window above the top of > the screen" hold _only_ when the menu bar is hidden or does it hold > regardless of that? What's such a restriction good for anyway? Only when it is hidden (again, if I remember correctly). The reason, I guess, is to ensure that no application would ever land underneath the menu bar. > > -- the code in Emacs simply ensures that Emacs itself > > doesn't hinder this. > > Because Emacs "normally" advices OS X to constrain the frame to the > screen. Correct? No, not really. A frame can stretch below the screen, and (I have to double-check this one when I get home) to either side. When the menu bar is hidden, you can also do this above the screen. > > By the way, when I use Win32, I also place the title bar above the top of > > the screen, > > Why? Do you never use the fullscreen feature? No, never. The reason is that I want the Emacs frame to use maximal height, but at the same time I like to control the width so that I can have six side-by-side windows each with exactly 79 columns. (I use two 1600x1200 monitors and a 6x8 font, with the help of Follow mode I can see 888 consecutive lines of code.) > so this is not a feature that is unique to the OS X port. Of > > course, for a frame the be placed above the top of the screen, the user > > must explicitly placed it there. A frame should never "just happen" to be > > placed above the top of the screen. > > It will happen when it's too large and you specify negative values for > its position. Yes, but I would see that as though the user explicitly has asked for that case. The important thing is that it doesn't happen when a user creates a new frame using `C-x 5 2' or call `make-frame' with default parameters etc. / Anders --001a11434d2026080e051fb61e48 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Sep 14, 2015 at 3:39 PM, martin rudalics <rudalics@gmx.at> wrote:
>>> No, ns-auto-hide= -menu-bar does not move the frame at all.
>>
>> OK.=C2=A0 But doesn't it remove the constraint that a frame= 9;s rectangle must
>> start somehwere at or below (0, 0)?
>
> When the menu bar is visible, OS X doesn't allow windows above the= menu
> bar.

 I'm not sure I understand: Do you mean here "OS X doesn't allo= w windows
above the top of the screen"?

It's= not possible to place a window above the top of the screen if the menu bar= is visible. (If I remember correctly, I haven't worked in this for qui= te some time.)
=C2=A0

= > However, OS X allows an application to place a window= above the
> top of the screen -- the code in Emacs simply ensures that Emacs itsel= f
> doesn't hinder this.

 Does this "OS X allows an application to place a window above the top = of
the screen" hold _only_ when the menu bar is hidden or does it hold regardless of that?=C2=A0 What's such a restriction good for anyway?

Only when it is hidden (again, if I remember = correctly). The reason, I guess, is to ensure that no application would eve= r land underneath the menu bar.

=C2=A0
> -- the code in Emacs simply ensures that E= macs itself
> doesn't hinder this.

 Because Emacs "normally" advices OS X to constrain the frame to t= he
screen.=C2=A0 Correct?

No, not really. A fr= ame can stretch below the screen, and (I have to double-check this one when= I get home) to either side.

When the menu bar is = hidden, you can also do this above the screen.

=C2= =A0
> By the way, when I use Win3= 2, I also place the title bar above the top of
> the screen,

 Why?=C2=A0 Do you never use the fullscreen feature?

No, never.

The reason is that I want the = Emacs frame to use maximal height, but at the same time I like to control t= he width so that I can have six side-by-side windows each with exactly 79 c= olumns. (I use two 1600x1200 monitors and a 6x8 font, with the help of Foll= ow mode I can see 888 consecutive lines of code.)

=
> so this is not a feature t= hat is unique to the OS X port. Of
> course, for a frame the be placed above the top of the screen, the use= r
> must explicitly placed it there. A frame should never "just happe= n" to be
> placed above the top of the screen.

 It will happen when it's too large and you specify negative values for<= br> its position.

Yes, but I would see that as = though the user explicitly has asked for that case.

The important thing is that it doesn't happen when a user creates a n= ew frame using `C-x 5 2' or call `make-frame' with default paramete= rs etc.

/ Anders

<= /div> --001a11434d2026080e051fb61e48--