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