Discussion:
bug#21415: 25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame
Keith David Bershatsky
2015-09-04 17:41:46 UTC
Permalink
I am trying to do three things:

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

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

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

Thanks,

Keith

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

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

Configured features:
DBUS ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

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

Major mode: FM

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

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

Load-path shadows:
None found.

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

Memory information:
((conses 16 2227445 234500)
(symbols 48 87489 0)
(miscs 40 380 422)
(strings 32 196673 24233)
(string-bytes 1 7265947)
(vectors 16 41082)
(vector-slots 8 987798 14925)
(floats 8 2462 974)
(intervals 56 817 362)
(buffers 976 18))
martin rudalics
2015-09-04 19:17:51 UTC
Permalink
Post by Keith David Bershatsky
(1) efficiently create a new frame that is exact as to pixelwise
width/height so that `(set-frame-size FRAME WIDTH PIXELWISE)` is not
needed after each new frame is created;
Interesting. This is the first time someone asks for this. Do you have
a particular use case?
Post by Keith David Bershatsky
(2) pass a pixelwise argument to `x-create-frame` that would resolve the first goal [?];
We'd need a ‘pixel-width’ and a ‘pixel-height’ frame parameter. When
any of these is present, it would be used instead of the ‘width’ and
‘height’ parameters. Alternatively, we could interpret floating point
values of ‘width’ and ‘height’ specially.
Post by Keith David Bershatsky
(3) avoid intermittent visual flickering of the entire frame that is
caused by a frame creation at the default size of `(width . 80)
(height . 35)` followed immediately by programmatically enlarging the
frame substantially with `set-frame-size` using the pixelwise
argument. [The intermittent visual flickering can be avoided by
setting the `mode-line-format` to `nil`; however, the default
`mode-line-format` causes/contributes to the visual flickering.]
[This did not happen with the Emacs Trunk from last year, but happens
now intermittently with a current version.]
Could you try bisecting to find out when this started?

martin
Keith David Bershatsky
2015-09-05 00:31:24 UTC
Permalink
In my opinion, it would be useful to set the frame specifications exactly at the time of creation -- rather than fix it after the fact with `set-frame-size` using the pixelwise argument.

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

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

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

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

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

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

At Fri, 04 Sep 2015 21:17:51 +0200,
Post by martin rudalics
(1) . . .
Interesting. This is the first time someone asks for this. Do you have
a particular use case?
(2) . . .
We'd need a ‘pixel-width' and a ‘pixel-height' frame parameter. When
any of these is present, it would be used instead of the ‘width' and
‘height' parameters. Alternatively, we could interpret floating point
values of ‘width' and ‘height' specially.
(3) . . .
Could you try bisecting to find out when this started?
martin rudalics
2015-09-05 09:59:00 UTC
Permalink
Post by Keith David Bershatsky
In my opinion, it would be useful to set the frame specifications
exactly at the time of creation -- rather than fix it after the fact
with `set-frame-size` using the pixelwise argument.
Agreed.
Post by Keith David Bershatsky
My particular immediate use case is to simply fill the screen exactly
(on OSX, XP, and Windows 7). In my testing, `toggle-frame-maximized`
was never as accurate as `set-frame-size` using the pixelwise
argument.
I was afraid that would be your concern. ‘toggle-frame-maximized’
should work precisely. Can you provide me more details wrt how it
doesn't achieve its goal?
Post by Keith David Bershatsky
I would imagine there are other situations where a user may
wish to create a frame with exact specifications to fit precisely into
a specific location on the screen, without the need to fix it after
the fact.
Basically a tiling window manager should do that. But I'm not against
providing such a service.
Post by Keith David Bershatsky
I have a test that identifies the current operating system and screen
sizes on my different machines, and I have already determined exactly
how many Emacs frame pixels fill the screen based on other factors
such as font, fringe widths, no scroll bars, and no menu-bar.
The problem is that with Emacs it's pretty hard to do that reliably.
Knowing the exact sizes of each and every component on the various
platforms is a pain. For example, I doubt that you are able to
calculate the height of your tool bar beforehand - I never was. Or, do
you know the size of the external border of a frame on OS X?

I try to address most of these in the function ‘frame-geometry’. Does
that return good results on OS X? Also note that you have to subtract
one default scroll bar width/height, the fringe widths and the internal
border width in order to convert the frame's outer width (the one you
see on the screen) to its native width (the one you set via frame
parameters).
Post by Keith David Bershatsky
The
general approach has been to take the initial frame or subsequently
created frames and use `set-frame-size` with the pixelwise argument to
blow it up to the preferred size. It sure would be nice, however, to
set the pixel width/height along with the other frame parameters both
programmatically (passing as parameters to `make-frame`), and as part
of the `initial-frame-alist` and `default-frame-alist`.
OK.
Post by Keith David Bershatsky
I don't fully understand the floating point because the pixels are
whole numbers, rather than decimals -- this is probably because I'm
just a hobbyist, not a real programmer. But yes, a frame-parameter
for pixel width and pixel height would be awesome.
You would simply specify something like (height . 100.0) to get a 100
pixels high frame instead of (height . 6) to get a 6 columns high frame.
The advantage of the floating point idea over a separate ‘pixel-width’ /
‘pixel-height’ approach would be twofold:

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

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

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

