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

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

[Keith David Bershatsky]

As to a version of Emacs Trunk built this morning (August 7, 2014), it is no longer possible to set the frame size using pixelwise immediately following a call of `make-frame`, or when launching Emacs.

This no longer works on OSX 10.6.8:

    (let ((frame (make-frame)))
      (set-frame-size frame 1894 1054 t))

The following function should be able to work on startup of Emacs to modify the initial frame, however it does not work on OSX 10.6.8:

    (let ((frame (selected-frame)))
      (cond
        ((eq system-type 'darwin)
          (setq ns-auto-hide-menu-bar t)
          (set-frame-position frame 0 0) ;; must come after `ns-auto-hide-menu-bar`
          (cond
            ((and
                (= 1920 (display-pixel-width))
                (= 1080 (display-pixel-height)))
              (set-frame-size frame 1894 1054 t))
            ((and
                (= 1920 (display-pixel-width))
                (= 1200 (display-pixel-height)))
              (set-frame-size frame 1894 1174 t))
            ((and
                (= 1280 (display-pixel-width))
                (= 800 (display-pixel-height)))
              (set-frame-size frame 1254 774 t))) )
        ((eq system-type 'windows-nt)
          ;; (w32-send-sys-command #xf030)
          (set-frame-position frame 0 0)
          (cond
            ((and
                (= 1920 (display-pixel-width))
                (= 1003 (display-pixel-height)))
              (set-frame-size frame 1876 940 t))
            ((and
                (= 1920 (display-pixel-width))
                (= 1123 (display-pixel-height)))
              (set-frame-size frame 1876 1052 t))
            ((and
                (= 1280 (display-pixel-width))
                (= 723 (display-pixel-height)))
              (set-frame-size frame 1250 670 t)))  )))

Thanks,

Keith

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

In GNU Emacs 24.4.50.1 (x86_64-apple-darwin10.8.0, NS appkit-1038.36 Version 10.6.8 (Build 10K549))
 of 2014-08-07 on MP.local
Repository revision: 117666 kwhite@gnu.org-20140807164419-1oqbo1q8bhr0vnzo
Windowing system distributor `Apple', version 10.3.1038
Configured using:
 `configure --with-ns'

Configured features:
ACL LIBXML2 ZLIB

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

Major mode: Fundamental

Minor modes in effect:
  sd-mode: t
  sb-mode: t
  tb-mode: t
  shell-dirtrack-mode: t
  cm-mode: t
  bc-mode: t
  as-mode: t
  ds-mode: t
  ml-mode: t

Recent input:

Recent messages:

Load-path shadows:
/Users/HOME/.0.data/.0.emacs/.0.flim/md4 hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/md4
/Users/HOME/.0.data/.0.emacs/.0.flim/hex-util hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/hex-util
/Users/HOME/.0.data/.0.emacs/.0.flim/sasl hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/net/sasl
/Users/HOME/.0.data/.0.emacs/.0.flim/sasl-ntlm hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/net/sasl-ntlm
/Users/HOME/.0.data/.0.emacs/.0.flim/sasl-digest hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/net/sasl-digest
/Users/HOME/.0.data/.0.emacs/.0.flim/sasl-cram hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/net/sasl-cram
/Users/HOME/.0.data/.0.emacs/.0.flim/ntlm hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/net/ntlm
/Users/HOME/.0.data/.0.emacs/.0.flim/hmac-md5 hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/net/hmac-md5
/Users/HOME/.0.data/.0.emacs/.0.flim/hmac-def hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/net/hmac-def
/Users/HOME/.0.data/.0.emacs/.0.wl/rfc2368 hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/mail/rfc2368
/Users/HOME/.0.data/.0.emacs/.0.wl/utf7 hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/gnus/utf7
/Users/HOME/.0.data/.0.emacs/.0.simi/smime hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/gnus/smime
/Users/HOME/.0.data/.0.emacs/.0.simi/pgg hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/obsolete/pgg
/Users/HOME/.0.data/.0.emacs/.0.simi/pgg-pgp5 hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/obsolete/pgg-pgp5
/Users/HOME/.0.data/.0.emacs/.0.simi/pgg-pgp hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/obsolete/pgg-pgp
/Users/HOME/.0.data/.0.emacs/.0.simi/pgg-parse hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/obsolete/pgg-parse
/Users/HOME/.0.data/.0.emacs/.0.simi/pgg-gpg hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/obsolete/pgg-gpg
/Users/HOME/.0.data/.0.emacs/.0.simi/pgg-def hides /Users/HOME/.0.data/.0.emacs/Emacs_08_07_2014.app/Contents/Resources/lisp/obsolete/pgg-def

Features:
(shadow wl-mime mime-edit pgg-parse pccl pccl-20 signature mime-setup
mail-mime-setup semi-setup mime-pgp pgg-def mime-play filename
mime-image modb-standard elmo-imap4 emacsbug lawlist-desktop frameset
lawlist-dv lawlist-mc rect lawlist-ztree lawlist-wl wl-demo wl-draft
eword-encode wl-template sendmail elmo-net elmo-cache elmo-map
elmo-dop wl-news wl-address wl-thread wl-folder wl wl-e21 wl-spam
wl-action wl-summary wl-refile wl-util pp elmo-flag elmo-localdir
wl-message elmo-mime mmelmo-buffer mmelmo-imap mime-view mime-conf
calist semi-def mmimap mime-parse mmbuffer mmgeneric elmo-filter
elmo-multi elmo-spam elsp-header elsp-generic elmo elmo-signal
wl-highlight wl-vars wl-version elmo-msgdb modb modb-generic
modb-entity luna mime elmo-util emu invisible inv-23 poem poem-e20
poem-e20_3 eword-decode std11 elmo-date elmo-vars elmo-version
w3m-load mime-w3m w3m browse-url doc-view jka-compr image-mode
w3m-hist w3m-fb bookmark-w3m w3m-ems w3m-ccl ccl w3m-favicon w3m-image
w3m-proc w3m-util lawlist-dired dired-aux lawlist-vr-hr lawlist-ws
disp-table lawlist-calculator lawlist-flyspell bbdb-autoloads bbdb
lawlist-yasnippet lawlist-tex-mode skeleton compare-w
lawlist-text-mode lawlist-tabbar lawlist-github ido view tramp
tramp-compat tramp-loaddefs trampver shell pcomplete help-mode grep
compile comint epa epg epg-config diff-mode autorevert filenotify
ansi-color find-lisp log-edit ring add-log thingatpt log-view
pcvs-util conf-mode time-stamp vc-git vc vc-dispatcher ediff-merg
ediff-wind ediff-diff ediff-mult ediff-help ediff-init ediff-util
ediff rx ert ewoc debug timezone eieio-base lawlist-org
lawlist-calendar derived lawlist-toodledo advice url-http url-auth
url-gw url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util url-parse auth-source eieio byte-opt
bytecomp byte-compile cconv eieio-core password-cache url-vars mailcap
json xml noutline outline gnus-sum gnus-group gnus-undo gnus-start
gnus-cloud nnimap nnmail mail-source tls utf7 mel path-util mime-def
alist mcharset mcs-20 mcs-e20 pcustom pces pces-e20 pces-20 broken poe
pym static apel-ver product netrc nnoo parse-time gnus-spec gnus-int
gnus-range message dired format-spec rfc822 mml mml-sec mm-decode
mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 ietf-drums
mailabbrev gmm-utils mailheader gnus-win gnus gnus-ems nnheader
gnus-util mail-utils mm-util mail-prsvr wid-edit cl
lawlist-frame-buffer lawlist-init pcase help-fns cl-macs gv easy-mmode
edmacro kmacro cl-loaddefs cl-lib savehist server ps-print ps-def lpr
find-func saveplace easymenu time-date tooltip electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode
register page menu-bar rfn-eshadow timer select scroll-bar mouse
jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer 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 make-network-process
cocoa ns multi-tty emacs)

Memory information:
((conses 16 826275 97182)
 (symbols 48 55916 0)
 (miscs 40 116 406)
 (strings 32 112828 13683)
 (string-bytes 1 3779780)
 (vectors 16 39422)
 (vector-slots 8 740042 32580)
 (floats 8 987 155)
 (intervals 56 3967 24)
 (buffers 976 16))

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

[martin rudalics]

 > As to a version of Emacs Trunk built this morning (August 7, 2014), it is no longer possible to set the frame size using pixelwise immediately following a call of `make-frame`, or when launching Emacs.

Can you tell me the date of the last build where this worked for you?

 > This no longer works on OSX 10.6.8:
 >
 >      (let ((frame (make-frame)))
 >        (set-frame-size frame 1894 1054 t))

This should work, indeed.  Does it work correctly by evaluating just

(set-frame-size frame 1894 1054 t)

interactively?

 > The following function should be able to work on startup of Emacs to modify the initial frame, however it does not work on OSX 10.6.8:
 >
 >      (let ((frame (selected-frame)))
 >        (cond
 >          ((eq system-type 'darwin)
 >            (setq ns-auto-hide-menu-bar t)
 >            (set-frame-position frame 0 0) ;; must come after `ns-auto-hide-menu-bar`
 >            (cond
 >              ((and
 >                  (= 1920 (display-pixel-width))
 >                  (= 1080 (display-pixel-height)))
 >                (set-frame-size frame 1894 1054 t))
 >              ((and
 >                  (= 1920 (display-pixel-width))
 >                  (= 1200 (display-pixel-height)))
 >                (set-frame-size frame 1894 1174 t))
 >              ((and
 >                  (= 1280 (display-pixel-width))
 >                  (= 800 (display-pixel-height)))
 >                (set-frame-size frame 1254 774 t))) )
 >          ((eq system-type 'windows-nt)
 >            ;; (w32-send-sys-command #xf030)
 >            (set-frame-position frame 0 0)
 >            (cond
 >              ((and
 >                  (= 1920 (display-pixel-width))
 >                  (= 1003 (display-pixel-height)))
 >                (set-frame-size frame 1876 940 t))
 >              ((and
 >                  (= 1920 (display-pixel-width))
 >                  (= 1123 (display-pixel-height)))
 >                (set-frame-size frame 1876 1052 t))
 >              ((and
 >                  (= 1280 (display-pixel-width))
 >                  (= 723 (display-pixel-height)))
 >                (set-frame-size frame 1250 670 t)))  )))

I hope it continues to work for you on Windows.  Here setting the
initial size works as expected on Windows.  I don't have OSX to test it.
BTW, does "maximizing" your frame on OSX work?

martin

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

[martin rudalics]

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

 > The version of Emacs Trunk built on June 1, 2014 works well -- i.e., the two examples in the current bug report work as expected.
 >
 > GNU Emacs 24.4.50.1 (x86_64-apple-darwin10.8.0, NS appkit-1038.36 Version 10.6.8 (Build 10K549)) of 2014-06-01 on MP.local
 >
 > I did not test any builds between the dates of June 2, 2014 through August 6, 2014.
 >
 > Yes, `(set-frame-size (selected-frame) 1894 1054 t)`, works well with the August 7 and 8, 2014 build when it is evaluated all by itself.
 >
 > `M-x toggle-frame-maximized` works well with the August 7 and 8, 2014 build.

Thanks for the information.  Can you please try the attached patch?

Thanks, martin

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

*** /tmp/ediff3478SQe	2014-08-09 11:04:18.373494252 +0200
--- /home/martin/emacs/quickfixes/src/nsfns.m	2014-08-09 10:44:13.892636675 +0200
***************
*** 1267,1277 ****
    init_frame_faces (f);
  
    /* Read comment about this code in corresponding place in xfns.c.  */
!   width = FRAME_TEXT_WIDTH (f);
!   height = FRAME_TEXT_HEIGHT (f);
!   FRAME_TEXT_HEIGHT (f) = 0;
!   SET_FRAME_WIDTH (f, 0);
!   change_frame_size (f, width, height, 1, 0, 0, 1);
  
    /* The resources controlling the menu-bar and tool-bar are
       processed specially at startup, and reflected in the mode
--- 1267,1274 ----
    init_frame_faces (f);
  
    /* Read comment about this code in corresponding place in xfns.c.  */
!   adjust_frame_size (f, FRAME_COLS (f) * FRAME_COLUMN_WIDTH (f),
! 		     FRAME_LINES (f) * FRAME_LINE_HEIGHT (f), 5, 1);
  
    /* The resources controlling the menu-bar and tool-bar are
       processed specially at startup, and reflected in the mode
***************
*** 1342,1352 ****
    x_default_parameter (f, parms, Qfullscreen, Qnil,
                         "fullscreen", "Fullscreen", RES_TYPE_SYMBOL);
  
!   width = FRAME_TEXT_WIDTH (f);
!   height = FRAME_TEXT_HEIGHT (f);
!   FRAME_TEXT_HEIGHT (f) = 0;
!   SET_FRAME_WIDTH (f, 0);
!   change_frame_size (f, width, height, 1, 0, 0, 1);
  
    if (! f->output_data.ns->explicit_parent)
      {
--- 1339,1348 ----
    x_default_parameter (f, parms, Qfullscreen, Qnil,
                         "fullscreen", "Fullscreen", RES_TYPE_SYMBOL);
  
!   /* Consider frame official, now.  */
!   f->official = true;
! 
!   adjust_frame_size (f, FRAME_TEXT_WIDTH (f), FRAME_TEXT_HEIGHT (f), 0, 1);
  
    if (! f->output_data.ns->explicit_parent)
      {

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

[martin rudalics]

 > The patch you provided did indeed fix the problem -- both examples mentioned in the initial bug report now work with the patched build of Emacs Trunk from August 8, 2014.
 >
 > I should mention that there is a slight difference between the June 1, 2014 build and the patched build of August 8, 2014.  The difference is about six (6) pixels in frame width.  With the June 1, 2014 build, I use 1894 to exactly fill the screen that is 1920 pixels wide.  With the patched build of August 8, 2014, I would now need to use 1900 to exactly fill that same screen which is 1920 pixels wide.  `(frame-pixel-width)` returns 1920 with the patched build following (set-frame-size (selected-frame) 1900 1054 t).

Can you please in _both_ builds (that from June and the present one)
evaluate

(window--dump-frame)

and post the contents of the buffer *window-frame-dump* for both builds
here.  And please keep the CC for 18215@debbugs.gnu.org.

Thanks, martin

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

[Keith David Bershatsky]

Martin:

Thank you for the reminder to include the CC to 18215@debbugs.gnu.org.  I have modified my email reply function so that the carbon copy will always be included in the future whenever the original message contains anything @ that domain name.  I will forward the previous e-mails to the debbugs mailing list so that there is a full record relating to bug 18215.

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
    
    #<window 3 on .scratch>   parent: nil
    pixel left: 0   top: 0   size: 1916 x 1034   new: 0
    char left: 0   top: 0   size: 174 x 51   new: 0
    normal: 1.0 x 1.0   new: 0
    body pixel: 1906 x 996   char: 173 x 49
    width left fringe: 10  left margin: 0  right margin: 0
    width right fringe: 0  scroll-bar: 0  divider: 0
    height header-line: 22  mode-line: 16  divider: 0
    
    #<window 4 on  *Minibuf-0*>   parent: nil
    pixel left: 0   top: 1034   size: 1916 x 20   new: 0
    char left: 0   top: 51   size: 1916 x 1   new: 0
    normal: 1.0 x 1.0   new: 0
    body pixel: 1894 x 20   char: 172 x 1
    width left fringe: 11  left margin: 0  right margin: 0
    width right fringe: 11  scroll-bar: 0  divider: 0
    height header-line: 0  mode-line: 0  divider: 0

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
    
    #<window 3 on .scratch>   parent: nil
    pixel left: 0   top: 0   size: 1910 x 1034   new: 0
    char left: 0   top: 0   size: 173 x 51   new: 0
    normal: 1.0 x 1.0   new: 0
    body pixel: 1900 x 996   char: 172 x 49
    width left fringe: 10  left margin: 0  right margin: 0
    width right fringe: 0  scroll-bar: 0  divider: 0
    height header-line: 22  mode-line: 16  divider: 0
    
    #<window 4 on  *Minibuf-0*>   parent: nil
    pixel left: 0   top: 1034   size: 1910 x 20   new: 0
    char left: 0   top: 51   size: 1910 x 1   new: 0
    normal: 1.0 x 1.0   new: 0
    body pixel: 1894 x 20   char: 172 x 1
    width left fringe: 8  left margin: 0  right margin: 0
    width right fringe: 8  scroll-bar: 0  divider: 0
    height header-line: 0  mode-line: 0  divider: 0

Both of the printouts were made using the settings contained in the initial bug report.

Thanks,

Keith

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

At Sat, 09 Aug 2014 19:14:10 +0200,
martin rudalics wrote:
> 
>  > The patch you provided did indeed fix the problem -- both examples mentioned in the initial bug report now work with the patched build of Emacs Trunk from August 8, 2014.
>  >
>  > I should mention that there is a slight difference between the June 1, 2014 build and the patched build of August 8, 2014.  The difference is about six (6) pixels in frame width.  With the June 1, 2014 build, I use 1894 to exactly fill the screen that is 1920 pixels wide.  With the patched build of August 8, 2014, I would now need to use 1900 to exactly fill that same screen which is 1920 pixels wide.  `(frame-pixel-width)` returns 1920 with the patched build following (set-frame-size (selected-frame) 1900 1054 t).
> 
> Can you please in _both_ builds (that from June and the present one)
> evaluate
> 
> (window--dump-frame)
> 
> and post the contents of the buffer *window-frame-dump* for both builds
> here.  And please keep the CC for 18215@debbugs.gnu.org.
> 
> Thanks, martin

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

[Keith David Bershatsky]

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

The following is a copy of a message that should have been sent to `18215@debbugs.gnu.org`, but which was inadvertently omitted.

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


[-- Attachment #2: Type: message/rfc822, Size: 3607 bytes --]

From: Keith David Bershatsky <esq@lawlist.com>
To: martin rudalics <rudalics@gmx.at>
Subject: Re: bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
Date: Fri, 08 Aug 2014 08:30:27 -0700
Message-ID: <m24mxnknho.wl%esq@lawlist.com>

The version of Emacs Trunk built on June 1, 2014 works well -- i.e., the two examples in the current bug report work as expected.

GNU Emacs 24.4.50.1 (x86_64-apple-darwin10.8.0, NS appkit-1038.36 Version 10.6.8 (Build 10K549)) of 2014-06-01 on MP.local

I did not test any builds between the dates of June 2, 2014 through August 6, 2014.

Yes, `(set-frame-size (selected-frame) 1894 1054 t)`, works well with the August 7 and 8, 2014 build when it is evaluated all by itself.

`M-x toggle-frame-maximized` works well with the August 7 and 8, 2014 build.

Keith

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

At Fri, 08 Aug 2014 10:45:32 +0200,
martin rudalics wrote:
> 
>  > As to a version of Emacs Trunk built this morning (August 7, 2014), it is no longer possible to set the frame size using pixelwise immediately following a call of `make-frame`, or when launching Emacs.
> 
> Can you tell me the date of the last build where this worked for you?
> 
>  > This no longer works on OSX 10.6.8:
>  >
>  >      (let ((frame (make-frame)))
>  >        (set-frame-size frame 1894 1054 t))
> 
> This should work, indeed.  Does it work correctly by evaluating just
> 
> (set-frame-size frame 1894 1054 t)
> 
> interactively?
> 
>  > The following function should be able to work on startup of Emacs to modify the initial frame, however it does not work on OSX 10.6.8:
>  >
>  >      (let ((frame (selected-frame)))
>  >        (cond
>  >          ((eq system-type 'darwin)
>  >            (setq ns-auto-hide-menu-bar t)
>  >            (set-frame-position frame 0 0) ;; must come after `ns-auto-hide-menu-bar`
>  >            (cond
>  >              ((and
>  >                  (= 1920 (display-pixel-width))
>  >                  (= 1080 (display-pixel-height)))
>  >                (set-frame-size frame 1894 1054 t))
>  >              ((and
>  >                  (= 1920 (display-pixel-width))
>  >                  (= 1200 (display-pixel-height)))
>  >                (set-frame-size frame 1894 1174 t))
>  >              ((and
>  >                  (= 1280 (display-pixel-width))
>  >                  (= 800 (display-pixel-height)))
>  >                (set-frame-size frame 1254 774 t))) )
>  >          ((eq system-type 'windows-nt)
>  >            ;; (w32-send-sys-command #xf030)
>  >            (set-frame-position frame 0 0)
>  >            (cond
>  >              ((and
>  >                  (= 1920 (display-pixel-width))
>  >                  (= 1003 (display-pixel-height)))
>  >                (set-frame-size frame 1876 940 t))
>  >              ((and
>  >                  (= 1920 (display-pixel-width))
>  >                  (= 1123 (display-pixel-height)))
>  >                (set-frame-size frame 1876 1052 t))
>  >              ((and
>  >                  (= 1280 (display-pixel-width))
>  >                  (= 723 (display-pixel-height)))
>  >                (set-frame-size frame 1250 670 t)))  )))
> 
> I hope it continues to work for you on Windows.  Here setting the initial size works as expected on Windows.  I don't have OSX to test it.
> BTW, does "maximizing" your frame on OSX work?
> 
> martin

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

[Keith David Bershatsky]

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

The following is a copy of a message that should have been sent to `18215@debbugs.gnu.org`, but which was inadvertently omitted.

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


[-- Attachment #2: Type: message/rfc822, Size: 1995 bytes --]

From: Keith David Bershatsky <esq@lawlist.com>
To: martin rudalics <rudalics@gmx.at>
Subject: Re: bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
Date: Sat, 09 Aug 2014 09:39:50 -0700
Message-ID: <m2ha1l4nxl.wl%esq@lawlist.com>

Martin:

The patch you provided did indeed fix the problem -- both examples mentioned in the initial bug report now work with the patched build of Emacs Trunk from August 8, 2014.

I should mention that there is a slight difference between the June 1, 2014 build and the patched build of August 8, 2014.  The difference is about six (6) pixels in frame width.  With the June 1, 2014 build, I use 1894 to exactly fill the screen that is 1920 pixels wide.  With the patched build of August 8, 2014, I would now need to use 1900 to exactly fill that same screen which is 1920 pixels wide.  `(frame-pixel-width)` returns 1920 with the patched build following (set-frame-size (selected-frame) 1900 1054 t).

Thanks,

Keith

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

At Sat, 09 Aug 2014 11:44:02 +0200,
martin rudalics wrote:
> 
>  > The version of Emacs Trunk built on June 1, 2014 works well -- i.e., the two examples in the current bug report work as expected.
>  >
>  > GNU Emacs 24.4.50.1 (x86_64-apple-darwin10.8.0, NS appkit-1038.36 Version 10.6.8 (Build 10K549)) of 2014-06-01 on MP.local
>  >
>  > I did not test any builds between the dates of June 2, 2014 through August 6, 2014.
>  >
>  > Yes, `(set-frame-size (selected-frame) 1894 1054 t)`, works well with the August 7 and 8, 2014 build when it is evaluated all by itself.
>  >
>  > `M-x toggle-frame-maximized` works well with the August 7 and 8, 2014 build.
> 
> Thanks for the information.  Can you please try the attached patch?
> 
> Thanks, martin

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

[Keith David Bershatsky]

Here are the other relevant settings that were used to give the `(window--dump-frame)` printouts mentioned in my previous e-mail.

    (setq-default left-fringe-width 10)
    
    (setq-default right-fringe-width 0)
    
    (menu-bar-mode -1)
    
    (tool-bar-mode -1)
    
    (add-to-list 'default-frame-alist '(vertical-scroll-bars . nil))

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

At Sat, 09 Aug 2014 19:14:10 +0200,
martin rudalics wrote:
> 
>  > The patch you provided did indeed fix the problem -- both examples mentioned in the initial bug report now work with the patched build of Emacs Trunk from August 8, 2014.
>  >
>  > I should mention that there is a slight difference between the June 1, 2014 build and the patched build of August 8, 2014.  The difference is about six (6) pixels in frame width.  With the June 1, 2014 build, I use 1894 to exactly fill the screen that is 1920 pixels wide.  With the patched build of August 8, 2014, I would now need to use 1900 to exactly fill that same screen which is 1920 pixels wide.  `(frame-pixel-width)` returns 1920 with the patched build following (set-frame-size (selected-frame) 1900 1054 t).
> 
> Can you please in _both_ builds (that from June and the present one)
> evaluate
> 
> (window--dump-frame)
> 
> and post the contents of the buffer *window-frame-dump* for both builds
> here.  And please keep the CC for 18215@debbugs.gnu.org.
> 
> Thanks, martin

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

[martin rudalics]

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

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

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

[martin rudalics]

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

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

I suppose the missing 10/4 pixels are from trying to constrain the size
of the frame to multiples of Emacs' character sizes.  What happens when
you disable that as in the attached patch?

martin

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

--- src/nsterm.m	2014-08-11 08:37:20.734375000 +0200
***************
*** 5842,5848 ****
          {
            sz.width = FRAME_COLUMN_WIDTH (emacsframe);
            sz.height = FRAME_LINE_HEIGHT (emacsframe);
!           [win setResizeIncrements: sz];
  
            NSTRACE_SIZE ("New size", NSMakeSize (neww, newh));
          }
--- 5842,5848 ----
          {
            sz.width = FRAME_COLUMN_WIDTH (emacsframe);
            sz.height = FRAME_LINE_HEIGHT (emacsframe);
! ///           [win setResizeIncrements: sz];
  
            NSTRACE_SIZE ("New size", NSMakeSize (neww, newh));
          }
***************
*** 6113,6119 ****
  
    sz.width = FRAME_COLUMN_WIDTH (f);
    sz.height = FRAME_LINE_HEIGHT (f);
!   [win setResizeIncrements: sz];
  
    [[win contentView] addSubview: self];
  
--- 6113,6119 ----
  
    sz.width = FRAME_COLUMN_WIDTH (f);
    sz.height = FRAME_LINE_HEIGHT (f);
! ///   [win setResizeIncrements: sz];
  
    [[win contentView] addSubview: self];
  
***************
*** 6499,6505 ****
        [fw setDelegate:self];
        [fw setAcceptsMouseMovedEvents: YES];
        [fw useOptimizedDrawing: YES];
!       [fw setResizeIncrements: sz];
        [fw setBackgroundColor: col];
        if ([col alphaComponent] != (EmacsCGFloat) 1.0)
          [fw setOpaque: NO];
--- 6499,6505 ----
        [fw setDelegate:self];
        [fw setAcceptsMouseMovedEvents: YES];
        [fw useOptimizedDrawing: YES];
! ///       [fw setResizeIncrements: sz];
        [fw setBackgroundColor: col];
        if ([col alphaComponent] != (EmacsCGFloat) 1.0)
          [fw setOpaque: NO];
***************
*** 6537,6543 ****
          }
  
        [w setContentView:[fw contentView]];
!       [w setResizeIncrements: sz];
        [w setBackgroundColor: col];
        if ([col alphaComponent] != (EmacsCGFloat) 1.0)
          [w setOpaque: NO];
--- 6537,6543 ----
          }
  
        [w setContentView:[fw contentView]];
! ///       [w setResizeIncrements: sz];
        [w setBackgroundColor: col];
        if ([col alphaComponent] != (EmacsCGFloat) 1.0)
          [w setOpaque: NO];

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

[Keith David Bershatsky]

I was not able to successfully apply the patch due to an error message:

"missing header for context diff at line 2 of patch"

Thanks,

Keith

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

At Mon, 11 Aug 2014 09:40:04 +0200,
martin rudalics wrote:
> 
>  > 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`.
> 
> I suppose the missing 10/4 pixels are from trying to constrain the size
> of the frame to multiples of Emacs' character sizes.  What happens when
> you disable that as in the attached patch?
> 
> martin

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

[martin rudalics]

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

 > I was not able to successfully apply the patch due to an error message:
 >
 > "missing header for context diff at line 2 of patch"

I attached a new patch.  But testing this on GNUstep here shows no
difference.  Funnily, fullheight makes the frame full height as
expected, but maximized leaves some free space below the frame.  Maybe
it depends upon whether one has native fullscreen support or not.

martin

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

=== modified file 'src/nsterm.m'
--- src/nsterm.m	2014-07-27 14:45:26 +0000
+++ src/nsterm.m	2014-08-12 12:55:14 +0000
@@ -5842,7 +5842,7 @@
         {
           sz.width = FRAME_COLUMN_WIDTH (emacsframe);
           sz.height = FRAME_LINE_HEIGHT (emacsframe);
-          [win setResizeIncrements: sz];
+///           [win setResizeIncrements: sz];

           NSTRACE_SIZE ("New size", NSMakeSize (neww, newh));
         }
@@ -6113,7 +6113,7 @@

   sz.width = FRAME_COLUMN_WIDTH (f);
   sz.height = FRAME_LINE_HEIGHT (f);
-  [win setResizeIncrements: sz];
+///   [win setResizeIncrements: sz];

   [[win contentView] addSubview: self];

@@ -6499,7 +6499,7 @@
       [fw setDelegate:self];
       [fw setAcceptsMouseMovedEvents: YES];
       [fw useOptimizedDrawing: YES];
-      [fw setResizeIncrements: sz];
+///       [fw setResizeIncrements: sz];
       [fw setBackgroundColor: col];
       if ([col alphaComponent] != (EmacsCGFloat) 1.0)
         [fw setOpaque: NO];
@@ -6537,7 +6537,7 @@
         }

       [w setContentView:[fw contentView]];
-      [w setResizeIncrements: sz];
+///       [w setResizeIncrements: sz];
       [w setBackgroundColor: col];
       if ([col alphaComponent] != (EmacsCGFloat) 1.0)
         [w setOpaque: NO];

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

[Keith David Bershatsky]

Thank you for the new patch.  I was able to successfully apply the new patch for 'nsterm.m` to a version of Emacs Trunk downloaded tonight (08/12/2014).  I also tried patching the previous file for `nsfns.m`, but received a message that the patch had already been applied.

After patching `nsterm.m` and building Emacs Trunk downloaded tonight (08/12/2014), I was not able to set the frame size to 1920 using any of the settings previously mentioned relating to bug 18215.  I was able to achieve a little less than 1920 or several pixels more than 1920, but not exactly 1920.

Keith

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

At Tue, 12 Aug 2014 15:03:05 +0200,
martin rudalics wrote:
> 
>  > I was not able to successfully apply the patch due to an error message:
>  >
>  > "missing header for context diff at line 2 of patch"
> 
> I attached a new patch.  But testing this on GNUstep here shows no
> difference.  Funnily, fullheight makes the frame full height as
> expected, but maximized leaves some free space below the frame.  Maybe
> it depends upon whether one has native fullscreen support or not.
> 
> martin

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

[Keith David Bershatsky]

Martin:

Please disregard my last e-mail.  It's been a very long day and I'd like to take another look at the new patch with a fresh eye.  I've got so many different versions on my desktop, and I don't want to make an error.

Please keep the report open, and I'll take another look again tomorrow with a cup of coffee in-hand.

Thanks,

Keith

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

At Tue, 12 Aug 2014 15:03:05 +0200,
martin rudalics wrote:
> 
>  > I was not able to successfully apply the patch due to an error message:
>  >
>  > "missing header for context diff at line 2 of patch"
> 
> I attached a new patch.  But testing this on GNUstep here shows no
> difference.  Funnily, fullheight makes the frame full height as
> expected, but maximized leaves some free space below the frame.  Maybe
> it depends upon whether one has native fullscreen support or not.
> 
> martin

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

[martin rudalics]

 > Thank you for the new patch.  I was able to successfully apply the new
 > patch for 'nsterm.m` to a version of Emacs Trunk downloaded tonight
 > (08/12/2014).  I also tried patching the previous file for `nsfns.m`,
 > but received a message that the patch had already been applied.

Jan applied it as revision 117687 with the slightly misleading commit
message: "Fix default width not being 80, but 77."

 > After patching `nsterm.m` and building Emacs Trunk downloaded tonight
 > (08/12/2014), I was not able to set the frame size to 1920 using any
 > of the settings previously mentioned relating to bug 18215.  I was
 > able to achieve a little less than 1920 or several pixels more than
 > 1920, but not exactly 1920.

Do you mean with `set-frame-size' and PIXELWISE non-nil?  I have no idea
how size hints work on OSX so that's easily possible.  Around line 5843
nsterm.m has these three lines

           sz.width = FRAME_COLUMN_WIDTH (emacsframe);
           sz.height = FRAME_LINE_HEIGHT (emacsframe);
           [win setResizeIncrements: sz];

These seem to say that resize increments should happen in multiples of
the frame's character sizes.  Note that in Lisp you get the values of
FRAME_LINE_HEIGHT and FRAME_COLUMN_WIDTH via `frame-char-height' and
`frame-char-width' respectively.

So if you did something like

           sz.width = 1;
           sz.height = 1;
           [win setResizeIncrements: sz];

instead, this should tell your window manager to resize your frame in
increments of 1 pixel instead.  You should be able to try this out by
mouse-dragging the edge of a frame after such change.

But I'm not sure what happens when you omit the

           [win setResizeIncrements: sz];

entirely as in the diffs I sent you.  It might leave the hint values at
some earlier default which inhibits pixelwise resizing.

Note that nsterm.c also has two occurrences of setResizeIncrements in
toggleFullScreen.  I'm not sure whether these apply for getting the
entire screen estate.  You could try to replace around line 6462

   sz.width = FRAME_COLUMN_WIDTH (f);
   sz.height = FRAME_LINE_HEIGHT (f);

with

   sz.width = 1;
   sz.height = 1;

and look whether maximizing works as expected then.

martin

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

[Jan D.]

Hi. 

> 13 aug 2014 kl. 08:23 skrev martin rudalics <rudalics@gmx.at>:
> 
> > Thank you for the new patch.  I was able to successfully apply the new
> > patch for 'nsterm.m` to a version of Emacs Trunk downloaded tonight
> > (08/12/2014).  I also tried patching the previous file for `nsfns.m`,
> > but received a message that the patch had already been applied.
> 
> Jan applied it as revision 117687 with the slightly misleading commit
> message: "Fix default width not being 80, but 77."

That was what I fixed. I have not looked at your patches. 

> 
> > After patching `nsterm.m` and building Emacs Trunk downloaded tonight
> > (08/12/2014), I was not able to set the frame size to 1920 using any
> > of the settings previously mentioned relating to bug 18215.  I was
> > able to achieve a little less than 1920 or several pixels more than
> > 1920, but not exactly 1920.
> 
> Do you mean with `set-frame-size' and PIXELWISE non-nil?  I have no idea
> how size hints work on OSX so that's easily possible.  Around line 5843
> nsterm.m has these three lines
> 
>          sz.width = FRAME_COLUMN_WIDTH (emacsframe);
>          sz.height = FRAME_LINE_HEIGHT (emacsframe);
>          [win setResizeIncrements: sz];
> 
> These seem to say that resize increments should happen in multiples of
> the frame's character sizes.  Note that in Lisp you get the values of
> FRAME_LINE_HEIGHT and FRAME_COLUMN_WIDTH via `frame-char-height' and
> `frame-char-width' respectively.
> 
> So if you did something like
> 
>          sz.width = 1;
>          sz.height = 1;
>          [win setResizeIncrements: sz];
> 
> instead, this should tell your window manager to resize your frame in
> increments of 1 pixel instead.  You should be able to try this out by
> mouse-dragging the edge of a frame after such change.
> 
> But I'm not sure what happens when you omit the
> 
>          [win setResizeIncrements: sz];
> 
> entirely as in the diffs I sent you.  It might leave the hint values at
> some earlier default which inhibits pixelwise resizing.
> 
> Note that nsterm.c also has two occurrences of setResizeIncrements in
> toggleFullScreen.  I'm not sure whether these apply for getting the
> entire screen estate.  You could try to replace around line 6462
> 
>  sz.width = FRAME_COLUMN_WIDTH (f);
>  sz.height = FRAME_LINE_HEIGHT (f);
> 
> with
> 
>  sz.width = 1;
>  sz.height = 1;
> 
> and look whether maximizing works as expected then.

If you remove or set to one, you loose the resize feedback in the title bar (w x h) during resize. 

      Jan D. 

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

[martin rudalics]

 >> Jan applied it as revision 117687 with the slightly misleading commit
 >> message: "Fix default width not being 80, but 77."
 >
 > That was what I fixed. I have not looked at your patches.

The associated Change Log reads as

2014-08-11  Jan Djärv  <jan.h.d@swipnet.se>

	* nsfns.m (Fx_create_frame): Call adjust_frame_size,
	set f->official.

and that's what the code change does.  The default width is not set.
Please have a look.

 >> entire screen estate.  You could try to replace around line 6462
 >>
 >>   sz.width = FRAME_COLUMN_WIDTH (f);
 >>   sz.height = FRAME_LINE_HEIGHT (f);
 >>
 >> with
 >>
 >>   sz.width = 1;
 >>   sz.height = 1;
 >>
 >> and look whether maximizing works as expected then.
 >
 > If you remove or set to one, you loose the resize feedback in the title bar (w x h) during resize.

I suppose so.  But Keith wants to "truly" maximize the frame and it might
be interesting to find out why he can't.

martin

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

[Keith David Bershatsky]

Here are a few printouts of `(window--dump-frame)` with three different builds:

(1) June 1, 2014 -- Emacs Trunk

(2) August 13, 2014 -- Emacs Trunk

(3) August 13, 2014 -- Emacs Trunk with the August 12, 2014 patch of nsterm.m

The last printout is with the patched nsterm.m and calling `M-x toggle-frame-maximized`.

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

I see no difference between the default behavior of August 13, 2014 Emacs Trunk (before applying the patch), versus after applying the August 12, 2014 patch of nsterm.m.

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

*window-frame-dump*_06_01_2014.txt

frame pixel: 1926 x 1058   cols/lines: 174 x 52   units: 11 x 20
frame text pixel: 1900 x 1054   cols/lines: 172 x 52
tool: 0  scroll: 0  fringe: 22  border: 2  right: 0  bottom: 0

#<window 3 on *GNU Emacs*>   parent: nil
pixel left: 0   top: 0   size: 1922 x 1034   new: 0
char left: 0   top: 0   size: 174 x 51   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1900 x 1014   char: 172 x 50
width left fringe: 11  left margin: 0  right margin: 0
width right fringe: 11  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 20  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 1034   size: 1922 x 20   new: 0
char left: 0   top: 51   size: 1922 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1900 x 20   char: 172 x 1
width left fringe: 11  left margin: 0  right margin: 0
width right fringe: 11  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0


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

*window_frame_dump*_08_13_2014.txt

frame pixel: 1920 x 1058   cols/lines: 175 x 52   units: 11 x 20
frame text pixel: 1900 x 1054   cols/lines: 172 x 52
tool: 0  scroll: 0/0  fringe: 16  border: 2  right: 0  bottom: 0

#<window 3 on *GNU Emacs*>   parent: nil
pixel left: 0   top: 0   size: 1916 x 1034   new: 1916
char left: 0   top: 0   size: 174 x 51   new: 174
normal: 1.0 x 1.0   new: 1.0
body pixel: 1900 x 1014   char: 172 x 50
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 20  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 1034   size: 1916 x 20   new: 0
char left: 0   top: 51   size: 1916 x 1   new: 174
normal: 1.0 x 1.0   new: 0
body pixel: 1900 x 20   char: 172 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0

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

*window_frame_dump*_08_13_2014_patched.txt

frame pixel: 1920 x 1058   cols/lines: 175 x 52   units: 11 x 20
frame text pixel: 1900 x 1054   cols/lines: 172 x 52
tool: 0  scroll: 0/0  fringe: 16  border: 2  right: 0  bottom: 0

#<window 3 on *GNU Emacs*>   parent: nil
pixel left: 0   top: 0   size: 1916 x 1034   new: 1916
char left: 0   top: 0   size: 174 x 51   new: 174
normal: 1.0 x 1.0   new: 1.0
body pixel: 1900 x 1014   char: 172 x 50
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 20  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 1034   size: 1916 x 20   new: 0
char left: 0   top: 51   size: 1916 x 1   new: 174
normal: 1.0 x 1.0   new: 0
body pixel: 1900 x 20   char: 172 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0

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

Printout with `toggle-frame-maximzed` following Emacs -Q

frame pixel: 1920 x 1000   cols/lines: 275 x 62   units: 7 x 16
frame text pixel: 1885 x 996   cols/lines: 269 x 62
tool: 0  scroll: 15/0  fringe: 16  border: 2  right: 0  bottom: 0

#<window 3 on *GNU Emacs*>   parent: nil
pixel left: 0   top: 0   size: 1916 x 980   new: 0
char left: 0   top: 0   size: 273 x 61   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1885 x 964   char: 269 x 60
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 15  divider: 0
height header-line: 0  mode-line: 16  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 980   size: 1916 x 16   new: 0
char left: 0   top: 61   size: 1916 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1885 x 16   char: 269 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 15  divider: 0
height header-line: 0  mode-line: 0  divider: 0

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

The settings used to run the tests are as follows:

(cond
  ((eq system-type 'darwin)
    (set-face-attribute 'default (selected-frame) :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
    (add-to-list 'default-frame-alist '(font . "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")))
  ((eq system-type 'windows-nt)
    (set-face-attribute 'default nil :height 180)))

(set-face-attribute 'fringe nil :background "black")

(menu-bar-mode -1)

(tool-bar-mode -1)

(add-to-list 'default-frame-alist '(vertical-scroll-bars . nil))

(add-to-list 'default-frame-alist '(cursor-color . "yellow"))

(add-to-list 'default-frame-alist '(cursor-type . (bar . 2 )))

(add-to-list 'default-frame-alist '(background-color . "black"))

(add-to-list 'default-frame-alist '(foreground-color . "white"))

(let ((frame (selected-frame)))
  (cond
    ((eq system-type 'darwin)
      (setq ns-auto-hide-menu-bar t)
      (set-frame-position frame 0 0) ;; must come after `ns-auto-hide-menu-bar`
      (cond
        ((and
            (= 1920 (display-pixel-width))
            (= 1080 (display-pixel-height)))
          (set-frame-size frame 1900 1054 t))
        ((and
            (= 1920 (display-pixel-width))
            (= 1200 (display-pixel-height)))
          (set-frame-size frame 1894 1174 t))
        ((and
            (= 1280 (display-pixel-width))
            (= 800 (display-pixel-height)))
          (set-frame-size frame 1265 774 t))) )
    ((eq system-type 'windows-nt)
      (set-frame-position frame 0 0)
      (cond
        ((and
            (= 1920 (display-pixel-width))
            (= 1003 (display-pixel-height)))
          (set-frame-size frame 1890 940 t))
        ((and
            (= 1920 (display-pixel-width))
            (= 1123 (display-pixel-height)))
          (set-frame-size frame 1876 1052 t))
        ((and
            (= 1280 (display-pixel-width))
            (= 723 (display-pixel-height)))
          (set-frame-size frame 1250 670 t)))  )))

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

[martin rudalics]

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

 > I see no difference between the default behavior of August 13, 2014 Emacs Trunk (before applying the patch), versus after applying the August 12, 2014 patch of nsterm.m.

I wasn't expecting too much from it anyway :-(

 > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 >
 > *window-frame-dump*_06_01_2014.txt
 >
 > frame pixel: 1926 x 1058   cols/lines: 174 x 52   units: 11 x 20
 > frame text pixel: 1900 x 1054   cols/lines: 172 x 52

I suppose the 1926 is now 6 pixels too wide for a display width of 1920
and this comes from adding the 6 pixels for the changes in the fringe
calculations.  Correct?

 > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 >
 > *window_frame_dump*_08_13_2014.txt
 >
 > frame pixel: 1920 x 1058   cols/lines: 175 x 52   units: 11 x 20
 > frame text pixel: 1900 x 1054   cols/lines: 172 x 52

Are these now the intended values?

BTW have you set `frame-resize-pixelwise' to t?  If you don't, Emacs
will round sizes to character multiples.

 > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 >
 > Printout with `toggle-frame-maximzed` following Emacs -Q
 >
 > frame pixel: 1920 x 1000   cols/lines: 275 x 62   units: 7 x 16
 > frame text pixel: 1885 x 996   cols/lines: 269 x 62

This means that the width isn't too far away from the other two but the
height is quite different - maybe to account for a taskbar.  I attach
yet another patch for nsterm.  You have to set `frame-resize-pixelwise'
in your .emacs to some non-nil value for it (but you should have done
that already as mentioned above).

martin

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

=== modified file 'src/nsterm.m'
--- src/nsterm.m	2014-07-27 14:45:26 +0000
+++ src/nsterm.m	2014-08-15 15:04:20 +0000
@@ -5840,9 +5840,18 @@
       if (sz.width != FRAME_COLUMN_WIDTH (emacsframe) ||
           sz.height != FRAME_LINE_HEIGHT (emacsframe))
         {
-          sz.width = FRAME_COLUMN_WIDTH (emacsframe);
-          sz.height = FRAME_LINE_HEIGHT (emacsframe);
-          [win setResizeIncrements: sz];
+          if (frame_resize_pixelwise)
+	    {
+	      sz.width = 1;
+	      sz.height = 1;
+	    }
+	  else
+	    {
+	      sz.width = FRAME_COLUMN_WIDTH (emacsframe);
+	      sz.height = FRAME_LINE_HEIGHT (emacsframe);
+	    }
+
+	  [win setResizeIncrements: sz];

           NSTRACE_SIZE ("New size", NSMakeSize (neww, newh));
         }
@@ -6111,8 +6120,17 @@
   [win setDelegate: self];
   [win useOptimizedDrawing: YES];

-  sz.width = FRAME_COLUMN_WIDTH (f);
-  sz.height = FRAME_LINE_HEIGHT (f);
+  if (frame_resize_pixelwise)
+    {
+      sz.width = 1;
+      sz.height = 1;
+    }
+  else
+    {
+      sz.width = FRAME_COLUMN_WIDTH (f);
+      sz.height = FRAME_LINE_HEIGHT (f);
+    }
+
   [win setResizeIncrements: sz];

   [[win contentView] addSubview: self];
@@ -6459,8 +6477,16 @@
                                  (FRAME_DEFAULT_FACE (f)),
                                  f);

-  sz.width = FRAME_COLUMN_WIDTH (f);
-  sz.height = FRAME_LINE_HEIGHT (f);
+  if (frame_resize_pixelwise)
+    {
+      sz.width = 1;
+      sz.height = 1;
+    }
+  else
+    {
+      sz.width = FRAME_COLUMN_WIDTH (f);
+      sz.height = FRAME_LINE_HEIGHT (f);
+    }

   if (fs_state != FULLSCREEN_BOTH)
     {

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

[Keith David Bershatsky]

The screen that is being used to run the following tests is 1920 by 1080.  An Emacs frame pixel of 1920 x 1058 fills the screen entirely when:  no Emacs menu-bar, no Emacs tool-bar, and the OSX menu-bar is hidden.

Until running the tests today, I had never used `frame-resize-pixelwise` before.  The test that was previously reported in a prior e-mail with 1926 pixels in width was due to trying to use the same settings for a version of Emacs built on June 1, 2014 and a version of Emacs built in mid-August 2014.

The tests that I ran today were done with an August 15, 2014 Emacs Trunk -- unpatched and patched using the latest patch from Martin (08/15/2014).

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; TEST # 1

The following `window--dump-frame` printout was based on an UN-patched version of Emacs Trunk built on August 15, 2014 using the following settings.  The frame fills the entire screen, and is what I consider to be perfect.

    (setq frame-resize-pixelwise t)
    
    (set-face-attribute 'default (selected-frame) :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
    
    (menu-bar-mode -1)
    
    (tool-bar-mode -1)
    
    (add-to-list 'default-frame-alist '(left-fringe . 11))
    
    (add-to-list 'default-frame-alist '(right-fringe . 0))
    
    (add-to-list 'default-frame-alist '(vertical-scroll-bars . nil))
    
    (setq ns-auto-hide-menu-bar t)
    
    (set-frame-position (selected-frame) 0 0)
    
    (set-frame-size (selected-frame) 1905 1054 t)

frame pixel: 1920 x 1058   cols/lines: 174 x 52   units: 11 x 20
frame text pixel: 1905 x 1054   cols/lines: 173 x 52
tool: 0  scroll: 0/0  fringe: 11  border: 2  right: 0  bottom: 0

#<window 3 on *GNU Emacs*>   parent: nil
pixel left: 0   top: 0   size: 1916 x 1034   new: 0
char left: 0   top: 0   size: 174 x 51   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1905 x 1014   char: 173 x 50
width left fringe: 11  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 20  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 1034   size: 1916 x 20   new: 0
char left: 0   top: 51   size: 1916 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1905 x 20   char: 173 x 1
width left fringe: 11  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; TEST # 2

The following `window--dump-frame` printout was based on an UN-patched version of Emacs Trunk built on August 15, 2014 using the following settings, and then manually typing `M-x toggle-frame-maximzed` after startup.  The frame does NOT fill the screen in either direction -- i.e., height is off by 14 pixels, and width is off by 2 pixels.

    (setq frame-resize-pixelwise t)
    
    (set-face-attribute 'default (selected-frame) :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
    
    (menu-bar-mode -1)
    
    (tool-bar-mode -1)
    
    (add-to-list 'default-frame-alist '(left-fringe . 11))
    
    (add-to-list 'default-frame-alist '(right-fringe . 0))
    
    (add-to-list 'default-frame-alist '(vertical-scroll-bars . nil))
    
    (setq ns-auto-hide-menu-bar t)

frame pixel: 1918 x 1044   cols/lines: 174 x 52   units: 11 x 20
frame text pixel: 1903 x 1040   cols/lines: 173 x 52
tool: 0  scroll: 0/0  fringe: 11  border: 2  right: 0  bottom: 0

#<window 3 on *GNU Emacs*>   parent: nil
pixel left: 0   top: 0   size: 1914 x 1020   new: 0
char left: 0   top: 0   size: 174 x 51   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1903 x 1000   char: 173 x 50
width left fringe: 11  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 20  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 1020   size: 1914 x 20   new: 0
char left: 0   top: 51   size: 1914 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1903 x 20   char: 173 x 1
width left fringe: 11  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; TEST # 3

The following `window--dump-frame` printout was based on a PATCHED (nsterm.m 08/15/2014) version of Emacs Trunk built on August 15, 2014 using the following settings.  The frame fills the entire screen, and is what I consider to be perfect.

    (setq frame-resize-pixelwise t)
    
    (set-face-attribute 'default (selected-frame) :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
    
    (menu-bar-mode -1)
    
    (tool-bar-mode -1)
    
    (add-to-list 'default-frame-alist '(left-fringe . 11))
    
    (add-to-list 'default-frame-alist '(right-fringe . 0))
    
    (add-to-list 'default-frame-alist '(vertical-scroll-bars . nil))
    
    (setq ns-auto-hide-menu-bar t)
    
    (set-frame-position (selected-frame) 0 0)
    
    (set-frame-size (selected-frame) 1905 1054 t)


frame pixel: 1920 x 1058   cols/lines: 174 x 52   units: 11 x 20
frame text pixel: 1905 x 1054   cols/lines: 173 x 52
tool: 0  scroll: 0/0  fringe: 11  border: 2  right: 0  bottom: 0

#<window 3 on *GNU Emacs*>   parent: nil
pixel left: 0   top: 0   size: 1916 x 1034   new: 0
char left: 0   top: 0   size: 174 x 51   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1905 x 1014   char: 173 x 50
width left fringe: 11  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 20  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 1034   size: 1916 x 20   new: 0
char left: 0   top: 51   size: 1916 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1905 x 20   char: 173 x 1
width left fringe: 11  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; TEST # 4

The following `window--dump-frame` printout was based on a PATCHED (nsterm.m 08/15/2014) version of Emacs Trunk built on August 15, 2014 using the following settings, and then manually typing `M-x toggle-frame-maximzed` after startup.  The width is now perfect (i.e., 1920).  The height is almost perfect -- i.e., 1054 -- it looks like about 2 pixels to the top of the screen are not filled, and about 2 pixels to the bottom of the screen are not filled.

    (setq frame-resize-pixelwise t)
    
    (set-face-attribute 'default (selected-frame) :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
    
    (menu-bar-mode -1)
    
    (tool-bar-mode -1)
    
    (add-to-list 'default-frame-alist '(left-fringe . 11))
    
    (add-to-list 'default-frame-alist '(right-fringe . 0))
    
    (add-to-list 'default-frame-alist '(vertical-scroll-bars . nil))
    
    (setq ns-auto-hide-menu-bar t)

frame pixel: 1920 x 1054   cols/lines: 174 x 52   units: 11 x 20
frame text pixel: 1905 x 1050   cols/lines: 173 x 52
tool: 0  scroll: 0/0  fringe: 11  border: 2  right: 0  bottom: 0

#<window 3 on *GNU Emacs*>   parent: nil
pixel left: 0   top: 0   size: 1916 x 1030   new: 0
char left: 0   top: 0   size: 174 x 51   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1905 x 1010   char: 173 x 50
width left fringe: 11  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 20  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 1030   size: 1916 x 20   new: 0
char left: 0   top: 51   size: 1916 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1905 x 20   char: 173 x 1
width left fringe: 11  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0


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

Thanks,

Keith

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

At Fri, 15 Aug 2014 17:52:25 +0200,
martin rudalics wrote:
> 
>  > I see no difference between the default behavior of August 13, 2014 Emacs Trunk (before applying the patch), versus after applying the August 12, 2014 patch of nsterm.m.
> 
> I wasn't expecting too much from it anyway :-(
> 
>  > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>  >
>  > *window-frame-dump*_06_01_2014.txt
>  >
>  > frame pixel: 1926 x 1058   cols/lines: 174 x 52   units: 11 x 20
>  > frame text pixel: 1900 x 1054   cols/lines: 172 x 52
> 
> I suppose the 1926 is now 6 pixels too wide for a display width of 1920
> and this comes from adding the 6 pixels for the changes in the fringe
> calculations.  Correct?
> 
>  > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>  >
>  > *window_frame_dump*_08_13_2014.txt
>  >
>  > frame pixel: 1920 x 1058   cols/lines: 175 x 52   units: 11 x 20
>  > frame text pixel: 1900 x 1054   cols/lines: 172 x 52
> 
> Are these now the intended values?
> 
> BTW have you set `frame-resize-pixelwise' to t?  If you don't, Emacs
> will round sizes to character multiples.
> 
>  > ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>  >
>  > Printout with `toggle-frame-maximzed` following Emacs -Q
>  >
>  > frame pixel: 1920 x 1000   cols/lines: 275 x 62   units: 7 x 16
>  > frame text pixel: 1885 x 996   cols/lines: 269 x 62
> 
> This means that the width isn't too far away from the other two but the
> height is quite different - maybe to account for a taskbar.  I attach
> yet another patch for nsterm.  You have to set `frame-resize-pixelwise'
> in your .emacs to some non-nil value for it (but you should have done
> that already as mentioned above).
> 
> martin

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

[martin rudalics]

 > The following `window--dump-frame` printout was based on an UN-patched
 > version of Emacs Trunk built on August 15, 2014 using the following
 > settings.  The frame fills the entire screen, and is what I consider
 > to be perfect.
 >
 >      (setq frame-resize-pixelwise t)
 >
 >      (set-face-attribute 'default (selected-frame) :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
 >
 >      (menu-bar-mode -1)
 >
 >      (tool-bar-mode -1)
 >
 >      (add-to-list 'default-frame-alist '(left-fringe . 11))
 >
 >      (add-to-list 'default-frame-alist '(right-fringe . 0))
 >
 >      (add-to-list 'default-frame-alist '(vertical-scroll-bars . nil))
 >
 >      (setq ns-auto-hide-menu-bar t)
 >
 >      (set-frame-position (selected-frame) 0 0)
 >
 >      (set-frame-size (selected-frame) 1905 1054 t)
 >
 > frame pixel: 1920 x 1058   cols/lines: 174 x 52   units: 11 x 20
 > frame text pixel: 1905 x 1054   cols/lines: 173 x 52
 > tool: 0  scroll: 0/0  fringe: 11  border: 2  right: 0  bottom: 0

Just for checking: If you change the following two forms

(add-to-list 'default-frame-alist '(left-fringe . 11))
(set-frame-size (selected-frame) 1905 1054 t)

to say

(add-to-list 'default-frame-alist '(left-fringe . 17))
(set-frame-size (selected-frame) 1899 1054 t)

do you still get the same value for the frame pixel width, namely 1920?

 > The following `window--dump-frame` printout was based on a PATCHED
 > (nsterm.m 08/15/2014) version of Emacs Trunk built on August 15, 2014
 > using the following settings, and then manually typing `M-x
 > toggle-frame-maximzed` after startup.  The width is now perfect (i.e.,
 > 1920).  The height is almost perfect -- i.e., 1054 -- it looks like
 > about 2 pixels to the top of the screen are not filled, and about 2
 > pixels to the bottom of the screen are not filled.
 >
 >      (setq frame-resize-pixelwise t)
 >
 >      (set-face-attribute 'default (selected-frame) :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
 >
 >      (menu-bar-mode -1)
 >
 >      (tool-bar-mode -1)
 >
 >      (add-to-list 'default-frame-alist '(left-fringe . 11))
 >
 >      (add-to-list 'default-frame-alist '(right-fringe . 0))
 >
 >      (add-to-list 'default-frame-alist '(vertical-scroll-bars . nil))
 >
 >      (setq ns-auto-hide-menu-bar t)
 >
 > frame pixel: 1920 x 1054   cols/lines: 174 x 52   units: 11 x 20
 > frame text pixel: 1905 x 1050   cols/lines: 173 x 52
 > tool: 0  scroll: 0/0  fringe: 11  border: 2  right: 0  bottom: 0

I don't understand how these get calculated:

(* 11 174) gets me 1914.  Add 4 pixels for the internal border gets me
1918.  Where do those two pixels missing to 1920 go to or come from?

(* 20 52) gets me 1040.  Add 4 pixels for the internal border gets me
1044.  10 pixels missing to 1054 for what?

Do you have any means to trigger maximization from the window manager
via some sort of maximize button?

BTW, can you run Emacs under GDB?

martin

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

[Keith David Bershatsky]

Yes, using the settings of

    (add-to-list 'default-frame-alist '(left-fringe . 17))
    (set-frame-size (selected-frame) 1899 1054 t)

results in this printout for `window--dump-frame`:

frame pixel: 1920 x 1058   cols/lines: 174 x 52   units: 11 x 20
frame text pixel: 1899 x 1054   cols/lines: 172 x 52
tool: 0  scroll: 0/0  fringe: 17  border: 2  right: 0  bottom: 0

#<window 3 on .scratch>   parent: nil
pixel left: 0   top: 0   size: 1916 x 1034   new: 0
char left: 0   top: 0   size: 174 x 51   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1899 x 996   char: 172 x 49
width left fringe: 17  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 0  divider: 0
height header-line: 22  mode-line: 16  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 1034   size: 1916 x 20   new: 0
char left: 0   top: 51   size: 1916 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1899 x 20   char: 172 x 1
width left fringe: 17  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0

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

There is a green button in the upper left-hand corner of the frame on OSX, which will maximize the frame.  With the patched nsterm.m from August 15, 2014, the green button maximization still leaves out four (4) pixels from the height -- i.e., should be 1058 instead of 1054.  I verified the 4 pixel shortfull with an applescript to measure the Emacs frame size, which is 1920 x 1076 instead of 1920 x 1080.  I don't understand why `1058` is Emacs' way of saying `1080 pixels` in height, but that is how it works.  It sure would be easier to understand if Emacs could report the actual frame size in pixel height, like it does for width -- i.e., if the actual frame height in pixels is 1076, then Emacs should report 1076 (instead of 1054).

frame pixel: 1920 x 1054   cols/lines: 174 x 52   units: 11 x 20
frame text pixel: 1905 x 1050   cols/lines: 173 x 52
tool: 0  scroll: 0/0  fringe: 11  border: 2  right: 0  bottom: 0

#<window 3 on *GNU Emacs*>   parent: nil
pixel left: 0   top: 0   size: 1916 x 1030   new: 0
char left: 0   top: 0   size: 174 x 51   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1905 x 1010   char: 173 x 50
width left fringe: 11  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 20  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 1030   size: 1916 x 20   new: 0
char left: 0   top: 51   size: 1916 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1905 x 20   char: 173 x 1
width left fringe: 11  left margin: 0  right margin: 0
width right fringe: 0  scroll-bar: 0  divider: 0
height header-line: 0  mode-line: 0  divider: 0

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

I am able to launch Emacs using GDB, and have used it on just one (1) occasion to submit a crash report of an issue not related to this current bug report.

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

Keith

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

At Sun, 17 Aug 2014 12:12:46 +0200,
martin rudalics wrote:
> 
>  > The following `window--dump-frame` printout was based on an UN-patched
>  > version of Emacs Trunk built on August 15, 2014 using the following
>  > settings.  The frame fills the entire screen, and is what I consider
>  > to be perfect.
>  >
>  >      (setq frame-resize-pixelwise t)
>  >
>  >      (set-face-attribute 'default (selected-frame) :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
>  >
>  >      (menu-bar-mode -1)
>  >
>  >      (tool-bar-mode -1)
>  >
>  >      (add-to-list 'default-frame-alist '(left-fringe . 11))
>  >
>  >      (add-to-list 'default-frame-alist '(right-fringe . 0))
>  >
>  >      (add-to-list 'default-frame-alist '(vertical-scroll-bars . nil))
>  >
>  >      (setq ns-auto-hide-menu-bar t)
>  >
>  >      (set-frame-position (selected-frame) 0 0)
>  >
>  >      (set-frame-size (selected-frame) 1905 1054 t)
>  >
>  > frame pixel: 1920 x 1058   cols/lines: 174 x 52   units: 11 x 20
>  > frame text pixel: 1905 x 1054   cols/lines: 173 x 52
>  > tool: 0  scroll: 0/0  fringe: 11  border: 2  right: 0  bottom: 0
> 
> Just for checking: If you change the following two forms
> 
> (add-to-list 'default-frame-alist '(left-fringe . 11))
> (set-frame-size (selected-frame) 1905 1054 t)
> 
> to say
> 
> (add-to-list 'default-frame-alist '(left-fringe . 17))
> (set-frame-size (selected-frame) 1899 1054 t)
> 
> do you still get the same value for the frame pixel width, namely 1920?
> 
>  > The following `window--dump-frame` printout was based on a PATCHED
>  > (nsterm.m 08/15/2014) version of Emacs Trunk built on August 15, 2014
>  > using the following settings, and then manually typing `M-x
>  > toggle-frame-maximzed` after startup.  The width is now perfect (i.e.,
>  > 1920).  The height is almost perfect -- i.e., 1054 -- it looks like
>  > about 2 pixels to the top of the screen are not filled, and about 2
>  > pixels to the bottom of the screen are not filled.
>  >
>  >      (setq frame-resize-pixelwise t)
>  >
>  >      (set-face-attribute 'default (selected-frame) :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
>  >
>  >      (menu-bar-mode -1)
>  >
>  >      (tool-bar-mode -1)
>  >
>  >      (add-to-list 'default-frame-alist '(left-fringe . 11))
>  >
>  >      (add-to-list 'default-frame-alist '(right-fringe . 0))
>  >
>  >      (add-to-list 'default-frame-alist '(vertical-scroll-bars . nil))
>  >
>  >      (setq ns-auto-hide-menu-bar t)
>  >
>  > frame pixel: 1920 x 1054   cols/lines: 174 x 52   units: 11 x 20
>  > frame text pixel: 1905 x 1050   cols/lines: 173 x 52
>  > tool: 0  scroll: 0/0  fringe: 11  border: 2  right: 0  bottom: 0
> 
> I don't understand how these get calculated:
> 
> (* 11 174) gets me 1914.  Add 4 pixels for the internal border gets me
> 1918.  Where do those two pixels missing to 1920 go to or come from?
> 
> (* 20 52) gets me 1040.  Add 4 pixels for the internal border gets me
> 1044.  10 pixels missing to 1054 for what?
> 
> Do you have any means to trigger maximization from the window manager
> via some sort of maximize button?
> 
> BTW, can you run Emacs under GDB?
> 
> martin

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

[martin rudalics]

 > Yes, using the settings of
 >
 >      (add-to-list 'default-frame-alist '(left-fringe . 17))
 >      (set-frame-size (selected-frame) 1899 1054 t)
 >
 > results in this printout for `window--dump-frame`:
 >
 > frame pixel: 1920 x 1058   cols/lines: 174 x 52   units: 11 x 20
 > frame text pixel: 1899 x 1054   cols/lines: 172 x 52

This means that we internally resize pixelwise as needed.

 > There is a green button in the upper left-hand corner of the frame on
 > OSX, which will maximize the frame.  With the patched nsterm.m from
 > August 15, 2014, the green button maximization still leaves out four
 > (4) pixels from the height -- i.e., should be 1058 instead of 1054.  I
 > verified the 4 pixel shortfull with an applescript to measure the
 > Emacs frame size, which is 1920 x 1076 instead of 1920 x 1080.

I suppose it's related to some extra calculations of the toolbar height
in nsterm.m.  For example here on GNUstep turning off the toolbar leaves
the entire space for it in the frame.

 > I
 > don't understand why `1058` is Emacs' way of saying `1080 pixels` in
 > height, but that is how it works.  It sure would be easier to
 > understand if Emacs could report the actual frame size in pixel
 > height, like it does for width -- i.e., if the actual frame height in
 > pixels is 1076, then Emacs should report 1076 (instead of 1054).

`frame-pixel-height' is a misnomer.  It returns the height of the frame
as the sum of the frame's text height (an abstraction inherited from
TTYs) plus the height of some objects Emacs handles internally (like the
internal border or an internal tool- or menubar).

Getting the screen estate of an Emacs frame (including things like title
bars or external borders) in a uniform manner for all platforms is not
entirely trivial.  I plan to provide a function to do that in the near
future.  Note, however, that maximized frames are usually positioned at
something like (-4, -4) to make the external border disappear and
inherently have variable size to make sure that parts of it don't get
hidden when changing the system taskbar.

 > I am able to launch Emacs using GDB, and have used it on just one (1)
 > occasion to submit a crash report of an issue not related to this
 > current bug report.

That's good.  As soon as I understand what and where I'll probably ask
you to check some things.

martin

bug#18215: [PATCH] Set frame size to actual requested size (bug#18215)

[Alan Third]

* src/nsterm.m (x_set_window_size): Don't use
FRAME_TEXT_TO_PIXEL_WIDTH or FRAME_TEXT_TO_PIXEL_HEIGHT.
---
 src/nsterm.m | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/nsterm.m b/src/nsterm.m
index ff3329d1ce..be97e94dd5 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1820,8 +1820,8 @@ -(void)remove
 
   if (pixelwise)
     {
-      pixelwidth = FRAME_TEXT_TO_PIXEL_WIDTH (f, width);
-      pixelheight = FRAME_TEXT_TO_PIXEL_HEIGHT (f, height);
+      pixelwidth = width;
+      pixelheight = height;
     }
   else
     {
-- 

This is a pretty old bug, but I think it’s still reproducible. The
patch just removes the use of FRAME_TEXT_TO_PIXEL_HEIGHT/WIDTH from
x_set_window_size, as they’re already used to calculate the width and
height in adjust_frame_size in frame.c.

-- 
Alan Third