GNU bug report logs -
#21415
25.0.50; Emacs Trunk -- pixelwise width/height for x-create-frame
Previous Next
Reported by: Keith David Bershatsky <esq <at> lawlist.com>
Date: Fri, 4 Sep 2015 17:43:01 UTC
Severity: wishlist
Found in version 25.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21415 in the body.
You can then email your comments to 21415 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Fri, 04 Sep 2015 17:43:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Keith David Bershatsky <esq <at> lawlist.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 04 Sep 2015 17:43:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Fri, 04 Sep 2015 19:19:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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;
Interesting. This is the first time someone asks for this. Do you have
a particular use case?
> (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.
> (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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 05 Sep 2015 00:32:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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,
martin rudalics wrote:
>
> > I am trying to do three things:
> >
> > (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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 05 Sep 2015 10:00:05 GMT)
Full text and
rfc822 format available.
Message #14 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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.
> 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?
> 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.
> 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).
> 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.
> 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)))
> 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
[frame.c.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 06 Sep 2015 17:19:03 GMT)
Full text and
rfc822 format available.
Message #17 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 06 Sep 2015 17:57:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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'.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 06 Sep 2015 19:28:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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?
> 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.
> I believe that `x-create-frame' is expecting an integer:
>
> 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
[frame.c.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 06 Sep 2015 19:28:03 GMT)
Full text and
rfc822 format available.
Message #26 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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.
> -- 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 06 Sep 2015 22:02:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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,
martin rudalics wrote:
>
> > 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?
>
> > 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.
>
> * * *
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 07 Sep 2015 07:06:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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
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
[frame.c.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 07 Sep 2015 17:54:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 08 Sep 2015 08:30:03 GMT)
Full text and
rfc822 format available.
Message #38 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> When using the setting of `(setq ns-auto-hide-menu-bar t)`
Is this necessary to trigger the behavior?
> 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 08 Sep 2015 16:14:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 08 Sep 2015 19:23:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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.
> 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’.
> 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.
> 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.
> 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 09 Sep 2015 00:39:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 09 Sep 2015 06:28:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 09 Sep 2015 14:31:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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,
martin rudalics wrote:
>
> > 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 09 Sep 2015 15:54:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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")
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 09 Sep 2015 16:27:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 09 Sep 2015 17:12:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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
[nsterm.m.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Thu, 10 Sep 2015 00:47:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Thu, 10 Sep 2015 06:58:01 GMT)
Full text and
rfc822 format available.
Message #68 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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.
I'm afraid that setting ‘frame-inhibit-implied-resize’ would't have
helped anyway in that case.
> 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.
> 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.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Thu, 10 Sep 2015 18:40:03 GMT)
Full text and
rfc822 format available.
Message #71 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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)
)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 12 Sep 2015 11:12:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 12 Sep 2015 11:13:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 12 Sep 2015 18:12:01 GMT)
Full text and
rfc822 format available.
Message #80 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 12 Sep 2015 19:58:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
On Sat, Sep 12, 2015 at 1:11 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> > 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
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 12 Sep 2015 23:10:03 GMT)
Full text and
rfc822 format available.
Message #86 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 12 Sep 2015 23:14:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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`.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 13 Sep 2015 07:11:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
On Sun, Sep 13, 2015 at 1:13 AM, Keith David Bershatsky <esq <at> lawlist.com>
wrote:
> 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`.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 13 Sep 2015 09:03:02 GMT)
Full text and
rfc822 format available.
Message #95 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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?
> 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"?
> it should
> adjust the window to start further down.
Further "up" maybe?
> 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.
> 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.
> ;; 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 13 Sep 2015 09:03:03 GMT)
Full text and
rfc822 format available.
Message #98 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 13 Sep 2015 09:03:03 GMT)
Full text and
rfc822 format available.
Message #101 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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.
> 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).
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 13 Sep 2015 16:18:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 13 Sep 2015 18:02:01 GMT)
Full text and
rfc822 format available.
Message #107 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 13 Sep 2015 18:37:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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,
martin rudalics wrote:
>
>
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 13 Sep 2015 18:54:02 GMT)
Full text and
rfc822 format available.
Message #113 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 13 Sep 2015 20:22:02 GMT)
Full text and
rfc822 format available.
Message #116 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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.
On Sun, Sep 13, 2015 at 8:01 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> > 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
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 14 Sep 2015 08:32:01 GMT)
Full text and
rfc822 format available.
Message #119 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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?
> ;; 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 14 Sep 2015 08:33:02 GMT)
Full text and
rfc822 format available.
Message #122 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 14 Sep 2015 09:38:02 GMT)
Full text and
rfc822 format available.
Message #125 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
>>> 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
On Mon, Sep 14, 2015 at 10:32 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> >> 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)?
>
> > 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?
>
> > 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).
>
> 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
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 14 Sep 2015 13:40:02 GMT)
Full text and
rfc822 format available.
Message #128 received at 21415 <at> debbugs.gnu.org (full text, mbox):
>>> 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"?
> 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.
> 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?
> -- 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?
> 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?
> 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.
> Hiding the menu bar only hides the menu bar -- it does not move the frame
> or hide the title bar.
OK.
> 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.
>> 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 14 Sep 2015 14:46:01 GMT)
Full text and
rfc822 format available.
Message #131 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Sep 14, 2015 at 3:39 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> >>> 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.)
> 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?
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.
> > -- 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.
> > 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.)
> 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.
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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 14 Sep 2015 15:26:02 GMT)
Full text and
rfc822 format available.
Message #134 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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 <rudalics <at> 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 <jan.h.d <at> 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)))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 14 Sep 2015 17:38:02 GMT)
Full text and
rfc822 format available.
Message #137 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 14 Sep 2015 17:38:02 GMT)
Full text and
rfc822 format available.
Message #140 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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 <rudalics <at> 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.
This one shouldn't affect OS X at all.
> commit fe2f33e8da2e2c7950214eafdfd610f164025baf
> Author: Jan Djärv <jan.h.d <at> 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.
No idea about this either.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 14 Sep 2015 19:04:02 GMT)
Full text and
rfc822 format available.
Message #143 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 15 Sep 2015 08:30:05 GMT)
Full text and
rfc822 format available.
Message #146 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 19 Sep 2015 21:13:02 GMT)
Full text and
rfc822 format available.
Message #149 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
On Tue, Sep 15, 2015 at 10:29 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> > 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
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 19 Sep 2015 22:18:02 GMT)
Full text and
rfc822 format available.
Message #152 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> Below is a patch that should correct the problem:
Thanks. But pretty please send it as an attachment. Here it arrived
as:
> 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.
Can you please tell us why the "origin" on OS X is apparently the lower
left corner? Where can I read about this?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 20 Sep 2015 07:26:02 GMT)
Full text and
rfc822 format available.
Message #155 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
On Sun, Sep 20, 2015 at 12:17 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> > Below is a patch that should correct the problem:
>
> Thanks. But pretty please send it as an attachment. Here it arrived
> as:
>
> > 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.
>
> Can you please tell us why the "origin" on OS X is apparently the lower
> left corner? Where can I read about this?
>
> martin
>
[Message part 2 (text/html, inline)]
[diff.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 20 Sep 2015 08:45:01 GMT)
Full text and
rfc822 format available.
Message #158 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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.
> You can read more about "screen coordinates" here:
>
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 20 Sep 2015 09:28:02 GMT)
Full text and
rfc822 format available.
Message #161 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
On Sun, Sep 20, 2015 at 10:44 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> > 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.
>
> > You can read more about "screen coordinates" here:
> >
> >
> 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
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 20 Sep 2015 09:55:01 GMT)
Full text and
rfc822 format available.
Message #164 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 20 Sep 2015 16:48:01 GMT)
Full text and
rfc822 format available.
Message #167 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 20 Sep 2015 18:30:03 GMT)
Full text and
rfc822 format available.
Message #170 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Sep 20, 2015 at 11:54 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 20 Sep 2015 18:32:01 GMT)
Full text and
rfc822 format available.
Message #173 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 20 Sep 2015 19:15:02 GMT)
Full text and
rfc822 format available.
Message #176 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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
[21415_g.diff (application/diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 21 Sep 2015 09:43:02 GMT)
Full text and
rfc822 format available.
Message #179 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 21 Sep 2015 09:44:02 GMT)
Full text and
rfc822 format available.
Message #182 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 21 Sep 2015 18:57:02 GMT)
Full text and
rfc822 format available.
Message #185 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 22 Sep 2015 06:39:02 GMT)
Full text and
rfc822 format available.
Message #188 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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.
> `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"?
> 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.
> 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 22 Sep 2015 08:55:02 GMT)
Full text and
rfc822 format available.
Message #191 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
On Tue, Sep 22, 2015 at 8:38 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> > 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.
>
> > `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"?
>
> > 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.
>
> > 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.
>
> > 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
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 22 Sep 2015 09:37:02 GMT)
Full text and
rfc822 format available.
Message #194 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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.
> 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.
> 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.
> 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.
> 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 27 Sep 2015 18:54:01 GMT)
Full text and
rfc822 format available.
Message #197 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
On Tue, Sep 22, 2015 at 11:36 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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.
>
> > 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
>
>
[Message part 2 (text/html, inline)]
[maximize.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 28 Sep 2015 06:49:02 GMT)
Full text and
rfc822 format available.
Message #200 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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.
> 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.
> 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.
When you do what, in Chrome? Try maximizing the Chrome window? How do
you do that?
> 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?
> 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’".
> 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’.
> 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.
> (In addition, there are some control
> characters showing on the first line.)
Please elaborate.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 28 Sep 2015 14:33:02 GMT)
Full text and
rfc822 format available.
Message #203 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 28 Sep 2015 15:32:01 GMT)
Full text and
rfc822 format available.
Message #206 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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)))
>
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?
> 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 ...
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 28 Sep 2015 17:50:02 GMT)
Full text and
rfc822 format available.
Message #209 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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)))
x-create-frame-with-faces(((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1")))
#[257 "\300!\207" [x-create-frame-with-faces] 3 "\n\n(fn PARAMS)"](((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1")))
apply(#[257 "\300!\207" [x-create-frame-with-faces] 3 "\n\n(fn PARAMS)"] ((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1")))
frame-creation-function(((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1")))
make-frame(((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1")))
(progn (setq frame-resize-pixelwise t) (setq frame-inhibit-implied-resize t) (make-frame (quote ((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1")))))
eval((progn (setq frame-resize-pixelwise t) (setq frame-inhibit-implied-resize t) (make-frame (quote ((width . 1200.0) (height . 600.0) (font . "-*-Courier-normal-normal-normal-*-17-*-*-*-m-0-iso10646-1"))))) nil)
elisp--eval-last-sexp(nil)
eval-last-sexp(nil)
funcall-interactively(eval-last-sexp nil)
call-interactively(eval-last-sexp nil nil)
command-execute(eval-last-sexp)
Keith
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 28 Sep 2015 18:01:02 GMT)
Full text and
rfc822 format available.
Message #212 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 28 Sep 2015 18:14:01 GMT)
Full text and
rfc822 format available.
Message #215 received at 21415 <at> debbugs.gnu.org (full text, mbox):
Ah . . . okay . . . on NS with emacs -Q, I get:
(1185 . 600)
Keith
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
At Mon, 28 Sep 2015 20:00:36 +0200,
martin rudalics wrote:
>
> * * *
> . . . 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 28 Sep 2015 21:36:02 GMT)
Full text and
rfc822 format available.
Message #218 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi!
> Makes sense. Pushed as 73b0901..e55460e to master.
Thanks!
> To see the difference, run Emacs -Q and evaluate the following. After the
> > patch is applied, the frame is no longer moves down.
> >
> > (progn
> > (setq frame-resize-pixelwise t)
> > (toggle-frame-maximized))
> >
> > Unfortunately, the frame still doesn't cover the entire screen.
>
> Usually it shouldn't, for maximizing. The problem as far as I
> understand is that NS doesn't have the concept of a "maximized" frame.
>
In earlier OS X versions, the green button was designed to make the window
large enough to accommodate the current document. In many applications,
this meant that the window grew to it's maximum hight, minus those missing
four pixels.
In newer versions, the green button makes the application enter fullscreen
mode.
Internally, however, internally, it's still possible to issue either
"toggleFullScreen" or "performZoom".
When you do what, in Chrome? Try maximizing the Chrome window? How do
> you do that?
If I manually drag the Chrome window to its largest size, I can make it
stretch the entire width, but there will be four pixels missing at the
bottom. Also, if I hit the green button in older OS X versions, the same
four pixels are missing from the bottom.
> We have the concept of a "workarea" as it's returned by
> ‘display-monitor-attributes-list’. On all systems I know of, a
> "maximized" frame occupies the full workarea, a "fullwidth" frame the
> full width of the workarea and a "fullheight" frame the full height of
> the workarea. (I have no idea how these concepts expand to multiple
> monitors though.) How do the four unused pixels relate to your
> workarea?
The function returns the following:
(((name . "SyncMaster")
(geometry 0 0 1600 1200)
(workarea 0 23 1600 1173)
(mm-size 432 324)
(frames #<frame *scratch* 0x101099630>)
(source . "NS"))
((name . "SyncMaster")
(geometry 1600 0 1600 1200)
(workarea 1600 0 1600 1200)
(mm-size 432 324)
(frames)
(source . "NS")))
Interestingly, the workarea of the primary screen is missing four pixels
(1200 - 1173 - 34) = 4.
However, the workarea of the secondary monitor does not. When executing
`toggle-frame-maximized' on the secondary frame (with
`frame-resize-pixelwise' set to t), the frame is placed at the bottom left
corner (which is good), but there are four pixles missing at the TOP of the
screen. (I haven't investigated why, though.)
> In the Info documentation to the `fullscreen' frame parameter, there are
> > two values missing: `nil' and `fullscreen'. The former indicates that the
> > frame is in non-maximized state
>
> nil means "neither of ‘maximized’, ‘fullwidth’, ‘fullheight’ or
> ‘fullboth’".
Yes, I guessed so -- but it needs to be documented, right?
> Interestingly, the function `toggle-frame-fullscreen' seems to
> > use this undocumented parameter value.
>
> It accepts it IIUC but it does not store it. Or what do you mean?
>
My mistake -- I was looking at the 24.5 source. There, the `fullscreen'
property was set to `fullscreen'. It has been fixed in the Emacs 25 source.
> (In addition, there are some control
> > characters showing on the first line.)
>
> Please elaborate.
In the "info" documentation, the first line looks like the following, where
the backslash-numbers represent a single character. I guess this is some
kind of encoding issue...
This parameter specifies whether to maximize the frame\342\200\231s
width,
> On a side note, the NSTRACE rewrite is coming along nicely (it really
> > helped in tracking down this problem) but it's not yet ready for release.
>
> Fine. Can you please get yourself write access to the git repository so
> you can install it when it's ready? I feel some unease installing
> larger changes on systems where I cannot check the consequences myself
> immediately.
I fully understand. Who should I talk to to get write access? (The last
time I was doing any serious work on Emacs, Jan Djärv did the checkins, but
that was before he resigned.)
/ Anders
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 29 Sep 2015 07:23:02 GMT)
Full text and
rfc822 format available.
Message #221 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> Ah . . . okay . . . on NS with emacs -Q, I get:
>
> (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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 29 Sep 2015 07:24:01 GMT)
Full text and
rfc822 format available.
Message #224 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> Internally, however, internally, it's still possible to issue either
> "toggleFullScreen" or "performZoom".
What does "internally" mean here?
> 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.
> 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?
>> nil means "neither of ‘maximized’, ‘fullwidth’, ‘fullheight’ or
>> ‘fullboth’".
>
>
> Yes, I guessed so -- but it needs to be documented, right?
I'll do that.
> 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 29 Sep 2015 07:51:01 GMT)
Full text and
rfc822 format available.
Message #227 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> Date: Tue, 29 Sep 2015 09:23:51 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Keith David Bershatsky <esq <at> lawlist.com>, 21415 <at> debbugs.gnu.org
>
> > 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.
Eli is only one of a few individuals who can do that; there are
others. They all will receive your request for membership.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 29 Sep 2015 17:10:02 GMT)
Full text and
rfc822 format available.
Message #230 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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"))))
At Tue, 29 Sep 2015 09:22:37 +0200, martin rudalics wrote:
>
> > Ah . . . okay . . . on NS with emacs -Q, I get:
> >
> > (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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 29 Sep 2015 17:15:02 GMT)
Full text and
rfc822 format available.
Message #233 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> I get 15, 8, 8:
>
> (frame-parameter nil 'scroll-bar-width): 15
So it's obviously the scroll bar width. I will look into this.
> (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"))))
>
> At Tue, 29 Sep 2015 09:22:37 +0200, martin rudalics wrote:
>>
>> > Ah . . . okay . . . on NS with emacs -Q, I get:
>> >
>> > (1185 . 600)
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 30 Sep 2015 17:55:02 GMT)
Full text and
rfc822 format available.
Message #236 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi!
> Internally, however, internally, it's still possible to issue either
> > "toggleFullScreen" or "performZoom".
>
> What does "internally" mean here?
It means that an application can call those function to perform the
actions, even though there are no user interface buttons the user can click
on.
In the Emacs case, setting the `fullscreen' property to the possible legal
values invokes one of the system functions `toggleFullScreen' or
`performZoom'.
> (((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.
"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.
> > 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?
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.
> 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.
I got my write access rights today! Thanks for suggesting this.
/ Anders
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 30 Sep 2015 18:58:02 GMT)
Full text and
rfc822 format available.
Message #239 received at 21415 <at> debbugs.gnu.org (full text, mbox):
>> (((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.
>
>
> "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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 30 Sep 2015 21:30:05 GMT)
Full text and
rfc822 format available.
Message #242 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> 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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Thu, 01 Oct 2015 06:44:02 GMT)
Full text and
rfc822 format available.
Message #245 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Fri, 02 Oct 2015 08:38:01 GMT)
Full text and
rfc822 format available.
Message #248 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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?
> 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?
> 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.
> 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.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Fri, 02 Oct 2015 08:39:02 GMT)
Full text and
rfc822 format available.
Message #251 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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
[frame-sizes-float.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 03 Oct 2015 06:17:02 GMT)
Full text and
rfc822 format available.
Message #254 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi!
But is the fact that OS X has responded to our zooming request reflected
> 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.
> 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?
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.
> 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?
Yes, it does.
I think this behaviour is fine.
> 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
> "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
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 03 Oct 2015 08:33:02 GMT)
Full text and
rfc822 format available.
Message #257 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> As far as I can tell, fullscreen mode work very well.
Fine.
>> 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.
> 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.
This last one sounds a bit clumsy.
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 03 Oct 2015 11:29:02 GMT)
Full text and
rfc822 format available.
Message #260 received at submit <at> debbugs.gnu.org (full text, mbox):
On Fri 02 Oct 2015, martin rudalics wrote:
> 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 ?
> - 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 03 Oct 2015 12:32:01 GMT)
Full text and
rfc822 format available.
Message #263 received at 21415 <at> debbugs.gnu.org (full text, mbox):
>> @@ -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.
>> - 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 05 Oct 2015 21:04:02 GMT)
Full text and
rfc822 format available.
Message #266 received at submit <at> debbugs.gnu.org (full text, mbox):
On Sat 03 Oct 2015, martin rudalics wrote:
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 06 Oct 2015 07:58:02 GMT)
Full text and
rfc822 format available.
Message #269 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 07 Oct 2015 03:44:02 GMT)
Full text and
rfc822 format available.
Message #272 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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,
martin rudalics wrote:
>
> > 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 13 Oct 2015 10:22:01 GMT)
Full text and
rfc822 format available.
Message #275 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 13 Oct 2015 17:24:02 GMT)
Full text and
rfc822 format available.
Message #278 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 13 Oct 2015 18:00:04 GMT)
Full text and
rfc822 format available.
Message #281 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
On Tue, Oct 13, 2015 at 7:23 PM, Keith David Bershatsky <esq <at> lawlist.com>
wrote:
> 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
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 14 Oct 2015 08:50:04 GMT)
Full text and
rfc822 format available.
Message #284 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> 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
[frame.test.el (application/emacs-lisp, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 14 Oct 2015 15:59:02 GMT)
Full text and
rfc822 format available.
Message #287 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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:
>
* * *
> 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]
[frame_test_osx.txt (application/txt, inline)]
[frame_test_windowsxp.txt (application/txt, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 14 Oct 2015 17:38:01 GMT)
Full text and
rfc822 format available.
Message #290 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 14 Oct 2015 20:35:02 GMT)
Full text and
rfc822 format available.
Message #293 received at 21415 <at> debbugs.gnu.org (full text, mbox):
(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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 14 Oct 2015 21:54:02 GMT)
Full text and
rfc822 format available.
Message #296 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
On Wed, Oct 14, 2015 at 7:37 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> > 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
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Thu, 15 Oct 2015 10:00:05 GMT)
Full text and
rfc822 format available.
Message #299 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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.
> (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".
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 <jan.h.d <at> 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 <eggert <at> 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.
> (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.
> (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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Thu, 15 Oct 2015 10:01:01 GMT)
Full text and
rfc822 format available.
Message #302 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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.
> 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).
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 20 Oct 2015 17:21:02 GMT)
Full text and
rfc822 format available.
Message #305 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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
On Thu, Oct 15, 2015 at 12:00 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> > 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.
>
> > 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).
>
> > 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
>
[Message part 2 (text/html, inline)]
[maximize_and_trace.diff (text/plain, attachment)]
[anders-frame-test.el (application/octet-stream, attachment)]
[emacs-commit-messages.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 21 Oct 2015 01:04:01 GMT)
Full text and
rfc822 format available.
Message #308 received at 21415 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 21 Oct 2015 02:08:01 GMT)
Full text and
rfc822 format available.
Message #311 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
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.
>
Great to hear!
> 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.
>
Please do! I'm on 10.9, so it won't hurt to run things on another version
of the OS.
If you don't find anything, I'll post this patch to emacs-devel, and if no
one objects, I will commit it.
-- Anders
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 21 Oct 2015 08:03:02 GMT)
Full text and
rfc822 format available.
Message #314 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> 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.
Great work! For reasons I don't understand yet the patch also fixes my
biggest problem with GNUStep here, namely that an emacs -Q frame has two
tool bars initially. Maximizing behavior is good though for some
reasons my maximized GNUStep frame (under xfce) still has no external
borders - if you have any ideas how to fix that please tell. Making a
frame just full height works fine instead.
> 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.
Let's leave the old code in for a couple of weeks - this way you keep
the changeset for the commit smaller. If there are no complaints with
the new behavior remove it then.
> You can enable the NSTRACE system by uncommenting a line in nsterm.h, see
> comments for detail.
I shall test that soon and post my comments - if any.
> 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.
Thanks for this as well.
There's one problem with the change log and the code comments: Please
stick to the rule to leave two empty spaces after each sentence. Done
that please install your changes as soon as you have time to do so.
Now the only remaining issue we must fix before the release is that of
the non-shrinking echo area when toggling off the tool bar and the fact
that a frame keeps shrinking when turning off/on the tool bar. I'll
look into that but if you have any ideas ...
Many thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 21 Oct 2015 16:08:02 GMT)
Full text and
rfc822 format available.
Message #317 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi Anders
Four problems encountered when running your patch with GNUStep Emacs
under xfwm4:
(1) With emacs -Q doing
(set-frame-parameter (selected-frame) 'fullscreen 'maximized)
maximizes the frame but (a) the "restore size button" of the window
manager decoration is not enabled, (b) leaves the external borders
visible on screen and (c) has the task bar hide the echo area of the
Emacs frame, see screenshot-1.png.
(a) is probably due to a failed interaction with the window manager.
(b) is not critical because even with GTK, for example, I can still see
the top border on a maximized frame. (c) is not really acceptable.
(2) With
emacs -Q --eval "(setq default-frame-alist '((fullscreen . maximized)))"
I see the same symptoms as with (1) however the initial frame also
contains two tool bar lines, see screenshot-2.png. This is the same
problem I had earlier with emacs -Q and which now disappeared.
(3) With emacs -Q hitting the window manager key for maximizing the
window that has focus, the Emacs frame loses its external borders but
does not extend to the edges of the screen, see screenshot-3.png. Not
grave but slightly annoying. Note that here the "restore size button"
is enabled correctly.
(4) After doing
(set-frame-parameter (selected-frame) 'fullscreen 'fullwidth)
doing
(set-frame-parameter (selected-frame) 'fullscreen 'maximized)
does not change the frame size at all. Same after making a fullheight
frame. I suppose this also makes your ert test fail here.
martin
[screenshot-1.png (image/png, attachment)]
[screenshot-2.png (image/png, attachment)]
[screenshot-3.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Thu, 22 Oct 2015 14:56:02 GMT)
Full text and
rfc822 format available.
Message #320 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I have never used GNUStep, maybe I should try it out so that my patch work
there. Are there build instructions for this somewhere?
Anyway, I think the problem you are seeing is due to the fact that I have
replaced the code in "zoom" with custom code that simply resizes the frame.
On OS X there is nothing special happening when maximizing the frame -- the
outer frame (one pixel thick) is still there, no buttons should change
state etc.
One thing we should try is to check is the old zoom system would work
better in GNUStep after all (this is the first of the three different zoom
version in the code).
Also, it would be interesting to see the NSTRACE output of a session where
we go "fullwidth" and then "maximized" and compare it with what happens
under OS X -- if it still is a problem after changing the zoom method.
When it comes to the double tool bar, I have unfortunately no idea what the
problem is.
-- Anders Lindgren
On Wed, Oct 21, 2015 at 6:07 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> Hi Anders
>
> Four problems encountered when running your patch with GNUStep Emacs
> under xfwm4:
>
>
> (1) With emacs -Q doing
>
> (set-frame-parameter (selected-frame) 'fullscreen 'maximized)
>
> maximizes the frame but (a) the "restore size button" of the window
> manager decoration is not enabled, (b) leaves the external borders
> visible on screen and (c) has the task bar hide the echo area of the
> Emacs frame, see screenshot-1.png.
>
> (a) is probably due to a failed interaction with the window manager.
> (b) is not critical because even with GTK, for example, I can still see
> the top border on a maximized frame. (c) is not really acceptable.
>
>
> (2) With
>
> emacs -Q --eval "(setq default-frame-alist '((fullscreen . maximized)))"
>
> I see the same symptoms as with (1) however the initial frame also
> contains two tool bar lines, see screenshot-2.png. This is the same
> problem I had earlier with emacs -Q and which now disappeared.
>
>
> (3) With emacs -Q hitting the window manager key for maximizing the
> window that has focus, the Emacs frame loses its external borders but
> does not extend to the edges of the screen, see screenshot-3.png. Not
> grave but slightly annoying. Note that here the "restore size button"
> is enabled correctly.
>
>
> (4) After doing
>
> (set-frame-parameter (selected-frame) 'fullscreen 'fullwidth)
>
> doing
>
> (set-frame-parameter (selected-frame) 'fullscreen 'maximized)
>
> does not change the frame size at all. Same after making a fullheight
> frame. I suppose this also makes your ert test fail here.
>
>
> martin
>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Thu, 22 Oct 2015 15:36:02 GMT)
Full text and
rfc822 format available.
Message #323 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> I have never used GNUStep, maybe I should try it out so that my patch work
> there. Are there build instructions for this somewhere?
Don't bother. Hardly anyone but me regularly builds on GNUStep. And I
can't use it anyway - too many other problems.
> Anyway, I think the problem you are seeing is due to the fact that I have
> replaced the code in "zoom" with custom code that simply resizes the frame.
> On OS X there is nothing special happening when maximizing the frame -- the
> outer frame (one pixel thick) is still there, no buttons should change
> state etc.
I suppose so. Maybe I find a way to splice in some code tailored for
GNUStep. But it will have low priority.
> One thing we should try is to check is the old zoom system would work
> better in GNUStep after all (this is the first of the three different zoom
> version in the code).
>
> Also, it would be interesting to see the NSTRACE output of a session where
> we go "fullwidth" and then "maximized" and compare it with what happens
> under OS X -- if it still is a problem after changing the zoom method.
I'll give you some feedback when I'm back there. One problem with
NSTRACE I have is that it clutters output with ns_update_window_begin
and ns_defined_color entries. I now started to comment them out one by
one. Maybe you could devise a method to display these optionally only.
> When it comes to the double tool bar, I have unfortunately no idea what the
> problem is.
It's a bad interaction between GNUStep and the window manager. Maybe I
can find out more.
Meanwhile please install your changes.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Fri, 23 Oct 2015 09:14:02 GMT)
Full text and
rfc822 format available.
Message #326 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
> Meanwhile please install your changes.
Done!
> Now the only remaining issue we must fix before the release is that of
> the non-shrinking echo area when toggling off the tool bar
I wasn't aware of this problem. Can you point me to where it's described.
> and the fact
> that a frame keeps shrinking when turning off/on the tool bar. I'll
> look into that but if you have any ideas ...
I though this was by design. On NextStep, the toolbar is excluded from
`frame-pixel-height', so it makes sense that frame size change when enabled
and disabled. Besides, it's height typically isn't a multiple of the text
size, so the frame would need to be resized slightly anyway (unless
`frame-resize-pixelwise' is set).
There are other things that we would need to fix:
* Symbols in the fringe are inverted. I saw a patch for this on the
emacs-dev mailing list a few weeks ago but I haven't tried it out.
* When the cursor is rendered in the fringe, it's only drawn incorrectly.
(This problem might be related to the previous.)
What is the time frame for the Emacs 25 release? I would be happy to work
on this, but with my family situation, work will progress very, very slowly.
> I'll give you some feedback when I'm back there. One problem with
> NSTRACE I have is that it clutters output with ns_update_window_begin
> and ns_defined_color entries. I now started to comment them out one by
> one. Maybe you could devise a method to display these optionally only.
I have thought about that as well. Currently, the package provides the
macros NSTRACE_WHEN and NSTRACE_UNLESS. I don't use then right now,
unfortunately they only silence the current function, not functions that
may be called by it (which is something that we would want). Hopefully, I
will be able to categorize the functions in such a way that the default
setting would silence some of the more frequently called functions.
/ Anders
On Thu, Oct 22, 2015 at 5:35 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> > I have never used GNUStep, maybe I should try it out so that my patch
> work
> > there. Are there build instructions for this somewhere?
>
> Don't bother. Hardly anyone but me regularly builds on GNUStep. And I
> can't use it anyway - too many other problems.
>
> > Anyway, I think the problem you are seeing is due to the fact that I have
> > replaced the code in "zoom" with custom code that simply resizes the
> frame.
> > On OS X there is nothing special happening when maximizing the frame --
> the
> > outer frame (one pixel thick) is still there, no buttons should change
> > state etc.
>
> I suppose so. Maybe I find a way to splice in some code tailored for
> GNUStep. But it will have low priority.
>
> > One thing we should try is to check is the old zoom system would work
> > better in GNUStep after all (this is the first of the three different
> zoom
> > version in the code).
> >
> > Also, it would be interesting to see the NSTRACE output of a session
> where
> > we go "fullwidth" and then "maximized" and compare it with what happens
> > under OS X -- if it still is a problem after changing the zoom method.
>
> I'll give you some feedback when I'm back there. One problem with
> NSTRACE I have is that it clutters output with ns_update_window_begin
> and ns_defined_color entries. I now started to comment them out one by
> one. Maybe you could devise a method to display these optionally only.
>
> > When it comes to the double tool bar, I have unfortunately no idea what
> the
> > problem is.
>
> It's a bad interaction between GNUStep and the window manager. Maybe I
> can find out more.
>
> Meanwhile please install your changes.
>
> martin
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Fri, 23 Oct 2015 18:02:02 GMT)
Full text and
rfc822 format available.
Message #329 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>> Meanwhile please install your changes.
>
> Done!
Thanks!
>> Now the only remaining issue we must fix before the release is that of
>> the non-shrinking echo area when toggling off the tool bar
>
> I wasn't aware of this problem. Can you point me to where it's described.
Citing Keith's experiments on OSX:
>>> (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.
I'll attach two screenshots. The problem arose after Jan installed this
change:
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 <jan.h.d <at> 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 <eggert <at> 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);
}
where the crucial aspect is the removal of the change_frame_size call.
Note that in updateFrameSize we call change_frame_size only
if (oldr != rows || oldc != cols || neww != oldw || newh != oldh)
which usually won't hold when removing the tool bar. Maybe we should
make the change_frame_size call in updateFrameSize unconditional after
being called from update_frame_tool_bar.
>> and the fact
>> that a frame keeps shrinking when turning off/on the tool bar. I'll
>> look into that but if you have any ideas ...
>
> I though this was by design. On NextStep, the toolbar is excluded from
> `frame-pixel-height', so it makes sense that frame size change when enabled
> and disabled. Besides, it's height typically isn't a multiple of the text
> size, so the frame would need to be resized slightly anyway (unless
> `frame-resize-pixelwise' is set).
All true. But the problem is that enabling the tool bar doesn't make
the overall frame height as large as it has been before disabling the
tool bar. So eventually you might end up with a zero height frame.
> There are other things that we would need to fix:
>
> * Symbols in the fringe are inverted. I saw a patch for this on the
> emacs-dev mailing list a few weeks ago but I haven't tried it out.
>
> * When the cursor is rendered in the fringe, it's only drawn incorrectly.
> (This problem might be related to the previous.)
I've seen these but can't do much about them. It would be great if you
looked into these.
> What is the time frame for the Emacs 25 release? I would be happy to work
> on this, but with my family situation, work will progress very, very slowly.
Bug fixes are practically always accepted. There's a short period
immediately before the release when only regressions wrt the previous
release may be fixed. So you won't have to bother about the time frame.
> I have thought about that as well. Currently, the package provides the
> macros NSTRACE_WHEN and NSTRACE_UNLESS. I don't use then right now,
> unfortunately they only silence the current function, not functions that
> may be called by it (which is something that we would want). Hopefully, I
> will be able to categorize the functions in such a way that the default
> setting would silence some of the more frequently called functions.
That would be fine.
Thanks, martin
[tool-bar-mode-on.png (image/png, attachment)]
[tool-bar-mode-off.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 24 Oct 2015 15:34:02 GMT)
Full text and
rfc822 format available.
Message #332 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I can repeat the problem with the tool-bar here. I'll take a look at it.
I fact, it looks Jan was trying to avoid the fact that the frame could be
constrained. However, one of the changes I made was to remove the
constraining of frames -- so chances are that things would work if we would
revert to the old code.
Anyway, we should try to include as much as possible into test cases, to
ensure that future changes won't break things again.
I put the fringe problem on the "fix queue", but it may take some time
before I get to them.
-- Anders
> Citing Keith's experiments on OSX:
>
> >>> (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.
>
> I'll attach two screenshots. The problem arose after Jan installed this
> change:
>
>
> 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 <jan.h.d <at> 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 <eggert <at> 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);
> }
>
> where the crucial aspect is the removal of the change_frame_size call.
> Note that in updateFrameSize we call change_frame_size only
>
> if (oldr != rows || oldc != cols || neww != oldw || newh != oldh)
>
> which usually won't hold when removing the tool bar. Maybe we should
> make the change_frame_size call in updateFrameSize unconditional after
> being called from update_frame_tool_bar.
>
> >> and the fact
> >> that a frame keeps shrinking when turning off/on the tool bar. I'll
> >> look into that but if you have any ideas ...
> >
> > I though this was by design. On NextStep, the toolbar is excluded from
> > `frame-pixel-height', so it makes sense that frame size change when
> enabled
> > and disabled. Besides, it's height typically isn't a multiple of the text
> > size, so the frame would need to be resized slightly anyway (unless
> > `frame-resize-pixelwise' is set).
>
> All true. But the problem is that enabling the tool bar doesn't make
> the overall frame height as large as it has been before disabling the
> tool bar. So eventually you might end up with a zero height frame.
>
> > There are other things that we would need to fix:
> >
> > * Symbols in the fringe are inverted. I saw a patch for this on the
> > emacs-dev mailing list a few weeks ago but I haven't tried it out.
> >
> > * When the cursor is rendered in the fringe, it's only drawn incorrectly.
> > (This problem might be related to the previous.)
>
> I've seen these but can't do much about them. It would be great if you
> looked into these.
>
> > What is the time frame for the Emacs 25 release? I would be happy to work
> > on this, but with my family situation, work will progress very, very
> slowly.
>
> Bug fixes are practically always accepted. There's a short period
> immediately before the release when only regressions wrt the previous
> release may be fixed. So you won't have to bother about the time frame.
>
> > I have thought about that as well. Currently, the package provides the
> > macros NSTRACE_WHEN and NSTRACE_UNLESS. I don't use then right now,
> > unfortunately they only silence the current function, not functions that
> > may be called by it (which is something that we would want). Hopefully, I
> > will be able to categorize the functions in such a way that the default
> > setting would silence some of the more frequently called functions.
>
> That would be fine.
>
> Thanks, martin
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 24 Oct 2015 18:58:01 GMT)
Full text and
rfc822 format available.
Message #335 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> Anyway, I think the problem you are seeing is due to the fact that I have
> replaced the code in "zoom" with custom code that simply resizes the frame.
> On OS X there is nothing special happening when maximizing the frame -- the
> outer frame (one pixel thick) is still there, no buttons should change
^^^^^
You mean the outer border, I presume. Here the border (some 5 pixels)
is probably removed by the window manager. Don't ask me why and how.
But this and most other problems I reported existed already before your
change.
> state etc.
>
> One thing we should try is to check is the old zoom system would work
> better in GNUStep after all (this is the first of the three different zoom
> version in the code).
I doubt it would help much. One basic problem with GNUStep here is that
the workarea as returned by ‘display-monitor-attributes-list’ is the
same as the geometry returned by that function (are they the same on
OSX?). Hence I see no way to have the GNUStep build recognize the
presence of my taskbar and not hide it when maximizing the frame.
> Also, it would be interesting to see the NSTRACE output of a session where
> we go "fullwidth" and then "maximized" and compare it with what happens
> under OS X -- if it still is a problem after changing the zoom method.
Funnily I can't reproduce this currently, maybe some local change I made
is involved.
BTW
(set-frame-parameter nil 'fullscreen 'fullboth)
is broken here just as it was before your changes. Does it work for you?
> When it comes to the double tool bar, I have unfortunately no idea what the
> problem is.
The crazy thing is that with the old build I got it for a normal initial
frame and now I get for a maximized initial frame ;-)
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 24 Oct 2015 21:45:02 GMT)
Full text and
rfc822 format available.
Message #338 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
On Sat, Oct 24, 2015 at 8:57 PM, martin rudalics <rudalics <at> gmx.at> wrote:
>
> > Anyway, I think the problem you are seeing is due to the fact that I
have
> > replaced the code in "zoom" with custom code that simply resizes the
frame.
> > On OS X there is nothing special happening when maximizing the frame --
the
> > outer frame (one pixel thick) is still there, no buttons should change
> ^^^^^
> You mean the outer border, I presume. Here the border (some 5 pixels)
> is probably removed by the window manager. Don't ask me why and how.
> But this and most other problems I reported existed already before your
> change.
Was the outer frame removed and the icon changed before my rewrites? If so,
try to use the old zoom system instead of the new.
> I doubt it would help much. One basic problem with GNUStep here is that
> the workarea as returned by ‘display-monitor-attributes-list’ is the
> same as the geometry returned by that function (are they the same on
> OSX?). Hence I see no way to have the GNUStep build recognize the
> presence of my taskbar and not hide it when maximizing the frame.
You can check if the NSScreen "frame" and "visibleFrame" would return
different frame. In "ns_menu_bar_height" I use this. Maybe it can be used
under GNUStep to find the height of the taskbar?
> BTW
>
> (set-frame-parameter nil 'fullscreen 'fullboth)
>
> is broken here just as it was before your changes. Does it work for you?
Yes, it enters the real fullscreen mode.
Does it work if you set `ns-use-native-fullscreen' to nil?
> > When it comes to the double tool bar, I have unfortunately no idea what
the
> > problem is.
>
> The crazy thing is that with the old build I got it for a normal initial
> frame and now I get for a maximized initial frame ;-)
Bizzarre... I would check "update_frame_tool_bar" in nsmenu.m or
initFrameFromEmacs in nsterm.m to see if any of those allocate more than
one EmacsToolbar.
I have located the toolbar error. When "setVisible" is called, OS X starts
an animation. When this animation runs, windowWasResized tried to keep up
and update rows and columns. On the way it got lost and the end result was
a bad "row" could. When simply doing nothing when the animation runs,
everything work OK. Hopefully, I will be able to push the end result within
the next couple of days.
-- Anders
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 27 Oct 2015 21:43:01 GMT)
Full text and
rfc822 format available.
Message #341 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
here is a patch to fix the problems with tool-bar-mode, please try it out.
One thing that I have noticed lately is that Emacs often crash when
started. I managed to get a call stack by running gdb, but it doesn't mean
much to me. Do any of you have an idea what is going on?
-- Anders
On Sat, Oct 24, 2015 at 11:43 PM, Anders Lindgren <andlind <at> gmail.com> wrote:
> Hi,
>
> On Sat, Oct 24, 2015 at 8:57 PM, martin rudalics <rudalics <at> gmx.at> wrote:
> >
> > > Anyway, I think the problem you are seeing is due to the fact that I
> have
> > > replaced the code in "zoom" with custom code that simply resizes the
> frame.
> > > On OS X there is nothing special happening when maximizing the frame
> -- the
> > > outer frame (one pixel thick) is still there, no buttons should change
> > ^^^^^
> > You mean the outer border, I presume. Here the border (some 5 pixels)
> > is probably removed by the window manager. Don't ask me why and how.
> > But this and most other problems I reported existed already before your
> > change.
>
> Was the outer frame removed and the icon changed before my rewrites? If
> so, try to use the old zoom system instead of the new.
>
>
> > I doubt it would help much. One basic problem with GNUStep here is that
> > the workarea as returned by ‘display-monitor-attributes-list’ is the
> > same as the geometry returned by that function (are they the same on
> > OSX?). Hence I see no way to have the GNUStep build recognize the
> > presence of my taskbar and not hide it when maximizing the frame.
>
> You can check if the NSScreen "frame" and "visibleFrame" would return
> different frame. In "ns_menu_bar_height" I use this. Maybe it can be used
> under GNUStep to find the height of the taskbar?
>
>
> > BTW
> >
> > (set-frame-parameter nil 'fullscreen 'fullboth)
> >
> > is broken here just as it was before your changes. Does it work for you?
>
> Yes, it enters the real fullscreen mode.
>
> Does it work if you set `ns-use-native-fullscreen' to nil?
>
>
> > > When it comes to the double tool bar, I have unfortunately no idea
> what the
> > > problem is.
> >
> > The crazy thing is that with the old build I got it for a normal initial
> > frame and now I get for a maximized initial frame ;-)
>
> Bizzarre... I would check "update_frame_tool_bar" in nsmenu.m or
> initFrameFromEmacs in nsterm.m to see if any of those allocate more than
> one EmacsToolbar.
>
>
> I have located the toolbar error. When "setVisible" is called, OS X starts
> an animation. When this animation runs, windowWasResized tried to keep up
> and update rows and columns. On the way it got lost and the end result was
> a bad "row" could. When simply doing nothing when the animation runs,
> everything work OK. Hopefully, I will be able to push the end result within
> the next couple of days.
>
> -- Anders
>
>
[Message part 2 (text/html, inline)]
[toolbar.diff (text/plain, attachment)]
[emacs-commit-messages2.txt (text/plain, attachment)]
[start-crash.txt (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 28 Oct 2015 07:55:02 GMT)
Full text and
rfc822 format available.
Message #344 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> One thing that I have noticed lately is that Emacs often crash when
> started. I managed to get a call stack by running gdb, but it doesn't mean
> much to me. Do any of you have an idea what is going on?
>
I think I have solved this one. Input events started coming in before the
init code had finished. By surrounding it by a block_input() and
unblock_input() pair it seems to work better. I will run it for a couple of
days and, if the problems have gone away, I will commit it.
-- Anders
> On Sat, Oct 24, 2015 at 11:43 PM, Anders Lindgren <andlind <at> gmail.com>
> wrote:
>
>> Hi,
>>
>> On Sat, Oct 24, 2015 at 8:57 PM, martin rudalics <rudalics <at> gmx.at> wrote:
>> >
>> > > Anyway, I think the problem you are seeing is due to the fact that I
>> have
>> > > replaced the code in "zoom" with custom code that simply resizes the
>> frame.
>> > > On OS X there is nothing special happening when maximizing the frame
>> -- the
>> > > outer frame (one pixel thick) is still there, no buttons should change
>> > ^^^^^
>> > You mean the outer border, I presume. Here the border (some 5 pixels)
>> > is probably removed by the window manager. Don't ask me why and how.
>> > But this and most other problems I reported existed already before your
>> > change.
>>
>> Was the outer frame removed and the icon changed before my rewrites? If
>> so, try to use the old zoom system instead of the new.
>>
>>
>> > I doubt it would help much. One basic problem with GNUStep here is that
>> > the workarea as returned by ‘display-monitor-attributes-list’ is the
>> > same as the geometry returned by that function (are they the same on
>> > OSX?). Hence I see no way to have the GNUStep build recognize the
>> > presence of my taskbar and not hide it when maximizing the frame.
>>
>> You can check if the NSScreen "frame" and "visibleFrame" would return
>> different frame. In "ns_menu_bar_height" I use this. Maybe it can be used
>> under GNUStep to find the height of the taskbar?
>>
>>
>> > BTW
>> >
>> > (set-frame-parameter nil 'fullscreen 'fullboth)
>> >
>> > is broken here just as it was before your changes. Does it work for
>> you?
>>
>> Yes, it enters the real fullscreen mode.
>>
>> Does it work if you set `ns-use-native-fullscreen' to nil?
>>
>>
>> > > When it comes to the double tool bar, I have unfortunately no idea
>> what the
>> > > problem is.
>> >
>> > The crazy thing is that with the old build I got it for a normal initial
>> > frame and now I get for a maximized initial frame ;-)
>>
>> Bizzarre... I would check "update_frame_tool_bar" in nsmenu.m or
>> initFrameFromEmacs in nsterm.m to see if any of those allocate more than
>> one EmacsToolbar.
>>
>>
>> I have located the toolbar error. When "setVisible" is called, OS X
>> starts an animation. When this animation runs, windowWasResized tried to
>> keep up and update rows and columns. On the way it got lost and the end
>> result was a bad "row" could. When simply doing nothing when the animation
>> runs, everything work OK. Hopefully, I will be able to push the end result
>> within the next couple of days.
>>
>> -- Anders
>>
>>
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 28 Oct 2015 09:55:02 GMT)
Full text and
rfc822 format available.
Message #347 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> here is a patch to fix the problems with tool-bar-mode, please try it out.
Thank you. Works well here. Please install ASAP.
> One thing that I have noticed lately is that Emacs often crash when
> started. I managed to get a call stack by running gdb, but it doesn't mean
> much to me. Do any of you have an idea what is going on?
Leaves me completely clueless :-(
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 28 Oct 2015 09:56:02 GMT)
Full text and
rfc822 format available.
Message #350 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> I think I have solved this one. Input events started coming in before the
> init code had finished. By surrounding it by a block_input() and
> unblock_input() pair it seems to work better. I will run it for a couple of
> days and, if the problems have gone away, I will commit it.
Would that help? I earlier mentioned that here
"on GNUStep making the
toolbar visible in update_frame_tool_bar immediately provokes a call of
windowDidResize which calls updateFrameSize with a not yet updated
toolbar height some time before updateFrameSize gets properly called at
the end of update_frame_tool_bar."
Now update_frame_tool_bar has
block_input ();
...
if (![toolbar isVisible])
[toolbar setVisible: YES];
...
unblock_input ();
and the windowDidResize gets through nevertheless.
martin
BTW, can you reproduce the scenario of bug#21770?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 28 Oct 2015 11:26:02 GMT)
Full text and
rfc822 format available.
Message #353 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Wed, Oct 28, 2015 at 10:55 AM, martin rudalics <rudalics <at> gmx.at> wrote:
> > I think I have solved this one. Input events started coming in before the
> > init code had finished. By surrounding it by a block_input() and
> > unblock_input() pair it seems to work better. I will run it for a couple
> of
> > days and, if the problems have gone away, I will commit it.
>
> Would that help?
Yes, it helped, but for a totally different problem, the startup crash.
> I earlier mentioned that here
>
> "on GNUStep making the
> toolbar visible in update_frame_tool_bar immediately provokes a call of
> windowDidResize which calls updateFrameSize with a not yet updated
> toolbar height some time before updateFrameSize gets properly called at
> the end of update_frame_tool_bar."
>
> Now update_frame_tool_bar has
>
> block_input ();
> ...
> if (![toolbar isVisible])
> [toolbar setVisible: YES];
> ...
> unblock_input ();
>
> and the windowDidResize gets through nevertheless.
>
I have fixed this by introducing a flag, in_animation, which I set
temporarily around calls to setVisible. It makes updateFrameSize return
immediately. Problem solved.
BTW, can you reproduce the scenario of bug#21770?
>
Yes.
I will take a look at fringe-related problems next. I might be able to take
a look at this after that.
I just pushed the toolbar fix and the startup crash fix.
-- Anders
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 28 Oct 2015 19:21:03 GMT)
Full text and
rfc822 format available.
Message #356 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> I will take a look at fringe-related problems next.
That inversion effect is pretty distracting, indeed.
> I might be able to take
> a look at this after that.
>
>
> I just pushed the toolbar fix and the startup crash fix.
Fine. Keith, can you test it? Just turn off/on the tool bar once with
a normal and a maximized frame.
Eventually it would be to nice to have adding/removing the tool bar obey
‘frame-inhibit-implied-resize’ (it currently works OK for the maximized
frame so the fix shouldn't be too hard).
Thanks, martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Thu, 29 Oct 2015 02:49:02 GMT)
Full text and
rfc822 format available.
Message #359 received at 21415 <at> debbugs.gnu.org (full text, mbox):
The following are results of my tests with `emacs-repository-version` "ffa41ad2a02dbd1202d71a08bac34831f25662d0" built this evening (October 28, 2015).
Starting from Emacs -Q, and then turning off the toolbar using the mouse by clicking the option in the menubar, the frame shrinks slightly. Clicking the toolbar option again restores the frame to its original position.
`M-x toggle-frame-maximized` results in a frame properly maximized.
The first time I turned off the toolbar from a maximized frame, the frame shrunk a little. When I turned the toolbar back on again, the frame did not return to a maximized position -- i.e., it remained a few pixels shy of full-screen in terms of height. When I turned the toolbar off again, the main window reduced in size and the height of the echo area increased to about 3 lines in height -- the frame remained the same size. When I turned the toolbar on again, the main window returned to its prior size and the echo area returned to a size of just one line -- the frame stayed the same size (i.e., a few pixels shy of full-screen in terms of height).
Keith
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Thu, 29 Oct 2015 22:55:02 GMT)
Full text and
rfc822 format available.
Message #362 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
> I will take a look at fringe-related problems next.
>
> That inversion effect is pretty distracting, indeed.
I have attached a fix for the fringe issue. The images were reversed, the
background was not transparent (which the rendering code assumed it was),
and finally, all images were mirror flipped left-to-right...
I have attached a patch for this, please try it out. If possible, try to
check if this causes some other image-related problems which I haven't
thought of.
(I will clean up the trace code before I commit it.)
> I might be able to take
> > a look at this after that.
> >
> >
> > I just pushed the toolbar fix and the startup crash fix.
>
> Fine. Keith, can you test it? Just turn off/on the tool bar once with
> a normal and a maximized frame.
>
> Eventually it would be to nice to have adding/removing the tool bar obey
> ‘frame-inhibit-implied-resize’ (it currently works OK for the maximized
> frame so the fix shouldn't be too hard).
>
I don't think it really worked for fullheight frames. When enabling the
tool bar in a maximized frame it looked OK at first glance. However, below
the screen, the window stretched out about three text lines, but due to the
bug Keith reported, the text grid was restricted with the same amount. The
effect was that it only looked like it worked.
Now, when enabling tool-bar mode in a fullheight frames, after Keiths bug
was fixed, the frame stretches below the screen. It's a bit unfortunate,
but it will be a lot of work to do anything about it -- given how the tool
bar is currently implemented.
Keith wrote:
> The first time I turned off the toolbar from a maximized frame, the frame
shrunk a little. When I turned the toolbar back on again, the frame did
not return to a maximized position -- i.e., it remained a few pixels shy of
full-screen in terms of height.
I can see the same effect here. I have only tried this with a fullheight
frame, in which case it worked. I will take a look at it and try to figure
out what the difference between the fullheight and maximized cases.
-- Anders
Ps. I will be away over the weekend -- hopefully I will be able to answer
mail but not do any Emacs core work.
[Message part 2 (text/html, inline)]
[emacs-commit-messages-fringe.txt (text/plain, attachment)]
[fringe.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Fri, 30 Oct 2015 08:00:05 GMT)
Full text and
rfc822 format available.
Message #365 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> I have attached a fix for the fringe issue. The images were reversed, the
> background was not transparent (which the rendering code assumed it was),
> and finally, all images were mirror flipped left-to-right...
>
> I have attached a patch for this, please try it out. If possible, try to
> check if this causes some other image-related problems which I haven't
> thought of.
Thanks. Continuation glyphs now look good. Here on GNUStep the left
fringe occasionally gets clipped, probably by the adjacent scroll bar.
Maybe some "fringe sizes should be multiples of character sizes" issue I
haven't been able to trace yet. In any case please check in your fix.
Please mention the bug number in ChangeLog and commit message and inform
the OP, possibly closing the bug (I think it's Bug#21301).
Keith - yet another fix you should test ;-)
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Fri, 30 Oct 2015 08:12:01 GMT)
Full text and
rfc822 format available.
Message #368 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> Thanks. Continuation glyphs now look good. Here on GNUStep the left
> fringe occasionally gets clipped, probably by the adjacent scroll bar.
> Maybe some "fringe sizes should be multiples of character sizes" issue I
> haven't been able to trace yet.
... which might be related to issues we discussed earlier when you
reported bug#16856. Did you ever look into that again?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Fri, 30 Oct 2015 09:01:01 GMT)
Full text and
rfc822 format available.
Message #371 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi!
I'm glad that it works, I will check in the changes, hopefully, later today.
When it comes to the ChangeLog -- I noticed that it hadn't been updated for
a while and assumed that it is now automatically populated from the git
commit messages -- is this correct, or should I also manually update it?
Also, is there a major mode like "change-log-mode" that would work with git
commits, i.e. where text is formatted like a ChangeLog entry but without
requiring the text to be indented?
... which might be related to issues we discussed earlier when you
> reported bug#16856. Did you ever look into that again?
No, at the time I didn't have the time and energy to look into it. In
addition, I found that when I resized the frame pixel-perfect (using my
multicolumn package), the problem didn't occur and I was happy with that.
I can see if the problem is still present, and if not, we can close that
issue.
When it comes to the bug tracker -- can I filter the bug reports so that I
can only see the ones related to the NextStep port?
-- Anders
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Fri, 30 Oct 2015 09:36:02 GMT)
Full text and
rfc822 format available.
Message #374 received at 21415 <at> debbugs.gnu.org (full text, mbox):
> When it comes to the ChangeLog -- I noticed that it hadn't been updated for
> a while
"The" ChangeLog is now in the source directory of the Emacs tree,
currently we are at ChangeLog.2.
> and assumed that it is now automatically populated from the git
> commit messages -- is this correct, ....
This is correct.
> or should I also manually update it?
No. Kind souls (usually Glen) take care of it at least once a week.
> Also, is there a major mode like "change-log-mode" that would work with git
> commits, i.e. where text is formatted like a ChangeLog entry but without
> requiring the text to be indented?
I think that some vc-... function does that now, but I don't use it.
> ... which might be related to issues we discussed earlier when you
>> reported bug#16856. Did you ever look into that again?
>
>
> No, at the time I didn't have the time and energy to look into it. In
> addition, I found that when I resized the frame pixel-perfect (using my
> multicolumn package), the problem didn't occur and I was happy with that.
Do you advice users of your package to resize pixel-perfectly?
> I can see if the problem is still present, and if not, we can close that
> issue.
OK.
> When it comes to the bug tracker -- can I filter the bug reports so that I
> can only see the ones related to the NextStep port?
There was a way to tag bugs wrt the OS. But I don't see it any more.
And it's not mentioned in ../admin/notes/bugtracker.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Fri, 30 Oct 2015 10:19:01 GMT)
Full text and
rfc822 format available.
Message #377 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi!
> Do you advice users of your package to resize pixel-perfectly?
The package does it for them. One purpose of the package is to create a
frame layout with a number of side-by-side windows. The user specifies the
width of the windows in characters, e.g. 80, and the package then finds out
how many windows will fit, resizes and positions the frame accordingly, and
creates the windows.
I use this in my startup code, so whenever I open Emacs, it starts with six
side-by-side windows that cover the screen form top to bottom.
In fact, one thing on my TODO list is to reimplement the positioning part
of the package using your new border information function. Right now, the
package hardcodes a lot of information about the properties of things like
the window title and border dimensions, in different window systems. If I
can eliminate all the hardcoded values, it would be a receipt that the
functions provide the right kind of information.
> > When it comes to the bug tracker -- can I filter the bug reports so
that I
> > can only see the ones related to the NextStep port?
>
> There was a way to tag bugs wrt the OS. But I don't see it any more.
> And it's not mentioned in ../admin/notes/bugtracker.
Too bad, it makes it kind of hard to maintain a port if there is no
efficient way to see relevant bug reports.
-- Anders
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 01 Nov 2015 16:55:02 GMT)
Full text and
rfc822 format available.
Message #380 received at 21415 <at> debbugs.gnu.org (full text, mbox):
A fix for bug 21301 would indeed be wonderful. I anticipate having some free time later this evening to look more carefully at this recent thread to see what patch needs to be applied to test out the fix and I'll try it and report back.
Keith
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
At Fri, 30 Oct 2015 08:59:47 +0100,
martin rudalics wrote:
>
* * *
> Please mention the bug number in ChangeLog and commit message and inform
> the OP, possibly closing the bug (I think it's Bug#21301).
>
> Keith - yet another fix you should test ;-)
>
> martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sun, 01 Nov 2015 21:10:02 GMT)
Full text and
rfc822 format available.
Message #383 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Keith,
Please check the diff I posted in this thread on the 29:th, it solves all
the fringe problems I have seen -- both the fringe icons and the rendering
of the cursor when in the fringe.
-- Anders
On Sun, Nov 1, 2015 at 5:53 PM, Keith David Bershatsky <esq <at> lawlist.com>
wrote:
> A fix for bug 21301 would indeed be wonderful. I anticipate having some
> free time later this evening to look more carefully at this recent thread
> to see what patch needs to be applied to test out the fix and I'll try it
> and report back.
>
> Keith
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> At Fri, 30 Oct 2015 08:59:47 +0100,
> martin rudalics wrote:
> >
> * * *
> > Please mention the bug number in ChangeLog and commit message and inform
> > the OP, possibly closing the bug (I think it's Bug#21301).
> >
> > Keith - yet another fix you should test ;-)
> >
> > martin
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 02 Nov 2015 05:19:01 GMT)
Full text and
rfc822 format available.
Message #386 received at 21415 <at> debbugs.gnu.org (full text, mbox):
With respect to fringe.diff from October 29, 2015, applied to a latest download of Emacs master branch, an issue remains with respect to empty line indicators at the end of the buffer. It looks like two of the indicators are correct, then one is reversed, then two are correct, then one is reversed, and so on. The fringe bitmap images prior to the end of the buffer looked correct for the few that I tried.
Thanks,
Keith
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 02 Nov 2015 20:52:02 GMT)
Full text and
rfc822 format available.
Message #389 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
The empty line indicator seems to be a new kind of fringe bitmap used to
create repetitive patterns. The code was only half-hearted when it comes to
this, as it cashed only the first of the alternative images. I rewrote the
code to cache the full image and select a suitable subpart of the when
drawing.
If you have time, please try out the attached patch.
Thanks!
-- Anders
On Mon, Nov 2, 2015 at 6:18 AM, Keith David Bershatsky <esq <at> lawlist.com>
wrote:
> With respect to fringe.diff from October 29, 2015, applied to a latest
> download of Emacs master branch, an issue remains with respect to empty
> line indicators at the end of the buffer. It looks like two of the
> indicators are correct, then one is reversed, then two are correct, then
> one is reversed, and so on. The fringe bitmap images prior to the end of
> the buffer looked correct for the few that I tried.
>
> Thanks,
>
> Keith
>
[Message part 2 (text/html, inline)]
[fringe2.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 03 Nov 2015 06:30:02 GMT)
Full text and
rfc822 format available.
Message #392 received at 21415 <at> debbugs.gnu.org (full text, mbox):
Using the latest download of Emacs master branch (tonight November 2, 2015 at about 10:15 p.m. PST) and fringe2.diff, I was not able to complete the building process. I only tried one time, but think the same result would probably happen if I tried again.
font.c: In function 'font_fill_lglyph_metrics':
font.c:4356: warning: comparison is always true due to limited range of data type
font.c:4356: warning: comparison is always true due to limited range of data type
font.c:4356: warning: comparison is always true due to limited range of data type
font.c:4356: warning: comparison is always true due to limited range of data type
font.c: In function 'Ffont_variation_glyphs':
font.c:4473: warning: comparison is always true due to limited range of data type
font.c:4473: warning: comparison is always true due to limited range of data type
font.c:4473: warning: comparison is always true due to limited range of data type
font.c:4473: warning: comparison is always true due to limited range of data type
font.c: In function 'Finternal_char_font':
font.c:4576: warning: comparison is always true due to limited range of data type
font.c:4576: warning: comparison is always true due to limited range of data type
font.c:4576: warning: comparison is always true due to limited range of data type
font.c:4576: warning: comparison is always true due to limited range of data type
font.c: In function 'Ffont_get_glyphs':
font.c:4909: warning: comparison is always true due to limited range of data type
font.c:4909: warning: comparison is always true due to limited range of data type
font.c:4909: warning: comparison is always true due to limited range of data type
font.c:4909: warning: comparison is always true due to limited range of data type
CC print.o
CC lread.o
CC syntax.o
CC unexmacosx.o
CC bytecode.o
CC process.o
process.c: In function 'record_deleted_pid':
process.c:818: warning: comparison is always true due to limited range of data type
process.c:818: warning: comparison is always true due to limited range of data type
process.c: In function 'Fprocess_id':
process.c:938: warning: comparison is always true due to limited range of data type
process.c:938: warning: comparison is always true due to limited range of data type
CC gnutls.o
CC callproc.o
CC region-cache.o
CC sound.o
CC atimer.o
CC doprnt.o
CC intervals.o
CC textprop.o
CC composite.o
composite.c: In function 'fill_gstring_body':
composite.c:843: warning: comparison is always true due to limited range of data type
composite.c:843: warning: comparison is always true due to limited range of data type
composite.c:843: warning: comparison is always true due to limited range of data type
composite.c:843: warning: comparison is always true due to limited range of data type
composite.c:843: warning: comparison is always true due to limited range of data type
composite.c:843: warning: comparison is always true due to limited range of data type
CC xml.o
CC profiler.o
CC decompress.o
CC fontset.o
CC fringe.o
CC image.o
CC nsterm.o
nsterm.m: In function 'ns_draw_fringe_bitmap':
nsterm.m:2507: error: 'len' undeclared (first use in this function)
nsterm.m:2507: error: (Each undeclared identifier is reported only once
nsterm.m:2507: error: for each function it appears in.)
make[1]: *** [nsterm.o] Error 1
make: *** [src] Error 2
~/Desktop/emacs $
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Tue, 03 Nov 2015 08:55:02 GMT)
Full text and
rfc822 format available.
Message #395 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
My mistake... I made a last minute change, I changed "len" to
"full_height", and apparently didn't change it in all places.
I can post a new patch when I get home tonight, alternatively you can try
to do the change yourself and recompile.
/ Anders
On Tue, Nov 3, 2015 at 7:29 AM, Keith David Bershatsky <esq <at> lawlist.com>
wrote:
> Using the latest download of Emacs master branch (tonight November 2, 2015
> at about 10:15 p.m. PST) and fringe2.diff, I was not able to complete the
> building process. I only tried one time, but think the same result would
> probably happen if I tried again.
>
> font.c: In function 'font_fill_lglyph_metrics':
> font.c:4356: warning: comparison is always true due to limited range of
> data type
> font.c:4356: warning: comparison is always true due to limited range of
> data type
> font.c:4356: warning: comparison is always true due to limited range of
> data type
> font.c:4356: warning: comparison is always true due to limited range of
> data type
> font.c: In function 'Ffont_variation_glyphs':
> font.c:4473: warning: comparison is always true due to limited range of
> data type
> font.c:4473: warning: comparison is always true due to limited range of
> data type
> font.c:4473: warning: comparison is always true due to limited range of
> data type
> font.c:4473: warning: comparison is always true due to limited range of
> data type
> font.c: In function 'Finternal_char_font':
> font.c:4576: warning: comparison is always true due to limited range of
> data type
> font.c:4576: warning: comparison is always true due to limited range of
> data type
> font.c:4576: warning: comparison is always true due to limited range of
> data type
> font.c:4576: warning: comparison is always true due to limited range of
> data type
> font.c: In function 'Ffont_get_glyphs':
> font.c:4909: warning: comparison is always true due to limited range of
> data type
> font.c:4909: warning: comparison is always true due to limited range of
> data type
> font.c:4909: warning: comparison is always true due to limited range of
> data type
> font.c:4909: warning: comparison is always true due to limited range of
> data type
> CC print.o
> CC lread.o
> CC syntax.o
> CC unexmacosx.o
> CC bytecode.o
> CC process.o
> process.c: In function 'record_deleted_pid':
> process.c:818: warning: comparison is always true due to limited range of
> data type
> process.c:818: warning: comparison is always true due to limited range of
> data type
> process.c: In function 'Fprocess_id':
> process.c:938: warning: comparison is always true due to limited range of
> data type
> process.c:938: warning: comparison is always true due to limited range of
> data type
> CC gnutls.o
> CC callproc.o
> CC region-cache.o
> CC sound.o
> CC atimer.o
> CC doprnt.o
> CC intervals.o
> CC textprop.o
> CC composite.o
> composite.c: In function 'fill_gstring_body':
> composite.c:843: warning: comparison is always true due to limited range
> of data type
> composite.c:843: warning: comparison is always true due to limited range
> of data type
> composite.c:843: warning: comparison is always true due to limited range
> of data type
> composite.c:843: warning: comparison is always true due to limited range
> of data type
> composite.c:843: warning: comparison is always true due to limited range
> of data type
> composite.c:843: warning: comparison is always true due to limited range
> of data type
> CC xml.o
> CC profiler.o
> CC decompress.o
> CC fontset.o
> CC fringe.o
> CC image.o
> CC nsterm.o
> nsterm.m: In function 'ns_draw_fringe_bitmap':
> nsterm.m:2507: error: 'len' undeclared (first use in this function)
> nsterm.m:2507: error: (Each undeclared identifier is reported only once
> nsterm.m:2507: error: for each function it appears in.)
> make[1]: *** [nsterm.o] Error 1
> make: *** [src] Error 2
> ~/Desktop/emacs $
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 04 Nov 2015 02:22:02 GMT)
Full text and
rfc822 format available.
Message #398 received at 21415 <at> debbugs.gnu.org (full text, mbox):
Ah, yes, `fringe3.diff` does indeed fix the issue with empty line fringe bitmap indicators at the end of the buffer. Good job!
Keith
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
At Tue, 3 Nov 2015 19:01:13 +0100,
Anders Lindgren wrote:
>
> Hi,
>
> here is a new version of the fringe patch.
>
> -- Anders
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Wed, 04 Nov 2015 05:55:02 GMT)
Full text and
rfc822 format available.
Message #401 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Wonderful news!
I just pushed the fringe patch. Thanks for testing it!
-- Anders Lindgren
On Wed, Nov 4, 2015 at 3:21 AM, Keith David Bershatsky <esq <at> lawlist.com>
wrote:
> Ah, yes, `fringe3.diff` does indeed fix the issue with empty line fringe
> bitmap indicators at the end of the buffer. Good job!
>
> Keith
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> At Tue, 3 Nov 2015 19:01:13 +0100,
> Anders Lindgren wrote:
> >
> > Hi,
> >
> > here is a new version of the fringe patch.
> >
> > -- Anders
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Sat, 14 Nov 2015 19:43:02 GMT)
Full text and
rfc822 format available.
Message #404 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
I found some time to look into this. When the frame was maximized and the
tool-bar was disabled, the function x_set_window_size was never called.
The following patch makes the frame exit the fullheight or maximized states
when the tool-bar is disabled, which makes the call x_set_window_size
reappear. It does NOT, however, return the frame to the fullheight or
maximized states when the toolbar is re-enabled (I don't even know if it
should). In addition, it does not support frame-inhibit-implied-resize
either (which would require a lot more work).
I read in the emacs-devel group that there is a feature-freeze in place --
does this mean that I shouldn't commit this?
Also, the current Emacs master branch doesn't build on OS X 10.6.8 after an
attempt to David Reitter to eliminate warnings -- I think it's an easy fix
(David don't have access to a 10.6.8 machine but fortunately I do).
-- Anders
On Thu, Oct 29, 2015 at 3:47 AM, Keith David Bershatsky <esq <at> lawlist.com>
wrote:
> The following are results of my tests with `emacs-repository-version`
> "ffa41ad2a02dbd1202d71a08bac34831f25662d0" built this evening (October 28,
> 2015).
>
> Starting from Emacs -Q, and then turning off the toolbar using the mouse
> by clicking the option in the menubar, the frame shrinks slightly. Clicking
> the toolbar option again restores the frame to its original position.
>
> `M-x toggle-frame-maximized` results in a frame properly maximized.
>
> The first time I turned off the toolbar from a maximized frame, the frame
> shrunk a little. When I turned the toolbar back on again, the frame did
> not return to a maximized position -- i.e., it remained a few pixels shy of
> full-screen in terms of height. When I turned the toolbar off again, the
> main window reduced in size and the height of the echo area increased to
> about 3 lines in height -- the frame remained the same size. When I turned
> the toolbar on again, the main window returned to its prior size and the
> echo area returned to a size of just one line -- the frame stayed the same
> size (i.e., a few pixels shy of full-screen in terms of height).
>
> Keith
>
[Message part 2 (text/html, inline)]
[toolbar-maximized.diff (text/plain, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 16 Nov 2015 03:07:02 GMT)
Full text and
rfc822 format available.
Message #407 received at 21415 <at> debbugs.gnu.org (full text, mbox):
Using a download of Emacs master branch from this morning (11/15/2015) -- emacs-repository-version "70f1fda4ae6abb5e11dcf281738c25f6f5b06061", and applying toolbar-maximized.diff, and building on OSX Server 10.6.8, I repeated the previous tests.
This time around everything worked as expected.
(1) the default frame with Emacs -Q shrunk a bit and then returned to the previous size when toggling the tool-bar with the mouse. The beginning bounds were (0, 22, 595, 640), which was reduced to (0, 22, 595, 608), which then increased again to (0, 22, 595, 640).
(2) the full-size frame when issuing the command toggle-frame-maximized had a bounds of (0, 22, 1920, 1080). When toggling the tool-bar the mouse, the bounds reduced to (0, 22, 1920, 1048). When toggling the tool-bar again with the mouse, the bounds returned to (0, 22, 1920, 1080).
I tested the bounds with the applescript described in feature request #18283.
Keith
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 16 Nov 2015 03:17:02 GMT)
Full text and
rfc822 format available.
Message #410 received at 21415 <at> debbugs.gnu.org (full text, mbox):
I really enjoy using OSX 10.6.8 and presently have three (3) computers that I regularly use with that operating system running natively.
I would undoubtedly need to undergo several sessions of therapeutic interventions to help me cope with a world without OSX 10.6.8 if Emacs master branch someday becomes unavailable as to that OSX version.
Anything that can be done to maintain compatibility with OSX 10.6.8 would be greatly appreciated -- pretty please with sugar on top -- :)
Keith
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
At Sat, 14 Nov 2015 20:42:04 +0100,
Anders Lindgren wrote:
>
> * * *
>
> Also, the current Emacs master branch doesn't build on OS X 10.6.8 after an
> attempt to David Reitter to eliminate warnings -- I think it's an easy fix
> (David don't have access to a 10.6.8 machine but fortunately I do).
>
> -- Anders
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 16 Nov 2015 07:55:02 GMT)
Full text and
rfc822 format available.
Message #413 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi,
Yesterday I checked in a fix for the OS X 10.6.8 build problem. However, I
used the emacs-25 branch, which is where active development should go after
Fridays feature freeze. Please try it out and let me know if it works for
you.
I'm 100% behind supporting 10.6.8. There are a number of Mac:s that can't
be upgraded to newer OS X versions, but otherwise run perfectly fine.
However, there has been talk about dropping 10.5 and PowerPC support, but I
haven't seen any definitive decision regarding this. I guess they will fall
of the wagon once there are no developers actively supporting them.
(Personally, I don't have access to a PowerPC machine, and wouldn't spend
my free time supporting it anyway.)
-- Anders
On Mon, Nov 16, 2015 at 4:16 AM, Keith David Bershatsky <esq <at> lawlist.com>
wrote:
> I really enjoy using OSX 10.6.8 and presently have three (3) computers
> that I regularly use with that operating system running natively.
>
> I would undoubtedly need to undergo several sessions of therapeutic
> interventions to help me cope with a world without OSX 10.6.8 if Emacs
> master branch someday becomes unavailable as to that OSX version.
>
> Anything that can be done to maintain compatibility with OSX 10.6.8 would
> be greatly appreciated -- pretty please with sugar on top -- :)
>
> Keith
>
> ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
>
> At Sat, 14 Nov 2015 20:42:04 +0100,
> Anders Lindgren wrote:
> >
> > * * *
> >
> > Also, the current Emacs master branch doesn't build on OS X 10.6.8 after
> an
> > attempt to David Reitter to eliminate warnings -- I think it's an easy
> fix
> > (David don't have access to a 10.6.8 machine but fortunately I do).
> >
> > -- Anders
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 16 Nov 2015 09:12:02 GMT)
Full text and
rfc822 format available.
Message #416 received at 21415 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Thanks for testing this.
Yesterday I pushed this fix (or rather a variant of it) to the "emacs-25"
branch.
When it comes to feature request #18283 -- this sounds like good idea. But
before I add the applescript lines, I would like to read up on the issue a
bit.
I have found the bug database really hard to navigate -- do you know of any
other OS X-related bugs that are still open, I might as well look into
those while I'm at it.
-- Anders
On Mon, Nov 16, 2015 at 4:06 AM, Keith David Bershatsky <esq <at> lawlist.com>
wrote:
> Using a download of Emacs master branch from this morning (11/15/2015) --
> emacs-repository-version "70f1fda4ae6abb5e11dcf281738c25f6f5b06061", and
> applying toolbar-maximized.diff, and building on OSX Server 10.6.8, I
> repeated the previous tests.
>
> This time around everything worked as expected.
>
> (1) the default frame with Emacs -Q shrunk a bit and then returned to the
> previous size when toggling the tool-bar with the mouse. The beginning
> bounds were (0, 22, 595, 640), which was reduced to (0, 22, 595, 608),
> which then increased again to (0, 22, 595, 640).
>
> (2) the full-size frame when issuing the command toggle-frame-maximized
> had a bounds of (0, 22, 1920, 1080). When toggling the tool-bar the mouse,
> the bounds reduced to (0, 22, 1920, 1048). When toggling the tool-bar
> again with the mouse, the bounds returned to (0, 22, 1920, 1080).
>
> I tested the bounds with the applescript described in feature request
> #18283.
>
> Keith
>
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 16 Nov 2015 17:27:01 GMT)
Full text and
rfc822 format available.
Message #419 received at 21415 <at> debbugs.gnu.org (full text, mbox):
I was able to successfully build Emacs master branch today on 10.6.8 -- emacs-repository-version "937565268a5dc3377d4c9bff6d48eb3645a77160".
I am not aware of any other open OSX specific bugs.
Keith
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
At Mon, 16 Nov 2015 10:11:03 +0100,
Anders Lindgren wrote:
>
> * * *
>
> I have found the bug database really hard to navigate -- do you know of any
> other OS X-related bugs that are still open, I might as well look into
> those while I'm at it.
>
> -- Anders
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Mon, 16 Nov 2015 23:53:01 GMT)
Full text and
rfc822 format available.
Message #422 received at 21415 <at> debbugs.gnu.org (full text, mbox):
Anders:
I just remembered an open bug that is OSX specific:
bug#21714: 25.0.50; image-metadata using Emacs --with-ns prevents *.gif
Keth
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
At Mon, 16 Nov 2015 10:11:03 +0100,
Anders Lindgren wrote:
>
> * * *
>
> I have found the bug database really hard to navigate -- do you know of any
> other OS X-related bugs that are still open, I might as well look into
> those while I'm at it.
>
> -- Anders
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#21415; Package
emacs.
(Thu, 17 Sep 2020 17:55:01 GMT)
Full text and
rfc822 format available.
Message #425 received at 21415 <at> debbugs.gnu.org (full text, mbox):
Keith David Bershatsky <esq <at> lawlist.com> writes:
> Using a download of Emacs master branch from this morning (11/15/2015)
> -- emacs-repository-version
> "70f1fda4ae6abb5e11dcf281738c25f6f5b06061", and applying
> toolbar-maximized.diff, and building on OSX Server 10.6.8, I repeated
> the previous tests.
>
> This time around everything worked as expected.
This was an very, very long bug report, and it seems like many, many
pixel-resizing bugs were fixed. Skimming it, it doesn't seem clear why
the bug report was left open, but I may very well have missed
something. I'm closing it anyway -- if there are anything more to be
done in this area, it's probably more productive to open new bug reports
for these specific things.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
bug closed, send any further explanations to
21415 <at> debbugs.gnu.org and Keith David Bershatsky <esq <at> lawlist.com>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Thu, 17 Sep 2020 17:55:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Fri, 16 Oct 2020 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 42 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.