(make-frame '((width . 400.0) (height . 200.0)))
Post by Keith David Bershatsky
Last weekend, I learned how to build Emacs from any point in time
based on a particular commit; and, I also learned the layman's way to
download prebuilt nightlies from http://emacsformacosx.com/ I'd be
happy to work on pinpointing when the intermittent flickering began,
and will spend a little time on that project each day.
That would be fine.

Thanks, martin
Keith David Bershatsky
2015-09-06 17:18:22 UTC
Permalink
With respect to the patch, I believe it was applied successfully -- I selected the option "y".

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

patching file src/frame.c

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

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

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

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

With respect to the other issues, I will spend some time familiarizing myself with the geometry function and get back to you on those.
martin rudalics
2015-09-06 19:26:54 UTC
Permalink
Post by Keith David Bershatsky
With respect to the patch, I believe it was applied successfully -- I selected the option "y".
SHELL-PROMPT: emacs HOME$ patch -p1 < frame.c.diff
patching file src/frame.c
Reversed (or previously applied) patch detected! Assume -R? [n] y
Strange. Are you sure you had a pristine frame.c? What does git diff
give for your Emacs tree?
Post by Keith David Bershatsky
Hunk #3 succeeded at 4840 (offset 9 lines).
If you have no private changes in frame.c do a C-x v u in a buffer
showing frame.c and afterwards do

git apply frame.c.diff

followed by make.
Post by Keith David Bershatsky
Debugger entered--Lisp error: (wrong-type-argument integerp 400.0)
That would indicate that my patch was not applied or you did not build
Emacs correctly afterwards. In any case I attach the patch again.

martin
Keith David Bershatsky
2015-09-06 17:56:25 UTC
Permalink
With respect to your inquiry about `frame-geometry' on OSX, I tested the outer frame dimensions with an applescript using the feature request of bug number 18283 -- the results of getting the bounds with an applescript were the same as those returned by `frame-geometry' for the outer frame pixel width/height. So that aspect of `frame-geometry' is correct on OSX 10.6.8 Snow Leopard Server. I did not test the other aspects of `frame-geometry'.
martin rudalics
2015-09-06 19:26:59 UTC
Permalink
Post by Keith David Bershatsky
With respect to your inquiry about `frame-geometry' on OSX, I tested
the outer frame dimensions with an applescript using the feature
request of bug number 18283
You really should send a patch for that bug. If noone objects I'll
apply it in a few days. Few people here build on OS X and still fewer
write Applescripts.
Post by Keith David Bershatsky
-- the results of getting the bounds with
an applescript were the same as those returned by `frame-geometry' for
the outer frame pixel width/height. So that aspect of
`frame-geometry' is correct on OSX 10.6.8 Snow Leopard Server. I did
not test the other aspects of `frame-geometry'.
You will need them to be able to translate from the outer frame pixel
width/height to the native width/height. It's the latter you specify in
the width/height parameters. So you have to subtract the width of the
external border and the title bar from the outer width/height to get the
desired native width/height.

martin
Keith David Bershatsky
2015-09-06 22:01:28 UTC
Permalink
Using a brand new download of the Emacs master repository and a fresh copy of the patch, I ran:

git apply frame.c.diff

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

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


I ran: git diff

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

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

At Sun, 06 Sep 2015 21:26:54 +0200,
Post by martin rudalics
Post by Keith David Bershatsky
With respect to the patch, I believe it was applied successfully -- I selected the option "y".
[* * *]HOME$ patch -p1 < frame.c.diff
patching file src/frame.c
Reversed (or previously applied) patch detected! Assume -R? [n] y
Strange. Are you sure you had a pristine frame.c? What does git diff
give for your Emacs tree?
Post by Keith David Bershatsky
Hunk #3 succeeded at 4840 (offset 9 lines).
If you have no private changes in frame.c do a C-x v u in a buffer
showing frame.c and afterwards do
git apply frame.c.diff
followed by make.
* * *
martin rudalics
2015-09-07 07:05:11 UTC
Permalink
Post by martin rudalics
git apply frame.c.diff
error: patch failed: src/frame.c:537
error: src/frame.c: patch does not apply
My apologies. I've sent you a completely unrelated old patch while the
new one happened to end up in the wrong directory. The present one
should be OK.

martin
Keith David Bershatsky
2015-09-07 17:53:31 UTC
Permalink
The latest patch was successfully applied, and building occurred without incident.

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

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

Keith
martin rudalics
2015-09-08 08:29:23 UTC
Permalink
Post by Keith David Bershatsky
When using the setting of `(setq ns-auto-hide-menu-bar t)`
Is this necessary to trigger the behavior?
Post by Keith David Bershatsky
and a
`make-frame` with pixelwise parameters for width/height, the result
when creating large frames -- (width 1909.0) (height . 1060.0) -- is a
frame that is one-half above the screen (out of sight) and one-half of
the frame is showing. Adding a parameter of (top . 0) has no affect.
Probably because, as you say below, a height of 1060.0 makes the frame
have 1086 pixels outer height which is too large for your screen.
Post by Keith David Bershatsky
The pixelwise frame parameters of width/height for `make-frame` are
not behaving precisely -- e.g., a height specification of (height
. 1059.0) is 14 pixels shy of filling the entire screen [i.e., 1066
pixels outer width]; and a height specification of (height . 1060.0)
is 6 pixels larger than the full screen [i.e., 1086 pixels outer
width]. It is not presently possible to create a frame that precisely
fills the entire screen using the patch as-is.
I don't know how you calculated your values but I'll try to explain
what happens here. Suppose with emacs -Q I do

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

Then I get a frame where

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

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

Evaluating

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

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

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

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

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

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

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

Keith
martin rudalics
2015-09-08 19:22:07 UTC
Permalink
Post by Keith David Bershatsky
With this feature request (#21415), I was hoping to incorporate the
magic of `set-frame-size` with the pixelwise argument. That function
is magical because it lets a user precisely control the outer
dimensions of a frame on OSX -- i.e., a user can make the outer
dimensions exactly one or more pixels larger or smaller.
There is no magic at all in ‘set-frame-size’. Just that at the time you
call that function all those annoying calculations like how large is my
title bar or the external border have been already done by the window
manager. And ‘set-frame-size’ doesn't have to care about idiosyncrasies
like adding fringe or scroll bar widths.
Post by Keith David Bershatsky
The patch, from what I understand, seeks to convert pixel
specifications into the standard character width and standard text
line height.
No. These values are set eventually just like when you call
‘set-frame-size’.
Post by Keith David Bershatsky
I believe that method cannot be used to precisely
control the pixel outer dimensions of the frame.
It can. But if and only if you know, for example, how large the title
bar and the external borders are.
Post by Keith David Bershatsky
The feature request (as I understand it) seeks to control the exact
pixel height/width of the outer frame -- irregardless of the character
width and text line height.
The character width and text line height are not consulted. Provided
you have set ‘frame-resize-pixelwise’ to t.
Post by Keith David Bershatsky
For example, the laptop that I am using
today uses the following: `(set-frame-size FRAME 1260 774 t)` to
precisely fill the display. The corresponding frame parameters are
(width . 114) (height . 38); however, those are insufficient to fill
the screen precisely.
These frame parameters contain rounded values. Just ignore them.
Post by Keith David Bershatsky
I can get close (but no cigar) with (width
. 114) (height . 38), and then I need to use `(set-frame-size FRAME
1260 774 t)` to fix what `make-frame` cannot accomplish.
Have you tried to do the calculations I sent you in my previous mail?
Once you've done them, ‘make-frame’ should be able to do what you want.

martin
Keith David Bershatsky
2015-09-09 00:38:35 UTC
Permalink
I have tracked down the cause of the problem, but I do not know how to fix it.

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

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

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

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

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

I am using `set-frame-position` to compensate for `ns-auto-hide-menu-bar`, which prevents successfully setting `top` (and maybe `left`) as part of the `make-frame` parameters.
martin rudalics
2015-09-09 06:27:37 UTC
Permalink
Post by Keith David Bershatsky
Is there
any way to prevent `set-face-attribute` from ruining the outer frame
dimensions that are created with `make-frame`?
Customizing ‘frame-inhibit-implied-resize’ to t should accomplish that.

martin
Keith David Bershatsky
2015-09-09 14:30:54 UTC
Permalink
Thank you for the suggestion. I tried:

(setq frame-inhibit-implied-resize t)

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

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

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

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

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

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

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

At Wed, 09 Sep 2015 08:27:37 +0200,
Post by Keith David Bershatsky
Is there
any way to prevent `set-face-attribute` from ruining the outer frame
dimensions that are created with `make-frame`?
Customizing ‘frame-inhibit-implied-resize' to t should accomplish that.
martin
martin rudalics
2015-09-09 15:53:06 UTC
Permalink
Post by Keith David Bershatsky
(set-face-attribute 'default nil :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
Here the frame size remains unaltered. What happens when you do that on
a maximized frame? And what does evaluating

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

return?

martin
Keith David Bershatsky
2015-09-09 16:26:00 UTC
Permalink
Step 1: M-x toggle-frame-maximized

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

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


Evaluating the following from a default frame when Emacs opens:

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

RESULT:

(998 (#<frame *Minibuf-1* 0x104078830> adjust-frame-size-3 (560 560 880 700) (595 564 915 704)) (#<frame *Minibuf-1* 0x104078830> adjust-frame-size-1 (560 560 880 700) (change-frame-size 5)))
martin rudalics
2015-09-09 17:11:18 UTC
Permalink
Post by Keith David Bershatsky
Step 1: M-x toggle-frame-maximized
Step 2 [evaluate]: (set-face-attribute 'default nil :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
RESULT: The frame substantially increases in size, going from maximized to extending well beyond the right edge of the screen.
That's bad. Please try the attached patch (completely untested, might
crash your Emacs).

martin
Keith David Bershatsky
2015-09-10 00:46:51 UTC
Permalink
The patch of `nsterm.m` has repaired much of the functionality of `frame-inhibit-implied-resize`. The two tests that previously failed now work as expected:

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

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

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

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

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

;; BROKEN
(let* (
(frame-inhibit-implied-resize t)
(frame
(make-frame '(
(font . "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
(vertical-scroll-bars)
(left-fringe . 8)
(right-fringe . 8)
(width . 1259.0)
(height . 771.0)
(tool-bar-lines . 0)))) )
(set-frame-position frame 0 0))
martin rudalics
2015-09-10 06:57:25 UTC
Permalink
Post by Keith David Bershatsky
The patch of `nsterm.m` has repaired much of the functionality of
`frame-inhibit-implied-resize`. The two tests that previously failed
1. From a maximized frame, I can change the `font` to Courier
18 using `set-face-attribute` and there is no need to set
`frame-inhibit-implied-resize` in that circumstance.
I'm afraid that setting ‘frame-inhibit-implied-resize’ would't have
helped anyway in that case.
Post by Keith David Bershatsky
2. From a frame that is smaller than the screen size, I can use
`set-face-attribute` to change the font to Courier 18
provided that `frame-inhibit-implied-resize` is set to `t`.
OK. Together with the two I sent earlier I attach one additional
change, this time for the tool bar. You don't use it, so it shouldn't
affect you. Nevertheless keep it included, it might have side effects.
Post by Keith David Bershatsky
The problem I am having is with a situation where
`ns-auto-hide-menu-bar` is set to `t`. As previously noted in this
thread, the `top` frame parameter is ignored when making a new frame
that is the size of the screen -- the new frame appears substantially
above the top of the display -- i.e., one-half out of sight. When the
new frame is partially above the top of the screen,
`set-face-attribute` substantially enlarges the frame even though
`frame-inhibit-implied-resize` is set to `t`. When the frame comes
back into full view (e.g., top 0, left 0), it is then possible to
apply `set-face-attribute` without altering the dimensions of the
frame. The following are two examples -- one example works, the other
example is broken -- both rely upon `ns-auto-hide-menu-bar` being set
to `t`.
(setq ns-auto-hide-menu-bar t)
;; WORKS
(let* (
(frame-inhibit-implied-resize t)
(frame
(make-frame '(
(vertical-scroll-bars)
(left-fringe . 8)
(right-fringe . 8)
(width . 1259.0)
(height . 771.0)
(tool-bar-lines . 0)))) )
(set-frame-position frame 0 0)
(set-face-attribute 'default frame :font "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1"))
;; BROKEN
(let* (
(frame-inhibit-implied-resize t)
(frame
(make-frame '(
(font . "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
(vertical-scroll-bars)
(left-fringe . 8)
(right-fringe . 8)
(width . 1259.0)
(height . 771.0)
(tool-bar-lines . 0)))) )
(set-frame-position frame 0 0))
I have no idea what this small segment in nsterm.m

if (ns_menu_bar_should_be_hidden ())
return frameRect;

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

martin
Keith David Bershatsky
2015-09-10 18:39:01 UTC
Permalink
We are in the home-stretch -- i.e., making significant progress! :)

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

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

if (ns_menu_bar_should_be_hidden ())
return frameRect;

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

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


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

;; BROKEN -- unless `frame-after-make-frame` is called BEFORE `set-face-attribute`.
(let* (
(frame-inhibit-implied-resize t)
(frame
(make-frame '(
(font . "-*-Courier-normal-normal-normal-*-18-*-*-*-m-0-iso10646-1")
(vertical-scroll-bars)
(left-fringe . 8)
(right-fringe . 8)
(width . 1259.0)
(height . 771.0)
(tool-bar-lines . 0)))) )
;; (set-frame-position frame 0 0)
)
martin rudalics
2015-09-12 11:11:16 UTC
Permalink
Post by Keith David Bershatsky
Commenting out the following small segment in `nsterm.m` fixes the
problem with large frames being created partially above the top of the
display -- i.e., it is no longer necessary to correct the bug by
following a `make-frame` with `set-frame-position` (to move it
squarely onto the screen) when `ns-auto-hide-menu-bar` is set to `t`.
As it stands now, the default position is `top 0` and `left 0` --
perfect!
if (ns_menu_bar_should_be_hidden ())
return frameRect;
That check probably had a purpose. Anders, what's your opinion on
removing it?

Thanks, martin
Anders Lindgren
2015-09-12 19:57:35 UTC
Permalink
Hi Martin and Keith!

Unfortunately, removing the suggested lines break another feature.

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

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

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

Sincerely,
Anders Lindgren

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

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

;; ----------------------------------------;; Exit auto hide menu;;;;
Redisplay the menu bar. After this, the frame should be placed;;
*below* the menu bar.(setq ns-auto-hide-menu-bar nil)
;; ns-frame-test.el ends here.
Post by martin rudalics
Post by Keith David Bershatsky
Commenting out the following small segment in `nsterm.m` fixes the
problem with large frames being created partially above the top of the
display -- i.e., it is no longer necessary to correct the bug by
following a `make-frame` with `set-frame-position` (to move it
squarely onto the screen) when `ns-auto-hide-menu-bar` is set to `t`.
As it stands now, the default position is `top 0` and `left 0` --
perfect!
if (ns_menu_bar_should_be_hidden ())
return frameRect;
That check probably had a purpose. Anders, what's your opinion on
removing it?
Thanks, martin
martin rudalics
2015-09-13 09:02:08 UTC
Permalink
Post by Anders Lindgren
Unfortunately, removing the suggested lines break another feature.
The system is designed so that it should be possible to programmatically
place the top of the frame above the top of the screen (when the menu bar
is hidden). This is useful to hide the window title so that the full height
of the screen can be utilised to edit text. When the suggested patch is
applied, this no longer is possible.
OK. But this _is_ a different issue we could customize appropriately.
Auto hiding the menu bar should not unconditionally require to hide the
title bar as well. So we could easily add an additional value to
‘ns-auto-hide-menu-bar’, say 'hide-menu-bar-only, where we only hide the
menu bar and still constrain the frame to the screen. Both nil and t
would mean to leave the current behavior unchanged. WDYT?
Post by Anders Lindgren
I would say that the problem is not related to this, but to `make-frame'
itself. When a weight higher than the default is specified,
What is a "weight higher than the default"? I suppose you mean "height"
but I still don't understand. What is the "default"?
Post by Anders Lindgren
it should
adjust the window to start further down.
Further "up" maybe?
Post by Anders Lindgren
As it is today, it always seem to
start mid screen.
IIUC Emacs does _not_ ask for a specific start position. If it does we
could remove that. Eventually it's always up to the WM to put the
window where it wants to.
Post by Anders Lindgren
Below is a small test file I have used to test the frame placement
features. If you come up with another solution, you can use it to check
that it doesn't break existing features. By the way, it's not intended to
be loaded, instead follow the comment and evaluate the expression one by
one and check that the result is as described in the file.
This one appears severely mangled by one of our MUAs. But I have no OS
X here to check this anyway. Maybe Keith can comment.
Post by Anders Lindgren
;; ns-frame-test.el --- test for NextStep (Mac OS X) frame
positioning.;; Author: Anders Lindgren;; This file is *not* intended
...

Thanks for the quick response, martin
martin rudalics
2015-09-12 11:12:11 UTC
Permalink
Post by Keith David Bershatsky
I had previously thought that the above-mentioned problem (now fixed)
was responsible for the frame increasing in size with the example
labeled BROKEN. I see now that the difference between the WORKING
example and the BROKEN example is caused by the fact that
`frame-after-make-frame` has already run in the WORKING example before
`set-face-attribute` is called with the `font` parameter. If we
modify `x-create-frame-with-faces` by commenting out
`(face-set-after-frame-default frame parameters)` and move that over
to `make-frame` following `(frame-after-make-frame frame t)`, then
both examples work as expected.
I understand that may not be the preferred solution, but at least we
know for sure that calling `frame-after-make-frame` BEFORE
`set-face-attribute` fixes the problem with the frame expanding even
though `frame-inhibit-implied-resize` is set to `t`.
Yes. I forgot that we try to keep the number of lines and faces
constant when making the initial frame. Try the attached patch. It
should cover everything we have investigated so far. Unfortunately, it
won't work with an internal tool bar like we have on Lucid, Motif, and
Windows. There's something I haven't fathomed yet :-(

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

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

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

Keith
Keith David Bershatsky
2015-09-12 23:09:08 UTC
Permalink
Anders: Thank you for weighing in and vetoing the proposed revision -- your insight is greatly appreciated.

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

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

@@ -7196,8 +7196,8 @@ if (cols > 0 && rows > 0)
NSTRACE (constrainFrameRect);
NSTRACE_RECT ("input", frameRect);

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

if (nr_screens == 1)
return [super constrainFrameRect:frameRect toScreen:screen];

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

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

Keith
martin rudalics
2015-09-13 09:02:24 UTC
Permalink
Post by Keith David Bershatsky
I am now able to achieve a frame size of 1920 x 1080 on a screen that
is 1920 x 1080; there is no longer any problem with the frame moving
when touching the menubar; and the frame title is working as it should
be.
This, however, seems to hint at some unplesant locking of the auto hide
menu bar feature with the auto hide frame title feature. Conceptually,
these should work independently from each other.
Post by Keith David Bershatsky
So, the issue now remaining is how to let `make-frame` respect a frame
parameter of `(top . 0)` upon frame creation when a user has `(setq
ns-auto-hide-menu-bar t)`. As it stands now, it is necessary to
programmatically call `(set-frame-size FRAME 0 0)` subsequent to each
frame being created, and am doing the same each time Emacs starts for
the initial frame.
Maybe Anders has an idea why on OS X we apparently ignore the ‘top’ and
‘left’ parameters.

martin
Keith David Bershatsky
2015-09-12 23:13:26 UTC
Permalink
I meant to say that I call `(set-frame-position FRAME 0 0)` to fix the inability to use `(top . 0)` as a frame parameter argument on frame creation when `ns-auto-hide-menu-bar` is set to `t`.
Anders Lindgren
2015-09-13 07:10:19 UTC
Permalink
Hi,

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

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

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

Sincerely,
Anders Lindgren
Post by Keith David Bershatsky
I meant to say that I call `(set-frame-position FRAME 0 0)` to fix the
inability to use `(top . 0)` as a frame parameter argument on frame
creation when `ns-auto-hide-menu-bar` is set to `t`.
martin rudalics
2015-09-13 09:02:45 UTC
Permalink
Post by Anders Lindgren
I just checked this against Emacs 24.5. In that version, new frames always
start at 0 x 0, no matter how high they are. In addition, both versions
seem to react to the `top' property -- in Emacs 24 the window is placed
relative to the top (as expected). In Emacs 25 the start position when the
parameter is missing or is zero places the bottom of the frame in the
middle-ish of the screen, and a positive value for `top' places it further
down on the screen.
I would suggest that we try to find why Emacs 24 and 25 differs, so we can
revert back to the old behaviour.
Agreed. Could you or Keith please do that? No OS X around here.
Post by Anders Lindgren
A side topic: The documentation to `make-frame' seems a little bit vague.
It doesn't include `top' as an attribute, on the other hand doesn't say
that it accepts more properties than the ones listed.
We don't mention most of the parameters. Funnily, ‘top’ is indirectly
referred to here:

Note that on multi-monitor displays (*note Multiple Terminals::),
the window manager might position the frame differently than
specified by the positional parameters in ALIST (*note Position
Parameters::). For example, some window managers have a policy of
displaying the frame on the monitor that contains the largest part
of the window (a.k.a. the "dominating" monitor).
Post by Anders Lindgren
In addition, is the
limitation when it comes to `width' and `height' correct ("You cannot
specify either `width' or `height', you must specify neither or both.")? If
seems to work just fine when I supply only a `height' property.
I don't even understand where and how we were able to apply such a
restriction in the first place. Anyway, we should rewrite both
doc-string and documentation. As someone who always works with a single
main frame I have no practice with this function though. So I'm
probably not the ideal choice for that task.

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

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

martin
Anders Lindgren
2015-09-13 20:21:37 UTC
Permalink
If ‘ns-auto-hide-menu-bar’ non-nil also moves the title bar off screen,
you can't position the frame at (0, 0). Or am I missing something?
No, ns-auto-hide-menu-bar does not move the frame at all. The user is
allowed to place the frame above the top of the screen, but this does not
occur automatically. In other words, a frame can be placed at (0, 0).

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

--Anders

Ps. Martin, sorry for the double post, but I realised that I had dropped
the other recipients, so I decided to resend it with a full "To:" list.
Martin: I wanted to clarify the concept/feature referred to by Anders
for hiding the window title bar on OSX. OSX does not offer this
feature. What some users are doing is positioning the frame partially
above the display so they cannot see the window frame title. For
example, instead of (0 0 1920 1080) it would be (0 -22 1920 1102).
The gain is about one extra line of text and less visual distraction.
If ‘ns-auto-hide-menu-bar’ non-nil also moves the title bar off screen,
you can't position the frame at (0, 0). Or am I missing something?
martin
Anders Lindgren
2015-09-14 09:37:46 UTC
Permalink
Hi,
Post by Anders Lindgren
If ‘ns-auto-hide-menu-bar’ non-nil also moves the title bar off screen,
you can't position the frame at (0, 0). Or am I missing something?
No, ns-auto-hide-menu-bar does not move the frame at all.
OK. But doesn't it remove the constraint that a frame's rectangle must
start somehwere at or below (0, 0)?
When the menu bar is visible, OS X doesn't allow windows above the menu
bar. When it is hidden, it's not possible to drag a window above the top of
the screen. However, OS X allows an application to place a window above the
top of the screen -- the code in Emacs simply ensures that Emacs itself
doesn't hinder this.

By the way, when I use Win32, I also place the title bar above the top of
the screen, so this is not a feature that is unique to the OS X port. Of
course, for a frame the be placed above the top of the screen, the user
must explicitly placed it there. A frame should never "just happen" to be
placed above the top of the screen.
I lost you. I thought that ‘ns-auto-hide-menu-bar’ non-nil means to
also automatically hide the title bar. Am I wrong?
Yes, you are wrong!

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

However, when the menu bar is hidden the user can place the top of the
frame at a negative offset (i.e. above the top of the screes), but this
must be done explicitly. Most users won't use this feature, but it's
important to those that do.
But how comes that for Keith the frame is apparently placed above the
top of the screen although he didn't specify it?
Clearly, this is a bug -- the frame should not be placed above the top of
the screen in this case.

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

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

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

/ Anders
Post by Anders Lindgren
If ‘ns-auto-hide-menu-bar’ non-nil also moves the title bar off screen,
you can't position the frame at (0, 0). Or am I missing something?
No, ns-auto-hide-menu-bar does not move the frame at all.
OK. But doesn't it remove the constraint that a frame's rectangle must
start somehwere at or below (0, 0)?
Post by Anders Lindgren
The user is
allowed to place the frame above the top of the screen, but this does not
occur automatically. In other words, a frame can be placed at (0, 0).
But how comes that for Keith the frame is apparently placed above the
top of the screen although he didn't specify it?
Post by Anders Lindgren
To answer your earlier questions. You were speculating about adding
another
Post by Anders Lindgren
variable for "the auto hide frame title feature". However, I don't think
this is a good idea since there is no such feature. Hiding the frame
title
Post by Anders Lindgren
requires the user to explicitly move the frame (or use a package that
does
Post by Anders Lindgren
this, like my "multicolumn" package).
I lost you. I thought that ‘ns-auto-hide-menu-bar’ non-nil means to
also automatically hide the title bar. Am I wrong?
martin
martin rudalics
2015-09-14 13:39:46 UTC
Permalink
Post by Anders Lindgren
Post by Anders Lindgren
No, ns-auto-hide-menu-bar does not move the frame at all.
OK. But doesn't it remove the constraint that a frame's rectangle must
start somehwere at or below (0, 0)?
When the menu bar is visible, OS X doesn't allow windows above the menu
bar.
I'm not sure I understand: Do you mean here "OS X doesn't allow windows
above the top of the screen"?
Post by Anders Lindgren
When it is hidden, it's not possible to drag a window above the top of
the screen.
I've never been able to "drag" a window above the top of the screen
because on all machines I know of the title bar is the handle for
dragging.
Post by Anders Lindgren
However, OS X allows an application to place a window above the
top of the screen -- the code in Emacs simply ensures that Emacs itself
doesn't hinder this.
Does this "OS X allows an application to place a window above the top of
the screen" hold _only_ when the menu bar is hidden or does it hold
regardless of that? What's such a restriction good for anyway?
Post by Anders Lindgren
-- the code in Emacs simply ensures that Emacs itself
doesn't hinder this.
Because Emacs "normally" advices OS X to constrain the frame to the
screen. Correct?
Post by Anders Lindgren
By the way, when I use Win32, I also place the title bar above the top of
the screen,
Why? Do you never use the fullscreen feature?
Post by Anders Lindgren
so this is not a feature that is unique to the OS X port. Of
course, for a frame the be placed above the top of the screen, the user
must explicitly placed it there. A frame should never "just happen" to be
placed above the top of the screen.
It will happen when it's too large and you specify negative values for
its position.
Post by Anders Lindgren
Hiding the menu bar only hides the menu bar -- it does not move the frame
or hide the title bar.
OK.
Post by Anders Lindgren
However, when the menu bar is hidden the user can place the top of the
frame at a negative offset (i.e. above the top of the screes), but this
must be done explicitly. Most users won't use this feature, but it's
important to those that do.
OK. The "when" might be an answer to one of my questions above.
Post by Anders Lindgren
But how comes that for Keith the frame is apparently placed above the
top of the screen although he didn't specify it?
Clearly, this is a bug -- the frame should not be placed above the top of
the screen in this case.
In Emacs 24, this didn't happen. Why this happens in Emacs 25, I don't
know, but clearly this is not the way we want the system to work.
The desired behavior is to place the top of the frame at the top of the
screen, or right below the menu bar (if it's present). If a `top' attribute
is present, the window should be placed accordingly. Also, a frame that is
too high for the screen should stretch down below the bottom of the screen,
like it did in Emacs 24.
Agreed.
Post by Anders Lindgren
I have tried to trace it through the various functions -- it seems that
Emacs tries to place the frame at the top of the screen (which is where we
want it) but at a later phase, the frame is somehow moved and/or constraint
to an incorrect location. This may take some time, however, given that I
have small children and a full time job, but I will try to find some time
for it during this or (more likely) next week.
Fine.

Thanks for your efforts, martin
Anders Lindgren
2015-09-14 14:45:33 UTC
Permalink
Post by martin rudalics
Post by Anders Lindgren
Post by Anders Lindgren
No, ns-auto-hide-menu-bar does not move the frame at all.
OK. But doesn't it remove the constraint that a frame's rectangle must
start somehwere at or below (0, 0)?
When the menu bar is visible, OS X doesn't allow windows above the menu
bar.
I'm not sure I understand: Do you mean here "OS X doesn't allow windows
above the top of the screen"?
It's not possible to place a window above the top of the screen if the menu
bar is visible. (If I remember correctly, I haven't worked in this for
quite some time.)
Post by martin rudalics
However, OS X allows an application to place a window above the
Post by Anders Lindgren
top of the screen -- the code in Emacs simply ensures that Emacs itself
doesn't hinder this.
Does this "OS X allows an application to place a window above the top of
the screen" hold _only_ when the menu bar is hidden or does it hold
regardless of that? What's such a restriction good for anyway?
Only when it is hidden (again, if I remember correctly). The reason, I
guess, is to ensure that no application would ever land underneath the menu
bar.
Post by martin rudalics
Post by Anders Lindgren
-- the code in Emacs simply ensures that Emacs itself
doesn't hinder this.
Because Emacs "normally" advices OS X to constrain the frame to the
screen. Correct?
No, not really. A frame can stretch below the screen, and (I have to
double-check this one when I get home) to either side.

When the menu bar is hidden, you can also do this above the screen.
Post by martin rudalics
Post by Anders Lindgren
By the way, when I use Win32, I also place the title bar above the top of
the screen,
Why? Do you never use the fullscreen feature?
No, never.

The reason is that I want the Emacs frame to use maximal height, but at the
same time I like to control the width so that I can have six side-by-side
windows each with exactly 79 columns. (I use two 1600x1200 monitors and a
6x8 font, with the help of Follow mode I can see 888 consecutive lines of
code.)
Post by martin rudalics
so this is not a feature that is unique to the OS X port. Of
Post by Anders Lindgren
course, for a frame the be placed above the top of the screen, the user
must explicitly placed it there. A frame should never "just happen" to be
placed above the top of the screen.
It will happen when it's too large and you specify negative values for
its position.
Yes, but I would see that as though the user explicitly has asked for that
case.

The important thing is that it doesn't happen when a user creates a new
frame using `C-x 5 2' or call `make-frame' with default parameters etc.

/ Anders
martin rudalics
2015-09-14 17:37:42 UTC
Permalink
Post by Anders Lindgren
The reason is that I want the Emacs frame to use maximal height, but at the
same time I like to control the width so that I can have six side-by-side
windows each with exactly 79 columns. (I use two 1600x1200 monitors and a
6x8 font, with the help of Follow mode I can see 888 consecutive lines of
code.)
Then you should see the same problems as Keith with the frame not
covering the entire screen (or workarea). I presume you can live with
that.

martin
Anders Lindgren
2015-09-14 19:03:03 UTC
Permalink
Post by martin rudalics
Then you should see the same problems as Keith with the frame not
covering the entire screen (or workarea). I presume you can live with
that.
I have a font that is an even multiple of the screensize, so I don't have a
problem with that.

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

/ Anders
martin rudalics
2015-09-15 08:29:42 UTC
Permalink
Post by Anders Lindgren
I have a font that is an even multiple of the screensize, so I don't have a
problem with that.
You're lucky. External borders, tool bar and menu bar often mess things
up.

martin
Anders Lindgren
2015-09-19 21:12:40 UTC
Permalink
Hi,

Below is a patch that should correct the problem:

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

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

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

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

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

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

Sincerely,
Anders
Post by Keith David Bershatsky
Post by Anders Lindgren
I have a font that is an even multiple of the screensize, so I don't
have a
Post by Anders Lindgren
problem with that.
You're lucky. External borders, tool bar and menu bar often mess things
up.
martin
martin rudalics
2015-09-19 22:17:10 UTC
Permalink
Thanks. But pretty please send it as an attachment. Here it arrived
Post by Anders Lindgren
diff --git a/src/nsterm.m b/src/nsterm.m
index 2806f31..14f2beb 100644--- a/src/nsterm.m
frame *f, int tb = FRAME_EXTERNAL_TOOL_BAR (f);
int pixelwidth, pixelheight;
int rows, cols;+ int orig_height = wr.size.height;
NSTRACE (x_set_window_size);
@@ -1386,7 +1387,7 @@ x_set_window_size (struct frame *f, if
(f->output_data.ns->zooming)
f->output_data.ns->zooming = 0;
else- wr.origin.y += FRAME_PIXEL_HEIGHT (f) - pixelheight;+
wr.origin.y += orig_height - wr.size.height;
[view setRows: rows andColumns: cols];
[window setFrame: wr display: YES];
Effectively, this will ensure that whenever the height of a frame is
changed, the origin (the distance from the lower left corner of the display
to the lower left hand corner of the frame) is updated accordingly.
Can you please tell us why the "origin" on OS X is apparently the lower
left corner? Where can I read about this?

martin
Anders Lindgren
2015-09-20 07:25:30 UTC
Permalink
Hi,

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

You can read more about "screen coordinates" here:

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

Sincerely,
Anders
Post by martin rudalics
Thanks. But pretty please send it as an attachment. Here it arrived
Post by Anders Lindgren
diff --git a/src/nsterm.m b/src/nsterm.m
index 2806f31..14f2beb 100644--- a/src/nsterm.m
frame *f, int tb = FRAME_EXTERNAL_TOOL_BAR (f);
int pixelwidth, pixelheight;
int rows, cols;+ int orig_height = wr.size.height;
NSTRACE (x_set_window_size);
@@ -1386,7 +1387,7 @@ x_set_window_size (struct frame *f, if
(f->output_data.ns->zooming)
f->output_data.ns->zooming = 0;
else- wr.origin.y += FRAME_PIXEL_HEIGHT (f) - pixelheight;+
wr.origin.y += orig_height - wr.size.height;
[view setRows: rows andColumns: cols];
[window setFrame: wr display: YES];
Effectively, this will ensure that whenever the height of a frame is
changed, the origin (the distance from the lower left corner of the
display
Post by Anders Lindgren
to the lower left hand corner of the frame) is updated accordingly.
Can you please tell us why the "origin" on OS X is apparently the lower
left corner? Where can I read about this?
martin
martin rudalics
2015-09-20 08:44:02 UTC
Permalink
Post by Anders Lindgren
I've attached the patch, sorry for posting it in the mail.
Thank you. Keith please try it. If it fixes all remaining issues I'll
try to commit everything we have now next week.
Post by Anders Lindgren
https://developer.apple.com/library/ios/documentation/General/Conceptual/Devpedia-CocoaApp/CoordinateSystem.html
Thanks. I'm slightly confused, at least - I have no idea what flipping
means. Can you have a short look at the section "Frame Geometry" in the
Elisp manual? Maybe I should mention something about this issue there.

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

martin
Anders Lindgren
2015-09-20 09:27:43 UTC
Permalink
Martin,

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

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

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

/ Anders
Post by martin rudalics
Post by Anders Lindgren
I've attached the patch, sorry for posting it in the mail.
Thank you. Keith please try it. If it fixes all remaining issues I'll
try to commit everything we have now next week.
https://developer.apple.com/library/ios/documentation/General/Conceptual/Devpedia-CocoaApp/CoordinateSystem.html
Thanks. I'm slightly confused, at least - I have no idea what flipping
means. Can you have a short look at the section "Frame Geometry" in the
Elisp manual? Maybe I should mention something about this issue there.
And do you have any idea why this apparently worked in Emacs 24.5 and
doesn't work with present master/trunk?
martin
martin rudalics
2015-09-20 09:54:09 UTC
Permalink
Post by Anders Lindgren
I just hope I didn't confuse you with the "screen coordinates" stuff. From
an Emacs users point of view (and from the point of view of elisp) the
UPPER LEFT corner is 0x0 -- as it is on every other system. The fact that
OS X see everything from the lower left corner is handled by internally by
"nsterm.m".
I guessed so but wanted your confirmation.
Post by Anders Lindgren
Hence, there is no need to mention this in the manual.
"Flipping" mean that the coordinate system is mirrored, in some way. I
guess it could be used to set the upper left as the origin, but I'm not
that into OS X to tell you how that is done and what other consequences
that would have for the Emacs code base.
Unfortunately, I have no idea why it worked in 24.5 and why it didn't in
25. There has been a lot of changes along the way, so one would have to
inspect each one to see what changed, and why.
No need to investigate if it works now. Hopefully we can count on you
when we see similar problems. After Jan's resignation we need all the
help we can get.

Many thanks, martin
Anders Lindgren
2015-09-20 18:29:54 UTC
Permalink
Hopefully we can count on you when we see similar problems. After Jan's
resignation we need all the help we can get.
If I can help, I will try to do so. I know the code base relatively well,
even though I've only authored a fraction of it.

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

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

Sincerely,
Anders Lindgren
martin rudalics
2015-09-21 09:42:28 UTC
Permalink
Post by Anders Lindgren
I don't have write access to the Emacs repository, so someone would have to
commit this for me, if it gets accepted.
Committed to trunk/master.

Thanks again, martin
Keith David Bershatsky
2015-09-13 18:36:43 UTC
Permalink
I have been able to reproduce the disregarding `top` frame parameter error with a much simpler example that does not involve `ns-auto-hide-menu-bar`. I'm not sure why these simple tests are intermittently crashing the Emacs application with no user settings.

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

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

And here is an unsophisticated hack:

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



At Sun, 13 Sep 2015 20:01:03 +0200,
If ‘ns-auto-hide-menu-bar' non-nil also moves the title bar off screen,
you can't position the frame at (0, 0). Or am I missing something?
martin
martin rudalics
2015-09-14 08:31:30 UTC
Permalink
Post by Keith David Bershatsky
I have been able to reproduce the disregarding `top` frame parameter
error with a much simpler example that does not involve
`ns-auto-hide-menu-bar`. I'm not sure why these simple tests are
intermittently crashing the Emacs application with no user settings.
What does "crashing" mean in this context?
Post by Keith David Bershatsky
;; WORKING -- respects `top` parameter.
(make-frame '(
(top . 50)
(left . 50)
;; (height . 250.0)
(width . 250.0)))
;; BROKEN -- disregards `top` parameter.
(make-frame '(
(top . 50)
(left . 50)
(height . 250.0)
(width . 250.0)))
Anders said this worked in emacs 24.5 and doesn't work nowadays. We'd
have to find the commit that broke that. I can't.

martin
martin rudalics
2015-09-14 08:32:21 UTC
Permalink
Post by Keith David Bershatsky
I have been able to reproduce the disregarding `top` frame parameter
error with a much simpler example that does not involve
`ns-auto-hide-menu-bar`. I'm not sure why these simple tests are
intermittently crashing the Emacs application with no user settings.
;; WORKING -- respects `top` parameter.
(make-frame '(
(top . 50)
(left . 50)
;; (height . 250.0)
(width . 250.0)))
;; BROKEN -- disregards `top` parameter.
(make-frame '(
(top . 50)
(left . 50)
(height . 250.0)
(width . 250.0)))
Can you step through x_set_offset to find out which offsets we provide
and what we eventually pass on?

