bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

I am trying to do three things:

(1) efficiently create a new frame that is exact as to pixelwise width/height so that `(set-frame-size FRAME WIDTH PIXELWISE)` is not needed after each new frame is created;

(2) pass a pixelwise argument to `x-create-frame` that would resolve the first goal [?];

(3) avoid intermittent visual flickering of the entire frame that is caused by a frame creation at the default size of `(width . 80) (height . 35)` followed immediately by programmatically enlarging the frame substantially with `set-frame-size` using the pixelwise argument.  [The intermittent visual flickering can be avoided by setting the `mode-line-format` to `nil`; however, the default `mode-line-format` causes/contributes to the visual flickering.]  [This did not happen with the Emacs Trunk from last year, but happens now intermittently with a current version.]

Thanks,

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

In GNU Emacs 25.0.50.1 (x86_64-apple-darwin10.8.0, NS appkit-1038.36 Version 10.6.8 (Build 10K549))
 of 2015-08-29 on server.private
Repository revision: 24ae05251587fbba4687544ec57565c8bc48071a
Windowing system distributor `Apple', version 10.3.1038
Configured using:
 `configure --with-ns --without-imagemagick'

Configured features:
DBUS ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  locale-coding-system: utf-8-unix

Major mode: FM

Minor modes in effect:
  tb-mode: t
  sb-mode: t
  ml-mode: t
  ds-mode: t
  sd-mode: t
  bc-mode: t

Recent messages:
*beep*
Quit: "lawlist-line-move -- lawlist-beginning-of-buffer"
*beep*
Quit: "lawlist-line-move -- lawlist-beginning-of-buffer"
*beep*
Quit: "lawlist-line-move -- lawlist-beginning-of-buffer"
Wrote /Users/HOME/.0.data/.0.emacs/.scratch
Emacs:  Emacs Trunk -- pixelwise width/height fo . . .
*beep*
Making completion list...

Load-path shadows:
None found.

Features:
(shadow emacsbug sendmail .multiple_cursors lawlist-ztree lawlist-yas
lawlist-ws lawlist-wl elmo-imap4 elmo-localdir modb-standard
modb-legacy elmo-internal elmo-flag mmelmo-imap mmelmo-buffer
elsp-generic mel-u ps-print ps-def lpr epg-config enriched lawlist-w3m
doc-view image-mode ccl lawlist-vl lawlist-view lawlist-undo
lawlist-txt lawlist-tm lawlist-tex compare-w lawlist-tabbar
lawlist-speedbar lawlist-shell info esh-groups ehelp ange-ftp
lawlist-sgml lawlist-sb lawlist-saveplace lawlist-ruler
lawlist-replace lawlist-rectangle lawlist-re-builder lawlist-python
skeleton lawlist-profiler lawlist-print lawlist-php cl-seq
lawlist-perl lawlist-parens lawlist-org lawlist-calendar org-agenda
org org-macro org-footnote org-pcomplete org-list org-faces
org-entities org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-src ob-keys ob-comint ob-core ob-eval org-compat
org-macs org-loaddefs find-func holidays hol-loaddefs cal-menu
calendar cal-loaddefs lawlist-neotree lawlist-movement lawlist-mouse
lawlist-ml lawlist-minibuffer lawlist-misc lawlist-messages lawlist-mc
rect lawlist-markdown noutline outline lawlist-lorem lawlist-ln
lawlist-keymap lawlist-js lawlist-ispell lawlist-isearch lawlist-imenu
lawlist-ibuffer lawlist-hl lawlist-grep lawlist-git ido vc-git vc
vc-dispatcher thingatpt time-stamp subr-x server nntp gnus-group
gnus-undo gnus-start gnus-cloud nnimap nnmail mail-source tls utf7
netrc parse-time gnus-spec gnus-int gnus-range gnus-win nnoo mm-view
mml-smime smime dig mailcap log-view log-edit message mml mml-sec
mm-decode mm-bodies mm-encode gmm-utils mailheader pcvs-util add-log
ldap json grep compile find-lisp ediff-merg ediff-wind ediff-diff
ediff-mult ediff-help ediff-init ediff-util ediff diff-mode conf-mode
autorevert filenotify lawlist-frameset lawlist-framebase
lawlist-framebufs lawlist-frame lawlist-font-lock lawlist-fm
lawlist-faces lawlist-env lawlist-elscreen lawlist-elisp lawlist-dv
jka-compr lawlist-image cl-macs lawlist-files zeroconf dbus xml
lawlist-ds lawlist-dired dired format-spec lawlist-desktop frameset
lawlist-debug lawlist-window debug lawlist-css smie lawlist-compile rx
lawlist-color lawlist-cm gv lawlist-cc cc-langs cc-mode cc-fonts
cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
cc-bytecomp lawlist-calc lawlist-calc+ lawlist-bk lawlist-bc
lawlist-bbdb gnus gnus-ems nnheader mail-utils wid-edit mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev mail-extr rfc822
timezone lawlist-auth gnus-util mm-util help-fns mail-prsvr
password-cache lawlist-as lawlist-archive lawlist-+ lawlist-lcl
byte-opt bytecomp byte-compile cl-extra seq cconv lawlist-help
disp-table easy-mmode edmacro kmacro quail help-mode easymenu
cl-loaddefs cl-lib pcase derived advice shell pcomplete comint
ansi-color ring savehist time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese
eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook
help simple abbrev minibuffer cl-preloaded nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 2227445 234500)
 (symbols 48 87489 0)
 (miscs 40 380 422)
 (strings 32 196673 24233)
 (string-bytes 1 7265947)
 (vectors 16 41082)
 (vector-slots 8 987798 14925)
 (floats 8 2462 974)
 (intervals 56 817 362)
 (buffers 976 18))

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I am trying to do three things:
 >
 > (1) efficiently create a new frame that is exact as to pixelwise
 > width/height so that `(set-frame-size FRAME WIDTH PIXELWISE)` is not
 > needed after each new frame is created;

Interesting.  This is the first time someone asks for this.  Do you have
a particular use case?

 > (2) pass a pixelwise argument to `x-create-frame` that would resolve
 > the first goal [?];

We'd need a ‘pixel-width’ and a ‘pixel-height’ frame parameter.  When
any of these is present, it would be used instead of the ‘width’ and
‘height’ parameters.  Alternatively, we could interpret floating point
values of ‘width’ and ‘height’ specially.

 > (3) avoid intermittent visual flickering of the entire frame that is
 > caused by a frame creation at the default size of `(width . 80)
 > (height . 35)` followed immediately by programmatically enlarging the
 > frame substantially with `set-frame-size` using the pixelwise
 > argument.  [The intermittent visual flickering can be avoided by
 > setting the `mode-line-format` to `nil`; however, the default
 > `mode-line-format` causes/contributes to the visual flickering.]
 > [This did not happen with the Emacs Trunk from last year, but happens
 > now intermittently with a current version.]

Could you try bisecting to find out when this started?

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

In my opinion, it would be useful to set the frame specifications exactly at the time of creation -- rather than fix it after the fact with `set-frame-size` using the pixelwise argument.

My particular immediate use case is to simply fill the screen exactly (on OSX, XP, and Windows 7).  In my testing, `toggle-frame-maximized` was never as accurate as `set-frame-size` using the pixelwise argument.  I would imagine there are other situations where a user may wish to create a frame with exact specifications to fit precisely into a specific location on the screen, without the need to fix it after the fact.

I have a test that identifies the current operating system and screen sizes on my different machines, and I have already determined exactly how many Emacs frame pixels fill the screen based on other factors such as font, fringe widths, no scroll bars, and no menu-bar.  The general approach has been to take the initial frame or subsequently created frames and use `set-frame-size` with the pixelwise argument to blow it up to the preferred size.  It sure would be nice, however, to set the pixel width/height along with the other frame parameters both programmatically (passing as parameters to `make-frame`), and as part of the `initial-frame-alist` and `default-frame-alist`.

I would still use `set-frame-size` with the pixelwise argument for functions where contraction/expansion of frames is needed -- e.g., I have a custom reduce-all-frame-size function and a custom maximize-all-frame-size function.  That is handy for me to see other programs without completely hiding Emacs, and then to restore it again to full size when I'm done with those other programs.

I don't fully understand the floating point because the pixels are whole numbers, rather than decimals -- this is probably because I'm just a hobbyist, not a real programmer.  But yes, a frame-parameter for pixel width and pixel height would be awesome.

Last weekend, I learned how to build Emacs from any point in time based on a particular commit; and, I also learned the layman's way to download prebuilt nightlies from http://emacsformacosx.com/  I'd be happy to work on pinpointing when the intermittent flickering began, and will spend a little time on that project each day.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Fri, 04 Sep 2015 21:17:51 +0200,
martin rudalics wrote:
> 
>  > I am trying to do three things:
>  >
>  > (1) . . . 
> 
> Interesting.  This is the first time someone asks for this.  Do you have
> a particular use case?
> 
>  > (2) . . . 
> 
> We'd need a ‘pixel-width' and a ‘pixel-height' frame parameter.  When
> any of these is present, it would be used instead of the ‘width' and
> ‘height' parameters.  Alternatively, we could interpret floating point
> values of ‘width' and ‘height' specially.
> 
>  > (3) . . . 
> 
> Could you try bisecting to find out when this started?

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 3767 bytes --]

 > In my opinion, it would be useful to set the frame specifications
 > exactly at the time of creation -- rather than fix it after the fact
 > with `set-frame-size` using the pixelwise argument.

Agreed.

 > My particular immediate use case is to simply fill the screen exactly
 > (on OSX, XP, and Windows 7).  In my testing, `toggle-frame-maximized`
 > was never as accurate as `set-frame-size` using the pixelwise
 > argument.

I was afraid that would be your concern.  ‘toggle-frame-maximized’
should work precisely.  Can you provide me more details wrt how it
doesn't achieve its goal?

 > I would imagine there are other situations where a user may
 > wish to create a frame with exact specifications to fit precisely into
 > a specific location on the screen, without the need to fix it after
 > the fact.

Basically a tiling window manager should do that.  But I'm not against
providing such a service.

 > I have a test that identifies the current operating system and screen
 > sizes on my different machines, and I have already determined exactly
 > how many Emacs frame pixels fill the screen based on other factors
 > such as font, fringe widths, no scroll bars, and no menu-bar.

The problem is that with Emacs it's pretty hard to do that reliably.
Knowing the exact sizes of each and every component on the various
platforms is a pain.  For example, I doubt that you are able to
calculate the height of your tool bar beforehand - I never was.  Or, do
you know the size of the external border of a frame on OS X?

I try to address most of these in the function ‘frame-geometry’.  Does
that return good results on OS X?  Also note that you have to subtract
one default scroll bar width/height, the fringe widths and the internal
border width in order to convert the frame's outer width (the one you
see on the screen) to its native width (the one you set via frame
parameters).

 > The
 > general approach has been to take the initial frame or subsequently
 > created frames and use `set-frame-size` with the pixelwise argument to
 > blow it up to the preferred size.  It sure would be nice, however, to
 > set the pixel width/height along with the other frame parameters both
 > programmatically (passing as parameters to `make-frame`), and as part
 > of the `initial-frame-alist` and `default-frame-alist`.

OK.

 > I don't fully understand the floating point because the pixels are
 > whole numbers, rather than decimals -- this is probably because I'm
 > just a hobbyist, not a real programmer.  But yes, a frame-parameter
 > for pixel width and pixel height would be awesome.

You would simply specify something like (height . 100.0) to get a 100
pixels high frame instead of (height . 6) to get a 6 columns high frame.
The advantage of the floating point idea over a separate ‘pixel-width’ /
‘pixel-height’ approach would be twofold:

(1) Technically, Emacs wouldn't have to care about whether a ‘width’
entry in ‘initial-frame-alist’ should override a ‘pixel-width’ entry in
‘default-frame-alist’.

(2) The user doesn't have to investigate these lists to check for the
presence of another entry.

I attach a simple patch based on this kludge so if you can build Emacs
you can try it with something like

(make-frame '((width . 400.0) (height . 200.0)))

 > Last weekend, I learned how to build Emacs from any point in time
 > based on a particular commit; and, I also learned the layman's way to
 > download prebuilt nightlies from http://emacsformacosx.com/ I'd be
 > happy to work on pinpointing when the intermittent flickering began,
 > and will spend a little time on that project each day.

That would be fine.

Thanks, martin

[-- Attachment #2: frame.c.diff --]
[-- Type: text/plain, Size: 1191 bytes --]

diff --git a/src/frame.c b/src/frame.c
index 4a526e2..bac2b24 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -537,6 +537,8 @@ adjust_frame_size (struct frame *f, int new_width, int new_height, int inhibit,
 	}
 #endif
     }
+  else if (new_cols != old_cols)
+    call2 (Qwindow_pixel_to_total, frame, Qt);
 
   if (new_windows_height != old_windows_height
       /* When the top margin has changed we have to recalculate the top
@@ -551,6 +553,8 @@ adjust_frame_size (struct frame *f, int new_width, int new_height, int inhibit,
       if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f))
 	FrameRows (FRAME_TTY (f)) = new_lines + FRAME_TOP_MARGIN (f);
     }
+  else if (new_lines != old_lines)
+    call2 (Qwindow_pixel_to_total, frame, Qnil);
 
   frame_size_history_add
     (f, Qadjust_frame_size_3, new_text_width, new_text_height,
@@ -4831,6 +4835,7 @@ syms_of_frame (void)
   DEFSYM (Qframep, "framep");
   DEFSYM (Qframe_live_p, "frame-live-p");
   DEFSYM (Qframe_windows_min_size, "frame-windows-min-size");
+  DEFSYM (Qwindow_pixel_to_total, "window--pixel-to-total");
   DEFSYM (Qexplicit_name, "explicit-name");
   DEFSYM (Qheight, "height");
   DEFSYM (Qicon, "icon");

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

With respect to the patch, I believe it was applied successfully -- I selected the option "y".

     SHELL-PROMPT: emacs HOME$ patch -p1 < frame.c.diff

     patching file src/frame.c

     Reversed (or previously applied) patch detected!  Assume -R? [n] y

     Hunk #3 succeeded at 4840 (offset 9 lines).

I believe that `x-create-frame' is expecting an integer:

     Debugger entered--Lisp error: (wrong-type-argument integerp 400.0)
       x-create-frame(((visibility) (width . 400.0) (height . 200.0)))
       x-create-frame-with-faces(((width . 400.0) (height . 200.0)))
       #[257 "\300\x01!\207" [x-create-frame-with-faces] 3 "\n\n(fn PARAMS)"](((width . 400.0) (height . 200.0)))
       apply(#[257 "\300\x01!\207" [x-create-frame-with-faces] 3 "\n\n(fn PARAMS)"] ((width . 400.0) (height . 200.0)))
       frame-creation-function(((width . 400.0) (height . 200.0)))
       make-frame(((width . 400.0) (height . 200.0)))
       eval((make-frame (quote ((width . 400.0) (height . 200.0)))) nil)
       eval-expression((make-frame (quote ((width . 400.0) (height . 200.0)))) nil)
       funcall-interactively(eval-expression (make-frame (quote ((width . 400.0) (height . 200.0)))) nil)
       call-interactively(eval-expression nil nil)
       command-execute(eval-expression)

With respect to the other issues, I will spend some time familiarizing myself with the geometry function and get back to you on those.

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

 > With respect to the patch, I believe it was applied successfully -- I selected the option "y".
 >
 >       SHELL-PROMPT: emacs HOME$ patch -p1 < frame.c.diff
 >
 >       patching file src/frame.c
 >
 >       Reversed (or previously applied) patch detected!  Assume -R? [n] y

Strange.  Are you sure you had a pristine frame.c?  What does git diff
give for your Emacs tree?

 >       Hunk #3 succeeded at 4840 (offset 9 lines).

If you have no private changes in frame.c do a C-x v u in a buffer
showing frame.c and afterwards do

git apply frame.c.diff

followed by make.

 > I believe that `x-create-frame' is expecting an integer:
 >
 >       Debugger entered--Lisp error: (wrong-type-argument integerp 400.0)

That would indicate that my patch was not applied or you did not build
Emacs correctly afterwards.  In any case I attach the patch again.

martin

[-- Attachment #2: frame.c.diff --]
[-- Type: text/plain, Size: 1191 bytes --]

diff --git a/src/frame.c b/src/frame.c
index 4a526e2..bac2b24 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -537,6 +537,8 @@ adjust_frame_size (struct frame *f, int new_width, int new_height, int inhibit,
 	}
 #endif
     }
+  else if (new_cols != old_cols)
+    call2 (Qwindow_pixel_to_total, frame, Qt);
 
   if (new_windows_height != old_windows_height
       /* When the top margin has changed we have to recalculate the top
@@ -551,6 +553,8 @@ adjust_frame_size (struct frame *f, int new_width, int new_height, int inhibit,
       if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f))
 	FrameRows (FRAME_TTY (f)) = new_lines + FRAME_TOP_MARGIN (f);
     }
+  else if (new_lines != old_lines)
+    call2 (Qwindow_pixel_to_total, frame, Qnil);
 
   frame_size_history_add
     (f, Qadjust_frame_size_3, new_text_width, new_text_height,
@@ -4831,6 +4835,7 @@ syms_of_frame (void)
   DEFSYM (Qframep, "framep");
   DEFSYM (Qframe_live_p, "frame-live-p");
   DEFSYM (Qframe_windows_min_size, "frame-windows-min-size");
+  DEFSYM (Qwindow_pixel_to_total, "window--pixel-to-total");
   DEFSYM (Qexplicit_name, "explicit-name");
   DEFSYM (Qheight, "height");
   DEFSYM (Qicon, "icon");

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

With respect to your inquiry about `frame-geometry' on OSX, I tested the outer frame dimensions with an applescript using the feature request of bug number 18283 -- the results of getting the bounds with an applescript were the same as those returned by `frame-geometry' for the outer frame pixel width/height.  So that aspect of `frame-geometry' is correct on OSX 10.6.8 Snow Leopard Server.  I did not test the other aspects of `frame-geometry'.

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > With respect to your inquiry about `frame-geometry' on OSX, I tested
 > the outer frame dimensions with an applescript using the feature
 > request of bug number 18283

You really should send a patch for that bug.  If noone objects I'll
apply it in a few days.  Few people here build on OS X and still fewer
write Applescripts.

 > -- the results of getting the bounds with
 > an applescript were the same as those returned by `frame-geometry' for
 > the outer frame pixel width/height.  So that aspect of
 > `frame-geometry' is correct on OSX 10.6.8 Snow Leopard Server.  I did
 > not test the other aspects of `frame-geometry'.

You will need them to be able to translate from the outer frame pixel
width/height to the native width/height.  It's the latter you specify in
the width/height parameters.  So you have to subtract the width of the
external border and the title bar from the outer width/height to get the
desired native width/height.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Using a brand new download of the Emacs master repository and a fresh copy of the patch, I ran:

git apply frame.c.diff

  error: patch failed: src/frame.c:537
  error: src/frame.c: patch does not apply

I also tried using a third-party program called Tower.app, and the result was the same error message.


I ran:  git diff

and I received no output, and was just returned to a new command prompt.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Sun, 06 Sep 2015 21:26:54 +0200,
martin rudalics wrote:
> 
>  > With respect to the patch, I believe it was applied successfully -- I selected the option "y".
>  >
>  >       [* * *]HOME$ patch -p1 < frame.c.diff
>  >
>  >       patching file src/frame.c
>  >
>  >       Reversed (or previously applied) patch detected!  Assume -R? [n] y
> 
> Strange.  Are you sure you had a pristine frame.c?  What does git diff
> give for your Emacs tree?
> 
>  >       Hunk #3 succeeded at 4840 (offset 9 lines).
> 
> If you have no private changes in frame.c do a C-x v u in a buffer
> showing frame.c and afterwards do
> 
> git apply frame.c.diff
> 
> followed by make.
> 
> * * *

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 384 bytes --]

 > Using a brand new download of the Emacs master repository and a fresh copy of the patch, I ran:
 >
 > git apply frame.c.diff
 >
 >    error: patch failed: src/frame.c:537
 >    error: src/frame.c: patch does not apply

My apologies.  I've sent you a completely unrelated old patch while the
new one happened to end up in the wrong directory.  The present one
should be OK.

martin

[-- Attachment #2: frame.c.diff --]
[-- Type: text/plain, Size: 1676 bytes --]

diff --git a/src/frame.c b/src/frame.c
index d3e4780..1cd7c36 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -4582,20 +4582,40 @@ x_figure_window_size (struct frame *f, Lisp_Object parms, bool toolbar_p)
     {
       if (!EQ (width, Qunbound))
 	{
-	  CHECK_NUMBER (width);
-	  if (! (0 <= XINT (width) && XINT (width) <= INT_MAX))
-	    xsignal1 (Qargs_out_of_range, width);
+	  if (FLOATP (width))
+	    {
+	      if (XFLOAT_DATA (width) < 0 || (int) XFLOAT_DATA (width) > INT_MAX)
+		xsignal1 (Qargs_out_of_range, width);
+	      else
+		SET_FRAME_WIDTH (f, (int) XFLOAT_DATA (width));
+	    }
+	  else
+	    {
+	      CHECK_NUMBER (width);
+	      if (! (0 <= XINT (width) && XINT (width) <= INT_MAX))
+		xsignal1 (Qargs_out_of_range, width);

-	  SET_FRAME_WIDTH (f, XINT (width) * FRAME_COLUMN_WIDTH (f));
+	      SET_FRAME_WIDTH (f, XINT (width) * FRAME_COLUMN_WIDTH (f));
+	    }
 	}

       if (!EQ (height, Qunbound))
 	{
-	  CHECK_NUMBER (height);
-	  if (! (0 <= XINT (height) && XINT (height) <= INT_MAX))
-	    xsignal1 (Qargs_out_of_range, height);
+	  if (FLOATP (height))
+	    {
+	      if (XFLOAT_DATA (height) < 0 || (int) XFLOAT_DATA (height) > INT_MAX)
+		xsignal1 (Qargs_out_of_range, height);
+	      else
+		SET_FRAME_HEIGHT (f, (int) XFLOAT_DATA (height));
+	    }
+	  else
+	    {
+	      CHECK_NUMBER (height);
+	      if (! (0 <= XINT (height) && XINT (height) <= INT_MAX))
+		xsignal1 (Qargs_out_of_range, height);

-	  SET_FRAME_HEIGHT (f, XINT (height) * FRAME_LINE_HEIGHT (f));
+	      SET_FRAME_HEIGHT (f, XINT (height) * FRAME_LINE_HEIGHT (f));
+	    }
 	}

       user_size = x_get_arg (dpyinfo, parms, Quser_size, 0, 0, RES_TYPE_NUMBER);

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

The latest patch was successfully applied, and building occurred without incident.

When using the setting of `(setq ns-auto-hide-menu-bar t)` and a `make-frame` with pixelwise parameters for width/height, the result when creating large frames -- (width 1909.0) (height . 1060.0) -- is a frame that is one-half above the screen (out of sight) and one-half of the frame is showing.  Adding a parameter of (top . 0) has no affect.

The pixelwise frame parameters of width/height for `make-frame` are not behaving precisely -- e.g., a height specification of (height . 1059.0) is 14 pixels shy of filling the entire screen [i.e., 1066 pixels outer width]; and a height specification of (height . 1060.0) is 6 pixels larger than the full screen [i.e., 1086 pixels outer width].  It is not presently possible to create a frame that precisely fills the entire screen using the patch as-is.

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > When using the setting of `(setq ns-auto-hide-menu-bar t)`

Is this necessary to trigger the behavior?

 > and a
 > `make-frame` with pixelwise parameters for width/height, the result
 > when creating large frames -- (width 1909.0) (height . 1060.0) -- is a
 > frame that is one-half above the screen (out of sight) and one-half of
 > the frame is showing.  Adding a parameter of (top . 0) has no affect.

Probably because, as you say below, a height of 1060.0 makes the frame
have 1086 pixels outer height which is too large for your screen.

 > The pixelwise frame parameters of width/height for `make-frame` are
 > not behaving precisely -- e.g., a height specification of (height
 > . 1059.0) is 14 pixels shy of filling the entire screen [i.e., 1066
 > pixels outer width]; and a height specification of (height . 1060.0)
 > is 6 pixels larger than the full screen [i.e., 1086 pixels outer
 > width].  It is not presently possible to create a frame that precisely
 > fills the entire screen using the patch as-is.

I don't know how you calculated your values but I'll try to explain
what happens here.  Suppose with emacs -Q I do

(make-frame '((width . 599.0) (height . 399.0)))

Then I get a frame where

(let ((edges (frame-edges nil 'native-edges)))
   (cons (- (nth 2 edges) (nth 0 edges))
	(- (nth 3 edges) (nth 1 edges))))

returns (631 . 435).  The difference between the widths 631 and 599 is
32 pixels.  These consist of 16 pixels for one scroll bar, 8 pixels for
a left and 8 pixels for a right fringe.  The difference between the
heights 435 and 399 is 36.  This is exactly the height of my tool bar.

Evaluating

(let ((edges (frame-edges nil 'outer-edges)))
   (cons (- (nth 2 edges) (nth 0 edges))
	(- (nth 3 edges) (nth 1 edges))))

yields (639 . 481).  So the difference between outer (639) and native
(631) width is 8 pixels which is twice the size of the frame's external
border (4).  The difference between outer (481) and native (435) height
is 46 which equals twice the external border size (2 * 4) plus the title
bar height (19) and the menu bar height (19).

The outer width/height is what you need.  Which results do you get when
you do the same calculations on your system?

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Yes, `(setq ns-auto-hide-menu-bar t)` is directly/indirectly related to the new large frame appearing one-half out of sight (above the top of the display).  Setting that variable to the default value of `nil` avoids the problem.  The behavior is not caused by the patch, but is something that I recently noticed (again) when trying to control the exact parameters upon frame creation.  I have been programmatically using `set-frame-position FRAME 0 0` following the creation of new frames to compensate for the inability to set the `top` correctly on frame creation.

With this feature request (#21415), I was hoping to incorporate the magic of `set-frame-size` with the pixelwise argument.  That function is magical because it lets a user precisely control the outer dimensions of a frame on OSX -- i.e., a user can make the outer dimensions exactly one or more pixels larger or smaller.

The patch, from what I understand, seeks to convert pixel specifications into the standard character width and standard text line height.  I believe that method cannot be used to precisely control the pixel outer dimensions of the frame.

The feature request (as I understand it) seeks to control the exact pixel height/width of the outer frame -- irregardless of the character width and text line height.  For example, the laptop that I am using today uses the following:  `(set-frame-size FRAME 1260 774 t)` to precisely fill the display.  The corresponding frame parameters are (width . 114) (height . 38); however, those are insufficient to fill the screen precisely.  I can get close (but no cigar) with (width . 114) (height . 38), and then I need to use `(set-frame-size FRAME 1260 774 t)` to fix what `make-frame` cannot accomplish.

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > With this feature request (#21415), I was hoping to incorporate the
 > magic of `set-frame-size` with the pixelwise argument.  That function
 > is magical because it lets a user precisely control the outer
 > dimensions of a frame on OSX -- i.e., a user can make the outer
 > dimensions exactly one or more pixels larger or smaller.

There is no magic at all in ‘set-frame-size’.  Just that at the time you
call that function all those annoying calculations like how large is my
title bar or the external border have been already done by the window
manager.  And ‘set-frame-size’ doesn't have to care about idiosyncrasies
like adding fringe or scroll bar widths.

 > The patch, from what I understand, seeks to convert pixel
 > specifications into the standard character width and standard text
 > line height.

No.  These values are set eventually just like when you call
‘set-frame-size’.

 > I believe that method cannot be used to precisely
 > control the pixel outer dimensions of the frame.

It can.  But if and only if you know, for example, how large the title
bar and the external borders are.

 > The feature request (as I understand it) seeks to control the exact
 > pixel height/width of the outer frame -- irregardless of the character
 > width and text line height.

The character width and text line height are not consulted.  Provided
you have set ‘frame-resize-pixelwise’ to t.

 > For example, the laptop that I am using
 > today uses the following: `(set-frame-size FRAME 1260 774 t)` to
 > precisely fill the display. The corresponding frame parameters are
 > (width . 114) (height . 38); however, those are insufficient to fill
 > the screen precisely.

These frame parameters contain rounded values.  Just ignore them.

 > I can get close (but no cigar) with (width
 > . 114) (height . 38), and then I need to use `(set-frame-size FRAME
 > 1260 774 t)` to fix what `make-frame` cannot accomplish.

Have you tried to do the calculations I sent you in my previous mail?
Once you've done them, ‘make-frame’ should be able to do what you want.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

I have tracked down the cause of the problem, but I do not know how to fix it.

`make-frame` with the patch is working correctly.  `x-create-frame-with-faces` does not deal with `font` when creating the frame, and `font` is dealt with after the fact by `face-set-after-frame-default`.  `face-set-after-frame-default` uses `set-face-attribute`, which is responsible for significantly changing the frame width/height

`(set-face-attribute 'default nil :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")`

I commented out the `set-face-attribute` section of `face-set-after-frame-default` to track down the problem.  Is there any way to prevent `set-face-attribute` from ruining the outer frame dimensions that are created with `make-frame`?

(setq ns-auto-hide-menu-bar t)

(set-frame-position
  (make-frame '(
    (font . "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
    (vertical-scroll-bars)
    (left-fringe . 8)
    (right-fringe . 8)
    (width . 1900.0)
    (height . 1054.0)
    (tool-bar-lines . 0)
         ))
  0 0)

I am using `set-frame-position` to compensate for `ns-auto-hide-menu-bar`, which prevents successfully setting `top` (and maybe `left`) as part of the `make-frame` parameters.

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Is there
 > any way to prevent `set-face-attribute` from ruining the outer frame
 > dimensions that are created with `make-frame`?

Customizing ‘frame-inhibit-implied-resize’ to t should accomplish that.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Thank you for the suggestion.  I tried:

    (setq frame-inhibit-implied-resize t)

    (setq-default frame-inhibit-implied-resize t)

    (setq frame-inhibit-implied-resize '(font font-backend internal-border-width menu-bar-lines tool-bar-lines))

However, evaluating the following still substantially increases the size of the frame:

    (set-face-attribute 'default nil :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")

The result is the same when evaluating the following -- i.e., the frame substantially increases in size when `font` is included in the parameters:

    (set-frame-position
     (make-frame '(
           (font . "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
           (frame-inhibit-implied-resize)
           (vertical-scroll-bars)
           (left-fringe . 8)
           (right-fringe . 8)
           (width . 1900.0)
           (height . 1054.0)
           (tool-bar-lines . 0)
           ))
     0 0)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Wed, 09 Sep 2015 08:27:37 +0200,
martin rudalics wrote:
> 
>  > Is there
>  > any way to prevent `set-face-attribute` from ruining the outer frame
>  > dimensions that are created with `make-frame`?
> 
> Customizing ‘frame-inhibit-implied-resize' to t should accomplish that.
> 
> martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > However, evaluating the following still substantially increases the size of the frame:
 >
 >      (set-face-attribute 'default nil :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")

Here the frame size remains unaltered.  What happens when you do that on
a maximized frame?  And what does evaluating

(progn
   (setq frame-size-history '(1000))
   (setq frame-inhibit-implied-resize t)
   (set-face-attribute 'default nil :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
   frame-size-history)

return?

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Step 1:  M-x toggle-frame-maximized

Step 2 [evaluate]:  (set-face-attribute 'default nil :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")

RESULT:  The frame substantially increases in size, going from maximized to extending well beyond the right edge of the screen.


Evaluating the following from a default frame when Emacs opens:

(progn
   (setq frame-size-history '(1000))
   (setq frame-inhibit-implied-resize t)
   (set-face-attribute 'default nil :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
   frame-size-history)

RESULT:

(998 (#<frame  *Minibuf-1* 0x104078830> adjust-frame-size-3 (560 560 880 700) (595 564 915 704)) (#<frame  *Minibuf-1* 0x104078830> adjust-frame-size-1 (560 560 880 700) (change-frame-size 5)))

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 398 bytes --]

 > Step 1:  M-x toggle-frame-maximized
 >
 > Step 2 [evaluate]:  (set-face-attribute 'default nil :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
 >
 > RESULT:  The frame substantially increases in size, going from maximized to extending well beyond the right edge of the screen.

That's bad.  Please try the attached patch (completely untested, might
crash your Emacs).

martin

[-- Attachment #2: nsterm.m.diff --]
[-- Type: text/plain, Size: 633 bytes --]

diff --git a/src/nsterm.m b/src/nsterm.m
index e90c3d7..196c30b 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -7612,8 +7612,9 @@ x_new_font (struct frame *f, Lisp_Object font_object, int fontset)
 
   /* Now make the frame display the given font.  */
   if (FRAME_NS_WINDOW (f) != 0 && ! [view isFullscreen])
-    x_set_window_size (f, false, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
-                       FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), true);
+    adjust_frame_size (f, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
+		       FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), 3,
+		       false, Qfont);
 
   return font_object;
 }

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

The patch of `nsterm.m` has repaired much of the functionality of `frame-inhibit-implied-resize`.  The two tests that previously failed now work as expected:

     1.  From a maximized frame, I can change the `font` to Courier 18 using `set-face-attribute` and there is no need to set `frame-inhibit-implied-resize` in that circumstance.

     2.  From a frame that is smaller than the screen size, I can use `set-face-attribute` to change the font to Courier 18 provided that `frame-inhibit-implied-resize` is set to `t`.

The problem I am having is with a situation where `ns-auto-hide-menu-bar` is set to `t`.  As previously noted in this thread, the `top` frame parameter is ignored when making a new frame that is the size of the screen -- the new frame appears substantially above the top of the display -- i.e., one-half out of sight.  When the new frame is partially above the top of the screen, `set-face-attribute` substantially enlarges the frame even though `frame-inhibit-implied-resize` is set to `t`.  When the frame comes back into full view (e.g., top 0, left 0), it is then possible to apply `set-face-attribute` without altering the dimensions of the frame.  The following are two examples -- one example works, the other example is broken -- both rely upon `ns-auto-hide-menu-bar` being set to `t`.

(setq ns-auto-hide-menu-bar t)

;; WORKS
(let* (
    (frame-inhibit-implied-resize t)
    (frame
      (make-frame '(
         (vertical-scroll-bars)
         (left-fringe . 8)
         (right-fringe . 8)
         (width . 1259.0)
         (height . 771.0)
         (tool-bar-lines . 0)))) )
  (set-frame-position frame 0 0)
  (set-face-attribute 'default frame :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1"))

;; BROKEN
(let* (
    (frame-inhibit-implied-resize t)
    (frame
      (make-frame '(
        (font . "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
        (vertical-scroll-bars)
        (left-fringe . 8)
        (right-fringe . 8)
        (width . 1259.0)
        (height . 771.0)
        (tool-bar-lines . 0)))) )
  (set-frame-position frame 0 0))

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 2963 bytes --]

 > The patch of `nsterm.m` has repaired much of the functionality of
 > `frame-inhibit-implied-resize`.  The two tests that previously failed
 > now work as expected:
 >
 >       1.  From a maximized frame, I can change the `font` to Courier
 >           18 using `set-face-attribute` and there is no need to set
 >           `frame-inhibit-implied-resize` in that circumstance.

I'm afraid that setting ‘frame-inhibit-implied-resize’ would't have
helped anyway in that case.

 >       2.  From a frame that is smaller than the screen size, I can use
 >           `set-face-attribute` to change the font to Courier 18
 >           provided that `frame-inhibit-implied-resize` is set to `t`.

OK.  Together with the two I sent earlier I attach one additional
change, this time for the tool bar.  You don't use it, so it shouldn't
affect you.  Nevertheless keep it included, it might have side effects.

 > The problem I am having is with a situation where
 > `ns-auto-hide-menu-bar` is set to `t`.  As previously noted in this
 > thread, the `top` frame parameter is ignored when making a new frame
 > that is the size of the screen -- the new frame appears substantially
 > above the top of the display -- i.e., one-half out of sight.  When the
 > new frame is partially above the top of the screen,
 > `set-face-attribute` substantially enlarges the frame even though
 > `frame-inhibit-implied-resize` is set to `t`.  When the frame comes
 > back into full view (e.g., top 0, left 0), it is then possible to
 > apply `set-face-attribute` without altering the dimensions of the
 > frame.  The following are two examples -- one example works, the other
 > example is broken -- both rely upon `ns-auto-hide-menu-bar` being set
 > to `t`.
 >
 > (setq ns-auto-hide-menu-bar t)
 >
 > ;; WORKS
 > (let* (
 >      (frame-inhibit-implied-resize t)
 >      (frame
 >        (make-frame '(
 >           (vertical-scroll-bars)
 >           (left-fringe . 8)
 >           (right-fringe . 8)
 >           (width . 1259.0)
 >           (height . 771.0)
 >           (tool-bar-lines . 0)))) )
 >    (set-frame-position frame 0 0)
 >    (set-face-attribute 'default frame :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1"))
 >
 > ;; BROKEN
 > (let* (
 >      (frame-inhibit-implied-resize t)
 >      (frame
 >        (make-frame '(
 >          (font . "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
 >          (vertical-scroll-bars)
 >          (left-fringe . 8)
 >          (right-fringe . 8)
 >          (width . 1259.0)
 >          (height . 771.0)
 >          (tool-bar-lines . 0)))) )
 >    (set-frame-position frame 0 0))

I have no idea what this small segment in nsterm.m

   if (ns_menu_bar_should_be_hidden ())
     return frameRect;

is meant to accomplish.  Try to comment it out and see what happens.  If
you see a difference, we'll have to look into it.

martin

[-- Attachment #2: Keith.diff --]
[-- Type: text/plain, Size: 2719 bytes --]

diff --git a/src/frame.c b/src/frame.c
index 6debcb8..f0c76ca 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -4582,20 +4582,40 @@ x_figure_window_size (struct frame *f, Lisp_Object parms, bool toolbar_p)
     {
       if (!EQ (width, Qunbound))
 	{
-	  CHECK_NUMBER (width);
-	  if (! (0 <= XINT (width) && XINT (width) <= INT_MAX))
-	    xsignal1 (Qargs_out_of_range, width);
+	  if (FLOATP (width))
+	    {
+	      if (XFLOAT_DATA (width) < 0 || (int) XFLOAT_DATA (width) > INT_MAX)
+		xsignal1 (Qargs_out_of_range, width);
+	      else
+		SET_FRAME_WIDTH (f, (int) XFLOAT_DATA (width));
+	    }
+	  else
+	    {
+	      CHECK_NUMBER (width);
+	      if (! (0 <= XINT (width) && XINT (width) <= INT_MAX))
+		xsignal1 (Qargs_out_of_range, width);

-	  SET_FRAME_WIDTH (f, XINT (width) * FRAME_COLUMN_WIDTH (f));
+	      SET_FRAME_WIDTH (f, XINT (width) * FRAME_COLUMN_WIDTH (f));
+	    }
 	}

       if (!EQ (height, Qunbound))
 	{
-	  CHECK_NUMBER (height);
-	  if (! (0 <= XINT (height) && XINT (height) <= INT_MAX))
-	    xsignal1 (Qargs_out_of_range, height);
+	  if (FLOATP (height))
+	    {
+	      if (XFLOAT_DATA (height) < 0 || (int) XFLOAT_DATA (height) > INT_MAX)
+		xsignal1 (Qargs_out_of_range, height);
+	      else
+		SET_FRAME_HEIGHT (f, (int) XFLOAT_DATA (height));
+	    }
+	  else
+	    {
+	      CHECK_NUMBER (height);
+	      if (! (0 <= XINT (height) && XINT (height) <= INT_MAX))
+		xsignal1 (Qargs_out_of_range, height);

-	  SET_FRAME_HEIGHT (f, XINT (height) * FRAME_LINE_HEIGHT (f));
+	      SET_FRAME_HEIGHT (f, XINT (height) * FRAME_LINE_HEIGHT (f));
+	    }
 	}

       user_size = x_get_arg (dpyinfo, parms, Quser_size, 0, 0, RES_TYPE_NUMBER);
diff --git a/src/nsfns.m b/src/nsfns.m
index 89b9f7c..4cb33be 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -679,7 +679,8 @@ x_set_tool_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
         }
     }

-  x_set_window_size (f, 0, f->text_cols, f->text_lines, 0);
+  frame_size_history_add (f, Qupdate_frame_tool_bar, 0, 0, Qnil);
+  adjust_frame_size (f, -1, -1, 2, 0, Qtool_bar_lines);
 }


diff --git a/src/nsterm.m b/src/nsterm.m
index 2806f31..360e831 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -7738,8 +7738,9 @@ x_new_font (struct frame *f, Lisp_Object font_object, int fontset)

   /* Now make the frame display the given font.  */
   if (FRAME_NS_WINDOW (f) != 0 && ! [view isFullscreen])
-    x_set_window_size (f, false, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
-                       FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), true);
+    adjust_frame_size (f, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
+		       FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), 3,
+		       false, Qfont);

   return font_object;
 }

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

We are in the home-stretch -- i.e., making significant progress!  :)

I applied the latest combined patch named `Keith.diff`.  I didn't see any side affects from the latest revision.

Commenting out the following small segment in `nsterm.m` fixes the problem with large frames being created partially above the top of the display -- i.e., it is no longer necessary to correct the bug by following a `make-frame` with `set-frame-position` (to move it squarely onto the screen) when `ns-auto-hide-menu-bar` is set to `t`.  As it stands now, the default position is `top 0` and `left 0` -- perfect!

   if (ns_menu_bar_should_be_hidden ())
     return frameRect;

I had previously thought that the above-mentioned problem (now fixed) was responsible for the frame increasing in size with the example labeled BROKEN.  I see now that the difference between the WORKING example and the BROKEN example is caused by the fact that `frame-after-make-frame` has already run in the WORKING example before `set-face-attribute` is called with the `font` parameter.  If we modify `x-create-frame-with-faces` by commenting out `(face-set-after-frame-default frame parameters)` and move that over to `make-frame` following `(frame-after-make-frame frame t)`, then both examples work as expected.

I understand that may not be the preferred solution, but at least we know for sure that calling `frame-after-make-frame` BEFORE `set-face-attribute` fixes the problem with the frame expanding even though `frame-inhibit-implied-resize` is set to `t`.


;; WORKS
(let* (
    (frame-inhibit-implied-resize t)
    (frame
      (make-frame '(
         (vertical-scroll-bars)
         (left-fringe . 8)
         (right-fringe . 8)
         (width . 1259.0)
         (height . 771.0)
         (tool-bar-lines . 0)))) )
  ;; (set-frame-position frame 0 0)
  (set-face-attribute 'default frame :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1"))

;; BROKEN -- unless `frame-after-make-frame` is called BEFORE `set-face-attribute`.
(let* (
    (frame-inhibit-implied-resize t)
    (frame
      (make-frame '(
        (font . "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
        (vertical-scroll-bars)
        (left-fringe . 8)
        (right-fringe . 8)
        (width . 1259.0)
        (height . 771.0)
        (tool-bar-lines . 0)))) )
  ;; (set-frame-position frame 0 0)
  )

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Commenting out the following small segment in `nsterm.m` fixes the
 > problem with large frames being created partially above the top of the
 > display -- i.e., it is no longer necessary to correct the bug by
 > following a `make-frame` with `set-frame-position` (to move it
 > squarely onto the screen) when `ns-auto-hide-menu-bar` is set to `t`.
 > As it stands now, the default position is `top 0` and `left 0` --
 > perfect!
 >
 >     if (ns_menu_bar_should_be_hidden ())
 >       return frameRect;

That check probably had a purpose.  Anders, what's your opinion on
removing it?

Thanks, martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 4070 bytes --]

Hi Martin and Keith!

Unfortunately, removing the suggested lines break another feature.

The system is designed so that it should be possible to programmatically
place the top of the frame above the top of the screen (when the menu bar
is hidden). This is useful to hide the window title so that the full height
of the screen can be utilised to edit text. When the suggested patch is
applied, this no longer is possible.

I would say that the problem is not related to this, but to `make-frame'
itself. When a weight higher than the default is specified, it should
adjust the window to start further down. As it is today, it always seem to
start mid screen.

Below is a small test file I have used to test the frame placement
features. If you come up with another solution, you can use it to check
that it doesn't break existing features. By the way, it's not intended to
be loaded, instead follow the comment and evaluate the expression one by
one and check that the result is as described in the file.

Sincerely,
    Anders Lindgren

;; ns-frame-test.el --- test for NextStep (Mac OS X) frame
positioning.;; Author: Anders Lindgren;; This file is *not* intended
to be loaded into Emacs. Instead, it;; contains individual expressions
that should be evaluated one by;; one, with accompanying manual test
steps.;; Future development:;;;; * Add more test cases, like
resolution change, frame stretching;;   multiple screens, and dragging
between different sized screens.;;;; * Automatic testing using a unit
test framework, for example ert.;;(error "You should not load this
file, read the file comments for details")
;; ----------------------------------------;; Basics;;;; Initially,
Emacs should be placed under the menu bar.;; After each test in this
section, it should be possible to drag the;; frame around, but it
should not be possible to drag it in under the;; menu bar.;; The
following should not place the window under the menu
bar.(set-frame-position (selected-frame) 0 -10)
;; The following will create a frame taller than screen. (90 is;;
suitable for a 1200 pixel display, you mileage may wary.);;;; The
frame should not be resized to fit the screen.(set-frame-size
(selected-frame) 80 90)
;; The following should move the frame down a bit. It should not be;;
resized to fit the screen.(set-frame-position (selected-frame) 0 50)

;; ----------------------------------------;; Auto hide menu;;;; In
this section, the auto-hide feature of the menu bar is;; tested. After
each step it should be possible do drag the window;; around. It should
not be possible to drag the window from within;; the screen to above
the screen. However, if it already is above the;; screen, it should be
possible to drag it around there.;; Start with a frame smaller than
the screen.(set-frame-size (selected-frame) 80 50)
;; After this, the menu bar should be hidden (unless the mouse
pointer;; is at the top of the screen).(setq ns-auto-hide-menu-bar t)
;; This will place the window title *above* the top of the screen
(as;; intended).(set-frame-position (selected-frame) 0 -10)
;; Frame will be higher than screen.(set-frame-size (selected-frame) 80 90)

;; ----------------------------------------;; Exit auto hide menu;;;;
Redisplay the menu bar. After this, the frame should be placed;;
*below* the menu bar.(setq ns-auto-hide-menu-bar nil)
;; ns-frame-test.el ends here.


On Sat, Sep 12, 2015 at 1:11 PM, martin rudalics <rudalics@gmx.at> wrote:

> > Commenting out the following small segment in `nsterm.m` fixes the
> > problem with large frames being created partially above the top of the
> > display -- i.e., it is no longer necessary to correct the bug by
> > following a `make-frame` with `set-frame-position` (to move it
> > squarely onto the screen) when `ns-auto-hide-menu-bar` is set to `t`.
> > As it stands now, the default position is `top 0` and `left 0` --
> > perfect!
> >
> >     if (ns_menu_bar_should_be_hidden ())
> >       return frameRect;
>
> That check probably had a purpose.  Anders, what's your opinion on
> removing it?
>
> Thanks, martin
>

[-- Attachment #2: Type: text/html, Size: 9682 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Unfortunately, removing the suggested lines break another feature.
 >
 > The system is designed so that it should be possible to programmatically
 > place the top of the frame above the top of the screen (when the menu bar
 > is hidden). This is useful to hide the window title so that the full height
 > of the screen can be utilised to edit text. When the suggested patch is
 > applied, this no longer is possible.

OK.  But this _is_ a different issue we could customize appropriately.
Auto hiding the menu bar should not unconditionally require to hide the
title bar as well.  So we could easily add an additional value to
‘ns-auto-hide-menu-bar’, say 'hide-menu-bar-only, where we only hide the
menu bar and still constrain the frame to the screen.  Both nil and t
would mean to leave the current behavior unchanged.  WDYT?

 > I would say that the problem is not related to this, but to `make-frame'
 > itself. When a weight higher than the default is specified,

What is a "weight higher than the default"?  I suppose you mean "height"
but I still don't understand.  What is the "default"?

 > it should
 > adjust the window to start further down.

Further "up" maybe?

 > As it is today, it always seem to
 > start mid screen.

IIUC Emacs does _not_ ask for a specific start position.  If it does we
could remove that.  Eventually it's always up to the WM to put the
window where it wants to.

 > Below is a small test file I have used to test the frame placement
 > features. If you come up with another solution, you can use it to check
 > that it doesn't break existing features. By the way, it's not intended to
 > be loaded, instead follow the comment and evaluate the expression one by
 > one and check that the result is as described in the file.

This one appears severely mangled by one of our MUAs.  But I have no OS
X here to check this anyway.  Maybe Keith can comment.

 > ;; ns-frame-test.el --- test for NextStep (Mac OS X) frame
 > positioning.;; Author: Anders Lindgren;; This file is *not* intended
...

Thanks for the quick response, martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]

 > I had previously thought that the above-mentioned problem (now fixed)
 > was responsible for the frame increasing in size with the example
 > labeled BROKEN.  I see now that the difference between the WORKING
 > example and the BROKEN example is caused by the fact that
 > `frame-after-make-frame` has already run in the WORKING example before
 > `set-face-attribute` is called with the `font` parameter.  If we
 > modify `x-create-frame-with-faces` by commenting out
 > `(face-set-after-frame-default frame parameters)` and move that over
 > to `make-frame` following `(frame-after-make-frame frame t)`, then
 > both examples work as expected.
 >
 > I understand that may not be the preferred solution, but at least we
 > know for sure that calling `frame-after-make-frame` BEFORE
 > `set-face-attribute` fixes the problem with the frame expanding even
 > though `frame-inhibit-implied-resize` is set to `t`.

Yes.  I forgot that we try to keep the number of lines and faces
constant when making the initial frame.  Try the attached patch.  It
should cover everything we have investigated so far.  Unfortunately, it
won't work with an internal tool bar like we have on Lucid, Motif, and
Windows.  There's something I haven't fathomed yet :-(

martin

[-- Attachment #2: Keith.diff --]
[-- Type: text/plain, Size: 6475 bytes --]

diff --git a/src/frame.c b/src/frame.c
index 6debcb8..01c7166 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -428,13 +428,15 @@ adjust_frame_size (struct frame *f, int new_width, int new_height, int inhibit,
        within the limits and either frame_inhibit_resize tells us to do
        so or INHIBIT equals 4.  */
     {
-      inhibit_horizontal = ((windows_width >= min_windows_width
-			     && (inhibit == 4
-				 || frame_inhibit_resize (f, true, parameter)))
+      inhibit_horizontal = ((f->inhibit_implied_resize
+			     || (windows_width >= min_windows_width
+				 && (inhibit == 4
+				     || frame_inhibit_resize (f, true, parameter))))
 			    ? true : false);
-      inhibit_vertical = ((windows_height >= min_windows_height
-			   && (inhibit == 4
-			       || frame_inhibit_resize (f, false, parameter)))
+      inhibit_vertical = ((f->inhibit_implied_resize
+			   || (windows_height >= min_windows_height
+			       && (inhibit == 4
+				   || frame_inhibit_resize (f, false, parameter))))
 			  ? true : false);
     }
   else
@@ -634,6 +636,7 @@ make_frame (bool mini_p)
   f->garbaged = true;
   f->can_x_set_window_size = false;
   f->after_make_frame = false;
+  f->inhibit_implied_resize = false;
   f->tool_bar_redisplayed_once = false;
   f->column_width = 1;  /* !FRAME_WINDOW_P value.  */
   f->line_height = 1;  /* !FRAME_WINDOW_P value.  */
@@ -2304,6 +2307,7 @@ otherwise used with utter care to avoid that running functions on
 {
   struct frame *f = decode_live_frame (frame);
   f->after_make_frame = !NILP (made);
+  f->inhibit_implied_resize = false;
   return made;
 }

@@ -3167,15 +3171,25 @@ x_set_frame_parameters (struct frame *f, Lisp_Object alist)
       prop = parms[i];
       val = values[i];

-      if (EQ (prop, Qwidth) && RANGED_INTEGERP (0, val, INT_MAX))
+      if (EQ (prop, Qwidth))
         {
 	  width_change = 1;
-          width = XFASTINT (val) * FRAME_COLUMN_WIDTH (f) ;
+	  if (RANGED_INTEGERP (0, val, INT_MAX))
+	    width = XFASTINT (val) * FRAME_COLUMN_WIDTH (f) ;
+	  else if (FLOATP (val)
+		   && XFLOAT_DATA (val) >= 0
+		   && (int) XFLOAT_DATA (val) <= INT_MAX)
+	    width = (int) XFLOAT_DATA (val);
         }
-      else if (EQ (prop, Qheight) && RANGED_INTEGERP (0, val, INT_MAX))
+      else if (EQ (prop, Qheight))
         {
 	  height_change = 1;
-          height = XFASTINT (val) * FRAME_LINE_HEIGHT (f);
+	  if (RANGED_INTEGERP (0, val, INT_MAX))
+	    height = XFASTINT (val) * FRAME_LINE_HEIGHT (f);
+	  else if (FLOATP (val)
+		   && XFLOAT_DATA (val) >= 0
+		   && (int) XFLOAT_DATA (val) <= INT_MAX)
+	    height = (int) XFLOAT_DATA (val);
         }
       else if (EQ (prop, Qtop))
 	top = val;
@@ -4582,20 +4596,50 @@ x_figure_window_size (struct frame *f, Lisp_Object parms, bool toolbar_p)
     {
       if (!EQ (width, Qunbound))
 	{
-	  CHECK_NUMBER (width);
-	  if (! (0 <= XINT (width) && XINT (width) <= INT_MAX))
-	    xsignal1 (Qargs_out_of_range, width);
+	  if (FLOATP (width))
+	    {
+	      if ((int) XFLOAT_DATA (width) < (FRAME_SCROLL_BAR_AREA_WIDTH (f)
+					       + FRAME_TOTAL_FRINGE_WIDTH (f)
+					       + 2 * FRAME_INTERNAL_BORDER_WIDTH (f))
+		  || (int) XFLOAT_DATA (width) > INT_MAX)
+		xsignal1 (Qargs_out_of_range, width);
+	      else
+		SET_FRAME_WIDTH (f, (int) XFLOAT_DATA (width));

-	  SET_FRAME_WIDTH (f, XINT (width) * FRAME_COLUMN_WIDTH (f));
+	      f->inhibit_implied_resize = true;
+	    }
+	  else
+	    {
+	      CHECK_NUMBER (width);
+	      if (! (0 <= XINT (width) && XINT (width) <= INT_MAX))
+		xsignal1 (Qargs_out_of_range, width);
+
+	      SET_FRAME_WIDTH (f, XINT (width) * FRAME_COLUMN_WIDTH (f));
+	    }
 	}

       if (!EQ (height, Qunbound))
 	{
-	  CHECK_NUMBER (height);
-	  if (! (0 <= XINT (height) && XINT (height) <= INT_MAX))
-	    xsignal1 (Qargs_out_of_range, height);
+	  if (FLOATP (height))
+	    {
+	      if ((int) XFLOAT_DATA (height) < (FRAME_TOP_MARGIN_HEIGHT (f)
+						+ FRAME_SCROLL_BAR_AREA_HEIGHT (f)
+						+ 2 * FRAME_INTERNAL_BORDER_WIDTH (f))
+		  || (int) XFLOAT_DATA (height) > INT_MAX)
+		xsignal1 (Qargs_out_of_range, height);
+	      else
+		SET_FRAME_HEIGHT (f, (int) XFLOAT_DATA (height));

-	  SET_FRAME_HEIGHT (f, XINT (height) * FRAME_LINE_HEIGHT (f));
+	      f->inhibit_implied_resize = true;
+	    }
+	  else
+	    {
+	      CHECK_NUMBER (height);
+	      if (! (0 <= XINT (height) && XINT (height) <= INT_MAX))
+		xsignal1 (Qargs_out_of_range, height);
+
+	      SET_FRAME_HEIGHT (f, XINT (height) * FRAME_LINE_HEIGHT (f));
+	    }
 	}

       user_size = x_get_arg (dpyinfo, parms, Quser_size, 0, 0, RES_TYPE_NUMBER);
diff --git a/src/frame.h b/src/frame.h
index 17e356d..21918ba 100644
--- a/src/frame.h
+++ b/src/frame.h
@@ -335,6 +335,9 @@ struct frame
   /* Set to true after this frame was made by `make-frame'.  */
   bool_bf after_make_frame : 1;

+  /* Inhibit implied resize before after_make_frame is set.  */
+  bool_bf inhibit_implied_resize : 1;
+
   /* True means tool bar has been redisplayed at least once in current
      session.  */
   bool_bf tool_bar_redisplayed_once : 1;
diff --git a/src/nsfns.m b/src/nsfns.m
index 9c805ac..e589929 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -679,7 +679,8 @@ x_set_tool_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
         }
     }

-  x_set_window_size (f, 0, f->text_cols, f->text_lines, 0);
+  frame_size_history_add (f, Qupdate_frame_tool_bar, 0, 0, Qnil);
+  adjust_frame_size (f, -1, -1, 2, 0, Qtool_bar_lines);
 }


diff --git a/src/nsterm.m b/src/nsterm.m
index 2806f31..48b88e1 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -7196,8 +7196,8 @@ if (cols > 0 && rows > 0)
   NSTRACE (constrainFrameRect);
   NSTRACE_RECT ("input", frameRect);

-  if (ns_menu_bar_should_be_hidden ())
-    return frameRect;
+///   if (ns_menu_bar_should_be_hidden ())
+///     return frameRect;

   if (nr_screens == 1)
     return [super constrainFrameRect:frameRect toScreen:screen];
@@ -7738,8 +7738,9 @@ x_new_font (struct frame *f, Lisp_Object font_object, int fontset)

   /* Now make the frame display the given font.  */
   if (FRAME_NS_WINDOW (f) != 0 && ! [view isFullscreen])
-    x_set_window_size (f, false, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
-                       FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), true);
+    adjust_frame_size (f, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
+		       FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), 3,
+		       false, Qfont);

   return font_object;
 }

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

I have applied the latest patch and just about everything is working as expected.  At some point prior to this latest patch, I lost the ability to expand a frame to fill the entire screen -- by a height of four (4) pixels on bottom.  This particular computer uses 1920 x 1080 -- the maximum outer dimension with the patches is 1920 x 1076.  This was not the case prior to working on bug 21415 -- i.e., prior to applying patches relating to bug 21415, I could expand (using set-frame-size) to the full size of 1920 x 1080.

I'll go back to the first patch we did and work forwards to see if I can be of any further assistance in tracking down why the frame stops 4 pixels shy of full screen at the bottom.

The other issues appear to have all been addressed in the latest patch.

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Anders:  Thank you for weighing in and vetoing the proposed revision -- your insight is greatly appreciated.

Martin:  In addition to the feature mentioned by Anders, it turned out that the proposed revision (that have since been vetoed for good reason) was responsible for my missing four (4) pixels at the bottom of the screen -- i.e., the best I could achieve with that vetoed revision was 1920 x 1076 on a 1920 x 1080 screen.  There were other problems I later discovered that were also linked to the proposed revision -- i.e., touching the mouse to the menubar to make it temporary visible, moved the frame downward; and, there was a side effect with the frame name whenever the frame was not squarely within the visible screen.

I removed all of the following lines from the most recent patch and built a new Emacs:

    @@ -7196,8 +7196,8 @@ if (cols > 0 && rows > 0)
       NSTRACE (constrainFrameRect);
       NSTRACE_RECT ("input", frameRect);
    
    -  if (ns_menu_bar_should_be_hidden ())
    -    return frameRect;
    +///   if (ns_menu_bar_should_be_hidden ())
    +///     return frameRect;
    
       if (nr_screens == 1)
         return [super constrainFrameRect:frameRect toScreen:screen];

I am now able to achieve a frame size of 1920 x 1080 on a screen that is 1920 x 1080; there is no longer any problem with the frame moving when touching the menubar; and the frame title is working as it should be.

So, the issue now remaining is how to let `make-frame` respect a frame parameter of `(top . 0)` upon frame creation when a user has `(setq ns-auto-hide-menu-bar t)`.  As it stands now, it is necessary to programmatically call `(set-frame-size FRAME 0 0)` subsequent to each frame being created, and am doing the same each time Emacs starts for the initial frame.

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I am now able to achieve a frame size of 1920 x 1080 on a screen that
 > is 1920 x 1080; there is no longer any problem with the frame moving
 > when touching the menubar; and the frame title is working as it should
 > be.

This, however, seems to hint at some unplesant locking of the auto hide
menu bar feature with the auto hide frame title feature.  Conceptually,
these should work independently from each other.

 > So, the issue now remaining is how to let `make-frame` respect a frame
 > parameter of `(top . 0)` upon frame creation when a user has `(setq
 > ns-auto-hide-menu-bar t)`.  As it stands now, it is necessary to
 > programmatically call `(set-frame-size FRAME 0 0)` subsequent to each
 > frame being created, and am doing the same each time Emacs starts for
 > the initial frame.

Maybe Anders has an idea why on OS X we apparently ignore the ‘top’ and
‘left’ parameters.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

I meant to say that I call `(set-frame-position FRAME 0 0)` to fix the inability to use `(top . 0)` as a frame parameter argument on frame creation when `ns-auto-hide-menu-bar` is set to `t`.

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1320 bytes --]

Hi,

I just checked this against Emacs 24.5. In that version, new frames always
start at 0 x 0, no matter how high they are. In addition, both versions
seem to react to the `top' property -- in Emacs 24 the window is placed
relative to the top (as expected). In Emacs 25 the start position when the
parameter is missing or is zero places the bottom of the frame in the
middle-ish of the screen, and a positive value for `top' places it further
down on the screen.

I would suggest that we try to find why Emacs 24 and 25 differs, so we can
revert back to the old behaviour.

A side topic: The documentation to `make-frame' seems a little bit vague.
It doesn't include `top' as an attribute, on the other hand doesn't say
that it accepts more properties than the ones listed. In addition, is the
limitation when it comes to `width' and `height' correct ("You cannot
specify either `width' or `height', you must specify neither or both.")? If
seems to work just fine when I supply only a `height' property.

Sincerely,
    Anders Lindgren

On Sun, Sep 13, 2015 at 1:13 AM, Keith David Bershatsky <esq@lawlist.com>
wrote:

> I meant to say that I call `(set-frame-position FRAME 0 0)` to fix the
> inability to use `(top . 0)` as a frame parameter argument on frame
> creation when `ns-auto-hide-menu-bar` is set to `t`.
>

[-- Attachment #2: Type: text/html, Size: 1769 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I just checked this against Emacs 24.5. In that version, new frames always
 > start at 0 x 0, no matter how high they are. In addition, both versions
 > seem to react to the `top' property -- in Emacs 24 the window is placed
 > relative to the top (as expected). In Emacs 25 the start position when the
 > parameter is missing or is zero places the bottom of the frame in the
 > middle-ish of the screen, and a positive value for `top' places it further
 > down on the screen.
 >
 > I would suggest that we try to find why Emacs 24 and 25 differs, so we can
 > revert back to the old behaviour.

Agreed.  Could you or Keith please do that?  No OS X around here.

 > A side topic: The documentation to `make-frame' seems a little bit vague.
 > It doesn't include `top' as an attribute, on the other hand doesn't say
 > that it accepts more properties than the ones listed.

We don't mention most of the parameters.  Funnily, ‘top’ is indirectly
referred to here:

      Note that on multi-monitor displays (*note Multiple Terminals::),
      the window manager might position the frame differently than
      specified by the positional parameters in ALIST (*note Position
      Parameters::).  For example, some window managers have a policy of
      displaying the frame on the monitor that contains the largest part
      of the window (a.k.a. the "dominating" monitor).

 > In addition, is the
 > limitation when it comes to `width' and `height' correct ("You cannot
 > specify either `width' or `height', you must specify neither or both.")? If
 > seems to work just fine when I supply only a `height' property.

I don't even understand where and how we were able to apply such a
restriction in the first place.  Anyway, we should rewrite both
doc-string and documentation.  As someone who always works with a single
main frame I have no practice with this function though.  So I'm
probably not the ideal choice for that task.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Martin:  I wanted to clarify the concept/feature referred to by Anders for hiding the window title bar on OSX.  OSX does not offer this feature.  What some users are doing is positioning the frame partially above the display so they cannot see the window frame title.  For example, instead of (0 0 1920 1080) it would be (0 -22 1920 1102).  The gain is about one extra line of text and less visual distraction.

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Martin: I wanted to clarify the concept/feature referred to by Anders
 > for hiding the window title bar on OSX.  OSX does not offer this
 > feature.  What some users are doing is positioning the frame partially
 > above the display so they cannot see the window frame title.  For
 > example, instead of (0 0 1920 1080) it would be (0 -22 1920 1102).
 > The gain is about one extra line of text and less visual distraction.

If ‘ns-auto-hide-menu-bar’ non-nil also moves the title bar off screen,
you can't position the frame at (0, 0).  Or am I missing something?

martin

bug#21415: Fwd: bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]

> If ‘ns-auto-hide-menu-bar’ non-nil also moves the title bar off screen,
> you can't position the frame at (0, 0).  Or am I missing something?

No, ns-auto-hide-menu-bar does not move the frame at all. The user is
allowed to place the frame above the top of the screen, but this does not
occur automatically. In other words, a frame can be placed at (0, 0).

To answer your earlier questions. You were speculating about adding another
variable for "the auto hide frame title feature". However, I don't think
this is a good idea since there is no such feature. Hiding the frame title
requires the user to explicitly move the frame (or use a package that does
this, like my "multicolumn" package).

    --Anders

Ps. Martin, sorry for the double post, but I realised that I had dropped
the other recipients, so I decided to resend it with a full "To:" list.

On Sun, Sep 13, 2015 at 8:01 PM, martin rudalics <rudalics@gmx.at> wrote:

> > Martin: I wanted to clarify the concept/feature referred to by Anders
> > for hiding the window title bar on OSX.  OSX does not offer this
> > feature.  What some users are doing is positioning the frame partially
> > above the display so they cannot see the window frame title.  For
> > example, instead of (0 0 1920 1080) it would be (0 -22 1920 1102).
> > The gain is about one extra line of text and less visual distraction.
>
> If ‘ns-auto-hide-menu-bar’ non-nil also moves the title bar off screen,
> you can't position the frame at (0, 0).  Or am I missing something?
>
> martin
>
>

[-- Attachment #2: Type: text/html, Size: 2722 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 3900 bytes --]

Hi,

>>> If ‘ns-auto-hide-menu-bar’ non-nil also moves the title bar off screen,
>>> you can't position the frame at (0, 0).  Or am I missing something?
>>
>> 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. When it is hidden, it's not possible to drag a window above the top of
the screen. 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.

By the way, when I use Win32, I also place the title bar above the top of
the screen, 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.


> I lost you.  I thought that ‘ns-auto-hide-menu-bar’ non-nil means to
> also automatically hide the title bar.  Am I wrong?

Yes, you are wrong!

Hiding the menu bar only hides the menu bar -- it does not move the frame
or hide the title bar.

However, when the menu bar is hidden the user can place the top of the
frame at a negative offset (i.e. above the top of the screes), but this
must be done explicitly. Most users won't use this feature, but it's
important to those that do.


> But how comes that for Keith the frame is apparently placed above the
> top of the screen although he didn't specify it?

Clearly, this is a bug -- the frame should not be placed above the top of
the screen in this case.

In Emacs 24, this didn't happen. Why this happens in Emacs 25, I don't
know, but clearly this is not the way we want the system to work.

The desired behavior is to place the top of the frame at the top of the
screen, or right below the menu bar (if it's present). If a `top' attribute
is present, the window should be placed accordingly. Also, a frame that is
too high for the screen should stretch down below the bottom of the screen,
like it did in Emacs 24.

I have tried to trace it through the various functions -- it seems that
Emacs tries to place the frame at the top of the screen (which is where we
want it) but at a later phase, the frame is somehow moved and/or constraint
to an incorrect location. This may take some time, however, given that I
have small children and a full time job, but I will try to find some time
for it during this or (more likely) next week.

/ Anders


On Mon, Sep 14, 2015 at 10:32 AM, martin rudalics <rudalics@gmx.at> wrote:

> >> If ‘ns-auto-hide-menu-bar’ non-nil also moves the title bar off screen,
> >> you can't position the frame at (0, 0).  Or am I missing something?
> >
> > 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)?
>
> > The user is
> > allowed to place the frame above the top of the screen, but this does not
> > occur automatically. In other words, a frame can be placed at (0, 0).
>
> But how comes that for Keith the frame is apparently placed above the
> top of the screen although he didn't specify it?
>
> > To answer your earlier questions. You were speculating about adding
> another
> > variable for "the auto hide frame title feature". However, I don't think
> > this is a good idea since there is no such feature. Hiding the frame
> title
> > requires the user to explicitly move the frame (or use a package that
> does
> > this, like my "multicolumn" package).
>
> I lost you.  I thought that ‘ns-auto-hide-menu-bar’ non-nil means to
> also automatically hide the title bar.  Am I wrong?
>
> martin
>
>

[-- Attachment #2: Type: text/html, Size: 6857 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 >>> 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"?

 > When it is hidden, it's not possible to drag a window above the top of
 > the screen.

I've never been able to "drag" a window above the top of the screen
because on all machines I know of the title bar is the handle for
dragging.

 > 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?

 > -- 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?

 > 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?

 > 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.

 > Hiding the menu bar only hides the menu bar -- it does not move the frame
 > or hide the title bar.

OK.

 > However, when the menu bar is hidden the user can place the top of the
 > frame at a negative offset (i.e. above the top of the screes), but this
 > must be done explicitly. Most users won't use this feature, but it's
 > important to those that do.

OK.  The "when" might be an answer to one of my questions above.

 >> But how comes that for Keith the frame is apparently placed above the
 >> top of the screen although he didn't specify it?
 >
 > Clearly, this is a bug -- the frame should not be placed above the top of
 > the screen in this case.
 >
 > In Emacs 24, this didn't happen. Why this happens in Emacs 25, I don't
 > know, but clearly this is not the way we want the system to work.
 >
 > The desired behavior is to place the top of the frame at the top of the
 > screen, or right below the menu bar (if it's present). If a `top' attribute
 > is present, the window should be placed accordingly. Also, a frame that is
 > too high for the screen should stretch down below the bottom of the screen,
 > like it did in Emacs 24.

Agreed.

 > I have tried to trace it through the various functions -- it seems that
 > Emacs tries to place the frame at the top of the screen (which is where we
 > want it) but at a later phase, the frame is somehow moved and/or constraint
 > to an incorrect location. This may take some time, however, given that I
 > have small children and a full time job, but I will try to find some time
 > for it during this or (more likely) next week.

Fine.

Thanks for your efforts, martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 2590 bytes --]

On Mon, 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.  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

[-- Attachment #2: Type: text/html, Size: 4330 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > 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.)

Then you should see the same problems as Keith with the frame not
covering the entire screen (or workarea).  I presume you can live with
that.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

>
> Then you should see the same problems as Keith with the frame not
> covering the entire screen (or workarea).  I presume you can live with
> that.


I have a font that is an even multiple of the screensize, so I don't have a
problem with that.

If I use another font then there will be a small gap at the bottom of the
screen. Setting `frame-resize-pixelwise' to t allows the frame to cover the
entire display, but the last line will be only partially visible.

/ Anders

[-- Attachment #2: Type: text/html, Size: 819 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I have a font that is an even multiple of the screensize, so I don't have a
 > problem with that.

You're lucky.  External borders, tool bar and menu bar often mess things
up.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1807 bytes --]

Hi,

Below is a patch that should correct the problem:

diff --git a/src/nsterm.m b/src/nsterm.m
index 2806f31..14f2beb 100644--- a/src/nsterm.m
+++ b/src/nsterm.m@@ -1333,6 +1333,7 @@ x_set_window_size (struct
frame *f,   int tb = FRAME_EXTERNAL_TOOL_BAR (f);
   int pixelwidth, pixelheight;
   int rows, cols;+  int orig_height = wr.size.height;
   NSTRACE (x_set_window_size);
 @@ -1386,7 +1387,7 @@ x_set_window_size (struct frame *f,  if
(f->output_data.ns->zooming)
    f->output_data.ns->zooming = 0;
  else-   wr.origin.y += FRAME_PIXEL_HEIGHT (f) - pixelheight;+
wr.origin.y += orig_height - wr.size.height;
   [view setRows: rows andColumns: cols];
   [window setFrame: wr display: YES];

Effectively, this will ensure that whenever the height of a frame is
changed, the origin (the distance from the lower left corner of the display
to the lower left hand corner of the frame) is updated accordingly.

Keith, please test this and see if it solves your problem with `make-frame'.

If it does then I suggest that we run it past whoever is in charge of the
OS X port. Apparently, it's not Jan Djärv anymore (in fact, I mailed him
asking him for help and he replied that he no longer was involved with
Emacs).

I don't have write access to the Emacs repository, so someone would have to
commit this for me, if it gets accepted.

By the way, do anyone know if there is a test case covering things like
this? If not, one should be implemented.

Sincerely,
    Anders




On Tue, Sep 15, 2015 at 10:29 AM, martin rudalics <rudalics@gmx.at> wrote:

> > I have a font that is an even multiple of the screensize, so I don't
> have a
> > problem with that.
>
> You're lucky.  External borders, tool bar and menu bar often mess things
> up.
>
> martin
>

[-- Attachment #2: Type: text/html, Size: 3514 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Below is a patch that should correct the problem:

Thanks.  But pretty please send it as an attachment.  Here it arrived
as:

 > diff --git a/src/nsterm.m b/src/nsterm.m
 > index 2806f31..14f2beb 100644--- a/src/nsterm.m
 > +++ b/src/nsterm.m@@ -1333,6 +1333,7 @@ x_set_window_size (struct
 > frame *f,   int tb = FRAME_EXTERNAL_TOOL_BAR (f);
 >     int pixelwidth, pixelheight;
 >     int rows, cols;+  int orig_height = wr.size.height;
 >     NSTRACE (x_set_window_size);
 >   @@ -1386,7 +1387,7 @@ x_set_window_size (struct frame *f,  if
 > (f->output_data.ns->zooming)
 >      f->output_data.ns->zooming = 0;
 >    else-   wr.origin.y += FRAME_PIXEL_HEIGHT (f) - pixelheight;+
 > wr.origin.y += orig_height - wr.size.height;
 >     [view setRows: rows andColumns: cols];
 >     [window setFrame: wr display: YES];

 > Effectively, this will ensure that whenever the height of a frame is
 > changed, the origin (the distance from the lower left corner of the display
 > to the lower left hand corner of the frame) is updated accordingly.

Can you please tell us why the "origin" on OS X is apparently the lower
left corner?  Where can I read about this?

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1.1: Type: text/plain, Size: 1535 bytes --]

Hi,

I've attached the patch, sorry for posting it in the mail.

You can read more about "screen coordinates" here:

https://developer.apple.com/library/ios/documentation/General/Conceptual/Devpedia-CocoaApp/CoordinateSystem.html

Sincerely,
    Anders

On Sun, Sep 20, 2015 at 12:17 AM, martin rudalics <rudalics@gmx.at> wrote:

> > Below is a patch that should correct the problem:
>
> Thanks.  But pretty please send it as an attachment.  Here it arrived
> as:
>
> > diff --git a/src/nsterm.m b/src/nsterm.m
> > index 2806f31..14f2beb 100644--- a/src/nsterm.m
> > +++ b/src/nsterm.m@@ -1333,6 +1333,7 @@ x_set_window_size (struct
> > frame *f,   int tb = FRAME_EXTERNAL_TOOL_BAR (f);
> >     int pixelwidth, pixelheight;
> >     int rows, cols;+  int orig_height = wr.size.height;
> >     NSTRACE (x_set_window_size);
> >   @@ -1386,7 +1387,7 @@ x_set_window_size (struct frame *f,  if
> > (f->output_data.ns->zooming)
> >      f->output_data.ns->zooming = 0;
> >    else-   wr.origin.y += FRAME_PIXEL_HEIGHT (f) - pixelheight;+
> > wr.origin.y += orig_height - wr.size.height;
> >     [view setRows: rows andColumns: cols];
> >     [window setFrame: wr display: YES];
>
> > Effectively, this will ensure that whenever the height of a frame is
> > changed, the origin (the distance from the lower left corner of the
> display
> > to the lower left hand corner of the frame) is updated accordingly.
>
> Can you please tell us why the "origin" on OS X is apparently the lower
> left corner?  Where can I read about this?
>
> martin
>

[-- Attachment #1.2: Type: text/html, Size: 2415 bytes --]

[-- Attachment #2: diff.txt --]
[-- Type: text/plain, Size: 656 bytes --]

diff --git a/src/nsterm.m b/src/nsterm.m
index 2806f31..14f2beb 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1333,6 +1333,7 @@ x_set_window_size (struct frame *f,
   int tb = FRAME_EXTERNAL_TOOL_BAR (f);
   int pixelwidth, pixelheight;
   int rows, cols;
+  int orig_height = wr.size.height;
 
   NSTRACE (x_set_window_size);
 
@@ -1386,7 +1387,7 @@ x_set_window_size (struct frame *f,
  if (f->output_data.ns->zooming)
    f->output_data.ns->zooming = 0;
  else
-   wr.origin.y += FRAME_PIXEL_HEIGHT (f) - pixelheight;
+   wr.origin.y += orig_height - wr.size.height;
 
   [view setRows: rows andColumns: cols];
   [window setFrame: wr display: YES];

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I've attached the patch, sorry for posting it in the mail.

Thank you.  Keith please try it.  If it fixes all remaining issues I'll
try to commit everything we have now next week.

 > You can read more about "screen coordinates" here:
 >
 > https://developer.apple.com/library/ios/documentation/General/Conceptual/Devpedia-CocoaApp/CoordinateSystem.html

Thanks.  I'm slightly confused, at least - I have no idea what flipping
means.  Can you have a short look at the section "Frame Geometry" in the
Elisp manual?  Maybe I should mention something about this issue there.

And do you have any idea why this apparently worked in Emacs 24.5 and
doesn't work with present master/trunk?

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]

Martin,

I just hope I didn't confuse you with the "screen coordinates" stuff. From
an Emacs users point of view (and from the point of view of elisp) the
UPPER LEFT corner is 0x0 -- as it is on every other system. The fact that
OS X see everything from the lower left corner is handled by internally by
"nsterm.m". Hence, there is no need to mention this in the manual.

"Flipping" mean that the coordinate system is mirrored, in some way. I
guess it could be used to set the upper left as the origin, but I'm not
that into OS X to tell you how that is done and what other consequences
that would have for the Emacs code base.

Unfortunately, I have no idea why it worked in 24.5 and why it didn't in
25. There has been a lot of changes along the way, so one would have to
inspect each one to see what changed, and why.

/ Anders

On Sun, Sep 20, 2015 at 10:44 AM, martin rudalics <rudalics@gmx.at> wrote:

> > I've attached the patch, sorry for posting it in the mail.
>
> Thank you.  Keith please try it.  If it fixes all remaining issues I'll
> try to commit everything we have now next week.
>
> > You can read more about "screen coordinates" here:
> >
> >
> https://developer.apple.com/library/ios/documentation/General/Conceptual/Devpedia-CocoaApp/CoordinateSystem.html
>
> Thanks.  I'm slightly confused, at least - I have no idea what flipping
> means.  Can you have a short look at the section "Frame Geometry" in the
> Elisp manual?  Maybe I should mention something about this issue there.
>
> And do you have any idea why this apparently worked in Emacs 24.5 and
> doesn't work with present master/trunk?
>
> martin
>

[-- Attachment #2: Type: text/html, Size: 2425 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I just hope I didn't confuse you with the "screen coordinates" stuff. From
 > an Emacs users point of view (and from the point of view of elisp) the
 > UPPER LEFT corner is 0x0 -- as it is on every other system. The fact that
 > OS X see everything from the lower left corner is handled by internally by
 > "nsterm.m".

I guessed so but wanted your confirmation.

 > Hence, there is no need to mention this in the manual.
 >
 > "Flipping" mean that the coordinate system is mirrored, in some way. I
 > guess it could be used to set the upper left as the origin, but I'm not
 > that into OS X to tell you how that is done and what other consequences
 > that would have for the Emacs code base.
 >
 > Unfortunately, I have no idea why it worked in 24.5 and why it didn't in
 > 25. There has been a lot of changes along the way, so one would have to
 > inspect each one to see what changed, and why.

No need to investigate if it works now.  Hopefully we can count on you
when we see similar problems.  After Jan's resignation we need all the
help we can get.

Many thanks, martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1066 bytes --]

On Sun, Sep 20, 2015 at 11:54 AM, martin rudalics <rudalics@gmx.at> wrote:

> Hopefully we can count on you when we see similar problems.  After Jan's

resignation we need all the help we can get.
>

If I can help, I will try to do so. I know the code base relatively well,
even though I've only authored a fraction of it.

Having said that, I just want you to know that I'm not that experienced
when it comes to OS X programming. Emacs is the only OS X application I've
ever worked on. Also, I am very time limited, given that I have a full time
job (I'm a compiler developer) and that I have small children (keeping me
very occupied).

When it comes to the code base, if I should work with it more, the first
thing I would do is to enhance the trace system (the NSTRACE_xxx macros).
The next would be to set up a regression test system, both generic and OS X
specific, so that it would be easy to detect when things like `make-frame'
changes behaviour, and so that the different UI:s don't diverge more than
they already have done.

Sincerely,
    Anders Lindgren

[-- Attachment #2: Type: text/html, Size: 1619 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I don't have write access to the Emacs repository, so someone would have to
 > commit this for me, if it gets accepted.

Committed to trunk/master.

Thanks again, martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

I have been able to reproduce the disregarding `top` frame parameter error with a much simpler example that does not involve `ns-auto-hide-menu-bar`.  I'm not sure why these simple tests are intermittently crashing the Emacs application with no user settings.

;; WORKING -- respects `top` parameter.
(make-frame '(
  (top . 50)
  (left . 50)
  ;; (height . 250.0)
  (width . 250.0)))

;; BROKEN -- disregards `top` parameter.
(make-frame '(
  (top . 50)
  (left . 50)
  (height . 250.0)
  (width . 250.0)))

And here is an unsophisticated hack:

(defadvice face-set-after-frame-default (before face-set-after-frame-default-before activate)
  (let* (
      (top (or (cdr (assq 'top parameters)) 0))
      (left (or (cdr (assq 'left parameters)) 0)) )
    (set-frame-position frame left top)))



At Sun, 13 Sep 2015 20:01:03 +0200,
martin rudalics wrote:
> 
> 
> If ‘ns-auto-hide-menu-bar' non-nil also moves the title bar off screen,
> you can't position the frame at (0, 0).  Or am I missing something?
> 
> martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I have been able to reproduce the disregarding `top` frame parameter
 > error with a much simpler example that does not involve
 > `ns-auto-hide-menu-bar`.  I'm not sure why these simple tests are
 > intermittently crashing the Emacs application with no user settings.

What does "crashing" mean in this context?

 > ;; WORKING -- respects `top` parameter.
 > (make-frame '(
 >    (top . 50)
 >    (left . 50)
 >    ;; (height . 250.0)
 >    (width . 250.0)))
 >
 > ;; BROKEN -- disregards `top` parameter.
 > (make-frame '(
 >    (top . 50)
 >    (left . 50)
 >    (height . 250.0)
 >    (width . 250.0)))

Anders said this worked in emacs 24.5 and doesn't work nowadays.  We'd
have to find the commit that broke that.  I can't.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I have been able to reproduce the disregarding `top` frame parameter
 > error with a much simpler example that does not involve
 > `ns-auto-hide-menu-bar`.  I'm not sure why these simple tests are
 > intermittently crashing the Emacs application with no user settings.
 >
 > ;; WORKING -- respects `top` parameter.
 > (make-frame '(
 >    (top . 50)
 >    (left . 50)
 >    ;; (height . 250.0)
 >    (width . 250.0)))
 >
 > ;; BROKEN -- disregards `top` parameter.
 > (make-frame '(
 >    (top . 50)
 >    (left . 50)
 >    (height . 250.0)
 >    (width . 250.0)))

Can you step through x_set_offset to find out which offsets we provide
and what we eventually pass on?

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

I closed out all the open Emacs instances and the crashing issue is gone, so that potential issue is moot.

To sum up the last email, essentially it appears that setting the `height` parameter causes `make-frame` to disregard a `top` parameter.

Thanks,

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

The `top` frame parameter is respected when setting the `height` frame parameter in the Emacs built on August 11, 2014, but is broken in the Emacs built on August 12, 2014.  I was not able to revert due to error messages about merging and so forth, but my best guess is that either of the following two commits are responsible:

commit bd4de70f13a92230da479e6fcd87d4355d626edf
Author: Martin Rudalics <rudalics@gmx.at>
Date:   Tue Aug 12 11:47:27 2014 +0200

    In set_menu_bar_lines call change_frame_size instead of set_menu_bar_lines_1.
    
    * frame.c (set_menu_bar_lines_1): Remove.
    (set_menu_bar_lines): Call change_frame_size instead of
    set_menu_bar_lines_1.

commit fe2f33e8da2e2c7950214eafdfd610f164025baf
Author: Jan Djärv <jan.h.d@swipnet.se>
Date:   Mon Aug 11 15:16:31 2014 +0200

    Fix default width not being 80, but 77.
    
    * nsfns.m (Fx_create_frame): Call adjust_frame_size,
    set f->official.

The crashing of Emacs yesterday (i.e., the application quitting without any error messages) was an anomaly, perhaps caused by running multiple instances and copying running Emacs programs to other directories.  I have not been able to repeat the crashing.  I have been reliably using Emacs built from the last commit on September 11, 2015 using the latest patch, with my own modification striking/removing the portion relating to "if (ns_menu_bar_should_be_hidden ()) return frameRect;" in nsterm.m.  That build seems to be working well for every situation except setting the `top` frame parameter when calling `make-frame, for which I have implemented the hack previously mentioned:

(defadvice face-set-after-frame-default (before face-set-after-frame-default-before activate)
  (let* (
      (top (or (cdr (assq 'top parameters)) 0))
      (left (or (cdr (assq 'left parameters)) 0)) )
    (set-frame-position frame left top)))

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > The `top` frame parameter is respected when setting the `height` frame
 > parameter in the Emacs built on August 11, 2014, but is broken in the
 > Emacs built on August 12, 2014.  I was not able to revert due to error
 > messages about merging and so forth, but my best guess is that either
 > of the following two commits are responsible:

 > commit bd4de70f13a92230da479e6fcd87d4355d626edf
 > Author: Martin Rudalics <rudalics@gmx.at>
 > Date:   Tue Aug 12 11:47:27 2014 +0200
 >
 >      In set_menu_bar_lines call change_frame_size instead of set_menu_bar_lines_1.
 >
 >      * frame.c (set_menu_bar_lines_1): Remove.
 >      (set_menu_bar_lines): Call change_frame_size instead of
 >      set_menu_bar_lines_1.

This one shouldn't affect OS X at all.

 > commit fe2f33e8da2e2c7950214eafdfd610f164025baf
 > Author: Jan Djärv <jan.h.d@swipnet.se>
 > Date:   Mon Aug 11 15:16:31 2014 +0200
 >
 >      Fix default width not being 80, but 77.
 >
 >      * nsfns.m (Fx_create_frame): Call adjust_frame_size,
 >      set f->official.

No idea about this either.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

The latest patch by Anders is working well with the following tests:

(make-frame '(
   (top . 50)
   (left . 50)
   ;; (height . 250.0)
   (width . 250.0)))

(make-frame '(
   (top . 50)
   (left . 50)
   (height . 250.0)
   (width . 250.0)))

(make-frame)

The `top` frame parameter is now respected.  When the `top` and `left` frame parameters are not included and `ns-auto-hide-menu-bar` is set to `t`, the default position is 0 0, even for large frames that are the size of the display -- very good!

The build recipe I used was the latest patch by Martin -- but WITHOUT modifying "if (ns_menu_bar_should_be_hidden ()) return frameRect;" -- followed by applying the patch from Anders.

Thanks,

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 346 bytes --]

>
> The `top` frame parameter is now respected.  When the `top` and `left`
> frame parameters are not included and `ns-auto-hide-menu-bar` is set to
> `t`, the default position is 0 0, even for large frames that are the size
> of the display -- very good!
>

Great news!

Are there any other open issues, or does this cover everything?

/ Anders

[-- Attachment #2: Type: text/html, Size: 625 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Are there any other open issues, or does this cover everything?

According to Keith one issue raised in this thread was that maximizing
the Emacs frame does not really maximize it on OS X.  In particular he
said that

   In my testing, `toggle-frame-maximized` was never as accurate as
   `set-frame-size` using the pixelwise argument.

Can you confirm that ‘toggle-frame-maximized’ doesn't really maximize
the frame?

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1101 bytes --]

>
> Can you confirm that ‘toggle-frame-maximized’ doesn't really maximize
> the frame?


 Yes, I can confirm this -- sort of.

In OS X Yosemite, the "maximize" button (the green round button on the top
left of the screen) starts fullscreen mode.

`toggle-frame-maximized', on the other hand, tries to resize the frame so
that it covers an entire monitor, but without entering full-screen mode
(which is the way it should work). Unfortunately, there is a bit of empty
space above and below the Emacs frame. It looks like this is due to the
fact that there isn't enough space to create another full line of text.
When setting `frame-resize-pixelwise' to t, unfortunately, it still doesn't
cover the entire display, and the behaviour is a bit more random, with the
frame repositioning itself slightly differently when
`toggle-frame-maximized' is called multiple times.

I didn't manage to make it fill both my monitors, only one. (How does the
command work on other systems?)

The documentation refers to an undefined
variable, x-frame-normalize-before-maximize.

/ Anders

[-- Attachment #2: Type: text/html, Size: 1531 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > In OS X Yosemite, the "maximize" button (the green round button on the top
 > left of the screen) starts fullscreen mode.

This is what ‘toggle-frame-fullscreen’ is supposed to do.

 > `toggle-frame-maximized', on the other hand, tries to resize the frame so
 > that it covers an entire monitor, but without entering full-screen mode
 > (which is the way it should work).

What if the next OS X generation changes policy again and asks for some
sort of "fullboth"?

 > Unfortunately, there is a bit of empty
 > space above and below the Emacs frame. It looks like this is due to the
 > fact that there isn't enough space to create another full line of text.
 > When setting `frame-resize-pixelwise' to t, unfortunately, it still doesn't
 > cover the entire display, and the behaviour is a bit more random, with the
 > frame repositioning itself slightly differently when
 > `toggle-frame-maximized' is called multiple times.

We'd have to fix this one way or the other.  Maybe by temporarily
collating "fullscreen" and "fullboth" for the NS builds.

The important thing is to synchronize the value of the ‘fullscreen’
frame parameter with the actual state of the frame as seen by both, the
window manager (or the OS) and the user.  The state of the frame
includes its size, its decorations and the state of the "maximize"
button.  In my experience, having ‘toggle-frame-maximized’ follow
‘toggle-frame-fullscreen’ can be very tricky in this regard.

 > I didn't manage to make it fill both my monitors, only one. (How does the
 > command work on other systems?)

I can't tell because I use only one monitor.

 > The documentation refers to an undefined
 > variable, x-frame-normalize-before-maximize.

This variable is for X only.  I'll fix that in the documentation.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 3015 bytes --]

Hi!

I can take a look at it. However, the experience I had with the previous
bug was that it's immensely hard to follow what happens when it comes to
frame resizing and placement. So what I will do is to first reimplement the
NSTRACE package and then start looking for the problem. By the way, is
there some kind of deadline coming up?

Also, things are starting to get so complicated so that we would need to
state what each concept mean so that they can be implemented the same way
on all systems. (When I wrote my "multicolumn" package I found tons and
tons of things that differed between systems, I just want to make sure we
don't introduce more such things.) In addition, we really must write test
cases automatically walking through all transitions, ensuring that nothing
breaks in the future, but also as this is a good way to describe the
intended behavior.

I don't know what you mean by "fullboth", so I can't comment on what would
happen when you collate "fullscreen" and "fullboth".

/ Anders


On Tue, Sep 22, 2015 at 8:38 AM, martin rudalics <rudalics@gmx.at> wrote:

> > In OS X Yosemite, the "maximize" button (the green round button on the
> top
> > left of the screen) starts fullscreen mode.
>
> This is what ‘toggle-frame-fullscreen’ is supposed to do.
>
> > `toggle-frame-maximized', on the other hand, tries to resize the frame so
> > that it covers an entire monitor, but without entering full-screen mode
> > (which is the way it should work).
>
> What if the next OS X generation changes policy again and asks for some
> sort of "fullboth"?
>
> > Unfortunately, there is a bit of empty
> > space above and below the Emacs frame. It looks like this is due to the
> > fact that there isn't enough space to create another full line of text.
> > When setting `frame-resize-pixelwise' to t, unfortunately, it still
> doesn't
> > cover the entire display, and the behaviour is a bit more random, with
> the
> > frame repositioning itself slightly differently when
> > `toggle-frame-maximized' is called multiple times.
>
> We'd have to fix this one way or the other.  Maybe by temporarily
> collating "fullscreen" and "fullboth" for the NS builds.
>
> The important thing is to synchronize the value of the ‘fullscreen’
> frame parameter with the actual state of the frame as seen by both, the
> window manager (or the OS) and the user.  The state of the frame
> includes its size, its decorations and the state of the "maximize"
> button.  In my experience, having ‘toggle-frame-maximized’ follow
> ‘toggle-frame-fullscreen’ can be very tricky in this regard.
>
> > I didn't manage to make it fill both my monitors, only one. (How does the
> > command work on other systems?)
>
> I can't tell because I use only one monitor.
>
> > The documentation refers to an undefined
> > variable, x-frame-normalize-before-maximize.
>
> This variable is for X only.  I'll fix that in the documentation.
>
> martin
>
>

[-- Attachment #2: Type: text/html, Size: 3839 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I can take a look at it. However, the experience I had with the previous
 > bug was that it's immensely hard to follow what happens when it comes to
 > frame resizing and placement. So what I will do is to first reimplement the
 > NSTRACE package and then start looking for the problem.

OK.  As far as frame resizing is concerned I wrote some rudimentary
Elisp support.  Set the variable ‘frame-size-history’ to a value like
'(100) and you will get a (partly cryptic) list of requests to resize a
frame and whether and how the request got honored.

 > By the way, is
 > there some kind of deadline coming up?

Not for bugs like this.  It's only short before a release that we only
fix regressions introduced since the last release.

 > Also, things are starting to get so complicated so that we would need to
 > state what each concept mean so that they can be implemented the same way
 > on all systems. (When I wrote my "multicolumn" package I found tons and
 > tons of things that differed between systems, I just want to make sure we
 > don't introduce more such things.)

One thing that should work uniformly accross platforms is the
‘frame-geometry’ function as well as the recently introduced
‘frame-edges’.  Since I was never able to verify these for OS X it would
be a good start to make sure they deliver correct results there first.
Done that, we should have a common platform to discuss the remaining
issues.

 > In addition, we really must write test
 > cases automatically walking through all transitions, ensuring that nothing
 > breaks in the future,

One problem with automatic test cases is that numbers may lie about the
effect you see on screen.  For example, Emacs can resize your scroll bar
width with completely correct metrics but since Gtk+ usually refuses to
change scroll bar widths, the visual appearance is devastating.  But
obviously, automatic test cases would be very useful.

 > but also as this is a good way to describe the
 > intended behavior.

Such description should be found in the frame geometry section of the
Elisp manual.

 > I don't know what you mean by "fullboth", so I can't comment on what would
 > happen when you collate "fullscreen" and "fullboth".

"fullboth" is our misnomer for "maximized", that is, the frame should
occupy the full work area of the display and its "maximize" button
should indicate that the frame can be restored to its normal size (the
latter implies that a maximized frame usually keeps its title bar).

A "fullscreen" frame, OTOH, occupies the entire display area (including
a task bar) and has no title bar.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1.1: Type: text/plain, Size: 4927 bytes --]

Hi,

I found one problem related to `toggle-to-maximized'. If this happened
right after `frame-resize-pixelwise' was set to a non-nil value, the
NSWindow parameter `resizeIncrement' must be updated. If this does not
occur, the frame size is rounded down to only accommodate full characters.
The extra space was distributed evenly above and below the frame. The
attached patch fixes this issue.

To see the difference, run Emacs -Q and evaluate the following. After the
patch is applied, the frame is no longer moves down.

    (progn
      (setq frame-resize-pixelwise t)
      (toggle-frame-maximized))

Unfortunately, the frame still doesn't cover the entire screen. The
documentation to `windowWillUseStandardFrame' says:

    "The size of the current screen, which is the screen containing the
largest part of the window's current frame, possibly reduced on the top,
bottom, left, or right, depending on the current interface style."

Effectively, this mean that the frame is reduced one pixel on the top (if
the menu bar is visible) and four pixels at the bottom. This corresponds to
how other applications, like Chrome, works.

I think it would be relatively easy to override this (well, at least the
four pixels at the bottom), but I'm not sure if we should and, if so, under
which conditions. (I can image that some users would like Emacs to fill the
entire screen whereas others might prefer the standard four pixels to be
unused at the bottom.)

In the Info documentation to the `fullscreen' frame parameter, there are
two values missing: `nil' and `fullscreen'. The former indicates that the
frame is in non-maximized state and the latter seems to behave like
`fullboth'. Interestingly, the function `toggle-frame-fullscreen' seems to
use this undocumented parameter value. (In addition, there are some control
characters showing on the first line.)

On a side note, the NSTRACE rewrite is coming along nicely (it really
helped in tracking down this problem) but it's not yet ready for release.

Sincerely,
    Anders Lindgren

On Tue, Sep 22, 2015 at 11:36 AM, martin rudalics <rudalics@gmx.at> wrote:

> > I can take a look at it. However, the experience I had with the previous
> > bug was that it's immensely hard to follow what happens when it comes to
> > frame resizing and placement. So what I will do is to first reimplement
> the
> > NSTRACE package and then start looking for the problem.
>
> OK.  As far as frame resizing is concerned I wrote some rudimentary
> Elisp support.  Set the variable ‘frame-size-history’ to a value like
> '(100) and you will get a (partly cryptic) list of requests to resize a
> frame and whether and how the request got honored.
>
> > By the way, is
> > there some kind of deadline coming up?
>
> Not for bugs like this.  It's only short before a release that we only
> fix regressions introduced since the last release.
>
> > Also, things are starting to get so complicated so that we would need to
> > state what each concept mean so that they can be implemented the same way
> > on all systems. (When I wrote my "multicolumn" package I found tons and
> > tons of things that differed between systems, I just want to make sure we
> > don't introduce more such things.)
>
> One thing that should work uniformly accross platforms is the
> ‘frame-geometry’ function as well as the recently introduced
> ‘frame-edges’.  Since I was never able to verify these for OS X it would
> be a good start to make sure they deliver correct results there first.
> Done that, we should have a common platform to discuss the remaining
> issues.
>
> > In addition, we really must write test
> > cases automatically walking through all transitions, ensuring that
> nothing
> > breaks in the future,
>
> One problem with automatic test cases is that numbers may lie about the
> effect you see on screen.  For example, Emacs can resize your scroll bar
> width with completely correct metrics but since Gtk+ usually refuses to
> change scroll bar widths, the visual appearance is devastating.  But
> obviously, automatic test cases would be very useful.
>
> > but also as this is a good way to describe the
> > intended behavior.
>
> Such description should be found in the frame geometry section of the
> Elisp manual.
>
> > I don't know what you mean by "fullboth", so I can't comment on what
> would
> > happen when you collate "fullscreen" and "fullboth".
>
> "fullboth" is our misnomer for "maximized", that is, the frame should
> occupy the full work area of the display and its "maximize" button
> should indicate that the frame can be restored to its normal size (the
> latter implies that a maximized frame usually keeps its title bar).
>
> A "fullscreen" frame, OTOH, occupies the entire display area (including
> a task bar) and has no title bar.
>
> martin
>
>

[-- Attachment #1.2: Type: text/html, Size: 5999 bytes --]

[-- Attachment #2: maximize.diff --]
[-- Type: text/plain, Size: 535 bytes --]

diff --git a/src/nsterm.m b/src/nsterm.m
index a5bf06a..65d07b2 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -6724,6 +6724,11 @@ if (cols > 0 && rows > 0)
 {
   if (fs_state != emacsframe->want_fullscreen)
     {
+      NSSize sz;
+      sz.width = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (emacsframe);
+      sz.height = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (emacsframe);
+      [[self window] setResizeIncrements:sz];
+
       if (fs_state == FULLSCREEN_BOTH)
         {
           [self toggleFullScreen:self];

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I found one problem related to `toggle-to-maximized'. If this happened
 > right after `frame-resize-pixelwise' was set to a non-nil value, the
 > NSWindow parameter `resizeIncrement' must be updated. If this does not
 > occur, the frame size is rounded down to only accommodate full characters.
 > The extra space was distributed evenly above and below the frame. The
 > attached patch fixes this issue.

Makes sense.  Pushed as 73b0901..e55460e to master.

 > To see the difference, run Emacs -Q and evaluate the following. After the
 > patch is applied, the frame is no longer moves down.
 >
 >      (progn
 >        (setq frame-resize-pixelwise t)
 >        (toggle-frame-maximized))
 >
 > Unfortunately, the frame still doesn't cover the entire screen.

Usually it shouldn't, for maximizing.  The problem as far as I
understand is that NS doesn't have the concept of a "maximized" frame.

 > The
 > documentation to `windowWillUseStandardFrame' says:
 >
 >      "The size of the current screen, which is the screen containing the
 > largest part of the window's current frame, possibly reduced on the top,
 > bottom, left, or right, depending on the current interface style."
 >
 > Effectively, this mean that the frame is reduced one pixel on the top (if
 > the menu bar is visible) and four pixels at the bottom. This corresponds to
 > how other applications, like Chrome, works.

When you do what, in Chrome?  Try maximizing the Chrome window?  How do
you do that?

 > I think it would be relatively easy to override this (well, at least the
 > four pixels at the bottom), but I'm not sure if we should and, if so, under
 > which conditions. (I can image that some users would like Emacs to fill the
 > entire screen whereas others might prefer the standard four pixels to be
 > unused at the bottom.)

We have the concept of a "workarea" as it's returned by
‘display-monitor-attributes-list’.  On all systems I know of, a
"maximized" frame occupies the full workarea, a "fullwidth" frame the
full width of the workarea and a "fullheight" frame the full height of
the workarea. (I have no idea how these concepts expand to multiple
monitors though.)  How do the four unused pixels relate to your
workarea?

 > In the Info documentation to the `fullscreen' frame parameter, there are
 > two values missing: `nil' and `fullscreen'. The former indicates that the
 > frame is in non-maximized state

nil means "neither of ‘maximized’, ‘fullwidth’, ‘fullheight’ or
‘fullboth’".

 > and the latter seems to behave like
 > `fullboth'.

‘fullscreen’ should not be used.  I kept it in because I had the faint
feeling that at some time it was used isntead of ‘fullboth’.

 > Interestingly, the function `toggle-frame-fullscreen' seems to
 > use this undocumented parameter value.

It accepts it IIUC but it does not store it.  Or what do you mean?

Note that the documentations is still not very clear on the entire
subject, mostly so because I don't know how other systems handle it.
For example, xfce which I use on Debian seems to correctly cooperate
with Emacs via the extended window manager hints with one exception: The
state of the "resize" button in the title bar is the same for
‘fullheight’ and ‘maximized’.  Consequently, using that button doesn't
quite DTRT for a full height frame.

On Windows, Emacs controls ‘fullheight’ and ‘fullwidth’ and I see no
such problem.  But you will nowhere find a description of the semantics
of ‘toggle-frame-maximized’ when the frame is in the ‘fullboth’ state
and was ‘maximized’ before.

Note also in this context that Stefan's bug #10670 "`fullscreen' frame
parameter ill-named" is yet unresolved:

   The frame parameter `fullscreen' is ill-named: I think that it should be
   renamed to `maximized' with accepted values nil, `vertical',
   `horizontal', `both', or `fullscreen'.

I agree with his diagnosis but I disagree with the cure.  And for
compatibility reasons we would have to accept the old values anyway.

 > (In addition, there are some control
 > characters showing on the first line.)

Please elaborate.

 > On a side note, the NSTRACE rewrite is coming along nicely (it really
 > helped in tracking down this problem) but it's not yet ready for release.

Fine.  Can you please get yourself write access to the git repository so
you can install it when it's ready?  I feel some unease installing
larger changes on systems where I cannot check the consequences myself
immediately.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 4224 bytes --]

Hi!


> Makes sense.  Pushed as 73b0901..e55460e to master.


Thanks!


> To see the difference, run Emacs -Q and evaluate the following. After the
> > patch is applied, the frame is no longer moves down.
> >
> >      (progn
> >        (setq frame-resize-pixelwise t)
> >        (toggle-frame-maximized))
> >
> > Unfortunately, the frame still doesn't cover the entire screen.
>
> Usually it shouldn't, for maximizing.  The problem as far as I
> understand is that NS doesn't have the concept of a "maximized" frame.
>

In earlier OS X versions, the green button was designed to make the window
large enough to accommodate the current document. In many applications,
this meant that the window grew to it's maximum hight, minus those missing
four pixels.

In newer versions, the green button makes the application enter fullscreen
mode.

Internally, however, internally, it's still possible to issue either
"toggleFullScreen" or "performZoom".


When you do what, in Chrome?  Try maximizing the Chrome window?  How do

> you do that?


If I manually drag the Chrome window to its largest size, I can make it
stretch the entire width, but there will be four pixels missing at the
bottom. Also, if I hit the green button in older OS X versions, the same
four pixels are missing from the bottom.


> We have the concept of a "workarea" as it's returned by
> ‘display-monitor-attributes-list’.  On all systems I know of, a
> "maximized" frame occupies the full workarea, a "fullwidth" frame the
> full width of the workarea and a "fullheight" frame the full height of
> the workarea. (I have no idea how these concepts expand to multiple
> monitors though.)  How do the four unused pixels relate to your
> workarea?


The function returns the following:

(((name . "SyncMaster")
  (geometry 0 0 1600 1200)
  (workarea 0 23 1600 1173)
  (mm-size 432 324)
  (frames #<frame *scratch* 0x101099630>)
  (source . "NS"))
 ((name . "SyncMaster")
  (geometry 1600 0 1600 1200)
  (workarea 1600 0 1600 1200)
  (mm-size 432 324)
  (frames)
  (source . "NS")))

Interestingly, the workarea of the primary screen is missing four pixels
(1200 - 1173 - 34) = 4.

However, the workarea of the secondary monitor does not. When executing
`toggle-frame-maximized' on the secondary frame (with
`frame-resize-pixelwise' set to t), the frame is placed at the bottom left
corner (which is good), but there are four pixles missing at the TOP of the
screen. (I haven't investigated why, though.)


> In the Info documentation to the `fullscreen' frame parameter, there are
> > two values missing: `nil' and `fullscreen'. The former indicates that the
> > frame is in non-maximized state
>
> nil means "neither of ‘maximized’, ‘fullwidth’, ‘fullheight’ or
> ‘fullboth’".


Yes, I guessed so -- but it needs to be documented, right?


> Interestingly, the function `toggle-frame-fullscreen' seems to
> > use this undocumented parameter value.
>
> It accepts it IIUC but it does not store it.  Or what do you mean?
>

My mistake -- I was looking at the 24.5 source. There, the `fullscreen'
property was set to `fullscreen'. It has been fixed in the Emacs 25 source.


> (In addition, there are some control
> > characters showing on the first line.)
>
> Please elaborate.


In the "info" documentation, the first line looks like the following, where
the backslash-numbers represent a single character. I guess this is some
kind of encoding issue...

     This parameter specifies whether to maximize the frame\342\200\231s
width,


> On a side note, the NSTRACE rewrite is coming along nicely (it really
> > helped in tracking down this problem) but it's not yet ready for release.
>
> Fine.  Can you please get yourself write access to the git repository so
> you can install it when it's ready?  I feel some unease installing
> larger changes on systems where I cannot check the consequences myself
> immediately.


I fully understand. Who should I talk to to get write access? (The last
time I was doing any serious work on Emacs, Jan Djärv did the checkins, but
that was before he resigned.)

/ Anders

[-- Attachment #2: Type: text/html, Size: 6811 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Internally, however, internally, it's still possible to issue either
 > "toggleFullScreen" or "performZoom".

What does "internally" mean here?

 > If I manually drag the Chrome window to its largest size, I can make it
 > stretch the entire width, but there will be four pixels missing at the
 > bottom. Also, if I hit the green button in older OS X versions, the same
 > four pixels are missing from the bottom.

 > (((name . "SyncMaster")
 >    (geometry 0 0 1600 1200)
 >    (workarea 0 23 1600 1173)
 >    (mm-size 432 324)
 >    (frames #<frame *scratch* 0x101099630>)
 >    (source . "NS"))
 >   ((name . "SyncMaster")
 >    (geometry 1600 0 1600 1200)
 >    (workarea 1600 0 1600 1200)
 >    (mm-size 432 324)
 >    (frames)
 >    (source . "NS")))
 >
 > Interestingly, the workarea of the primary screen is missing four pixels
 > (1200 - 1173 - 34) = 4.

What was the 34 about?  I probably forgot.

 > However, the workarea of the secondary monitor does not. When executing
 > `toggle-frame-maximized' on the secondary frame (with
 > `frame-resize-pixelwise' set to t), the frame is placed at the bottom left
 > corner (which is good), but there are four pixles missing at the TOP of the
 > screen. (I haven't investigated why, though.)

Does ‘toggle-frame-maximized’ pass on 1173 or 1176 or 1200 as height?

 >> nil means "neither of ‘maximized’, ‘fullwidth’, ‘fullheight’ or
 >> ‘fullboth’".
 >
 >
 > Yes, I guessed so -- but it needs to be documented, right?

I'll do that.

 > In the "info" documentation, the first line looks like the following, where
 > the backslash-numbers represent a single character. I guess this is some
 > kind of encoding issue...
 >
 >       This parameter specifies whether to maximize the frame\342\200\231s
 > width,

Funny.  Here this line reads as

This parameter specifies whether to maximize the frame's width, height

Probably this got screwed up during the "'" conversion process.

 > I fully understand. Who should I talk to to get write access? (The last
 > time I was doing any serious work on Emacs, Jan Djärv did the checkins, but
 > that was before he resigned.)

You have to apply for membership at Savannah:

https://savannah.gnu.org/git/?group=emacs

Then Eli (I believe) has to confirm that you are given write access and
finally you have to establish a key pair.  Eli will correct me possibly.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Eli Zaretskii]

> Date: Tue, 29 Sep 2015 09:23:51 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Keith David Bershatsky <esq@lawlist.com>, 21415@debbugs.gnu.org
> 
>  > I fully understand. Who should I talk to to get write access? (The last
>  > time I was doing any serious work on Emacs, Jan Djärv did the checkins, but
>  > that was before he resigned.)
> 
> You have to apply for membership at Savannah:
> 
> https://savannah.gnu.org/git/?group=emacs
> 
> Then Eli (I believe) has to confirm that you are given write access and
> finally you have to establish a key pair.  Eli will correct me possibly.

Eli is only one of a few individuals who can do that; there are
others.  They all will receive your request for membership.

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]

Hi!

> Internally, however, internally, it's still possible to issue either
> > "toggleFullScreen" or "performZoom".
>
> What does "internally" mean here?


It means that an application can call those function to perform the
actions, even though there are no user interface buttons the user can click
on.

In the Emacs case, setting the `fullscreen' property to the possible legal
values invokes one of the system functions `toggleFullScreen' or
`performZoom'.


> (((name . "SyncMaster")
> >    (geometry 0 0 1600 1200)
> >    (workarea 0 23 1600 1173)
> >    (mm-size 432 324)
> >    (frames #<frame *scratch* 0x101099630>)
> >    (source . "NS"))
> >   ((name . "SyncMaster")
> >    (geometry 1600 0 1600 1200)
> >    (workarea 1600 0 1600 1200)
> >    (mm-size 432 324)
> >    (frames)
> >    (source . "NS")))
> >
> > Interestingly, the workarea of the primary screen is missing four pixels
> > (1200 - 1173 - 34) = 4.
>
> What was the 34 about?  I probably forgot.


"34" should be "23", which is the height of the menu bar.

In other words, the effective work area seems to be lacking four pixels at
the bottom.

I agree with you that I prefer a maximized frame to cover the entire
screen. I will try to do some experiments to see if it's possible, and if
so, we can discuss if we should modify Emacs to behave this way.



> > However, the workarea of the secondary monitor does not. When executing
> > `toggle-frame-maximized' on the secondary frame (with
> > `frame-resize-pixelwise' set to t), the frame is placed at the bottom
> left
> > corner (which is good), but there are four pixles missing at the TOP of
> the
> > screen. (I haven't investigated why, though.)
>
> Does ‘toggle-frame-maximized’ pass on 1173 or 1176 or 1200 as height?


Emacs calls the NextStep function `performZoom' without specifying a
height. The system, in turn, calls `windowWillUseStandardFrame:' with a
suggested frame with the height 1173 (when frame-resize-pixelwise is
non-nil).

My guess is that we can override this, but I haven't verified this.


> I fully understand. Who should I talk to to get write access? (The last
> > time I was doing any serious work on Emacs, Jan Djärv did the checkins,
> but
> > that was before he resigned.)
>
> You have to apply for membership at Savannah:
>
> https://savannah.gnu.org/git/?group=emacs
>
> Then Eli (I believe) has to confirm that you are given write access and
> finally you have to establish a key pair.  Eli will correct me possibly.


I got my write access rights today! Thanks for suggesting this.

/ Anders

[-- Attachment #2: Type: text/html, Size: 4178 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 >> (((name . "SyncMaster")
 >>>     (geometry 0 0 1600 1200)
 >>>     (workarea 0 23 1600 1173)
 >>>     (mm-size 432 324)
 >>>     (frames #<frame *scratch* 0x101099630>)
 >>>     (source . "NS"))
 >>>    ((name . "SyncMaster")
 >>>     (geometry 1600 0 1600 1200)
 >>>     (workarea 1600 0 1600 1200)
 >>>     (mm-size 432 324)
 >>>     (frames)
 >>>     (source . "NS")))
 >>>
 >>> Interestingly, the workarea of the primary screen is missing four pixels
 >>> (1200 - 1173 - 34) = 4.
 >>
 >> What was the 34 about?  I probably forgot.
 >
 >
 > "34" should be "23", which is the height of the menu bar.
 >
 > In other words, the effective work area seems to be lacking four pixels at
 > the bottom.
 >
 > I agree with you that I prefer a maximized frame to cover the entire
 > screen. I will try to do some experiments to see if it's possible, and if
 > so, we can discuss if we should modify Emacs to behave this way.

IIUC the Mac menu bar is what other systems call a task bar.  In that
case, a maximized frame should cover everything but the menu bar and a
fullboth frame should cover the entire screen.  Now if I understand you
correctly, Mac doesn't distinguish the various "zoomed" states - a
fullheight frame is just as "zoomed" as a fullscreen or maximized one.

 > Emacs calls the NextStep function `performZoom' without specifying a
 > height. The system, in turn, calls `windowWillUseStandardFrame:' with a
 > suggested frame with the height 1173 (when frame-resize-pixelwise is
 > non-nil).
 >
 > My guess is that we can override this, but I haven't verified this.

How does one specify a size with performZoom?  And does one performZoom
(to get a fullheight frame, say) followed by another one (to get a
fullboth frame, say) followed by toggling the button produce the initial
normal frame?

 > I got my write access rights today! Thanks for suggesting this.

Great!

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 2181 bytes --]

>
> IIUC the Mac menu bar is what other systems call a task bar.  In that
> case, a maximized frame should cover everything but the menu bar and a
> fullboth frame should cover the entire screen.  Now if I understand you
> correctly, Mac doesn't distinguish the various "zoomed" states - a
> fullheight frame is just as "zoomed" as a fullscreen or maximized one.


Zooming and fullscreen are two different concepts. Zooming is a generic
system, and it's up to the application to decide what to do. When
initialized using the user interface, Emacs steps through full-height,
maximized, and original size. When the frame `fullscreen' property is
updated, the correct state is set immediately. OS X is simply informed of
the end size and placement and resized the frame using a resizing animation.

FullScreen is a totally different animal with a special sideways animation,
gives the application exclusive use of the screen, and blanks out other
monitors.

Today, I did try a little experiment by
modifying `windowWillUseStandardFrame:' to return the full screen size.
Unfortunately, using this method it doesn't seem possible to make the frame
use the entire screen -- it appears as though the system restrict the
requested frame size to what it considers the visible area.

The four pixels, by the way, is related to the position of the "Dock" -- if
it is placed on the side of the screen, OS X won't use the four leftmost
pixels. Also, if the Dock is not in auto-hide mode, OS X will restrict zoom
so that the dock isn't covered at all (i.e. some 20 or 30 pixels).

It would be relatively easy to modify the code so that setting a frame
parameter would set the frame size without using the zoom system. However,
it would make maximizing the frame using the user interface different from
`toggle-frame-maximized', which might be undesirable. On the other hand, I
compared with another application (LightRoom). When it is maximized using
the user interface, it's frame doesn't cover the entire screen (the same
four pixels as in Emacs). To cover the entire screen, another command must
be issued which cycles through maximized, maximized with hidden menu bar,
and normal.

/ Anders

[-- Attachment #2: Type: text/html, Size: 2680 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Zooming and fullscreen are two different concepts. Zooming is a generic
 > system, and it's up to the application to decide what to do. When
 > initialized using the user interface, Emacs steps through full-height,
 > maximized, and original size. When the frame `fullscreen' property is
 > updated, the correct state is set immediately. OS X is simply informed of
 > the end size and placement and resized the frame using a resizing animation.

But is the fact that OS X has responded to our zooming request reflected
in that "button" and if so in which way?

 > FullScreen is a totally different animal with a special sideways animation,
 > gives the application exclusive use of the screen, and blanks out other
 > monitors.

What is the size of such a "FullScreen" screen in relation to the size
of your screen?

 > Today, I did try a little experiment by
 > modifying `windowWillUseStandardFrame:' to return the full screen size.
 > Unfortunately, using this method it doesn't seem possible to make the frame
 > use the entire screen -- it appears as though the system restrict the
 > requested frame size to what it considers the visible area.
 >
 > The four pixels, by the way, is related to the position of the "Dock" -- if
 > it is placed on the side of the screen, OS X won't use the four leftmost
 > pixels. Also, if the Dock is not in auto-hide mode, OS X will restrict zoom
 > so that the dock isn't covered at all (i.e. some 20 or 30 pixels).

This makes sense, more or less.

 > It would be relatively easy to modify the code so that setting a frame
 > parameter would set the frame size without using the zoom system. However,
 > it would make maximizing the frame using the user interface different from
 > `toggle-frame-maximized', which might be undesirable.

Agreed.

 > On the other hand, I
 > compared with another application (LightRoom). When it is maximized using
 > the user interface, it's frame doesn't cover the entire screen (the same
 > four pixels as in Emacs). To cover the entire screen, another command must
 > be issued which cycles through maximized, maximized with hidden menu bar,
 > and normal.

I'm afraid that I don't yet understand that "cycling".  Do you mean that
pushing that button (which I presume is the "user interface") repeatedly
cycles through these three states?  In that case there's still the
question whether ‘toggle-frame-maximized’ should hide the menu bar.

BTW, you above say "full-height" and "maximized" and here you talk about
"maximized" and "maximized with hidden menu bar".  Which of these
correlate?

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 3137 bytes --]

Hi!

But is the fact that OS X has responded to our zooming request reflected
> in that "button" and if so in which way?


No, the button does not change in any way when zooming.

The button is typically always plain green. When hovering above it, it
displays the fullscreen version of it (two arrows pointing either inwards
or outwards, depending on the fullscreen state). When pressing ALT, the
button change to contain a "+" sign, indicating that the operation will be
a "zoom". The application will display the "+" sign regardless of whether
it's maximized or not.

In earlier versions of OS X, there was no fullscreen mode. In those
versions, the green button always contained a "+" when hovering above it.


> FullScreen is a totally different animal with a special sideways
> animation,
> > gives the application exclusive use of the screen, and blanks out other
> > monitors.
>
> What is the size of such a "FullScreen" screen in relation to the size
> of your screen?


It's always use the full screen, as far as I can tell.

In fact, when in fullscreen mode, the menu bar, tool bar, and title bar are
hidden. When the mouse touch the upper part of the screen, they slide in.

As far as I can tell, fullscreen mode work very well.


> On the other hand, I
> > compared with another application (LightRoom). When it is maximized using
> > the user interface, it's frame doesn't cover the entire screen (the same
> > four pixels as in Emacs). To cover the entire screen, another command
> must
> > be issued which cycles through maximized, maximized with hidden menu bar,
> > and normal.
>
> I'm afraid that I don't yet understand that "cycling".  Do you mean that
> pushing that button (which I presume is the "user interface") repeatedly
> cycles through these three states?


Yes, it does.

I think this behaviour is fine.



>  In that case there's still the
> question whether ‘toggle-frame-maximized’ should hide the menu bar.
>

I would say no.

Currently, the user can hide the menu bar by setting
`ns-auto-hide-menu-bar' to t. If this is set, `toggle-frame-maximized' (and
zooming using the user interface) use the entire screen.

I see no reason to change this.


BTW, you above say "full-height" and "maximized" and here you talk about
> "maximized" and "maximized with hidden menu bar".  Which of these
> correlate?


Different applications use different states, it was only an example of how
another application handle similar situation. I don't think this cycle is
the way to go for us.


All in all, the Emacs system works well. The only problem is that a
maximized window doesn't cover the entire screen. I have been thinking
about two alternatives:

* Replace the zoom code with a custom one that simply sets the correct
size. (Hopefully, it's possible to get this to work with the zoom button as
well.)
* Call the standard zoom function to get the zoom animation, then do an
extra resize after it's done.

Also, one could imagine a new variable `ns-use-native-zoom' if the user
would like the normal zoom.

/ Anders

[-- Attachment #2: Type: text/html, Size: 4830 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > As far as I can tell, fullscreen mode work very well.

Fine.

 >>   In that case there's still the
 >> question whether ‘toggle-frame-maximized’ should hide the menu bar.
 >>
 >
 > I would say no.
 >
 > Currently, the user can hide the menu bar by setting
 > `ns-auto-hide-menu-bar' to t. If this is set, `toggle-frame-maximized' (and
 > zooming using the user interface) use the entire screen.

Ah... Then everything looks alright in this regard.

 > All in all, the Emacs system works well. The only problem is that a
 > maximized window doesn't cover the entire screen. I have been thinking
 > about two alternatives:
 >
 > * Replace the zoom code with a custom one that simply sets the correct
 > size. (Hopefully, it's possible to get this to work with the zoom button as
 > well.)
 > * Call the standard zoom function to get the zoom animation, then do an
 > extra resize after it's done.

This last one sounds a bit clumsy.

 > Also, one could imagine a new variable `ns-use-native-zoom' if the user
 > would like the normal zoom.

We could try that.  After all it looks like a complement to
‘ns-auto-hide-menu-bar’.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

> Are there any other open issues, or does this cover everything?
> 
> / Anders

All issues regarding functionality as to bug 21415 are handled as far as I can tell.  Attached is the combined patch that I used today to perform my testing.

Martin implemented a new feature for pixel width/height specifications with a floating number, so it would probably be a good idea to mention something about that feature somewhere in the doc-string for `make-frame'.

And, as Anders previously noted, on OSX it is possible to set the width or the height or both -- so the following statement may need to be modified to something such as:  "On some operating systems, . . .[y]ou cannot specify either ‘width’ or ‘height’, you must specify neither or both."

Thank you both for all your hard work -- today is the first time since I started using Emacs that I have been able to set the `default-frame-alist` in my `.emacs` file and have it work well for the initial frame and all subsequently created frames.  :)

Keith


[-- Attachment #2: 21415_g.diff --]
[-- Type: application/diff, Size: 6786 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Would it be possible to broaden the scope of issue number 21415 to include Emacs for Microsoft Windows such that the following will also work using a floating point:

    (make-frame '(
      (height . 25.0)
      (width . 50.0)))

Because I do not yet have the knowledge to build Emacs for Microsoft Windows, I have been using the Emacs Trunk built by Dani Moncayo.  The updates are every few weeks.

https://sourceforge.net/projects/emacs-bin/?source=updater

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Would it be possible to broaden the scope of issue number 21415 to
 > include Emacs for Microsoft Windows such that the following will also
 > work using a floating point:
 >
 >      (make-frame '(
 >        (height . 25.0)
 >        (width . 50.0)))
 >

A 25 x 50 pixels window might look a bit small but 500.0 x 250.0 work
here.  With X things get more complicated but they should work there
too.  The major problem is and will remain NS: If with emacs -Q, you
evaluate

(progn
   (setq frame-resize-pixelwise t)
   (setq frame-inhibit-implied-resize t)
   (make-frame '((width . 1200.0) (height . 600.0)
		(font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1"))))

what does

(cons (frame-text-width) (frame-text-height))

return?

 > Because I do not yet have the knowledge to build Emacs for Microsoft
 > Windows,

You should acquire that knowledge.  If there are any problems, Eli will
help (I won't because I'm misconfiguring).  The more people build on
Windows, the sooner we will be able to catch errors there.  As things
stand, too many people wait for the next release of ...

 > I have been using the Emacs Trunk built by Dani Moncayo.  The updates are every few weeks.
 >
 > https://sourceforge.net/projects/emacs-bin/?source=updater

... and if Dani picked up a bad moment, we might get floods of errors
for something that was broken (and maybe even fixed) some time ago.

And I forgot to mention one aspect: You might then even be the first to
regularly build Emacs on both Windows and NS.  While this probably won't
give you any bonus points in this community, it still might be
interesting to get first hand experience with comparing the behavior of
Emacs on the two major proprietary systems.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

The pre-built Windows version from September 23, 2015 doesn't yet have the magical patch to support a pixelwise floating point.  I've taken the first steps toward learning how to build Emacs on Windows, but have encountered some initial stumbling blocks with a never ending loop after the initial checking is performed during the make process.  I will work on it a little each day until I figure it out . . . .

Debugger entered--Lisp error: (wrong-type-argument integerp 1200.0)
  x-create-frame(((visibility) (width . 1200.0) (height . 600.0)))
  x-create-frame-with-faces(((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1")))
  #[257 "\300\x01!\207" [x-create-frame-with-faces] 3 "\n\n(fn PARAMS)"](((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1")))
  apply(#[257 "\300\x01!\207" [x-create-frame-with-faces] 3 "\n\n(fn PARAMS)"] ((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1")))
  frame-creation-function(((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1")))
  make-frame(((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1")))
  (progn (setq frame-resize-pixelwise t) (setq frame-inhibit-implied-resize t) (make-frame (quote ((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1")))))
  eval((progn (setq frame-resize-pixelwise t) (setq frame-inhibit-implied-resize t) (make-frame (quote ((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1"))))) nil)
  elisp--eval-last-sexp(nil)
  eval-last-sexp(nil)
  funcall-interactively(eval-last-sexp nil)
  call-interactively(eval-last-sexp nil nil)
  command-execute(eval-last-sexp)

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > The pre-built Windows version from September 23, 2015 doesn't yet have
 > the magical patch to support a pixelwise floating point.  I've taken
 > the first steps toward learning how to build Emacs on Windows, but
 > have encountered some initial stumbling blocks with a never ending
 > loop after the initial checking is performed during the make process.
 > I will work on it a little each day until I figure it out . . . .
 >
 > Debugger entered--Lisp error: (wrong-type-argument integerp 1200.0)
 >    x-create-frame(((visibility) (width . 1200.0) (height . 600.0)))

Obviously.  This works only with the patch I sent you.  But I asked you
to do on NS:

If with emacs -Q, you evaluate

(progn
   (setq frame-resize-pixelwise t)
   (setq frame-inhibit-implied-resize t)
   (make-frame '((width . 1200.0) (height . 600.0)
		(font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1"))))

what does

(cons (frame-text-width) (frame-text-height))

return?

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Ah . . . okay . . . on NS with emacs -Q, I get:

(1185 . 600)

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Mon, 28 Sep 2015 20:00:36 +0200,
martin rudalics wrote:
> 
> * * *
> . . . I asked you to do on NS:
> 
> If with emacs -Q, you evaluate
> 
> (progn
>    (setq frame-resize-pixelwise t)
>    (setq frame-inhibit-implied-resize t)
>    (make-frame '((width . 1200.0) (height . 600.0)
>   (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1"))))
> 
> what does
> 
> (cons (frame-text-width) (frame-text-height))
> 
> return?
> 
> martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Ah . . . okay . . . on NS with emacs -Q, I get:
 >
 > (1185 . 600)

Not all too bad given that we want (1200 . 600).  I'm really surprised
that the height seems OK.  What does evaluating the following three
forms in the new frame return?

(frame-parameter nil 'scroll-bar-width)
(frame-parameter nil 'left-fringe)
(frame-parameter nil 'right-fringe)

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

I get 15, 8, 8:

(frame-parameter nil 'scroll-bar-width):  15

(frame-parameter nil 'left-fringe):  8

(frame-parameter nil 'right-fringe):  8

With emacs -Q, after evaluating:

(progn
   (setq frame-resize-pixelwise t)
   (setq frame-inhibit-implied-resize t)
   (make-frame '((width . 1200.0) (height . 600.0)
  (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1"))))

At Tue, 29 Sep 2015 09:22:37 +0200, martin rudalics wrote:
> 
>  > Ah . . . okay . . . on NS with emacs -Q, I get:
>  >
>  > (1185 . 600)
> 
> Not all too bad given that we want (1200 . 600).  I'm really surprised
> that the height seems OK.  What does evaluating the following three
> forms in the new frame return?
> 
> (frame-parameter nil 'scroll-bar-width)
> (frame-parameter nil 'left-fringe)
> (frame-parameter nil 'right-fringe)
> 
> martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I get 15, 8, 8:
 >
 > (frame-parameter nil 'scroll-bar-width):  15

So it's obviously the scroll bar width.  I will look into this.

 > (frame-parameter nil 'left-fringe):  8
 >
 > (frame-parameter nil 'right-fringe):  8
 >
 > With emacs -Q, after evaluating:
 >
 > (progn
 >     (setq frame-resize-pixelwise t)
 >     (setq frame-inhibit-implied-resize t)
 >     (make-frame '((width . 1200.0) (height . 600.0)
 >    (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1"))))
 >
 > At Tue, 29 Sep 2015 09:22:37 +0200, martin rudalics wrote:
 >>
 >>   > Ah . . . okay . . . on NS with emacs -Q, I get:
 >>   >
 >>   > (1185 . 600)

Thanks, martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

I had an opportunity this evening to test out the earlier patch by Martin in this thread for the floating point frame-creation on Emacs built for MS-Windows (XP--SP3) and it is working well.  I've set up the `default-frame-alist' with floating points for height and width, and the initial frame and all new frames perfectly reflect the parameters tested -- what a pleasure -- :)

I wasn't sure if anything had changed in the past couple of weeks, so I did a hard reset back to the last commit on September 11, 2015 and then applied the patch to do my testing.

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

 > I wasn't sure if anything had changed in the past couple of weeks, so
 > I did a hard reset back to the last commit on September 11, 2015 and
 > then applied the patch to do my testing.

Find attached the most recent version of the patch.  Fixes are mainly
for Lucid/Motif but something might change for other platforms as well.

martin

[-- Attachment #2: frame-sizes-float.diff --]
[-- Type: text/plain, Size: 47703 bytes --]

--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -461,7 +461,7 @@ there (in decreasing order of priority)."
 		    (cons (1- (car frame-size-history))
 			  (cons
 			   (list frame-initial-frame
-				 "frame-notice-user-settings"
+				 "FRAME-NOTICE-USER"
 				 nil newparms)
 			   (cdr frame-size-history)))))

@@ -702,7 +702,7 @@ the new frame according to its own rules."
     (when (numberp (car frame-size-history))
       (setq frame-size-history
 	    (cons (1- (car frame-size-history))
-		  (cons (list frame "make-frame")
+		  (cons (list frame "MAKE-FRAME")
 			(cdr frame-size-history)))))

     ;; We can run `window-configuration-change-hook' for this frame now.
@@ -1382,6 +1382,27 @@ and width values are in pixels.
        (cons 'internal-border-width
 	     (frame-parameter frame 'internal-border-width)))))))

+(defun frame--size-history (&optional frame)
+  "Print history of resize operations for FRAME.
+Print prettified version of `frame-size-history' into a buffer
+called *frame-size-history*.  Optional argument FRAME denotes the
+frame whose history will be printed.  FRAME defaults to the
+selected frame."
+  (let ((history (reverse frame-size-history))
+	entry)
+    (setq frame (window-normalize-frame frame))
+    (with-current-buffer (get-buffer-create "*frame-size-history*")
+      (erase-buffer)
+      (insert (format "Frame size history of %s\n" frame))
+      (while (listp (setq entry (pop history)))
+	(when (eq (car entry) frame)
+          (pop entry)
+          (insert (format "%s" (pop entry)))
+          (move-to-column 24 t)
+          (while entry
+            (insert (format " %s" (pop entry))))
+          (insert "\n"))))))
+
 (declare-function x-frame-edges "xfns.c" (&optional frame type))
 (declare-function w32-frame-edges "w32fns.c" (&optional frame type))
 (declare-function ns-frame-edges "nsfns.m" (&optional frame type))
diff --git a/src/frame.c b/src/frame.c
index f1a78fb..c2ddb30 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -184,16 +184,17 @@ frame_inhibit_resize (struct frame *f, bool horizontal, Lisp_Object parameter)
 {
   Lisp_Object fullscreen = get_frame_param (f, Qfullscreen);
   bool inhibit
-    = ((f->after_make_frame
-	&& (EQ (frame_inhibit_implied_resize, Qt)
-	    || (CONSP (frame_inhibit_implied_resize)
-		&& !NILP (Fmemq (parameter, frame_inhibit_implied_resize)))))
-       || (horizontal
-	   && !EQ (fullscreen, Qnil) && !EQ (fullscreen, Qfullheight))
-       || (!horizontal
-	   && !EQ (fullscreen, Qnil) && !EQ (fullscreen, Qfullwidth))
-       || FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f));
-
+    = (f->after_make_frame
+       ? (EQ (frame_inhibit_implied_resize, Qt)
+	  || (CONSP (frame_inhibit_implied_resize)
+	      && !NILP (Fmemq (parameter, frame_inhibit_implied_resize)))
+	  || (horizontal
+	      && !EQ (fullscreen, Qnil) && !EQ (fullscreen, Qfullheight))
+	  || (!horizontal
+	      && !EQ (fullscreen, Qnil) && !EQ (fullscreen, Qfullwidth))
+	  || FRAME_TERMCAP_P (f) || FRAME_MSDOS_P (f))
+       : ((horizontal && f->inhibit_horizontal_resize)
+	  || (!horizontal && f->inhibit_vertical_resize)));
   if (inhibit && !FRAME_TERMCAP_P (f) && !FRAME_MSDOS_P (f))
     frame_size_history_add
       (f, Qframe_inhibit_resize, 0, 0,
@@ -425,17 +426,15 @@ adjust_frame_size (struct frame *f, int new_width, int new_height, int inhibit,

   if (inhibit >= 2 && inhibit <= 4)
     /* When INHIBIT is in [2..4] inhibit if the "old" window sizes stay
-       within the limits and either frame_inhibit_resize tells us to do
-       so or INHIBIT equals 4.  */
+       within the limits and either resizing is inhibited or INHIBIT
+       equals 4.  */
     {
-      inhibit_horizontal = ((windows_width >= min_windows_width
-			     && (inhibit == 4
-				 || frame_inhibit_resize (f, true, parameter)))
-			    ? true : false);
-      inhibit_vertical = ((windows_height >= min_windows_height
-			   && (inhibit == 4
-			       || frame_inhibit_resize (f, false, parameter)))
-			  ? true : false);
+      inhibit_horizontal = (windows_width >= min_windows_width
+                            && (inhibit == 4
+                                || frame_inhibit_resize (f, true, parameter)));
+      inhibit_vertical = (windows_height >= min_windows_height
+                          && (inhibit == 4
+                              || frame_inhibit_resize (f, false, parameter)));
     }
   else
     /* Otherwise inhibit if INHIBIT equals 5.  */
@@ -634,6 +633,10 @@ make_frame (bool mini_p)
   f->garbaged = true;
   f->can_x_set_window_size = false;
   f->after_make_frame = false;
+  f->inhibit_horizontal_resize = false;
+  f->inhibit_vertical_resize = false;
+  f->tool_bar_redisplayed = false;
+  f->tool_bar_resized = false;
   f->column_width = 1;  /* !FRAME_WINDOW_P value.  */
   f->line_height = 1;  /* !FRAME_WINDOW_P value.  */
 #ifdef HAVE_WINDOW_SYSTEM
@@ -2303,6 +2306,8 @@ otherwise used with utter care to avoid that running functions on
 {
   struct frame *f = decode_live_frame (frame);
   f->after_make_frame = !NILP (made);
+  f->inhibit_horizontal_resize = false;
+  f->inhibit_vertical_resize = false;
   return made;
 }

@@ -3166,15 +3171,25 @@ x_set_frame_parameters (struct frame *f, Lisp_Object alist)
       prop = parms[i];
       val = values[i];

-      if (EQ (prop, Qwidth) && RANGED_INTEGERP (0, val, INT_MAX))
+      if (EQ (prop, Qwidth))
         {
 	  width_change = 1;
-          width = XFASTINT (val) * FRAME_COLUMN_WIDTH (f) ;
+	  if (RANGED_INTEGERP (0, val, INT_MAX))
+	    width = XFASTINT (val) * FRAME_COLUMN_WIDTH (f) ;
+	  else if (FLOATP (val)
+		   && XFLOAT_DATA (val) >= 0
+		   && (int) XFLOAT_DATA (val) <= INT_MAX)
+	    width = (int) XFLOAT_DATA (val);
         }
-      else if (EQ (prop, Qheight) && RANGED_INTEGERP (0, val, INT_MAX))
+      else if (EQ (prop, Qheight))
         {
 	  height_change = 1;
-          height = XFASTINT (val) * FRAME_LINE_HEIGHT (f);
+	  if (RANGED_INTEGERP (0, val, INT_MAX))
+	    height = XFASTINT (val) * FRAME_LINE_HEIGHT (f);
+	  else if (FLOATP (val)
+		   && XFLOAT_DATA (val) >= 0
+		   && (int) XFLOAT_DATA (val) <= INT_MAX)
+	    height = (int) XFLOAT_DATA (val);
         }
       else if (EQ (prop, Qtop))
 	top = val;
@@ -3262,28 +3277,15 @@ x_set_frame_parameters (struct frame *f, Lisp_Object alist)
     XSETFRAME (frame, f);

     if ((width_change && width != FRAME_TEXT_WIDTH (f))
-	|| (height_change && height != FRAME_TEXT_HEIGHT (f))
-	|| (f->can_x_set_window_size && (f->new_height || f->new_width)))
-      {
-	/* If necessary provide default values for HEIGHT and WIDTH.  Do
-	   that here since otherwise a size change implied by an
-	   intermittent font change may get lost as in Bug#17142.  */
-	if (!width_change)
-	  width = ((f->can_x_set_window_size && f->new_width)
-		   ? (f->new_pixelwise
-		      ? f->new_width
-		      : (f->new_width * FRAME_COLUMN_WIDTH (f)))
-		   : FRAME_TEXT_WIDTH (f));
-
-	if (!height_change)
-	  height = ((f->can_x_set_window_size && f->new_height)
-		    ? (f->new_pixelwise
-		       ? f->new_height
-		       : (f->new_height * FRAME_LINE_HEIGHT (f)))
-		    : FRAME_TEXT_HEIGHT (f));
-
-	Fset_frame_size (frame, make_number (width), make_number (height), Qt);
-      }
+	|| (height_change && height != FRAME_TEXT_HEIGHT (f)))
+      /* We could consider checking f->after_make_frame here, but I
+	 don't have the faintest idea why the following is needed at
+	 all.  With the old setting it can get a Heisenbug when
+	 EmacsFrameResize intermittently provokes a delayed
+	 change_frame_size in the middle of adjust_frame_size.  */
+      /** 	|| (f->can_x_set_window_size && (f->new_height || f->new_width))) **/
+      adjust_frame_size (f, width_change ? width : -1,
+			 height_change ? height : -1, 1, 0, Qx_set_frame_parameters);

     if ((!NILP (left) || !NILP (top))
 	&& ! (left_no_change && top_no_change)
@@ -4552,7 +4554,7 @@ On Nextstep, this just calls `ns-parse-geometry'.  */)
 #define DEFAULT_COLS 80

 long
-x_figure_window_size (struct frame *f, Lisp_Object parms, bool toolbar_p)
+x_figure_window_size (struct frame *f, Lisp_Object parms, bool toolbar_p, int *x_width, int *x_height)
 {
   Lisp_Object height, width, user_size, top, left, user_position;
   long window_prompting = 0;
@@ -4571,44 +4573,11 @@ x_figure_window_size (struct frame *f, Lisp_Object parms, bool toolbar_p)
   f->top_pos = 0;
   f->left_pos = 0;

-  /* Ensure that earlier new_width and new_height settings won't
-     override what we specify below.  */
-  f->new_width = f->new_height = 0;
-
-  height = x_get_arg (dpyinfo, parms, Qheight, 0, 0, RES_TYPE_NUMBER);
-  width = x_get_arg (dpyinfo, parms, Qwidth, 0, 0, RES_TYPE_NUMBER);
-  if (!EQ (width, Qunbound) || !EQ (height, Qunbound))
-    {
-      if (!EQ (width, Qunbound))
-	{
-	  CHECK_NUMBER (width);
-	  if (! (0 <= XINT (width) && XINT (width) <= INT_MAX))
-	    xsignal1 (Qargs_out_of_range, width);
-
-	  SET_FRAME_WIDTH (f, XINT (width) * FRAME_COLUMN_WIDTH (f));
-	}
-
-      if (!EQ (height, Qunbound))
-	{
-	  CHECK_NUMBER (height);
-	  if (! (0 <= XINT (height) && XINT (height) <= INT_MAX))
-	    xsignal1 (Qargs_out_of_range, height);
-
-	  SET_FRAME_HEIGHT (f, XINT (height) * FRAME_LINE_HEIGHT (f));
-	}
-
-      user_size = x_get_arg (dpyinfo, parms, Quser_size, 0, 0, RES_TYPE_NUMBER);
-      if (!NILP (user_size) && !EQ (user_size, Qunbound))
-	window_prompting |= USSize;
-      else
-	window_prompting |= PSize;
-    }
-
-  /* Add a tool bar height to the initial frame height so that the user
-     gets a text display area of the size he specified with -g or via
-     .Xdefaults.  Later changes of the tool bar height don't change the
-     frame size.  This is done so that users can create tall Emacs
-     frames without having to guess how tall the tool bar will get.  */
+  /* Calculate a tool bar height so that the user gets a text display
+     area of the size he specified with -g or via .Xdefaults.  Later
+     changes of the tool bar height don't change the frame size.  This
+     is done so that users can create tall Emacs frames without having
+     to guess how tall the tool bar will get.  */
   if (toolbar_p && FRAME_TOOL_BAR_LINES (f))
     {
       if (frame_default_tool_bar_height)
@@ -4634,6 +4603,69 @@ x_figure_window_size (struct frame *f, Lisp_Object parms, bool toolbar_p)
 	}
     }

+  /* Ensure that earlier new_width and new_height settings won't
+     override what we specify below.  */
+  f->new_width = f->new_height = 0;
+
+  height = x_get_arg (dpyinfo, parms, Qheight, 0, 0, RES_TYPE_NUMBER);
+  width = x_get_arg (dpyinfo, parms, Qwidth, 0, 0, RES_TYPE_NUMBER);
+  if (!EQ (width, Qunbound) || !EQ (height, Qunbound))
+    {
+      if (!EQ (width, Qunbound))
+	{
+	  if (FLOATP (width))
+	    {
+	      if ((int) XFLOAT_DATA (width) < 0
+		  || (int) XFLOAT_DATA (width) > INT_MAX)
+		xsignal1 (Qargs_out_of_range, width);
+	      else
+		{
+		  SET_FRAME_WIDTH (f, (int) XFLOAT_DATA (width));
+		  f->inhibit_horizontal_resize = true;
+		  *x_width = (int) XFLOAT_DATA (width);
+		}
+	    }
+	  else
+	    {
+	      CHECK_NUMBER (width);
+	      if ((XINT (width) < 0 || XINT (width) > INT_MAX))
+		xsignal1 (Qargs_out_of_range, width);
+
+	      SET_FRAME_WIDTH (f, XINT (width) * FRAME_COLUMN_WIDTH (f));
+	    }
+	}
+
+      if (!EQ (height, Qunbound))
+	{
+	  if (FLOATP (height))
+	    {
+	      if ((int) XFLOAT_DATA (height) < 0
+		  || (int) XFLOAT_DATA (height) > INT_MAX)
+		xsignal1 (Qargs_out_of_range, height);
+	      else
+		{
+		  SET_FRAME_HEIGHT (f, (int) XFLOAT_DATA (height));
+		  f->inhibit_vertical_resize = true;
+		  *x_height = (int) XFLOAT_DATA (height);
+		}
+	    }
+	  else
+	    {
+	      CHECK_NUMBER (height);
+	      if ((XINT (height) < 0) || (XINT (height) > INT_MAX))
+		xsignal1 (Qargs_out_of_range, height);
+
+	      SET_FRAME_HEIGHT (f, XINT (height) * FRAME_LINE_HEIGHT (f));
+	    }
+	}
+
+      user_size = x_get_arg (dpyinfo, parms, Quser_size, 0, 0, RES_TYPE_NUMBER);
+      if (!NILP (user_size) && !EQ (user_size, Qunbound))
+	window_prompting |= USSize;
+      else
+	window_prompting |= PSize;
+    }
+
   top = x_get_arg (dpyinfo, parms, Qtop, 0, 0, RES_TYPE_NUMBER);
   left = x_get_arg (dpyinfo, parms, Qleft, 0, 0, RES_TYPE_NUMBER);
   user_position = x_get_arg (dpyinfo, parms, Quser_position, 0, 0, RES_TYPE_NUMBER);
@@ -4909,7 +4941,9 @@ syms_of_frame (void)
   DEFSYM (Qadjust_frame_size_1, "adjust-frame-size-1");
   DEFSYM (Qadjust_frame_size_2, "adjust-frame-size-2");
   DEFSYM (Qadjust_frame_size_3, "adjust-frame-size-3");
+  DEFSYM (Qx_set_frame_parameters, "x-set-frame-parameters");
   DEFSYM (QEmacsFrameResize, "EmacsFrameResize");
+  DEFSYM (Qset_frame_size, "set-frame-size");
   DEFSYM (Qframe_inhibit_resize, "frame-inhibit-resize");
   DEFSYM (Qx_set_fullscreen, "x-set-fullscreen");
   DEFSYM (Qx_check_fullscreen, "x-check-fullscreen");
@@ -4917,13 +4951,16 @@ syms_of_frame (void)
   DEFSYM (Qxg_frame_set_char_size_1, "xg-frame-set-char-size-1");
   DEFSYM (Qxg_frame_set_char_size_2, "xg-frame-set-char-size-2");
   DEFSYM (Qxg_frame_set_char_size_3, "xg-frame-set-char-size-3");
+  DEFSYM (Qx_set_window_size_1, "x-set-window-size-1");
+  DEFSYM (Qx_set_window_size_2, "x-set-window-size-2");
+  DEFSYM (Qx_set_window_size_3, "x-set-window-size-3");
   DEFSYM (Qxg_change_toolbar_position, "xg-change-toolbar-position");
   DEFSYM (Qx_net_wm_state, "x-net-wm-state");
   DEFSYM (Qx_handle_net_wm_state, "x-handle-net-wm-state");
   DEFSYM (Qtb_size_cb, "tb-size-cb");
   DEFSYM (Qupdate_frame_tool_bar, "update-frame-tool-bar");
   DEFSYM (Qfree_frame_tool_bar, "free-frame-tool-bar");
-
+  DEFSYM (Qx_set_menu_bar_lines, "x-set-menu-bar-lines");
   DEFSYM (Qchange_frame_size, "change-frame-size");
   DEFSYM (Qxg_frame_set_char_size, "xg-frame-set-char-size");
   DEFSYM (Qset_window_configuration, "set-window-configuration");
@@ -4952,6 +4989,9 @@ syms_of_frame (void)
   DEFSYM (Qleft_fringe, "left-fringe");
   DEFSYM (Qline_spacing, "line-spacing");
   DEFSYM (Qmenu_bar_lines, "menu-bar-lines");
+  DEFSYM (Qupdate_frame_menubar, "update-frame-menubar");
+  DEFSYM (Qfree_frame_menubar_1, "free-frame-menubar-1");
+  DEFSYM (Qfree_frame_menubar_2, "free-frame-menubar-2");
   DEFSYM (Qmouse_color, "mouse-color");
   DEFSYM (Qname, "name");
   DEFSYM (Qright_divider_width, "right-divider-width");
diff --git a/src/frame.h b/src/frame.h
index af0dadb..acac514 100644
--- a/src/frame.h
+++ b/src/frame.h
@@ -335,6 +335,14 @@ struct frame
   /* Set to true after this frame was made by `make-frame'.  */
   bool_bf after_make_frame : 1;

+  /* Whether the tool bar height change should be taken into account.  */
+  bool_bf tool_bar_redisplayed : 1;
+  bool_bf tool_bar_resized : 1;
+
+  /* Inhibit implied resize before after_make_frame is set.  */
+  bool_bf inhibit_horizontal_resize : 1;
+  bool_bf inhibit_vertical_resize : 1;
+
   /* Non-zero if this frame's faces need to be recomputed.  */
   bool_bf face_change : 1;

@@ -1375,7 +1383,7 @@ extern void x_set_horizontal_scroll_bars (struct frame *, Lisp_Object, Lisp_Obje
 extern void x_set_scroll_bar_width (struct frame *, Lisp_Object, Lisp_Object);
 extern void x_set_scroll_bar_height (struct frame *, Lisp_Object, Lisp_Object);

-extern long x_figure_window_size (struct frame *, Lisp_Object, bool);
+extern long x_figure_window_size (struct frame *, Lisp_Object, bool, int *, int *);

 extern void x_set_alpha (struct frame *, Lisp_Object, Lisp_Object);

diff --git a/src/gtkutil.c b/src/gtkutil.c
index 725e330..3099d11 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -1401,7 +1401,8 @@ x_wm_set_size_hint (struct frame *f, long int flags, bool user_position)

   hint_flags |= GDK_HINT_BASE_SIZE;
   /* Use one row/col here so base_height/width does not become zero.
-     Gtk+ and/or Unity on Ubuntu 12.04 can't handle it.  */
+     Gtk+ and/or Unity on Ubuntu 12.04 can't handle it.
+     Obviously this makes the row/col value displayed off by 1.  */
   base_width = FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, 1) + FRAME_TOOLBAR_WIDTH (f);
   base_height = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, 1)
     + FRAME_MENUBAR_HEIGHT (f) + FRAME_TOOLBAR_HEIGHT (f);
@@ -5000,9 +5001,23 @@ update_frame_tool_bar (struct frame *f)
       gtk_widget_show_all (x->toolbar_widget);
       if (xg_update_tool_bar_sizes (f))
 	{
+	  int inhibit
+	    = ((f->after_make_frame
+		&& !f->tool_bar_resized
+		&& (EQ (frame_inhibit_implied_resize, Qt)
+		    || (CONSP (frame_inhibit_implied_resize)
+			&& !NILP (Fmemq (Qtool_bar_lines,
+					 frame_inhibit_implied_resize))))
+		/* This will probably fail to DTRT in the
+		   fullheight/-width cases.  */
+		&& NILP (get_frame_param (f, Qfullscreen)))
+	       ? 0
+	       : 2);
+
 	  frame_size_history_add (f, Qupdate_frame_tool_bar, 0, 0, Qnil);
-	  adjust_frame_size (f, -1, -1, 2, 0, Qtool_bar_lines);
+	  adjust_frame_size (f, -1, -1, inhibit, 0, Qtool_bar_lines);
 	}
+      f->tool_bar_resized = f->tool_bar_redisplayed;
     }

   unblock_input ();
diff --git a/src/nsfns.m b/src/nsfns.m
index ad71a50..43002ca 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -679,7 +679,23 @@ x_set_tool_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
         }
     }

-  x_set_window_size (f, 0, f->text_cols, f->text_lines, 0);
+  {
+    int inhibit
+      = ((f->after_make_frame
+	  && !f->tool_bar_resized
+	  && (EQ (frame_inhibit_implied_resize, Qt)
+	      || (CONSP (frame_inhibit_implied_resize)
+		  && !NILP (Fmemq (Qtool_bar_lines,
+				   frame_inhibit_implied_resize))))
+	  /* This will probably fail to DTRT in the
+	     fullheight/-width cases.  */
+	  && NILP (get_frame_param (f, Qfullscreen)))
+	 ? 0
+	 : 2);
+
+    frame_size_history_add (f, Qupdate_frame_tool_bar, 0, 0, Qnil);
+    adjust_frame_size (f, -1, -1, inhibit, 0, Qtool_bar_lines);
+  }
 }


@@ -1082,6 +1098,7 @@ This function is an internal primitive--use `make-frame' instead.  */)
   Lisp_Object parent;
   struct kboard *kb;
   static int desc_ctr = 1;
+  int x_width = 0, x_height = 0;

   /* x_get_arg modifies parms.  */
   parms = Fcopy_alist (parms);
@@ -1268,7 +1285,7 @@ This function is an internal primitive--use `make-frame' instead.  */)
                        RES_TYPE_STRING);

   parms = get_geometry_from_preferences (dpyinfo, parms);
-  window_prompting = x_figure_window_size (f, parms, 1);
+  window_prompting = x_figure_window_size (f, parms, true, &x_width, &x_height);

   tem = x_get_arg (dpyinfo, parms, Qunsplittable, 0, 0, RES_TYPE_BOOLEAN);
   f->no_split = minibuffer_only || (!EQ (tem, Qunbound) && !EQ (tem, Qnil));
@@ -1322,6 +1339,11 @@ This function is an internal primitive--use `make-frame' instead.  */)
   /* Allow x_set_window_size, now.  */
   f->can_x_set_window_size = true;

+  if (x_width > 0)
+    SET_FRAME_WIDTH (f, x_width);
+  if (x_height > 0)
+    SET_FRAME_HEIGHT (f, x_height);
+
   adjust_frame_size (f, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f), 0, 1,
 		     Qx_create_frame_2);

diff --git a/src/nsterm.m b/src/nsterm.m
index 65d07b2..c4bfd7c 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1365,9 +1365,12 @@ x_set_window_size (struct frame *f,
     FRAME_TOOLBAR_HEIGHT (f) =
       NSHeight ([window frameRectForContentRect: NSMakeRect (0, 0, 0, 0)])
         - FRAME_NS_TITLEBAR_HEIGHT (f);
+#if 0
+      /* Only breaks things here, removed by martin 2015-09-30.  */
 #ifdef NS_IMPL_GNUSTEP
       FRAME_TOOLBAR_HEIGHT (f) -= 3;
 #endif
+#endif
     }
   else
     FRAME_TOOLBAR_HEIGHT (f) = 0;
@@ -1386,6 +1389,14 @@ x_set_window_size (struct frame *f,
  else
    wr.origin.y += orig_height - wr.size.height;

+ frame_size_history_add
+   (f, Qx_set_window_size_1, width, height,
+    list5 (Fcons (make_number (pixelwidth), make_number (pixelheight)),
+	   Fcons (make_number (wr.size.width), make_number (wr.size.height)),
+	   make_number (f->border_width),
+	   make_number (FRAME_NS_TITLEBAR_HEIGHT (f)),
+	   make_number (FRAME_TOOLBAR_HEIGHT (f))));
+
   [view setRows: rows andColumns: cols];
   [window setFrame: wr display: YES];

@@ -7741,8 +7752,9 @@ x_new_font (struct frame *f, Lisp_Object font_object, int fontset)

   /* Now make the frame display the given font.  */
   if (FRAME_NS_WINDOW (f) != 0 && ! [view isFullscreen])
-    x_set_window_size (f, false, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
-                       FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), true);
+    adjust_frame_size (f, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
+		       FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), 3,
+		       false, Qfont);

   return font_object;
 }
diff --git a/src/w32fns.c b/src/w32fns.c
index 99fd3ba..5c69856 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -1761,14 +1761,20 @@ x_change_tool_bar_height (struct frame *f, int height)

   /* Recalculate toolbar height.  */
   f->n_tool_bar_rows = 0;
+  if (old_height == 0)
+    f->tool_bar_redisplayed = f->tool_bar_resized = false;

   adjust_frame_size (f, -1, -1,
-		     ((NILP (fullscreen = get_frame_param (f, Qfullscreen))
-		       || EQ (fullscreen, Qfullwidth)) ? 1
+		     ((!f->tool_bar_resized
+		       && (NILP (fullscreen =
+				 get_frame_param (f, Qfullscreen))
+			   || EQ (fullscreen, Qfullwidth))) ? 1
 		      : (old_height == 0 || height == 0) ? 2
 		      : 4),
 		     false, Qtool_bar_lines);

+  f->tool_bar_resized = f->tool_bar_redisplayed;
+
   /* adjust_frame_size might not have done anything, garbage frame
      here.  */
   adjust_frame_glyphs (f);
@@ -4367,97 +4373,7 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
     case WM_WINDOWPOSCHANGING:
       /* Don't restrict the sizing of any kind of frames.  If the window
 	 manager doesn't, there's no reason to do it ourselves.  */
-#if 0
-	if (frame_resize_pixelwise || hwnd == tip_window)
-#endif
-	  return 0;
-
-#if 0
-      /* Don't restrict the sizing of fullscreened frames, allowing them to be
-	 flush with the sides of the screen.  */
-      f = x_window_to_frame (dpyinfo, hwnd);
-      if (f && FRAME_PREV_FSMODE (f) != FULLSCREEN_NONE)
-	return 0;
-
-      {
-	WINDOWPLACEMENT wp;
-	LPWINDOWPOS lppos = (WINDOWPOS *) lParam;
-
-	wp.length = sizeof (WINDOWPLACEMENT);
-	GetWindowPlacement (hwnd, &wp);
-
-	if (wp.showCmd != SW_SHOWMAXIMIZED && wp.showCmd != SW_SHOWMINIMIZED
-	    && (lppos->flags & SWP_NOSIZE) == 0)
-	  {
-	    RECT rect;
-	    int wdiff;
-	    int hdiff;
-	    DWORD font_width;
-	    DWORD line_height;
-	    DWORD internal_border;
-	    DWORD vscrollbar_extra;
-	    DWORD hscrollbar_extra;
-	    RECT wr;
-
-	    wp.length = sizeof (wp);
-	    GetWindowRect (hwnd, &wr);
-
-	    enter_crit ();
-
-	    font_width = GetWindowLong (hwnd, WND_FONTWIDTH_INDEX);
-	    line_height = GetWindowLong (hwnd, WND_LINEHEIGHT_INDEX);
-	    internal_border = GetWindowLong (hwnd, WND_BORDER_INDEX);
-	    vscrollbar_extra = GetWindowLong (hwnd, WND_VSCROLLBAR_INDEX);
-	    hscrollbar_extra = GetWindowLong (hwnd, WND_HSCROLLBAR_INDEX);
-
-	    leave_crit ();
-
-	    memset (&rect, 0, sizeof (rect));
-	    AdjustWindowRect (&rect, GetWindowLong (hwnd, GWL_STYLE),
-			      GetMenu (hwnd) != NULL);
-
-	    /* Force width and height of client area to be exact
-	       multiples of the character cell dimensions.  */
-	    wdiff = (lppos->cx - (rect.right - rect.left)
-		     - 2 * internal_border - vscrollbar_extra)
-	      % font_width;
-	    hdiff = (lppos->cy - (rect.bottom - rect.top)
-		     - 2 * internal_border - hscrollbar_extra)
-	      % line_height;
-
-	    if (wdiff || hdiff)
-	      {
-		/* For right/bottom sizing we can just fix the sizes.
-		   However for top/left sizing we will need to fix the X
-		   and Y positions as well.  */
-
-		int cx_mintrack = GetSystemMetrics (SM_CXMINTRACK);
-		int cy_mintrack = GetSystemMetrics (SM_CYMINTRACK);
-
-		lppos->cx = max (lppos->cx - wdiff, cx_mintrack);
-		lppos->cy = max (lppos->cy - hdiff, cy_mintrack);
-
-		if (wp.showCmd != SW_SHOWMAXIMIZED
-		    && (lppos->flags & SWP_NOMOVE) == 0)
-		  {
-		    if (lppos->x != wr.left || lppos->y != wr.top)
-		      {
-			lppos->x += wdiff;
-			lppos->y += hdiff;
-		      }
-		    else
-		      {
-			lppos->flags |= SWP_NOMOVE;
-		      }
-		  }
-
-		return 0;
-	      }
-	  }
-      }
-
-      goto dflt;
-#endif
+      return 0;

     case WM_GETMINMAXINFO:
       /* Hack to allow resizing the Emacs frame above the screen size.
@@ -4976,6 +4892,7 @@ This function is an internal primitive--use `make-frame' instead.  */)
   struct w32_display_info *dpyinfo = NULL;
   Lisp_Object parent;
   struct kboard *kb;
+  int x_width = 0, x_height = 0;

   if (!FRAME_W32_P (SELECTED_FRAME ())
       && !FRAME_INITIAL_P (SELECTED_FRAME ()))
@@ -5198,7 +5115,7 @@ This function is an internal primitive--use `make-frame' instead.  */)

   f->output_data.w32->current_cursor = f->output_data.w32->nontext_cursor;

-  window_prompting = x_figure_window_size (f, parameters, true);
+  window_prompting = x_figure_window_size (f, parameters, true, &x_width, &x_height);

   tem = x_get_arg (dpyinfo, parameters, Qunsplittable, 0, 0, RES_TYPE_BOOLEAN);
   f->no_split = minibuffer_only || EQ (tem, Qt);
@@ -5232,8 +5149,10 @@ This function is an internal primitive--use `make-frame' instead.  */)
   /* Allow x_set_window_size, now.  */
   f->can_x_set_window_size = true;

-  adjust_frame_size (f, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f), 0, true,
-		     Qx_create_frame_2);
+  if (x_width > 0)
+    SET_FRAME_WIDTH (f, x_width);
+  if (x_height > 0)
+    SET_FRAME_HEIGHT (f, x_height);

   /* Tell the server what size and position, etc, we want, and how
      badly we want them.  This should be done after we have the menu
@@ -5242,6 +5161,9 @@ This function is an internal primitive--use `make-frame' instead.  */)
   x_wm_set_size_hint (f, window_prompting, false);
   unblock_input ();

+  adjust_frame_size (f, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f), 0, true,
+		     Qx_create_frame_2);
+
   /* Process fullscreen parameter here in the hope that normalizing a
      fullheight/fullwidth frame will produce the size set by the last
      adjust_frame_size call.  */
@@ -6178,6 +6100,7 @@ x_create_tip_frame (struct w32_display_info *dpyinfo,
   bool face_change_before = face_change;
   Lisp_Object buffer;
   struct buffer *old_buffer;
+  int x_width = 0, x_height = 0;

   /* Use this general default value to start with until we know if
      this frame has a specified name.  */
@@ -6308,7 +6231,7 @@ x_create_tip_frame (struct w32_display_info *dpyinfo,
   f->output_data.w32->dwStyle = WS_BORDER | WS_POPUP | WS_DISABLED;
   f->output_data.w32->parent_desc = FRAME_DISPLAY_INFO (f)->root_window;

-  window_prompting = x_figure_window_size (f, parms, false);
+  window_prompting = x_figure_window_size (f, parms, true, &x_width, &x_height);

   /* No fringes on tip frame.  */
   f->fringe_cols = 0;
diff --git a/src/w32term.c b/src/w32term.c
index 82b05bf..d8c4550 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -6176,6 +6176,13 @@ x_set_window_size (struct frame *f, bool change_gravity,

   if (pixelwidth > 0 || pixelheight > 0)
     {
+      frame_size_history_add
+	(f, Qx_set_window_size_1, width, height,
+	 list2 (Fcons (make_number (pixelwidth),
+		       make_number (pixelheight)),
+		Fcons (make_number (rect.right - rect.left),
+		       make_number (rect.bottom - rect.top))));
+
       my_set_window_pos (FRAME_W32_WINDOW (f), NULL,
 			 0, 0,
 			 rect.right - rect.left,
diff --git a/src/widget.c b/src/widget.c
index 0986ba6..48872f5 100644
--- a/src/widget.c
+++ b/src/widget.c
@@ -268,167 +268,26 @@ set_frame_size (EmacsFrame ew)
    */

   /* Hairily merged geometry */
-  int w = FRAME_COLS (ew->emacs_frame.frame);
-  int h = FRAME_LINES (ew->emacs_frame.frame);
-
+  struct frame *f = ew->emacs_frame.frame;
+  int w = FRAME_COLS (f);
+  int h = FRAME_LINES (f);
   Widget wmshell = get_wm_shell ((Widget) ew);
+  Dimension pixel_width, pixel_height;
   /* Each Emacs shell is now independent and top-level.  */

   if (! XtIsSubclass (wmshell, shellWidgetClass)) emacs_abort ();

-  /* We don't need this for the moment. The geometry is computed in
-     xfns.c.  */
-#if 0
-  /* If the EmacsFrame doesn't have a geometry but the shell does,
-     treat that as the geometry of the frame.  (Is this bogus?
-     I'm not sure.) */
-  if (ew->emacs_frame.geometry == 0)
-    XtVaGetValues (wmshell, XtNgeometry, &ew->emacs_frame.geometry, NULL);
-
-  /* If the Shell is iconic, then the EmacsFrame is iconic.  (Is
-     this bogus? I'm not sure.) */
-  if (!ew->emacs_frame.iconic)
-    XtVaGetValues (wmshell, XtNiconic, &ew->emacs_frame.iconic, NULL);
-
-
-  {
-    char *geom = 0;
-    XtVaGetValues (app_shell, XtNgeometry, &geom, NULL);
-    if (geom)
-      app_flags = XParseGeometry (geom, &app_x, &app_y, &app_w, &app_h);
-  }
-
-  if (ew->emacs_frame.geometry)
-    frame_flags = XParseGeometry (ew->emacs_frame.geometry,
-				   &frame_x, &frame_y,
-				   &frame_w, &frame_h);
-
-  if (first_frame_p)
-    {
-      /* If this is the first frame created:
-         ====================================
-
-         - Use the ApplicationShell's size/position, if specified.
-           (This is "Emacs.geometry", or the "-geometry" command line arg.)
-         - Else use the EmacsFrame's size/position.
-           (This is "*Frame-NAME.geometry")
-
-	 - If the AppShell is iconic, the frame should be iconic.
-
-	 AppShell comes first so that -geometry always applies to the first
-	 frame created, even if there is an "every frame" entry in the
-	 resource database.
-       */
-      if (app_flags & (XValue | YValue))
-	{
-	  x = app_x; y = app_y;
-	  flags |= (app_flags & (XValue | YValue | XNegative | YNegative));
-	}
-      else if (frame_flags & (XValue | YValue))
-	{
-	  x = frame_x; y = frame_y;
-	  flags |= (frame_flags & (XValue | YValue | XNegative | YNegative));
-	}
-
-      if (app_flags & (WidthValue | HeightValue))
-	{
-	  w = app_w; h = app_h;
-	  flags |= (app_flags & (WidthValue | HeightValue));
-	}
-      else if (frame_flags & (WidthValue | HeightValue))
-	{
-	  w = frame_w; h = frame_h;
-	  flags |= (frame_flags & (WidthValue | HeightValue));
-	}
-
-      /* If the AppShell is iconic, then the EmacsFrame is iconic. */
-      if (!ew->emacs_frame.iconic)
-	XtVaGetValues (app_shell, XtNiconic, &ew->emacs_frame.iconic, NULL);
-
-      first_frame_p = False;
-    }
-  else
-    {
-      /* If this is not the first frame created:
-         ========================================
-
-         - use the EmacsFrame's size/position if specified
-         - Otherwise, use the ApplicationShell's size, but not position.
-
-         So that means that one can specify the position of the first frame
-         with "Emacs.geometry" or `-geometry'; but can only specify the
-	 position of subsequent frames with "*Frame-NAME.geometry".
-
-	 AppShell comes second so that -geometry does not apply to subsequent
-	 frames when there is an "every frame" entry in the resource db,
-	 but does apply to the first frame.
-       */
-      if (frame_flags & (XValue | YValue))
-	{
-	  x = frame_x; y = frame_y;
-	  flags |= (frame_flags & (XValue | YValue | XNegative | YNegative));
-	}
+  char_to_pixel_size (ew, w, h, &pixel_width, &pixel_height);
+  ew->core.width = (frame_resize_pixelwise
+		    ? FRAME_PIXEL_WIDTH (f)
+		    : pixel_width);
+  ew->core.height = (frame_resize_pixelwise
+		     ? FRAME_PIXEL_HEIGHT (f)
+		     : pixel_height);

-      if (frame_flags & (WidthValue | HeightValue))
-	{
-	  w = frame_w; h = frame_h;
-	  flags |= (frame_flags & (WidthValue | HeightValue));
-	}
-      else if (app_flags & (WidthValue | HeightValue))
-	{
-	  w = app_w;
-	  h = app_h;
-	  flags |= (app_flags & (WidthValue | HeightValue));
-	}
-    }
-#endif /* 0 */
-  {
-    Dimension pixel_width, pixel_height;
-
-    /* Take into account the size of the scrollbar.  Always use the
-       number of columns occupied by the scroll bar here otherwise we
-       might end up with a frame width that is not a multiple of the
-       frame's character width which is bad for vertically split
-       windows.  */
-
-#if 0 /* This can run Lisp code, and it is dangerous to give
-	 out the frame to Lisp code before it officially exists.
-	 This is handled in Fx_create_frame so not needed here.  */
-    change_frame_size (f, w, h, 1, 0, 0, 0);
-#endif
-    char_to_pixel_size (ew, w, h, &pixel_width, &pixel_height);
-    ew->core.width = pixel_width;
-    ew->core.height = pixel_height;
-
-#if 0 /* xfns.c takes care of this now.  */
-    /* If a position was specified, assign it to the shell widget.
-       (Else WM won't do anything with it.)
-     */
-    if (flags & (XValue | YValue))
-      {
-	/* the tricky things with the sign is to make sure that
-	   -0 is printed -0. */
-	sprintf (shell_position, "=%c%d%c%d",
-		 flags & XNegative ? '-' : '+', x < 0 ? -x : x,
-		 flags & YNegative ? '-' : '+', y < 0 ? -y : y);
-	XtVaSetValues (wmshell, XtNgeometry, xstrdup (shell_position), NULL);
-      }
-    else if (flags & (WidthValue | HeightValue))
-      {
-	sprintf (shell_position, "=%dx%d", pixel_width, pixel_height);
-	XtVaSetValues (wmshell, XtNgeometry, xstrdup (shell_position), NULL);
-      }
-
-    /* If the geometry spec we're using has W/H components, mark the size
-       in the WM_SIZE_HINTS as user specified. */
-    if (flags & (WidthValue | HeightValue))
-      mark_shell_size_user_specified (wmshell);
-
-    /* Also assign the iconic status of the frame to the Shell, so that
-       the WM sees it. */
-    XtVaSetValues (wmshell, XtNiconic, ew->emacs_frame.iconic, NULL);
-#endif /* 0 */
-  }
+  frame_size_history_add
+    (f, Qset_frame_size, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f),
+     list2 (make_number (ew->core.width), make_number (ew->core.height)));
 }

 static void
@@ -486,16 +345,6 @@ update_various_frame_slots (EmacsFrame ew)
 {
   struct frame *f = ew->emacs_frame.frame;

-  /* Don't do that: It confuses the check in change_frame_size_1 whether
-     the pixel size of the frame changed due to a change of the internal
-     border width.  Bug#16736.  */
-  if (false)
-    {
-      struct x_output *x = f->output_data.x;
-      FRAME_PIXEL_HEIGHT (f) = ew->core.height + x->menubar_height;
-      FRAME_PIXEL_WIDTH (f) = ew->core.width;
-    }
-
   f->internal_border_width = ew->emacs_frame.internal_border_width;
 }

@@ -504,6 +353,7 @@ update_from_various_frame_slots (EmacsFrame ew)
 {
   struct frame *f = ew->emacs_frame.frame;
   struct x_output *x = f->output_data.x;
+
   ew->core.height = FRAME_PIXEL_HEIGHT (f) - x->menubar_height;
   ew->core.width = FRAME_PIXEL_WIDTH (f);
   ew->core.background_pixel = FRAME_BACKGROUND_PIXEL (f);
@@ -576,7 +426,10 @@ EmacsFrameResize (Widget widget)

   frame_size_history_add
     (f, QEmacsFrameResize, width, height,
-     list2 (make_number (ew->core.width), make_number (ew->core.height)));
+     list5 (make_number (ew->core.width), make_number (ew->core.height),
+	    make_number (FRAME_TOP_MARGIN_HEIGHT (f)),
+	    make_number (FRAME_SCROLL_BAR_AREA_HEIGHT (f)),
+	    make_number (2 * FRAME_INTERNAL_BORDER_WIDTH (f))));

   change_frame_size (f, width, height, 0, 1, 0, 1);

@@ -596,11 +449,12 @@ EmacsFrameQueryGeometry (Widget widget, XtWidgetGeometry *request, XtWidgetGeome

   if (mask & (CWWidth | CWHeight))
     {
-      round_size_to_char (ew,
-			  (mask & CWWidth) ? request->width : ew->core.width,
-			  ((mask & CWHeight) ? request->height
-			   : ew->core.height),
-			  &ok_width, &ok_height);
+      if (!frame_resize_pixelwise)
+	round_size_to_char (ew,
+			    (mask & CWWidth) ? request->width : ew->core.width,
+			    ((mask & CWHeight) ? request->height
+			     : ew->core.height),
+			    &ok_width, &ok_height);
       if ((mask & CWWidth) && (ok_width != request->width))
 	{
 	  result->request_mode |= CWWidth;
diff --git a/src/xdisp.c b/src/xdisp.c
index 1524783..0a2b3ae 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -12310,6 +12310,7 @@ PIXELWISE non-nil means return the height of the tool bar in pixels.  */)
 static bool
 redisplay_tool_bar (struct frame *f)
 {
+  f->tool_bar_redisplayed = true;
 #if defined (USE_GTK) || defined (HAVE_NS)

   if (FRAME_EXTERNAL_TOOL_BAR (f))
diff --git a/src/xfns.c b/src/xfns.c
index fc6111c..b4397ad 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -1064,7 +1064,7 @@ x_set_menu_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
 #else /* not USE_X_TOOLKIT && not USE_GTK */
   FRAME_MENU_BAR_LINES (f) = nlines;
   FRAME_MENU_BAR_HEIGHT (f) = nlines * FRAME_LINE_HEIGHT (f);
-  adjust_frame_size (f, -1, -1, 2, true, Qmenu_bar_lines);
+  adjust_frame_size (f, -1, -1, 2, true, Qx_set_menu_bar_lines);
   if (FRAME_X_WINDOW (f))
     x_clear_under_internal_border (f);

@@ -1188,12 +1188,16 @@ x_change_tool_bar_height (struct frame *f, int height)
   f->n_tool_bar_rows = 0;

   adjust_frame_size (f, -1, -1,
-		     ((NILP (fullscreen = get_frame_param (f, Qfullscreen))
-		       || EQ (fullscreen, Qfullwidth)) ? 1
+		     ((!f->tool_bar_resized
+		       && (NILP (fullscreen =
+				 get_frame_param (f, Qfullscreen))
+			   || EQ (fullscreen, Qfullwidth))) ? 1
 		      : (old_height == 0 || height == 0) ? 2
 		      : 4),
 		     false, Qtool_bar_lines);

+  f->tool_bar_resized = f->tool_bar_redisplayed;
+
   /* adjust_frame_size might not have done anything, garbage frame
      here.  */
   adjust_frame_glyphs (f);
@@ -2975,6 +2979,7 @@ This function is an internal primitive--use `make-frame' instead.  */)
   struct x_display_info *dpyinfo = NULL;
   Lisp_Object parent;
   struct kboard *kb;
+  int x_width = 0, x_height = 0;

   parms = Fcopy_alist (parms);

@@ -3249,7 +3254,7 @@ This function is an internal primitive--use `make-frame' instead.  */)
                        FRAME_TOOL_BAR_POSITION (f), 0, 0, RES_TYPE_SYMBOL);

   /* Compute the size of the X window.  */
-  window_prompting = x_figure_window_size (f, parms, true);
+  window_prompting = x_figure_window_size (f, parms, true, &x_width, &x_height);

   tem = x_get_arg (dpyinfo, parms, Qunsplittable, 0, 0, RES_TYPE_BOOLEAN);
   f->no_split = minibuffer_only || EQ (tem, Qt);
@@ -3291,12 +3296,6 @@ This function is an internal primitive--use `make-frame' instead.  */)
   x_default_parameter (f, parms, Qalpha, Qnil,
 		       "alpha", "Alpha", RES_TYPE_NUMBER);

-  /* Consider frame official, now.  */
-  f->can_x_set_window_size = true;
-
-  adjust_frame_size (f, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f), 0, true,
-		     Qx_create_frame_2);
-
 #if defined (USE_X_TOOLKIT) || defined (USE_GTK)
   /* Create the menu bar.  */
   if (!minibuffer_only && FRAME_EXTERNAL_MENU_BAR (f))
@@ -3315,6 +3314,14 @@ This function is an internal primitive--use `make-frame' instead.  */)
     }
 #endif /* USE_X_TOOLKIT || USE_GTK */

+  /* Consider frame official, now.  */
+  f->can_x_set_window_size = true;
+
+  if (x_width > 0)
+    SET_FRAME_WIDTH (f, x_width);
+  if (x_height > 0)
+    SET_FRAME_HEIGHT (f, x_height);
+
   /* Tell the server what size and position, etc, we want, and how
      badly we want them.  This should be done after we have the menu
      bar so that its size can be taken into account.  */
@@ -3322,6 +3329,9 @@ This function is an internal primitive--use `make-frame' instead.  */)
   x_wm_set_size_hint (f, window_prompting, false);
   unblock_input ();

+  adjust_frame_size (f, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f),
+		     0, true, Qx_create_frame_2);
+
   /* Process fullscreen parameter here in the hope that normalizing a
      fullheight/fullwidth frame will produce the size set by the last
      adjust_frame_size call.  */
@@ -5135,6 +5145,7 @@ x_create_tip_frame (struct x_display_info *dpyinfo,
   bool face_change_before = face_change;
   Lisp_Object buffer;
   struct buffer *old_buffer;
+  int x_width = 0, x_height = 0;

   if (!dpyinfo->terminal->name)
     error ("Terminal is not live, can't create new frames on it");
@@ -5307,7 +5318,7 @@ x_create_tip_frame (struct x_display_info *dpyinfo,

   f->output_data.x->parent_desc = FRAME_DISPLAY_INFO (f)->root_window;

-  x_figure_window_size (f, parms, false);
+  x_figure_window_size (f, parms, false, &x_width, &x_height);

   {
     XSetWindowAttributes attrs;
diff --git a/src/xmenu.c b/src/xmenu.c
index f183c70..ee7769a 100644
--- a/src/xmenu.c
+++ b/src/xmenu.c
@@ -636,13 +636,7 @@ update_frame_menubar (struct frame *f)
   lw_refigure_widget (x->column_widget, True);

   /* Force the pane widget to resize itself.  */
-  int new_height = -1;
-#ifdef USE_LUCID
-  /* For reasons I don't know Lucid wants to add one pixel to the frame
-     height when adding the menu bar.  Compensate that here.  */
-  new_height = FRAME_TEXT_HEIGHT (f) - 1;
-#endif /* USE_LUCID */
-  adjust_frame_size (f, -1, new_height, 2, false, Qmenu_bar_lines);
+  adjust_frame_size (f, -1, -1, 2, false, Qupdate_frame_menubar);
   unblock_input ();
 #endif /* USE_GTK */
 }
@@ -979,7 +973,15 @@ set_frame_menubar (struct frame *f, bool first_time, bool deep_p)
     menubar_size
       = (f->output_data.x->menubar_widget
 	 ? (f->output_data.x->menubar_widget->core.height
-	    + f->output_data.x->menubar_widget->core.border_width)
+#ifndef USE_LUCID
+	    /* Damn me...  With Lucid I get a core.border_width of 1
+	       only the first time this is called and an ibw of 1 every
+	       time this is called.  So the first time this is called I
+	       was off by one.  Fix that here by never adding
+	       core.border_width for Lucid.  */
+	    + f->output_data.x->menubar_widget->core.border_width
+#endif /* USE_LUCID */
+	    )
 	 : 0);

 #ifdef USE_LUCID
@@ -990,9 +992,10 @@ set_frame_menubar (struct frame *f, bool first_time, bool deep_p)
     if (FRAME_EXTERNAL_MENU_BAR (f))
       {
         Dimension ibw = 0;
+
         XtVaGetValues (f->output_data.x->column_widget,
 		       XtNinternalBorderWidth, &ibw, NULL);
-        menubar_size += ibw;
+	menubar_size += ibw;
       }
 #endif /* USE_LUCID */

@@ -1081,13 +1084,14 @@ free_frame_menubar (struct frame *f)
 	  if (frame_inhibit_resize (f, false, Qmenu_bar_lines))
 	    new_height = old_height;
 #endif /* USE_MOTIF */
-	  adjust_frame_size (f, -1, new_height, 2, false, Qmenu_bar_lines);
+	  adjust_frame_size (f, -1, new_height, 2, false, Qfree_frame_menubar_1);
 	}
       else
 	{
 #ifdef USE_MOTIF
-	  if (frame_inhibit_resize (f, false, Qmenu_bar_lines))
-	    adjust_frame_size (f, -1, old_height, 1, false, Qmenu_bar_lines);
+	  if (WINDOWP (FRAME_ROOT_WINDOW (f))
+	      && frame_inhibit_resize (f, false, Qmenu_bar_lines))
+	    adjust_frame_size (f, -1, old_height, 1, false, Qfree_frame_menubar_2);
 #endif
 	}

diff --git a/src/xterm.c b/src/xterm.c
index dd54552..a51d517 100644
--- a/src/xterm.c
+++ b/src/xterm.c
@@ -9408,6 +9408,10 @@ x_new_font (struct frame *f, Lisp_Object font_object, int fontset)
 {
   struct font *font = XFONT_OBJECT (font_object);
   int unit, font_ascent, font_descent;
+#ifndef USE_X_TOOLKIT
+  int old_menu_bar_height = FRAME_MENU_BAR_HEIGHT (f);
+  Lisp_Object fullscreen;
+#endif

   if (fontset < 0)
     fontset = fontset_from_font (font_object);
@@ -9444,9 +9448,25 @@ x_new_font (struct frame *f, Lisp_Object font_object, int fontset)
 	 doing it because it's done in Fx_show_tip, and it leads to
 	 problems because the tip frame has no widget.  */
       if (NILP (tip_frame) || XFRAME (tip_frame) != f)
+	{
 	  adjust_frame_size (f, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
 			     FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), 3,
 			     false, Qfont);
+#ifndef USE_X_TOOLKIT
+	  if (FRAME_MENU_BAR_HEIGHT (f) != old_menu_bar_height
+	      && !f->after_make_frame
+	      && (EQ (frame_inhibit_implied_resize, Qt)
+		  || (CONSP (frame_inhibit_implied_resize)
+		      && NILP (Fmemq (Qfont, frame_inhibit_implied_resize))))
+	      && (NILP (fullscreen = get_frame_param (f, Qfullscreen))
+		  || EQ (fullscreen, Qfullwidth)))
+	    /* If the menu bar height changes, try to keep text height
+	       constant.  */
+	    adjust_frame_size
+	      (f, -1, FRAME_TEXT_HEIGHT (f) + FRAME_MENU_BAR_HEIGHT (f)
+	       - old_menu_bar_height, 1, false, Qfont);
+#endif /* USE_X_TOOLKIT  */
+	}
     }

 #ifdef HAVE_X_I18N
@@ -10379,7 +10399,7 @@ x_set_window_size_1 (struct frame *f, bool change_gravity,
   if (EQ (fullscreen, Qfullwidth) && width == FRAME_TEXT_WIDTH (f))
     {
       frame_size_history_add
-	(f, Qxg_frame_set_char_size_1, width, height,
+	(f, Qx_set_window_size_1, width, height,
 	 list2 (make_number (old_height),
 		make_number (pixelheight + FRAME_MENUBAR_HEIGHT (f))));

@@ -10389,7 +10409,7 @@ x_set_window_size_1 (struct frame *f, bool change_gravity,
   else if (EQ (fullscreen, Qfullheight) && height == FRAME_TEXT_HEIGHT (f))
     {
       frame_size_history_add
-	(f, Qxg_frame_set_char_size_2, width, height,
+	(f, Qx_set_window_size_2, width, height,
 	 list2 (make_number (old_width), make_number (pixelwidth)));

       XResizeWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
@@ -10399,10 +10419,11 @@ x_set_window_size_1 (struct frame *f, bool change_gravity,
   else
     {
       frame_size_history_add
-	(f, Qxg_frame_set_char_size_3, width, height,
-	 list2 (make_number (pixelwidth + FRAME_TOOLBAR_WIDTH (f)),
+	(f, Qx_set_window_size_3, width, height,
+	 list3 (make_number (pixelwidth + FRAME_TOOLBAR_WIDTH (f)),
 		make_number (pixelheight + FRAME_TOOLBAR_HEIGHT (f)
-			     + FRAME_MENUBAR_HEIGHT (f))));
+			     + FRAME_MENUBAR_HEIGHT (f)),
+		make_number (FRAME_MENUBAR_HEIGHT (f))));

       XResizeWindow (FRAME_X_DISPLAY (f), FRAME_OUTER_WINDOW (f),
 		     pixelwidth, pixelheight + FRAME_MENUBAR_HEIGHT (f));
@@ -11172,8 +11193,8 @@ x_wm_set_size_hint (struct frame *f, long flags, bool user_position)
   size_hints.x = f->left_pos;
   size_hints.y = f->top_pos;

-  size_hints.height = FRAME_PIXEL_HEIGHT (f);
   size_hints.width = FRAME_PIXEL_WIDTH (f);
+  size_hints.height = FRAME_PIXEL_HEIGHT (f);

   size_hints.width_inc = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
   size_hints.height_inc = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);
@@ -11186,34 +11207,21 @@ x_wm_set_size_hint (struct frame *f, long flags, bool user_position)
   /* Calculate the base and minimum sizes.  */
   {
     int base_width, base_height;
-    int min_rows = 0, min_cols = 0;

     base_width = FRAME_TEXT_COLS_TO_PIXEL_WIDTH (f, 0);
     base_height = FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (f, 0);

-    if (frame_resize_pixelwise)
-      /* Needed to prevent a bad protocol error crash when making the
-	 frame size very small.  */
-      {
-	min_cols = 2 * min_cols;
-	min_rows = 2 * min_rows;
-      }
-
     /* The window manager uses the base width hints to calculate the
        current number of rows and columns in the frame while
        resizing; min_width and min_height aren't useful for this
        purpose, since they might not give the dimensions for a
-       zero-row, zero-column frame.
-
-       We use the base_width and base_height members if we have
-       them; otherwise, we set the min_width and min_height members
-       to the size for a zero x zero frame.  */
+       zero-row, zero-column frame.  */

     size_hints.flags |= PBaseSize;
     size_hints.base_width = base_width;
     size_hints.base_height = base_height + FRAME_MENUBAR_HEIGHT (f);
-    size_hints.min_width  = base_width + min_cols * FRAME_COLUMN_WIDTH (f);
-    size_hints.min_height = base_height + min_rows * FRAME_LINE_HEIGHT (f);
+    size_hints.min_width  = base_width;
+    size_hints.min_height = base_height;
   }

   /* If we don't need the old flags, we don't need the old hint at all.  */

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Andy Moreton]

On Fri 02 Oct 2015, martin rudalics wrote:
> Find attached the most recent version of the patch.  Fixes are mainly
> for Lucid/Motif but something might change for other platforms as well.
>
> @@ -3166,15 +3171,25 @@ x_set_frame_parameters (struct frame *f, Lisp_Object alist)
>        prop = parms[i];
>        val = values[i];
>
> -      if (EQ (prop, Qwidth) && RANGED_INTEGERP (0, val, INT_MAX))
> +      if (EQ (prop, Qwidth))
>          {
>  	  width_change = 1;
> -          width = XFASTINT (val) * FRAME_COLUMN_WIDTH (f) ;
> +	  if (RANGED_INTEGERP (0, val, INT_MAX))
> +	    width = XFASTINT (val) * FRAME_COLUMN_WIDTH (f) ;
> +	  else if (FLOATP (val)
> +		   && XFLOAT_DATA (val) >= 0
> +		   && (int) XFLOAT_DATA (val) <= INT_MAX)
> +	    width = (int) XFLOAT_DATA (val);
>          }

This changes the logic to set width_change even when Qwidth is an
out of range integer: is that intended ?

> -      else if (EQ (prop, Qheight) && RANGED_INTEGERP (0, val, INT_MAX))
> +      else if (EQ (prop, Qheight))
>          {
>  	  height_change = 1;
> -          height = XFASTINT (val) * FRAME_LINE_HEIGHT (f);
> +	  if (RANGED_INTEGERP (0, val, INT_MAX))
> +	    height = XFASTINT (val) * FRAME_LINE_HEIGHT (f);
> +	  else if (FLOATP (val)
> +		   && XFLOAT_DATA (val) >= 0
> +		   && (int) XFLOAT_DATA (val) <= INT_MAX)
> +	    height = (int) XFLOAT_DATA (val);

Similarly for height_change.

    AndyM

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 >> @@ -3166,15 +3171,25 @@ x_set_frame_parameters (struct frame *f, Lisp_Object alist)
 >>         prop = parms[i];
 >>         val = values[i];
 >>
 >> -      if (EQ (prop, Qwidth) && RANGED_INTEGERP (0, val, INT_MAX))
 >> +      if (EQ (prop, Qwidth))
 >>           {
 >>   	  width_change = 1;
 >> -          width = XFASTINT (val) * FRAME_COLUMN_WIDTH (f) ;
 >> +	  if (RANGED_INTEGERP (0, val, INT_MAX))
 >> +	    width = XFASTINT (val) * FRAME_COLUMN_WIDTH (f) ;
 >> +	  else if (FLOATP (val)
 >> +		   && XFLOAT_DATA (val) >= 0
 >> +		   && (int) XFLOAT_DATA (val) <= INT_MAX)
 >> +	    width = (int) XFLOAT_DATA (val);
 >>           }
 >
 > This changes the logic to set width_change even when Qwidth is an
 > out of range integer: is that intended ?

Certainly not.

 >> -      else if (EQ (prop, Qheight) && RANGED_INTEGERP (0, val, INT_MAX))
 >> +      else if (EQ (prop, Qheight))
 >>           {
 >>   	  height_change = 1;
 >> -          height = XFASTINT (val) * FRAME_LINE_HEIGHT (f);
 >> +	  if (RANGED_INTEGERP (0, val, INT_MAX))
 >> +	    height = XFASTINT (val) * FRAME_LINE_HEIGHT (f);
 >> +	  else if (FLOATP (val)
 >> +		   && XFLOAT_DATA (val) >= 0
 >> +		   && (int) XFLOAT_DATA (val) <= INT_MAX)
 >> +	    height = (int) XFLOAT_DATA (val);
 >
 > Similarly for height_change.

Thanks for the heads-up.  I will fix that.

Did you try the rest of it?  Any suggestions?

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Andy Moreton]

On Sat 03 Oct 2015, martin rudalics wrote:
> Thanks for the heads-up.  I will fix that.
>
> Did you try the rest of it?  Any suggestions?

The use of a float for an exact number of pixels seems an odd interface
design. What if you later want to add the ability to specify frame sizes
in inches or mm ?

    AndyM

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > The use of a float for an exact number of pixels seems an odd interface
 > design. What if you later want to add the ability to specify frame sizes
 > in inches or mm ?

How about using entries like

(width . (text-pixels . 400))

instead?  Then "text" could be replaced by "native", "outer" or "inner"
and "pixels" could be replaced by "mms" or "inches".

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Sorry for taking so long to try this patch out.  I tried the latest patch out this evening on a new build with OSX 10.6.8 -- master branch -- and the tests I performed work well -- i.e., I have a default-frame-alist that creates the perfect size initial and subsequent frames to precise pixel specifications using courier font size 18.

 (font . "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
 (top . 0)
 (left . 0)
 (left-fringe . 8)
 (right-fringe . 8)
 (vertical-scroll-bars)
 (cursor-color . "yellow")
 (cursor-type bar . 1)
 (background-color . "black")
 (foreground-color . "white")
 (tool-bar-lines . 0)
 (menu-bar-lines . 0)
 (width . 1900.0)
 (height . 1054.0)

Keith


At Fri, 02 Oct 2015 10:37:55 +0200,
martin rudalics wrote:
> 
>  > I wasn't sure if anything had changed in the past couple of weeks, so
>  > I did a hard reset back to the last commit on September 11, 2015 and
>  > then applied the patch to do my testing.
> 
> Find attached the most recent version of the patch.  Fixes are mainly
> for Lucid/Motif but something might change for other platforms as well.

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Sorry for taking so long to try this patch out.  I tried the latest
 > patch out this evening on a new build with OSX 10.6.8 -- master branch
 > -- and the tests I performed work well -- i.e., I have a
 > default-frame-alist that creates the perfect size initial and
 > subsequent frames to precise pixel specifications using courier font
 > size 18.

I now pushed everything to master.  It's been pretty difficult to fix
the various builds.  I found a number of bugs that earlier were swept
under the lines/columns carpets.

There is one major change: Instead of

(width . 200.0)

you have to use

(width . (text-pixels . 200))

to spefify that a frame should be 200 pixels wide.  Similarly for
height.  Please report any problems you find.

Thanks, martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Thank you both so very much for making feature request 21415 a reality and for fixing the various issues along the way.  I built Emacs this morning from the master branch for both OSX 10.6.8 and Windows XP -- i.e., through "6d6bf466477b004035a4314886e35214c6f8603b", which is subsequent in time to the commit by Martin earlier in the day.

Both of the builds (i.e., OSX and Windows XP) are working well with the tests that I performed using the `default-frame-alist` and the new `text-pixels` specifications for `width` and `height`.

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

Great to hear that things are working!

Just to send out a "ping" from my side. I've reworked quite a lot of the
NextStep maximization system, as well as replacing the NSTRACE package. I
have a few more hours of work (i.e. a couple of nights) before I have
something to show, I'll let you know when I'm done.

    -- Anders

On Tue, Oct 13, 2015 at 7:23 PM, Keith David Bershatsky <esq@lawlist.com>
wrote:

> Thank you both so very much for making feature request 21415 a reality and
> for fixing the various issues along the way.  I built Emacs this morning
> from the master branch for both OSX 10.6.8 and Windows XP -- i.e., through
> "6d6bf466477b004035a4314886e35214c6f8603b", which is subsequent in time to
> the commit by Martin earlier in the day.
>
> Both of the builds (i.e., OSX and Windows XP) are working well with the
> tests that I performed using the `default-frame-alist` and the new
> `text-pixels` specifications for `width` and `height`.
>
> Keith
>

[-- Attachment #2: Type: text/html, Size: 1403 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

 > Both of the builds (i.e., OSX and Windows XP) are working well with
 > the tests ...

Can you try the attached test suite?  Simply load the attached file and
do M-x frame-test.  The transcript can be found in a buffer called
*frame-test*.  Please do that for both installations.

martin

[-- Attachment #2: frame.test.el --]
[-- Type: application/emacs-lisp, Size: 31830 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

Attached are the test suite results for each 10/13/2015 build of Emacs -- OSX 10.6.8, and Windows XP.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Wed, 14 Oct 2015 10:49:37 +0200,
martin rudalics wrote:
> 
* * *
> Can you try the attached test suite?  Simply load the attached file and
> do M-x frame-test.  The transcript can be found in a buffer called
> *frame-test*.  Please do that for both installations.
> 
> martin
> [* frame.test.el]


[-- Attachment #2: frame_test_osx.txt --]
[-- Type: application/txt, Size: 4379 bytes --]

[-- Attachment #3: frame_test_windowsxp.txt --]
[-- Type: application/txt, Size: 4391 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Attached are the test suite results for each 10/13/2015 build of Emacs -- OSX 10.6.8, and Windows XP.

Thanks.  Apparently toggling the tool bar on OSX is still causing
problems.  Can you please, on OSX, do the following with emacs -Q:

(1) Toggle the tool bar off.  Does the overall frame height shrink or
     stay the same?

(2) Toggle the tool bar on again.  Does the overall frame height
     increase or stay the same?

(3) Evaluate (setq frame-inhibit-implied-resize t) and repeat steps (1)
     and (2).

Thanks, martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

Martin,

I've got a quick question. I noticed that the OS X port behaves a bit
inconsistent when it comes to restricting a frame to the screen --
sometimes it is restricted in height, sometimes it's not. I would like to
make this more consistent, but I'm not sure in which direction I should go.

How does the other terms (especially X11) behave? Does it restrict the
frame to be within the screen? If so, does it allow for the frame border to
be placed outside the screen?

What happens if the frame is first resized and then moved. Should the
resize truncate the height, even though the move would place the entire
frame inside the screen borders? Can a move and a resize be made atomically
(pixelwise)?

Personally, I'd prefer it there is no truncation. However, if it is, I
really would like to be able to allow the frame border to stretch outside
the screen, in order to really maximize the screen real estate.

/ Anders



On Wed, Oct 14, 2015 at 7:37 PM, martin rudalics <rudalics@gmx.at> wrote:

> > Attached are the test suite results for each 10/13/2015 build of Emacs
> -- OSX 10.6.8, and Windows XP.
>
> Thanks.  Apparently toggling the tool bar on OSX is still causing
> problems.  Can you please, on OSX, do the following with emacs -Q:
>
> (1) Toggle the tool bar off.  Does the overall frame height shrink or
>     stay the same?
>
> (2) Toggle the tool bar on again.  Does the overall frame height
>     increase or stay the same?
>
> (3) Evaluate (setq frame-inhibit-implied-resize t) and repeat steps (1)
>     and (2).
>
> Thanks, martin
>

[-- Attachment #2: Type: text/html, Size: 2095 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I've got a quick question. I noticed that the OS X port behaves a bit
 > inconsistent when it comes to restricting a frame to the screen --
 > sometimes it is restricted in height, sometimes it's not. I would like to
 > make this more consistent, but I'm not sure in which direction I should go.
 >
 > How does the other terms (especially X11) behave? Does it restrict the
 > frame to be within the screen? If so, does it allow for the frame border to
 > be placed outside the screen?

I suppose nobody can answer this question satisfactorily.  IMO good
"systems" allow the frame to be placed anywhere.  And I usually have
troubles only with window managers constraining placement.

 > What happens if the frame is first resized and then moved. Should the
 > resize truncate the height, even though the move would place the entire
 > frame inside the screen borders? Can a move and a resize be made atomically
 > (pixelwise)?

For Emacs moving means to pass on coordinates to whoever is responsible.
And Emacs itself never constrains the frame size (it must not get too
small, though).

 > Personally, I'd prefer it there is no truncation. However, if it is, I
 > really would like to be able to allow the frame border to stretch outside
 > the screen, in order to really maximize the screen real estate.

That's what most systems do AFAICT.  So if you can do that please go on.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1.1: Type: text/plain, Size: 3104 bytes --]

Ok, here comes a patch file for the "maximize" and "NSTRACE" rewrites, see
the file "emacs-commit-message.txt" for details. I would like you
(especially Keith, since Martin don't use OS X) to take a look at it before
I post in on emacs-devel and (unless people object) I commit it.

The rewrite became a bit larger than I originally expected since I realised
that the system to snap the frame size to the text grid was fundamentally
broken. It used a features called "SetResizeIncrements", where the
increments were set to the size of the current font. Unfortunately, once
the frame size got out of sync (e.g. by setting the frame size to a
specific pixel value) it remained out of sync. In addition, it interfered
with the maximization system.

The current implementation snaps the frame size to the text grid in a
callback function.

The patch below contains excluded code to maximize the frame the old way
using the system "zoom" function, and an excluded code section for a hybrid
maximize solution. Also, the code to restrict a frame to the screen height
is still present but excluded. Before I commit this to the archive I will
remove the excluded code, unless someone thinks that its worth while to
allow the user to configure this.

You can enable the NSTRACE system by uncommenting a line in nsterm.h, see
comments for detail.

In addition, I have included my own test file for frame maximization I
wrote to ensure that I didn't introduce any problems. Martin, if there are
anything in this you can use for your frame test file, feel free to use it.

Sincerely,
    Anders Lindgren


On Thu, Oct 15, 2015 at 12:00 PM, martin rudalics <rudalics@gmx.at> wrote:

> > I've got a quick question. I noticed that the OS X port behaves a bit
> > inconsistent when it comes to restricting a frame to the screen --
> > sometimes it is restricted in height, sometimes it's not. I would like to
> > make this more consistent, but I'm not sure in which direction I should
> go.
> >
> > How does the other terms (especially X11) behave? Does it restrict the
> > frame to be within the screen? If so, does it allow for the frame border
> to
> > be placed outside the screen?
>
> I suppose nobody can answer this question satisfactorily.  IMO good
> "systems" allow the frame to be placed anywhere.  And I usually have
> troubles only with window managers constraining placement.
>
> > What happens if the frame is first resized and then moved. Should the
> > resize truncate the height, even though the move would place the entire
> > frame inside the screen borders? Can a move and a resize be made
> atomically
> > (pixelwise)?
>
> For Emacs moving means to pass on coordinates to whoever is responsible.
> And Emacs itself never constrains the frame size (it must not get too
> small, though).
>
> > Personally, I'd prefer it there is no truncation. However, if it is, I
> > really would like to be able to allow the frame border to stretch outside
> > the screen, in order to really maximize the screen real estate.
>
> That's what most systems do AFAICT.  So if you can do that please go on.
>
> martin
>

[-- Attachment #1.2: Type: text/html, Size: 3908 bytes --]

[-- Attachment #2: maximize_and_trace.diff --]
[-- Type: text/plain, Size: 78576 bytes --]

diff --git a/src/nsfns.m b/src/nsfns.m
index 43002ca..1ed3e23 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -49,13 +49,6 @@ GNUstep port and post-20 update by Adrian Robert (arobert@cogsci.ucsd.edu)
 #include "macfont.h"
 #endif
 
-#if 0
-int fns_trace_num = 1;
-#define NSTRACE(x)        fprintf (stderr, "%s:%d: [%d] " #x "\n",        \
-                                  __FILE__, __LINE__, ++fns_trace_num)
-#else
-#define NSTRACE(x)
-#endif
 
 #ifdef HAVE_NS
 
@@ -364,7 +357,7 @@ static void
 x_set_icon_name (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
 {
   NSView *view = FRAME_NS_VIEW (f);
-  NSTRACE (x_set_icon_name);
+  NSTRACE ("x_set_icon_name");
 
   /* see if it's changed */
   if (STRINGP (arg))
@@ -436,7 +429,7 @@ ns_set_name_internal (struct frame *f, Lisp_Object name)
 static void
 ns_set_name (struct frame *f, Lisp_Object name, int explicit)
 {
-  NSTRACE (ns_set_name);
+  NSTRACE ("ns_set_name");
 
   /* Make sure that requests from lisp code override requests from
      Emacs redisplay code.  */
@@ -477,7 +470,7 @@ ns_set_name (struct frame *f, Lisp_Object name, int explicit)
 static void
 x_explicitly_set_name (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
 {
-  NSTRACE (x_explicitly_set_name);
+  NSTRACE ("x_explicitly_set_name");
   ns_set_name (f, arg, 1);
 }
 
@@ -488,7 +481,7 @@ x_explicitly_set_name (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
 void
 x_implicitly_set_name (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
 {
-  NSTRACE (x_implicitly_set_name);
+  NSTRACE ("x_implicitly_set_name");
 
   /* Deal with NS specific format t.  */
   if (FRAME_NS_P (f) && ((FRAME_ICONIFIED_P (f) && EQ (Vicon_title_format, Qt))
@@ -505,7 +498,7 @@ x_implicitly_set_name (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
 static void
 x_set_title (struct frame *f, Lisp_Object name, Lisp_Object old_name)
 {
-  NSTRACE (x_set_title);
+  NSTRACE ("x_set_title");
   /* Don't change the title if it's already NAME.  */
   if (EQ (name, f->title))
     return;
@@ -533,7 +526,7 @@ ns_set_name_as_filename (struct frame *f)
   NSAutoreleasePool *pool;
   Lisp_Object encoded_name, encoded_filename;
   NSString *str;
-  NSTRACE (ns_set_name_as_filename);
+  NSTRACE ("ns_set_name_as_filename");
 
   if (f->explicit_name || ! NILP (f->title))
     return;
@@ -729,7 +722,7 @@ ns_implicitly_set_icon_type (struct frame *f)
   NSAutoreleasePool *pool;
   BOOL setMini = YES;
 
-  NSTRACE (ns_implicitly_set_icon_type);
+  NSTRACE ("ns_implicitly_set_icon_type");
 
   block_input ();
   pool = [[NSAutoreleasePool alloc] init];
@@ -797,7 +790,7 @@ x_set_icon_type (struct frame *f, Lisp_Object arg, Lisp_Object oldval)
   id image = nil;
   BOOL setMini = YES;
 
-  NSTRACE (x_set_icon_type);
+  NSTRACE ("x_set_icon_type");
 
   if (!NILP (arg) && SYMBOLP (arg))
     {
diff --git a/src/nsimage.m b/src/nsimage.m
index 9eaeefe..e76a7db 100644
--- a/src/nsimage.m
+++ b/src/nsimage.m
@@ -35,14 +35,6 @@ GNUstep port and post-20 update by Adrian Robert (arobert@cogsci.ucsd.edu)
 #include "frame.h"
 #include "coding.h"
 
-/* call tracing */
-#if 0
-int image_trace_num = 0;
-#define NSTRACE(x)        fprintf (stderr, "%s:%d: [%d] " #x "\n",         \
-                                __FILE__, __LINE__, ++image_trace_num)
-#else
-#define NSTRACE(x)
-#endif
 
 
 /* ==========================================================================
@@ -57,7 +49,7 @@ void *
 ns_image_from_XBM (unsigned char *bits, int width, int height,
                    unsigned long fg, unsigned long bg)
 {
-  NSTRACE (ns_image_from_XBM);
+  NSTRACE ("ns_image_from_XBM");
   return [[EmacsImage alloc] initFromXBM: bits
                                    width: width height: height
                                       fg: fg bg: bg];
@@ -66,7 +58,7 @@ ns_image_from_XBM (unsigned char *bits, int width, int height,
 void *
 ns_image_for_XPM (int width, int height, int depth)
 {
-  NSTRACE (ns_image_for_XPM);
+  NSTRACE ("ns_image_for_XPM");
   return [[EmacsImage alloc] initForXPMWithDepth: depth
                                            width: width height: height];
 }
@@ -74,7 +66,7 @@ ns_image_for_XPM (int width, int height, int depth)
 void *
 ns_image_from_file (Lisp_Object file)
 {
-  NSTRACE (ns_image_from_bitmap_file);
+  NSTRACE ("ns_image_from_bitmap_file");
   return [EmacsImage allocInitFromFile: file];
 }
 
@@ -85,7 +77,7 @@ ns_load_image (struct frame *f, struct image *img,
   EmacsImage *eImg = nil;
   NSSize size;
 
-  NSTRACE (ns_load_image);
+  NSTRACE ("ns_load_image");
 
   if (STRINGP (spec_file))
     {
diff --git a/src/nsmenu.m b/src/nsmenu.m
index b5cb64d..2ef1223 100644
--- a/src/nsmenu.m
+++ b/src/nsmenu.m
@@ -45,13 +45,6 @@ Carbon version by Yamamoto Mitsuharu. */
 #include <sys/types.h>
 #endif
 
-#if 0
-int menu_trace_num = 0;
-#define NSTRACE(x)        fprintf (stderr, "%s:%d: [%d] " #x "\n",        \
-                                __FILE__, __LINE__, ++menu_trace_num)
-#else
-#define NSTRACE(x)
-#endif
 
 #if 0
 /* Include lisp -> C common menu parsing code */
@@ -121,7 +114,7 @@ ns_update_menubar (struct frame *f, bool deep_p, EmacsMenu *submenu)
   long t;
 #endif
 
-  NSTRACE (ns_update_menubar);
+  NSTRACE ("ns_update_menubar");
 
   if (f != SELECTED_FRAME ())
       return;
@@ -801,6 +794,8 @@ ns_menu_show (struct frame *f, int x, int y, int menuflags,
   widget_value *wv, *first_wv = 0;
   bool keymaps = (menuflags & MENU_KEYMAPS);
 
+  NSTRACE ("ns_menu_show");
+
   block_input ();
 
   p.x = x; p.y = y;
@@ -1423,7 +1418,7 @@ ns_popup_dialog (struct frame *f, Lisp_Object header, Lisp_Object contents)
   BOOL isQ;
   NSAutoreleasePool *pool;
 
-  NSTRACE (x-popup-dialog);
+  NSTRACE ("ns_popup_dialog");
 
   isQ = NILP (header);
 
diff --git a/src/nsterm.h b/src/nsterm.h
index c06b7c4..d7aebe0 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -61,6 +61,241 @@ typedef float EmacsCGFloat;
 
 /* ==========================================================================
 
+   Trace support
+
+   ========================================================================== */
+
+/* Uncomment the following line to enable trace. */
+
+/* #define NSTRACE_ENABLED 1 */
+
+
+/* Print a call tree containing all annotated functions.
+
+   The call structure of the functions is represented using
+   indentation and vertical lines. Extra information is printed using
+   horizontal lines that connect to the vertical line.
+
+   The return value is represented using the arrow "->>". For simple
+   functions, the arrow can be printed on the same line as the
+   function name. If more output is printed, it is connected to the
+   vertical line of the function.
+
+   The first column contains the file name, the second the line
+   number, and the third a number increasing for each trace line.
+
+   Note that the trace system, when enabled, use the GCC/Clang
+   "cleanup" extension.
+
+   For example (long lines manually split to reduce width):
+
+nsterm.m  : 1600: [ 4428]  ns_fullscreen_hook
+nsterm.m  : 7006: [ 4429]  | handleFS
+nsterm.m  : 7035: [ 4430]  | +--- FULLSCREEN_MAXIMIZED
+nsterm.m  : 7627: [ 4431]  | | performZoom
+nsterm.m  : 7636: [ 4432]  | | | zoom
+nsterm.m  :  874: [ 4433]  | | | | ns_update_auto_hide_menu_bar
+nsterm.m  : 6615: [ 4434]  | | | | [windowWillUseStandardFrame:
+                                       defaultFrame:(X:0 Y:0)/(W:1600 H:1177)]
+nsterm.m  :   99: [ 4435]  | | | | +--- fs_state: FULLSCREEN_NONE
+nsterm.m  :  119: [ 4436]  | | | | +--- fs_before_fs: -1
+nsterm.m  :  115: [ 4437]  | | | | +--- next_maximized: FULLSCREEN_MAXIMIZED
+nsterm.m  : 6619: [ 4438]  | | | | +--- ns_userRect: (X:0 Y:0)/(W:0 H:0)
+nsterm.m  : 6620: [ 4439]  | | | | +--- [sender frame]:
+                                                      (X:0 Y:626)/(W:595 H:551)
+nsterm.m  : 6644: [ 4440]  | | | | +--- ns_userRect (2):
+                                                      (X:0 Y:626)/(W:595 H:551)
+nsterm.m  : 6684: [ 4441]  | | | | +--- FULLSCREEN_MAXIMIZED
+nsterm.m  : 7057: [ 4442]  | | | | | setFSValue
+nsterm.m  :  115: [ 4443]  | | | | | +--- value: FULLSCREEN_MAXIMIZED
+nsterm.m  : 6711: [ 4444]  | | | | +--- Final ns_userRect:
+                                                      (X:0 Y:626)/(W:595 H:551)
+nsterm.m  : 6712: [ 4445]  | | | | +--- Final maximized_width: 1600
+nsterm.m  : 6713: [ 4446]  | | | | +--- Final maximized_height: 1177
+nsterm.m  :  119: [ 4447]  | | | | +--- Final next_maximized: -1
+nsterm.m  : 6209: [ 4448]  | | | | | windowWillResize: toSize: (W:1600 H:1177)
+nsterm.m  : 6210: [ 4449]  | | | | | +--- [sender frame]:
+                                                      (X:0 Y:626)/(W:595 H:551)
+nsterm.m  :  115: [ 4450]  | | | | | +--- fs_state: FULLSCREEN_MAXIMIZED
+nsterm.m  : 6274: [ 4451]  | | | | | +--- cols: 223  rows: 79
+nsterm.m  : 6299: [ 4452]  | | | | | +->> (W:1596 H:1167)
+nsterm.m  : 6718: [ 4453]  | | | | +->> (X:0 Y:0)/(W:1600 H:1177)
+
+   Here, "ns_fullscreen_hook" calls "handleFS", which is turn calls
+   "performZoom". This function calls "[super performZoom]", which
+   isn't annoted (so it doesn't show up in the trace). However, it
+   calls "zoom" which is annotated so it is part of the call
+   trace. Later, the method "windowWillUseStandardFrame" and the
+   function "setFSValue" are called. The lines with "+---" contain
+   extra information and lines containing "->>" represent return
+   values. */
+
+#ifndef NSTRACE_ENABLED
+#define NSTRACE_ENABLED 0
+#endif
+
+#if NSTRACE_ENABLED
+extern int nstrace_num;
+extern int nstrace_depth;
+
+void nstrace_leave(int *);
+
+/* printf-style trace output. Output is aligned with contained heading. */
+#define NSTRACE_MSG_NO_DASHES(...)                                          \
+  do                                                                        \
+    {                                                                       \
+      if (nstrace_enabled)                                                  \
+        {                                                                   \
+          fprintf (stderr, "%-10s:%5d: [%5d]%.*s",                          \
+                   __FILE__, __LINE__, ++nstrace_num,                       \
+                   2*nstrace_depth, "  | | | | | | | | | | | | | | | ..");  \
+          fprintf (stderr, __VA_ARGS__);                                    \
+          fprintf (stderr, "\n");                                           \
+        }                                                                   \
+    }                                                                       \
+  while(0)
+
+#define NSTRACE_MSG(...) NSTRACE_MSG_NO_DASHES("+--- " __VA_ARGS__)
+
+
+
+/* Macros for printing complex types.
+
+   NSTRACE_FMT_what     -- Printf format string for "what".
+   NSTRACE_ARG_what(x)  -- Printf argument for "what". */
+
+#define NSTRACE_FMT_SIZE        "(W:%.0f H:%.0f)"
+#define NSTRACE_ARG_SIZE(elt)   (elt).width, (elt).height
+
+#define NSTRACE_FMT_POINT       "(X:%.0f Y:%.0f)"
+#define NSTRACE_ARG_POINT(elt)  (elt).x, (elt).y
+
+#define NSTRACE_FMT_RECT        NSTRACE_FMT_POINT "/" NSTRACE_FMT_SIZE
+#define NSTRACE_ARG_RECT(elt)   \
+  NSTRACE_ARG_POINT((elt).origin), NSTRACE_ARG_SIZE((elt).size)
+
+
+/* Macros for printing complex types as extra information. */
+
+#define NSTRACE_SIZE(str,size)                                          \
+  NSTRACE_MSG (str ": " NSTRACE_FMT_SIZE,                               \
+               NSTRACE_ARG_SIZE (size));
+
+#define NSTRACE_POINT(str,point)                                        \
+  NSTRACE_MSG (str ": " NSTRACE_FMT_POINT,                              \
+               NSTRACE_ARG_POINT (point));
+
+#define NSTRACE_RECT(str,rect)                                          \
+  NSTRACE_MSG (str ": " NSTRACE_FMT_RECT,                               \
+               NSTRACE_ARG_RECT (rect));
+
+#define NSTRACE_FSTYPE(str,fs_type)                                     \
+  do                                                                    \
+    {                                                                   \
+      if (nstrace_enabled)                                              \
+        {                                                               \
+          ns_print_fullscreen_type_name(str, fs_type);                  \
+        }                                                               \
+    }                                                                   \
+  while(0)
+
+
+/* Return value macros.
+
+   NSTRACE_RETURN(fmt, ...) - Print a return value, support printf-style
+                              format string and arguments.
+
+   NSTRACE_RETURN_what(obj) - Print a return value of kind WHAT.
+
+   NSTRACE_FMT_RETURN - A string literal representing a returned
+                        value.  Useful when creating a format string
+                        to printf-like constructs like NSTRACE(). */
+
+#define NSTRACE_FMT_RETURN "->>"
+
+#define NSTRACE_RETURN(...) \
+  NSTRACE_MSG_NO_DASHES ("+" NSTRACE_FMT_RETURN " " __VA_ARGS__)
+
+#define NSTRACE_RETURN_SIZE(size) \
+  NSTRACE_RETURN(NSTRACE_FMT_SIZE, NSTRACE_ARG_SIZE(size))
+
+#define NSTRACE_RETURN_POINT(point) \
+  NSTRACE_RETURN(NSTRACE_FMT_POINT, NSTRACE_ARG_POINT(point))
+
+#define NSTRACE_RETURN_RECT(rect) \
+  NSTRACE_RETURN(NSTRACE_FMT_RECT, NSTRACE_ARG_RECT(rect))
+
+
+/* Function enter macros.
+
+   NSTRACE (fmt, ...) -- Enable trace output in curent block
+                         (typically a function). Accepts printf-style
+                         arguments.
+
+   NSTRACE_WHEN (cond, fmt, ...) -- Enable trace output when COND is true.
+
+   NSTRACE_UNLESS (cond, fmt, ...) -- Enable trace output unless COND is
+                                      true. */
+
+
+
+#define NSTRACE_WHEN(cond, ...)                                         \
+  __attribute__((cleanup(nstrace_leave)))                               \
+  int nstrace_enabled = (cond);                                         \
+  if (nstrace_enabled) { ++nstrace_depth; }                             \
+  NSTRACE_MSG_NO_DASHES(__VA_ARGS__);
+
+#endif /* NSTRACE_ENABLED */
+
+#define NSTRACE(...)              NSTRACE_WHEN(1, __VA_ARGS__)
+#define NSTRACE_UNLESS(cond, ...) NSTRACE_WHEN(!(cond), __VA_ARGS__)
+
+
+/* Non-trace replacement versions. */
+#ifndef NSTRACE_WHEN
+#define NSTRACE_WHEN(...)
+#endif
+
+#ifndef NSTRACE_MSG
+#define NSTRACE_MSG(...)
+#endif
+
+#ifndef NSTRACE_SIZE
+#define NSTRACE_SIZE(str,size)
+#endif
+
+#ifndef NSTRACE_POINT
+#define NSTRACE_POINT(str,point)
+#endif
+
+#ifndef NSTRACE_RECT
+#define NSTRACE_RECT(str,rect)
+#endif
+
+#ifndef NSTRACE_FSTYPE
+#define NSTRACE_FSTYPE(str,fs_type)
+#endif
+
+#ifndef NSTRACE_RETURN_SIZE
+#define NSTRACE_RETURN_SIZE(size)
+#endif
+
+#ifndef NSTRACE_RETURN_POINT
+#define NSTRACE_RETURN_POINT(point)
+#endif
+
+#ifndef NSTRACE_RETURN_RECT
+#define NSTRACE_RETURN_RECT(rect)
+#endif
+
+#ifndef NSTRACE_RETURN_FSTYPE
+#define NSTRACE_RETURN_FSTYPE(fs_type)
+#endif
+
+
+
+/* ==========================================================================
+
    NSColor, EmacsColor category.
 
    ========================================================================== */
@@ -174,6 +409,7 @@ typedef float EmacsCGFloat;
 #ifdef NS_IMPL_GNUSTEP
 - (void)windowDidMove: (id)sender;
 #endif
+- (int)fullscreenState;
 @end
 
 
diff --git a/src/nsterm.m b/src/nsterm.m
index c4bfd7c..774eaf7 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -68,38 +68,60 @@ GNUstep port and post-20 update by Adrian Robert (arobert@cogsci.ucsd.edu)
 #include "macfont.h"
 #endif
 
-/* call tracing */
-#if 0
-int term_trace_num = 0;
-#define NSTRACE(x)        fprintf (stderr, "%s:%d: [%d] " #x "\n",         \
-                                __FILE__, __LINE__, ++term_trace_num)
-#else
-#define NSTRACE(x)
-#endif
 
-/* Detailed tracing. "S" means "size" and "LL" stands for "lower left". */
-#if 0
-int term_trace_num = 0;
-#define NSTRACE_SIZE(str,size) fprintf (stderr,                         \
-                                   "%s:%d: [%d]   " str                 \
-                                   " (S:%.0f x %.0f)\n", \
-                                   __FILE__, __LINE__, ++term_trace_num,\
-                                   size.height,                       \
-                                   size.width)
-#define NSTRACE_RECT(s,r) fprintf (stderr,                              \
-                                   "%s:%d: [%d]   " s                   \
-                                   " (LL:%.0f x %.0f -> S:%.0f x %.0f)\n", \
-                                   __FILE__, __LINE__, ++term_trace_num,\
-                                   r.origin.x,                          \
-                                   r.origin.y,                          \
-                                   r.size.height,                       \
-                                   r.size.width)
-#else
-#define NSTRACE_SIZE(str,size)
-#define NSTRACE_RECT(s,r)
+extern NSString *NSMenuDidBeginTrackingNotification;
+
+
+#if NSTRACE_ENABLED
+int nstrace_num = 0;
+int nstrace_depth = 0;
+
+/* Called when nstrace_enabled goes out of scope. */
+void nstrace_leave(int * pointer_to_nstrace_enabled)
+{
+  if (*pointer_to_nstrace_enabled)
+    {
+      --nstrace_depth;
+    }
+}
+
+
+void ns_print_fullscreen_type_name (char const * s, int fs_type)
+{
+  // This is a support function for the NSTRACE system, don't add a
+  // NSTRACE () here. However, a local `nstrace_enabled' variable is
+  // needed by the NSTRACE_MSG macros.
+  int nstrace_enabled = 1;
+
+  switch (fs_type)
+    {
+    case FULLSCREEN_NONE:
+      NSTRACE_MSG ("%s: FULLSCREEN_NONE", s);
+      break;
+
+    case FULLSCREEN_WIDTH:
+      NSTRACE_MSG ("%s: FULLSCREEN_WIDTH", s);
+      break;
+
+    case FULLSCREEN_HEIGHT:
+      NSTRACE_MSG ("%s: FULLSCREEN_HEIGHT", s);
+      break;
+
+    case FULLSCREEN_BOTH:
+      NSTRACE_MSG ("%s: FULLSCREEN_BOTH", s);
+      break;
+
+    case FULLSCREEN_MAXIMIZED:
+      NSTRACE_MSG ("%s: FULLSCREEN_MAXIMIZED", s);
+      break;
+
+    default:
+      NSTRACE_MSG ("%s: %d", s, fs_type);
+      break;
+    }
+}
 #endif
 
-extern NSString *NSMenuDidBeginTrackingNotification;
 
 /* ==========================================================================
 
@@ -242,7 +264,7 @@ static struct frame *ns_updating_frame;
 static NSView *focus_view = NULL;
 static int ns_window_num = 0;
 #ifdef NS_IMPL_GNUSTEP
-static NSRect uRect;
+static NSRect uRect;            // TODO: This is dead, remove it?
 #endif
 static BOOL gsaved = NO;
 static BOOL ns_fake_keydown = NO;
@@ -622,6 +644,46 @@ ns_release_autorelease_pool (void *pool)
 }
 
 
+/* True, if the menu bar should be hidden.  */
+
+static BOOL
+ns_menu_bar_should_be_hidden (void)
+{
+  return !NILP (ns_auto_hide_menu_bar)
+    && [NSApp respondsToSelector:@selector(setPresentationOptions:)];
+}
+
+
+static CGFloat
+ns_menu_bar_height (NSScreen *screen)
+/* The height of the menu bar, if visible. */
+{
+  //  NSTRACE ("ns_menu_bar_height");
+
+  CGFloat res;
+
+  if (ns_menu_bar_should_be_hidden())
+    {
+      res = 0;
+    }
+  else
+    {
+      NSRect screenFrame = [screen frame];
+      NSRect screenVisibleFrame = [screen visibleFrame];
+
+      CGFloat frameTop = screenFrame.origin.y + screenFrame.size.height;
+      CGFloat visibleFrameTop = (screenVisibleFrame.origin.y
+                                 + screenVisibleFrame.size.height);
+
+      res = frameTop - visibleFrameTop;
+
+    }
+
+  // NSTRACE_MSG (NSTRACE_FMT_RETURN "%.0f", res);
+
+  return res;
+}
+
 
 /* ==========================================================================
 
@@ -671,44 +733,140 @@ ns_release_autorelease_pool (void *pool)
 //    Result: Menu bar visible, frame placed immediately below the menu.
 //
 
+static NSRect constrain_frame_rect(NSRect frameRect)
+{
+  NSTRACE ("constrain_frame_rect(" NSTRACE_FMT_RECT ")",
+             NSTRACE_ARG_RECT (frameRect));
+
+  // --------------------
+  // Collect information about the screen the frame is covering.
+  //
+
+  NSArray *screens = [NSScreen screens];
+  NSUInteger nr_screens = [screens count];
+
+  int i;
+
+  // The height of the menu bar, if present in any screen the frame is
+  // displayed in.
+  int menu_bar_height = 0;
+
+  // A rectangle covering all the screen the frame is displayed in.
+  NSRect multiscreenRect = NSMakeRect(0, 0, 0, 0);
+  for (i = 0; i < nr_screens; ++i )
+    {
+      NSScreen *s = [screens objectAtIndex: i];
+      NSRect scrRect = [s frame];
+
+      NSTRACE_MSG ("Screen %d: " NSTRACE_FMT_RECT,
+                   i, NSTRACE_ARG_RECT (scrRect));
+
+      if (NSIntersectionRect (frameRect, scrRect).size.height != 0)
+        {
+          multiscreenRect = NSUnionRect (multiscreenRect, scrRect);
+
+          menu_bar_height = max(menu_bar_height, ns_menu_bar_height (s));
+        }
+    }
+
+  NSTRACE_RECT ("multiscreenRect", multiscreenRect);
+
+  NSTRACE_MSG ("menu_bar_height: %d", menu_bar_height);
+
+  if (multiscreenRect.size.width == 0
+      || multiscreenRect.size.height == 0)
+    {
+      // Failed to find any monitor, give up.
+      NSTRACE_MSG ("multiscreenRect empty");
+      NSTRACE_RETURN_RECT (frameRect);
+      return frameRect;
+    }
+
+
+  // --------------------
+  // Find a suitable placement.
+  //
+
+  if (ns_menu_bar_should_be_hidden())
+    {
+      // When the menu bar is hidden, the user may place part of the
+      // frame above the top of the screen, for example to hide the
+      // title bar.
+      //
+      // Hence, keep the original position.
+    }
+  else
+    {
+      // Ensure that the frame is below the menu bar, or below the top
+      // of the screen.
+      //
+      // This assume that the menu bar is placed at the top in the
+      // rectangle that covers the monitors. (It doesn't have to be,
+      // but if it's not it's hard to do anything useful.)
+      CGFloat topOfWorkArea = (multiscreenRect.origin.y
+                               + multiscreenRect.size.height
+                               - menu_bar_height);
+
+      CGFloat topOfFrame = frameRect.origin.y + frameRect.size.height;
+      if (topOfFrame > topOfWorkArea)
+        {
+          frameRect.origin.y -= topOfFrame - topOfWorkArea;
+          NSTRACE_RECT ("After placement adjust", frameRect);
+        }
+    }
+
+  // Include the following section to restrict frame to the screens.
+  // (If so, update it to allow the frame to stretch down below the
+  // screen.)
+#if 0
+  // --------------------
+  // Ensure frame doesn't stretch below the screens.
+  //
+
+  CGFloat diff = multiscreenRect.origin.y - frameRect.origin.y;
+
+  if (diff > 0)
+    {
+      frameRect.origin.y = multiscreenRect.origin.y;
+      frameRect.size.height -= diff;
+    }
+#endif
+
+  NSTRACE_RETURN_RECT (frameRect);
+  return frameRect;
+}
+
+
 static void
 ns_constrain_all_frames (void)
 {
   Lisp_Object tail, frame;
 
+  NSTRACE ("ns_constrain_all_frames");
+
   FOR_EACH_FRAME (tail, frame)
     {
       struct frame *f = XFRAME (frame);
       if (FRAME_NS_P (f))
         {
           NSView *view = FRAME_NS_VIEW (f);
-          /* This no-op will trigger the default window placing
-           * constraint system. */
-          [[view window] setFrameOrigin:[[view window] frame].origin];
+
+          [[view window] setFrame:constrain_frame_rect([[view window] frame])
+                          display:NO];
         }
     }
 }
 
 
-/* True, if the menu bar should be hidden.  */
-
-static BOOL
-ns_menu_bar_should_be_hidden (void)
-{
-  return !NILP (ns_auto_hide_menu_bar)
-    && [NSApp respondsToSelector:@selector(setPresentationOptions:)];
-}
-
-
 /* Show or hide the menu bar, based on user setting.  */
 
 static void
 ns_update_auto_hide_menu_bar (void)
 {
 #ifdef NS_IMPL_COCOA
-  block_input ();
+  NSTRACE ("ns_update_auto_hide_menu_bar");
 
-  NSTRACE (ns_update_auto_hide_menu_bar);
+  block_input ();
 
   if (NSApp != nil && [NSApp isActive])
     {
@@ -749,7 +907,7 @@ ns_update_begin (struct frame *f)
    -------------------------------------------------------------------------- */
 {
   EmacsView *view = FRAME_NS_VIEW (f);
-  NSTRACE (ns_update_begin);
+  NSTRACE ("ns_update_begin");
 
   ns_update_auto_hide_menu_bar ();
 
@@ -806,7 +964,7 @@ ns_update_window_begin (struct window *w)
   struct frame *f = XFRAME (WINDOW_FRAME (w));
   Mouse_HLInfo *hlinfo = MOUSE_HL_INFO (f);
 
-  NSTRACE (ns_update_window_begin);
+  NSTRACE ("ns_update_window_begin");
   w->output_cursor = w->cursor;
 
   block_input ();
@@ -836,6 +994,8 @@ ns_update_window_end (struct window *w, bool cursor_on_p,
    external (RIF) call; for one window called before update_end
    -------------------------------------------------------------------------- */
 {
+  NSTRACE ("update_window_end");
+
   /* note: this fn is nearly identical in all terms */
   if (!w->pseudo_window_p)
     {
@@ -861,8 +1021,6 @@ ns_update_window_end (struct window *w, bool cursor_on_p,
      frame_up_to_date to redisplay the mouse highlight.  */
   if (mouse_face_overwritten_p)
     reset_mouse_highlight (MOUSE_HL_INFO (XFRAME (w->frame)));
-
-  NSTRACE (update_window_end);
 }
 
 
@@ -875,6 +1033,8 @@ ns_update_end (struct frame *f)
 {
   EmacsView *view = FRAME_NS_VIEW (f);
 
+  NSTRACE ("ns_update_end");
+
 /*   if (f == MOUSE_HL_INFO (f)->mouse_face_mouse_frame) */
   MOUSE_HL_INFO (f)->mouse_face_defer = 0;
 
@@ -885,7 +1045,6 @@ ns_update_end (struct frame *f)
 
   unblock_input ();
   ns_updating_frame = NULL;
-  NSTRACE (ns_update_end);
 }
 
 static void
@@ -899,7 +1058,7 @@ ns_focus (struct frame *f, NSRect *r, int n)
      the entire window.
    -------------------------------------------------------------------------- */
 {
-//  NSTRACE (ns_focus);
+//  NSTRACE ("ns_focus");
 /* static int c =0;
    fprintf (stderr, "focus: %d", c++);
    if (r) fprintf (stderr, " (%.0f, %.0f : %.0f x %.0f)", r->origin.x, r->origin.y, r->size.width, r->size.height);
@@ -943,7 +1102,7 @@ ns_unfocus (struct frame *f)
      Internal: Remove focus on given frame
    -------------------------------------------------------------------------- */
 {
-//  NSTRACE (ns_unfocus);
+//  NSTRACE ("ns_unfocus");
 
   if (gsaved)
     {
@@ -993,7 +1152,7 @@ ns_ring_bell (struct frame *f)
      "Beep" routine
    -------------------------------------------------------------------------- */
 {
-  NSTRACE (ns_ring_bell);
+  NSTRACE ("ns_ring_bell");
   if (visible_bell)
     {
       NSAutoreleasePool *pool;
@@ -1079,7 +1238,7 @@ ns_frame_raise_lower (struct frame *f, bool raise)
      External (hook)
    -------------------------------------------------------------------------- */
 {
-  NSTRACE (ns_frame_raise_lower);
+  NSTRACE ("ns_frame_raise_lower");
 
   if (raise)
     ns_raise_frame (f);
@@ -1097,7 +1256,7 @@ ns_frame_rehighlight (struct frame *frame)
   struct ns_display_info *dpyinfo = FRAME_DISPLAY_INFO (frame);
   struct frame *old_highlight = dpyinfo->x_highlight_frame;
 
-  NSTRACE (ns_frame_rehighlight);
+  NSTRACE ("ns_frame_rehighlight");
   if (dpyinfo->x_focus_frame)
     {
       dpyinfo->x_highlight_frame
@@ -1136,7 +1295,7 @@ x_make_frame_visible (struct frame *f)
      External: Show the window (X11 semantics)
    -------------------------------------------------------------------------- */
 {
-  NSTRACE (x_make_frame_visible);
+  NSTRACE ("x_make_frame_visible");
   /* XXX: at some points in past this was not needed, as the only place that
      called this (frame.c:Fraise_frame ()) also called raise_lower;
      if this ends up the case again, comment this out again. */
@@ -1170,7 +1329,7 @@ x_make_frame_invisible (struct frame *f)
    -------------------------------------------------------------------------- */
 {
   NSView *view;
-  NSTRACE (x_make_frame_invisible);
+  NSTRACE ("x_make_frame_invisible");
   check_window_system (f);
   view = FRAME_NS_VIEW (f);
   [[view window] orderOut: NSApp];
@@ -1188,7 +1347,7 @@ x_iconify_frame (struct frame *f)
   NSView *view;
   struct ns_display_info *dpyinfo;
 
-  NSTRACE (x_iconify_frame);
+  NSTRACE ("x_iconify_frame");
   check_window_system (f);
   view = FRAME_NS_VIEW (f);
   dpyinfo = FRAME_DISPLAY_INFO (f);
@@ -1220,7 +1379,7 @@ x_free_frame_resources (struct frame *f)
   struct ns_display_info *dpyinfo;
   Mouse_HLInfo *hlinfo;
 
-  NSTRACE (x_free_frame_resources);
+  NSTRACE ("x_free_frame_resources");
   check_window_system (f);
   view = FRAME_NS_VIEW (f);
   dpyinfo = FRAME_DISPLAY_INFO (f);
@@ -1257,7 +1416,7 @@ x_destroy_window (struct frame *f)
      External: Delete the window
    -------------------------------------------------------------------------- */
 {
-  NSTRACE (x_destroy_window);
+  NSTRACE ("x_destroy_window");
   check_window_system (f);
   x_free_frame_resources (f);
   ns_window_num--;
@@ -1275,7 +1434,7 @@ x_set_offset (struct frame *f, int xoff, int yoff, int change_grav)
   NSScreen *fscreen = [screens objectAtIndex: 0];
   NSScreen *screen = [[view window] screen];
 
-  NSTRACE (x_set_offset);
+  NSTRACE ("x_set_offset");
 
   block_input ();
 
@@ -1301,10 +1460,11 @@ x_set_offset (struct frame *f, int xoff, int yoff, int change_grav)
 #endif
       /* Constrain the setFrameTopLeftPoint so we don't move behind the
          menu bar.  */
-      [[view window] setFrameTopLeftPoint:
-                       NSMakePoint (SCREENMAXBOUND (f->left_pos),
-                                    SCREENMAXBOUND ([fscreen frame].size.height
-                                                    - NS_TOP_POS (f)))];
+      NSPoint pt = NSMakePoint (SCREENMAXBOUND (f->left_pos),
+                                SCREENMAXBOUND ([fscreen frame].size.height
+                                                - NS_TOP_POS (f)));
+      NSTRACE_POINT ("setFrameTopLeftPoint", pt);
+      [[view window] setFrameTopLeftPoint: pt];
       f->size_hint_flags &= ~(XNegative|YNegative);
     }
 
@@ -1332,11 +1492,13 @@ x_set_window_size (struct frame *f,
   int rows, cols;
   int orig_height = wr.size.height;
 
-  NSTRACE (x_set_window_size);
+  NSTRACE ("x_set_window_size");
 
   if (view == nil)
     return;
 
+  NSTRACE_RECT ("input", wr);
+
 /*fprintf (stderr, "\tsetWindowSize: %d x %d, pixelwise %d, font size %d x %d\n", width, height, pixelwise, FRAME_COLUMN_WIDTH (f), FRAME_LINE_HEIGHT (f));*/
 
   block_input ();
@@ -1398,6 +1560,7 @@ x_set_window_size (struct frame *f,
 	   make_number (FRAME_TOOLBAR_HEIGHT (f))));
 
   [view setRows: rows andColumns: cols];
+  NSTRACE_RECT ("setFrame", wr);
   [window setFrame: wr display: YES];
 
   /* This is a trick to compensate for Emacs' managing the scrollbar area
@@ -1412,6 +1575,7 @@ x_set_window_size (struct frame *f,
       ? NSMakePoint (FRAME_SCROLL_BAR_COLS (f) * FRAME_COLUMN_WIDTH (f)
                      - NS_SCROLL_BAR_WIDTH (f), 0)
       : NSMakePoint (0, 0);
+    NSTRACE_RECT ("setFrame", wr);
     [view setFrame: NSMakeRect (0, 0, pixelwidth, pixelheight)];
     [view setBoundsOrigin: origin];
   }
@@ -1426,6 +1590,8 @@ ns_fullscreen_hook (struct frame *f)
 {
   EmacsView *view = (EmacsView *)FRAME_NS_VIEW (f);
 
+  NSTRACE ("ns_fullscreen_hook");
+
   if (!FRAME_VISIBLE_P (f))
     return;
 
@@ -1672,7 +1838,7 @@ ns_lisp_to_color (Lisp_Object color, NSColor **col)
      Convert a Lisp string object to a NS color
    -------------------------------------------------------------------------- */
 {
-  NSTRACE (ns_lisp_to_color);
+  NSTRACE ("ns_lisp_to_color");
   if (STRINGP (color))
     return ns_get_color (SSDATA (color), col);
   else if (SYMBOLP (color))
@@ -1690,7 +1856,7 @@ ns_color_to_lisp (NSColor *col)
   EmacsCGFloat red, green, blue, alpha, gray;
   char buf[1024];
   const char *str;
-  NSTRACE (ns_color_to_lisp);
+  NSTRACE ("ns_color_to_lisp");
 
   block_input ();
   if ([[col colorSpaceName] isEqualToString: NSNamedColorSpace])
@@ -1758,7 +1924,7 @@ ns_defined_color (struct frame *f,
    -------------------------------------------------------------------------- */
 {
   NSColor *col;
-  NSTRACE (ns_defined_color);
+  NSTRACE ("ns_defined_color");
 
   block_input ();
   if (ns_get_color (name, &col) != 0) /* Color not found  */
@@ -1823,7 +1989,7 @@ frame_set_mouse_pixel_position (struct frame *f, int pix_x, int pix_y)
      Programmatically reposition mouse pointer in pixel coordinates
    -------------------------------------------------------------------------- */
 {
-  NSTRACE (frame_set_mouse_pixel_position);
+  NSTRACE ("frame_set_mouse_pixel_position");
   ns_raise_frame (f);
 #if 0
   /* FIXME: this does not work, and what about GNUstep? */
@@ -1846,7 +2012,7 @@ note_mouse_movement (struct frame *frame, CGFloat x, CGFloat y)
   struct ns_display_info *dpyinfo = FRAME_DISPLAY_INFO (frame);
   NSRect *r;
 
-//  NSTRACE (note_mouse_movement);
+//  NSTRACE ("note_mouse_movement");
 
   dpyinfo->last_mouse_motion_frame = frame;
   r = &dpyinfo->last_mouse_glyph;
@@ -1887,7 +2053,7 @@ ns_mouse_position (struct frame **fp, int insist, Lisp_Object *bar_window,
   struct frame *f;
   struct ns_display_info *dpyinfo;
 
-  NSTRACE (ns_mouse_position);
+  NSTRACE ("ns_mouse_position");
 
   if (*fp == NULL)
     {
@@ -1943,7 +2109,7 @@ ns_frame_up_to_date (struct frame *f)
     Can't use FRAME_MOUSE_UPDATE due to ns_frame_begin and ns_frame_end calls.
    -------------------------------------------------------------------------- */
 {
-  NSTRACE (ns_frame_up_to_date);
+  NSTRACE ("ns_frame_up_to_date");
 
   if (FRAME_NS_P (f))
     {
@@ -1968,7 +2134,7 @@ ns_define_frame_cursor (struct frame *f, Cursor cursor)
     External (RIF): set frame mouse pointer type.
    -------------------------------------------------------------------------- */
 {
-  NSTRACE (ns_define_frame_cursor);
+  NSTRACE ("ns_define_frame_cursor");
   if (FRAME_POINTER_TYPE (f) != cursor)
     {
       EmacsView *view = FRAME_NS_VIEW (f);
@@ -2015,7 +2181,7 @@ x_get_keysym_name (int keysym)
    -------------------------------------------------------------------------- */
 {
   static char value[16];
-  NSTRACE (x_get_keysym_name);
+  NSTRACE ("x_get_keysym_name");
   sprintf (value, "%d", keysym);
   return value;
 }
@@ -2035,7 +2201,7 @@ ns_redraw_scroll_bars (struct frame *f)
   int i;
   id view;
   NSArray *subviews = [[FRAME_NS_VIEW (f) superview] subviews];
-  NSTRACE (ns_redraw_scroll_bars);
+  NSTRACE ("ns_redraw_scroll_bars");
   for (i =[subviews count]-1; i >= 0; i--)
     {
       view = [subviews objectAtIndex: i];
@@ -2054,7 +2220,7 @@ ns_clear_frame (struct frame *f)
   NSView *view = FRAME_NS_VIEW (f);
   NSRect r;
 
-  NSTRACE (ns_clear_frame);
+  NSTRACE ("ns_clear_frame");
 
  /* comes on initial frame because we have
     after-make-frame-functions = select-frame */
@@ -2090,7 +2256,7 @@ ns_clear_frame_area (struct frame *f, int x, int y, int width, int height)
   if (!view || !face)
     return;
 
-  NSTRACE (ns_clear_frame_area);
+  NSTRACE ("ns_clear_frame_area");
 
   r = NSIntersectionRect (r, [view frame]);
   ns_focus (f, &r, 1);
@@ -2124,7 +2290,7 @@ ns_scroll_run (struct window *w, struct run *run)
   struct frame *f = XFRAME (w->frame);
   int x, y, width, height, from_y, to_y, bottom_y;
 
-  NSTRACE (ns_scroll_run);
+  NSTRACE ("ns_scroll_run");
 
   /* begin copy from other terms */
   /* Get frame-relative bounding box of the text display area of W,
@@ -2183,7 +2349,7 @@ ns_after_update_window_line (struct window *w, struct glyph_row *desired_row)
   struct frame *f;
   int width, height;
 
-  NSTRACE (ns_after_update_window_line);
+  NSTRACE ("ns_after_update_window_line");
 
   /* begin copy from other terms */
   eassert (w);
@@ -2224,7 +2390,7 @@ ns_shift_glyphs_for_insert (struct frame *f,
   NSRect srcRect = NSMakeRect (x, y, width, height);
   NSRect dstRect = NSMakeRect (x+shift_by, y, width, height);
 
-  NSTRACE (ns_shift_glyphs_for_insert);
+  NSTRACE ("ns_shift_glyphs_for_insert");
 
   ns_copy_bits (f, srcRect, dstRect);
 }
@@ -2394,7 +2560,7 @@ ns_draw_window_cursor (struct window *w, struct glyph_row *glyph_row,
      in mini-buffer windows when switching between echo area glyphs
      and mini-buffer.  */
 
-  NSTRACE (dumpcursor);
+  NSTRACE ("dumpcursor");
 
   if (!on_p)
     return;
@@ -2523,7 +2689,7 @@ ns_draw_vertical_window_border (struct window *w, int x, int y0, int y1)
   struct face *face;
   NSRect r = NSMakeRect (x, y0, 1, y1-y0);
 
-  NSTRACE (ns_draw_vertical_window_border);
+  NSTRACE ("ns_draw_vertical_window_border");
 
   face = FACE_FROM_ID (f, VERTICAL_BORDER_FACE_ID);
   if (face)
@@ -2545,7 +2711,7 @@ ns_draw_window_divider (struct window *w, int x0, int x1, int y0, int y1)
   struct face *face;
   NSRect r = NSMakeRect (x0, y0, x1-x0, y1-y0);
 
-  NSTRACE (ns_draw_window_divider);
+  NSTRACE ("ns_draw_window_divider");
 
   face = FACE_FROM_ID (f, WINDOW_DIVIDER_FACE_ID);
   if (face)
@@ -2802,7 +2968,7 @@ ns_draw_relief (NSRect r, int thickness, char raised_p,
   NSColor *newBaseCol = nil;
   NSRect sr = r;
 
-  NSTRACE (ns_draw_relief);
+  NSTRACE ("ns_draw_relief");
 
   /* set up colors */
 
@@ -2889,7 +3055,7 @@ ns_dumpglyphs_box_or_relief (struct glyph_string *s)
 
   thickness = face->box_line_width;
 
-  NSTRACE (ns_dumpglyphs_box_or_relief);
+  NSTRACE ("ns_dumpglyphs_box_or_relief");
 
   last_x = ((s->row->full_width_p && !s->w->pseudo_window_p)
 	    ? WINDOW_RIGHT_EDGE_X (s->w)
@@ -2931,7 +3097,7 @@ ns_maybe_dumpglyphs_background (struct glyph_string *s, char force_p)
       certain cases.  Others are left to the text rendering routine.
    -------------------------------------------------------------------------- */
 {
-  NSTRACE (ns_maybe_dumpglyphs_background);
+  NSTRACE ("ns_maybe_dumpglyphs_background");
 
   if (!s->background_filled_p/* || s->hl == DRAW_MOUSE_FACE*/)
     {
@@ -2994,7 +3160,7 @@ ns_dumpglyphs_image (struct glyph_string *s, NSRect r)
   struct face *face;
   NSColor *tdCol;
 
-  NSTRACE (ns_dumpglyphs_image);
+  NSTRACE ("ns_dumpglyphs_image");
 
   if (s->face->box != FACE_NO_BOX
       && s->first_glyph->left_box_line_p && s->slice.x == 0)
@@ -3311,7 +3477,7 @@ ns_draw_glyph_string (struct glyph_string *s)
   struct font *font = s->face->font;
   if (! font) font = FRAME_FONT (s->f);
 
-  NSTRACE (ns_draw_glyph_string);
+  NSTRACE ("ns_draw_glyph_string");
 
   if (s->next && s->right_overhang && !s->for_overlaps/*&&s->hl!=DRAW_CURSOR*/)
     {
@@ -3469,7 +3635,7 @@ ns_send_appdefined (int value)
               recognize and take as a command to halt the event loop.
    -------------------------------------------------------------------------- */
 {
-  /*NSTRACE (ns_send_appdefined); */
+  /*NSTRACE ("ns_send_appdefined"); */
 
 #ifdef NS_IMPL_GNUSTEP
   // GNUstep needs postEvent to happen on the main thread.
@@ -3643,7 +3809,7 @@ ns_read_socket (struct terminal *terminal, struct input_event *hold_quit)
   struct input_event ev;
   int nevents;
 
-/* NSTRACE (ns_read_socket); */
+/* NSTRACE ("ns_read_socket"); */
 
 #ifdef HAVE_NATIVE_FS
   check_native_fs ();
@@ -3727,7 +3893,7 @@ ns_select (int nfds, fd_set *readfds, fd_set *writefds,
   struct input_event event;
   char c;
 
-/*  NSTRACE (ns_select); */
+/*  NSTRACE ("ns_select"); */
 
 #ifdef HAVE_NATIVE_FS
   check_native_fs ();
@@ -3903,7 +4069,7 @@ ns_set_vertical_scroll_bar (struct window *window,
         }
     }
 
-  NSTRACE (ns_set_vertical_scroll_bar);
+  NSTRACE ("ns_set_vertical_scroll_bar");
 
   /* Get dimensions.  */
   window_box (window, ANY_AREA, 0, &window_y, 0, &window_height);
@@ -3997,7 +4163,7 @@ ns_set_horizontal_scroll_bar (struct window *window,
         }
     }
 
-  NSTRACE (ns_set_horizontal_scroll_bar);
+  NSTRACE ("ns_set_horizontal_scroll_bar");
 
   /* Get dimensions.  */
   window_box (window, ANY_AREA, 0, &window_x, &window_width, 0);
@@ -4069,7 +4235,7 @@ ns_condemn_scroll_bars (struct frame *f)
   id view;
   NSArray *subviews = [[FRAME_NS_VIEW (f) superview] subviews];
 
-  NSTRACE (ns_condemn_scroll_bars);
+  NSTRACE ("ns_condemn_scroll_bars");
 
   for (i =[subviews count]-1; i >= 0; i--)
     {
@@ -4088,7 +4254,7 @@ ns_redeem_scroll_bar (struct window *window)
    -------------------------------------------------------------------------- */
 {
   id bar;
-  NSTRACE (ns_redeem_scroll_bar);
+  NSTRACE ("ns_redeem_scroll_bar");
   if (!NILP (window->vertical_scroll_bar))
     {
       bar = XNS_SCROLL_BAR (window->vertical_scroll_bar);
@@ -4116,7 +4282,7 @@ ns_judge_scroll_bars (struct frame *f)
   NSArray *subviews = [[eview superview] subviews];
   BOOL removed = NO;
 
-  NSTRACE (ns_judge_scroll_bars);
+  NSTRACE ("ns_judge_scroll_bars");
   for (i = [subviews count]-1; i >= 0; --i)
     {
       view = [subviews objectAtIndex: i];
@@ -4294,6 +4460,8 @@ ns_delete_terminal (struct terminal *terminal)
 {
   struct ns_display_info *dpyinfo = terminal->display_info.ns;
 
+  NSTRACE ("ns_delete_terminal");
+
   /* Protect against recursive calls.  delete_frame in
      delete_terminal calls us back when it deletes our last frame.  */
   if (!terminal->name)
@@ -4315,7 +4483,7 @@ ns_create_terminal (struct ns_display_info *dpyinfo)
 {
   struct terminal *terminal;
 
-  NSTRACE (ns_create_terminal);
+  NSTRACE ("ns_create_terminal");
 
   terminal = create_terminal (output_ns, &ns_redisplay_interface);
 
@@ -4361,7 +4529,7 @@ ns_term_init (Lisp_Object display_name)
   if (ns_initialized) return x_display_list;
   ns_initialized = 1;
 
-  NSTRACE (ns_term_init);
+  NSTRACE ("ns_term_init");
 
   [outerpool release];
   outerpool = [[NSAutoreleasePool alloc] init];
@@ -4443,6 +4611,8 @@ ns_term_init (Lisp_Object display_name)
       ns_antialias_threshold = NILP (tmp) ? 10.0 : XFLOATINT (tmp);
     }
 
+  NSTRACE_MSG ("Colors");
+
   {
     NSColorList *cl = [NSColorList colorListNamed: @"Emacs"];
 
@@ -4476,6 +4646,8 @@ ns_term_init (Lisp_Object display_name)
       }
   }
 
+  NSTRACE_MSG ("Versions");
+
   {
 #ifdef NS_IMPL_GNUSTEP
     Vwindow_system_version = build_string (gnustep_base_version);
@@ -4491,7 +4663,10 @@ ns_term_init (Lisp_Object display_name)
 
   ns_app_name = [[NSProcessInfo processInfo] processName];
 
-/* Set up OS X app menu */
+  /* Set up OS X app menu */
+
+  NSTRACE_MSG ("Menu init");
+
 #ifdef NS_IMPL_COCOA
   {
     NSMenu *appMenu;
@@ -4564,6 +4739,9 @@ ns_term_init (Lisp_Object display_name)
 
   /* Register our external input/output types, used for determining
      applicable services and also drag/drop eligibility. */
+
+  NSTRACE_MSG ("Input/output types");
+
   ns_send_types = [[NSArray arrayWithObjects: NSStringPboardType, nil] retain];
   ns_return_types = [[NSArray arrayWithObjects: NSStringPboardType, nil]
                       retain];
@@ -4577,6 +4755,8 @@ ns_term_init (Lisp_Object display_name)
      right for fullscreen windows, so set this.  */
   [NSApp activateIgnoringOtherApps:YES];
 
+  NSTRACE_MSG ("Call NSApp run");
+
   [NSApp run];
   ns_do_open_file = YES;
 
@@ -4585,6 +4765,9 @@ ns_term_init (Lisp_Object display_name)
      We must re-catch it so subprocess works.  */
   catch_child_signal ();
 #endif
+
+  NSTRACE_MSG ("ns_term_init done");
+
   return dpyinfo;
 }
 
@@ -4697,7 +4880,7 @@ ns_term_shutdown (int sig)
   int type = [theEvent type];
   NSWindow *window = [theEvent window];
 
-/*  NSTRACE (sendEvent); */
+/*  NSTRACE ("sendEvent"); */
 /*fprintf (stderr, "received event of type %d\t%d\n", type);*/
 
 #ifdef NS_IMPL_GNUSTEP
@@ -4847,7 +5030,7 @@ ns_term_shutdown (int sig)
      When application is loaded, terminate event loop in ns_term_init
    -------------------------------------------------------------------------- */
 {
-  NSTRACE (applicationDidFinishLaunching);
+  NSTRACE ("applicationDidFinishLaunching");
 #ifdef NS_IMPL_GNUSTEP
   ((EmacsApp *)self)->applicationDidFinishLaunchingCalled = YES;
 #endif
@@ -5015,7 +5198,7 @@ not_in_argv (NSString *arg)
 }
 - (void)applicationDidBecomeActive: (NSNotification *)notification
 {
-  NSTRACE (applicationDidBecomeActive);
+  NSTRACE ("applicationDidBecomeActive");
 
 #ifdef NS_IMPL_GNUSTEP
   if (! applicationDidFinishLaunchingCalled)
@@ -5047,7 +5230,7 @@ not_in_argv (NSString *arg)
      The timeout specified to ns_select has passed.
    -------------------------------------------------------------------------- */
 {
-  /*NSTRACE (timeout_handler); */
+  /*NSTRACE ("timeout_handler"); */
   ns_send_appdefined (-2);
 }
 
@@ -5071,7 +5254,7 @@ not_in_argv (NSString *arg)
   struct timespec timeout, *tmo;
   NSAutoreleasePool *pool = nil;
 
-  /* NSTRACE (fd_handler); */
+  /* NSTRACE ("fd_handler"); */
 
   for (;;)
     {
@@ -5208,7 +5391,7 @@ not_in_argv (NSString *arg)
 
 - (void)dealloc
 {
-  NSTRACE (EmacsView_dealloc);
+  NSTRACE ("EmacsView_dealloc");
   [toolbar release];
   if (fs_state == FULLSCREEN_BOTH)
     [nonfs_window release];
@@ -5226,7 +5409,7 @@ not_in_argv (NSString *arg)
   CGFloat size;
   NSFont *nsfont;
 
-  NSTRACE (changeFont);
+  NSTRACE ("changeFont");
 
   if (!emacs_event)
     return;
@@ -5256,7 +5439,7 @@ not_in_argv (NSString *arg)
 
 - (BOOL)acceptsFirstResponder
 {
-  NSTRACE (acceptsFirstResponder);
+  NSTRACE ("acceptsFirstResponder");
   return YES;
 }
 
@@ -5265,7 +5448,7 @@ not_in_argv (NSString *arg)
 {
   NSRect visible = [self visibleRect];
   NSCursor *currentCursor = FRAME_POINTER_TYPE (emacsframe);
-  NSTRACE (resetCursorRects);
+  NSTRACE ("resetCursorRects");
 
   if (currentCursor == nil)
     currentCursor = [NSCursor arrowCursor];
@@ -5290,7 +5473,7 @@ not_in_argv (NSString *arg)
   int left_is_none;
   unsigned int flags = [theEvent modifierFlags];
 
-  NSTRACE (keyDown);
+  NSTRACE ("keyDown");
 
   /* Rhapsody and OS X give up and down events for the arrow keys */
   if (ns_fake_keydown == YES)
@@ -5753,7 +5936,7 @@ not_in_argv (NSString *arg)
   struct ns_display_info *dpyinfo = FRAME_DISPLAY_INFO (emacsframe);
   NSPoint p = [self convertPoint: [theEvent locationInWindow] fromView: nil];
 
-  NSTRACE (mouseDown);
+  NSTRACE ("mouseDown");
 
   [self deleteWorkingText];
 
@@ -5774,7 +5957,7 @@ not_in_argv (NSString *arg)
           delta = [theEvent deltaX];
           if (delta == 0)
             {
-              NSTRACE (deltaIsZero);
+              NSTRACE ("deltaIsZero");
               return;
             }
           emacs_event->kind = HORIZ_WHEEL_EVENT;
@@ -5801,42 +5984,42 @@ not_in_argv (NSString *arg)
 
 - (void)rightMouseDown: (NSEvent *)theEvent
 {
-  NSTRACE (rightMouseDown);
+  NSTRACE ("rightMouseDown");
   [self mouseDown: theEvent];
 }
 
 
 - (void)otherMouseDown: (NSEvent *)theEvent
 {
-  NSTRACE (otherMouseDown);
+  NSTRACE ("otherMouseDown");
   [self mouseDown: theEvent];
 }
 
 
 - (void)mouseUp: (NSEvent *)theEvent
 {
-  NSTRACE (mouseUp);
+  NSTRACE ("mouseUp");
   [self mouseDown: theEvent];
 }
 
 
 - (void)rightMouseUp: (NSEvent *)theEvent
 {
-  NSTRACE (rightMouseUp);
+  NSTRACE ("rightMouseUp");
   [self mouseDown: theEvent];
 }
 
 
 - (void)otherMouseUp: (NSEvent *)theEvent
 {
-  NSTRACE (otherMouseUp);
+  NSTRACE ("otherMouseUp");
   [self mouseDown: theEvent];
 }
 
 
 - (void) scrollWheel: (NSEvent *)theEvent
 {
-  NSTRACE (scrollWheel);
+  NSTRACE ("scrollWheel");
   [self mouseDown: theEvent];
 }
 
@@ -5849,7 +6032,7 @@ not_in_argv (NSString *arg)
   Lisp_Object frame;
   NSPoint pt;
 
-//  NSTRACE (mouseMoved);
+//  NSTRACE ("mouseMoved");
 
   dpyinfo->last_mouse_movement_time = EV_TIMESTAMP (e);
   pt = [self convertPoint: [e locationInWindow] fromView: nil];
@@ -5869,7 +6052,7 @@ not_in_argv (NSString *arg)
 
   if (!NILP (Vmouse_autoselect_window))
     {
-      NSTRACE (mouse_autoselect_window);
+      NSTRACE ("mouse_autoselect_window");
       static Lisp_Object last_mouse_window;
       Lisp_Object window
 	= window_from_coordinates (emacsframe, pt.x, pt.y, 0, 0);
@@ -5881,7 +6064,7 @@ not_in_argv (NSString *arg)
               || (EQ (XWINDOW (window)->frame,
                       XWINDOW (selected_window)->frame))))
         {
-          NSTRACE (in_window);
+          NSTRACE ("in_window");
           emacs_event->kind = SELECT_WINDOW_EVENT;
           emacs_event->frame_or_window = window;
           EV_TRAILER2 (e);
@@ -5911,21 +6094,21 @@ not_in_argv (NSString *arg)
 
 - (void)mouseDragged: (NSEvent *)e
 {
-  NSTRACE (mouseDragged);
+  NSTRACE ("mouseDragged");
   [self mouseMoved: e];
 }
 
 
 - (void)rightMouseDragged: (NSEvent *)e
 {
-  NSTRACE (rightMouseDragged);
+  NSTRACE ("rightMouseDragged");
   [self mouseMoved: e];
 }
 
 
 - (void)otherMouseDragged: (NSEvent *)e
 {
-  NSTRACE (otherMouseDragged);
+  NSTRACE ("otherMouseDragged");
   [self mouseMoved: e];
 }
 
@@ -5934,7 +6117,7 @@ not_in_argv (NSString *arg)
 {
   NSEvent *e =[[self window] currentEvent];
 
-  NSTRACE (windowShouldClose);
+  NSTRACE ("windowShouldClose");
   windowClosing = YES;
   if (!emacs_event)
     return NO;
@@ -5956,8 +6139,9 @@ not_in_argv (NSString *arg)
   int oldh = FRAME_PIXEL_HEIGHT (emacsframe);
   int neww, newh;
 
-  NSTRACE (updateFrameSize);
+  NSTRACE ("updateFrameSize");
   NSTRACE_SIZE ("Original size", NSMakeSize (oldw, oldh));
+  NSTRACE_RECT ("Original frame", wr);
 
   if (! [self isFullscreen])
     {
@@ -5994,7 +6178,6 @@ not_in_argv (NSString *arg)
     {
       NSView *view = FRAME_NS_VIEW (emacsframe);
       NSWindow *win = [view window];
-      NSSize sz = [win resizeIncrements];
 
       change_frame_size (emacsframe,
                          FRAME_PIXEL_TO_TEXT_WIDTH (emacsframe, neww),
@@ -6003,21 +6186,9 @@ not_in_argv (NSString *arg)
       SET_FRAME_GARBAGED (emacsframe);
       cancel_mouse_face (emacsframe);
 
-      // Did resize increments change because of a font change?
-      if (sz.width != FRAME_COLUMN_WIDTH (emacsframe) ||
-          sz.height != FRAME_LINE_HEIGHT (emacsframe) ||
-          (frame_resize_pixelwise && sz.width != 1))
-        {
-          sz.width = frame_resize_pixelwise
-            ? 1 : FRAME_COLUMN_WIDTH (emacsframe);
-          sz.height = frame_resize_pixelwise
-            ? 1 : FRAME_LINE_HEIGHT (emacsframe);
-          [win setResizeIncrements: sz];
-
-          NSTRACE_SIZE ("New size", NSMakeSize (neww, newh));
-        }
-
-      [view setFrame: NSMakeRect (0, 0, neww, newh)];
+      wr = NSMakeRect (0, 0, neww, newh);
+      NSTRACE_RECT ("setFrame", wr);
+      [view setFrame: wr];
       [self windowDidMove:nil];   // Update top/left.
     }
 }
@@ -6027,9 +6198,10 @@ not_in_argv (NSString *arg)
 {
   int extra = 0;
 
-  NSTRACE (windowWillResize);
-  NSTRACE_SIZE ("Original size", frameSize);
-/*fprintf (stderr,"Window will resize: %.0f x %.0f\n",frameSize.width,frameSize.height); */
+  NSTRACE ("windowWillResize: toSize: " NSTRACE_FMT_SIZE,
+           NSTRACE_ARG_SIZE (frameSize));
+  NSTRACE_RECT   ("[sender frame]", [sender frame]);
+  NSTRACE_FSTYPE ("fs_state", fs_state);
 
   if (fs_state == FULLSCREEN_MAXIMIZED
       && (maximized_width != (int)frameSize.width
@@ -6041,6 +6213,7 @@ not_in_argv (NSString *arg)
   else if (fs_state == FULLSCREEN_HEIGHT
            && maximized_height != (int)frameSize.height)
     [self setFSValue: FULLSCREEN_NONE];
+
   if (fs_state == FULLSCREEN_NONE)
     maximized_width = maximized_height = -1;
 
@@ -6090,7 +6263,33 @@ not_in_argv (NSString *arg)
       }
   }
 #endif /* NS_IMPL_COCOA */
-/*fprintf (stderr,"    ...size became %.0f x %.0f  (%d x %d)\n",frameSize.width,frameSize.height,cols,rows); */
+
+  NSTRACE_MSG ("cols: %d  rows: %d", cols, rows);
+
+  /* Restrict the new size to the text gird.
+
+     Don't restict the width if the user only adjusted the height, and
+     vice versa. (Without this, the frame would shrink, and move
+     slightly, if the window was resized by dragging one of its
+     borders. */
+  if (!frame_resize_pixelwise)
+    {
+      NSRect r = [[self window] frame];
+
+      if (r.size.width != frameSize.width)
+        {
+          frameSize.width =
+            FRAME_TEXT_COLS_TO_PIXEL_WIDTH  (emacsframe, cols);
+        }
+
+      if (r.size.height != frameSize.height)
+        {
+          frameSize.height =
+            FRAME_TEXT_LINES_TO_PIXEL_HEIGHT (emacsframe, rows) + extra;
+        }
+    }
+
+  NSTRACE_RETURN_SIZE (frameSize);
 
   return frameSize;
 }
@@ -6098,6 +6297,8 @@ not_in_argv (NSString *arg)
 
 - (void)windowDidResize: (NSNotification *)notification
 {
+  NSTRACE ("windowDidResize");
+
   if (! [self fsIsNative])
     {
       NSWindow *theWindow = [notification object];
@@ -6106,6 +6307,8 @@ not_in_argv (NSString *arg)
       if ([self window] != theWindow) return;
     }
 
+  NSTRACE_RECT ("frame", [[notification object] frame]);
+
 #ifdef NS_IMPL_GNUSTEP
   NSWindow *theWindow = [notification object];
 
@@ -6116,10 +6319,7 @@ not_in_argv (NSString *arg)
   sz = [self windowWillResize: theWindow toSize: sz];
 #endif /* NS_IMPL_GNUSTEP */
 
-  NSTRACE (windowDidResize);
-/*fprintf (stderr,"windowDidResize: %.0f\n",[theWindow frame].size.height); */
-
-if (cols > 0 && rows > 0)
+  if (cols > 0 && rows > 0)
     {
       [self updateFrameSize: YES];
     }
@@ -6148,7 +6348,7 @@ if (cols > 0 && rows > 0)
   struct ns_display_info *dpyinfo = FRAME_DISPLAY_INFO (emacsframe);
   struct frame *old_focus = dpyinfo->x_focus_frame;
 
-  NSTRACE (windowDidBecomeKey);
+  NSTRACE ("windowDidBecomeKey");
 
   if (emacsframe != old_focus)
     dpyinfo->x_focus_frame = emacsframe;
@@ -6168,7 +6368,7 @@ if (cols > 0 && rows > 0)
 {
   struct ns_display_info *dpyinfo = FRAME_DISPLAY_INFO (emacsframe);
   BOOL is_focus_frame = dpyinfo->x_focus_frame == emacsframe;
-  NSTRACE (windowDidResignKey);
+  NSTRACE ("windowDidResignKey");
 
   if (is_focus_frame)
     dpyinfo->x_focus_frame = 0;
@@ -6203,7 +6403,7 @@ if (cols > 0 && rows > 0)
 
 - (void)windowWillMiniaturize: sender
 {
-  NSTRACE (windowWillMiniaturize);
+  NSTRACE ("windowWillMiniaturize");
 }
 
 
@@ -6224,11 +6424,10 @@ if (cols > 0 && rows > 0)
   NSRect r, wr;
   Lisp_Object tem;
   NSWindow *win;
-  NSSize sz;
   NSColor *col;
   NSString *name;
 
-  NSTRACE (initFrameFromEmacs);
+  NSTRACE ("initFrameFromEmacs");
 
   windowClosing = NO;
   processingCompose = NO;
@@ -6283,9 +6482,6 @@ if (cols > 0 && rows > 0)
   MAC_OS_X_VERSION_MAX_ALLOWED <= MAC_OS_X_VERSION_10_9
   [win useOptimizedDrawing: YES];
 #endif
-  sz.width = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
-  sz.height = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);
-  [win setResizeIncrements: sz];
 
   [[win contentView] addSubview: self];
 
@@ -6329,10 +6525,18 @@ if (cols > 0 && rows > 0)
     NSScreen *screen = [win screen];
 
     if (screen != 0)
-      [win setFrameTopLeftPoint: NSMakePoint
-           (IN_BOUND (-SCREENMAX, f->left_pos, SCREENMAX),
-            IN_BOUND (-SCREENMAX,
-                     [screen frame].size.height - NS_TOP_POS (f), SCREENMAX))];
+      {
+        NSPoint pt = NSMakePoint
+          (IN_BOUND (-SCREENMAX, f->left_pos, SCREENMAX),
+           IN_BOUND (-SCREENMAX,
+                     [screen frame].size.height - NS_TOP_POS (f), SCREENMAX));
+
+        NSTRACE_POINT ("setFrameTopLeftPoint", pt);
+
+        [win setFrameTopLeftPoint: pt];
+
+        NSTRACE_RECT ("new frame", [win frame]);
+      }
   }
 
   [win makeFirstResponder: self];
@@ -6362,7 +6566,7 @@ if (cols > 0 && rows > 0)
   NSArray *screens = [NSScreen screens];
   NSScreen *screen = [screens objectAtIndex: 0];
 
-  NSTRACE (windowDidMove);
+  NSTRACE ("windowDidMove");
 
   if (!emacsframe->output_data.ns)
     return;
@@ -6380,6 +6584,10 @@ if (cols > 0 && rows > 0)
    location so set_window_size moves the frame. */
 - (BOOL)windowShouldZoom: (NSWindow *)sender toFrame: (NSRect)newFrame
 {
+  NSTRACE (("[windowShouldZoom:win toFrame:" NSTRACE_FMT_RECT "]"
+            NSTRACE_FMT_RETURN "YES"),
+           NSTRACE_ARG_RECT (newFrame));
+
   emacsframe->output_data.ns->zooming = 1;
   return YES;
 }
@@ -6391,71 +6599,124 @@ if (cols > 0 && rows > 0)
 - (NSRect)windowWillUseStandardFrame:(NSWindow *)sender
                         defaultFrame:(NSRect)defaultFrame
 {
+  // TODO: Rename to "currentFrame" and assign "result" properly in
+  // all paths.
   NSRect result = [sender frame];
 
-  NSTRACE (windowWillUseStandardFrame);
+  NSTRACE (("[windowWillUseStandardFrame: defaultFrame:"
+            NSTRACE_FMT_RECT "]"),
+           NSTRACE_ARG_RECT (defaultFrame));
+  NSTRACE_FSTYPE ("fs_state", fs_state);
+  NSTRACE_FSTYPE ("fs_before_fs", fs_before_fs);
+  NSTRACE_FSTYPE ("next_maximized", next_maximized);
+  NSTRACE_RECT   ("ns_userRect", ns_userRect);
+  NSTRACE_RECT   ("[sender frame]", [sender frame]);
 
   if (fs_before_fs != -1) /* Entering fullscreen */
-      {
-        result = defaultFrame;
-      }
-  else if (next_maximized == FULLSCREEN_HEIGHT
-      || (next_maximized == -1
-          && abs ((int)(defaultFrame.size.height - result.size.height))
-          > FRAME_LINE_HEIGHT (emacsframe)))
-    {
-      /* first click */
-      ns_userRect = result;
-      maximized_height = result.size.height = defaultFrame.size.height;
-      maximized_width = -1;
-      result.origin.y = defaultFrame.origin.y;
-      [self setFSValue: FULLSCREEN_HEIGHT];
-#ifdef NS_IMPL_COCOA
-      maximizing_resize = YES;
-#endif
-    }
-  else if (next_maximized == FULLSCREEN_WIDTH)
     {
-      ns_userRect = result;
-      maximized_width = result.size.width = defaultFrame.size.width;
-      maximized_height = -1;
-      result.origin.x = defaultFrame.origin.x;
-      [self setFSValue: FULLSCREEN_WIDTH];
+      NSTRACE_MSG ("Entering fullscreen");
+      result = defaultFrame;
     }
-  else if (next_maximized == FULLSCREEN_MAXIMIZED
-           || (next_maximized == -1
-               && abs ((int)(defaultFrame.size.width - result.size.width))
-               > FRAME_COLUMN_WIDTH (emacsframe)))
+  else
     {
-      result = defaultFrame;  /* second click */
-      maximized_width = result.size.width;
-      maximized_height = result.size.height;
-      [self setFSValue: FULLSCREEN_MAXIMIZED];
+      // Save the window size and position (frame) before the resize.
+      if (fs_state != FULLSCREEN_MAXIMIZED
+          && fs_state != FULLSCREEN_WIDTH)
+        {
+          ns_userRect.size.width = result.size.width;
+          ns_userRect.origin.x   = result.origin.x;
+        }
+
+      if (fs_state != FULLSCREEN_MAXIMIZED
+          && fs_state != FULLSCREEN_HEIGHT)
+        {
+          ns_userRect.size.height = result.size.height;
+          ns_userRect.origin.y    = result.origin.y;
+        }
+
+      NSTRACE_RECT ("ns_userRect (2)", ns_userRect);
+
+      if (next_maximized == FULLSCREEN_HEIGHT
+          || (next_maximized == -1
+              && abs ((int)(defaultFrame.size.height - result.size.height))
+              > FRAME_LINE_HEIGHT (emacsframe)))
+        {
+          /* first click */
+          NSTRACE_MSG ("FULLSCREEN_HEIGHT");
+          maximized_height = result.size.height = defaultFrame.size.height;
+          maximized_width = -1;
+          result.origin.y = defaultFrame.origin.y;
+          if (ns_userRect.size.height != 0)
+            {
+              result.origin.x = ns_userRect.origin.x;
+              result.size.width = ns_userRect.size.width;
+            }
+          [self setFSValue: FULLSCREEN_HEIGHT];
 #ifdef NS_IMPL_COCOA
-      maximizing_resize = YES;
+          maximizing_resize = YES;
 #endif
-    }
-  else
-    {
-      /* restore */
-      result = ns_userRect.size.height ? ns_userRect : result;
-      ns_userRect = NSMakeRect (0, 0, 0, 0);
+        }
+      else if (next_maximized == FULLSCREEN_WIDTH)
+        {
+          NSTRACE_MSG ("FULLSCREEN_WIDTH");
+          maximized_width = result.size.width = defaultFrame.size.width;
+          maximized_height = -1;
+          result.origin.x = defaultFrame.origin.x;
+          if (ns_userRect.size.width != 0)
+            {
+              result.origin.y = ns_userRect.origin.y;
+              result.size.height = ns_userRect.size.height;
+            }
+          [self setFSValue: FULLSCREEN_WIDTH];
+        }
+      else if (next_maximized == FULLSCREEN_MAXIMIZED
+               || (next_maximized == -1
+                   && abs ((int)(defaultFrame.size.width - result.size.width))
+                   > FRAME_COLUMN_WIDTH (emacsframe)))
+        {
+          NSTRACE_MSG ("FULLSCREEN_MAXIMIZED");
+
+          result = defaultFrame;  /* second click */
+          maximized_width = result.size.width;
+          maximized_height = result.size.height;
+          [self setFSValue: FULLSCREEN_MAXIMIZED];
+#ifdef NS_IMPL_COCOA
+          maximizing_resize = YES;
+#endif
+        }
+      else
+        {
+          /* restore */
+          NSTRACE_MSG ("Restore");
+          result = ns_userRect.size.height ? ns_userRect : result;
+          NSTRACE_RECT ("restore (2)", result);
+          ns_userRect = NSMakeRect (0, 0, 0, 0);
 #ifdef NS_IMPL_COCOA
-      maximizing_resize = fs_state != FULLSCREEN_NONE;
+          maximizing_resize = fs_state != FULLSCREEN_NONE;
 #endif
-      [self setFSValue: FULLSCREEN_NONE];
-      maximized_width = maximized_height = -1;
+          [self setFSValue: FULLSCREEN_NONE];
+          maximized_width = maximized_height = -1;
+        }
     }
 
   if (fs_before_fs == -1) next_maximized = -1;
+
+  NSTRACE_RECT   ("Final ns_userRect", ns_userRect);
+  NSTRACE_MSG    ("Final maximized_width: %d", maximized_width);
+  NSTRACE_MSG    ("Final maximized_height: %d", maximized_height);
+  NSTRACE_FSTYPE ("Final next_maximized", next_maximized);
+
   [self windowWillResize: sender toSize: result.size];
+
+  NSTRACE_RETURN_RECT (result);
+
   return result;
 }
 
 
 - (void)windowDidDeminiaturize: sender
 {
-  NSTRACE (windowDidDeminiaturize);
+  NSTRACE ("windowDidDeminiaturize");
   if (!emacsframe->output_data.ns)
     return;
 
@@ -6473,7 +6734,7 @@ if (cols > 0 && rows > 0)
 
 - (void)windowDidExpose: sender
 {
-  NSTRACE (windowDidExpose);
+  NSTRACE ("windowDidExpose");
   if (!emacsframe->output_data.ns)
     return;
 
@@ -6487,7 +6748,7 @@ if (cols > 0 && rows > 0)
 
 - (void)windowDidMiniaturize: sender
 {
-  NSTRACE (windowDidMiniaturize);
+  NSTRACE ("windowDidMiniaturize");
   if (!emacsframe->output_data.ns)
     return;
 
@@ -6512,11 +6773,13 @@ if (cols > 0 && rows > 0)
 
 - (void)windowWillEnterFullScreen:(NSNotification *)notification
 {
+  NSTRACE ("windowWillEnterFullScreen");
   fs_before_fs = fs_state;
 }
 
 - (void)windowDidEnterFullScreen:(NSNotification *)notification
 {
+  NSTRACE ("windowDidEnterFullScreen");
   [self setFSValue: FULLSCREEN_BOTH];
   if (! [self fsIsNative])
     {
@@ -6550,12 +6813,16 @@ if (cols > 0 && rows > 0)
 
 - (void)windowWillExitFullScreen:(NSNotification *)notification
 {
+  NSTRACE ("windowWillExitFullScreen");
+
   if (next_maximized != -1)
     fs_before_fs = next_maximized;
 }
 
 - (void)windowDidExitFullScreen:(NSNotification *)notification
 {
+  NSTRACE ("windowDidExitFullScreen");
+
   [self setFSValue: fs_before_fs];
   fs_before_fs = -1;
 #ifdef HAVE_NATIVE_FS
@@ -6613,10 +6880,11 @@ if (cols > 0 && rows > 0)
   NSWindow *w, *fw;
   BOOL onFirstScreen;
   struct frame *f;
-  NSSize sz;
   NSRect r, wr;
   NSColor *col;
 
+  NSTRACE ("toggleFullScreen");
+
   if (fs_is_native)
     {
 #ifdef HAVE_NATIVE_FS
@@ -6633,9 +6901,6 @@ if (cols > 0 && rows > 0)
                                  (FRAME_DEFAULT_FACE (f)),
                                  f);
 
-  sz.width = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (f);
-  sz.height = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (f);
-
   if (fs_state != FULLSCREEN_BOTH)
     {
       NSScreen *screen = [w screen];
@@ -6675,7 +6940,6 @@ if (cols > 0 && rows > 0)
   MAC_OS_X_VERSION_MAX_ALLOWED <= MAC_OS_X_VERSION_10_9
       [fw useOptimizedDrawing: YES];
 #endif
-      [fw setResizeIncrements: sz];
       [fw setBackgroundColor: col];
       if ([col alphaComponent] != (EmacsCGFloat) 1.0)
         [fw setOpaque: NO];
@@ -6712,7 +6976,6 @@ if (cols > 0 && rows > 0)
         }
 
       [w setContentView:[fw contentView]];
-      [w setResizeIncrements: sz];
       [w setBackgroundColor: col];
       if ([col alphaComponent] != (EmacsCGFloat) 1.0)
         [w setOpaque: NO];
@@ -6733,39 +6996,42 @@ if (cols > 0 && rows > 0)
 
 - (void)handleFS
 {
+  NSTRACE ("handleFS");
+
   if (fs_state != emacsframe->want_fullscreen)
     {
-      NSSize sz;
-      sz.width = frame_resize_pixelwise ? 1 : FRAME_COLUMN_WIDTH (emacsframe);
-      sz.height = frame_resize_pixelwise ? 1 : FRAME_LINE_HEIGHT (emacsframe);
-      [[self window] setResizeIncrements:sz];
-
       if (fs_state == FULLSCREEN_BOTH)
         {
+          NSTRACE_MSG ("fs_state == FULLSCREEN_BOTH");
           [self toggleFullScreen:self];
         }
 
       switch (emacsframe->want_fullscreen)
         {
         case FULLSCREEN_BOTH:
+          NSTRACE_MSG ("FULLSCREEN_BOTH");
           [self toggleFullScreen:self];
           break;
         case FULLSCREEN_WIDTH:
+          NSTRACE_MSG ("FULLSCREEN_WIDTH");
           next_maximized = FULLSCREEN_WIDTH;
           if (fs_state != FULLSCREEN_BOTH)
             [[self window] performZoom:self];
           break;
         case FULLSCREEN_HEIGHT:
+          NSTRACE_MSG ("FULLSCREEN_HEIGHT");
           next_maximized = FULLSCREEN_HEIGHT;
           if (fs_state != FULLSCREEN_BOTH)
             [[self window] performZoom:self];
           break;
         case FULLSCREEN_MAXIMIZED:
+          NSTRACE_MSG ("FULLSCREEN_MAXIMIZED");
           next_maximized = FULLSCREEN_MAXIMIZED;
           if (fs_state != FULLSCREEN_BOTH)
             [[self window] performZoom:self];
           break;
         case FULLSCREEN_NONE:
+          NSTRACE_MSG ("FULLSCREEN_NONE");
           if (fs_state != FULLSCREEN_BOTH)
             {
               next_maximized = FULLSCREEN_NONE;
@@ -6781,6 +7047,9 @@ if (cols > 0 && rows > 0)
 
 - (void) setFSValue: (int)value
 {
+  NSTRACE ("setFSValue");
+  NSTRACE_FSTYPE ("value", value);
+
   Lisp_Object lval = Qnil;
   switch (value)
     {
@@ -6803,7 +7072,7 @@ if (cols > 0 && rows > 0)
 
 - (void)mouseEntered: (NSEvent *)theEvent
 {
-  NSTRACE (mouseEntered);
+  NSTRACE ("mouseEntered");
   if (emacsframe)
     FRAME_DISPLAY_INFO (emacsframe)->last_mouse_movement_time
       = EV_TIMESTAMP (theEvent);
@@ -6814,7 +7083,7 @@ if (cols > 0 && rows > 0)
 {
   Mouse_HLInfo *hlinfo = emacsframe ? MOUSE_HL_INFO (emacsframe) : NULL;
 
-  NSTRACE (mouseExited);
+  NSTRACE ("mouseExited");
 
   if (!hlinfo)
     return;
@@ -6832,7 +7101,7 @@ if (cols > 0 && rows > 0)
 
 - menuDown: sender
 {
-  NSTRACE (menuDown);
+  NSTRACE ("menuDown");
   if (context_menu_value == -1)
     context_menu_value = [sender tag];
   else
@@ -6860,7 +7129,7 @@ if (cols > 0 && rows > 0)
   NSEvent *theEvent;
   int idx = [item tag] * TOOL_BAR_ITEM_NSLOTS;
 
-  NSTRACE (toolbarClicked);
+  NSTRACE ("toolbarClicked");
 
   if (!emacs_event)
     return self;
@@ -6898,7 +7167,8 @@ if (cols > 0 && rows > 0)
   int x = NSMinX (rect), y = NSMinY (rect);
   int width = NSWidth (rect), height = NSHeight (rect);
 
-  NSTRACE (drawRect);
+  NSTRACE ("drawRect");
+  NSTRACE_RECT ("input", rect);
 
   if (!emacsframe || !emacsframe->output_data.ns)
     return;
@@ -6924,7 +7194,7 @@ if (cols > 0 && rows > 0)
 
 -(NSDragOperation) draggingEntered: (id <NSDraggingInfo>) sender
 {
-  NSTRACE (draggingEntered);
+  NSTRACE ("draggingEntered");
   return NSDragOperationGeneric;
 }
 
@@ -6945,7 +7215,7 @@ if (cols > 0 && rows > 0)
   NSDragOperation op = [sender draggingSourceOperationMask];
   int modifiers = 0;
 
-  NSTRACE (performDragOperation);
+  NSTRACE ("performDragOperation");
 
   if (!emacs_event)
     return NO;
@@ -7045,7 +7315,7 @@ if (cols > 0 && rows > 0)
 - (id) validRequestorForSendType: (NSString *)typeSent
                       returnType: (NSString *)typeReturned
 {
-  NSTRACE (validRequestorForSendType);
+  NSTRACE ("validRequestorForSendType");
   if (typeSent != nil && [ns_send_types indexOfObject: typeSent] != NSNotFound
       && typeReturned == nil)
     {
@@ -7107,7 +7377,7 @@ if (cols > 0 && rows > 0)
 - setMiniwindowImage: (BOOL) setMini
 {
   id image = [[self window] miniwindowImage];
-  NSTRACE (setMiniwindowImage);
+  NSTRACE ("setMiniwindowImage");
 
   /* NOTE: under Cocoa miniwindowImage always returns nil, documentation
      about "AppleDockIconEnabled" notwithstanding, however the set message
@@ -7130,6 +7400,11 @@ if (cols > 0 && rows > 0)
   cols = c;
 }
 
+- (int) fullscreenState
+{
+  return fs_state;
+}
+
 @end  /* EmacsView */
 
 
@@ -7199,32 +7474,96 @@ if (cols > 0 && rows > 0)
 }
 #endif /* NS_IMPL_COCOA */
 
-/* If we have multiple monitors, one above the other, we don't want to
-   restrict the height to just one monitor.  So we override this.  */
+/* Constrain size and placement of a frame.
+
+   By returning the original "frameRect", the frame is not
+   contrained. This can lead to unwanted situations where, for
+   example, the menu bar covers the frame.
+
+   The default implementation (accessed using "super") constrains the
+   frame to the visible area of SCREEN, minus the menu bar (if
+   present) and the Dock. Note that default implementation also calls
+   windowWillResize, with the frame it thinks should have. (This can
+   make the frame exit maximized mode.)
+
+   Note that this should work in situations where multiple monitors
+   are present. Common configurations are side-by-side monitors and a
+   monitor on top of another (e.g. when a laptop is placed under a
+   large screen). */
+#if 1
+- (NSRect)constrainFrameRect:(NSRect)frameRect toScreen:(NSScreen *)screen
+{
+  NSTRACE ("constrainFrameRect:" NSTRACE_FMT_RECT " toScreen:",
+             NSTRACE_ARG_RECT (frameRect));
+
+#ifdef NS_IMPL_COCOA
+#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_9
+  // If separate spaces is on, it is like each screen is independent.  There is
+  // no spanning of frames across screens.
+  if ([NSScreen screensHaveSeparateSpaces])
+    {
+      NSTRACE_MSG ("Screens have separate spaces");
+      frameRect = [super constrainFrameRect:frameRect toScreen:screen];
+      NSTRACE_RETURN_RECT (frameRect);
+      return frameRect;
+    }
+#endif
+#endif
+
+  return constrain_frame_rect(frameRect);
+}
+#else
 - (NSRect)constrainFrameRect:(NSRect)frameRect toScreen:(NSScreen *)screen
 {
   /* When making the frame visible for the first time or if there is just
      one screen, we want to constrain.  Other times not.  */
   NSArray *screens = [NSScreen screens];
   NSUInteger nr_screens = [screens count], nr_eff_screens = 0, i;
-  NSTRACE (constrainFrameRect);
-  NSTRACE_RECT ("input", frameRect);
+  NSTRACE ("constrainFrameRect:" NSTRACE_FMT_RECT,
+           NSTRACE_ARG_RECT (frameRect));
 
   if (ns_menu_bar_should_be_hidden ())
-    return frameRect;
+    {
+      NSTRACE_RECT ("Menu bar should be hidden", frameRect);
+      return frameRect;
+    }
 
   if (nr_screens == 1)
-    return [super constrainFrameRect:frameRect toScreen:screen];
+    {
+      frameRect = [super constrainFrameRect:frameRect toScreen:screen];
+      NSTRACE_MSG ("nr_screens == 1");
+      NSTRACE_RETURN_RECT (frameRect);
+      return frameRect;
+    }
 
 #ifdef NS_IMPL_COCOA
 #if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_9
   // If separate spaces is on, it is like each screen is independent.  There is
   // no spanning of frames across screens.
   if ([NSScreen screensHaveSeparateSpaces])
-    return [super constrainFrameRect:frameRect toScreen:screen];
+    {
+      frameRect = [super constrainFrameRect:frameRect toScreen:screen];
+      NSTRACE_MSG ("Screens have separate spaces");
+      NSTRACE_RETURN_RECT (frameRect);
+      return frameRect;
+    }
 #endif
 #endif
 
+  /* TODO: Decide what to do with this. Currently disabled since it
+     cause maximized windows to be resized to accomodate the dock,
+     which is not what we want. */
+#if 1
+  /* Constrain a frame on a single screen to that screen. */
+
+  /* TODO: This has the effect that a frame on a single screen is
+     restricted in height, whereas a frame stratching two side-by side
+     monitors are not, when resized programmatically. Clearly, this is
+     not the desired behaviour.
+
+     Also, if the monitors are one above the other, this will probably
+     prevent the frame from stretching over them both. */
+
   for (i = 0; i < nr_screens; ++i)
     {
       NSScreen *s = [screens objectAtIndex: i];
@@ -7236,7 +7575,13 @@ if (cols > 0 && rows > 0)
     }
 
   if (nr_eff_screens == 1)
-    return [super constrainFrameRect:frameRect toScreen:screen];
+    {
+      frameRect = [super constrainFrameRect:frameRect toScreen:screen];
+      NSTRACE_MSG ("nr_eff_screens == 1");
+      NSTRACE_RETURN_RECT (frameRect);
+      return frameRect;
+    }
+#endif
 
   /* The default implementation does two things 1) ensure that the top
      of the rectangle is below the menu bar (or below the top of the
@@ -7262,11 +7607,103 @@ if (cols > 0 && rows > 0)
     frameRect.origin.y = new_top - frameRect.size.height;
   }
 
-  NSTRACE_RECT ("output", frameRect);
+  NSTRACE_RETURN_RECT (frameRect);
 
   return frameRect;
 #undef FAKE_HEIGHT
 }
+#endif
+
+
+- (void)performZoom:(id)sender
+{
+  NSTRACE ("performZoom");
+
+  return [super performZoom:sender];
+}
+
+- (void)zoom:(id)sender
+{
+  struct frame * f = SELECTED_FRAME ();
+
+  NSTRACE ("zoom");
+
+  ns_update_auto_hide_menu_bar();
+
+  // Below are three zoom implementations. In the final commit, the
+  // idea is that the last should be included.
+
+#if 0
+  // Native zoom done using the standard zoom animation. Size of the
+  // resulting frame reduced to accomodate the Dock and, if present,
+  // the menu-bar.
+  [super zoom:sender];
+
+#elsif 0
+  // Native zoom done using the standard zoom animation, plus an
+  // explicit resize to cover the full screen.
+  [super zoom:sender];
+
+  // After the native zoom, resize the resulting frame to fill the
+  // entire screen, except the menu-bar.
+  //
+  // This works for all practical purposes. (The only minor oddity is
+  // when transiting from full-height frame to a maximized, the
+  // animation reduces the height of the frame slighty (to the 4
+  // pixels needed to accomodate the Doc) before it snaps back into
+  // full height. The user would need a very trained eye to spot
+  // this.)
+  NSScreen * screen = [self screen];
+  if (screen != nil)
+    {
+      int fs_state = [(EmacsView *)[self delegate] fullscreenState];
+
+      NSTRACE_FSTYPE ("fullscreenState", fs_state);
+
+      NSRect sr = [screen frame];
+      NSRect wr = [self frame];
+      NSTRACE_RECT ("Rect after zoom", wr);
+
+      NSRect newWr = wr;
+
+      if (fs_state == FULLSCREEN_MAXIMIZED
+          || fs_state == FULLSCREEN_HEIGHT)
+        {
+          newWr.origin.x = 0;
+          newWr.size.height = sr.size.height - ns_menu_bar_height(screen);
+        }
+
+      if (fs_state == FULLSCREEN_MAXIMIZED
+          || fs_state == FULLSCREEN_WIDTH)
+        {
+          newWr.origin.y = 0;
+          newWr.size.width = sr.size.width;
+        }
+
+      if (newWr.size.width     != wr.size.width
+          || newWr.size.height != wr.size.height
+          || newWr.origin.x    != wr.origin.x
+          || newWr.origin.y    != wr.origin.y)
+        {
+          NSTRACE_RECT ("Corrected rect", newWr);
+          [self setFrame: newWr display: NO];
+        }
+    }
+#else
+  // Non-native zoom which is done instantaneous. The resulting frame
+  // covert the entire scrren, except the menu-bar, if present.
+  NSScreen * screen = [self screen];
+  if (screen != nil)
+    {
+      NSRect sr = [screen frame];
+      sr.size.height -= ns_menu_bar_height (screen);
+
+      sr = [[self delegate] windowWillUseStandardFrame:self
+                                          defaultFrame:sr];
+      [self setFrame: sr display: NO];
+    }
+#endif
+}
 
 @end /* EmacsWindow */
 
@@ -7316,7 +7753,7 @@ if (cols > 0 && rows > 0)
 
 - initFrame: (NSRect )r window: (Lisp_Object)nwin
 {
-  NSTRACE (EmacsScroller_initFrame);
+  NSTRACE ("EmacsScroller_initFrame");
 
   r.size.width = [EmacsScroller scrollerWidth];
   [super initWithFrame: r/*NSMakeRect (0, 0, 0, 0)*/];
@@ -7362,7 +7799,7 @@ if (cols > 0 && rows > 0)
 
 - (void)setFrame: (NSRect)newRect
 {
-  NSTRACE (EmacsScroller_setFrame);
+  NSTRACE ("EmacsScroller_setFrame");
 /*  block_input (); */
   pixel_height = NSHeight (newRect);
   if (pixel_height == 0) pixel_height = 1;
@@ -7374,7 +7811,7 @@ if (cols > 0 && rows > 0)
 
 - (void)dealloc
 {
-  NSTRACE (EmacsScroller_dealloc);
+  NSTRACE ("EmacsScroller_dealloc");
   if (window)
     wset_vertical_scroll_bar (window, Qnil);
   window = 0;
@@ -7384,7 +7821,7 @@ if (cols > 0 && rows > 0)
 
 - condemn
 {
-  NSTRACE (condemn);
+  NSTRACE ("condemn");
   condemned =YES;
   return self;
 }
@@ -7392,7 +7829,7 @@ if (cols > 0 && rows > 0)
 
 - reprieve
 {
-  NSTRACE (reprieve);
+  NSTRACE ("reprieve");
   condemned =NO;
   return self;
 }
@@ -7400,7 +7837,7 @@ if (cols > 0 && rows > 0)
 
 -(bool)judge
 {
-  NSTRACE (judge);
+  NSTRACE ("judge");
   bool ret = condemned;
   if (condemned)
     {
@@ -7424,7 +7861,7 @@ if (cols > 0 && rows > 0)
 - (void)resetCursorRects
 {
   NSRect visible = [self visibleRect];
-  NSTRACE (resetCursorRects);
+  NSTRACE ("resetCursorRects");
 
   if (!NSIsEmptyRect (visible))
     [self addCursorRect: visible cursor: [NSCursor arrowCursor]];
@@ -7442,7 +7879,7 @@ if (cols > 0 && rows > 0)
 
 - setPosition: (int)position portion: (int)portion whole: (int)whole
 {
-  NSTRACE (setPosition);
+  NSTRACE ("setPosition");
 
   em_position = position;
   em_portion = portion;
@@ -7547,7 +7984,7 @@ if (cols > 0 && rows > 0)
   CGFloat inc = 0.0, loc, kloc, pos;
   int edge = 0;
 
-  NSTRACE (EmacsScroller_mouseDown);
+  NSTRACE ("EmacsScroller_mouseDown");
 
   switch (part)
     {
@@ -7644,7 +8081,7 @@ if (cols > 0 && rows > 0)
     NSRect sr;
     double loc, pos;
 
-    NSTRACE (EmacsScroller_mouseDragged);
+    NSTRACE ("EmacsScroller_mouseDragged");
 
       sr = [self convertRect: [self rectForPart: NSScrollerKnobSlot]
                       toView: nil];
@@ -7813,7 +8250,7 @@ ns_xlfd_to_fontname (const char *xlfd)
 void
 syms_of_nsterm (void)
 {
-  NSTRACE (syms_of_nsterm);
+  NSTRACE ("syms_of_nsterm");
 
   ns_antialias_threshold = 10.0;
 

[-- Attachment #3: anders-frame-test.el --]
[-- Type: application/octet-stream, Size: 6945 bytes --]

;;; frame-test.el --- Test Emacs resize and zoom features.

;; Copyright (C) 2015  Anders Lindgren

;; Author: Anders Lindgren <anders@macpro.lan>
;; Keywords: frames

;; This program is free software; you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.

;; This program is distributed in the hope that it will be useful,
;; but WITHOUT ANY WARRANTY; without even the implied warranty of
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;; GNU General Public License for more details.

;; You should have received a copy of the GNU General Public License
;; along with this program.  If not, see <http://www.gnu.org/licenses/>.

;;; Commentary:

;; Tests for Emacs resize and zoom features.

;;; Code:

(require 'ert)

(defun frame-test-display-monitor-rect (&optional frame)
  "Return (X Y WIDTH HEIGHT) of monitor hosting FRAME.

X and Y are relative to the top left corner."
  (cdr (assq 'geometry (frame-monitor-attributes frame))))


(defun frame-test-calculate-position (value width-or-height)
  "Convert from frame parameter values to real coordinates.

If VALUE is a non-negative integer, it is relative to the near
border and is returned.

If VALUE is a negative integer, it is considered relative from
the far border and the absolute value is subtracted from WIDTH-OR-HEIGHT.

If VALUE is (+ REL), it is considered relative to the near
border, REL is returned.

If VALUE is (- REL), it is considered relative to the far border,
WIDTH-OR-HEIGHT minus REL is returned."
  (unless (consp value)
    (if (< value 0)
        (setq value (list '- (- value)))
      (setq value (list '+ value))))
  (cond ((eq (car value) '+)
         (nth 1 value))
        ((eq (car value) '-)
         (- width-or-height (nth 1 value)))
        (t
         (error "unexpected position: %s" value))))


(defun frame-test-frame-rect (&optional frame)
  "Return the geometry, (X Y WIDTH HEIGHT), of FRAME."
  (unless frame
    (setq frame (selected-frame)))
  (let ((geometry (frame-test-display-monitor-rect frame)))
    (list
     (frame-test-calculate-position
      (frame-parameter frame 'left) (nth 2 geometry))
     (frame-test-calculate-position
      (frame-parameter frame 'top) (nth 3 geometry))
     (frame-pixel-width)
     (frame-pixel-height))))


(defun frame-test-set-nth (list n value)
  "Return a copy of LIST where the N:th element is VALUE."
  (let ((new-list (copy-tree list)))
    (setcar (nthcdr n new-list) value)
    new-list))


(defun frame-test-set-geometry-xpos-width (x width geometry)
  "Return a copy of GEOMETRY with new X and WIDTH values."
  (frame-test-set-nth
   (frame-test-set-nth geometry 2 width)
   0 x))


(defun frame-test-set-geometry-ypos-height (y height geometry)
  "Return a copy of GEOMETRY with new Y and HEIGHT values."
  (frame-test-set-nth
   (frame-test-set-nth geometry 3 height)
   1 y))

(defun frame-test-extra-height (&optional frame)
  "Number of extra pixels on the top and botton of FRAME."
  (if (fboundp 'frame-edges)
      (let ((outer (frame-edges frame 'outer-edges))
            (inner (frame-edges frame 'inner-edges)))
        (+ (- (nth 1 inner)
              (nth 1 outer))
           (- (nth 2 inner)
              (nth 2 outer))))))

(defun frame-test-menu-bar-height (&optional frame)
  "The height of the menu bar, if present."
  (nth 1 (cdr (assq 'workarea (frame-monitor-attributes frame)))))


;; -------------------------------------------------------------------
;; Test cases
;;

(ert-deftest frame-test-fullscreen-property ()
  "Test frame fullscreen properties."
  (set-frame-position (selected-frame) 100 100)
  (set-frame-size (selected-frame) 80 40)
  (let ((user-rect (frame-test-frame-rect))
        (monitor-rect (frame-test-display-monitor-rect)))
    (set-frame-parameter (selected-frame) 'fullscreen nil)
    (should (equal user-rect (frame-test-frame-rect)))

    ;; ----------
    ;; Full width
    (set-frame-parameter (selected-frame) 'fullscreen 'fullwidth)
    (sit-for 0)
    (should (equal (frame-test-set-geometry-xpos-width
		    0 (nth 2 monitor-rect) user-rect)
		   (frame-test-frame-rect)))

    (set-frame-parameter (selected-frame) 'fullscreen nil)
    (sit-for 0)
    (should (equal user-rect
		   (frame-test-frame-rect)))

    ;; ----------
    ;; Full height
    (sit-for 0)
    (set-frame-parameter (selected-frame) 'fullscreen 'fullheight)
    (sit-for 0)
    (let ((menu-bar-height (frame-test-menu-bar-height)))
      (should (equal (frame-test-set-geometry-ypos-height
		      menu-bar-height
		      (- (nth 3 monitor-rect)
			 menu-bar-height
			 (frame-test-extra-height))
		      user-rect)
		     (frame-test-frame-rect))))

    (sit-for 0)
    (set-frame-parameter (selected-frame) 'fullscreen nil)
    (sit-for 0)
    (should (equal user-rect (frame-test-frame-rect)))

    ;; ----------
    ;; Maximized
    (set-frame-parameter (selected-frame) 'fullscreen 'maximized)
    (sit-for 0)
    (let ((menu-bar-height (frame-test-menu-bar-height)))
      (should (equal (list 0 menu-bar-height
			   (nth 2 monitor-rect)
			   (- (nth 3 monitor-rect)
			      menu-bar-height
			      (frame-test-extra-height)))
		     (frame-test-frame-rect))))

    (sit-for 0)
    (set-frame-parameter (selected-frame) 'fullscreen nil)
    (sit-for 0)
    (should (equal user-rect (frame-test-frame-rect)))

    ;; ----------
    ;; User -> Fullwidth -> Fullhight -> User
    (set-frame-parameter (selected-frame) 'fullscreen 'fullwidth)
    (sit-for 0.1)
    (set-frame-parameter (selected-frame) 'fullscreen 'fullheight)
    (sit-for 0.1)
    (set-frame-parameter (selected-frame) 'fullscreen nil)
    (sit-for 0.1)
    (should (equal user-rect (frame-test-frame-rect)))
    ))

(ert-deftest frame-test-ns-auto-hide-menu-bar ()
  "Test frame NextStep-specific features, no-op otherwise."
  (when (boundp 'ns-auto-hide-menu-bar)
    (set-frame-position (selected-frame) 100 100)
    (set-frame-size (selected-frame) 80 40)
    (let ((user-rect (frame-test-frame-rect)))
      (let ((menu-bar-height (frame-test-menu-bar-height)))
        (setq ns-auto-hide-menu-bar t)
        (set-frame-position (selected-frame) 100 -50)
        (sit-for 0)
        (should (equal (frame-test-set-nth user-rect 1 -50)
                       (frame-test-frame-rect)))
        (setq ns-auto-hide-menu-bar nil)
        (sit-for 0)
        (should (equal (frame-test-set-nth user-rect 1 menu-bar-height)
                       (frame-test-frame-rect)))))))


;; TODO:
;;
;; * When frame-resize-pixelwise is nil:
;;
;; ** Draggins in a corner should snap window size to text grid.
;;
;; ** Dragging a border should snap that axis, not the other.
;;
;; * Zooming, both with toggle-frame-maximized and by ALT-clicking the green button.

(provide 'frame-test)

;;; frame-test.el ends here

[-- Attachment #4: emacs-commit-messages.txt --]
[-- Type: text/plain, Size: 6818 bytes --]

        Full-height, full-width, and maximized windows now cover the
        entire screen (except the menu bar), including the part where the
        system dock is placed. The system zoom animation is no longer
        used.

        Made NonMaximized->FullWidth->FullHeight->NonMaximized restore the
        original size.

        * nsterm.m (ns_menu_bar_height): New function, return height of
        the menu bar, or 0 when it's hidden.
        * nsterm.m (constrain_frame_rect): New function for constraining a
        frame.
        * nsterm.m (ns_constrain_all_frames): Set frame size explicitly
        rather than relying on the system doing it for us by writing back
        the current frame size.
        * nsterm.m (windowWillUseStandardFrame): Register non-maximized
        width or height as new user size. When entering full width or
        height, the other size component is taken from the user size.
        * nsterm.m (fullscreenState): New method for accessing the
        fullscreen state.
        * nsterm.m (constrainFrameRect): Restrict frame to be placed under
        the menu bar, if present. The old version, sometimes, restricted
        the height of a frame to the screen, this version never does this.
        * nsterm.m (zoom): Perform zoom by setting the frame to the full
        size of the screen (minus the menu bar). The default system
        function, with the zoom animation, is no longer used, as the final
        frame size doesn't cover the entire screen.



        Rework how to constrain resizing to the character grid. The old
        system used "resizeIncrements" in NSWindows. However, once a frame
        was resized so that it was not aligned to the text grid, it
        remained unaligned even after a resize. In addition, it conflicted
        when resizing a fullheight window.

        * nsterm.m (windowWillResize): Restrict frame size to text grid,
        unless when pixelwise frame resizing is enabled.
        * nsterm.m (updateFrameSize, initFrameFromEmacs)
        (toggleFullScreen, handleFS): Don't set resizeIncrements.


        Redesign the NS trace system. The call structure is represented
        using indentations and vertical lines. The NSTRACE macro accepts
        printf-style arguments. New macros for printing various
        information.

        * nsterm.h (NSTRACE_ENABLED): Macro to enable trace system.
        * nsterm.h (NSTRACE, NSTRACE_WHEN, NSTRACE_UNLESS): Macros to
        start a new block (typically a function), accept printf-style
        arguments.
        * nsterm.h (NSTRACE_MSG): Macro for extra information, accepts
        printf-style arguments.
        * nsterm.h (NSTRACE_what): Macros for printing various types.
        * nsterm.h (NSTRACE_FMT_what): Macro with printf format string
        snippets.
        * nsterm.h (NSTRACE_ARG_what): Macros for passing printf-style
        arguments, corresponds to NSTRACE_FMT_what.
        * nsterm.h (NSTRACE_RETURN): Macro to print return value, accept
        printf-style arguments.
        * nsterm.h (NSTRACE_RETURN_what): Macros to print return value for
        various types.

	* nsterm.m: Remove old NSTRACE macro.
	* nsterm.m (nstrace_num): Trace counter.
        * nsterm.m (nstrace_depth): Current call depth.
        * nsterm.m (nstrace_leave): NSTRACE support function, called when
        the local variable "nstrace_enabled" goes out of scope using the
        "cleanup" extension.
        * nsterm.m (ns_print_fullscreen_type_name): NSTRACE_FSTYPE support
        function.
	* nsterm.m (constrain_frame_rect, ns_constrain_all_frames)
        (ns_update_auto_hide_menu_bar, ns_update_begin)
        (ns_update_window_begin, update_window_end, ns_update_end)
        (ns_focus, ns_unfocus, ns_ring_bell, ns_frame_raise_lower)
        (ns_frame_rehighlight, x_make_frame_visible)
        (x_make_frame_invisible, x_iconify_frame, x_free_frame_resources)
        (x_destroy_window, x_set_offset, x_set_window_size)
        (ns_fullscreen_hook, ns_lisp_to_color, ns_color_to_lisp)
        (ns_defined_color, frame_set_mouse_pixel_position)
        (note_mouse_movement, ns_mouse_position, ns_frame_up_to_date)
        (ns_define_frame_cursor, x_get_keysym_name, ns_redraw_scroll_bars)
        (ns_clear_frame, ns_clear_frame_area, ns_scroll_run)
        (ns_after_update_window_line, ns_shift_glyphs_for_insert)
        (dumpcursor, ns_draw_vertical_window_border)
        (ns_draw_window_divider, ns_draw_relief)
        (ns_dumpglyphs_box_or_relief, ns_maybe_dumpglyphs_background)
        (ns_dumpglyphs_image, ns_draw_glyph_string, ns_send_appdefined)
        (ns_read_socket, ns_select, ns_set_vertical_scroll_bar)
        (ns_set_horizontal_scroll_bar, ns_condemn_scroll_bars)
        (ns_redeem_scroll_bar, ns_judge_scroll_bars, ns_delete_terminal)
        (ns_create_terminal, ns_term_init, sendEvent)
        (applicationDidFinishLaunching, applicationDidBecomeActive)
        (timeout_handler, fd_handler, EmacsView_dealloc, changeFont)
        (acceptsFirstResponder, resetCursorRects, keyDown, mouseDown)
        (deltaIsZero, rightMouseDown, otherMouseDown, mouseUp)
        (rightMouseUp, otherMouseUp, scrollWheel, mouseMoved)
        (mouse_autoselect_window, in_window, mouseDragged)
        (rightMouseDragged, otherMouseDragged, windowShouldClose)
        (updateFrameSize, windowWillResize, windowDidResize)
        (windowDidBecomeKey, windowDidResignKey, windowWillMiniaturize)
        (initFrameFromEmacs, windowDidMove, windowDidDeminiaturize)
        (windowDidExpose, windowDidMiniaturize, windowWillEnterFullScreen)
        (windowDidEnterFullScreen, windowWillExitFullScreen)
        (windowDidExitFullScreen, toggleFullScreen, handleFS, setFSValue)
        (mouseEntered, mouseExited, menuDown, toolbarClicked, drawRect)
        (draggingEntered, performDragOperation, validRequestorForSendType)
        (setMiniwindowImage, constrainFrameRect, performZoom, zoom)
        (EmacsScroller_initFrame, EmacsScroller_setFrame)
        (EmacsScroller_dealloc, condemn, reprieve, judge)
        (resetCursorRects, setPosition, EmacsScroller_mouseDown)
        (EmacsScroller_mouseDragged, syms_of_nsterm): Use new trace system.

        * nsfns.m: Remove old NSTRACE macro.
        * nsfns.m (x_set_icon_name, ns_set_name, x_explicitly_set_name)
        (x_implicitly_set_name, x_set_title, ns_set_name_as_filename)
        (ns_implicitly_set_icon_type, x_set_icon_type): Use new trace system.

        * nsimage.m: Remove old NSTRACE macro.
        * nsimage.m (ns_image_from_XBM, ns_image_for_XPM)
        (ns_image_from_bitmap_file, ns_load_image): Use new trace system.

        * nsmenu.m: Remove old NSTRACE macro.
        * nsmenu.m (ns_update_menubar, ns_menu_show, ns_popup_dialog):
        Use new trace system.

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Ok, here comes a patch file for the "maximize" and "NSTRACE" rewrites, see
 > the file "emacs-commit-message.txt" for details. I would like you
 > (especially Keith, since Martin don't use OS X) to take a look at it before
 > I post in on emacs-devel and (unless people object) I commit it.

Great work!  For reasons I don't understand yet the patch also fixes my
biggest problem with GNUStep here, namely that an emacs -Q frame has two
tool bars initially.  Maximizing behavior is good though for some
reasons my maximized GNUStep frame (under xfce) still has no external
borders - if you have any ideas how to fix that please tell.  Making a
frame just full height works fine instead.

 > The patch below contains excluded code to maximize the frame the old way
 > using the system "zoom" function, and an excluded code section for a hybrid
 > maximize solution. Also, the code to restrict a frame to the screen height
 > is still present but excluded. Before I commit this to the archive I will
 > remove the excluded code, unless someone thinks that its worth while to
 > allow the user to configure this.

Let's leave the old code in for a couple of weeks - this way you keep
the changeset for the commit smaller.  If there are no complaints with
the new behavior remove it then.

 > You can enable the NSTRACE system by uncommenting a line in nsterm.h, see
 > comments for detail.

I shall test that soon and post my comments - if any.

 > In addition, I have included my own test file for frame maximization I
 > wrote to ensure that I didn't introduce any problems. Martin, if there are
 > anything in this you can use for your frame test file, feel free to use it.

Thanks for this as well.

There's one problem with the change log and the code comments: Please
stick to the rule to leave two empty spaces after each sentence.  Done
that please install your changes as soon as you have time to do so.

Now the only remaining issue we must fix before the release is that of
the non-shrinking echo area when toggling off the tool bar and the fact
that a frame keeps shrinking when turning off/on the tool bar.  I'll
look into that but if you have any ideas ...

Many thanks, martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 1513 bytes --]

Hi Anders

Four problems encountered when running your patch with GNUStep Emacs
under xfwm4:


(1) With emacs -Q doing

(set-frame-parameter (selected-frame) 'fullscreen 'maximized)

maximizes the frame but (a) the "restore size button" of the window
manager decoration is not enabled, (b) leaves the external borders
visible on screen and (c) has the task bar hide the echo area of the
Emacs frame, see screenshot-1.png.

(a) is probably due to a failed interaction with the window manager.
(b) is not critical because even with GTK, for example, I can still see
the top border on a maximized frame.  (c) is not really acceptable.


(2) With

emacs -Q --eval "(setq default-frame-alist '((fullscreen . maximized)))"

I see the same symptoms as with (1) however the initial frame also
contains two tool bar lines, see screenshot-2.png.  This is the same
problem I had earlier with emacs -Q and which now disappeared.


(3) With emacs -Q hitting the window manager key for maximizing the
window that has focus, the Emacs frame loses its external borders but
does not extend to the edges of the screen, see screenshot-3.png.  Not
grave but slightly annoying.  Note that here the "restore size button"
is enabled correctly.


(4) After doing

(set-frame-parameter (selected-frame) 'fullscreen 'fullwidth)

doing

(set-frame-parameter (selected-frame) 'fullscreen 'maximized)

does not change the frame size at all.  Same after making a fullheight
frame.  I suppose this also makes your ert test fail here.


martin


[-- Attachment #2: screenshot-1.png --]
[-- Type: image/png, Size: 44361 bytes --]

[-- Attachment #3: screenshot-2.png --]
[-- Type: image/png, Size: 36402 bytes --]

[-- Attachment #4: screenshot-3.png --]
[-- Type: image/png, Size: 26992 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 2615 bytes --]

Hi,

I have never used GNUStep, maybe I should try it out so that my patch work
there. Are there build instructions for this somewhere?

Anyway, I think the problem you are seeing is due to the fact that I have
replaced the code in "zoom" with custom code that simply resizes the frame.
On OS X there is nothing special happening when maximizing the frame -- the
outer frame (one pixel thick) is still there, no buttons should change
state etc.

One thing we should try is to check is the old zoom system would work
better in GNUStep after all (this is the first of the three different zoom
version in the code).

Also, it would be interesting to see the NSTRACE output of a session where
we go "fullwidth" and then "maximized" and compare it with what happens
under OS X -- if it still is a problem after changing the zoom method.

When it comes to the double tool bar, I have unfortunately no idea what the
problem is.

    -- Anders Lindgren

On Wed, Oct 21, 2015 at 6:07 PM, martin rudalics <rudalics@gmx.at> wrote:

> Hi Anders
>
> Four problems encountered when running your patch with GNUStep Emacs
> under xfwm4:
>
>
> (1) With emacs -Q doing
>
> (set-frame-parameter (selected-frame) 'fullscreen 'maximized)
>
> maximizes the frame but (a) the "restore size button" of the window
> manager decoration is not enabled, (b) leaves the external borders
> visible on screen and (c) has the task bar hide the echo area of the
> Emacs frame, see screenshot-1.png.
>
> (a) is probably due to a failed interaction with the window manager.
> (b) is not critical because even with GTK, for example, I can still see
> the top border on a maximized frame.  (c) is not really acceptable.
>
>
> (2) With
>
> emacs -Q --eval "(setq default-frame-alist '((fullscreen . maximized)))"
>
> I see the same symptoms as with (1) however the initial frame also
> contains two tool bar lines, see screenshot-2.png.  This is the same
> problem I had earlier with emacs -Q and which now disappeared.
>
>
> (3) With emacs -Q hitting the window manager key for maximizing the
> window that has focus, the Emacs frame loses its external borders but
> does not extend to the edges of the screen, see screenshot-3.png.  Not
> grave but slightly annoying.  Note that here the "restore size button"
> is enabled correctly.
>
>
> (4) After doing
>
> (set-frame-parameter (selected-frame) 'fullscreen 'fullwidth)
>
> doing
>
> (set-frame-parameter (selected-frame) 'fullscreen 'maximized)
>
> does not change the frame size at all.  Same after making a fullheight
> frame.  I suppose this also makes your ert test fail here.
>
>
> martin
>
>

[-- Attachment #2: Type: text/html, Size: 3371 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I have never used GNUStep, maybe I should try it out so that my patch work
 > there. Are there build instructions for this somewhere?

Don't bother.  Hardly anyone but me regularly builds on GNUStep.  And I
can't use it anyway - too many other problems.

 > Anyway, I think the problem you are seeing is due to the fact that I have
 > replaced the code in "zoom" with custom code that simply resizes the frame.
 > On OS X there is nothing special happening when maximizing the frame -- the
 > outer frame (one pixel thick) is still there, no buttons should change
 > state etc.

I suppose so.  Maybe I find a way to splice in some code tailored for
GNUStep.  But it will have low priority.

 > One thing we should try is to check is the old zoom system would work
 > better in GNUStep after all (this is the first of the three different zoom
 > version in the code).
 >
 > Also, it would be interesting to see the NSTRACE output of a session where
 > we go "fullwidth" and then "maximized" and compare it with what happens
 > under OS X -- if it still is a problem after changing the zoom method.

I'll give you some feedback when I'm back there.  One problem with
NSTRACE I have is that it clutters output with ns_update_window_begin
and ns_defined_color entries.  I now started to comment them out one by
one.  Maybe you could devise a method to display these optionally only.

 > When it comes to the double tool bar, I have unfortunately no idea what the
 > problem is.

It's a bad interaction between GNUStep and the window manager.  Maybe I
can find out more.

Meanwhile please install your changes.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 3672 bytes --]

Hi,

> Meanwhile please install your changes.

Done!


> Now the only remaining issue we must fix before the release is that of
> the non-shrinking echo area when toggling off the tool bar

I wasn't aware of this problem. Can you point me to where it's described.


> and the fact
> that a frame keeps shrinking when turning off/on the tool bar.  I'll
> look into that but if you have any ideas ...

I though this was by design. On NextStep, the toolbar is excluded from
`frame-pixel-height', so it makes sense that frame size change when enabled
and disabled. Besides, it's height typically isn't a multiple of the text
size, so the frame would need to be resized slightly anyway (unless
`frame-resize-pixelwise' is set).


There are other things that we would need to fix:

* Symbols in the fringe are inverted. I saw a patch for this on the
emacs-dev mailing list a few weeks ago but I haven't tried it out.

* When the cursor is rendered in the fringe, it's only drawn incorrectly.
(This problem might be related to the previous.)

What is the time frame for the Emacs 25 release? I would be happy to work
on this, but with my family situation, work will progress very, very slowly.


> I'll give you some feedback when I'm back there.  One problem with
> NSTRACE I have is that it clutters output with ns_update_window_begin
> and ns_defined_color entries.  I now started to comment them out one by
> one.  Maybe you could devise a method to display these optionally only.

I have thought about that as well. Currently, the package provides the
macros NSTRACE_WHEN and NSTRACE_UNLESS. I don't use then right now,
unfortunately they only silence the current function, not functions that
may be called by it (which is something that we would want). Hopefully, I
will be able to categorize the functions in such a way that the default
setting would silence some of the more frequently called functions.

/ Anders


On Thu, Oct 22, 2015 at 5:35 PM, martin rudalics <rudalics@gmx.at> wrote:

> > I have never used GNUStep, maybe I should try it out so that my patch
> work
> > there. Are there build instructions for this somewhere?
>
> Don't bother.  Hardly anyone but me regularly builds on GNUStep.  And I
> can't use it anyway - too many other problems.
>
> > Anyway, I think the problem you are seeing is due to the fact that I have
> > replaced the code in "zoom" with custom code that simply resizes the
> frame.
> > On OS X there is nothing special happening when maximizing the frame --
> the
> > outer frame (one pixel thick) is still there, no buttons should change
> > state etc.
>
> I suppose so.  Maybe I find a way to splice in some code tailored for
> GNUStep.  But it will have low priority.
>
> > One thing we should try is to check is the old zoom system would work
> > better in GNUStep after all (this is the first of the three different
> zoom
> > version in the code).
> >
> > Also, it would be interesting to see the NSTRACE output of a session
> where
> > we go "fullwidth" and then "maximized" and compare it with what happens
> > under OS X -- if it still is a problem after changing the zoom method.
>
> I'll give you some feedback when I'm back there.  One problem with
> NSTRACE I have is that it clutters output with ns_update_window_begin
> and ns_defined_color entries.  I now started to comment them out one by
> one.  Maybe you could devise a method to display these optionally only.
>
> > When it comes to the double tool bar, I have unfortunately no idea what
> the
> > problem is.
>
> It's a bad interaction between GNUStep and the window manager.  Maybe I
> can find out more.
>
> Meanwhile please install your changes.
>
> martin
>

[-- Attachment #2: Type: text/html, Size: 5915 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 4624 bytes --]

 >> Meanwhile please install your changes.
 >
 > Done!

Thanks!

 >> Now the only remaining issue we must fix before the release is that of
 >> the non-shrinking echo area when toggling off the tool bar
 >
 > I wasn't aware of this problem. Can you point me to where it's described.

Citing Keith's experiments on OSX:

 >>> (1) Toggle the tool bar off.  Does the overall frame height shrink or stay the same?
 >>>
 >>> A: Starting from Emacs -Q.  Using the mouse to toggle the toolbar off,
 >>> the height of the frame shrinks -- i.e., top and left remain the same,
 >>> and the bottom shrinks upward about one-half the height of the toolbar
 >>> that disappears.  The minibuffer / echo area increases in size to about
 >>> 3 lines of text, with just one line of text that reads: "menu-bar
 >>> options showhide showhide-tool-bar".
 >>>
 >>>
 >>> (2) Toggle the tool bar on again.  Does the overall frame height increase or stay the same?
 >>>
 >>> A: The frame height quickly shrinks and expands, but ultimately remains
 >>> the same size -- i.e., slightly less than when Emacs -Q first began its
 >>> GUI session.

I'll attach two screenshots.  The problem arose after Jan installed this
change:

diff --git a/src/ChangeLog b/src/ChangeLog
index 69da1c3..861ba91 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,8 @@
+2015-01-06  Jan Djärv  <jan.h.d@swipnet.se>
+
+    * nsterm.m (x_set_window_size): Call updateFrameSize to get real
+    size instead of using widht/height.  The frame may be constrained.
+
  2015-01-05  Paul Eggert  <eggert@cs.ucla.edu>

      * lisp.h (XSYMBOL): Parenthesize id in forward decl.
diff --git a/src/nsterm.m b/src/nsterm.m
index 2ccb7fe..bf3192b 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1404,15 +1404,8 @@ x_set_window_size (struct frame *f,
      [view setBoundsOrigin: origin];
    }

-  change_frame_size (f, width, height, 0, 1, 0, pixelwise);
-/*  SET_FRAME_GARBAGED (f); // this short-circuits expose call in drawRect */
-
-  mark_window_cursors_off (XWINDOW (f->root_window));
-  cancel_mouse_face (f);
-
+  [view updateFrameSize: NO];
    unblock_input ();
-
-  do_pending_window_change (0);
  }

where the crucial aspect is the removal of the change_frame_size call.
Note that in updateFrameSize we call change_frame_size only

    if (oldr != rows || oldc != cols || neww != oldw || newh != oldh)

which usually won't hold when removing the tool bar.  Maybe we should
make the change_frame_size call in updateFrameSize unconditional after
being called from update_frame_tool_bar.

 >> and the fact
 >> that a frame keeps shrinking when turning off/on the tool bar.  I'll
 >> look into that but if you have any ideas ...
 >
 > I though this was by design. On NextStep, the toolbar is excluded from
 > `frame-pixel-height', so it makes sense that frame size change when enabled
 > and disabled. Besides, it's height typically isn't a multiple of the text
 > size, so the frame would need to be resized slightly anyway (unless
 > `frame-resize-pixelwise' is set).

All true.  But the problem is that enabling the tool bar doesn't make
the overall frame height as large as it has been before disabling the
tool bar.  So eventually you might end up with a zero height frame.

 > There are other things that we would need to fix:
 >
 > * Symbols in the fringe are inverted. I saw a patch for this on the
 > emacs-dev mailing list a few weeks ago but I haven't tried it out.
 >
 > * When the cursor is rendered in the fringe, it's only drawn incorrectly.
 > (This problem might be related to the previous.)

I've seen these but can't do much about them.  It would be great if you
looked into these.

 > What is the time frame for the Emacs 25 release? I would be happy to work
 > on this, but with my family situation, work will progress very, very slowly.

Bug fixes are practically always accepted.  There's a short period
immediately before the release when only regressions wrt the previous
release may be fixed.  So you won't have to bother about the time frame.

 > I have thought about that as well. Currently, the package provides the
 > macros NSTRACE_WHEN and NSTRACE_UNLESS. I don't use then right now,
 > unfortunately they only silence the current function, not functions that
 > may be called by it (which is something that we would want). Hopefully, I
 > will be able to categorize the functions in such a way that the default
 > setting would silence some of the more frequently called functions.

That would be fine.

Thanks, martin

[-- Attachment #2: tool-bar-mode-on.png --]
[-- Type: image/png, Size: 19415 bytes --]

[-- Attachment #3: tool-bar-mode-off.png --]
[-- Type: image/png, Size: 12725 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 5074 bytes --]

Hi,

I can repeat the problem with the tool-bar here. I'll take a look at it.

I fact, it looks Jan was trying to avoid the fact that the frame could be
constrained. However, one of the changes I made was to remove the
constraining of frames -- so chances are that things would work if we would
revert to the old code.

Anyway, we should try to include as much as possible into test cases, to
ensure that future changes won't break things again.

I put the fringe problem on the "fix queue", but it may take some time
before I get to them.

    -- Anders



> Citing Keith's experiments on OSX:
>
> >>> (1) Toggle the tool bar off.  Does the overall frame height shrink or
> stay the same?
> >>>
> >>> A: Starting from Emacs -Q.  Using the mouse to toggle the toolbar off,
> >>> the height of the frame shrinks -- i.e., top and left remain the same,
> >>> and the bottom shrinks upward about one-half the height of the toolbar
> >>> that disappears.  The minibuffer / echo area increases in size to about
> >>> 3 lines of text, with just one line of text that reads: "menu-bar
> >>> options showhide showhide-tool-bar".
> >>>
> >>>
> >>> (2) Toggle the tool bar on again.  Does the overall frame height
> increase or stay the same?
> >>>
> >>> A: The frame height quickly shrinks and expands, but ultimately remains
> >>> the same size -- i.e., slightly less than when Emacs -Q first began its
> >>> GUI session.
>
> I'll attach two screenshots.  The problem arose after Jan installed this
> change:
>
>
> diff --git a/src/ChangeLog b/src/ChangeLog
> index 69da1c3..861ba91 100644
> --- a/src/ChangeLog
> +++ b/src/ChangeLog
> @@ -1,3 +1,8 @@
> +2015-01-06  Jan Djärv  <jan.h.d@swipnet.se>
> +
> +    * nsterm.m (x_set_window_size): Call updateFrameSize to get real
> +    size instead of using widht/height.  The frame may be constrained.
> +
>  2015-01-05  Paul Eggert  <eggert@cs.ucla.edu>
>
>      * lisp.h (XSYMBOL): Parenthesize id in forward decl.
> diff --git a/src/nsterm.m b/src/nsterm.m
> index 2ccb7fe..bf3192b 100644
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -1404,15 +1404,8 @@ x_set_window_size (struct frame *f,
>      [view setBoundsOrigin: origin];
>    }
>
> -  change_frame_size (f, width, height, 0, 1, 0, pixelwise);
> -/*  SET_FRAME_GARBAGED (f); // this short-circuits expose call in
> drawRect */
> -
> -  mark_window_cursors_off (XWINDOW (f->root_window));
> -  cancel_mouse_face (f);
> -
> +  [view updateFrameSize: NO];
>    unblock_input ();
> -
> -  do_pending_window_change (0);
>  }
>
> where the crucial aspect is the removal of the change_frame_size call.
> Note that in updateFrameSize we call change_frame_size only
>
>    if (oldr != rows || oldc != cols || neww != oldw || newh != oldh)
>
> which usually won't hold when removing the tool bar.  Maybe we should
> make the change_frame_size call in updateFrameSize unconditional after
> being called from update_frame_tool_bar.
>
> >> and the fact
> >> that a frame keeps shrinking when turning off/on the tool bar.  I'll
> >> look into that but if you have any ideas ...
> >
> > I though this was by design. On NextStep, the toolbar is excluded from
> > `frame-pixel-height', so it makes sense that frame size change when
> enabled
> > and disabled. Besides, it's height typically isn't a multiple of the text
> > size, so the frame would need to be resized slightly anyway (unless
> > `frame-resize-pixelwise' is set).
>
> All true.  But the problem is that enabling the tool bar doesn't make
> the overall frame height as large as it has been before disabling the
> tool bar.  So eventually you might end up with a zero height frame.
>
> > There are other things that we would need to fix:
> >
> > * Symbols in the fringe are inverted. I saw a patch for this on the
> > emacs-dev mailing list a few weeks ago but I haven't tried it out.
> >
> > * When the cursor is rendered in the fringe, it's only drawn incorrectly.
> > (This problem might be related to the previous.)
>
> I've seen these but can't do much about them.  It would be great if you
> looked into these.
>
> > What is the time frame for the Emacs 25 release? I would be happy to work
> > on this, but with my family situation, work will progress very, very
> slowly.
>
> Bug fixes are practically always accepted.  There's a short period
> immediately before the release when only regressions wrt the previous
> release may be fixed.  So you won't have to bother about the time frame.
>
> > I have thought about that as well. Currently, the package provides the
> > macros NSTRACE_WHEN and NSTRACE_UNLESS. I don't use then right now,
> > unfortunately they only silence the current function, not functions that
> > may be called by it (which is something that we would want). Hopefully, I
> > will be able to categorize the functions in such a way that the default
> > setting would silence some of the more frequently called functions.
>
> That would be fine.
>
> Thanks, martin
>

[-- Attachment #2: Type: text/html, Size: 6307 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Anyway, I think the problem you are seeing is due to the fact that I have
 > replaced the code in "zoom" with custom code that simply resizes the frame.
 > On OS X there is nothing special happening when maximizing the frame -- the
 > outer frame (one pixel thick) is still there, no buttons should change
         ^^^^^
You mean the outer border, I presume.  Here the border (some 5 pixels)
is probably removed by the window manager.  Don't ask me why and how.
But this and most other problems I reported existed already before your
change.

 > state etc.
 >
 > One thing we should try is to check is the old zoom system would work
 > better in GNUStep after all (this is the first of the three different zoom
 > version in the code).

I doubt it would help much.  One basic problem with GNUStep here is that
the workarea as returned by ‘display-monitor-attributes-list’ is the
same as the geometry returned by that function (are they the same on
OSX?).  Hence I see no way to have the GNUStep build recognize the
presence of my taskbar and not hide it when maximizing the frame.

 > Also, it would be interesting to see the NSTRACE output of a session where
 > we go "fullwidth" and then "maximized" and compare it with what happens
 > under OS X -- if it still is a problem after changing the zoom method.

Funnily I can't reproduce this currently, maybe some local change I made
is involved.

BTW

(set-frame-parameter nil 'fullscreen 'fullboth)

is broken here just as it was before your changes.  Does it work for you?

 > When it comes to the double tool bar, I have unfortunately no idea what the
 > problem is.

The crazy thing is that with the old build I got it for a normal initial
frame and now I get for a maximized initial frame ;-)

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 2424 bytes --]

Hi,

On Sat, Oct 24, 2015 at 8:57 PM, martin rudalics <rudalics@gmx.at> wrote:
>
> > Anyway, I think the problem you are seeing is due to the fact that I
have
> > replaced the code in "zoom" with custom code that simply resizes the
frame.
> > On OS X there is nothing special happening when maximizing the frame --
the
> > outer frame (one pixel thick) is still there, no buttons should change
>         ^^^^^
> You mean the outer border, I presume.  Here the border (some 5 pixels)
> is probably removed by the window manager.  Don't ask me why and how.
> But this and most other problems I reported existed already before your
> change.

Was the outer frame removed and the icon changed before my rewrites? If so,
try to use the old zoom system instead of the new.


> I doubt it would help much.  One basic problem with GNUStep here is that
> the workarea as returned by ‘display-monitor-attributes-list’ is the
> same as the geometry returned by that function (are they the same on
> OSX?).  Hence I see no way to have the GNUStep build recognize the
> presence of my taskbar and not hide it when maximizing the frame.

You can check if the NSScreen "frame" and "visibleFrame" would return
different frame. In "ns_menu_bar_height" I use this. Maybe it can be used
under GNUStep to find the height of the taskbar?


> BTW
>
> (set-frame-parameter nil 'fullscreen 'fullboth)
>
> is broken here just as it was before your changes.  Does it work for you?

Yes, it enters the real fullscreen mode.

Does it work if you set `ns-use-native-fullscreen' to nil?


> > When it comes to the double tool bar, I have unfortunately no idea what
the
> > problem is.
>
> The crazy thing is that with the old build I got it for a normal initial
> frame and now I get for a maximized initial frame ;-)

Bizzarre... I would check "update_frame_tool_bar" in nsmenu.m or
initFrameFromEmacs in nsterm.m to see if any of those allocate more than
one EmacsToolbar.


I have located the toolbar error. When "setVisible" is called, OS X starts
an animation. When this animation runs, windowWasResized tried to keep up
and update rows and columns. On the way it got lost and the end result was
a bad "row" could. When simply doing nothing when the animation runs,
everything work OK. Hopefully, I will be able to push the end result within
the next couple of days.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 2844 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1.1: Type: text/plain, Size: 2930 bytes --]

Hi,

here is a patch to fix the problems with tool-bar-mode, please try it out.

One thing that I have noticed lately is that Emacs often crash when
started. I managed to get a call stack by running gdb, but it doesn't mean
much to me. Do any of you have an idea what is going on?

    -- Anders


On Sat, Oct 24, 2015 at 11:43 PM, Anders Lindgren <andlind@gmail.com> wrote:

> Hi,
>
> On Sat, Oct 24, 2015 at 8:57 PM, martin rudalics <rudalics@gmx.at> wrote:
> >
> > > Anyway, I think the problem you are seeing is due to the fact that I
> have
> > > replaced the code in "zoom" with custom code that simply resizes the
> frame.
> > > On OS X there is nothing special happening when maximizing the frame
> -- the
> > > outer frame (one pixel thick) is still there, no buttons should change
> >         ^^^^^
> > You mean the outer border, I presume.  Here the border (some 5 pixels)
> > is probably removed by the window manager.  Don't ask me why and how.
> > But this and most other problems I reported existed already before your
> > change.
>
> Was the outer frame removed and the icon changed before my rewrites? If
> so, try to use the old zoom system instead of the new.
>
>
> > I doubt it would help much.  One basic problem with GNUStep here is that
> > the workarea as returned by ‘display-monitor-attributes-list’ is the
> > same as the geometry returned by that function (are they the same on
> > OSX?).  Hence I see no way to have the GNUStep build recognize the
> > presence of my taskbar and not hide it when maximizing the frame.
>
> You can check if the NSScreen "frame" and "visibleFrame" would return
> different frame. In "ns_menu_bar_height" I use this. Maybe it can be used
> under GNUStep to find the height of the taskbar?
>
>
> > BTW
> >
> > (set-frame-parameter nil 'fullscreen 'fullboth)
> >
> > is broken here just as it was before your changes.  Does it work for you?
>
> Yes, it enters the real fullscreen mode.
>
> Does it work if you set `ns-use-native-fullscreen' to nil?
>
>
> > > When it comes to the double tool bar, I have unfortunately no idea
> what the
> > > problem is.
> >
> > The crazy thing is that with the old build I got it for a normal initial
> > frame and now I get for a maximized initial frame ;-)
>
> Bizzarre... I would check "update_frame_tool_bar" in nsmenu.m or
> initFrameFromEmacs in nsterm.m to see if any of those allocate more than
> one EmacsToolbar.
>
>
> I have located the toolbar error. When "setVisible" is called, OS X starts
> an animation. When this animation runs, windowWasResized tried to keep up
> and update rows and columns. On the way it got lost and the end result was
> a bad "row" could. When simply doing nothing when the animation runs,
> everything work OK. Hopefully, I will be able to push the end result within
> the next couple of days.
>
>     -- Anders
>
>

[-- Attachment #1.2: Type: text/html, Size: 3765 bytes --]

[-- Attachment #2: toolbar.diff --]
[-- Type: text/plain, Size: 7910 bytes --]

diff --git a/src/nsfns.m b/src/nsfns.m
index 1ed3e23..c243444 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -1298,6 +1298,8 @@ This function is an internal primitive--use `make-frame' instead.  */)
      = [NSCursor arrowCursor];
   f->output_data.ns->current_pointer = f->output_data.ns->text_cursor;
 
+  f->output_data.ns->in_animation = NO;
+
   [[EmacsView alloc] initFrameFromEmacs: f];
 
   x_icon (f, parms);
diff --git a/src/nsmenu.m b/src/nsmenu.m
index 2ef1223..ddc5dc2 100644
--- a/src/nsmenu.m
+++ b/src/nsmenu.m
@@ -998,10 +998,20 @@ free_frame_tool_bar (struct frame *f)
    -------------------------------------------------------------------------- */
 {
   EmacsView *view = FRAME_NS_VIEW (f);
+
+  NSTRACE ("free_frame_tool_bar");
+
   block_input ();
   view->wait_for_tool_bar = NO;
-  [[view toolbar] setVisible: NO];
+
   FRAME_TOOLBAR_HEIGHT (f) = 0;
+
+  /* Note: This trigger an animation, which calls windowDidResize
+     repeatedly. */
+  f->output_data.ns->in_animation = 1;
+  [[view toolbar] setVisible: NO];
+  f->output_data.ns->in_animation = 0;
+
   unblock_input ();
 }
 
@@ -1017,6 +1027,8 @@ update_frame_tool_bar (struct frame *f)
   EmacsToolbar *toolbar = [view toolbar];
   int oldh;
 
+  NSTRACE ("update_frame_tool_bar");
+
   if (view == nil || toolbar == nil) return;
   block_input ();
 
@@ -1096,7 +1108,11 @@ update_frame_tool_bar (struct frame *f)
     }
 
   if (![toolbar isVisible])
+    {
+      f->output_data.ns->in_animation = 1;
       [toolbar setVisible: YES];
+      f->output_data.ns->in_animation = 0;
+    }
 
 #ifdef NS_IMPL_COCOA
   if ([toolbar changed])
@@ -1150,6 +1166,8 @@ update_frame_tool_bar (struct frame *f)
 
 - initForView: (EmacsView *)view withIdentifier: (NSString *)identifier
 {
+  NSTRACE ("[EmacsToolbar initForView: withIdentifier:]");
+
   self = [super initWithIdentifier: identifier];
   emacsView = view;
   [self setDisplayMode: NSToolbarDisplayModeIconOnly];
@@ -1164,6 +1182,8 @@ update_frame_tool_bar (struct frame *f)
 
 - (void)dealloc
 {
+  NSTRACE ("[EmacsToolbar dealloc]");
+
   [prevIdentifiers release];
   [activeIdentifiers release];
   [identifierToItem release];
@@ -1172,6 +1192,8 @@ update_frame_tool_bar (struct frame *f)
 
 - (void) clearActive
 {
+  NSTRACE ("[EmacsToolbar clearActive]");
+
   [prevIdentifiers release];
   prevIdentifiers = [activeIdentifiers copy];
   [activeIdentifiers removeAllObjects];
@@ -1181,6 +1203,8 @@ update_frame_tool_bar (struct frame *f)
 
 - (void) clearAll
 {
+  NSTRACE ("[EmacsToolbar clearAll]");
+
   [self clearActive];
   while ([[self items] count] > 0)
     [self removeItemAtIndex: 0];
@@ -1188,6 +1212,8 @@ update_frame_tool_bar (struct frame *f)
 
 - (BOOL) changed
 {
+  NSTRACE ("[EmacsToolbar changed]");
+
   return [activeIdentifiers isEqualToArray: prevIdentifiers] &&
     enablement == prevEnablement ? NO : YES;
 }
@@ -1198,6 +1224,8 @@ update_frame_tool_bar (struct frame *f)
                         helpText: (const char *)help
                          enabled: (BOOL)enabled
 {
+  NSTRACE ("[EmacsToolbar addDisplayItemWithImage: ...]");
+
   /* 1) come up w/identifier */
   NSString *identifier
     = [NSString stringWithFormat: @"%lu", (unsigned long)[img hash]];
@@ -1231,6 +1259,7 @@ update_frame_tool_bar (struct frame *f)
    all items to enabled state (for some reason). */
 - (void)validateVisibleItems
 {
+  NSTRACE ("[EmacsToolbar validateVisibleItems]");
 }
 
 
@@ -1240,12 +1269,16 @@ update_frame_tool_bar (struct frame *f)
       itemForItemIdentifier: (NSString *)itemIdentifier
   willBeInsertedIntoToolbar: (BOOL)flag
 {
+  NSTRACE ("[EmacsToolbar toolbar: ...]");
+
   /* look up NSToolbarItem by identifier and return... */
   return [identifierToItem objectForKey: itemIdentifier];
 }
 
 - (NSArray *)toolbarDefaultItemIdentifiers: (NSToolbar *)toolbar
 {
+  NSTRACE ("[EmacsToolbar toolbarDefaultItemIdentifiers:]");
+
   /* return entire set.. */
   return activeIdentifiers;
 }
@@ -1253,6 +1286,8 @@ update_frame_tool_bar (struct frame *f)
 /* for configuration palette (not yet supported) */
 - (NSArray *)toolbarAllowedItemIdentifiers: (NSToolbar *)toolbar
 {
+  NSTRACE ("[EmacsToolbar toolbarAllowedItemIdentifiers:]");
+
   /* return entire set... */
   return activeIdentifiers;
   //return [identifierToItem allKeys];
diff --git a/src/nsterm.h b/src/nsterm.h
index 8d52dc6..3fb8cfc 100644
--- a/src/nsterm.h
+++ b/src/nsterm.h
@@ -65,9 +65,12 @@ typedef float EmacsCGFloat;
 
    ========================================================================== */
 
-/* Uncomment the following line to enable trace. */
+/* Uncomment the following line to enable trace.
 
-/* #define NSTRACE_ENABLED 1 */
+   Hint: keep the trailing whitespace -- the version control system
+   will reject accidental commits. */
+
+/* #define NSTRACE_ENABLED 1          */
 
 
 /* Print a call tree containing all annotated functions.
@@ -913,6 +916,9 @@ struct ns_output
 
   /* Non-zero if we are zooming (maximizing) the frame.  */
   int zooming;
+
+  /* Non-zero if we are doing an animation, e.g. toggling the tool bar. */
+  int in_animation;
 };
 
 /* this dummy decl needed to support TTYs */
diff --git a/src/nsterm.m b/src/nsterm.m
index e5eb8ca..ba205f5 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1497,7 +1497,7 @@ x_set_window_size (struct frame *f,
   if (view == nil)
     return;
 
-  NSTRACE_RECT ("input", wr);
+  NSTRACE_RECT ("current", wr);
 
 /*fprintf (stderr, "\tsetWindowSize: %d x %d, pixelwise %d, font size %d x %d\n", width, height, pixelwise, FRAME_COLUMN_WIDTH (f), FRAME_LINE_HEIGHT (f));*/
 
@@ -1559,7 +1559,6 @@ x_set_window_size (struct frame *f,
 	   make_number (FRAME_NS_TITLEBAR_HEIGHT (f)),
 	   make_number (FRAME_TOOLBAR_HEIGHT (f))));
 
-  [view setRows: rows andColumns: cols];
   NSTRACE_RECT ("setFrame", wr);
   [window setFrame: wr display: YES];
 
@@ -6142,6 +6141,8 @@ not_in_argv (NSString *arg)
   NSTRACE ("updateFrameSize");
   NSTRACE_SIZE ("Original size", NSMakeSize (oldw, oldh));
   NSTRACE_RECT ("Original frame", wr);
+  NSTRACE_MSG  ("Original columns: %d", cols);
+  NSTRACE_MSG  ("Original rows: %d", rows);
 
   if (! [self isFullscreen])
     {
@@ -6158,13 +6159,19 @@ not_in_argv (NSString *arg)
   if (wait_for_tool_bar)
     {
       if (FRAME_TOOLBAR_HEIGHT (emacsframe) == 0)
-        return;
+        {
+          NSTRACE_MSG ("Waiting for toolbar");
+          return;
+        }
       wait_for_tool_bar = NO;
     }
 
   neww = (int)wr.size.width - emacsframe->border_width;
   newh = (int)wr.size.height - extra;
 
+  NSTRACE_SIZE ("New size", NSMakeSize (neww, newh));
+  NSTRACE_MSG ("tool_bar_height: %d", emacsframe->tool_bar_height);
+
   cols = FRAME_PIXEL_WIDTH_TO_TEXT_COLS (emacsframe, neww);
   rows = FRAME_PIXEL_HEIGHT_TO_TEXT_LINES (emacsframe, newh);
 
@@ -6174,6 +6181,9 @@ not_in_argv (NSString *arg)
   if (rows < MINHEIGHT)
     rows = MINHEIGHT;
 
+  NSTRACE_MSG  ("New columns: %d", cols);
+  NSTRACE_MSG  ("New rows: %d", rows);
+
   if (oldr != rows || oldc != cols || neww != oldw || newh != oldh)
     {
       NSView *view = FRAME_NS_VIEW (emacsframe);
@@ -6191,6 +6201,10 @@ not_in_argv (NSString *arg)
       [view setFrame: wr];
       [self windowDidMove:nil];   // Update top/left.
     }
+  else
+    {
+      NSTRACE_MSG ("No change");
+    }
 }
 
 - (NSSize)windowWillResize: (NSWindow *)sender toSize: (NSSize)frameSize
@@ -6299,6 +6313,12 @@ not_in_argv (NSString *arg)
 {
   NSTRACE ("windowDidResize");
 
+  if (emacsframe->output_data.ns->in_animation)
+    {
+      NSTRACE_MSG ("Ignored (in animation)");
+      return;
+    }
+
   if (! [self fsIsNative])
     {
       NSWindow *theWindow = [notification object];
@@ -7396,6 +7416,7 @@ not_in_argv (NSString *arg)
 
 - (void) setRows: (int) r andColumns: (int) c
 {
+  NSTRACE ("[EmacsView setRows:%d andColumns:%d]", r, c);
   rows = r;
   cols = c;
 }

[-- Attachment #3: emacs-commit-messages2.txt --]
[-- Type: text/plain, Size: 744 bytes --]

Fix incorrect NextStep tool-bar-mode -- wrong number of rows in frame.

* nsterm.h (struct ns_output): New flag, in_animation.
* nsfns.m (Fx_create_frame): Initialize in_animation flag.
* nsmenu.m (free_frame_tool_bar, update_frame_tool_bar): Set
in_animation flag around call to "setVisible". Set new tool bar
height before call to setVisible.
* nsterm.m (x_set_window_size): Don't call [view setRow:
andColumns:] as this fools the subsequent call to updateFrameSize
from performing the real resize.
(windowDidResize): Don't update anything when in_animation is
non-zero.

Trace output.

* nsmenu.m (free_frame_tool_bar, update_frame_tool_bar)
(EmacsToolbar):
* nsterm.m (x_set_window_size, updateFrameSize)
([EmacsView setRows: andColumns:])

[-- Attachment #4: start-crash.txt --]
[-- Type: text/plain, Size: 4970 bytes --]

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000010
0x00007fff8ae4be65 in (anonymous namespace)::AutoreleasePoolPage::pop ()
(gdb) bt
#0  0x00007fff8ae4be65 in (anonymous namespace)::AutoreleasePoolPage::pop ()
#1  0x00007fff8b1c16f2 in _CFAutoreleasePoolPop ()
#2  0x00007fff8f6a2832 in -[NSAutoreleasePool drain] ()
#3  0x00007fff867ddbc1 in -[NSApplication run] ()
#4  0x00000001001a27a8 in -[EmacsApp run] (
    self=<value temporarily unavailable, due to optimizations>, 
    _cmd=<value temporarily unavailable, due to optimizations>)
    at nsterm.m:4827
#5  0x00000001001a250b in ns_term_init (
    display_name=<value temporarily unavailable, due to optimizations>)
    at nsterm.m:4759
#6  0x00000001001b5da7 in Fx_open_connection (display=4375708556, 
    resource_string=0, must_succeed=40416) at nsfns.m:1844
#7  0x0000000100137cfe in Ffuncall (
    nargs=<value temporarily unavailable, due to optimizations>, 
    args=<value temporarily unavailable, due to optimizations>) at eval.c:2657
#8  0x000000010016fca4 in exec_byte_code (
    bytestr=<value temporarily unavailable, due to optimizations>, 
    vector=4429459997, 
    maxdepth=<value temporarily unavailable, due to optimizations>, 
    args_template=<value temporarily unavailable, due to optimizations>, 
    nargs=<value temporarily unavailable, due to optimizations>, 
    args=<value temporarily unavailable, due to optimizations>)
    at bytecode.c:880
#9  0x0000000100137b4f in Ffuncall (
    nargs=<value temporarily unavailable, due to optimizations>, 
    args=<value temporarily unavailable, due to optimizations>) at eval.c:2699
#10 0x0000000100137648 in Fapply (
    nargs=<value temporarily unavailable, due to optimizations>, 
    args=<value temporarily unavailable, due to optimizations>) at eval.c:2231
#11 0x0000000100137bea in Ffuncall (
    nargs=<value temporarily unavailable, due to optimizations>, 
    args=<value temporarily unavailable, due to optimizations>) at eval.c:2630
#12 0x000000010016fca4 in exec_byte_code (
    bytestr=<value temporarily unavailable, due to optimizations>, 
    vector=4496538477, 
    maxdepth=<value temporarily unavailable, due to optimizations>, 
    args_template=<value temporarily unavailable, due to optimizations>, 
    nargs=<value temporarily unavailable, due to optimizations>, 
    args=<value temporarily unavailable, due to optimizations>)
    at bytecode.c:880
#13 0x0000000100137b4f in Ffuncall (
    nargs=<value temporarily unavailable, due to optimizations>, 
    args=<value temporarily unavailable, due to optimizations>) at eval.c:2699
#14 0x000000010016fca4 in exec_byte_code (
    bytestr=<value temporarily unavailable, due to optimizations>, 
    vector=4298365205, 
    maxdepth=<value temporarily unavailable, due to optimizations>, 
    args_template=<value temporarily unavailable, due to optimizations>, 
    nargs=<value temporarily unavailable, due to optimizations>, 
    args=<value temporarily unavailable, due to optimizations>)
    at bytecode.c:880
#15 0x0000000100137b4f in Ffuncall (
    nargs=<value temporarily unavailable, due to optimizations>, 
    args=<value temporarily unavailable, due to optimizations>) at eval.c:2699
#16 0x000000010016fca4 in exec_byte_code (
    bytestr=<value temporarily unavailable, due to optimizations>, 
    vector=4298361181, 
    maxdepth=<value temporarily unavailable, due to optimizations>, 
    args_template=<value temporarily unavailable, due to optimizations>, 
    nargs=<value temporarily unavailable, due to optimizations>, 
    args=<value temporarily unavailable, due to optimizations>)
    at bytecode.c:880
#17 0x0000000100137540 in apply_lambda (fun=4298361101, 
    args=<value temporarily unavailable, due to optimizations>, 
    count=<value temporarily unavailable, due to optimizations>) at eval.c:2751
#18 0x000000010013445d in eval_sub (
    form=<value temporarily unavailable, due to optimizations>) at eval.c:2168
#19 0x0000000100137398 in Feval (form=4462858579, 
    lexical=<value temporarily unavailable, due to optimizations>)
    at eval.c:1953
#20 0x00000001001366b7 in internal_condition_case (
    bfun=0x1000cc840 <top_level_2>, 
    handlers=<value temporarily unavailable, due to optimizations>, 
    hfun=<value temporarily unavailable, due to optimizations>) at eval.c:1309
#21 0x00000001000cc80d in top_level_1 (
    ignore=<value temporarily unavailable, due to optimizations>)
    at keyboard.c:1103
#22 0x00000001001360ef in internal_catch (
    tag=<value temporarily unavailable, due to optimizations>, 
    func=0x1000cc7e0 <top_level_1>, arg=0) at eval.c:1073
#23 0x00000001000bb0ff in command_loop () at keyboard.c:1064
#24 0x00000001000bb029 in recursive_edit_1 () at keyboard.c:671
#25 0x00000001000bb24c in Frecursive_edit () at keyboard.c:742
#26 0x00000001000b9f34 in main (argc=Cannot access memory at address 0x0
) at emacs.c:1644

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 3218 bytes --]

>
> One thing that I have noticed lately is that Emacs often crash when
> started. I managed to get a call stack by running gdb, but it doesn't mean
> much to me. Do any of you have an idea what is going on?
>

I think I have solved this one. Input events started coming in before the
init code had finished. By surrounding it by a block_input() and
unblock_input() pair it seems to work better. I will run it for a couple of
days and, if the problems have gone away, I will commit it.

    -- Anders



> On Sat, Oct 24, 2015 at 11:43 PM, Anders Lindgren <andlind@gmail.com>
> wrote:
>
>> Hi,
>>
>> On Sat, Oct 24, 2015 at 8:57 PM, martin rudalics <rudalics@gmx.at> wrote:
>> >
>> > > Anyway, I think the problem you are seeing is due to the fact that I
>> have
>> > > replaced the code in "zoom" with custom code that simply resizes the
>> frame.
>> > > On OS X there is nothing special happening when maximizing the frame
>> -- the
>> > > outer frame (one pixel thick) is still there, no buttons should change
>> >         ^^^^^
>> > You mean the outer border, I presume.  Here the border (some 5 pixels)
>> > is probably removed by the window manager.  Don't ask me why and how.
>> > But this and most other problems I reported existed already before your
>> > change.
>>
>> Was the outer frame removed and the icon changed before my rewrites? If
>> so, try to use the old zoom system instead of the new.
>>
>>
>> > I doubt it would help much.  One basic problem with GNUStep here is that
>> > the workarea as returned by ‘display-monitor-attributes-list’ is the
>> > same as the geometry returned by that function (are they the same on
>> > OSX?).  Hence I see no way to have the GNUStep build recognize the
>> > presence of my taskbar and not hide it when maximizing the frame.
>>
>> You can check if the NSScreen "frame" and "visibleFrame" would return
>> different frame. In "ns_menu_bar_height" I use this. Maybe it can be used
>> under GNUStep to find the height of the taskbar?
>>
>>
>> > BTW
>> >
>> > (set-frame-parameter nil 'fullscreen 'fullboth)
>> >
>> > is broken here just as it was before your changes.  Does it work for
>> you?
>>
>> Yes, it enters the real fullscreen mode.
>>
>> Does it work if you set `ns-use-native-fullscreen' to nil?
>>
>>
>> > > When it comes to the double tool bar, I have unfortunately no idea
>> what the
>> > > problem is.
>> >
>> > The crazy thing is that with the old build I got it for a normal initial
>> > frame and now I get for a maximized initial frame ;-)
>>
>> Bizzarre... I would check "update_frame_tool_bar" in nsmenu.m or
>> initFrameFromEmacs in nsterm.m to see if any of those allocate more than
>> one EmacsToolbar.
>>
>>
>> I have located the toolbar error. When "setVisible" is called, OS X
>> starts an animation. When this animation runs, windowWasResized tried to
>> keep up and update rows and columns. On the way it got lost and the end
>> result was a bad "row" could. When simply doing nothing when the animation
>> runs, everything work OK. Hopefully, I will be able to push the end result
>> within the next couple of days.
>>
>>     -- Anders
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 4272 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I think I have solved this one. Input events started coming in before the
 > init code had finished. By surrounding it by a block_input() and
 > unblock_input() pair it seems to work better. I will run it for a couple of
 > days and, if the problems have gone away, I will commit it.

Would that help?  I earlier mentioned that here

"on GNUStep making the
toolbar visible in update_frame_tool_bar immediately provokes a call of
windowDidResize which calls updateFrameSize with a not yet updated
toolbar height some time before updateFrameSize gets properly called at
the end of update_frame_tool_bar."

Now update_frame_tool_bar has

   block_input ();
...
   if (![toolbar isVisible])
       [toolbar setVisible: YES];
...
   unblock_input ();

and the windowDidResize gets through nevertheless.

martin


BTW, can you reproduce the scenario of bug#21770?

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1402 bytes --]

On Wed, Oct 28, 2015 at 10:55 AM, martin rudalics <rudalics@gmx.at> wrote:

> > I think I have solved this one. Input events started coming in before the
> > init code had finished. By surrounding it by a block_input() and
> > unblock_input() pair it seems to work better. I will run it for a couple
> of
> > days and, if the problems have gone away, I will commit it.
>
> Would that help?


Yes, it helped, but for a totally different problem, the startup crash.



>   I earlier mentioned that here
>
> "on GNUStep making the
> toolbar visible in update_frame_tool_bar immediately provokes a call of
> windowDidResize which calls updateFrameSize with a not yet updated
> toolbar height some time before updateFrameSize gets properly called at
> the end of update_frame_tool_bar."
>
> Now update_frame_tool_bar has
>
>   block_input ();
> ...
>   if (![toolbar isVisible])
>       [toolbar setVisible: YES];
> ...
>   unblock_input ();
>
> and the windowDidResize gets through nevertheless.
>

I have fixed this by introducing a flag, in_animation, which I set
temporarily around calls to setVisible. It makes updateFrameSize return
immediately. Problem solved.


BTW, can you reproduce the scenario of bug#21770?
>

Yes.

I will take a look at fringe-related problems next. I might be able to take
a look at this after that.


I just pushed the toolbar fix and the startup crash fix.

     -- Anders

[-- Attachment #2: Type: text/html, Size: 2250 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I will take a look at fringe-related problems next.

That inversion effect is pretty distracting, indeed.

 > I might be able to take
 > a look at this after that.
 >
 >
 > I just pushed the toolbar fix and the startup crash fix.

Fine.  Keith, can you test it?  Just turn off/on the tool bar once with
a normal and a maximized frame.

Eventually it would be to nice to have adding/removing the tool bar obey
‘frame-inhibit-implied-resize’ (it currently works OK for the maximized
frame so the fix shouldn't be too hard).

Thanks, martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1.1: Type: text/plain, Size: 2251 bytes --]

Hi,

> I will take a look at fringe-related problems next.
>
> That inversion effect is pretty distracting, indeed.


I have attached a fix for the fringe issue. The images were reversed, the
background was not transparent (which the rendering code assumed it was),
and finally, all images were mirror flipped left-to-right...

I have attached a patch for this, please try it out. If possible, try to
check if this causes some other image-related problems which I haven't
thought of.

(I will clean up the trace code before I commit it.)


> I might be able to take
> > a look at this after that.
> >
> >
> > I just pushed the toolbar fix and the startup crash fix.
>
> Fine.  Keith, can you test it?  Just turn off/on the tool bar once with
> a normal and a maximized frame.
>
> Eventually it would be to nice to have adding/removing the tool bar obey
> ‘frame-inhibit-implied-resize’ (it currently works OK for the maximized
> frame so the fix shouldn't be too hard).
>

I don't think it really worked for fullheight frames. When enabling the
tool bar in a maximized frame it looked OK at first glance. However, below
the screen, the window stretched out about three text lines, but due to the
bug Keith reported, the text grid was restricted with the same amount. The
effect was that it only looked like it worked.

Now, when enabling tool-bar mode in a fullheight frames, after Keiths bug
was fixed, the frame stretches below the screen. It's a bit unfortunate,
but it will be a lot of work to do anything about it -- given how the tool
bar is currently implemented.


Keith wrote:

> The first time I turned off the toolbar from a maximized frame, the frame
shrunk a little.  When I turned the toolbar back on again, the frame did
not return to a maximized position -- i.e., it remained a few pixels shy of
full-screen in terms of height.

I can see the same effect here. I have only tried this with a fullheight
frame, in which case it worked. I will take a look at it and try to figure
out what the difference between the fullheight and maximized cases.

    -- Anders

Ps. I will be away over the weekend -- hopefully I will be able to answer
mail but not do any Emacs core work.

[-- Attachment #1.2: Type: text/html, Size: 3497 bytes --]

[-- Attachment #2: emacs-commit-messages-fringe.txt --]
[-- Type: text/plain, Size: 546 bytes --]

Render fringe bitmaps correctly on NextStep.

The fringe bitmaps were inverted, the background was not
transparent, and the image data was flipped bitwise left-right.

* nsimage.m ([EmacsImage initFromXBM:width:height:fg:bg:]): When
both background and foreground colors are 0, set the background
alpha channel to 0 (making the background transparent).  When
copying the image data, do this from the most significant bit
(leftmost) to the least (rightmost), to avoid mirroring it.
* nsterm.m (ns_draw_fringe_bitmap): Don't invert the image bits.

[-- Attachment #3: fringe.diff --]
[-- Type: text/plain, Size: 2497 bytes --]

diff --git a/src/nsimage.m b/src/nsimage.m
index e76a7db..a2e0618 100644
--- a/src/nsimage.m
+++ b/src/nsimage.m
@@ -206,6 +206,7 @@ ns_set_alpha (void *img, int x, int y, unsigned char a)
            fg: (unsigned long)fg bg: (unsigned long)bg
 {
   unsigned char *planes[5];
+  unsigned char bg_alpha = 0xff;
 
   [self initWithSize: NSMakeSize (w, h)];
 
@@ -219,7 +220,10 @@ ns_set_alpha (void *img, int x, int y, unsigned char a)
   [bmRep getBitmapDataPlanes: planes];
 
   if (fg == 0 && bg == 0)
-    bg = 0xffffff;
+    {
+      bg = 0xffffff;
+      bg_alpha = 0;
+    }
 
   {
     /* pull bits out to set the (bytewise) alpha mask */
@@ -244,21 +248,22 @@ ns_set_alpha (void *img, int x, int y, unsigned char a)
           c = *s++;
           for (k = 0; i < w && k < 8; ++k, ++i)
             {
-              *alpha++ = 0xff;
-              if (c & 1)
+              if (c & 0x80)
                 {
                   *rr++ = fgr;
                   *gg++ = fgg;
                   *bb++ = fgb;
+                  *alpha++ = 0xff;
                 }
               else
                 {
                   *rr++ = bgr;
                   *gg++ = bgg;
                   *bb++ = bgb;
+                  *alpha++ = bg_alpha;
                 }
               idx++;
-              c >>= 1;
+              c <<= 1;
             }
         }
   }
diff --git a/src/nsterm.h b/src/nsterm.h
index 3fb8cfc..2e3076d 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -2461,6 +2461,10 @@ ns_draw_fringe_bitmap (struct window *w, struct glyph_row *row,
   static EmacsImage **bimgs = NULL;
   static int nBimgs = 0;
 
+  // NSTRACE ("ns_draw_fringe_bitmap");
+  // NSTRACE_MSG ("which:%d cursor:%d overlay:%d",
+  //              p->which, p->cursor_p, p->overlay_p);
+
   /* grow bimgs if needed */
   if (nBimgs < max_used_fringe_bitmap)
     {
@@ -2499,13 +2503,15 @@ ns_draw_fringe_bitmap (struct window *w, struct glyph_row *row,
           unsigned char *cbits = xmalloc (len);
 
           for (i = 0; i < len; i++)
-            cbits[i] = ~(bits[i] & 0xff);
+            cbits[i] = bits[i];
           img = [[EmacsImage alloc] initFromXBM: cbits width: 8 height: p->h
                                              fg: 0 bg: 0];
           bimgs[p->which - 1] = img;
           xfree (cbits);
         }
 
+      // NSTRACE_RECT ("r", r);
+
       NSRectClip (r);
       /* Since we composite the bitmap instead of just blitting it, we need
          to erase the whole background. */

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > I have attached a fix for the fringe issue. The images were reversed, the
 > background was not transparent (which the rendering code assumed it was),
 > and finally, all images were mirror flipped left-to-right...
 >
 > I have attached a patch for this, please try it out. If possible, try to
 > check if this causes some other image-related problems which I haven't
 > thought of.

Thanks.  Continuation glyphs now look good.  Here on GNUStep the left
fringe occasionally gets clipped, probably by the adjacent scroll bar.
Maybe some "fringe sizes should be multiples of character sizes" issue I
haven't been able to trace yet.  In any case please check in your fix.
Please mention the bug number in ChangeLog and commit message and inform
the OP, possibly closing the bug (I think it's Bug#21301).

Keith - yet another fix you should test ;-)

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > Thanks.  Continuation glyphs now look good.  Here on GNUStep the left
 > fringe occasionally gets clipped, probably by the adjacent scroll bar.
 > Maybe some "fringe sizes should be multiples of character sizes" issue I
 > haven't been able to trace yet.

... which might be related to issues we discussed earlier when you
reported bug#16856.  Did you ever look into that again?

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]

Hi!

I'm glad that it works, I will check in the changes, hopefully, later today.

When it comes to the ChangeLog -- I noticed that it hadn't been updated for
a while and assumed that it is now automatically populated from the git
commit messages -- is this correct, or should I also manually update it?

Also, is there a major mode like "change-log-mode" that would work with git
commits, i.e. where text is formatted like a ChangeLog entry but without
requiring the text to be indented?


... which might be related to issues we discussed earlier when you
> reported bug#16856.  Did you ever look into that again?


No, at the time I didn't have the time and energy to look into it. In
addition, I found that when I resized the frame pixel-perfect (using my
multicolumn package), the problem didn't occur and I was happy with that.

I can see if the problem is still present, and if not, we can close that
issue.

When it comes to the bug tracker -- can I filter the bug reports so that I
can only see the ones related to the NextStep port?

    -- Anders

[-- Attachment #2: Type: text/html, Size: 1509 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > When it comes to the ChangeLog -- I noticed that it hadn't been updated for
 > a while

"The" ChangeLog is now in the source directory of the Emacs tree,
currently we are at ChangeLog.2.

 > and assumed that it is now automatically populated from the git
 > commit messages -- is this correct, ....

This is correct.

 > or should I also manually update it?

No.  Kind souls (usually Glen) take care of it at least once a week.

 > Also, is there a major mode like "change-log-mode" that would work with git
 > commits, i.e. where text is formatted like a ChangeLog entry but without
 > requiring the text to be indented?

I think that some vc-... function does that now, but I don't use it.

 > ... which might be related to issues we discussed earlier when you
 >> reported bug#16856.  Did you ever look into that again?
 >
 >
 > No, at the time I didn't have the time and energy to look into it. In
 > addition, I found that when I resized the frame pixel-perfect (using my
 > multicolumn package), the problem didn't occur and I was happy with that.

Do you advice users of your package to resize pixel-perfectly?

 > I can see if the problem is still present, and if not, we can close that
 > issue.

OK.

 > When it comes to the bug tracker -- can I filter the bug reports so that I
 > can only see the ones related to the NextStep port?

There was a way to tag bugs wrt the OS.  But I don't see it any more.
And it's not mentioned in ../admin/notes/bugtracker.

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

Hi!

> Do you advice users of your package to resize pixel-perfectly?

The package does it for them. One purpose of the package is to create a
frame layout with a number of side-by-side windows. The user specifies the
width of the windows in characters, e.g. 80, and the package then finds out
how many windows will fit, resizes and positions the frame accordingly, and
creates the windows.

I use this in my startup code, so whenever I open Emacs, it starts with six
side-by-side windows that cover the screen form top to bottom.

In fact, one thing on my TODO list is to reimplement the positioning part
of the package using your new border information function. Right now, the
package hardcodes a lot of information about the properties of things like
the window title and border dimensions, in different window systems. If I
can eliminate all the hardcoded values, it would be a receipt that the
functions provide the right kind of information.


> > When it comes to the bug tracker -- can I filter the bug reports so
that I
> > can only see the ones related to the NextStep port?
>
> There was a way to tag bugs wrt the OS.  But I don't see it any more.
> And it's not mentioned in ../admin/notes/bugtracker.

Too bad, it makes it kind of hard to maintain a port if there is no
efficient way to see relevant bug reports.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 1475 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

 > here is a patch to fix the problems with tool-bar-mode, please try it out.

Thank you.  Works well here.  Please install ASAP.

 > One thing that I have noticed lately is that Emacs often crash when
 > started. I managed to get a call stack by running gdb, but it doesn't mean
 > much to me. Do any of you have an idea what is going on?

Leaves me completely clueless :-(

martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

(1) Toggle the tool bar off.  Does the overall frame height shrink or stay the same?

A:  Starting from Emacs -Q.  Using the mouse to toggle the toolbar off, the height of the frame shrinks -- i.e., top and left remain the same, and the bottom shrinks upward about one-half the height of the toolbar that disappears.  The minibuffer / echo area increases in size to about 3 lines of text, with just one line of text that reads:  "menu-bar options showhide showhide-tool-bar".


(2) Toggle the tool bar on again.  Does the overall frame height increase or stay the same?

A:  The frame height quickly shrinks and expands, but ultimately remains the same size -- i.e., slightly less than when Emacs -Q first began its GUI session.


(3) Evaluate (setq frame-inhibit-implied-resize t) and repeat steps (1) and (2).

A:  Starting again from Emacs -Q.  Evaluate `(setq frame-inhibit-implied-resize t)`.  Step 1 looks the same as previously reported.  Step 2 looks the same as previously reported.  I did not see any visual difference between this test and prior test mentioned above.


Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[martin rudalics]

I add a few observations from the GNUstep perspective.  This build is
inherently broken (emacs -Q starts out with _two_ identical tool bars)
but gets me similar results.  Anders what do you get when you repeat
Keith's experiment?  Only steps (1) and (2) make sense currently.

 > (1) Toggle the tool bar off.  Does the overall frame height shrink or stay the same?
 >
 > A: Starting from Emacs -Q.  Using the mouse to toggle the toolbar off,
 > the height of the frame shrinks -- i.e., top and left remain the same,
 > and the bottom shrinks upward about one-half the height of the toolbar
 > that disappears.  The minibuffer / echo area increases in size to
 > about 3 lines of text, with just one line of text that reads:
 > "menu-bar options showhide showhide-tool-bar".

This is more or less what happens here as well but worked previously.
IIUC it's due to Jan's change below:


diff --git a/src/ChangeLog b/src/ChangeLog
index 69da1c3..861ba91 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,8 @@
+2015-01-06  Jan Djärv  <jan.h.d@swipnet.se>
+
+	* nsterm.m (x_set_window_size): Call updateFrameSize to get real
+	size instead of using widht/height.  The frame may be constrained.
+
  2015-01-05  Paul Eggert  <eggert@cs.ucla.edu>

  	* lisp.h (XSYMBOL): Parenthesize id in forward decl.
diff --git a/src/nsterm.m b/src/nsterm.m
index 2ccb7fe..bf3192b 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1404,15 +1404,8 @@ x_set_window_size (struct frame *f,
      [view setBoundsOrigin: origin];
    }

-  change_frame_size (f, width, height, 0, 1, 0, pixelwise);
-/*  SET_FRAME_GARBAGED (f); // this short-circuits expose call in drawRect */
-
-  mark_window_cursors_off (XWINDOW (f->root_window));
-  cancel_mouse_face (f);
-
+  [view updateFrameSize: NO];
    unblock_input ();
-
-  do_pending_window_change (0);
  }


Restoring the change_frame_size call fixes the problem here.


 > (2) Toggle the tool bar on again.  Does the overall frame height increase or stay the same?
 >

 > A: The frame height quickly shrinks and expands, but ultimately
 > remains the same size -- i.e., slightly less than when Emacs -Q first
 > began its GUI session.

More or less same here.  I tried with earlier builds and all show the
same behavior: Toggling the tool bar on and off repeatedly has the frame
height ultimately shrink.


 > (3) Evaluate (setq frame-inhibit-implied-resize t) and repeat steps (1) and (2).
 >

 > A: Starting again from Emacs -Q.  Evaluate `(setq
 > frame-inhibit-implied-resize t)`.  Step 1 looks the same as previously
 > reported.  Step 2 looks the same as previously reported.  I did not
 > see any visual difference between this test and prior test mentioned
 > above.

I'll try to fix this.  But we must fix (1) first, then (2) ...

Thanks, martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

I applied the patch named `maximize_and_trace.diff` and built Emacs --with-ns.  I was surprised to see that `toggle-frame-maximized` actually worked, which is something I had never seen before on OSX.

My standard stuff that I normally use appears to be working okay -- e.g., `default-frame-alist` with pixel specifications for height/width and courier font are working correctly.

I'm not a programmer, but I'd be happy to run some layman's tests (if you need) on the build with OSX 10.6.8.

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

Hi,

I applied the patch named `maximize_and_trace.diff` and built Emacs
> --with-ns.  I was surprised to see that `toggle-frame-maximized` actually
> worked, which is something I had never seen before on OSX.
>
> My standard stuff that I normally use appears to be working okay -- e.g.,
> `default-frame-alist` with pixel specifications for height/width and
> courier font are working correctly.
>

Great to hear!


> I'm not a programmer, but I'd be happy to run some layman's tests (if you
> need) on the build with OSX 10.6.8.
>

Please do! I'm on 10.9, so it won't hurt to run things on another version
of the OS.

If you don't find anything, I'll post this patch to emacs-devel, and if no
one objects, I will commit it.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 1199 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

The following are results of my tests with `emacs-repository-version` "ffa41ad2a02dbd1202d71a08bac34831f25662d0" built this evening (October 28, 2015).

Starting from Emacs -Q, and then turning off the toolbar using the mouse by clicking the option in the menubar, the frame shrinks slightly. Clicking the toolbar option again restores the frame to its original position.

`M-x toggle-frame-maximized` results in a frame properly maximized.

The first time I turned off the toolbar from a maximized frame, the frame shrunk a little.  When I turned the toolbar back on again, the frame did not return to a maximized position -- i.e., it remained a few pixels shy of full-screen in terms of height.  When I turned the toolbar off again, the main window reduced in size and the height of the echo area increased to about 3 lines in height -- the frame remained the same size.  When I turned the toolbar on again, the main window returned to its prior size and the echo area returned to a size of just one line -- the frame stayed the same size (i.e., a few pixels shy of full-screen in terms of height).

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1.1: Type: text/plain, Size: 2146 bytes --]

Hi,

I found some time to look into this. When the frame was maximized and the
tool-bar was disabled, the function x_set_window_size was never called.

The following patch makes the frame exit the fullheight or maximized states
when the tool-bar is disabled, which makes the call x_set_window_size
reappear. It does NOT, however, return the frame to the fullheight or
maximized states when the toolbar is re-enabled (I don't even know if it
should). In addition, it does not support frame-inhibit-implied-resize
either (which would require a lot more work).

I read in the emacs-devel group that there is a feature-freeze in place --
does this mean that I shouldn't commit this?

Also, the current Emacs master branch doesn't build on OS X 10.6.8 after an
attempt to David Reitter to eliminate warnings -- I think it's an easy fix
(David don't have access to a 10.6.8 machine but fortunately I do).

    -- Anders


On Thu, Oct 29, 2015 at 3:47 AM, Keith David Bershatsky <esq@lawlist.com>
wrote:

> The following are results of my tests with `emacs-repository-version`
> "ffa41ad2a02dbd1202d71a08bac34831f25662d0" built this evening (October 28,
> 2015).
>
> Starting from Emacs -Q, and then turning off the toolbar using the mouse
> by clicking the option in the menubar, the frame shrinks slightly. Clicking
> the toolbar option again restores the frame to its original position.
>
> `M-x toggle-frame-maximized` results in a frame properly maximized.
>
> The first time I turned off the toolbar from a maximized frame, the frame
> shrunk a little.  When I turned the toolbar back on again, the frame did
> not return to a maximized position -- i.e., it remained a few pixels shy of
> full-screen in terms of height.  When I turned the toolbar off again, the
> main window reduced in size and the height of the echo area increased to
> about 3 lines in height -- the frame remained the same size.  When I turned
> the toolbar on again, the main window returned to its prior size and the
> echo area returned to a size of just one line -- the frame stayed the same
> size (i.e., a few pixels shy of full-screen in terms of height).
>
> Keith
>

[-- Attachment #1.2: Type: text/html, Size: 2649 bytes --]

[-- Attachment #2: toolbar-maximized.diff --]
[-- Type: text/plain, Size: 705 bytes --]

diff --git a/src/nsfns.m b/src/nsfns.m
index cffb599..8510327 100644
--- a/src/nsfns.m
+++ b/src/nsfns.m
@@ -671,6 +671,18 @@ x_set_tool_bar_lines (struct frame *f, Lisp_Object value, Lisp_Object oldval)
         {
           free_frame_tool_bar (f);
           FRAME_EXTERNAL_TOOL_BAR (f) = 0;
+
+          {
+            Lisp_Object fullscreen = get_frame_param (f, Qfullscreen);
+            if (EQ (fullscreen, Qmaximized))
+              {
+                store_frame_param (f, Qfullscreen, Qfullwidth);
+              }
+            else if (EQ (fullscreen, Qfullheight))
+              {
+                store_frame_param (f, Qfullscreen, Qnil);
+              }
+          }
         }
     }
 

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

A fix for bug 21301 would indeed be wonderful.  I anticipate having some free time later this evening to look more carefully at this recent thread to see what patch needs to be applied to test out the fix and I'll try it and report back.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Fri, 30 Oct 2015 08:59:47 +0100,
martin rudalics wrote:
> 
* * *
> Please mention the bug number in ChangeLog and commit message and inform
> the OP, possibly closing the bug (I think it's Bug#21301).
> 
> Keith - yet another fix you should test ;-)
> 
> martin

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 898 bytes --]

Keith,

Please check the diff I posted in this thread on the 29:th, it solves all
the fringe problems I have seen -- both the fringe icons and the rendering
of the cursor when in the fringe.

    -- Anders

On Sun, Nov 1, 2015 at 5:53 PM, Keith David Bershatsky <esq@lawlist.com>
wrote:

> A fix for bug 21301 would indeed be wonderful.  I anticipate having some
> free time later this evening to look more carefully at this recent thread
> to see what patch needs to be applied to test out the fix and I'll try it
> and report back.
>
> Keith
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> At Fri, 30 Oct 2015 08:59:47 +0100,
> martin rudalics wrote:
> >
> * * *
> > Please mention the bug number in ChangeLog and commit message and inform
> > the OP, possibly closing the bug (I think it's Bug#21301).
> >
> > Keith - yet another fix you should test ;-)
> >
> > martin
>

[-- Attachment #2: Type: text/html, Size: 1359 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

With respect to fringe.diff from October 29, 2015, applied to a latest download of Emacs master branch, an issue remains with respect to empty line indicators at the end of the buffer.  It looks like two of the indicators are correct, then one is reversed, then two are correct, then one is reversed, and so on.  The fringe bitmap images prior to the end of the buffer looked correct for the few that I tried.

Thanks,

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1.1: Type: text/plain, Size: 915 bytes --]

Hi,

The empty line indicator seems to be a new kind of fringe bitmap used to
create repetitive patterns. The code was only half-hearted when it comes to
this, as it cashed only the first of the alternative images. I rewrote the
code to cache the full image and select a suitable subpart of the when
drawing.

If you have time, please try out the attached patch.

Thanks!

    -- Anders

On Mon, Nov 2, 2015 at 6:18 AM, Keith David Bershatsky <esq@lawlist.com>
wrote:

> With respect to fringe.diff from October 29, 2015, applied to a latest
> download of Emacs master branch, an issue remains with respect to empty
> line indicators at the end of the buffer.  It looks like two of the
> indicators are correct, then one is reversed, then two are correct, then
> one is reversed, and so on.  The fringe bitmap images prior to the end of
> the buffer looked correct for the few that I tried.
>
> Thanks,
>
> Keith
>

[-- Attachment #1.2: Type: text/html, Size: 1310 bytes --]

[-- Attachment #2: fringe2.diff --]
[-- Type: text/plain, Size: 3665 bytes --]

diff --git a/src/nsimage.m b/src/nsimage.m
index e76a7db..a2e0618 100644
--- a/src/nsimage.m
+++ b/src/nsimage.m
@@ -206,6 +206,7 @@ ns_set_alpha (void *img, int x, int y, unsigned char a)
            fg: (unsigned long)fg bg: (unsigned long)bg
 {
   unsigned char *planes[5];
+  unsigned char bg_alpha = 0xff;
 
   [self initWithSize: NSMakeSize (w, h)];
 
@@ -219,7 +220,10 @@ ns_set_alpha (void *img, int x, int y, unsigned char a)
   [bmRep getBitmapDataPlanes: planes];
 
   if (fg == 0 && bg == 0)
-    bg = 0xffffff;
+    {
+      bg = 0xffffff;
+      bg_alpha = 0;
+    }
 
   {
     /* pull bits out to set the (bytewise) alpha mask */
@@ -244,21 +248,22 @@ ns_set_alpha (void *img, int x, int y, unsigned char a)
           c = *s++;
           for (k = 0; i < w && k < 8; ++k, ++i)
             {
-              *alpha++ = 0xff;
-              if (c & 1)
+              if (c & 0x80)
                 {
                   *rr++ = fgr;
                   *gg++ = fgg;
                   *bb++ = fgb;
+                  *alpha++ = 0xff;
                 }
               else
                 {
                   *rr++ = bgr;
                   *gg++ = bgg;
                   *bb++ = bgb;
+                  *alpha++ = bg_alpha;
                 }
               idx++;
-              c >>= 1;
+              c <<= 1;
             }
         }
   }
diff --git a/src/nsterm.m b/src/nsterm.m
index 925e9af..1f6b151 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -2461,6 +2461,10 @@ ns_draw_fringe_bitmap (struct window *w, struct glyph_row *row,
   static EmacsImage **bimgs = NULL;
   static int nBimgs = 0;
 
+  NSTRACE ("ns_draw_fringe_bitmap");
+  NSTRACE_MSG ("which:%d cursor:%d overlay:%d width:%d height:%d period:%d",
+               p->which, p->cursor_p, p->overlay_p, p->wd, p->h, p->dh);
+
   /* grow bimgs if needed */
   if (nBimgs < max_used_fringe_bitmap)
     {
@@ -2493,19 +2497,24 @@ ns_draw_fringe_bitmap (struct window *w, struct glyph_row *row,
 
       if (!img)
         {
-          unsigned short *bits = p->bits + p->dh;
-          int len = p->h;
+          // Note: For "periodic" images, allocate one EmacsImage for
+          // the base image, and use it for all dh:s.
+          unsigned short *bits = p->bits;
+          int full_height = p->h + p->dh;
           int i;
-          unsigned char *cbits = xmalloc (len);
+          unsigned char *cbits = xmalloc (full_height);
 
           for (i = 0; i < len; i++)
-            cbits[i] = ~(bits[i] & 0xff);
-          img = [[EmacsImage alloc] initFromXBM: cbits width: 8 height: p->h
+            cbits[i] = bits[i];
+          img = [[EmacsImage alloc] initFromXBM: cbits width: 8
+                                         height: full_height
                                              fg: 0 bg: 0];
           bimgs[p->which - 1] = img;
           xfree (cbits);
         }
 
+      NSTRACE_RECT ("r", r);
+
       NSRectClip (r);
       /* Since we composite the bitmap instead of just blitting it, we need
          to erase the whole background. */
@@ -2523,9 +2532,15 @@ ns_draw_fringe_bitmap (struct window *w, struct glyph_row *row,
         [img setXBMColor: bm_color];
       }
 
+      // Note: For periodic images, the full image height is "h + hd".
+      // By using the height h, a suitable part of the image is used.
+      NSRect fromRect = NSMakeRect(0, 0, p->wd, p->h);
+
+      NSTRACE_RECT ("fromRect", fromRect);
+
 #ifdef NS_IMPL_COCOA
       [img drawInRect: r
-              fromRect: NSZeroRect
+              fromRect: fromRect
              operation: NSCompositeSourceOver
               fraction: 1.0
            respectFlipped: YES

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Using the latest download of Emacs master branch (tonight November 2, 2015 at about 10:15 p.m. PST) and fringe2.diff, I was not able to complete the building process.  I only tried one time, but think the same result would probably happen if I tried again.

font.c: In function 'font_fill_lglyph_metrics':
font.c:4356: warning: comparison is always true due to limited range of data type
font.c:4356: warning: comparison is always true due to limited range of data type
font.c:4356: warning: comparison is always true due to limited range of data type
font.c:4356: warning: comparison is always true due to limited range of data type
font.c: In function 'Ffont_variation_glyphs':
font.c:4473: warning: comparison is always true due to limited range of data type
font.c:4473: warning: comparison is always true due to limited range of data type
font.c:4473: warning: comparison is always true due to limited range of data type
font.c:4473: warning: comparison is always true due to limited range of data type
font.c: In function 'Finternal_char_font':
font.c:4576: warning: comparison is always true due to limited range of data type
font.c:4576: warning: comparison is always true due to limited range of data type
font.c:4576: warning: comparison is always true due to limited range of data type
font.c:4576: warning: comparison is always true due to limited range of data type
font.c: In function 'Ffont_get_glyphs':
font.c:4909: warning: comparison is always true due to limited range of data type
font.c:4909: warning: comparison is always true due to limited range of data type
font.c:4909: warning: comparison is always true due to limited range of data type
font.c:4909: warning: comparison is always true due to limited range of data type
  CC       print.o
  CC       lread.o
  CC       syntax.o
  CC       unexmacosx.o
  CC       bytecode.o
  CC       process.o
process.c: In function 'record_deleted_pid':
process.c:818: warning: comparison is always true due to limited range of data type
process.c:818: warning: comparison is always true due to limited range of data type
process.c: In function 'Fprocess_id':
process.c:938: warning: comparison is always true due to limited range of data type
process.c:938: warning: comparison is always true due to limited range of data type
  CC       gnutls.o
  CC       callproc.o
  CC       region-cache.o
  CC       sound.o
  CC       atimer.o
  CC       doprnt.o
  CC       intervals.o
  CC       textprop.o
  CC       composite.o
composite.c: In function 'fill_gstring_body':
composite.c:843: warning: comparison is always true due to limited range of data type
composite.c:843: warning: comparison is always true due to limited range of data type
composite.c:843: warning: comparison is always true due to limited range of data type
composite.c:843: warning: comparison is always true due to limited range of data type
composite.c:843: warning: comparison is always true due to limited range of data type
composite.c:843: warning: comparison is always true due to limited range of data type
  CC       xml.o
  CC       profiler.o
  CC       decompress.o
  CC       fontset.o
  CC       fringe.o
  CC       image.o
  CC       nsterm.o
nsterm.m: In function 'ns_draw_fringe_bitmap':
nsterm.m:2507: error: 'len' undeclared (first use in this function)
nsterm.m:2507: error: (Each undeclared identifier is reported only once
nsterm.m:2507: error: for each function it appears in.)
make[1]: *** [nsterm.o] Error 1
make: *** [src] Error 2
~/Desktop/emacs $ 

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 4028 bytes --]

My mistake... I made a last minute change, I changed "len" to
"full_height", and apparently didn't change it in all places.

I can post a new patch when I get home tonight, alternatively you can try
to do the change yourself and recompile.

/ Anders


On Tue, Nov 3, 2015 at 7:29 AM, Keith David Bershatsky <esq@lawlist.com>
wrote:

> Using the latest download of Emacs master branch (tonight November 2, 2015
> at about 10:15 p.m. PST) and fringe2.diff, I was not able to complete the
> building process.  I only tried one time, but think the same result would
> probably happen if I tried again.
>
> font.c: In function 'font_fill_lglyph_metrics':
> font.c:4356: warning: comparison is always true due to limited range of
> data type
> font.c:4356: warning: comparison is always true due to limited range of
> data type
> font.c:4356: warning: comparison is always true due to limited range of
> data type
> font.c:4356: warning: comparison is always true due to limited range of
> data type
> font.c: In function 'Ffont_variation_glyphs':
> font.c:4473: warning: comparison is always true due to limited range of
> data type
> font.c:4473: warning: comparison is always true due to limited range of
> data type
> font.c:4473: warning: comparison is always true due to limited range of
> data type
> font.c:4473: warning: comparison is always true due to limited range of
> data type
> font.c: In function 'Finternal_char_font':
> font.c:4576: warning: comparison is always true due to limited range of
> data type
> font.c:4576: warning: comparison is always true due to limited range of
> data type
> font.c:4576: warning: comparison is always true due to limited range of
> data type
> font.c:4576: warning: comparison is always true due to limited range of
> data type
> font.c: In function 'Ffont_get_glyphs':
> font.c:4909: warning: comparison is always true due to limited range of
> data type
> font.c:4909: warning: comparison is always true due to limited range of
> data type
> font.c:4909: warning: comparison is always true due to limited range of
> data type
> font.c:4909: warning: comparison is always true due to limited range of
> data type
>   CC       print.o
>   CC       lread.o
>   CC       syntax.o
>   CC       unexmacosx.o
>   CC       bytecode.o
>   CC       process.o
> process.c: In function 'record_deleted_pid':
> process.c:818: warning: comparison is always true due to limited range of
> data type
> process.c:818: warning: comparison is always true due to limited range of
> data type
> process.c: In function 'Fprocess_id':
> process.c:938: warning: comparison is always true due to limited range of
> data type
> process.c:938: warning: comparison is always true due to limited range of
> data type
>   CC       gnutls.o
>   CC       callproc.o
>   CC       region-cache.o
>   CC       sound.o
>   CC       atimer.o
>   CC       doprnt.o
>   CC       intervals.o
>   CC       textprop.o
>   CC       composite.o
> composite.c: In function 'fill_gstring_body':
> composite.c:843: warning: comparison is always true due to limited range
> of data type
> composite.c:843: warning: comparison is always true due to limited range
> of data type
> composite.c:843: warning: comparison is always true due to limited range
> of data type
> composite.c:843: warning: comparison is always true due to limited range
> of data type
> composite.c:843: warning: comparison is always true due to limited range
> of data type
> composite.c:843: warning: comparison is always true due to limited range
> of data type
>   CC       xml.o
>   CC       profiler.o
>   CC       decompress.o
>   CC       fontset.o
>   CC       fringe.o
>   CC       image.o
>   CC       nsterm.o
> nsterm.m: In function 'ns_draw_fringe_bitmap':
> nsterm.m:2507: error: 'len' undeclared (first use in this function)
> nsterm.m:2507: error: (Each undeclared identifier is reported only once
> nsterm.m:2507: error: for each function it appears in.)
> make[1]: *** [nsterm.o] Error 1
> make: *** [src] Error 2
> ~/Desktop/emacs $
>

[-- Attachment #2: Type: text/html, Size: 4735 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Ah, yes, `fringe3.diff` does indeed fix the issue with empty line fringe bitmap indicators at the end of the buffer.  Good job!

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Tue, 3 Nov 2015 19:01:13 +0100,
Anders Lindgren wrote:
> 
> Hi,
> 
> here is a new version of the fringe patch.
> 
>     -- Anders

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 539 bytes --]

Wonderful news!

I just pushed the fringe patch. Thanks for testing it!

    -- Anders Lindgren

On Wed, Nov 4, 2015 at 3:21 AM, Keith David Bershatsky <esq@lawlist.com>
wrote:

> Ah, yes, `fringe3.diff` does indeed fix the issue with empty line fringe
> bitmap indicators at the end of the buffer.  Good job!
>
> Keith
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> At Tue, 3 Nov 2015 19:01:13 +0100,
> Anders Lindgren wrote:
> >
> > Hi,
> >
> > here is a new version of the fringe patch.
> >
> >     -- Anders
>

[-- Attachment #2: Type: text/html, Size: 1016 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Using a download of Emacs master branch from this morning (11/15/2015) -- emacs-repository-version "70f1fda4ae6abb5e11dcf281738c25f6f5b06061", and applying toolbar-maximized.diff, and building on OSX Server 10.6.8, I repeated the previous tests.

This time around everything worked as expected.

(1) the default frame with Emacs -Q shrunk a bit and then returned to the previous size when toggling the tool-bar with the mouse.  The beginning bounds were (0, 22, 595, 640), which was reduced to (0, 22, 595, 608), which then increased again to (0, 22, 595, 640).

(2) the full-size frame when issuing the command toggle-frame-maximized had a bounds of (0, 22, 1920, 1080).  When toggling the tool-bar the mouse, the bounds reduced to (0, 22, 1920, 1048).  When toggling the tool-bar again with the mouse, the bounds returned to (0, 22, 1920, 1080).

I tested the bounds with the applescript described in feature request #18283.

Keith

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1506 bytes --]

Thanks for testing this.

Yesterday I pushed this fix (or rather a variant of it) to the "emacs-25"
branch.

When it comes to feature request #18283 -- this sounds like good idea. But
before I add the applescript lines, I would like to read up on the issue a
bit.

I have found the bug database really hard to navigate -- do you know of any
other OS X-related bugs that are still open, I might as well look into
those while I'm at it.

    -- Anders

On Mon, Nov 16, 2015 at 4:06 AM, Keith David Bershatsky <esq@lawlist.com>
wrote:

> Using a download of Emacs master branch from this morning (11/15/2015) --
> emacs-repository-version "70f1fda4ae6abb5e11dcf281738c25f6f5b06061", and
> applying toolbar-maximized.diff, and building on OSX Server 10.6.8, I
> repeated the previous tests.
>
> This time around everything worked as expected.
>
> (1) the default frame with Emacs -Q shrunk a bit and then returned to the
> previous size when toggling the tool-bar with the mouse.  The beginning
> bounds were (0, 22, 595, 640), which was reduced to (0, 22, 595, 608),
> which then increased again to (0, 22, 595, 640).
>
> (2) the full-size frame when issuing the command toggle-frame-maximized
> had a bounds of (0, 22, 1920, 1080).  When toggling the tool-bar the mouse,
> the bounds reduced to (0, 22, 1920, 1048).  When toggling the tool-bar
> again with the mouse, the bounds returned to (0, 22, 1920, 1080).
>
> I tested the bounds with the applescript described in feature request
> #18283.
>
> Keith
>

[-- Attachment #2: Type: text/html, Size: 2223 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Lars Ingebrigtsen]

Keith David Bershatsky <esq@lawlist.com> writes:

> Using a download of Emacs master branch from this morning (11/15/2015)
> -- emacs-repository-version
> "70f1fda4ae6abb5e11dcf281738c25f6f5b06061", and applying
> toolbar-maximized.diff, and building on OSX Server 10.6.8, I repeated
> the previous tests.
>
> This time around everything worked as expected.

This was an very, very long bug report, and it seems like many, many
pixel-resizing bugs were fixed.  Skimming it, it doesn't seem clear why
the bug report was left open, but I may very well have missed
something.  I'm closing it anyway -- if there are anything more to be
done in this area, it's probably more productive to open new bug reports
for these specific things.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

I really enjoy using OSX 10.6.8 and presently have three (3) computers that I regularly use with that operating system running natively.

I would undoubtedly need to undergo several sessions of therapeutic interventions to help me cope with a world without OSX 10.6.8 if Emacs master branch someday becomes unavailable as to that OSX version.

Anything that can be done to maintain compatibility with OSX 10.6.8 would be greatly appreciated -- pretty please with sugar on top -- :)

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Sat, 14 Nov 2015 20:42:04 +0100,
Anders Lindgren wrote:
> 
> * * *
> 
> Also, the current Emacs master branch doesn't build on OS X 10.6.8 after an
> attempt to David Reitter to eliminate warnings -- I think it's an easy fix
> (David don't have access to a 10.6.8 machine but fortunately I do).
> 
>     -- Anders

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Anders Lindgren]

[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]

Hi,

Yesterday I checked in a fix for the OS X 10.6.8 build problem. However, I
used the emacs-25 branch, which is where active development should go after
Fridays feature freeze. Please try it out and let me know if it works for
you.

I'm 100% behind supporting 10.6.8. There are a number of Mac:s that can't
be upgraded to newer OS X versions, but otherwise run perfectly fine.

However, there has been talk about dropping 10.5 and PowerPC support, but I
haven't seen any definitive decision regarding this. I guess they will fall
of the wagon once there are no developers actively supporting them.
(Personally, I don't have access to a PowerPC machine, and wouldn't spend
my free time supporting it anyway.)

    -- Anders


On Mon, Nov 16, 2015 at 4:16 AM, Keith David Bershatsky <esq@lawlist.com>
wrote:

> I really enjoy using OSX 10.6.8 and presently have three (3) computers
> that I regularly use with that operating system running natively.
>
> I would undoubtedly need to undergo several sessions of therapeutic
> interventions to help me cope with a world without OSX 10.6.8 if Emacs
> master branch someday becomes unavailable as to that OSX version.
>
> Anything that can be done to maintain compatibility with OSX 10.6.8 would
> be greatly appreciated -- pretty please with sugar on top -- :)
>
> Keith
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> At Sat, 14 Nov 2015 20:42:04 +0100,
> Anders Lindgren wrote:
> >
> > * * *
> >
> > Also, the current Emacs master branch doesn't build on OS X 10.6.8 after
> an
> > attempt to David Reitter to eliminate warnings -- I think it's an easy
> fix
> > (David don't have access to a 10.6.8 machine but fortunately I do).
> >
> >     -- Anders
>

[-- Attachment #2: Type: text/html, Size: 2288 bytes --]

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

I was able to successfully build Emacs master branch today on 10.6.8 -- emacs-repository-version "937565268a5dc3377d4c9bff6d48eb3645a77160".

I am not aware of any other open OSX specific bugs.

Keith

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Mon, 16 Nov 2015 10:11:03 +0100,
Anders Lindgren wrote:
> 
> * * *
> 
> I have found the bug database really hard to navigate -- do you know of any
> other OS X-related bugs that are still open, I might as well look into
> those while I'm at it.
> 
>     -- Anders

bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame

[Keith David Bershatsky]

Anders:

I just remembered an open bug that is OSX specific:

bug#21714: 25.0.50; image-metadata using Emacs --with-ns prevents *.gif

Keth

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

At Mon, 16 Nov 2015 10:11:03 +0100,
Anders Lindgren wrote:
> 
> * * *
> 
> I have found the bug database really hard to navigate -- do you know of any
> other OS X-related bugs that are still open, I might as well look into
> those while I'm at it.
> 
>     -- Anders