* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-07 18:40 bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame` Keith David Bershatsky
@ 2014-08-08 8:45 ` martin rudalics
2014-08-09 19:29 ` Keith David Bershatsky
` (10 subsequent siblings)
11 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2014-08-08 8:45 UTC (permalink / raw)
To: Keith David Bershatsky, 18215
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-07 18:40 bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame` Keith David Bershatsky
2014-08-08 8:45 ` martin rudalics
@ 2014-08-09 19:29 ` Keith David Bershatsky
2014-08-10 9:19 ` martin rudalics
2014-08-09 19:36 ` bug#18215: Fwd: " Keith David Bershatsky
` (9 subsequent siblings)
11 siblings, 1 reply; 25+ messages in thread
From: Keith David Bershatsky @ 2014-08-09 19:29 UTC (permalink / raw)
To: martin rudalics; +Cc: 18215
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
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-09 19:29 ` Keith David Bershatsky
@ 2014-08-10 9:19 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2014-08-10 9:19 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 18215
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#18215: Fwd: Re: bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-07 18:40 bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame` Keith David Bershatsky
2014-08-08 8:45 ` martin rudalics
2014-08-09 19:29 ` Keith David Bershatsky
@ 2014-08-09 19:36 ` Keith David Bershatsky
2014-08-09 19:37 ` Keith David Bershatsky
` (8 subsequent siblings)
11 siblings, 0 replies; 25+ messages in thread
From: Keith David Bershatsky @ 2014-08-09 19:36 UTC (permalink / raw)
To: 18215
[-- 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
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: Fwd: Re: bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-07 18:40 bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame` Keith David Bershatsky
` (2 preceding siblings ...)
2014-08-09 19:36 ` bug#18215: Fwd: " Keith David Bershatsky
@ 2014-08-09 19:37 ` Keith David Bershatsky
2014-08-09 20:00 ` Keith David Bershatsky
` (7 subsequent siblings)
11 siblings, 0 replies; 25+ messages in thread
From: Keith David Bershatsky @ 2014-08-09 19:37 UTC (permalink / raw)
To: 18215
[-- 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
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-07 18:40 bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame` Keith David Bershatsky
` (3 preceding siblings ...)
2014-08-09 19:37 ` Keith David Bershatsky
@ 2014-08-09 20:00 ` Keith David Bershatsky
2014-08-10 16:51 ` Keith David Bershatsky
` (6 subsequent siblings)
11 siblings, 0 replies; 25+ messages in thread
From: Keith David Bershatsky @ 2014-08-09 20:00 UTC (permalink / raw)
To: martin rudalics; +Cc: 18215
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
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-07 18:40 bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame` Keith David Bershatsky
` (4 preceding siblings ...)
2014-08-09 20:00 ` Keith David Bershatsky
@ 2014-08-10 16:51 ` Keith David Bershatsky
2014-08-11 7:40 ` martin rudalics
2014-08-12 2:47 ` Keith David Bershatsky
` (5 subsequent siblings)
11 siblings, 1 reply; 25+ messages in thread
From: Keith David Bershatsky @ 2014-08-10 16:51 UTC (permalink / raw)
To: martin rudalics; +Cc: 18215
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
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-10 16:51 ` Keith David Bershatsky
@ 2014-08-11 7:40 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2014-08-11 7:40 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 18215
[-- 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];
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-07 18:40 bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame` Keith David Bershatsky
` (5 preceding siblings ...)
2014-08-10 16:51 ` Keith David Bershatsky
@ 2014-08-12 2:47 ` Keith David Bershatsky
2014-08-12 13:03 ` martin rudalics
2014-08-13 4:43 ` Keith David Bershatsky
` (4 subsequent siblings)
11 siblings, 1 reply; 25+ messages in thread
From: Keith David Bershatsky @ 2014-08-12 2:47 UTC (permalink / raw)
To: martin rudalics; +Cc: 18215
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
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-12 2:47 ` Keith David Bershatsky
@ 2014-08-12 13:03 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2014-08-12 13:03 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 18215
[-- 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];
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-07 18:40 bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame` Keith David Bershatsky
` (6 preceding siblings ...)
2014-08-12 2:47 ` Keith David Bershatsky
@ 2014-08-13 4:43 ` Keith David Bershatsky
2014-08-13 6:23 ` martin rudalics
2014-08-13 4:49 ` Keith David Bershatsky
` (3 subsequent siblings)
11 siblings, 1 reply; 25+ messages in thread
From: Keith David Bershatsky @ 2014-08-13 4:43 UTC (permalink / raw)
To: martin rudalics; +Cc: 18215
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
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-13 4:43 ` Keith David Bershatsky
@ 2014-08-13 6:23 ` martin rudalics
2014-08-13 10:33 ` Jan D.
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2014-08-13 6:23 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 18215
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-13 6:23 ` martin rudalics
@ 2014-08-13 10:33 ` Jan D.
2014-08-13 12:21 ` martin rudalics
0 siblings, 1 reply; 25+ messages in thread
From: Jan D. @ 2014-08-13 10:33 UTC (permalink / raw)
To: martin rudalics; +Cc: 18215@debbugs.gnu.org, Keith David Bershatsky
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.
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-13 10:33 ` Jan D.
@ 2014-08-13 12:21 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2014-08-13 12:21 UTC (permalink / raw)
To: Jan D.; +Cc: 18215@debbugs.gnu.org, Keith David Bershatsky
>> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-07 18:40 bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame` Keith David Bershatsky
` (7 preceding siblings ...)
2014-08-13 4:43 ` Keith David Bershatsky
@ 2014-08-13 4:49 ` Keith David Bershatsky
2014-08-14 3:44 ` Keith David Bershatsky
` (2 subsequent siblings)
11 siblings, 0 replies; 25+ messages in thread
From: Keith David Bershatsky @ 2014-08-13 4:49 UTC (permalink / raw)
To: martin rudalics; +Cc: 18215
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
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-07 18:40 bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame` Keith David Bershatsky
` (8 preceding siblings ...)
2014-08-13 4:49 ` Keith David Bershatsky
@ 2014-08-14 3:44 ` Keith David Bershatsky
2014-08-15 15:52 ` martin rudalics
2014-08-16 23:35 ` Keith David Bershatsky
2014-08-17 18:29 ` Keith David Bershatsky
11 siblings, 1 reply; 25+ messages in thread
From: Keith David Bershatsky @ 2014-08-14 3:44 UTC (permalink / raw)
To: martin rudalics; +Cc: 18215
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))) )))
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-14 3:44 ` Keith David Bershatsky
@ 2014-08-15 15:52 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2014-08-15 15:52 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 18215
[-- 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)
{
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-07 18:40 bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame` Keith David Bershatsky
` (9 preceding siblings ...)
2014-08-14 3:44 ` Keith David Bershatsky
@ 2014-08-16 23:35 ` Keith David Bershatsky
2014-08-17 10:12 ` martin rudalics
2014-08-17 18:29 ` Keith David Bershatsky
11 siblings, 1 reply; 25+ messages in thread
From: Keith David Bershatsky @ 2014-08-16 23:35 UTC (permalink / raw)
To: martin rudalics; +Cc: 18215
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
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-16 23:35 ` Keith David Bershatsky
@ 2014-08-17 10:12 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2014-08-17 10:12 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 18215
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-07 18:40 bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame` Keith David Bershatsky
` (10 preceding siblings ...)
2014-08-16 23:35 ` Keith David Bershatsky
@ 2014-08-17 18:29 ` Keith David Bershatsky
2014-08-18 8:31 ` martin rudalics
11 siblings, 1 reply; 25+ messages in thread
From: Keith David Bershatsky @ 2014-08-17 18:29 UTC (permalink / raw)
To: martin rudalics; +Cc: 18215
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
^ permalink raw reply [flat|nested] 25+ messages in thread* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
2014-08-17 18:29 ` Keith David Bershatsky
@ 2014-08-18 8:31 ` martin rudalics
2017-09-02 17:44 ` bug#18215: [PATCH] Set frame size to actual requested size (bug#18215) Alan Third
0 siblings, 1 reply; 25+ messages in thread
From: martin rudalics @ 2014-08-18 8:31 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 18215
> 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
^ permalink raw reply [flat|nested] 25+ messages in thread
* bug#18215: [PATCH] Set frame size to actual requested size (bug#18215)
2014-08-18 8:31 ` martin rudalics
@ 2017-09-02 17:44 ` Alan Third
0 siblings, 0 replies; 25+ messages in thread
From: Alan Third @ 2017-09-02 17:44 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 18215
* 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
^ permalink raw reply related [flat|nested] 25+ messages in thread
* bug#18215: 24.4.50; OSX 10.6.8; set-frame-size by pixelwise does not work following `make-fame`.
[not found] <m24mxnknho.wl%esq@lawlist.com>
@ 2014-08-09 9:44 ` martin rudalics
0 siblings, 0 replies; 25+ messages in thread
From: martin rudalics @ 2014-08-09 9:44 UTC (permalink / raw)
To: Keith David Bershatsky; +Cc: 18215
[-- 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)
{
^ permalink raw reply [flat|nested] 25+ messages in thread