martin
Keith David Bershatsky
2015-09-13 18:53:12 UTC
Permalink
I closed out all the open Emacs instances and the crashing issue is gone, so that potential issue is moot.

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

Thanks,

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

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

In set_menu_bar_lines call change_frame_size instead of set_menu_bar_lines_1.

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

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

Fix default width not being 80, but 77.

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

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

(defadvice face-set-after-frame-default (before face-set-after-frame-default-before activate)
(let* (
(top (or (cdr (assq 'top parameters)) 0))
(left (or (cdr (assq 'left parameters)) 0)) )
(set-frame-position frame left top)))
martin rudalics
2015-09-14 17:37:52 UTC
Permalink
Post by Keith David Bershatsky
The `top` frame parameter is respected when setting the `height` frame
parameter in the Emacs built on August 11, 2014, but is broken in the
Emacs built on August 12, 2014. I was not able to revert due to error
messages about merging and so forth, but my best guess is that either
commit bd4de70f13a92230da479e6fcd87d4355d626edf
Date: Tue Aug 12 11:47:27 2014 +0200
In set_menu_bar_lines call change_frame_size instead of set_menu_bar_lines_1.
* frame.c (set_menu_bar_lines_1): Remove.
(set_menu_bar_lines): Call change_frame_size instead of
set_menu_bar_lines_1.
This one shouldn't affect OS X at all.
Post by Keith David Bershatsky
commit fe2f33e8da2e2c7950214eafdfd610f164025baf
Date: Mon Aug 11 15:16:31 2014 +0200
Fix default width not being 80, but 77.
* nsfns.m (Fx_create_frame): Call adjust_frame_size,
set f->official.
No idea about this either.

martin
Keith David Bershatsky
2015-09-20 16:47:50 UTC
Permalink
The latest patch by Anders is working well with the following tests:

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

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

(make-frame)

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

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

Thanks,

Keith
Anders Lindgren
2015-09-20 18:31:31 UTC
Permalink
Post by Keith David Bershatsky
The `top` frame parameter is now respected. When the `top` and `left`
frame parameters are not included and `ns-auto-hide-menu-bar` is set to
`t`, the default position is 0 0, even for large frames that are the size
of the display -- very good!
Great news!

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

/ Anders
martin rudalics
2015-09-21 09:43:29 UTC
Permalink
Post by Anders Lindgren
Are there any other open issues, or does this cover everything?
According to Keith one issue raised in this thread was that maximizing
the Emacs frame does not really maximize it on OS X. In particular he
said that

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

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

martin
Anders Lindgren
2015-09-21 18:56:42 UTC
Permalink
Can you confirm that ‘toggle-frame-maximized’ doesn't really maximize
the frame?
Yes, I can confirm this -- sort of.

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

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

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

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

/ Anders
martin rudalics
2015-09-22 06:38:27 UTC
Permalink
Post by Anders Lindgren
In OS X Yosemite, the "maximize" button (the green round button on the top
left of the screen) starts fullscreen mode.
This is what ‘toggle-frame-fullscreen’ is supposed to do.
Post by Anders Lindgren
`toggle-frame-maximized', on the other hand, tries to resize the frame so
that it covers an entire monitor, but without entering full-screen mode
(which is the way it should work).
What if the next OS X generation changes policy again and asks for some
sort of "fullboth"?
Post by Anders Lindgren
Unfortunately, there is a bit of empty
space above and below the Emacs frame. It looks like this is due to the
fact that there isn't enough space to create another full line of text.
When setting `frame-resize-pixelwise' to t, unfortunately, it still doesn't
cover the entire display, and the behaviour is a bit more random, with the
frame repositioning itself slightly differently when
`toggle-frame-maximized' is called multiple times.
We'd have to fix this one way or the other. Maybe by temporarily
collating "fullscreen" and "fullboth" for the NS builds.

The important thing is to synchronize the value of the ‘fullscreen’
frame parameter with the actual state of the frame as seen by both, the
window manager (or the OS) and the user. The state of the frame
includes its size, its decorations and the state of the "maximize"
button. In my experience, having ‘toggle-frame-maximized’ follow
‘toggle-frame-fullscreen’ can be very tricky in this regard.
Post by Anders Lindgren
I didn't manage to make it fill both my monitors, only one. (How does the
command work on other systems?)
I can't tell because I use only one monitor.
Post by Anders Lindgren
The documentation refers to an undefined
variable, x-frame-normalize-before-maximize.
This variable is for X only. I'll fix that in the documentation.

martin
Anders Lindgren
2015-09-22 08:54:03 UTC
Permalink
Hi!

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

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

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

/ Anders
Post by Anders Lindgren
In OS X Yosemite, the "maximize" button (the green round button on the
top
Post by Anders Lindgren
left of the screen) starts fullscreen mode.
This is what ‘toggle-frame-fullscreen’ is supposed to do.
Post by Anders Lindgren
`toggle-frame-maximized', on the other hand, tries to resize the frame so
that it covers an entire monitor, but without entering full-screen mode
(which is the way it should work).
What if the next OS X generation changes policy again and asks for some
sort of "fullboth"?
Post by Anders Lindgren
Unfortunately, there is a bit of empty
space above and below the Emacs frame. It looks like this is due to the
fact that there isn't enough space to create another full line of text.
When setting `frame-resize-pixelwise' to t, unfortunately, it still
doesn't
Post by Anders Lindgren
cover the entire display, and the behaviour is a bit more random, with
the
Post by Anders Lindgren
frame repositioning itself slightly differently when
`toggle-frame-maximized' is called multiple times.
We'd have to fix this one way or the other. Maybe by temporarily
collating "fullscreen" and "fullboth" for the NS builds.
The important thing is to synchronize the value of the ‘fullscreen’
frame parameter with the actual state of the frame as seen by both, the
window manager (or the OS) and the user. The state of the frame
includes its size, its decorations and the state of the "maximize"
button. In my experience, having ‘toggle-frame-maximized’ follow
‘toggle-frame-fullscreen’ can be very tricky in this regard.
Post by Anders Lindgren
I didn't manage to make it fill both my monitors, only one. (How does the
command work on other systems?)
I can't tell because I use only one monitor.
Post by Anders Lindgren
The documentation refers to an undefined
variable, x-frame-normalize-before-maximize.
This variable is for X only. I'll fix that in the documentation.
martin
martin rudalics
2015-09-22 09:36:30 UTC
Permalink
Post by Anders Lindgren
I can take a look at it. However, the experience I had with the previous
bug was that it's immensely hard to follow what happens when it comes to
frame resizing and placement. So what I will do is to first reimplement the
NSTRACE package and then start looking for the problem.
OK. As far as frame resizing is concerned I wrote some rudimentary
Elisp support. Set the variable ‘frame-size-history’ to a value like
'(100) and you will get a (partly cryptic) list of requests to resize a
frame and whether and how the request got honored.
Post by Anders Lindgren
By the way, is
there some kind of deadline coming up?
Not for bugs like this. It's only short before a release that we only
fix regressions introduced since the last release.
Post by Anders Lindgren
Also, things are starting to get so complicated so that we would need to
state what each concept mean so that they can be implemented the same way
on all systems. (When I wrote my "multicolumn" package I found tons and
tons of things that differed between systems, I just want to make sure we
don't introduce more such things.)
One thing that should work uniformly accross platforms is the
‘frame-geometry’ function as well as the recently introduced
‘frame-edges’. Since I was never able to verify these for OS X it would
be a good start to make sure they deliver correct results there first.
Done that, we should have a common platform to discuss the remaining
issues.
Post by Anders Lindgren
In addition, we really must write test
cases automatically walking through all transitions, ensuring that nothing
breaks in the future,
One problem with automatic test cases is that numbers may lie about the
effect you see on screen. For example, Emacs can resize your scroll bar
width with completely correct metrics but since Gtk+ usually refuses to
change scroll bar widths, the visual appearance is devastating. But
obviously, automatic test cases would be very useful.
Post by Anders Lindgren
but also as this is a good way to describe the
intended behavior.
Such description should be found in the frame geometry section of the
Elisp manual.
Post by Anders Lindgren
I don't know what you mean by "fullboth", so I can't comment on what would
happen when you collate "fullscreen" and "fullboth".
"fullboth" is our misnomer for "maximized", that is, the frame should
occupy the full work area of the display and its "maximize" button
should indicate that the frame can be restored to its normal size (the
latter implies that a maximized frame usually keeps its title bar).

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

martin
Anders Lindgren
2015-09-27 18:53:39 UTC
Permalink
Hi,

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

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

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

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

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

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

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

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

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

Sincerely,
Anders Lindgren
Post by martin rudalics
Post by Anders Lindgren
I can take a look at it. However, the experience I had with the previous
bug was that it's immensely hard to follow what happens when it comes to
frame resizing and placement. So what I will do is to first reimplement
the
Post by Anders Lindgren
NSTRACE package and then start looking for the problem.
OK. As far as frame resizing is concerned I wrote some rudimentary
Elisp support. Set the variable ‘frame-size-history’ to a value like
'(100) and you will get a (partly cryptic) list of requests to resize a
frame and whether and how the request got honored.
Post by Anders Lindgren
By the way, is
there some kind of deadline coming up?
Not for bugs like this. It's only short before a release that we only
fix regressions introduced since the last release.
Post by Anders Lindgren
Also, things are starting to get so complicated so that we would need to
state what each concept mean so that they can be implemented the same way
on all systems. (When I wrote my "multicolumn" package I found tons and
tons of things that differed between systems, I just want to make sure we
don't introduce more such things.)
One thing that should work uniformly accross platforms is the
‘frame-geometry’ function as well as the recently introduced
‘frame-edges’. Since I was never able to verify these for OS X it would
be a good start to make sure they deliver correct results there first.
Done that, we should have a common platform to discuss the remaining
issues.
Post by Anders Lindgren
In addition, we really must write test
cases automatically walking through all transitions, ensuring that
nothing
Post by Anders Lindgren
breaks in the future,
One problem with automatic test cases is that numbers may lie about the
effect you see on screen. For example, Emacs can resize your scroll bar
width with completely correct metrics but since Gtk+ usually refuses to
change scroll bar widths, the visual appearance is devastating. But
obviously, automatic test cases would be very useful.
Post by Anders Lindgren
but also as this is a good way to describe the
intended behavior.
Such description should be found in the frame geometry section of the
Elisp manual.
Post by Anders Lindgren
I don't know what you mean by "fullboth", so I can't comment on what
would
Post by Anders Lindgren
happen when you collate "fullscreen" and "fullboth".
"fullboth" is our misnomer for "maximized", that is, the frame should
occupy the full work area of the display and its "maximize" button
should indicate that the frame can be restored to its normal size (the
latter implies that a maximized frame usually keeps its title bar).
A "fullscreen" frame, OTOH, occupies the entire display area (including
a task bar) and has no title bar.
martin
martin rudalics
2015-09-28 06:48:11 UTC
Permalink
Post by Anders Lindgren
I found one problem related to `toggle-to-maximized'. If this happened
right after `frame-resize-pixelwise' was set to a non-nil value, the
NSWindow parameter `resizeIncrement' must be updated. If this does not
occur, the frame size is rounded down to only accommodate full characters.
The extra space was distributed evenly above and below the frame. The
attached patch fixes this issue.
Makes sense. Pushed as 73b0901..e55460e to master.
Post by Anders Lindgren
To see the difference, run Emacs -Q and evaluate the following. After the
patch is applied, the frame is no longer moves down.
(progn
(setq frame-resize-pixelwise t)
(toggle-frame-maximized))
Unfortunately, the frame still doesn't cover the entire screen.
Usually it shouldn't, for maximizing. The problem as far as I
understand is that NS doesn't have the concept of a "maximized" frame.
Post by Anders Lindgren
The
"The size of the current screen, which is the screen containing the
largest part of the window's current frame, possibly reduced on the top,
bottom, left, or right, depending on the current interface style."
Effectively, this mean that the frame is reduced one pixel on the top (if
the menu bar is visible) and four pixels at the bottom. This corresponds to
how other applications, like Chrome, works.
When you do what, in Chrome? Try maximizing the Chrome window? How do
you do that?
Post by Anders Lindgren
I think it would be relatively easy to override this (well, at least the
four pixels at the bottom), but I'm not sure if we should and, if so, under
which conditions. (I can image that some users would like Emacs to fill the
entire screen whereas others might prefer the standard four pixels to be
unused at the bottom.)
We have the concept of a "workarea" as it's returned by
‘display-monitor-attributes-list’. On all systems I know of, a
"maximized" frame occupies the full workarea, a "fullwidth" frame the
full width of the workarea and a "fullheight" frame the full height of
the workarea. (I have no idea how these concepts expand to multiple
monitors though.) How do the four unused pixels relate to your
workarea?
Post by Anders Lindgren
In the Info documentation to the `fullscreen' frame parameter, there are
two values missing: `nil' and `fullscreen'. The former indicates that the
frame is in non-maximized state
nil means "neither of ‘maximized’, ‘fullwidth’, ‘fullheight’ or
‘fullboth’".
Post by Anders Lindgren
and the latter seems to behave like
`fullboth'.
‘fullscreen’ should not be used. I kept it in because I had the faint
feeling that at some time it was used isntead of ‘fullboth’.
Post by Anders Lindgren
Interestingly, the function `toggle-frame-fullscreen' seems to
use this undocumented parameter value.
It accepts it IIUC but it does not store it. Or what do you mean?

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

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

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

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

I agree with his diagnosis but I disagree with the cure. And for
compatibility reasons we would have to accept the old values anyway.
Post by Anders Lindgren
(In addition, there are some control
characters showing on the first line.)
Please elaborate.
Post by Anders Lindgren
On a side note, the NSTRACE rewrite is coming along nicely (it really
helped in tracking down this problem) but it's not yet ready for release.
Fine. Can you please get yourself write access to the git repository so
you can install it when it's ready? I feel some unease installing
larger changes on systems where I cannot check the consequences myself
immediately.

martin
Anders Lindgren
2015-09-28 21:35:50 UTC
Permalink
Hi!
Post by martin rudalics
Makes sense. Pushed as 73b0901..e55460e to master.
Thanks!
Post by martin rudalics
To see the difference, run Emacs -Q and evaluate the following. After the
Post by Anders Lindgren
patch is applied, the frame is no longer moves down.
(progn
(setq frame-resize-pixelwise t)
(toggle-frame-maximized))
Unfortunately, the frame still doesn't cover the entire screen.
Usually it shouldn't, for maximizing. The problem as far as I
understand is that NS doesn't have the concept of a "maximized" frame.
In earlier OS X versions, the green button was designed to make the window
large enough to accommodate the current document. In many applications,
this meant that the window grew to it's maximum hight, minus those missing
four pixels.

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

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


When you do what, in Chrome? Try maximizing the Chrome window? How do
Post by martin rudalics
you do that?
If I manually drag the Chrome window to its largest size, I can make it
stretch the entire width, but there will be four pixels missing at the
bottom. Also, if I hit the green button in older OS X versions, the same
four pixels are missing from the bottom.
Post by martin rudalics
We have the concept of a "workarea" as it's returned by
‘display-monitor-attributes-list’. On all systems I know of, a
"maximized" frame occupies the full workarea, a "fullwidth" frame the
full width of the workarea and a "fullheight" frame the full height of
the workarea. (I have no idea how these concepts expand to multiple
monitors though.) How do the four unused pixels relate to your
workarea?
The function returns the following:

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

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

However, the workarea of the secondary monitor does not. When executing
`toggle-frame-maximized' on the secondary frame (with
`frame-resize-pixelwise' set to t), the frame is placed at the bottom left
corner (which is good), but there are four pixles missing at the TOP of the
screen. (I haven't investigated why, though.)
Post by martin rudalics
In the Info documentation to the `fullscreen' frame parameter, there are
Post by Anders Lindgren
two values missing: `nil' and `fullscreen'. The former indicates that the
frame is in non-maximized state
nil means "neither of ‘maximized’, ‘fullwidth’, ‘fullheight’ or
‘fullboth’".
Yes, I guessed so -- but it needs to be documented, right?
Post by martin rudalics
Interestingly, the function `toggle-frame-fullscreen' seems to
Post by Anders Lindgren
use this undocumented parameter value.
It accepts it IIUC but it does not store it. Or what do you mean?
My mistake -- I was looking at the 24.5 source. There, the `fullscreen'
property was set to `fullscreen'. It has been fixed in the Emacs 25 source.
Post by martin rudalics
(In addition, there are some control
Post by Anders Lindgren
characters showing on the first line.)
Please elaborate.
In the "info" documentation, the first line looks like the following, where
the backslash-numbers represent a single character. I guess this is some
kind of encoding issue...

This parameter specifies whether to maximize the frame\342\200\231s
width,
Post by martin rudalics
On a side note, the NSTRACE rewrite is coming along nicely (it really
Post by Anders Lindgren
helped in tracking down this problem) but it's not yet ready for release.
Fine. Can you please get yourself write access to the git repository so
you can install it when it's ready? I feel some unease installing
larger changes on systems where I cannot check the consequences myself
immediately.
I fully understand. Who should I talk to to get write access? (The last
time I was doing any serious work on Emacs, Jan DjÀrv did the checkins, but
that was before he resigned.)

/ Anders
martin rudalics
2015-09-29 07:23:51 UTC
Permalink
Post by Anders Lindgren
Internally, however, internally, it's still possible to issue either
"toggleFullScreen" or "performZoom".
What does "internally" mean here?
Post by Anders Lindgren
If I manually drag the Chrome window to its largest size, I can make it
stretch the entire width, but there will be four pixels missing at the
bottom. Also, if I hit the green button in older OS X versions, the same
four pixels are missing from the bottom.
(((name . "SyncMaster")
(geometry 0 0 1600 1200)
(workarea 0 23 1600 1173)
(mm-size 432 324)
(frames #<frame *scratch* 0x101099630>)
(source . "NS"))
((name . "SyncMaster")
(geometry 1600 0 1600 1200)
(workarea 1600 0 1600 1200)
(mm-size 432 324)
(frames)
(source . "NS")))
Interestingly, the workarea of the primary screen is missing four pixels
(1200 - 1173 - 34) = 4.
What was the 34 about? I probably forgot.
Post by Anders Lindgren
However, the workarea of the secondary monitor does not. When executing
`toggle-frame-maximized' on the secondary frame (with
`frame-resize-pixelwise' set to t), the frame is placed at the bottom left
corner (which is good), but there are four pixles missing at the TOP of the
screen. (I haven't investigated why, though.)
Does ‘toggle-frame-maximized’ pass on 1173 or 1176 or 1200 as height?
Post by Anders Lindgren
Post by martin rudalics
nil means "neither of ‘maximized’, ‘fullwidth’, ‘fullheight’ or
‘fullboth’".
Yes, I guessed so -- but it needs to be documented, right?
I'll do that.
Post by Anders Lindgren
In the "info" documentation, the first line looks like the following, where
the backslash-numbers represent a single character. I guess this is some
kind of encoding issue...
This parameter specifies whether to maximize the frame\342\200\231s
width,
Funny. Here this line reads as

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

Probably this got screwed up during the "'" conversion process.
Post by Anders Lindgren
I fully understand. Who should I talk to to get write access? (The last
time I was doing any serious work on Emacs, Jan Djärv did the checkins, but
that was before he resigned.)
You have to apply for membership at Savannah:

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

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

martin
Eli Zaretskii
2015-09-29 07:50:14 UTC
Permalink
Date: Tue, 29 Sep 2015 09:23:51 +0200
Post by Anders Lindgren
I fully understand. Who should I talk to to get write access? (The last
time I was doing any serious work on Emacs, Jan Djärv did the checkins, but
that was before he resigned.)
https://savannah.gnu.org/git/?group=emacs
Then Eli (I believe) has to confirm that you are given write access and
finally you have to establish a key pair. Eli will correct me possibly.
Eli is only one of a few individuals who can do that; there are
others. They all will receive your request for membership.
martin rudalics
2015-09-30 18:57:20 UTC
Permalink
Post by Anders Lindgren
(((name . "SyncMaster")
Post by Anders Lindgren
(geometry 0 0 1600 1200)
(workarea 0 23 1600 1173)
(mm-size 432 324)
(frames #<frame *scratch* 0x101099630>)
(source . "NS"))
((name . "SyncMaster")
(geometry 1600 0 1600 1200)
(workarea 1600 0 1600 1200)
(mm-size 432 324)
(frames)
(source . "NS")))
Interestingly, the workarea of the primary screen is missing four pixels
(1200 - 1173 - 34) = 4.
What was the 34 about? I probably forgot.
"34" should be "23", which is the height of the menu bar.
In other words, the effective work area seems to be lacking four pixels at
the bottom.
I agree with you that I prefer a maximized frame to cover the entire
screen. I will try to do some experiments to see if it's possible, and if
so, we can discuss if we should modify Emacs to behave this way.
IIUC the Mac menu bar is what other systems call a task bar. In that
case, a maximized frame should cover everything but the menu bar and a
fullboth frame should cover the entire screen. Now if I understand you
correctly, Mac doesn't distinguish the various "zoomed" states - a
fullheight frame is just as "zoomed" as a fullscreen or maximized one.
Emacs calls the NextStep function `performZoom' without specifying a
height. The system, in turn, calls `windowWillUseStandardFrame:' with a
suggested frame with the height 1173 (when frame-resize-pixelwise is
non-nil).
My guess is that we can override this, but I haven't verified this.
How does one specify a size with performZoom? And does one performZoom
(to get a fullheight frame, say) followed by another one (to get a
fullboth frame, say) followed by toggling the button produce the initial
normal frame?
I got my write access rights today! Thanks for suggesting this.
Great!

martin
Anders Lindgren
2015-09-30 21:29:56 UTC
Permalink
Post by martin rudalics
IIUC the Mac menu bar is what other systems call a task bar. In that
case, a maximized frame should cover everything but the menu bar and a
fullboth frame should cover the entire screen. Now if I understand you
correctly, Mac doesn't distinguish the various "zoomed" states - a
fullheight frame is just as "zoomed" as a fullscreen or maximized one.
Zooming and fullscreen are two different concepts. Zooming is a generic
system, and it's up to the application to decide what to do. When
initialized using the user interface, Emacs steps through full-height,
maximized, and original size. When the frame `fullscreen' property is
updated, the correct state is set immediately. OS X is simply informed of
the end size and placement and resized the frame using a resizing animation.

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

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

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

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

/ Anders
martin rudalics
2015-10-02 08:37:26 UTC
Permalink
Post by Anders Lindgren
Zooming and fullscreen are two different concepts. Zooming is a generic
system, and it's up to the application to decide what to do. When
initialized using the user interface, Emacs steps through full-height,
maximized, and original size. When the frame `fullscreen' property is
updated, the correct state is set immediately. OS X is simply informed of
the end size and placement and resized the frame using a resizing animation.
But is the fact that OS X has responded to our zooming request reflected
in that "button" and if so in which way?
Post by Anders Lindgren
FullScreen is a totally different animal with a special sideways animation,
gives the application exclusive use of the screen, and blanks out other
monitors.
What is the size of such a "FullScreen" screen in relation to the size
of your screen?
Post by Anders Lindgren
Today, I did try a little experiment by
modifying `windowWillUseStandardFrame:' to return the full screen size.
Unfortunately, using this method it doesn't seem possible to make the frame
use the entire screen -- it appears as though the system restrict the
requested frame size to what it considers the visible area.
The four pixels, by the way, is related to the position of the "Dock" -- if
it is placed on the side of the screen, OS X won't use the four leftmost
pixels. Also, if the Dock is not in auto-hide mode, OS X will restrict zoom
so that the dock isn't covered at all (i.e. some 20 or 30 pixels).
This makes sense, more or less.
Post by Anders Lindgren
It would be relatively easy to modify the code so that setting a frame
parameter would set the frame size without using the zoom system. However,
it would make maximizing the frame using the user interface different from
`toggle-frame-maximized', which might be undesirable.
Agreed.
Post by Anders Lindgren
On the other hand, I
compared with another application (LightRoom). When it is maximized using
the user interface, it's frame doesn't cover the entire screen (the same
four pixels as in Emacs). To cover the entire screen, another command must
be issued which cycles through maximized, maximized with hidden menu bar,
and normal.
I'm afraid that I don't yet understand that "cycling". Do you mean that
pushing that button (which I presume is the "user interface") repeatedly
cycles through these three states? In that case there's still the
question whether ‘toggle-frame-maximized’ should hide the menu bar.

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

martin
Anders Lindgren
2015-10-03 06:16:37 UTC
Permalink
Hi!

But is the fact that OS X has responded to our zooming request reflected
Post by martin rudalics
in that "button" and if so in which way?
No, the button does not change in any way when zooming.

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

In earlier versions of OS X, there was no fullscreen mode. In those
versions, the green button always contained a "+" when hovering above it.
Post by martin rudalics
FullScreen is a totally different animal with a special sideways animation,
Post by Anders Lindgren
gives the application exclusive use of the screen, and blanks out other
monitors.
What is the size of such a "FullScreen" screen in relation to the size
of your screen?
It's always use the full screen, as far as I can tell.

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

As far as I can tell, fullscreen mode work very well.
Post by martin rudalics
On the other hand, I
Post by Anders Lindgren
compared with another application (LightRoom). When it is maximized using
the user interface, it's frame doesn't cover the entire screen (the same
four pixels as in Emacs). To cover the entire screen, another command
must
Post by Anders Lindgren
be issued which cycles through maximized, maximized with hidden menu bar,
and normal.
I'm afraid that I don't yet understand that "cycling". Do you mean that
pushing that button (which I presume is the "user interface") repeatedly
cycles through these three states?
Yes, it does.

I think this behaviour is fine.
Post by martin rudalics
In that case there's still the
question whether ‘toggle-frame-maximized’ should hide the menu bar.
I would say no.

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

I see no reason to change this.


BTW, you above say "full-height" and "maximized" and here you talk about
Post by martin rudalics
"maximized" and "maximized with hidden menu bar". Which of these
correlate?
Different applications use different states, it was only an example of how
another application handle similar situation. I don't think this cycle is
the way to go for us.


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

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

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

/ Anders
martin rudalics
2015-10-03 08:32:37 UTC
Permalink
Post by Anders Lindgren
As far as I can tell, fullscreen mode work very well.
Fine.
Post by Anders Lindgren
Post by martin rudalics
In that case there's still the
question whether ‘toggle-frame-maximized’ should hide the menu bar.
I would say no.
Currently, the user can hide the menu bar by setting
`ns-auto-hide-menu-bar' to t. If this is set, `toggle-frame-maximized' (and
zooming using the user interface) use the entire screen.
Ah... Then everything looks alright in this regard.
Post by Anders Lindgren
All in all, the Emacs system works well. The only problem is that a
maximized window doesn't cover the entire screen. I have been thinking
* Replace the zoom code with a custom one that simply sets the correct
size. (Hopefully, it's possible to get this to work with the zoom button as
well.)
* Call the standard zoom function to get the zoom animation, then do an
extra resize after it's done.
This last one sounds a bit clumsy.
Post by Anders Lindgren
Also, one could imagine a new variable `ns-use-native-zoom' if the user
would like the normal zoom.
We could try that. After all it looks like a complement to
‘ns-auto-hide-menu-bar’.

martin
Keith David Bershatsky
2015-09-20 19:14:33 UTC
Permalink
Post by Anders Lindgren
Are there any other open issues, or does this cover everything?
/ Anders
All issues regarding functionality as to bug 21415 are handled as far as I can tell. Attached is the combined patch that I used today to perform my testing.

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

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

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

Keith
Keith David Bershatsky
2015-09-28 14:32:05 UTC
Permalink
Would it be possible to broaden the scope of issue number 21415 to include Emacs for Microsoft Windows such that the following will also work using a floating point:

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

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

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

Keith
martin rudalics
2015-09-28 15:31:31 UTC
Permalink
Post by Keith David Bershatsky
Would it be possible to broaden the scope of issue number 21415 to
include Emacs for Microsoft Windows such that the following will also
(make-frame '(
(height . 25.0)
(width . 50.0)))
A 25 x 50 pixels window might look a bit small but 500.0 x 250.0 work
here. With X things get more complicated but they should work there
too. The major problem is and will remain NS: If with emacs -Q, you
evaluate

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

what does

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

return?
Post by Keith David Bershatsky
Because I do not yet have the knowledge to build Emacs for Microsoft
Windows,
You should acquire that knowledge. If there are any problems, Eli will
help (I won't because I'm misconfiguring). The more people build on
Windows, the sooner we will be able to catch errors there. As things
stand, too many people wait for the next release of ...
Post by Keith David Bershatsky
I have been using the Emacs Trunk built by Dani Moncayo. The updates are every few weeks.
https://sourceforge.net/projects/emacs-bin/?source=updater
... and if Dani picked up a bad moment, we might get floods of errors
for something that was broken (and maybe even fixed) some time ago.

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

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

If with emacs -Q, you evaluate

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

what does

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

return?

martin
Keith David Bershatsky
2015-09-28 18:13:36 UTC
Permalink
Ah . . . okay . . . on NS with emacs -Q, I get:

(1185 . 600)

Keith

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

At Mon, 28 Sep 2015 20:00:36 +0200,
Post by martin rudalics
* * *
If with emacs -Q, you evaluate
(progn
(setq frame-resize-pixelwise t)
(setq frame-inhibit-implied-resize t)
(make-frame '((width . 1200.0) (height . 600.0)
(font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1"))))
what does
(cons (frame-text-width) (frame-text-height))
return?
martin
martin rudalics
2015-09-29 07:22:37 UTC
Permalink
Post by Keith David Bershatsky
(1185 . 600)
Not all too bad given that we want (1200 . 600). I'm really surprised
that the height seems OK. What does evaluating the following three
forms in the new frame return?

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

martin
Keith David Bershatsky
2015-09-29 17:09:33 UTC
Permalink
I get 15, 8, 8:

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

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

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

With emacs -Q, after evaluating:

(progn
(setq frame-resize-pixelwise t)
(setq frame-inhibit-implied-resize t)
(make-frame '((width . 1200.0) (height . 600.0)
(font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1"))))
Post by martin rudalics
Post by Keith David Bershatsky
(1185 . 600)
Not all too bad given that we want (1200 . 600). I'm really surprised
that the height seems OK. What does evaluating the following three
forms in the new frame return?
(frame-parameter nil 'scroll-bar-width)
(frame-parameter nil 'left-fringe)
(frame-parameter nil 'right-fringe)
martin
martin rudalics
2015-09-29 17:14:09 UTC
Permalink
Post by Keith David Bershatsky
(frame-parameter nil 'scroll-bar-width): 15
So it's obviously the scroll bar width. I will look into this.
Post by Keith David Bershatsky
(frame-parameter nil 'left-fringe): 8
(frame-parameter nil 'right-fringe): 8
(progn
(setq frame-resize-pixelwise t)
(setq frame-inhibit-implied-resize t)
(make-frame '((width . 1200.0) (height . 600.0)
(font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1"))))
Post by Keith David Bershatsky
(1185 . 600)
Thanks, martin
Keith David Bershatsky
2015-10-01 06:43:00 UTC
Permalink
I had an opportunity this evening to test out the earlier patch by Martin in this thread for the floating point frame-creation on Emacs built for MS-Windows (XP--SP3) and it is working well. I've set up the `default-frame-alist' with floating points for height and width, and the initial frame and all new frames perfectly reflect the parameters tested -- what a pleasure -- :)

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

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

martin
Andy Moreton
2015-10-03 11:28:31 UTC
Permalink
Post by martin rudalics
Find attached the most recent version of the patch. Fixes are mainly
for Lucid/Motif but something might change for other platforms as well.
@@ -3166,15 +3171,25 @@ x_set_frame_parameters (struct frame *f, Lisp_Object alist)
prop = parms[i];
val = values[i];
- if (EQ (prop, Qwidth) && RANGED_INTEGERP (0, val, INT_MAX))
+ if (EQ (prop, Qwidth))
{
width_change = 1;
- width = XFASTINT (val) * FRAME_COLUMN_WIDTH (f) ;
+ if (RANGED_INTEGERP (0, val, INT_MAX))
+ width = XFASTINT (val) * FRAME_COLUMN_WIDTH (f) ;
+ else if (FLOATP (val)
+ && XFLOAT_DATA (val) >= 0
+ && (int) XFLOAT_DATA (val) <= INT_MAX)
+ width = (int) XFLOAT_DATA (val);
}
This changes the logic to set width_change even when Qwidth is an
out of range integer: is that intended ?
Post by martin rudalics
- else if (EQ (prop, Qheight) && RANGED_INTEGERP (0, val, INT_MAX))
+ else if (EQ (prop, Qheight))
{
height_change = 1;
- height = XFASTINT (val) * FRAME_LINE_HEIGHT (f);
+ if (RANGED_INTEGERP (0, val, INT_MAX))
+ height = XFASTINT (val) * FRAME_LINE_HEIGHT (f);
+ else if (FLOATP (val)
+ && XFLOAT_DATA (val) >= 0
+ && (int) XFLOAT_DATA (val) <= INT_MAX)
+ height = (int) XFLOAT_DATA (val);
Similarly for height_change.

AndyM
martin rudalics
2015-10-03 12:31:41 UTC
Permalink
Post by Andy Moreton
Post by martin rudalics
@@ -3166,15 +3171,25 @@ x_set_frame_parameters (struct frame *f, Lisp_Object alist)
prop = parms[i];
val = values[i];
- if (EQ (prop, Qwidth) && RANGED_INTEGERP (0, val, INT_MAX))
+ if (EQ (prop, Qwidth))
{
width_change = 1;
- width = XFASTINT (val) * FRAME_COLUMN_WIDTH (f) ;
+ if (RANGED_INTEGERP (0, val, INT_MAX))
+ width = XFASTINT (val) * FRAME_COLUMN_WIDTH (f) ;
+ else if (FLOATP (val)
+ && XFLOAT_DATA (val) >= 0
+ && (int) XFLOAT_DATA (val) <= INT_MAX)
+ width = (int) XFLOAT_DATA (val);
}
This changes the logic to set width_change even when Qwidth is an
out of range integer: is that intended ?
Certainly not.
Post by Andy Moreton
Post by martin rudalics
- else if (EQ (prop, Qheight) && RANGED_INTEGERP (0, val, INT_MAX))
+ else if (EQ (prop, Qheight))
{
height_change = 1;
- height = XFASTINT (val) * FRAME_LINE_HEIGHT (f);
+ if (RANGED_INTEGERP (0, val, INT_MAX))
+ height = XFASTINT (val) * FRAME_LINE_HEIGHT (f);
+ else if (FLOATP (val)
+ && XFLOAT_DATA (val) >= 0
+ && (int) XFLOAT_DATA (val) <= INT_MAX)
+ height = (int) XFLOAT_DATA (val);
Similarly for height_change.
Thanks for the heads-up. I will fix that.

Did you try the rest of it? Any suggestions?

martin
Andy Moreton
2015-10-05 21:02:52 UTC
Permalink
Post by martin rudalics
Thanks for the heads-up. I will fix that.
Did you try the rest of it? Any suggestions?
The use of a float for an exact number of pixels seems an odd interface
design. What if you later want to add the ability to specify frame sizes
in inches or mm ?

AndyM
martin rudalics
2015-10-06 07:57:26 UTC
Permalink
Post by Andy Moreton
The use of a float for an exact number of pixels seems an odd interface
design. What if you later want to add the ability to specify frame sizes
in inches or mm ?
How about using entries like

(width . (text-pixels . 400))

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

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

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

Keith


At Fri, 02 Oct 2015 10:37:55 +0200,
Post by martin rudalics
Post by Keith David Bershatsky
I wasn't sure if anything had changed in the past couple of weeks, so
I did a hard reset back to the last commit on September 11, 2015 and
then applied the patch to do my testing.
Find attached the most recent version of the patch. Fixes are mainly
for Lucid/Motif but something might change for other platforms as well.
martin rudalics
2015-10-13 10:21:18 UTC
Permalink
Post by Keith David Bershatsky
Sorry for taking so long to try this patch out. I tried the latest
patch out this evening on a new build with OSX 10.6.8 -- master branch
-- and the tests I performed work well -- i.e., I have a
default-frame-alist that creates the perfect size initial and
subsequent frames to precise pixel specifications using courier font
size 18.
I now pushed everything to master. It's been pretty difficult to fix
the various builds. I found a number of bugs that earlier were swept
under the lines/columns carpets.

There is one major change: Instead of

(width . 200.0)

you have to use

(width . (text-pixels . 200))

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

Thanks, martin
Keith David Bershatsky
2015-10-13 17:23:11 UTC
Permalink
Thank you both so very much for making feature request 21415 a reality and for fixing the various issues along the way. I built Emacs this morning from the master branch for both OSX 10.6.8 and Windows XP -- i.e., through "6d6bf466477b004035a4314886e35214c6f8603b", which is subsequent in time to the commit by Martin earlier in the day.

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

Keith
Anders Lindgren
2015-10-13 17:59:12 UTC
Permalink
Great to hear that things are working!

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

-- Anders
Post by Keith David Bershatsky
Thank you both so very much for making feature request 21415 a reality and
for fixing the various issues along the way. I built Emacs this morning
from the master branch for both OSX 10.6.8 and Windows XP -- i.e., through
"6d6bf466477b004035a4314886e35214c6f8603b", which is subsequent in time to
the commit by Martin earlier in the day.
Both of the builds (i.e., OSX and Windows XP) are working well with the
tests that I performed using the `default-frame-alist` and the new
`text-pixels` specifications for `width` and `height`.
Keith
martin rudalics
2015-10-14 08:49:37 UTC
Permalink
Post by Keith David Bershatsky
Both of the builds (i.e., OSX and Windows XP) are working well with
the tests ...
Can you try the attached test suite? Simply load the attached file and
do M-x frame-test. The transcript can be found in a buffer called
*frame-test*. Please do that for both installations.

martin
Keith David Bershatsky
2015-10-14 15:58:30 UTC
Permalink
Attached are the test suite results for each 10/13/2015 build of Emacs -- OSX 10.6.8, and Windows XP.

Keith

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

At Wed, 14 Oct 2015 10:49:37 +0200,
martin rudalics wrote:
* * *
Post by martin rudalics
Can you try the attached test suite? Simply load the attached file and
do M-x frame-test. The transcript can be found in a buffer called
*frame-test*. Please do that for both installations.
martin
[* frame.test.el]
martin rudalics
2015-10-14 17:37:28 UTC
Permalink
Post by Keith David Bershatsky
Attached are the test suite results for each 10/13/2015 build of Emacs -- OSX 10.6.8, and Windows XP.
Thanks. Apparently toggling the tool bar on OSX is still causing
problems. Can you please, on OSX, do the following with emacs -Q:

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

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

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

Thanks, martin
Anders Lindgren
2015-10-14 21:53:20 UTC
Permalink
Martin,

I've got a quick question. I noticed that the OS X port behaves a bit
inconsistent when it comes to restricting a frame to the screen --
sometimes it is restricted in height, sometimes it's not. I would like to
make this more consistent, but I'm not sure in which direction I should go.

How does the other terms (especially X11) behave? Does it restrict the
frame to be within the screen? If so, does it allow for the frame border to
be placed outside the screen?

What happens if the frame is first resized and then moved. Should the
resize truncate the height, even though the move would place the entire
frame inside the screen borders? Can a move and a resize be made atomically
(pixelwise)?

Personally, I'd prefer it there is no truncation. However, if it is, I
really would like to be able to allow the frame border to stretch outside
the screen, in order to really maximize the screen real estate.

/ Anders
Post by Keith David Bershatsky
Post by Keith David Bershatsky
Attached are the test suite results for each 10/13/2015 build of Emacs
-- OSX 10.6.8, and Windows XP.
Thanks. Apparently toggling the tool bar on OSX is still causing
(1) Toggle the tool bar off. Does the overall frame height shrink or
stay the same?
(2) Toggle the tool bar on again. Does the overall frame height
increase or stay the same?
(3) Evaluate (setq frame-inhibit-implied-resize t) and repeat steps (1)
and (2).
Thanks, martin
martin rudalics
2015-10-15 10:00:35 UTC
Permalink
Post by Anders Lindgren
I've got a quick question. I noticed that the OS X port behaves a bit
inconsistent when it comes to restricting a frame to the screen --
sometimes it is restricted in height, sometimes it's not. I would like to
make this more consistent, but I'm not sure in which direction I should go.
How does the other terms (especially X11) behave? Does it restrict the
frame to be within the screen? If so, does it allow for the frame border to
be placed outside the screen?
I suppose nobody can answer this question satisfactorily. IMO good
"systems" allow the frame to be placed anywhere. And I usually have
troubles only with window managers constraining placement.
Post by Anders Lindgren
What happens if the frame is first resized and then moved. Should the
resize truncate the height, even though the move would place the entire
frame inside the screen borders? Can a move and a resize be made atomically
(pixelwise)?
For Emacs moving means to pass on coordinates to whoever is responsible.
And Emacs itself never constrains the frame size (it must not get too
small, though).
Post by Anders Lindgren
Personally, I'd prefer it there is no truncation. However, if it is, I
really would like to be able to allow the frame border to stretch outside
the screen, in order to really maximize the screen real estate.
That's what most systems do AFAICT. So if you can do that please go on.

martin
Anders Lindgren
2015-10-20 17:20:54 UTC
Permalink
Ok, here comes a patch file for the "maximize" and "NSTRACE" rewrites, see
the file "emacs-commit-message.txt" for details. I would like you
(especially Keith, since Martin don't use OS X) to take a look at it before
I post in on emacs-devel and (unless people object) I commit it.

The rewrite became a bit larger than I originally expected since I realised
that the system to snap the frame size to the text grid was fundamentally
broken. It used a features called "SetResizeIncrements", where the
increments were set to the size of the current font. Unfortunately, once
the frame size got out of sync (e.g. by setting the frame size to a
specific pixel value) it remained out of sync. In addition, it interfered
with the maximization system.

The current implementation snaps the frame size to the text grid in a
callback function.

The patch below contains excluded code to maximize the frame the old way
using the system "zoom" function, and an excluded code section for a hybrid
maximize solution. Also, the code to restrict a frame to the screen height
is still present but excluded. Before I commit this to the archive I will
remove the excluded code, unless someone thinks that its worth while to
allow the user to configure this.

You can enable the NSTRACE system by uncommenting a line in nsterm.h, see
comments for detail.

In addition, I have included my own test file for frame maximization I
wrote to ensure that I didn't introduce any problems. Martin, if there are
anything in this you can use for your frame test file, feel free to use it.

Sincerely,
Anders Lindgren
Post by martin rudalics
Post by Anders Lindgren
I've got a quick question. I noticed that the OS X port behaves a bit
inconsistent when it comes to restricting a frame to the screen --
sometimes it is restricted in height, sometimes it's not. I would like to
make this more consistent, but I'm not sure in which direction I should
go.
Post by Anders Lindgren
How does the other terms (especially X11) behave? Does it restrict the
frame to be within the screen? If so, does it allow for the frame border
to
Post by Anders Lindgren
be placed outside the screen?
I suppose nobody can answer this question satisfactorily. IMO good
"systems" allow the frame to be placed anywhere. And I usually have
troubles only with window managers constraining placement.
Post by Anders Lindgren
What happens if the frame is first resized and then moved. Should the
resize truncate the height, even though the move would place the entire
frame inside the screen borders? Can a move and a resize be made
atomically
Post by Anders Lindgren
(pixelwise)?
For Emacs moving means to pass on coordinates to whoever is responsible.
And Emacs itself never constrains the frame size (it must not get too
small, though).
Post by Anders Lindgren
Personally, I'd prefer it there is no truncation. However, if it is, I
really would like to be able to allow the frame border to stretch outside
the screen, in order to really maximize the screen real estate.
That's what most systems do AFAICT. So if you can do that please go on.
martin
Keith David Bershatsky
2015-10-14 20:34:41 UTC
Permalink
(1) Toggle the tool bar off. Does the overall frame height shrink or stay the same?

A: Starting from Emacs -Q. Using the mouse to toggle the toolbar off, the height of the frame shrinks -- i.e., top and left remain the same, and the bottom shrinks upward about one-half the height of the toolbar that disappears. The minibuffer / echo area increases in size to about 3 lines of text, with just one line of text that reads: "menu-bar options showhide showhide-tool-bar".


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

A: The frame height quickly shrinks and expands, but ultimately remains the same size -- i.e., slightly less than when Emacs -Q first began its GUI session.


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

A: Starting again from Emacs -Q. Evaluate `(setq frame-inhibit-implied-resize t)`. Step 1 looks the same as previously reported. Step 2 looks the same as previously reported. I did not see any visual difference between this test and prior test mentioned above.


Keith
martin rudalics
2015-10-15 09:59:49 UTC
Permalink
I add a few observations from the GNUstep perspective. This build is
inherently broken (emacs -Q starts out with _two_ identical tool bars)
but gets me similar results. Anders what do you get when you repeat
Keith's experiment? Only steps (1) and (2) make sense currently.
Post by Keith David Bershatsky
(1) Toggle the tool bar off. Does the overall frame height shrink or stay the same?
A: Starting from Emacs -Q. Using the mouse to toggle the toolbar off,
the height of the frame shrinks -- i.e., top and left remain the same,
and the bottom shrinks upward about one-half the height of the toolbar
that disappears. The minibuffer / echo area increases in size to
"menu-bar options showhide showhide-tool-bar".
This is more or less what happens here as well but worked previously.
IIUC it's due to Jan's change below:


diff --git a/src/ChangeLog b/src/ChangeLog
index 69da1c3..861ba91 100644
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,8 @@
+2015-01-06 Jan Djärv <***@swipnet.se>
+
+ * nsterm.m (x_set_window_size): Call updateFrameSize to get real
+ size instead of using widht/height. The frame may be constrained.
+
2015-01-05 Paul Eggert <***@cs.ucla.edu>

* lisp.h (XSYMBOL): Parenthesize id in forward decl.
diff --git a/src/nsterm.m b/src/nsterm.m
index 2ccb7fe..bf3192b 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -1404,15 +1404,8 @@ x_set_window_size (struct frame *f,
[view setBoundsOrigin: origin];
}

- change_frame_size (f, width, height, 0, 1, 0, pixelwise);
-/* SET_FRAME_GARBAGED (f); // this short-circuits expose call in drawRect */
-
- mark_window_cursors_off (XWINDOW (f->root_window));
- cancel_mouse_face (f);
-
+ [view updateFrameSize: NO];
unblock_input ();
-
- do_pending_window_change (0);
}


Restoring the change_frame_size call fixes the problem here.
Post by Keith David Bershatsky
(2) Toggle the tool bar on again. Does the overall frame height increase or stay the same?
A: The frame height quickly shrinks and expands, but ultimately
remains the same size -- i.e., slightly less than when Emacs -Q first
began its GUI session.
More or less same here. I tried with earlier builds and all show the
same behavior: Toggling the tool bar on and off repeatedly has the frame
height ultimately shrink.
Post by Keith David Bershatsky
(3) Evaluate (setq frame-inhibit-implied-resize t) and repeat steps (1) and (2).
A: Starting again from Emacs -Q. Evaluate `(setq
frame-inhibit-implied-resize t)`. Step 1 looks the same as previously
reported. Step 2 looks the same as previously reported. I did not
see any visual difference between this test and prior test mentioned
above.
I'll try to fix this. But we must fix (1) first, then (2) ...

Thanks, martin
Keith David Bershatsky
2015-10-21 01:03:12 UTC
Permalink
I applied the patch named `maximize_and_trace.diff` and built Emacs --with-ns. I was surprised to see that `toggle-frame-maximized` actually worked, which is something I had never seen before on OSX.

My standard stuff that I normally use appears to be working okay -- e.g., `default-frame-alist` with pixel specifications for height/width and courier font are working correctly.

I'm not a programmer, but I'd be happy to run some layman's tests (if you need) on the build with OSX 10.6.8.

Keith

Loading...