bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.

[Keith David Bershatsky]

With both Emacs versions (i.e., June 1, 2014 and the patched August 8, 2014) 
and a setting of `(setq ns-auto-hide-menu-bar t)`, the function 
`toggle-frame-maximized` leaves approximately 10 pixels at the top of the 
screen that are not filled and about 4 or more pixels to the right of the 
screen that are not filled.  The only method that I have discovered that can 
fill the screen entirely (without going into full-screen mode), is using 
`set-frame-size` with the pixelwise argument.  When not using `(setq 
ns-auto-hide-menu-bar t)`, there are still a few pixels that are not filled by 
the Emacs frame when using `toggle-frame-maximized`.

It would appear that `(setq-default left-fringe-width 10)` and `(setq-default 
right-fringe-width 0)` are geared towards the `window` settings, rather than 
the `frame` settings.  The default frame fringe settings can be seen visually 
in the minibuffer -- i.e., default fringe left and right are both 11 when not 
overriding the default settings with the `default-frame-alist`.  Rather than 
using `(setq-default left-fringe-width 10)` and `(setq-default 
right-fringe-width 0)`, I believe it would be better for me to use:

(add-to-list 'default-frame-alist '(left-fringe . 11))

(add-to-list 'default-frame-alist '(right-fringe . 0))

With those `default-frame-alist` settings, the same result can be achieved with 
both Emacs versions.

Keith

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

At Sun, 10 Aug 2014 11:19:28 +0200,
martin rudalics wrote:
> 
> Thanks for the dumps.  As I expected, the difference of 6 pixels is
> explained by the different values for the fringes, namely ...
> 
>  > Here is the `(window--dump-frame)` printout for the June 1, 2014 Emacs 
> Trunk build:
>  >
>  >      frame pixel: 1920 x 1058   cols/lines: 174 x 52   units: 11 x 20
>  >      frame text pixel: 1894 x 1054   cols/lines: 172 x 52
>  >      tool: 0  scroll: 0  fringe: 22  border: 2  right: 0  bottom: 0
> 
> ... 22 pixels for the June build, and ...
> 
>  > Here is the `(window--dump-frame)` printout for the August 8, 2014 patched 
> Emacs Trunk build:
>  >
>  >      frame pixel: 1914 x 1058   cols/lines: 175 x 52   units: 11 x 20
>  >      frame text pixel: 1894 x 1054   cols/lines: 172 x 52
>  >      tool: 0  scroll: 0/0  fringe: 16  border: 2  right: 0  bottom: 0
> 
> .... 16 pixels for the August build.  The reason for this is that the
> June build still rounds the fringe widths to the next multiple of the
> frame's character width which is listed as 11 in your dump (compare
> "units: 11 x 20") while the August build does not round any more.
> 
> Basically, you should be able to fix this problem in a more generic way
> either by maximizing the frame instead of calculating its sizes by hand
> or by making the calculations use terms like those used in
> `window--dump-frame' where you should see how the "pixel size" of a
> frame relates to its "text size".  In addition, you would have to
> platform-wise include the sizes of the outer borders and the frame
> decorations used by the respective window manager.  I plan to provide
> these values within Emacs but since I do no have access to all platforms
> this might still take some time.
> 
>  > Both of the printouts were made using the settings contained in the 
> initial bug report.
> 
> It's not entirely clear to me how the values reported here relate to the
> values of
> 
>  >     (setq-default left-fringe-width 10)
>  >
>  >     (setq-default right-fringe-width 0)
> 
> you report later.  Do your fringes appear as if they had this width (10
> pixels for the left and 0 pixels for the right) or do they look as in
> the dump (8 pixels on the left and the right, I presume)?
> 
> martin