* bug#37630: 27.0.50; image-mode-fit-frame doesn't
@ 2019-10-05 9:10 Eli Zaretskii
2019-10-07 3:59 ` Lars Ingebrigtsen
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2019-10-05 9:10 UTC (permalink / raw)
To: 37630
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))
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-05 9:10 bug#37630: 27.0.50; image-mode-fit-frame doesn't Eli Zaretskii
@ 2019-10-07 3:59 ` Lars Ingebrigtsen
2019-10-07 5:10 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-07 3:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 37630
[-- Attachment #1: Type: text/plain, Size: 321 bytes --]
Eli Zaretskii <eliz@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:
[-- Attachment #2: fit.jpg --]
[-- Type: image/jpeg, Size: 28723 bytes --]
[-- Attachment #3: Type: text/plain, Size: 320 bytes --]
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-07 3:59 ` Lars Ingebrigtsen
@ 2019-10-07 5:10 ` Eli Zaretskii
2019-10-07 5:15 ` Lars Ingebrigtsen
2019-10-07 5:31 ` Lars Ingebrigtsen
0 siblings, 2 replies; 27+ messages in thread
From: Eli Zaretskii @ 2019-10-07 5:10 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37630
On October 7, 2019 6:59:43 AM GMT+03:00, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-07 5:10 ` Eli Zaretskii
@ 2019-10-07 5:15 ` Lars Ingebrigtsen
2019-10-07 5:31 ` Lars Ingebrigtsen
1 sibling, 0 replies; 27+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-07 5:15 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 37630
[-- Attachment #1: Type: text/plain, Size: 218 bytes --]
Eli Zaretskii <eliz@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:
[-- Attachment #2: fit-no.jpg --]
[-- Type: image/jpeg, Size: 24323 bytes --]
[-- Attachment #3: Type: text/plain, Size: 104 bytes --]
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-07 5:10 ` Eli Zaretskii
2019-10-07 5:15 ` Lars Ingebrigtsen
@ 2019-10-07 5:31 ` Lars Ingebrigtsen
2019-10-07 16:25 ` Eli Zaretskii
1 sibling, 1 reply; 27+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-07 5:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 37630
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-07 5:31 ` Lars Ingebrigtsen
@ 2019-10-07 16:25 ` Eli Zaretskii
2019-10-08 8:43 ` martin rudalics
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2019-10-07 16:25 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37630
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 37630@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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-07 16:25 ` Eli Zaretskii
@ 2019-10-08 8:43 ` martin rudalics
2019-10-08 9:13 ` Eli Zaretskii
2019-10-08 15:47 ` Lars Ingebrigtsen
0 siblings, 2 replies; 27+ messages in thread
From: martin rudalics @ 2019-10-08 8:43 UTC (permalink / raw)
To: Eli Zaretskii, Lars Ingebrigtsen; +Cc: 37630
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-08 8:43 ` martin rudalics
@ 2019-10-08 9:13 ` Eli Zaretskii
2019-10-08 9:25 ` martin rudalics
2019-10-08 15:47 ` Lars Ingebrigtsen
1 sibling, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2019-10-08 9:13 UTC (permalink / raw)
To: martin rudalics; +Cc: larsi, 37630
> Cc: 37630@debbugs.gnu.org
> From: martin rudalics <rudalics@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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-08 9:13 ` Eli Zaretskii
@ 2019-10-08 9:25 ` martin rudalics
2019-10-08 11:53 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: martin rudalics @ 2019-10-08 9:25 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 37630
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-08 9:25 ` martin rudalics
@ 2019-10-08 11:53 ` Eli Zaretskii
2019-10-09 18:12 ` martin rudalics
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2019-10-08 11:53 UTC (permalink / raw)
To: martin rudalics; +Cc: larsi, 37630
> Cc: larsi@gnus.org, 37630@debbugs.gnu.org
> From: martin rudalics <rudalics@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'".
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-08 8:43 ` martin rudalics
2019-10-08 9:13 ` Eli Zaretskii
@ 2019-10-08 15:47 ` Lars Ingebrigtsen
2019-10-08 16:02 ` Eli Zaretskii
1 sibling, 1 reply; 27+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-08 15:47 UTC (permalink / raw)
To: martin rudalics; +Cc: 37630
martin rudalics <rudalics@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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-08 15:47 ` Lars Ingebrigtsen
@ 2019-10-08 16:02 ` Eli Zaretskii
2019-10-08 16:12 ` Lars Ingebrigtsen
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2019-10-08 16:02 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37630
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, 37630@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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-08 16:02 ` Eli Zaretskii
@ 2019-10-08 16:12 ` Lars Ingebrigtsen
2019-10-08 16:45 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-08 16:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 37630
Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-08 16:12 ` Lars Ingebrigtsen
@ 2019-10-08 16:45 ` Eli Zaretskii
2019-10-09 19:09 ` Lars Ingebrigtsen
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2019-10-08 16:45 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37630
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rudalics@gmx.at, 37630@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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-08 11:53 ` Eli Zaretskii
@ 2019-10-09 18:12 ` martin rudalics
0 siblings, 0 replies; 27+ messages in thread
From: martin rudalics @ 2019-10-09 18:12 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: larsi, 37630
>> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-08 16:45 ` Eli Zaretskii
@ 2019-10-09 19:09 ` Lars Ingebrigtsen
2022-03-23 13:18 ` Lars Ingebrigtsen
0 siblings, 1 reply; 27+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-09 19:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 37630
Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2019-10-09 19:09 ` Lars Ingebrigtsen
@ 2022-03-23 13:18 ` Lars Ingebrigtsen
2022-03-23 14:29 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Lars Ingebrigtsen @ 2022-03-23 13:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 37630
Lars Ingebrigtsen <larsi@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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2022-03-23 13:18 ` Lars Ingebrigtsen
@ 2022-03-23 14:29 ` Eli Zaretskii
2022-03-23 14:34 ` Lars Ingebrigtsen
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2022-03-23 14:29 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37630
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rudalics@gmx.at, 37630@debbugs.gnu.org
> Date: Wed, 23 Mar 2022 14:18:59 +0100
>
> Lars Ingebrigtsen <larsi@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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2022-03-23 14:29 ` Eli Zaretskii
@ 2022-03-23 14:34 ` Lars Ingebrigtsen
2022-03-23 14:35 ` Lars Ingebrigtsen
0 siblings, 1 reply; 27+ messages in thread
From: Lars Ingebrigtsen @ 2022-03-23 14:34 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 37630
Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2022-03-23 14:34 ` Lars Ingebrigtsen
@ 2022-03-23 14:35 ` Lars Ingebrigtsen
2022-03-23 14:50 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Lars Ingebrigtsen @ 2022-03-23 14:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 37630
Lars Ingebrigtsen <larsi@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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2022-03-23 14:35 ` Lars Ingebrigtsen
@ 2022-03-23 14:50 ` Eli Zaretskii
2022-03-23 14:55 ` Lars Ingebrigtsen
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2022-03-23 14:50 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37630
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rudalics@gmx.at, 37630@debbugs.gnu.org
> Date: Wed, 23 Mar 2022 15:35:40 +0100
>
> Lars Ingebrigtsen <larsi@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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2022-03-23 14:50 ` Eli Zaretskii
@ 2022-03-23 14:55 ` Lars Ingebrigtsen
2022-03-23 15:04 ` Eli Zaretskii
0 siblings, 1 reply; 27+ messages in thread
From: Lars Ingebrigtsen @ 2022-03-23 14:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 37630
Eli Zaretskii <eliz@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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2022-03-23 14:55 ` Lars Ingebrigtsen
@ 2022-03-23 15:04 ` Eli Zaretskii
2022-03-23 17:07 ` martin rudalics
0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2022-03-23 15:04 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37630
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: rudalics@gmx.at, 37630@debbugs.gnu.org
> Date: Wed, 23 Mar 2022 15:55:01 +0100
>
> Eli Zaretskii <eliz@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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2022-03-23 15:04 ` Eli Zaretskii
@ 2022-03-23 17:07 ` martin rudalics
2022-03-23 17:30 ` Lars Ingebrigtsen
0 siblings, 1 reply; 27+ messages in thread
From: martin rudalics @ 2022-03-23 17:07 UTC (permalink / raw)
To: Eli Zaretskii, Lars Ingebrigtsen; +Cc: 37630
>>>> (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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2022-03-23 17:07 ` martin rudalics
@ 2022-03-23 17:30 ` Lars Ingebrigtsen
2022-03-24 8:16 ` martin rudalics
0 siblings, 1 reply; 27+ messages in thread
From: Lars Ingebrigtsen @ 2022-03-23 17:30 UTC (permalink / raw)
To: martin rudalics; +Cc: 37630
martin rudalics <rudalics@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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2022-03-23 17:30 ` Lars Ingebrigtsen
@ 2022-03-24 8:16 ` martin rudalics
2022-03-24 9:00 ` Lars Ingebrigtsen
0 siblings, 1 reply; 27+ messages in thread
From: martin rudalics @ 2022-03-24 8:16 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37630
> 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
^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#37630: 27.0.50; image-mode-fit-frame doesn't
2022-03-24 8:16 ` martin rudalics
@ 2022-03-24 9:00 ` Lars Ingebrigtsen
0 siblings, 0 replies; 27+ messages in thread
From: Lars Ingebrigtsen @ 2022-03-24 9:00 UTC (permalink / raw)
To: martin rudalics; +Cc: 37630
martin rudalics <rudalics@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
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2022-03-24 9:00 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-10-05 9:10 bug#37630: 27.0.50; image-mode-fit-frame doesn't Eli Zaretskii
2019-10-07 3:59 ` Lars Ingebrigtsen
2019-10-07 5:10 ` Eli Zaretskii
2019-10-07 5:15 ` Lars Ingebrigtsen
2019-10-07 5:31 ` Lars Ingebrigtsen
2019-10-07 16:25 ` Eli Zaretskii
2019-10-08 8:43 ` martin rudalics
2019-10-08 9:13 ` Eli Zaretskii
2019-10-08 9:25 ` martin rudalics
2019-10-08 11:53 ` Eli Zaretskii
2019-10-09 18:12 ` martin rudalics
2019-10-08 15:47 ` Lars Ingebrigtsen
2019-10-08 16:02 ` Eli Zaretskii
2019-10-08 16:12 ` Lars Ingebrigtsen
2019-10-08 16:45 ` Eli Zaretskii
2019-10-09 19:09 ` Lars Ingebrigtsen
2022-03-23 13:18 ` Lars Ingebrigtsen
2022-03-23 14:29 ` Eli Zaretskii
2022-03-23 14:34 ` Lars Ingebrigtsen
2022-03-23 14:35 ` Lars Ingebrigtsen
2022-03-23 14:50 ` Eli Zaretskii
2022-03-23 14:55 ` Lars Ingebrigtsen
2022-03-23 15:04 ` Eli Zaretskii
2022-03-23 17:07 ` martin rudalics
2022-03-23 17:30 ` Lars Ingebrigtsen
2022-03-24 8:16 ` martin rudalics
2022-03-24 9:00 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).