GNU bug report logs - #37630
27.0.50; image-mode-fit-frame doesn't

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37630 in the body.
You can then email your comments to 37630 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; image-mode-fit-frame doesn't
Date: Sat, 05 Oct 2019 12:10:20 +0300

To reproduce:

  emacs -Q
  C-x C-f etc/images/splash.svg
  M-x image-mode-fit-frame RET

The last command is documented to "fit FRAME to the current image",
but it doesn't: the result shows the image only partially.

  M-x image-mode-fit-frame RET

This should return the frame to its original dimensions, but again
doesn't.

It seems like the command does its documented job only if the frame
has no tool bar and no menu bar.  IOW, if you invoke Emacs as in
"emacs -Q -D", the above recipe produces the expected results.  This
could be a documentation bug: perhaps this command was not supposed to
work in frames with tool bar and menu bar.


In GNU Emacs 27.0.50 (build 1459, i686-pc-mingw32)
 of 2019-10-05 built on HOME-C4E4A596F7
Repository revision: bbfa9995ff3bdb8a00fe3082bc3249cc1e68e1ab
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Scanning for dabbrevs...done
user-error: No dynamic expansion for ‘image-mode-fit’ found

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int --with-modules
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr dabbrev emacsbug message rmc puny dired
dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache
epa derived epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date subr-x seq byte-opt gv bytecomp
byte-compile cconv mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047
rfc2045 ietf-drums mm-util mail-prsvr mail-utils tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp
disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd
fontset image regexp-opt fringe tabulated-list replace newcomment
text-mode elisp-mode lisp-mode prog-mode register page tab-bar menu-bar
rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core term/tty-colors 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 composite charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray 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 threads w32notify w32
lcms2 multi-tty make-network-process emacs)

Memory information:
((conses 16 51337 9062)
 (symbols 48 7208 1)
 (strings 16 18894 2211)
 (string-bytes 1 535283)
 (vectors 16 9936)
 (vector-slots 8 130131 10194)
 (floats 8 23 23)
 (intervals 40 258 10)
 (buffers 888 11))

Message #8 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Mon, 07 Oct 2019 05:59:43 +0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> To reproduce:
>
>   emacs -Q
>   C-x C-f etc/images/splash.svg
>   M-x image-mode-fit-frame RET
>
> The last command is documented to "fit FRAME to the current image",
> but it doesn't: the result shows the image only partially.

I tried this on GNU/Linux, and it looks OK to me:

[fit.jpg (image/jpeg, inline)]

[Message part 3 (text/plain, inline)]

>   M-x image-mode-fit-frame RET
>
> This should return the frame to its original dimensions, but again
> doesn't.

I got the original dimensions here.

Could this be something that works differently under Windows?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #11 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Mon, 07 Oct 2019 08:10:29 +0300

On October 7, 2019 6:59:43 AM GMT+03:00, Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > To reproduce:
> >
> >   emacs -Q
> >   C-x C-f etc/images/splash.svg
> >   M-x image-mode-fit-frame RET
> >
> > The last command is documented to "fit FRAME to the current image",
> > but it doesn't: the result shows the image only partially.
> 
> I tried this on GNU/Linux, and it looks OK to me:

Could be, but please try a build with Emacs-generated ("native") tool bar, before we decide that it's Windows specific.

Message #14 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Mon, 07 Oct 2019 07:15:50 +0200

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> Could be, but please try a build with Emacs-generated ("native") tool
> bar, before we decide that it's Windows specific.

Ah, with --with-x-toolkit=no I can reproduce the bug:

[fit-no.jpg (image/jpeg, inline)]

[Message part 3 (text/plain, inline)]

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #17 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Mon, 07 Oct 2019 07:31:31 +0200

I've looked at what's different in a non-toolkit version and the toolkit
version that's relevant here.

If I say

(window-inside-edges)
=> (0 0 81 41)

and look at how many lines are displayed in this window (which is as
tall as the fram), it's 41 lines, i.e., (- 41 0).

In the non-toolkit version, I get

=> (1 2 92 42)

so the window should be (- 42 2) => 40 lines tall, but it's actually 39
lines tall.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #20 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Mon, 07 Oct 2019 19:25:40 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 37630 <at> debbugs.gnu.org
> Date: Mon, 07 Oct 2019 07:31:31 +0200
> 
> I've looked at what's different in a non-toolkit version and the toolkit
> version that's relevant here.
> 
> If I say
> 
> (window-inside-edges)
> => (0 0 81 41)
> 
> and look at how many lines are displayed in this window (which is as
> tall as the fram), it's 41 lines, i.e., (- 41 0).
> 
> In the non-toolkit version, I get
> 
> => (1 2 92 42)
> 
> so the window should be (- 42 2) => 40 lines tall, but it's actually 39
> lines tall.

