* bug#27923: 24.3; -iconic switch screws up geometry @ 2017-08-02 20:41 Geoff Kuenning 2017-08-17 9:22 ` martin rudalics 2022-02-21 15:32 ` Lars Ingebrigtsen 0 siblings, 2 replies; 24+ messages in thread From: Geoff Kuenning @ 2017-08-02 20:41 UTC (permalink / raw) To: 27923 In 24.3.1, starting emacs with the "-iconic" switch causes the main emacs window to be sized to the width of the icon rather than the width specified in the X resource database. Interestingly, the height is still correct. Compare the window created by: $ emacs & with the one from: $ emacs -iconic & On my system, the output for "xrdb -query | grep -i emacs" is: gnuemacs.geometry: 80x78+1180+0 Emacs.Font: -misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1 gnuemacs*cursorColor: red lemacs*cursorColor: red (I realize that some of these entries are obsolete...) In GNU Emacs 24.3.1 (x86_64-suse-linux-gnu, GTK+ Version 3.20.10) of 2017-07-05 on cloud131 Windowing system distributor `The X.Org Foundation', version 11.0.11803000 System Description: openSUSE Leap 42.2 Configured using: `configure '--with-pop' '--without-hesiod' '--with-kerberos' '--with-kerberos5' '--with-xim' '--with-wide-int' '--enable-autodepend' '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--localstatedir=/var' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--with-x' '--with-sound' '--with-xpm' '--with-jpeg' '--with-tiff' '--with-gif' '--with-png' '--with-rsvg' '--with-dbus' '--without-gpm' '--with-x-toolkit=gtk3' '--with-toolkit-scroll-bars' '--x-includes=/usr/include' '--x-libraries=/usr/lib64' '--with-xft' '--with-libotf' '--with-m17n-flt' '--build=x86_64-suse-linux' 'build_alias=x86_64-suse-linux' 'CFLAGS=-fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -D_GNU_SOURCE -pipe -Wno-pointer-sign -Wno-unused-variable -Wno-unused-label -Wno-unprototyped-calls -fno-optimize-sibling-calls -DSYSTEM_PURESIZE_EXTRA=55000 -DSITELOAD_PURESIZE_EXTRA=10000 ' 'LDFLAGS=-Wl,-O2 -Wl,--hash-size=65521'' Important settings: value of $LC_ALL: en_US.utf-8 value of $LC_COLLATE: C value of $LC_NUMERIC: POSIX value of $LANG: en_US.utf-8 locale-coding-system: utf-8-unix default enable-multibyte-characters: t Major mode: Text Minor modes in effect: desktop-save-mode: t shell-dirtrack-mode: t tooltip-mode: t mouse-wheel-mode: t file-name-shadow-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t auto-fill-function: do-auto-fill Recent input: M-x e m a c s - b u <tab> <tab> <tab> C-g M-x a p r o p o s <return> b u g <return> C-x o C-v C-v C-v C-v C-x 0 M-x r e p o r t <tab> <return> Recent messages: Loading `uniquify': old-style backquotes detected! PGP version set to 5.0. Setting up indent for shell type sh setting up indent stuff Indentation variables are now local. Indentation setup for shell type sh Note: file is write protected Wrote /home/geoff/.emacs.desktop.lock Desktop: 27 buffers restored. For information about GNU Emacs and the GNU system, type C-h C-a. Quit Load-path shadows: /home/geoff/lib/notes/notes-first hides ~geoff/elisp/notes-first /home/geoff/lib/notes/notes-xemacs hides ~geoff/elisp/notes-xemacs /home/geoff/lib/notes/notes-mode hides ~geoff/elisp/notes-mode /home/geoff/lib/notes/notes-index-mode hides ~geoff/elisp/notes-index-mode /home/geoff/lib/notes/notes-variables hides ~geoff/elisp/notes-variables /home/geoff/lib/notes/notes-url hides ~geoff/elisp/notes-url /home/geoff/lib/notes/notes-emacs hides ~geoff/elisp/notes-emacs /home/geoff/lib/notes/notes-aux hides ~geoff/elisp/notes-aux /home/geoff/lib/notes/notes-bootstrap hides ~geoff/elisp/notes-bootstrap /usr/local/share/emacs/site-lisp/rep-debugger hides /usr/share/emacs/site-lisp/rep-debugger /usr/share/emacs/site-lisp/lilypond-init hides /usr/share/emacs/site-lisp/site-start.d/lilypond-init /usr/share/emacs/site-lisp/flim/md5 hides /usr/share/emacs/site-lisp/w3/md5 /usr/share/emacs/site-lisp/devices hides /usr/share/emacs/site-lisp/w3/devices /usr/share/emacs/site-lisp/suse-start-xslide hides /usr/share/emacs/site-lisp/xslide/suse-start-xslide ~geoff/elisp/uniquify hides /usr/share/emacs/24.3/lisp/uniquify ~geoff/elisp/remember/remember hides /usr/share/emacs/24.3/lisp/textmodes/remember Features: (shadow sort mail-extr gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime password-cache dig gnus-sum nnoo gnus-group gnus-undo nnmail mail-source gnus-start gnus-spec gnus-int gnus-range gnus-win gnus gnus-ems nnheader gnus-util wid-edit emacsbug message idna mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils help-mode apropos sh-script smie executable bibtex desktop mailcap org byte-opt warnings bytecomp byte-compile cconv advice help-fns cl-lib advice-preload ob-tangle ob-ref ob-lob ob-table org-footnote org-src ob-comint ob-keys org-pcomplete org-list org-faces org-entities noutline outline easy-mmode org-version ob-emacs-lisp ob org-compat org-macs ob-eval org-loaddefs format-spec find-func cal-menu calendar cal-loaddefs remember paren mailcrypt rfc822 easymenu notes-variables notes-emacs uniquify server pabbrev tex-mode compile shell pcomplete comint ansi-color ring time-date delsel lpr tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) -- Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ An undocumented program is as useless as a non-working one. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2017-08-02 20:41 bug#27923: 24.3; -iconic switch screws up geometry Geoff Kuenning @ 2017-08-17 9:22 ` martin rudalics [not found] ` <pniziawo843.fsf@bow.cs.hmc.edu> 2022-02-21 15:32 ` Lars Ingebrigtsen 1 sibling, 1 reply; 24+ messages in thread From: martin rudalics @ 2017-08-17 9:22 UTC (permalink / raw) To: Geoff Kuenning, 27923 > In 24.3.1, starting emacs with the "-iconic" switch causes the main > emacs window to be sized to the width of the icon rather than the width > specified in the X resource database. Interestingly, the height is > still correct. Compare the window created by: > > $ emacs & > > with the one from: > > $ emacs -iconic & > > On my system, the output for "xrdb -query | grep -i emacs" is: > > gnuemacs.geometry: 80x78+1180+0 > Emacs.Font: -misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1 > gnuemacs*cursorColor: red > lemacs*cursorColor: red > > (I realize that some of these entries are obsolete...) Thanks for the report; apologizes for the late response. Are you sure that your display is at least 1900 pixels wide? If so, then when with emacs -Q you evaluate the form (setq default-frame-alist '((width . 80) (height . 78) (left . 1180) (font . "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1") (visibility . icon))) and subsequently do C-x 5 2 and deiconify the new frame, does it have the desired properties? Thanks, martin ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <pniziawo843.fsf@bow.cs.hmc.edu>]
* bug#27923: 24.3; -iconic switch screws up geometry [not found] ` <pniziawo843.fsf@bow.cs.hmc.edu> @ 2017-08-19 9:55 ` martin rudalics 2017-11-15 0:12 ` Geoff Kuenning 0 siblings, 1 reply; 24+ messages in thread From: martin rudalics @ 2017-08-19 9:55 UTC (permalink / raw) To: Geoff Kuenning; +Cc: 27923 > My display is 3840x1200. I'm pretty sure that's wider than 1900. ;-) That's bad because it means we are in the area of one of the most elusive bugs I've seen over the past years. Your scenario has been already reported (with .emacs instead of using a resource file) as https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24526 and probably also here https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25943 The underlying problem seems to be that the geometry settings for an invisible or iconified frame get lost somewhere and are not processed (or even reverted) when the frame is made visible. On Windows, the bug manifests itself when specifying the geometry in the init file but not when the geometry is specified as command argument. On GNU/Linux the bug seems to depend on the window manager - I can't reproduce it here on Debian using Xfwm. > In your suggested test, yes, setting default-frame-alist and then > creating a new iconified frame does indeed give me the desired > properties. Which suggests that creating the initial frame with its dimensions is the culprit. What does M-: RET (frame-width) RET of the deformed frame print? > Please let me know if there are any additional tests you'd like me to perform. There are. First I would like to see whether the bug occurs with all possible invocation scenarios in the same way. Please invoke Emacs as emacs -Q --iconic --geometry 80x78+1180+0 --font "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1" as emacs -Q --iconic --load ~/init.el with init.el specified as (setq default-frame-alist '((width . 80) (height . 78) (left . 1180) (font . "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1"))) and as emacs -Q --load ~/init.el with init.el specified as (setq default-frame-alist '((width . 80) (height . 78) (left . 1180) (font . "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1") (visibility . icon))) and tell me whether the results are the same. Also, please tell me what your original scenario gives with the line specifying the font setting removed from the resource file. Thanks, martin PS: Please keep 27923@debbugs.gnu.org CC'd ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2017-08-19 9:55 ` martin rudalics @ 2017-11-15 0:12 ` Geoff Kuenning 2017-11-16 9:04 ` martin rudalics 0 siblings, 1 reply; 24+ messages in thread From: Geoff Kuenning @ 2017-11-15 0:12 UTC (permalink / raw) To: martin rudalics; +Cc: 27923 Hi, Martin, I apologize profusely for my unacceptably long delay in answering your questions; your message slipped by me and I only found it when I was cleaning up old emails. FWIW, when I was doing the tests below there was a brief flash on my screen each time I launched emacs, implying that the window is first mapped and then unmapped. I don't know of that's related to the problem. > emacs -Q --iconic --geometry 80x78+1180+0 --font > "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1" This works correctly, but the geometry reported by xwininfo is 79x77+100+0 (which is related to my Emacs.geometry Xrdb setting rather than my gnuemacs.geometry). > emacs -Q --iconic --load ~/init.el works entirely correctly with the first init.el (including correct X placement). > emacs -Q --load ~/init.el works entirely correctly with the second init.el. > Also, please tell me what > your original scenario gives with the line specifying the font > setting > removed from the resource file. That one still fails. >> My display is 3840x1200. I'm pretty sure that's wider than >> 1900. ;-) > > That's bad because it means we are in the area of one of the > most > elusive bugs I've seen over the past years. Your scenario has > been > already reported (with .emacs instead of using a resource file) > as > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24526 > > and probably also here > > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25943 > > The underlying problem seems to be that the geometry settings > for an > invisible or iconified frame get lost somewhere and are not > processed > (or even reverted) when the frame is made visible. On Windows, > the bug > manifests itself when specifying the geometry in the init file > but not > when the geometry is specified as command argument. On > GNU/Linux the > bug seems to depend on the window manager - I can't reproduce it > here on > Debian using Xfwm. > >> In your suggested test, yes, setting default-frame-alist and >> then >> creating a new iconified frame does indeed give me the desired >> properties. > > Which suggests that creating the initial frame with its > dimensions is > the culprit. What does M-: RET (frame-width) RET of the > deformed frame > print? > >> Please let me know if there are any additional tests you'd like >> me to perform. > > There are. First I would like to see whether the bug occurs > with all > possible invocation scenarios in the same way. Please invoke > Emacs as > > emacs -Q --iconic --geometry 80x78+1180+0 --font > "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1" > > as > > emacs -Q --iconic --load ~/init.el > > with init.el specified as > > (setq default-frame-alist > '((width . 80) > (height . 78) > (left . 1180) > (font > . "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1"))) > > and as > > emacs -Q --load ~/init.el > > with init.el specified as > > (setq default-frame-alist > '((width . 80) > (height . 78) > (left . 1180) > (font > . "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1") > (visibility . icon))) > > and tell me whether the results are the same. Also, please tell > me what > your original scenario gives with the line specifying the font > setting > removed from the resource file. > > Thanks, martin > > PS: Please keep 27923@debbugs.gnu.org CC'd > -- Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ An Internet that is not Open represents a potentially grave risk to freedoms of many sorts -- freedom of speech and other civil liberties, freedom of commerce, and more -- and that openness is what we must so diligently work to both preserve and expand. -- Lauren Weinstein ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2017-11-15 0:12 ` Geoff Kuenning @ 2017-11-16 9:04 ` martin rudalics 2017-11-16 9:13 ` Geoff Kuenning 2017-11-16 23:16 ` Geoff Kuenning 0 siblings, 2 replies; 24+ messages in thread From: martin rudalics @ 2017-11-16 9:04 UTC (permalink / raw) To: Geoff Kuenning; +Cc: 27923 > FWIW, when I was doing the tests below there was a brief flash on my > screen each time I launched emacs, implying that the window is first > mapped and then unmapped. I don't know of that's related to the > problem. Do the flashes occur only when you load init.el or also when using the --iconic --geometry 80x78+1180+0 switches only? >> emacs -Q --iconic --geometry 80x78+1180+0 --font "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1" > > This works correctly, but the geometry reported by xwininfo is 79x77+100+0 (which is related to my Emacs.geometry Xrdb setting rather than my gnuemacs.geometry). Do you mean that both sizes are off by one - 80/79 and 78/77 ? What do M-: (frame-width) RET and M-: (frame-height) in such a frame give? Did you remove/comment out the resource settings? IIRC Emacs combines everything it finds and applies the last settings it read. >> emacs -Q --iconic --load ~/init.el > > works entirely correctly with the first init.el (including correct X placement). > >> emacs -Q --load ~/init.el > > works entirely correctly with the second init.el. So apart from the flashes these would be OK? >> Also, please tell me what >> your original scenario gives with the line specifying the font setting >> removed from the resource file. > > That one still fails. "still" in the sense that you get the same bad width? Does removing the font setting change _anything_ in the appearance of the frame? Thanks, martin ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2017-11-16 9:04 ` martin rudalics @ 2017-11-16 9:13 ` Geoff Kuenning 2017-11-16 9:29 ` martin rudalics 2017-11-16 23:16 ` Geoff Kuenning 1 sibling, 1 reply; 24+ messages in thread From: Geoff Kuenning @ 2017-11-16 9:13 UTC (permalink / raw) To: martin rudalics; +Cc: 27923 Caveat: the testing has all been on my desktop at work, so I can't run new tests at this instant and am working from memory. > Do the flashes occur only when you load init.el or also when > using the > --iconic --geometry 80x78+1180+0 switches only? My memory is that they happen at all times when using --iconic. >>> emacs -Q --iconic --geometry 80x78+1180+0 --font >>> "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1" >> >> This works correctly, but the geometry reported by xwininfo is >> 79x77+100+0 (which is related to my Emacs.geometry Xrdb setting >> rather than my gnuemacs.geometry). > > Do you mean that both sizes are off by one - 80/79 and 78/77 ? > What do Yes, the size should be 80x78 and instead comes up as 79x77. Weird, huh? > M-: (frame-width) RET > > and > > M-: (frame-height) I'll try to remember to try those tomorrow. > in such a frame give? Did you remove/comment out the resource > settings? > IIRC Emacs combines everything it finds and applies the last > settings it > read. When running without -Q, I used grep to remove resource settings from my master parameter file and reloaded that into X11 with xrdb. >>> emacs -Q --iconic --load ~/init.el >> >> works entirely correctly with the first init.el (including >> correct X >> placement). >> >>> emacs -Q --load ~/init.el >> >> works entirely correctly with the second init.el. > > So apart from the flashes these would be OK? Yes. And I never would have noticed the flashes if I hadn't been testing; they're under 1/10 second and happen when I'm logging in every morning. >>> Also, please tell me what >>> your original scenario gives with the line specifying the font >>> setting >>> removed from the resource file. >> >> That one still fails. > > "still" in the sense that you get the same bad width? Does > removing the > font setting change _anything_ in the appearance of the frame? Yes, the same bad width. I'll check carefully tomorrow to see whether there is any frame change. -- Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ Statistics don't bore people, people bore people. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2017-11-16 9:13 ` Geoff Kuenning @ 2017-11-16 9:29 ` martin rudalics 2017-11-16 23:20 ` Geoff Kuenning 0 siblings, 1 reply; 24+ messages in thread From: martin rudalics @ 2017-11-16 9:29 UTC (permalink / raw) To: Geoff Kuenning; +Cc: 27923 >> Do you mean that both sizes are off by one - 80/79 and 78/77 ? What do > > Yes, the size should be 80x78 and instead comes up as 79x77. Weird, huh? There might be some snafu with how to count in toolbar, menubar and scrollbar. >> M-: (frame-width) RET >> >> and >> >> M-: (frame-height) > > I'll try to remember to try those tomorrow. Please do that. It will tell us what Emacs thinks about the "realized" size. martin ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2017-11-16 9:29 ` martin rudalics @ 2017-11-16 23:20 ` Geoff Kuenning 2017-11-17 8:53 ` martin rudalics 0 siblings, 1 reply; 24+ messages in thread From: Geoff Kuenning @ 2017-11-16 23:20 UTC (permalink / raw) To: martin rudalics; +Cc: 27923 One other thing: I just checked the actual width of my frame by typing 80 characters, and it's 80 characters even though xwininfo is reporting 79. So I think this is either an actual xwininfo bug, or a minor interaction between emacs and X that causes the character size of a pixel window to be seen slightly incorrectly. >>> Do you mean that both sizes are off by one - 80/79 and 78/77 ? >>> What do >> >> Yes, the size should be 80x78 and instead comes up as >> 79x77. Weird, huh? > > There might be some snafu with how to count in toolbar, menubar > and > scrollbar. > >>> M-: (frame-width) RET >>> >>> and >>> >>> M-: (frame-height) >> >> I'll try to remember to try those tomorrow. > > Please do that. It will tell us what Emacs thinks about the > "realized" > size. > > martin > -- Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ The P in "PDF" is a lie. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2017-11-16 23:20 ` Geoff Kuenning @ 2017-11-17 8:53 ` martin rudalics 0 siblings, 0 replies; 24+ messages in thread From: martin rudalics @ 2017-11-17 8:53 UTC (permalink / raw) To: Geoff Kuenning; +Cc: 27923 > One other thing: I just checked the actual width of my frame by typing > 80 characters, and it's 80 characters even though xwininfo is > reporting 79. So I think this is either an actual xwininfo bug, or a > minor interaction between emacs and X that causes the character size > of a pixel window to be seen slightly incorrectly. The inherent idea here is that when Emacs comes up with a one-window frame that does not contain a minibuffer window, the sizes specified by 'frame-width' and 'frame-height' match the maximum number of characters on one line and the maximum number of lines that can be displayed in that frame's window. For each and every build of Emacs on every platform and regardless of which other GUI elements are present. So, for example, when you add/remove scrollbars or change the default font of a frame, Emacs usually asks the window manager to change the size of the (window manager) window to keep the number of lines/columns of the frame constant. martin ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2017-11-16 9:04 ` martin rudalics 2017-11-16 9:13 ` Geoff Kuenning @ 2017-11-16 23:16 ` Geoff Kuenning 2017-11-17 8:52 ` martin rudalics 1 sibling, 1 reply; 24+ messages in thread From: Geoff Kuenning @ 2017-11-16 23:16 UTC (permalink / raw) To: martin rudalics; +Cc: 27923 (frame-width) and (frame-height) give 80 and 78, respectively. And I double-checked that xwininfo indeed says 79x77+100+0. (This is when starting with -Q, --iconic, --geometry, --font, and my default resources.) If I grep all emacs-related resources from my xrdb file and reload it, starting with the same command gives the same inconsistency between frame-width/height and xwininfo. Perhaps the width issue is because one character space is allocated to the scrollbar? I also tried removing both emacs-related and font-related resources from the RDB, again getting the width/height inconsistency. But just to make sure we're talking about the same thing, in all of these cases emacs is coming up with a correct window size after I deiconify it. Hmmm, though...I just discovered that "emacs -Q --iconic" produces a different result: it creates an 80x35 frame (79x34 according to xwininfo) even when my xrdb contains both an Emacs.geometry of 80x78+100+0 and a slightly conflicting gnuemacs.geometry of 80x78+1180+0. (I have no clue why I have both!) This implies that there's something in my .emacs that's relevant. I did some binary searching and narrowed it down to a relatively small area. However, in the process I discovered that there must be a race, because on a hunch I tried launching twice with no change in my .emacs, and once was OK and once produced the narrow window. Anyway, I finally got down to the following two lines: (menu-bar-mode -1) (set-default-font (x-get-resource "Font" "")) With both of those present, I get the absurdly narrow frame. If I remove the first, then I get a frame that's 38x78. If I leave the first and remove the second, I get a teeny frame that's too small to type in, but xwininfo reports it as 1x1 (so suppose emacs thinks it's 2x2). And if I remove both, I get a properly sized frame. (This is all with my xrdb restored, BTW.) But that's not the strangest part. I cut my .emacs down to JUST those two lines, and things then worked fine. More testing eventually gave me the following .emacs file (this is 100% of the contents): (if nil (setq load-path (append (mapcar '(lambda (value) (if (and (stringp value) (not (string-match "^/usr/local/" value)) (string-match "^/usr/" value)) (replace-match "/usr/local/" t t value) value)) load-path) load-path))) (menu-bar-mode -1) (set-default-font (x-get-resource "Font" "")) Obviously, the first bit of code doesn't get executed. But if I remove it, launching in iconic mode works! Having it there makes stuff break. Note that the .emacs above is 532 bytes. Is there an ancient 512-byte buffer somewhere? I tried replacing the "if nil" part with 512 semicolons, but that didn't produce an error. Color me confused... >> FWIW, when I was doing the tests below there was a brief flash >> on my >> screen each time I launched emacs, implying that the window is >> first >> mapped and then unmapped. I don't know of that's related to >> the >> problem. > > Do the flashes occur only when you load init.el or also when > using the > --iconic --geometry 80x78+1180+0 switches only? > >>> emacs -Q --iconic --geometry 80x78+1180+0 --font >>> "-misc-fixed-bold-r-normal-*-15-*-100-100-*-*-ISO8859-1" >> >> This works correctly, but the geometry reported by xwininfo is >> 79x77+100+0 (which is related to my Emacs.geometry Xrdb setting >> rather than my gnuemacs.geometry). > > Do you mean that both sizes are off by one - 80/79 and 78/77 ? > What do > > M-: (frame-width) RET > > and > > M-: (frame-height) > > in such a frame give? Did you remove/comment out the resource > settings? > IIRC Emacs combines everything it finds and applies the last > settings it > read. > >>> emacs -Q --iconic --load ~/init.el >> >> works entirely correctly with the first init.el (including >> correct X >> placement). >> >>> emacs -Q --load ~/init.el >> >> works entirely correctly with the second init.el. > > So apart from the flashes these would be OK? > >>> Also, please tell me what >>> your original scenario gives with the line specifying the font >>> setting >>> removed from the resource file. >> >> That one still fails. > > "still" in the sense that you get the same bad width? Does > removing the > font setting change _anything_ in the appearance of the frame? > > Thanks, martin > -- Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ A programmer who can't write readable prose is as incompetent as one who can't produce working code. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2017-11-16 23:16 ` Geoff Kuenning @ 2017-11-17 8:52 ` martin rudalics 2017-11-17 8:59 ` Geoff Kuenning 0 siblings, 1 reply; 24+ messages in thread From: martin rudalics @ 2017-11-17 8:52 UTC (permalink / raw) To: Geoff Kuenning; +Cc: 27923 > (frame-width) and (frame-height) give 80 and 78, respectively. And I > double-checked that xwininfo indeed says 79x77+100+0. (This is when > starting with -Q, --iconic, --geometry, --font, and my default > resources.) With Emacs you traditionally set (via 'set-frame-height' and 'set-frame-width') and retrieve (via 'frame-height' and 'frame-width') the size of a somehwat fictitious area which includes one scroll bar and fringes sometimes a toolbar and a menubar. With GTK builds, tool- and menubar are usually not counted so I don't understand the 78/77 difference in your case but the 80/79 difference should be explainable by the presence of a scrollbar. All values are rounded to the frame's default character size. Usually, comparing xwininfo output with what Emacs tells you is confusing at least. > If I grep all emacs-related resources from my xrdb file and reload it, > starting with the same command gives the same inconsistency between > frame-width/height and xwininfo. Perhaps the width issue is because > one character space is allocated to the scrollbar? I think so too. > But just to make sure we're talking about the same thing, in all of > these cases emacs is coming up with a correct window size after I > deiconify it. I'm not sure I understand the last sentence. Correct in the sense that the main window displays 80x78 characters? > Hmmm, though...I just discovered that "emacs -Q --iconic" produces a > different result: it creates an 80x35 frame (79x34 according to > xwininfo) even when my xrdb contains both an Emacs.geometry of > 80x78+100+0 and a slightly conflicting gnuemacs.geometry of > 80x78+1180+0. (I have no clue why I have both!) This implies that > there's something in my .emacs that's relevant. You mean there's something in your .emacs that gets you a different height: 80/79 without loading .emacs and 35/34 with loading .emacs? > I did some binary searching and narrowed it down to a relatively small > area. However, in the process I discovered that there must be a race, > because on a hunch I tried launching twice with no change in my > .emacs, and once was OK and once produced the narrow window. I'm confused now - is the 35/34 above the width or the height of the frame? > Anyway, I finally got down to the following two lines: > > (menu-bar-mode -1) > (set-default-font (x-get-resource "Font" "")) > With both of those present, I get the absurdly narrow frame. If I > remove the first, then I get a frame that's 38x78. If I leave the > first and remove the second, I get a teeny frame that's too small to > type in, but xwininfo reports it as 1x1 (so suppose emacs thinks it's > 2x2). And if I remove both, I get a properly sized frame. (This is > all with my xrdb restored, BTW.) Sounds weird. BTW what does evaluating (x-get-resource "Font" "") return? > But that's not the strangest part. I cut my .emacs down to JUST those > two lines, and things then worked fine. More testing eventually gave me > the following .emacs file (this is 100% of the contents): > > (if nil > (setq load-path (append > (mapcar > '(lambda (value) > (if (and (stringp value) > (not (string-match "^/usr/local/" value)) > (string-match "^/usr/" value)) > (replace-match "/usr/local/" t t value) > value)) > load-path) > load-path))) > (menu-bar-mode -1) > (set-default-font (x-get-resource "Font" "")) > > Obviously, the first bit of code doesn't get executed. But if I remove > it, launching in iconic mode works! Having it there makes stuff break. > > Note that the .emacs above is 532 bytes. Is there an ancient 512-byte > buffer somewhere? I tried replacing the "if nil" part with 512 > semicolons, but that didn't produce an error. We occasionally use(d) a 512 byte limit to search for the occurrence of something in a file but I see no connection to your case. > Color me confused... Maybe the best thing to do at this moment is that you try with a later version of Emacs, 25.3 at least. My GNU/Linux machine crashed a few years ago and I still did not restore my older Emacs versions including that of Emacs 24. Also, on Windows the --iconic switch did not even work with Emacs 24, so maybe in this area something has changed on GNU/Linux as well. If you upgrade, we could try to synchronize our observations better. Note that on GNU/Linux it's already an enormous pain to compare the behavior of the same version of Emacs under two different window managers. martin ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2017-11-17 8:52 ` martin rudalics @ 2017-11-17 8:59 ` Geoff Kuenning 2017-11-17 9:23 ` martin rudalics 0 siblings, 1 reply; 24+ messages in thread From: Geoff Kuenning @ 2017-11-17 8:59 UTC (permalink / raw) To: martin rudalics; +Cc: 27923 >> But just to make sure we're talking about the same thing, in >> all of >> these cases emacs is coming up with a correct window size after >> I >> deiconify it. > > I'm not sure I understand the last sentence. Correct in the > sense that > the main window displays 80x78 characters? Yes, that's right. Whenever I refer to "works right" I mean that if I launch with -iconic and then de-iconify, I get a window that's the size I expect. >> Hmmm, though...I just discovered that "emacs -Q --iconic" >> produces a >> different result: it creates an 80x35 frame (79x34 according to >> xwininfo) even when my xrdb contains both an Emacs.geometry of >> 80x78+100+0 and a slightly conflicting gnuemacs.geometry of >> 80x78+1180+0. (I have no clue why I have both!) This implies >> that >> there's something in my .emacs that's relevant. > > You mean there's something in your .emacs that gets you a > different > height: 80/79 without loading .emacs and 35/34 with loading > .emacs? I didn't identify the source of the problem, but yes. BTW, that email was a bit of a stream of consciousness: I was typing it as I was doing experiments and being interrupted over the course of a few hours. > >> area. However, in the process I discovered that there must be >> a race, >> because on a hunch I tried launching twice with no change in my >> .emacs, and once was OK and once produced the narrow window. > > I'm confused now - is the 35/34 above the width or the height of > the > frame? Sorry, bad typing on my part. 35/34 was the height. >> Anyway, I finally got down to the following two lines: >> >> (menu-bar-mode -1) >> (set-default-font (x-get-resource "Font" "")) > >> With both of those present, I get the absurdly narrow frame. >> If I >> remove the first, then I get a frame that's 38x78. If I leave >> the >> first and remove the second, I get a teeny frame that's too >> small to >> type in, but xwininfo reports it as 1x1 (so suppose emacs >> thinks it's >> 2x2). And if I remove both, I get a properly sized frame. >> (This is >> all with my xrdb restored, BTW.) > > Sounds weird. BTW what does evaluating (x-get-resource "Font" > "") > return? I'll give that a shot tomorrow. >> But that's not the strangest part. I cut my .emacs down to >> JUST those >> two lines, and things then worked fine. More testing >> eventually gave me >> the following .emacs file (this is 100% of the contents): >> >> (if nil >> (setq load-path (append >> (mapcar >> '(lambda (value) >> (if (and (stringp value) >> (not (string-match >> "^/usr/local/" value)) >> (string-match "^/usr/" >> value)) >> (replace-match "/usr/local/" t t >> value) >> value)) >> load-path) >> load-path))) >> (menu-bar-mode -1) >> (set-default-font (x-get-resource "Font" "")) >> >> Obviously, the first bit of code doesn't get executed. But if >> I remove >> it, launching in iconic mode works! Having it there makes >> stuff break. >> >> Note that the .emacs above is 532 bytes. Is there an ancient >> 512-byte >> buffer somewhere? I tried replacing the "if nil" part with 512 >> semicolons, but that didn't produce an error. > > We occasionally use(d) a 512 byte limit to search for the > occurrence of > something in a file but I see no connection to your case. > >> Color me confused... > > Maybe the best thing to do at this moment is that you try with a > later > version of Emacs, 25.3 at least. My GNU/Linux machine crashed a > few > years ago and I still did not restore my older Emacs versions > including > that of Emacs 24. Also, on Windows the --iconic switch did not > even > work with Emacs 24, so maybe in this area something has changed > on > GNU/Linux as well. If you upgrade, we could try to synchronize > our > observations better. Note that on GNU/Linux it's already an > enormous > pain to compare the behavior of the same version of Emacs under > two > different window managers. It may not happen until the Christmas break, but I'm sure I can manage to get the latest version installed. It would be wonderful if the bug went away on its own! -- Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ Substitute "damn" every time you're inclined to write "very;" your editor will delete it and the writing will be just as it should be. -- Mark Twain ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2017-11-17 8:59 ` Geoff Kuenning @ 2017-11-17 9:23 ` martin rudalics 2017-11-17 9:31 ` Geoff Kuenning 0 siblings, 1 reply; 24+ messages in thread From: martin rudalics @ 2017-11-17 9:23 UTC (permalink / raw) To: Geoff Kuenning; +Cc: 27923 > Sorry, bad typing on my part. 35/34 was the height. > >>> Anyway, I finally got down to the following two lines: >>> >>> (menu-bar-mode -1) >>> (set-default-font (x-get-resource "Font" "")) >> >>> With both of those present, I get the absurdly narrow frame. If I >>> remove the first, then I get a frame that's 38x78. If I leave the >>> first and remove the second, I get a teeny frame that's too small to >>> type in, but xwininfo reports it as 1x1 (so suppose emacs thinks it's >>> 2x2). And if I remove both, I get a properly sized frame. (This is >>> all with my xrdb restored, BTW.) So are you getting a weird height, a weird width, independently both or simultaneously both? > It may not happen until the Christmas break, but I'm sure I can manage > to get the latest version installed. This would be currently 26.0.90 which also has a quite extensive set of functions to measure frame sizes and how they developed when starting Emacs. > It would be wonderful if the bug > went away on its own! Do they ever? martin ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2017-11-17 9:23 ` martin rudalics @ 2017-11-17 9:31 ` Geoff Kuenning 0 siblings, 0 replies; 24+ messages in thread From: Geoff Kuenning @ 2017-11-17 9:31 UTC (permalink / raw) To: martin rudalics; +Cc: 27923 >> Sorry, bad typing on my part. 35/34 was the height. >> >>>> Anyway, I finally got down to the following two lines: >>>> >>>> (menu-bar-mode -1) >>>> (set-default-font (x-get-resource "Font" "")) >>> >>>> With both of those present, I get the absurdly narrow >>>> frame. If I >>>> remove the first, then I get a frame that's 38x78. If I >>>> leave the >>>> first and remove the second, I get a teeny frame that's too >>>> small to >>>> type in, but xwininfo reports it as 1x1 (so suppose emacs >>>> thinks it's >>>> 2x2). And if I remove both, I get a properly sized >>>> frame. (This is >>>> all with my xrdb restored, BTW.) > > So are you getting a weird height, a weird width, independently > both or > simultaneously both? Sometimes normal height, tiny width (that's what prompted the original bug report). Sometimes both weird height and weird width. I don't think I've seen a normal width with a weird height but I might be misremembering. >> It would be wonderful if the bug >> went away on its own! > > Do they ever? Heisenbugs! More seriously, not without help from talented developers... -- Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ It's is not, it isn't ain't, and it's it's, not its, if you mean it is. If you don't, it's its. Then too, it's hers. It isn't her's. It isn't our's either. It's ours, and likewise yours and theirs. -- Oxford University Press, Edpress News ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2017-08-02 20:41 bug#27923: 24.3; -iconic switch screws up geometry Geoff Kuenning 2017-08-17 9:22 ` martin rudalics @ 2022-02-21 15:32 ` Lars Ingebrigtsen 2022-02-21 22:53 ` Geoff Kuenning 1 sibling, 1 reply; 24+ messages in thread From: Lars Ingebrigtsen @ 2022-02-21 15:32 UTC (permalink / raw) To: Geoff Kuenning; +Cc: 27923 Geoff Kuenning <geoff@cs.hmc.edu> writes: > In 24.3.1, starting emacs with the "-iconic" switch causes the main > emacs window to be sized to the width of the icon rather than the width > specified in the X resource database. Interestingly, the height is > still correct. Compare the window created by: > > $ emacs & > > with the one from: > > $ emacs -iconic & (I'm going through old bug reports that unfortunately weren't resolved at the time.) I tried reproducing this on Debian/bullseye with Gnome Shell, and I didn't see any differences in the frame sizes here, but perhaps it's dependent on the window manager. Are you still seeing this problem in recent Emacs versions? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2022-02-21 15:32 ` Lars Ingebrigtsen @ 2022-02-21 22:53 ` Geoff Kuenning 2022-02-22 1:45 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Geoff Kuenning @ 2022-02-21 22:53 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 27923 Well...yes and no. The "absurdly narrow" problem is gone. But if I start emacs with -iconic, the window *height* is now off (it's slightly too tall, by 1-2 lines, so that it goes off the screen since I use a full-height window). Without -iconic it is correctly sized for my screen. FWIW I use the sawfish window manager (because it's programmable via lisp...perhaps there are other emacs users who like lisp? *grin*). > Geoff Kuenning <geoff@cs.hmc.edu> writes: > >> In 24.3.1, starting emacs with the "-iconic" switch causes the >> main >> emacs window to be sized to the width of the icon rather than >> the width >> specified in the X resource database. Interestingly, the >> height is >> still correct. Compare the window created by: >> >> $ emacs & >> >> with the one from: >> >> $ emacs -iconic & > > (I'm going through old bug reports that unfortunately weren't > resolved > at the time.) > > I tried reproducing this on Debian/bullseye with Gnome Shell, > and I > didn't see any differences in the frame sizes here, but perhaps > it's > dependent on the window manager. > > Are you still seeing this problem in recent Emacs versions? > > -- > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no > -- Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ One could not be a successful scientist without realizing that, in contrast to the popular conception supported by newspapers and mothers of scientists, a goodly number of scientists are not only narrow-minded and dull, but also just stupid. -- James Watson ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2022-02-21 22:53 ` Geoff Kuenning @ 2022-02-22 1:45 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-02-22 13:24 ` Lars Ingebrigtsen 2022-02-23 9:28 ` martin rudalics 2 siblings, 0 replies; 24+ messages in thread From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-22 1:45 UTC (permalink / raw) To: Geoff Kuenning; +Cc: 27923, Lars Ingebrigtsen Geoff Kuenning <geoff@cs.hmc.edu> writes: > Well...yes and no. The "absurdly narrow" problem is gone. But if I > start emacs with -iconic, the window *height* is now off (it's > slightly too tall, by 1-2 lines, so that it goes off the screen since > I use a full-height window). Without -iconic it is correctly sized > for my screen. What happens if you put (setq frame-resize-pixelwise t) In your early-init.el file? ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2022-02-21 22:53 ` Geoff Kuenning 2022-02-22 1:45 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-02-22 13:24 ` Lars Ingebrigtsen 2022-02-23 9:28 ` martin rudalics 2 siblings, 0 replies; 24+ messages in thread From: Lars Ingebrigtsen @ 2022-02-22 13:24 UTC (permalink / raw) To: Geoff Kuenning; +Cc: 27923 Geoff Kuenning <geoff@cs.hmc.edu> writes: > Well...yes and no. The "absurdly narrow" problem is gone. But if I > start emacs with -iconic, the window *height* is now off (it's > slightly too tall, by 1-2 lines, so that it goes off the screen since > I use a full-height window). Without -iconic it is correctly sized > for my screen. > > FWIW I use the sawfish window manager (because it's programmable via > lisp...perhaps there are other emacs users who like lisp? *grin*). Must be a window manager interaction thing -- with Gnome Shell the size of the frame is identical whether I start with -iconic or not. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2022-02-21 22:53 ` Geoff Kuenning 2022-02-22 1:45 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-02-22 13:24 ` Lars Ingebrigtsen @ 2022-02-23 9:28 ` martin rudalics 2022-02-23 22:17 ` Geoff Kuenning 2 siblings, 1 reply; 24+ messages in thread From: martin rudalics @ 2022-02-23 9:28 UTC (permalink / raw) To: Geoff Kuenning, Lars Ingebrigtsen; +Cc: 27923 > Well...yes and no. The "absurdly narrow" problem is gone. But if I > start emacs with -iconic, the window *height* is now off (it's > slightly too tall, by 1-2 lines, so that it goes off the screen since > I use a full-height window). Without -iconic it is correctly sized > for my screen. In which Emacs version do you see this? martin ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2022-02-23 9:28 ` martin rudalics @ 2022-02-23 22:17 ` Geoff Kuenning 2022-02-24 9:16 ` Lars Ingebrigtsen 2022-02-24 9:19 ` martin rudalics 0 siblings, 2 replies; 24+ messages in thread From: Geoff Kuenning @ 2022-02-23 22:17 UTC (permalink / raw) To: martin rudalics; +Cc: 27923, Lars Ingebrigtsen I'm running 25.3.1. >> Well...yes and no. The "absurdly narrow" problem is gone. But >> if I >> start emacs with -iconic, the window *height* is now off (it's >> slightly too tall, by 1-2 lines, so that it goes off the screen >> since >> I use a full-height window). Without -iconic it is correctly >> sized >> for my screen. > > In which Emacs version do you see this? > > martin > -- Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ If it's visually ugly, it's almost certainly a bad design. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2022-02-23 22:17 ` Geoff Kuenning @ 2022-02-24 9:16 ` Lars Ingebrigtsen 2022-02-24 17:55 ` Geoff Kuenning 2022-02-24 9:19 ` martin rudalics 1 sibling, 1 reply; 24+ messages in thread From: Lars Ingebrigtsen @ 2022-02-24 9:16 UTC (permalink / raw) To: Geoff Kuenning; +Cc: 27923 Geoff Kuenning <geoff@cs.hmc.edu> writes: > I'm running 25.3.1. Could you test with a recent Emacs version instead? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2022-02-24 9:16 ` Lars Ingebrigtsen @ 2022-02-24 17:55 ` Geoff Kuenning 2022-02-24 18:07 ` Lars Ingebrigtsen 0 siblings, 1 reply; 24+ messages in thread From: Geoff Kuenning @ 2022-02-24 17:55 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 27923 From Lars: > Could you test with a recent Emacs version instead? Unfortunately that would be pretty painful; an emacs installation has enough complex dependencies that replacing my distro's version would be risky. I don't think I have the time right now to do that. From Martin: > We tried to fix that in what will become Emacs 28.1. In that case, and given that it seems to work for you, I think it might be best to just close this old bug report as "cannot reproduce". It's a small problem at worst and probably not worth spending a lot of your time chasing it when it might already be fixed. -- Geoff Kuenning geoff@cs.hmc.edu http://www.cs.hmc.edu/~geoff/ The "M" in XML stands for _markup_. If you don't have anything outside the angle brackets, you probably shouldn't be using XML. ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2022-02-24 17:55 ` Geoff Kuenning @ 2022-02-24 18:07 ` Lars Ingebrigtsen 0 siblings, 0 replies; 24+ messages in thread From: Lars Ingebrigtsen @ 2022-02-24 18:07 UTC (permalink / raw) To: Geoff Kuenning; +Cc: 27923 Geoff Kuenning <geoff@cs.hmc.edu> writes: > In that case, and given that it seems to work for you, I think it > might be best to just close this old bug report as "cannot reproduce". OK; closing this bug report, then. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 24+ messages in thread
* bug#27923: 24.3; -iconic switch screws up geometry 2022-02-23 22:17 ` Geoff Kuenning 2022-02-24 9:16 ` Lars Ingebrigtsen @ 2022-02-24 9:19 ` martin rudalics 1 sibling, 0 replies; 24+ messages in thread From: martin rudalics @ 2022-02-24 9:19 UTC (permalink / raw) To: Geoff Kuenning; +Cc: 27923, Lars Ingebrigtsen > I'm running 25.3.1. > >>> Well...yes and no. The "absurdly narrow" problem is gone. But if I >>> start emacs with -iconic, the window *height* is now off (it's >>> slightly too tall, by 1-2 lines, so that it goes off the screen since >>> I use a full-height window). Without -iconic it is correctly sized >>> for my screen. >> >> In which Emacs version do you see this? We tried to fix that in what will become Emacs 28.1. martin ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2022-02-24 18:07 UTC | newest] Thread overview: 24+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-08-02 20:41 bug#27923: 24.3; -iconic switch screws up geometry Geoff Kuenning 2017-08-17 9:22 ` martin rudalics [not found] ` <pniziawo843.fsf@bow.cs.hmc.edu> 2017-08-19 9:55 ` martin rudalics 2017-11-15 0:12 ` Geoff Kuenning 2017-11-16 9:04 ` martin rudalics 2017-11-16 9:13 ` Geoff Kuenning 2017-11-16 9:29 ` martin rudalics 2017-11-16 23:20 ` Geoff Kuenning 2017-11-17 8:53 ` martin rudalics 2017-11-16 23:16 ` Geoff Kuenning 2017-11-17 8:52 ` martin rudalics 2017-11-17 8:59 ` Geoff Kuenning 2017-11-17 9:23 ` martin rudalics 2017-11-17 9:31 ` Geoff Kuenning 2022-02-21 15:32 ` Lars Ingebrigtsen 2022-02-21 22:53 ` Geoff Kuenning 2022-02-22 1:45 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors 2022-02-22 13:24 ` Lars Ingebrigtsen 2022-02-23 9:28 ` martin rudalics 2022-02-23 22:17 ` Geoff Kuenning 2022-02-24 9:16 ` Lars Ingebrigtsen 2022-02-24 17:55 ` Geoff Kuenning 2022-02-24 18:07 ` Lars Ingebrigtsen 2022-02-24 9:19 ` martin rudalics
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.