I hope Martin will help us out here.

Message #23 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Tue, 8 Oct 2019 10:43:51 +0200

> I hope Martin will help us out here.

If he only could (I don't use Emacs for images).  On my MSYS 64 bit
build, I can't display splash.svg getting the somewhat vague error

Using vacuous schema
Type C-c C-c or C-c C-x to view the image as an image or hex.
Cannot display image: (Invalid image specification)

When I instead try to display some jpg image here via C-x C-f I first
get a separate frame which is slightly larger than that image: When I
now do M-x image-mode-fit-frame in that frame, the frame resizes as
expected without any cropping.

Looking at the code of 'image-mode-fit-frame' I can't find anything
wrong with

	  (set-frame-height frame (+ (ceiling (cdr size))
				     height (- inner-height)))

and would be surprised if this failed unless some frame properties
changed in between the 'frame-height' and the 'window-inside-edges'
calls.  Maybe it's also the strange saving modus that interferes in
your setups.  The

			       (list (cons (frame-width)
					   (frame-height))

doesn't look like TRT when FRAME is not the selected frame but so far
I have no idea how this code is supposed to behave at all.  In either
case, make sure the 'image-mode-saved-params' parameter is nil before
calling 'image-mode-fit-frame'.

martin

Message #26 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: larsi <at> gnus.org, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Tue, 08 Oct 2019 12:13:53 +0300

> Cc: 37630 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Tue, 8 Oct 2019 10:43:51 +0200
> 
>  > I hope Martin will help us out here.
> 
> If he only could (I don't use Emacs for images).  On my MSYS 64 bit
> build, I can't display splash.svg getting the somewhat vague error
> 
> Using vacuous schema
> Type C-c C-c or C-c C-x to view the image as an image or hex.
> Cannot display image: (Invalid image specification)

Are you unable to display SVG images in general?

Anyway, I get the same incorrect behavior if I use splash.png.  I
don't think it matters which image format of the splash image you use,
you will get the same behavior.  So just use whatever image types your
build supports.

> When I instead try to display some jpg image here via C-x C-f I first
> get a separate frame which is slightly larger than that image: When I
> now do M-x image-mode-fit-frame in that frame, the frame resizes as
> expected without any cropping.

Which JPG image did you use?

> Looking at the code of 'image-mode-fit-frame' I can't find anything
> wrong with
> 
> 	  (set-frame-height frame (+ (ceiling (cdr size))
> 				     height (- inner-height)))
> 
> and would be surprised if this failed unless some frame properties
> changed in between the 'frame-height' and the 'window-inside-edges'
> calls.  Maybe it's also the strange saving modus that interferes in
> your setups.  The
> 
> 			       (list (cons (frame-width)
> 					   (frame-height))
> 
> doesn't look like TRT when FRAME is not the selected frame but so far
> I have no idea how this code is supposed to behave at all.  In either
> case, make sure the 'image-mode-saved-params' parameter is nil before
> calling 'image-mode-fit-frame'.

My recipe is in "emacs -Q", so I guess this condition holds?

Message #29 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Tue, 8 Oct 2019 11:25:05 +0200

> Which JPG image did you use?

One of me, in the mountains.  You mean we should settle on the same
image if we find one we both can display.

>> Looking at the code of 'image-mode-fit-frame' I can't find anything
>> wrong with
>>
>> 	  (set-frame-height frame (+ (ceiling (cdr size))
>> 				     height (- inner-height)))
>>
>> and would be surprised if this failed unless some frame properties
>> changed in between the 'frame-height' and the 'window-inside-edges'
>> calls.  Maybe it's also the strange saving modus that interferes in
>> your setups.  The
>>
>> 			       (list (cons (frame-width)
>> 					   (frame-height))
>>
>> doesn't look like TRT when FRAME is not the selected frame but so far
>> I have no idea how this code is supposed to behave at all.  In either
>> case, make sure the 'image-mode-saved-params' parameter is nil before
>> calling 'image-mode-fit-frame'.
>
> My recipe is in "emacs -Q",

I'm using emacs -Q too but which ...

> so I guess this condition holds?

... condition do you mean here?

martin

Message #32 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: larsi <at> gnus.org, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Tue, 08 Oct 2019 14:53:36 +0300

> Cc: larsi <at> gnus.org, 37630 <at> debbugs.gnu.org
> From: martin rudalics <rudalics <at> gmx.at>
> Date: Tue, 8 Oct 2019 11:25:05 +0200
> 
>  > Which JPG image did you use?
> 
> One of me, in the mountains.  You mean we should settle on the same
> image if we find one we both can display.

That would help, yes.

>  >> doesn't look like TRT when FRAME is not the selected frame but so far
>  >> I have no idea how this code is supposed to behave at all.  In either
>  >> case, make sure the 'image-mode-saved-params' parameter is nil before
>  >> calling 'image-mode-fit-frame'.
>  >
>  > My recipe is in "emacs -Q",
> 
> I'm using emacs -Q too but which ...
> 
>  > so I guess this condition holds?
> 
> ... condition do you mean here?

The condition "make sure the 'image-mode-saved-params' parameter is
nil before calling 'image-mode-fit-frame'".

Message #35 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Tue, 08 Oct 2019 17:47:44 +0200

martin rudalics <rudalics <at> gmx.at> writes:

> Looking at the code of 'image-mode-fit-frame' I can't find anything
> wrong with
>
> 	  (set-frame-height frame (+ (ceiling (cdr size))
> 				     height (- inner-height)))
>
> and would be surprised if this failed unless some frame properties
> changed in between the 'frame-height' and the 'window-inside-edges'
> calls.

In my experiments, this wasn't what failed.  (window-inside-edges)
claimed that there was one more line in the frame than there actually is
(but only in --with-x-toolkit=no builds; it computes the correct height
in Gtk builds).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #38 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rudalics <at> gmx.at, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Tue, 08 Oct 2019 19:02:39 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  37630 <at> debbugs.gnu.org
> Date: Tue, 08 Oct 2019 17:47:44 +0200
> 
> In my experiments, this wasn't what failed.  (window-inside-edges)
> claimed that there was one more line in the frame than there actually is
> (but only in --with-x-toolkit=no builds; it computes the correct height
> in Gtk builds).

Why are we calculating the size in lines instead of pixels?  Could
that be the source of the problem?

Message #41 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Tue, 08 Oct 2019 18:12:40 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> Why are we calculating the size in lines instead of pixels?  Could
> that be the source of the problem?

Yeah, I wondered that, too.  Perhaps it's a historical artefact (I think
the pixel-wise options were added later?), but I think that perhaps we
do want to resize the frame on a line basis: We don't want to have half
a line at the bottom of the frame.

Perhaps?

I don't really understand the utility of this command, though.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #44 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rudalics <at> gmx.at, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Tue, 08 Oct 2019 19:45:26 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: rudalics <at> gmx.at,  37630 <at> debbugs.gnu.org
> Date: Tue, 08 Oct 2019 18:12:40 +0200
> 
> We don't want to have half a line at the bottom of the frame.

But that's only possible when resizing pixel-wise, no?

> I don't really understand the utility of this command, though.

I think it was written to allow popping up frames with minimal/no
decorations that show only the image.  But that's a guess.

Message #47 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Wed, 9 Oct 2019 20:12:01 +0200

>> You mean we should settle on the same
>> image if we find one we both can display.
>
> That would help, yes.

I updated MSYS2 and can display splash.svg now.  But that's a truly
hard case because the image is so small.  Fitting the frame to it not
only wraps the tool bar here to three lines but also gets me a two
lines menu bar.  The latter, in particular, is something we can hardly
handle on Windows ...

martin

Message #50 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Wed, 09 Oct 2019 21:09:30 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> We don't want to have half a line at the bottom of the frame.
>
> But that's only possible when resizing pixel-wise, no?

Yes, we could compute based on pixels, and then resize based on how many
lines that would be.  But I wonder whether the mapping from pixels to
lines would run into the same problems as just counting lines does.

>> I don't really understand the utility of this command, though.
>
> I think it was written to allow popping up frames with minimal/no
> decorations that show only the image.  But that's a guess.

Perhaps it was meant as a way to quickly expand the frame to display all
of the image?  In the olden days, you couldn't shrink images, so perhaps
making the frame bigger momentarily was seen as a feature.

But just guessing.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #53 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Wed, 23 Mar 2022 14:18:59 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Yes, we could compute based on pixels, and then resize based on how many
> lines that would be.  But I wonder whether the mapping from pixels to
> lines would run into the same problems as just counting lines does.

I've now rewritten the command to use pixels, and that seems to fix the
issue on a couple of configurations here, at least.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #58 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rudalics <at> gmx.at, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Wed, 23 Mar 2022 16:29:25 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: rudalics <at> gmx.at,  37630 <at> debbugs.gnu.org
> Date: Wed, 23 Mar 2022 14:18:59 +0100
> 
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> > Yes, we could compute based on pixels, and then resize based on how many
> > lines that would be.  But I wonder whether the mapping from pixels to
> > lines would run into the same problems as just counting lines does.
> 
> I've now rewritten the command to use pixels, and that seems to fix the
> issue on a couple of configurations here, at least.

Thanks, it's much better now.  Although the second
image-mode-fit-frame doesn't restore the original dimensions: I get a
frame that is 2 lines too high wrt the original one.

Message #61 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Wed, 23 Mar 2022 15:34:51 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Thanks, it's much better now.  Although the second
> image-mode-fit-frame doesn't restore the original dimensions: I get a
> frame that is 2 lines too high wrt the original one.

Hm.  Does `set-frame-height' exclude the ... toolbar? menu bar?  on some
systems, by any chance?

That is, does the following change the height?

(set-frame-height nil (frame-pixel-height))

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #64 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Wed, 23 Mar 2022 15:35:40 +0100

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> That is, does the following change the height?
>
> (set-frame-height nil (frame-pixel-height))

I meant

(set-frame-height nil (frame-pixel-height) nil t)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #67 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rudalics <at> gmx.at, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Wed, 23 Mar 2022 16:50:29 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: rudalics <at> gmx.at,  37630 <at> debbugs.gnu.org
> Date: Wed, 23 Mar 2022 15:35:40 +0100
> 
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> > That is, does the following change the height?
> >
> > (set-frame-height nil (frame-pixel-height))
> 
> I meant
> 
> (set-frame-height nil (frame-pixel-height) nil t)

Yes, it does here: the resulting frame is 2 lines taller.

Message #70 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rudalics <at> gmx.at, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Wed, 23 Mar 2022 15:55:01 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> (set-frame-height nil (frame-pixel-height) nil t)
>
> Yes, it does here: the resulting frame is 2 lines taller.

So it does here (with a non-toolkit build); I didn't notice.  (It does
nothing in a Gtk build.)

I guess that's a bug in `set-frame-height'?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #73 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: rudalics <at> gmx.at, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Wed, 23 Mar 2022 17:04:26 +0200

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: rudalics <at> gmx.at,  37630 <at> debbugs.gnu.org
> Date: Wed, 23 Mar 2022 15:55:01 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> (set-frame-height nil (frame-pixel-height) nil t)
> >
> > Yes, it does here: the resulting frame is 2 lines taller.
> 
> So it does here (with a non-toolkit build); I didn't notice.  (It does
> nothing in a Gtk build.)
> 
> I guess that's a bug in `set-frame-height'?

It could also be a feature.  Martin?

Message #76 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Wed, 23 Mar 2022 18:07:48 +0100

>>>> (set-frame-height nil (frame-pixel-height) nil t)
>>>
>>> Yes, it does here: the resulting frame is 2 lines taller.
>>
>> So it does here (with a non-toolkit build); I didn't notice.  (It does
>> nothing in a Gtk build.)
>>
>> I guess that's a bug in `set-frame-height'?
>
> It could also be a feature.  Martin?

A silly one.  For historical reason, 'set-frame-height' expects a "text
height" as argument.  'frame-pixel-height' OTOH returns the "native
height" of the frame.  How these relate is explained in sections 30.3.1
and 30.3.4 of the Elisp Manual.  The idempotent operation you have in
mind is probably

(set-frame-height nil (frame-text-height) nil t)

although with a GTK build you usually won't notice the difference.

martin

Message #79 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Wed, 23 Mar 2022 18:30:55 +0100

martin rudalics <rudalics <at> gmx.at> writes:

> A silly one.  For historical reason, 'set-frame-height' expects a "text
> height" as argument.  'frame-pixel-height' OTOH returns the "native
> height" of the frame.  How these relate is explained in sections 30.3.1
> and 30.3.4 of the Elisp Manual.  The idempotent operation you have in
> mind is probably
>
> (set-frame-height nil (frame-text-height) nil t)
>
> although with a GTK build you usually won't notice the difference.

Ah, right.

I've poked at the image-mode-fit-frame code some more to see whether we
could use frame-text-height directly without any further changes, but
that makes the frame too short.  So there's something not adding up in
the computations it does, but it's not clear what, exactly.

Perhaps somebody else should take a peek at it...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Message #82 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Thu, 24 Mar 2022 09:16:49 +0100

> I've poked at the image-mode-fit-frame code some more to see whether we
> could use frame-text-height directly without any further changes, but
> that makes the frame too short.  So there's something not adding up in
> the computations it does, but it's not clear what, exactly.
>
> Perhaps somebody else should take a peek at it...

Why do you want to reinvent the wheel?  Is there anything wrong with
'fit-frame-to-buffer'?

martin

Message #85 received at 37630 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 37630 <at> debbugs.gnu.org
Subject: Re: bug#37630: 27.0.50; image-mode-fit-frame doesn't
Date: Thu, 24 Mar 2022 10:00:34 +0100

martin rudalics <rudalics <at> gmx.at> writes:

> Why do you want to reinvent the wheel?  Is there anything wrong with
> 'fit-frame-to-buffer'?

Thanks; I've now adjusted the code, which seems to fix the resizing in
both directions.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.