bug#19972: 24.4; Font size change doesn't update (window-total-width)

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Joost Kremers]

After changing the font size (with `custom-push-theme' and
`face-spec-recalc'), the value returned by `window-total-width' is not
updated.

To reproduce, run `emacs -Q' and do:

- (window-total-width) ; shows the initial value
- (custom-push-theme 'theme-face 'default 'user 'set '((t (:height 128))))
  ; use a :height value that's actually different from the default height.
- (face-spec-recalc 'default (selected-frame))
- (window-total-width) ; still shows the initial value
- C-x 3 ; split window horizontally
- C-x 1 ; delete other window
- (window-total-width) ; shows the new value

The second call to `window-total-width' should already have returned the
new value.

The following IELM transcript (recorded directly after `emacs -Q') shows
the problem:

ELISP> (window-total-width)
240 (#o360, #xf0, ?ð)
ELISP> (custom-push-theme 'theme-face 'default 'user 'set '((t (:height 128))))
((theme-face default user
	     ((t
	       (:height 128)))))

ELISP> (face-spec-recalc 'default (selected-frame))
nil
ELISP> (window-total-width)
240 (#o360, #xf0, ?ð)

;; now press `C-x 3` followed by `C-x 1'

ELISP> (window-total-width)
192 (#o300, #xc0, ?À)
ELISP> 

The second call to `window-total-width` returns 240, but it should have
returned 192. After splitting the window and deleting the other window
again, the correct value is returned.

Note that splitting the window vertically (`C-x 2`) does *not* fix the
value returned by `window-total-width'.



In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2)
 of 2014-10-22 on IdeaPad
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	elementary OS Luna

Important settings:
  value of $LC_MONETARY: en_IE.UTF-8
  value of $LC_NUMERIC: en_IE.UTF-8
  value of $LC_TIME: en_IE.UTF-8
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: IELM

Minor modes in effect:
  tooltip-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

Recent input:
M-x i e l m <return> ( w i n d o w - w <backspace> 
t o t a l - w i d t h ) <return> C-y M-b M-b M-d M-d 
<backspace> 1 2 8 M-b M-b M-b M-b M-f C-f C-d ' C-e 
<return> ( f a c e - s p e c - r e <tab> c <tab> SPC 
' d e f a u l t SPC ' <backspace> ( s e l e t <backspace> 
c t e d - f r a m e ) ) <return> <up> <down> <C-up> 
<C-up> <C-up> <return> C-x 3 C-x 1 <C-up> <return> 
<help-echo> C-SPC C-t C-f C-SPC <up> <up> <up> <up> 
<up> <up> <up> <up> <up> <up> <up> <up> <up> C-a <up> 
<down> C-a a C-/ <left> <left> <left> <left> <left> 
<left> <left> <S-down> <S-down> <S-down> <S-down> <S-down> 
<S-down> <S-down> <S-down> <S-down> <S-down> <S-down> 
<S-down> <S-down> <S-down> M-w M-x r e p o r t - e 
m a c - <backspace> s - b u g <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Mark set
Making completion list...
Mark set
transpose-subr-1: Text is read-only
Mark activated
Undo!
Mark set
End of buffer

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils help-mode mule-util ielm easymenu pp
comint ansi-color ring time-date tooltip electric uniquify 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 prog-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 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 make-network-process dbusbind
gfilenotify dynamic-setting system-font-setting font-render-setting
move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 76433 3869)
 (symbols 48 18021 0)
 (miscs 40 52 174)
 (strings 32 10420 4770)
 (string-bytes 1 294096)
 (vectors 16 9633)
 (vector-slots 8 392165 12847)
 (floats 8 66 361)
 (intervals 56 294 16)
 (buffers 960 13)
 (heap 1024 45822 783))

-- 
Joost Kremers
Life has its moments

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 > After changing the font size (with `custom-push-theme' and
 > `face-spec-recalc'), the value returned by `window-total-width' is not
 > updated.
 >
 > To reproduce, run `emacs -Q' and do:
 >
 > - (window-total-width) ; shows the initial value
 > - (custom-push-theme 'theme-face 'default 'user 'set '((t (:height 128))))
 >    ; use a :height value that's actually different from the default height.
 > - (face-spec-recalc 'default (selected-frame))
 > - (window-total-width) ; still shows the initial value
 > - C-x 3 ; split window horizontally
 > - C-x 1 ; delete other window
 > - (window-total-width) ; shows the new value
 >
 > The second call to `window-total-width' should already have returned the
 > new value.
 >
 > The following IELM transcript (recorded directly after `emacs -Q') shows
 > the problem:
 >
 > ELISP> (window-total-width)
 > 240 (#o360, #xf0, ?ð)
 > ELISP> (custom-push-theme 'theme-face 'default 'user 'set '((t (:height 128))))
 > ((theme-face default user
 > 	     ((t
 > 	       (:height 128)))))
 >
 > ELISP> (face-spec-recalc 'default (selected-frame))
 > nil
 > ELISP> (window-total-width)
 > 240 (#o360, #xf0, ?ð)
 >
 > ;; now press `C-x 3` followed by `C-x 1'
 >
 > ELISP> (window-total-width)
 > 192 (#o300, #xc0, ?À)
 > ELISP>
 >
 > The second call to `window-total-width` returns 240, but it should have
 > returned 192.

I must admit that I don't have the faintest idea what `face-spec-recalc'
is supposed to do.  I don't understand its doc-string and don't know
where further documentation about it can be found in the manuals.  So I
would be grateful if you or someone else provided me with the necessary
information.

Anyway.  Why do you think that `window-total-width' should return 192 in
the first call?  In principle, face/font changes are supposed to keep
the number of columns/lines unchanged so returning 240 seems reasonable
to me.  Unfortunately, the fact that ...

 > After splitting the window and deleting the other window
 > again, the correct value is returned.

... seems to consitute a bug which, however, I haven't been able to
reproduce here.  One further puzzling aspect: Here, `face-spec-recalc'
makes the frame so large that it goes off-screen and I can't see the
modeline any more.  And you seem to expect the window to shrink ...

 > Note that splitting the window vertically (`C-x 2`) does *not* fix the
 > value returned by `window-total-width'.

Hopefully not.  Everything else would be strange.

In any case, please evaluate (window--dump-frame) in IELM once
immediately before you invoke `face-spec-recalc', once immediately after
you invoked it, and once after you did C-x 1.  You have to copy the
results from a buffer called *window-frame-dump* (three times, because
each dump overwrites the previous one).  Please post the results here.

 > In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2)
 >   of 2014-10-22 on IdeaPad

Could you try with current master/trunk?  Lots of things changed in this
area recently.

martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Sun, 01 Mar 2015 16:14:38 +0100
> From: martin rudalics <rudalics@gmx.at>
> 
>  > ELISP> (face-spec-recalc 'default (selected-frame))
>  > nil
>  > ELISP> (window-total-width)
>  > 240 (#o360, #xf0, ?ð)
>  >
>  > ;; now press `C-x 3` followed by `C-x 1'
>  >
>  > ELISP> (window-total-width)
>  > 192 (#o300, #xc0, ?À)
>  > ELISP>
>  >
>  > The second call to `window-total-width` returns 240, but it should have
>  > returned 192.
> 
> I must admit that I don't have the faintest idea what `face-spec-recalc'
> is supposed to do.

For the purposes of this discussion, I think the only thing that
matters is that it applies the change in the default face's font.

> Anyway.  Why do you think that `window-total-width' should return 192 in
> the first call?  In principle, face/font changes are supposed to keep
> the number of columns/lines unchanged so returning 240 seems reasonable
> to me.

Indeed.  It does for me.  Could this be something specific to GTK or
the window manager?

Also, I don't understand why the initial value is 240 in the first
place.  By default, "emacs -Q" creates a 80-column window, so I'd
expect window-total-width to return a value slightly larger than 80 (I
get 84 here).

So it sounds like some additional factors are at work here.

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 > For the purposes of this discussion, I think the only thing that
 > matters is that it applies the change in the default face's font.

If `set-frame-font' were involved, then it has a `keep-size' argument
which, when set, should keep the frame's pixel size constant.  But I
nowhere see `set-frame-font' getting called with that argument non-nil.

 >> Anyway.  Why do you think that `window-total-width' should return 192 in
 >> the first call?  In principle, face/font changes are supposed to keep
 >> the number of columns/lines unchanged so returning 240 seems reasonable
 >> to me.
 >
 > Indeed.  It does for me.  Could this be something specific to GTK or
 > the window manager?

I tried with Gtk and the numbers of lines/columns remain unaltered.  On
Windows I lose one line because the tool bar gets larger by one pixel.

 > Also, I don't understand why the initial value is 240 in the first
 > place.  By default, "emacs -Q" creates a 80-column window, so I'd
 > expect window-total-width to return a value slightly larger than 80 (I
 > get 84 here).
 >
 > So it sounds like some additional factors are at work here.

Indeed.  This issue needs clarification too.

martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Joost Kremers]

On Sun, Mar 01 2015, Eli Zaretskii <eliz@gnu.org> wrote:
> Also, I don't understand why the initial value is 240 in the first
> place.  By default, "emacs -Q" creates a 80-column window, so I'd
> expect window-total-width to return a value slightly larger than 80 (I
> get 84 here).
>
> So it sounds like some additional factors are at work here.

Sorry, my mistake. I should have added that I maximised the frame first.

-- 
Joost Kremers
Life has its moments

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Cc: martin rudalics <rudalics@gmx.at>, 19972@debbugs.gnu.org
> Date: Sun, 01 Mar 2015 18:07:33 +0100
> 
> On Sun, Mar 01 2015, Eli Zaretskii <eliz@gnu.org> wrote:
> > Also, I don't understand why the initial value is 240 in the first
> > place.  By default, "emacs -Q" creates a 80-column window, so I'd
> > expect window-total-width to return a value slightly larger than 80 (I
> > get 84 here).
> >
> > So it sounds like some additional factors are at work here.
> 
> Sorry, my mistake. I should have added that I maximised the frame first.

FWIW, I don't see a different value after evaluating the
face-spec-recalc form, even if I start with a maximized frame.  What I
see is a frame whose part is invisible because it is beyond the screen
edges.  Which is what I'd expect.

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Joost Kremers]

On Sun, Mar 01 2015, Eli Zaretskii <eliz@gnu.org> wrote:
>> Sorry, my mistake. I should have added that I maximised the frame first.
>
> FWIW, I don't see a different value after evaluating the
> face-spec-recalc form, even if I start with a maximized frame.  What I
> see is a frame whose part is invisible because it is beyond the screen
> edges.  Which is what I'd expect.

On my system (Elementary OS, which is based on Ubuntu, but uses a
different graphical environment), the frame doesn't change its size.
Since the font size changes, there are fewer characters on a line,
which, AFAIU, should be reflected in the value returned by
`window-total-width'. 

-- 
Joost Kremers
Life has its moments

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Cc: rudalics@gmx.at, 19972@debbugs.gnu.org
> Date: Sun, 01 Mar 2015 21:43:35 +0100
> 
> > FWIW, I don't see a different value after evaluating the
> > face-spec-recalc form, even if I start with a maximized frame.  What I
> > see is a frame whose part is invisible because it is beyond the screen
> > edges.  Which is what I'd expect.
> 
> On my system (Elementary OS, which is based on Ubuntu, but uses a
> different graphical environment), the frame doesn't change its size.

What is your window manager?

> Since the font size changes, there are fewer characters on a line,
> which, AFAIU, should be reflected in the value returned by
> `window-total-width'. 

I think Emacs doesn't expect the frame size to remain unchanged in
pixels.

I asked about values returned by window-width in this scenario, can
you provide them?

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Joost Kremers]

On Mon, Mar 02 2015, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Joost Kremers <joostkremers@fastmail.fm>
>> Cc: rudalics@gmx.at, 19972@debbugs.gnu.org
>> Date: Sun, 01 Mar 2015 21:43:35 +0100
>> 
>> > FWIW, I don't see a different value after evaluating the
>> > face-spec-recalc form, even if I start with a maximized frame.  What I
>> > see is a frame whose part is invisible because it is beyond the screen
>> > edges.  Which is what I'd expect.
>> 
>> On my system (Elementary OS, which is based on Ubuntu, but uses a
>> different graphical environment), the frame doesn't change its size.
>
> What is your window manager?

Gala: https://code.launchpad.net/~gala-dev/gala/trunk

>> Since the font size changes, there are fewer characters on a line,
>> which, AFAIU, should be reflected in the value returned by
>> `window-total-width'. 
>
> I think Emacs doesn't expect the frame size to remain unchanged in
> pixels.
>
> I asked about values returned by window-width in this scenario, can
> you provide them?

Sorry, forgot that. `window-width' doesn't have the same issue. On my
system, with a maximised Emacs frame (Emacs version 25.0.50.1), it
returns 236 before `custom-push-theme' + `face-spec-recalc', and 188
after it, even without doing `C-x 3' followed by `C-x 1'.

-- 
Joost Kremers
Life has its moments

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Cc: rudalics@gmx.at, 19972@debbugs.gnu.org
> Date: Mon, 02 Mar 2015 04:59:25 +0100
> 
> > I asked about values returned by window-width in this scenario, can
> > you provide them?
> 
> Sorry, forgot that. `window-width' doesn't have the same issue. On my
> system, with a maximised Emacs frame (Emacs version 25.0.50.1), it
> returns 236 before `custom-push-theme' + `face-spec-recalc', and 188
> after it, even without doing `C-x 3' followed by `C-x 1'.

In that case, I guess if you call (window-total-width 'round), you
will see the correct value even before "C-x 3", right?

Also, what does frame-total-cols return during your recipe?

Martin, I show below a backtrace that explains how face-spec-recalc
causes the frame to be resized, I hope this will help you see what's
going on.

My guess is that immediately after resizing the frame, as shown below
in the backtrace, we get some X event from the window manager telling
us to size the frame back, but we either don't interpret that event
correctly, or delay its handling.  This second resize doesn't happen
on my system, so I cannot show more information about it.

Joost, could you find out where does w->pixel_size change in your
recipe (where 'w' is the pointer to the window displaying *scratch*)?
If my guess is correct, it should change twice: once as shown below in
the backtrace I produced, and then once more, where it changes back to
the dimensions of your display.  We are interested to know where is
that second time, and who calls that code.

One way of finding this out is to put a watchpoint in GDB on
w->pixel_size.  Let me know if you need more detailed instructions for
how to do it.

Here's the backtrace from the code that resizes the frame as result of
face-spec-recalc:

0x0109bc93 in resize_frame_windows (f=0x17d7a30 <dumped_data+2428016>,
    size=833, horflag=true, pixelwise=true) at window.c:4192
4192            r->pixel_width = new_pixel_size;
(gdb) bt
#0  0x0109bc93 in resize_frame_windows (f=0x17d7a30 <dumped_data+2428016>,
    size=833, horflag=true, pixelwise=true) at window.c:4192
#1  0x01011f3e in adjust_frame_size (f=0x17d7a30 <dumped_data+2428016>,
    new_width=800, new_height=700, inhibit=5, pretend=false, parameter=8064)
    at frame.c:524
#2  0x0100f0cc in change_frame_size_1 (f=0x17d7a30 <dumped_data+2428016>,
    new_width=800, new_height=700, pretend=false, delay=false, safe=false,
    pixelwise=true) at dispnew.c:5501
#3  0x0100f12a in change_frame_size (f=0x17d7a30 <dumped_data+2428016>,
    new_width=800, new_height=700, pretend=false, delay=false, safe=false,
    pixelwise=true) at dispnew.c:5533
#4  0x0100eeb8 in do_pending_window_change (safe=false) at dispnew.c:5459
#5  0x0123f29d in x_set_window_size (f=0x17d7a30 <dumped_data+2428016>,
    change_gravity=false, width=800, height=700, pixelwise=true)
    at w32term.c:6194
#6  0x01011e7e in adjust_frame_size (f=0x17d7a30 <dumped_data+2428016>,
    new_width=800, new_height=700, inhibit=3, pretend=false, parameter=14464)
    at frame.c:490
#7  0x0123e411 in x_new_font (f=0x17d7a30 <dumped_data+2428016>,
    font_object=98909453, fontset=23) at w32term.c:5858
#8  0x0101b3b4 in x_set_font (f=0x17d7a30 <dumped_data+2428016>,
    arg=101384204, oldval=98121716) at frame.c:3611
#9  0x01019339 in x_set_frame_parameters (f=0x17d7a30 <dumped_data+2428016>,
    alist=0) at frame.c:3140
#10 0x010186e3 in Fmodify_frame_parameters (frame=25000501, alist=8969667)
    at frame.c:2663
#11 0x010fab62 in set_font_frame_param (frame=25000501, lface=25182821)
    at xfaces.c:3321
#12 0x010fa43c in Finternal_set_lisp_face_attribute (face=10592, attr=1792,
    value=514, frame=25000501) at xfaces.c:3135
#13 0x011a23f2 in Ffuncall (nargs=5, args=0x88df24) at eval.c:2729
#14 0x011e5ffb in exec_byte_code (bytestr=19792668, vector=19792685,
    maxdepth=30, args_template=0, nargs=0, args=0x0) at bytecode.c:919
#15 0x011a306d in funcall_lambda (fun=19792629, nargs=4,
    arg_vector=0x12e032d <pure+252013>) at eval.c:2951
#16 0x011a25dd in Ffuncall (nargs=5, args=0x88e250) at eval.c:2767
#17 0x011a182c in Fapply (nargs=4, args=0x88e388) at eval.c:2337
#18 0x011a2235 in Ffuncall (nargs=5, args=0x88e384) at eval.c:2698
#19 0x011e5ffb in exec_byte_code (bytestr=19801932, vector=19801949,
    maxdepth=26, args_template=0, nargs=0, args=0x0) at bytecode.c:919
#20 0x011a306d in funcall_lambda (fun=19801893, nargs=3,
    arg_vector=0x12e275d <pure+261277>) at eval.c:2951
#21 0x011a25dd in Ffuncall (nargs=4, args=0x88e6b4) at eval.c:2767
#22 0x011e5ffb in exec_byte_code (bytestr=19801788, vector=19801805,
    maxdepth=22, args_template=0, nargs=0, args=0x0) at bytecode.c:919
#23 0x011a306d in funcall_lambda (fun=19801765, nargs=2,
    arg_vector=0x12e26cd <pure+261133>) at eval.c:2951
#24 0x011a2918 in apply_lambda (fun=19801765, args=98601339, count=13)
    at eval.c:2826
#25 0x011a1118 in eval_sub (form=98601363) at eval.c:2226
#26 0x011a069d in Feval (form=98601363, lexical=0) at eval.c:1996
#27 0x011a2376 in Ffuncall (nargs=3, args=0x88eb9c) at eval.c:2721
#28 0x011e5ffb in exec_byte_code (bytestr=20304908, vector=20304925,
    maxdepth=22, args_template=1030, nargs=1, args=0x88eed0) at bytecode.c:919
#29 0x011a2c42 in funcall_lambda (fun=20304885, nargs=1, arg_vector=0x88eecc)
    at eval.c:2885
#30 0x011a25dd in Ffuncall (nargs=2, args=0x88eec8) at eval.c:2767
#31 0x011e5ffb in exec_byte_code (bytestr=20305284, vector=20305301,
    maxdepth=18, args_template=1030, nargs=1, args=0x88f2dc) at bytecode.c:919
#32 0x011a2c42 in funcall_lambda (fun=20305253, nargs=1, arg_vector=0x88f2d8)
    at eval.c:2885
#33 0x011a25dd in Ffuncall (nargs=2, args=0x88f2d4) at eval.c:2767
#34 0x011990dc in Ffuncall_interactively (nargs=2, args=0x88f2d4)
    at callint.c:252
#35 0x011a2235 in Ffuncall (nargs=3, args=0x88f2d0) at eval.c:2698
#36 0x0119b2b5 in Fcall_interactively (function=-10501392, record_flag=0,
    keys=22605245) at callint.c:849
#37 0x011a23ae in Ffuncall (nargs=4, args=0x88f55c) at eval.c:2725
#38 0x011e5ffb in exec_byte_code (bytestr=19977892, vector=19977909,
    maxdepth=54, args_template=4102, nargs=1, args=0x88f8a0) at bytecode.c:919
#39 0x011a2c42 in funcall_lambda (fun=19977869, nargs=1, arg_vector=0x88f89c)
    at eval.c:2885
#40 0x011a25dd in Ffuncall (nargs=2, args=0x88f898) at eval.c:2767
#41 0x011a1e40 in call1 (fn=9184, arg1=-10501392) at eval.c:2573
#42 0x0110b3b3 in command_loop_1 () at keyboard.c:1521
#43 0x0119ee3b in internal_condition_case (bfun=0x110ab87 <command_loop_1>,
    handlers=12224, hfun=0x110a281 <cmd_error>) at eval.c:1348
#44 0x0110a7c2 in command_loop_2 (ignore=0) at keyboard.c:1139
#45 0x0119e376 in internal_catch (tag=31904, func=0x110a797 <command_loop_2>,
    arg=0) at eval.c:1108
#46 0x0110a761 in command_loop () at keyboard.c:1118
#47 0x01109de1 in recursive_edit_1 () at keyboard.c:728
#48 0x01109fd3 in Frecursive_edit () at keyboard.c:799
#49 0x01107f3d in main (argc=2, argv=0xca1f38) at emacs.c:1607

Lisp Backtrace:
"internal-set-lisp-face-attribute" (0x88df28)
"set-face-attribute" (0x88e254)
"apply" (0x88e388)
"face-spec-set-2" (0x88e6b8)
"face-spec-recalc" (0x88e940)
"eval" (0x88eba0)
"elisp--eval-last-sexp" (0x88eecc)
"eval-last-sexp" (0x88f2d8)
"funcall-interactively" (0x88f2d4)
"call-interactively" (0x88f560)
"command-execute" (0x88f89c)

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 > In that case, I guess if you call (window-total-width 'round), you
 > will see the correct value even before "C-x 3", right?

I guess so too.  `window-total-width' is very special because it tries
to support `windmove'.  Suppose I have two adjacent side-by-side windows
both 49.5 columns wide.  Then `window-total-width' returns something
like 49 columns for one and 50 for the other window because otherwise
`windmove' would be broken.  `window-left-column' behaves accordingly.

Basically, for windows whose width is not an integral multiple of the
default character width, `window-total-width' is not accurate.  But it
should obviously be "more" correct in Joost's case.

 > Martin, I show below a backtrace that explains how face-spec-recalc
 > causes the frame to be resized, I hope this will help you see what's
 > going on.
 >
 > My guess is that immediately after resizing the frame, as shown below
 > in the backtrace, we get some X event from the window manager telling
 > us to size the frame back, but we either don't interpret that event
 > correctly, or delay its handling.  This second resize doesn't happen
 > on my system, so I cannot show more information about it.

No.  The problem is more trivial.  Every request to resize a frame is
eventually processed by adjust_frame_size.  But if the latter decides
that the width of the frame's root window does not change pixelwise, it
does not call resize_frame_windows.  And it's the latter who's
responsible for updating the total widths and heights of windows (all
for the sake of windmove only).

 > Here's the backtrace from the code that resizes the frame as result of
 > face-spec-recalc:
 >
 > 0x0109bc93 in resize_frame_windows (f=0x17d7a30 <dumped_data+2428016>,
 >      size=833, horflag=true, pixelwise=true) at window.c:4192
 > 4192            r->pixel_width = new_pixel_size;
 > (gdb) bt
 > #0  0x0109bc93 in resize_frame_windows (f=0x17d7a30 <dumped_data+2428016>,
 >      size=833, horflag=true, pixelwise=true) at window.c:4192

Here you see resize_frame_windows getting called which will eventually
call `window--pixel-to-total' to assign the new total sizes of windows.
For Joost this call doesn't happen because new_windows_width equals
old_windows_width.

 > #1  0x01011f3e in adjust_frame_size (f=0x17d7a30 <dumped_data+2428016>,
 >      new_width=800, new_height=700, inhibit=5, pretend=false, parameter=8064)
 >      at frame.c:524
 > #2  0x0100f0cc in change_frame_size_1 (f=0x17d7a30 <dumped_data+2428016>,
 >      new_width=800, new_height=700, pretend=false, delay=false, safe=false,
 >      pixelwise=true) at dispnew.c:5501
 > #3  0x0100f12a in change_frame_size (f=0x17d7a30 <dumped_data+2428016>,
 >      new_width=800, new_height=700, pretend=false, delay=false, safe=false,
 >      pixelwise=true) at dispnew.c:5533
 > #4  0x0100eeb8 in do_pending_window_change (safe=false) at dispnew.c:5459
 > #5  0x0123f29d in x_set_window_size (f=0x17d7a30 <dumped_data+2428016>,
 >      change_gravity=false, width=800, height=700, pixelwise=true)
 >      at w32term.c:6194
 > #6  0x01011e7e in adjust_frame_size (f=0x17d7a30 <dumped_data+2428016>,
 >      new_width=800, new_height=700, inhibit=3, pretend=false, parameter=14464)
 >      at frame.c:490

Note that x_new_font _always_ calls adjust_frame_size (even for the
`set-frame-font' KEEP-SIZE non-nil case) trying to adjust the frame
size.

I sincerely hope your frame was not maximized here.  Otherwise,
resize_frame_windows should not have been called ...

 > #7  0x0123e411 in x_new_font (f=0x17d7a30 <dumped_data+2428016>,
 >      font_object=98909453, fontset=23) at w32term.c:5858
 > #8  0x0101b3b4 in x_set_font (f=0x17d7a30 <dumped_data+2428016>,
 >      arg=101384204, oldval=98121716) at frame.c:3611
 > #9  0x01019339 in x_set_frame_parameters (f=0x17d7a30 <dumped_data+2428016>,
 >      alist=0) at frame.c:3140
 > #10 0x010186e3 in Fmodify_frame_parameters (frame=25000501, alist=8969667)
 >      at frame.c:2663
 > #11 0x010fab62 in set_font_frame_param (frame=25000501, lface=25182821)
 >      at xfaces.c:3321
 > #12 0x010fa43c in Finternal_set_lisp_face_attribute (face=10592, attr=1792,
 >      value=514, frame=25000501) at xfaces.c:3135

martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Mon, 02 Mar 2015 18:08:45 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19972@debbugs.gnu.org
> 
>  > Here's the backtrace from the code that resizes the frame as result of
>  > face-spec-recalc:
>  >
>  > 0x0109bc93 in resize_frame_windows (f=0x17d7a30 <dumped_data+2428016>,
>  >      size=833, horflag=true, pixelwise=true) at window.c:4192
>  > 4192            r->pixel_width = new_pixel_size;
>  > (gdb) bt
>  > #0  0x0109bc93 in resize_frame_windows (f=0x17d7a30 <dumped_data+2428016>,
>  >      size=833, horflag=true, pixelwise=true) at window.c:4192
> 
> Here you see resize_frame_windows getting called which will eventually
> call `window--pixel-to-total' to assign the new total sizes of windows.
> For Joost this call doesn't happen because new_windows_width equals
> old_windows_width.

I don't understand why that would happen.  It doesn't seem to happen
for me, with the current emacs-24 branch.

>  > #1  0x01011f3e in adjust_frame_size (f=0x17d7a30 <dumped_data+2428016>,
>  >      new_width=800, new_height=700, inhibit=5, pretend=false, parameter=8064)
>  >      at frame.c:524
>  > #2  0x0100f0cc in change_frame_size_1 (f=0x17d7a30 <dumped_data+2428016>,
>  >      new_width=800, new_height=700, pretend=false, delay=false, safe=false,
>  >      pixelwise=true) at dispnew.c:5501
>  > #3  0x0100f12a in change_frame_size (f=0x17d7a30 <dumped_data+2428016>,
>  >      new_width=800, new_height=700, pretend=false, delay=false, safe=false,
>  >      pixelwise=true) at dispnew.c:5533
>  > #4  0x0100eeb8 in do_pending_window_change (safe=false) at dispnew.c:5459
>  > #5  0x0123f29d in x_set_window_size (f=0x17d7a30 <dumped_data+2428016>,
>  >      change_gravity=false, width=800, height=700, pixelwise=true)
>  >      at w32term.c:6194
>  > #6  0x01011e7e in adjust_frame_size (f=0x17d7a30 <dumped_data+2428016>,
>  >      new_width=800, new_height=700, inhibit=3, pretend=false, parameter=14464)
>  >      at frame.c:490
> 
> Note that x_new_font _always_ calls adjust_frame_size (even for the
> `set-frame-font' KEEP-SIZE non-nil case) trying to adjust the frame
> size.
> 
> I sincerely hope your frame was not maximized here.  Otherwise,
> resize_frame_windows should not have been called ...

It is called with maximized frames as well, see the backtrace below.

#0  0x010913a4 in resize_frame_windows (f=0x3a7b5d0, size=2396, horflag=true,
    pixelwise=true) at window.c:4211
#1  0x0100ea3e in change_frame_size_1 (f=0x3a7b5d0, new_width=2360,
    new_height=1300, pretend=false, delay=false, safe=false, pixelwise=true)
    at dispnew.c:5610
#2  0x0100e719 in change_frame_size (f=0x3a7b5d0, new_width=2360,
    new_height=1300, pretend=false, delay=false, safe=false, pixelwise=true)
    at dispnew.c:5518
#3  0x0100e60c in do_pending_window_change (safe=false) at dispnew.c:5479
#4  0x010199eb in x_set_font (f=0x3a7b5d0, arg=62956977, oldval=58852321)
    at frame.c:3355
#5  0x01017c73 in x_set_frame_parameters (f=0x3a7b5d0, alist=58296354)
    at frame.c:2889
#6  0x01016c55 in Fmodify_frame_parameters (frame=61322709, alist=58675454)
    at frame.c:2350
#7  0x010e9f66 in set_font_frame_param (frame=61322709, lface=61590461)
    at xfaces.c:3418
#8  0x010e9975 in Finternal_set_lisp_face_attribute (face=58325890,
    attr=58296898, value=512, frame=61322709) at xfaces.c:3233
#9  0x01185d95 in Ffuncall (nargs=5, args=0x82e1a4) at eval.c:2822
#10 0x011c67a9 in exec_byte_code (bytestr=19629633, vector=19629653,
    maxdepth=28, args_template=58296354, nargs=0, args=0x0) at bytecode.c:916
#11 0x011868da in funcall_lambda (fun=19629597, nargs=4,
    arg_vector=0x12b8655 <pure+257109>) at eval.c:3044
#12 0x01185f42 in Ffuncall (nargs=5, args=0x82e4a0) at eval.c:2860
#13 0x01185268 in Fapply (nargs=4, args=0x82e5a8) at eval.c:2350
#14 0x01185bfb in Ffuncall (nargs=5, args=0x82e5a4) at eval.c:2792
#15 0x011c67a9 in exec_byte_code (bytestr=19638793, vector=19638813,
    maxdepth=24, args_template=58296354, nargs=0, args=0x0) at bytecode.c:916
#16 0x011868da in funcall_lambda (fun=19638757, nargs=3,
    arg_vector=0x12baa1d <pure+266269>) at eval.c:3044
#17 0x01185f42 in Ffuncall (nargs=4, args=0x82e8a4) at eval.c:2860
#18 0x011c67a9 in exec_byte_code (bytestr=19638649, vector=19638669,
    maxdepth=20, args_template=58296354, nargs=0, args=0x0) at bytecode.c:916
#19 0x011868da in funcall_lambda (fun=19638629, nargs=2,
    arg_vector=0x12ba98d <pure+266125>) at eval.c:3044
#20 0x01186216 in apply_lambda (fun=19638629, args=58677654, count=13)
    at eval.c:2919
#21 0x01184bcf in eval_sub (form=58677678) at eval.c:2226
#22 0x011841dd in Feval (form=58677678, lexical=58296354) at eval.c:1996
#23 0x01185d2e in Ffuncall (nargs=3, args=0x82ed4c) at eval.c:2814
#24 0x011c67a9 in exec_byte_code (bytestr=20150481, vector=20150501,
    maxdepth=20, args_template=1028, nargs=1, args=0x82f050) at bytecode.c:916
#25 0x01186516 in funcall_lambda (fun=20150461, nargs=1, arg_vector=0x82f04c)
    at eval.c:2978
#26 0x01185f42 in Ffuncall (nargs=2, args=0x82f048) at eval.c:2860
#27 0x011c67a9 in exec_byte_code (bytestr=20150857, vector=20150877,
    maxdepth=16, args_template=1028, nargs=1, args=0x82f398) at bytecode.c:916
#28 0x01186516 in funcall_lambda (fun=20150829, nargs=1, arg_vector=0x82f394)
    at eval.c:2978
#29 0x01185f42 in Ffuncall (nargs=2, args=0x82f390) at eval.c:2860
#30 0x0117f504 in Fcall_interactively (function=60483810,
    record_flag=58296354, keys=58317685) at callint.c:836
#31 0x01185d5d in Ffuncall (nargs=4, args=0x82f57c) at eval.c:2818
#32 0x011c67a9 in exec_byte_code (bytestr=19837345, vector=19837365,
    maxdepth=52, args_template=4100, nargs=1, args=0x82f890) at bytecode.c:916
#33 0x01186516 in funcall_lambda (fun=19837325, nargs=1, arg_vector=0x82f88c)
    at eval.c:2978
#34 0x01185f42 in Ffuncall (nargs=2, args=0x82f888) at eval.c:2860
#35 0x011857ec in call1 (fn=58342562, arg1=60483810) at eval.c:2610
#36 0x010f97bf in command_loop_1 () at keyboard.c:1560
#37 0x01182c4f in internal_condition_case (bfun=0x10f915e <command_loop_1>,
    handlers=58347874, hfun=0x10f89c3 <cmd_error>) at eval.c:1348
#38 0x010f8e13 in command_loop_2 (ignore=58296354) at keyboard.c:1178
#39 0x011821ff in internal_catch (tag=58343234,
    func=0x10f8def <command_loop_2>, arg=58296354) at eval.c:1112
#40 0x010f8dc9 in command_loop () at keyboard.c:1157
#41 0x010f8560 in recursive_edit_1 () at keyboard.c:778
#42 0x010f871c in Frecursive_edit () at keyboard.c:849
#43 0x010f6936 in main (argc=2, argv=0xa427e0) at emacs.c:1642

Lisp Backtrace:
"internal-set-lisp-face-attribute" (0x82e1a8)
"set-face-attribute" (0x82e4a4)
"apply" (0x82e5a8)
"face-spec-set-2" (0x82e8a8)
"face-spec-recalc" (0x82eb30)
"eval" (0x82ed50)
"eval-last-sexp-1" (0x82f04c)
"eval-last-sexp" (0x82f394)
"call-interactively" (0x82f580)
"command-execute" (0x82f88c)

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 >> Here you see resize_frame_windows getting called which will eventually
 >> call `window--pixel-to-total' to assign the new total sizes of windows.
 >> For Joost this call doesn't happen because new_windows_width equals
 >> old_windows_width.
 >
 > I don't understand why that would happen.  It doesn't seem to happen
 > for me, with the current emacs-24 branch.

Your backtrace was from Emacs 25.  Emacs 24 doesn't have
adjust_frame_size.

 >>   > #1  0x01011f3e in adjust_frame_size (f=0x17d7a30 <dumped_data+2428016>,
 >>   >      new_width=800, new_height=700, inhibit=5, pretend=false, parameter=8064)
 >>   >      at frame.c:524
[...]
 >> Note that x_new_font _always_ calls adjust_frame_size (even for the
 >> `set-frame-font' KEEP-SIZE non-nil case) trying to adjust the frame
 >> size.
 >>
 >> I sincerely hope your frame was not maximized here.  Otherwise,
 >> resize_frame_windows should not have been called ...
 >
 > It is called with maximized frames as well, see the backtrace below.
 >
 > #0  0x010913a4 in resize_frame_windows (f=0x3a7b5d0, size=2396, horflag=true,
 >      pixelwise=true) at window.c:4211
 > #1  0x0100ea3e in change_frame_size_1 (f=0x3a7b5d0, new_width=2360,
 >      new_height=1300, pretend=false, delay=false, safe=false, pixelwise=true)
 >      at dispnew.c:5610

This backtrace is from Emacs 24 where resize_frame_windows gets called
by change_frame_size_1.

martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Mon, 02 Mar 2015 19:12:42 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, 19972@debbugs.gnu.org
> 
>  > I don't understand why that would happen.  It doesn't seem to happen
>  > for me, with the current emacs-24 branch.
> 
> Your backtrace was from Emacs 25.  Emacs 24 doesn't have
> adjust_frame_size.
> 
>  >>   > #1  0x01011f3e in adjust_frame_size (f=0x17d7a30 <dumped_data+2428016>,
>  >>   >      new_width=800, new_height=700, inhibit=5, pretend=false, parameter=8064)
>  >>   >      at frame.c:524
> [...]
>  >> Note that x_new_font _always_ calls adjust_frame_size (even for the
>  >> `set-frame-font' KEEP-SIZE non-nil case) trying to adjust the frame
>  >> size.
>  >>
>  >> I sincerely hope your frame was not maximized here.  Otherwise,
>  >> resize_frame_windows should not have been called ...
>  >
>  > It is called with maximized frames as well, see the backtrace below.
>  >
>  > #0  0x010913a4 in resize_frame_windows (f=0x3a7b5d0, size=2396, horflag=true,
>  >      pixelwise=true) at window.c:4211
>  > #1  0x0100ea3e in change_frame_size_1 (f=0x3a7b5d0, new_width=2360,
>  >      new_height=1300, pretend=false, delay=false, safe=false, pixelwise=true)
>  >      at dispnew.c:5610
> 
> This backtrace is from Emacs 24 where resize_frame_windows gets called
> by change_frame_size_1.

Sorry, I didn't realize you were talking about the master branch.
Yes, there resize_frame_windows doesn't get called, and the frame
dimensions don't change, if it is maximized to begin with.

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 > Sorry, I didn't realize you were talking about the master branch.

I was because your first backtrace was from the master branch.

 > Yes, there resize_frame_windows doesn't get called, and the frame
 > dimensions don't change, if it is maximized to begin with.

Relieving.

Thanks, martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Mon, 02 Mar 2015 19:43:26 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, 19972@debbugs.gnu.org
> 
>  > Sorry, I didn't realize you were talking about the master branch.
> 
> I was because your first backtrace was from the master branch.

I didn't realize there was any difference regarding this issue between
the two branches.

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Joost Kremers]

On Mon, Mar 02 2015, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Joost Kremers <joostkremers@fastmail.fm>
>> Cc: rudalics@gmx.at, 19972@debbugs.gnu.org
>> Date: Mon, 02 Mar 2015 04:59:25 +0100
>> 
>> > I asked about values returned by window-width in this scenario, can
>> > you provide them?
>> 
>> Sorry, forgot that. `window-width' doesn't have the same issue. On my
>> system, with a maximised Emacs frame (Emacs version 25.0.50.1), it
>> returns 236 before `custom-push-theme' + `face-spec-recalc', and 188
>> after it, even without doing `C-x 3' followed by `C-x 1'.
>
> In that case, I guess if you call (window-total-width 'round), you
> will see the correct value even before "C-x 3", right?

No, it doesn't. It still returns 240, i.e., the same value returned by
(window-total-width).

(window-width) returns 188.

(frame-total-cols) returns 192.

After C-x 3 C-x 1, (window-total-width) also returns 192.

(All of this with Emacs 25.0.50.1 and a maximised frame.)

> Joost, could you find out where does w->pixel_size change in your
> recipe (where 'w' is the pointer to the window displaying *scratch*)?

I'd be happy to, but...

> If my guess is correct, it should change twice: once as shown below in
> the backtrace I produced, and then once more, where it changes back to
> the dimensions of your display.  We are interested to know where is
> that second time, and who calls that code.
>
> One way of finding this out is to put a watchpoint in GDB on
> w->pixel_size.  Let me know if you need more detailed instructions for
> how to do it.

That would be great, since I have only basic knowledge of GDB.


-- 
Joost Kremers
Life has its moments

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> From: Joost Kremers <joostkremers@fastmail.fm>
> Cc: rudalics@gmx.at, 19972@debbugs.gnu.org
> Date: Mon, 02 Mar 2015 23:26:58 +0100
> 
> >> Sorry, forgot that. `window-width' doesn't have the same issue. On my
> >> system, with a maximised Emacs frame (Emacs version 25.0.50.1), it
> >> returns 236 before `custom-push-theme' + `face-spec-recalc', and 188
> >> after it, even without doing `C-x 3' followed by `C-x 1'.
> >
> > In that case, I guess if you call (window-total-width 'round), you
> > will see the correct value even before "C-x 3", right?
> 
> No, it doesn't. It still returns 240, i.e., the same value returned by
> (window-total-width).
> 
> (window-width) returns 188.

That's very strange, since they use the same data.  But if Martin's
patch fixes the issue for you (does it?), we don't need to pursue this
further.

> > Joost, could you find out where does w->pixel_size change in your
> > recipe (where 'w' is the pointer to the window displaying *scratch*)?
> 
> I'd be happy to, but...
> 
> > If my guess is correct, it should change twice: once as shown below in
> > the backtrace I produced, and then once more, where it changes back to
> > the dimensions of your display.  We are interested to know where is
> > that second time, and who calls that code.
> >
> > One way of finding this out is to put a watchpoint in GDB on
> > w->pixel_size.  Let me know if you need more detailed instructions for
> > how to do it.
> 
> That would be great, since I have only basic knowledge of GDB.

Given Jan's explanation of the issue, I don't think this is needed
anymore.

Thanks.

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 > Given Jan's explanation of the issue, I don't think this is needed
 > anymore.

Jan's explanation was for X.  NS behaves differently IIUC.

martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Jan Djärv]

Hi. 


> 3 mar 2015 kl. 09:07 skrev martin rudalics <rudalics@gmx.at>:
> 
> > Given Jan's explanation of the issue, I don't think this is needed
> > anymore.
> 
> Jan's explanation was for X.  NS behaves differently IIUC.

Actually not. NS also only changes stuff when it gets an event that informs about resize. 

      Jan D. 

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 > Actually not. NS also only changes stuff when it gets an event that informs about resize.

IIUC Emacs doesn't run a timer when issuing a resize request on NS.  So
I have no idea how two subsequent resize requests are handled there.
Consider the case where Lisp code sends a height change request first
and a width change request afterwards: Which is the height Emacs asks
for in the second request?  The one before the first request or the one
after the first request has been honored?

martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Jan D.]

martin rudalics skrev den 2015-03-03 11:17:
>  > Actually not. NS also only changes stuff when it gets an event that
> informs about resize.
>
> IIUC Emacs doesn't run a timer when issuing a resize request on NS.  So
> I have no idea how two subsequent resize requests are handled there.
> Consider the case where Lisp code sends a height change request first
> and a width change request afterwards: Which is the height Emacs asks
> for in the second request?  The one before the first request or the one
> after the first request has been honored?

Lisp code that expects resize changes to be handeled synchronously and 
in order are fundamentally broken.

That said, it may very well be a race here, i.e. the wrong height gets 
sent.  But this is only because bad Lisp code assumes synchronous handling.

	Jan D.

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 > Lisp code that expects resize changes to be handeled synchronously and in order are fundamentally broken.
 >
 > That said, it may very well be a race here, i.e. the wrong height gets sent.  But this is only because bad Lisp code assumes synchronous handling.

Fully agreed.  Unfortunately, it can be very difficult to explain this
to users :-(

BTW what is the x_wait_for_event in x_set_window_size_1 then really
needed for?

martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Jan D.]

martin rudalics skrev den 2015-03-03 12:26:
>  > Lisp code that expects resize changes to be handeled synchronously
> and in order are fundamentally broken.
>  >
>  > That said, it may very well be a race here, i.e. the wrong height
> gets sent.  But this is only because bad Lisp code assumes synchronous
> handling.
>
> Fully agreed.  Unfortunately, it can be very difficult to explain this
> to users :-(
>
> BTW what is the x_wait_for_event in x_set_window_size_1 then really
> needed for?


Its an attempt to be nice to Lisp.  It can fail and time out.

	Jan D.

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Joost Kremers]

On Tue, Mar 03 2015, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Joost Kremers <joostkremers@fastmail.fm>
>> Cc: rudalics@gmx.at, 19972@debbugs.gnu.org
>> Date: Mon, 02 Mar 2015 23:26:58 +0100
>> 
>> >> Sorry, forgot that. `window-width' doesn't have the same issue. On my
>> >> system, with a maximised Emacs frame (Emacs version 25.0.50.1), it
>> >> returns 236 before `custom-push-theme' + `face-spec-recalc', and 188
>> >> after it, even without doing `C-x 3' followed by `C-x 1'.
>> >
>> > In that case, I guess if you call (window-total-width 'round), you
>> > will see the correct value even before "C-x 3", right?
>> 
>> No, it doesn't. It still returns 240, i.e., the same value returned by
>> (window-total-width).
>> 
>> (window-width) returns 188.
>
> That's very strange, since they use the same data.  But if Martin's
> patch fixes the issue for you (does it?), we don't need to pursue this
> further.

As Martin says, with `ceiling' or `floor' the return value is 192 instead
of 240.

-- 
Joost Kremers
Life has its moments

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 >> In that case, I guess if you call (window-total-width 'round), you
 >> will see the correct value even before "C-x 3", right?
 >
 > No, it doesn't. It still returns 240, i.e., the same value returned by
 > (window-total-width).

Observe that

(window-total-width 'round)

should get you

(wrong-type-argument window-valid-p round)

As a rule `window-' prefixed functions require a window as first
argument.

The form to evaluate should be either (window-total-width nil 'ceiling)
or (window-total-width nil 'floor).  Any other value for ROUND behaves
like `window-total-width' called without ROUND argument.

martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 > On my system (Elementary OS, which is based on Ubuntu, but uses a
 > different graphical environment), the frame doesn't change its size.

Well, this was the missing link.

 > Since the font size changes, there are fewer characters on a line,
 > which, AFAIU, should be reflected in the value returned by
 > `window-total-width'.

Correct.

martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 > FWIW, I don't see a different value after evaluating the
 > face-spec-recalc form, even if I start with a maximized frame.  What I
 > see is a frame whose part is invisible because it is beyond the screen
 > edges.  Which is what I'd expect.

On Emacs 24.5, I presume.  With Emacs 25 a maximized frame should not
change its size any more.

martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 > Sorry, my mistake. I should have added that I maximised the frame first.

This alone would have explained lots of things.

For Emacs 25 only, though ;-)

martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Joost Kremers]

On Sun, Mar 01 2015, martin rudalics <rudalics@gmx.at> wrote:
>  > The second call to `window-total-width` returns 240, but it should have
>  > returned 192.
>
> I must admit that I don't have the faintest idea what `face-spec-recalc'
> is supposed to do.

I must admit, neither do I. The report results from an issue reported
for a package of mine:

https://github.com/joostkremers/visual-fill-column/issues/2

I took the calls to `custom-push-theme' and `face-spec-recalc' from the
code of the `default-text-scale' package.

> Anyway.  Why do you think that `window-total-width' should return 192 in
> the first call?  In principle, face/font changes are supposed to keep
> the number of columns/lines unchanged so returning 240 seems reasonable
> to me.

Well, the fact is that after the font size change, the number of
characters that fit in the window changes as well. AFAIU the return
value of `window-total-width' depends on that, at least in part. Unless
I'm wrong in that assumption...

> In any case, please evaluate (window--dump-frame) in IELM once
> immediately before you invoke `face-spec-recalc', once immediately after
> you invoked it, and once after you did C-x 1.  You have to copy the
> results from a buffer called *window-frame-dump* (three times, because
> each dump overwrites the previous one).  Please post the results here.
> 
>  > In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2)
>  >   of 2014-10-22 on IdeaPad
>
> Could you try with current master/trunk?  Lots of things changed in this
> area recently.

I'll try with the latest Emacs and provide the output of
window--dump-frame ASAP.

-- 
Joost Kremers
Life has its moments

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Joost Kremers]

On Sun, Mar 01 2015, martin rudalics <rudalics@gmx.at> wrote:
>  > In GNU Emacs 24.4.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2)
>  >   of 2014-10-22 on IdeaPad
>
> Could you try with current master/trunk?  Lots of things changed in this
> area recently.

I cloned the git master branch and compiled Emacs (version says it's
25.0.50.1) and still see the same problem.

After Eli's comments, it's now clear that the problem is slightly
different than what I initially thought, though. The issue is not with
font size changes in general, because the frame is usually adjusted to
match. The problem arises when a font size change takes place *without*
the frame changing its size accordingly. In this case, the number of
columns on a frame is changed, but this is not reflected in the return
value of `window-total-width`.

This happened in my case because I ran the test on a maximised Emacs
frame, which wasn't adjusted. (Though I don't know whether that's due to
Emacs not resizing its frame or due to the window manager preventing
it.)

Here are the results from the calls to `window--dump-frame` (done on
Emacs 25.0.50.1):

========== one ==============================
right before `face-spec-recalc'

frame pixel: 1920 x 971   cols/lines: 240 x 57   units: 8 x 17
frame text pixel: 1888 x 971   cols/lines: 236 x 57
tool: 0  scroll: 16/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 3 on *ielm*>   parent: nil
pixel left: 0   top: 0   size: 1920 x 954   new: 0
char left: 0   top: 0   size: 240 x 56   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1888 x 937   char: 236 x 55
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 16  divider: 0
height header-line: 0  mode-line: 17  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 954   size: 1920 x 17   new: 0
char left: 0   top: 56   size: 1920 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1888 x 17   char: 236 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 16  divider: 0
height header-line: 0  mode-line: 0  divider: 0

=============================================

========== two ==============================
right after `face-spec-recalc`

frame pixel: 1920 x 971   cols/lines: 192 x 46   units: 10 x 21
frame text pixel: 1888 x 971   cols/lines: 188 x 46
tool: 0  scroll: 16/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 3 on *ielm*>   parent: nil
pixel left: 0   top: 0   size: 1920 x 950   new: 950
char left: 0   top: 0   size: 240 x 45   new: 56
normal: 1.0 x 1.0   new: ignore
body pixel: 1888 x 929   char: 188 x 44
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 16  divider: 0
height header-line: 0  mode-line: 21  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 950   size: 1920 x 21   new: 0
char left: 0   top: 45   size: 1920 x 1   new: 0
normal: 1.0 x 1.0   new: 0
body pixel: 1888 x 21   char: 188 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 16  divider: 0
height header-line: 0  mode-line: 0  divider: 0

=============================================

========== three ============================
after doing `C-x 3` + `C-x 1`

frame pixel: 1920 x 971   cols/lines: 192 x 46   units: 10 x 21
frame text pixel: 1888 x 971   cols/lines: 188 x 46
tool: 0  scroll: 16/0  fringe: 16  border: 0  right: 0  bottom: 0

#<window 3 on *ielm*>   parent: nil
pixel left: 0   top: 0   size: 1920 x 950   new: 960
char left: 0   top: 0   size: 192 x 45   new: 96
normal: 1.0 x 1.0   new: 0.5
body pixel: 1888 x 929   char: 188 x 44
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 16  divider: 0
height header-line: 0  mode-line: 21  divider: 0

#<window 4 on  *Minibuf-0*>   parent: nil
pixel left: 0   top: 950   size: 1920 x 21   new: 0
char left: 0   top: 45   size: 192 x 1   new: 192
normal: 1.0 x 1.0   new: 0
body pixel: 1888 x 21   char: 188 x 1
width left fringe: 8  left margin: 0  right margin: 0
width right fringe: 8  scroll-bar: 16  divider: 0
height header-line: 0  mode-line: 0  divider: 0

=============================================



-- 
Joost Kremers
Life has its moments

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 4209 bytes --]

 > Here are the results from the calls to `window--dump-frame` (done on
 > Emacs 25.0.50.1):

Thanks.  Presumably with a maximized frame.

 > ========== one ==============================
 > right before `face-spec-recalc'
 >
 > frame pixel: 1920 x 971   cols/lines: 240 x 57   units: 8 x 17
 > frame text pixel: 1888 x 971   cols/lines: 236 x 57
 > tool: 0  scroll: 16/0  fringe: 16  border: 0  right: 0  bottom: 0
 >
 > #<window 3 on *ielm*>   parent: nil
 > pixel left: 0   top: 0   size: 1920 x 954   new: 0
 > char left: 0   top: 0   size: 240 x 56   new: 0

240 is the "old" total width of your window.

 > normal: 1.0 x 1.0   new: 0
 > body pixel: 1888 x 937   char: 236 x 55
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 16  divider: 0
 > height header-line: 0  mode-line: 17  divider: 0
 >
 > #<window 4 on  *Minibuf-0*>   parent: nil
 > pixel left: 0   top: 954   size: 1920 x 17   new: 0
 > char left: 0   top: 56   size: 1920 x 1   new: 0
 > normal: 1.0 x 1.0   new: 0
 > body pixel: 1888 x 17   char: 236 x 1
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 16  divider: 0
 > height header-line: 0  mode-line: 0  divider: 0
 >
 > =============================================
 >
 > ========== two ==============================
 > right after `face-spec-recalc`
 >
 > frame pixel: 1920 x 971   cols/lines: 192 x 46   units: 10 x 21
 > frame text pixel: 1888 x 971   cols/lines: 188 x 46

Here we see the new default font set to 10 x 21, the various frame sizes
remain unaltered as you observed.

 > tool: 0  scroll: 16/0  fringe: 16  border: 0  right: 0  bottom: 0
 >
 > #<window 3 on *ielm*>   parent: nil
 > pixel left: 0   top: 0   size: 1920 x 950   new: 950
 > char left: 0   top: 0   size: 240 x 45   new: 56

The total width of your window remained unaltered at 240.  Clearly the
bug you observed.

 > normal: 1.0 x 1.0   new: ignore
 > body pixel: 1888 x 929   char: 188 x 44
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 16  divider: 0
 > height header-line: 0  mode-line: 21  divider: 0
 >
 > #<window 4 on  *Minibuf-0*>   parent: nil
 > pixel left: 0   top: 950   size: 1920 x 21   new: 0
 > char left: 0   top: 45   size: 1920 x 1   new: 0
 > normal: 1.0 x 1.0   new: 0
 > body pixel: 1888 x 21   char: 188 x 1
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 16  divider: 0
 > height header-line: 0  mode-line: 0  divider: 0
 >
 > =============================================
 >
 > ========== three ============================
 > after doing `C-x 3` + `C-x 1`
 >
 > frame pixel: 1920 x 971   cols/lines: 192 x 46   units: 10 x 21
 > frame text pixel: 1888 x 971   cols/lines: 188 x 46
 > tool: 0  scroll: 16/0  fringe: 16  border: 0  right: 0  bottom: 0
 >
 > #<window 3 on *ielm*>   parent: nil
 > pixel left: 0   top: 0   size: 1920 x 950   new: 960
 > char left: 0   top: 0   size: 192 x 45   new: 96

The total width got updated now to 192 as you observed.

 > normal: 1.0 x 1.0   new: 0.5
 > body pixel: 1888 x 929   char: 188 x 44
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 16  divider: 0
 > height header-line: 0  mode-line: 21  divider: 0
 >
 > #<window 4 on  *Minibuf-0*>   parent: nil
 > pixel left: 0   top: 950   size: 1920 x 21   new: 0
 > char left: 0   top: 45   size: 192 x 1   new: 192
 > normal: 1.0 x 1.0   new: 0
 > body pixel: 1888 x 21   char: 188 x 1
 > width left fringe: 8  left margin: 0  right margin: 0
 > width right fringe: 8  scroll-bar: 16  divider: 0
 > height header-line: 0  mode-line: 0  divider: 0
 >
 > =============================================

OK.  The fix for Emacs 25 is attached.  Please try it.

I'm not yet sure whether to fix this for Emacs 24.5 as well.  Basically,
the fix "should" be harmless and resolve a problem not present in Emacs
24.3.  However, wrong values for `window-total-width' or
`window-left-column' should not really harm if they occur _only_ after
setting the default font on a system whose window manager refuses to
resize the Emacs frame as requested.

Thanks, martin

[-- Attachment #2: frame.c.diff --]
[-- Type: text/plain, Size: 1191 bytes --]

diff --git a/src/frame.c b/src/frame.c
index 4a526e2..bac2b24 100644
--- a/src/frame.c
+++ b/src/frame.c
@@ -537,6 +537,8 @@ adjust_frame_size (struct frame *f, int new_width, int new_height, int inhibit,
 	}
 #endif
     }
+  else if (new_cols != old_cols)
+    call2 (Qwindow_pixel_to_total, frame, Qt);
 
   if (new_windows_height != old_windows_height
       /* When the top margin has changed we have to recalculate the top
@@ -551,6 +553,8 @@ adjust_frame_size (struct frame *f, int new_width, int new_height, int inhibit,
       if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f))
 	FrameRows (FRAME_TTY (f)) = new_lines + FRAME_TOP_MARGIN (f);
     }
+  else if (new_lines != old_lines)
+    call2 (Qwindow_pixel_to_total, frame, Qnil);
 
   frame_size_history_add
     (f, Qadjust_frame_size_3, new_text_width, new_text_height,
@@ -4831,6 +4835,7 @@ syms_of_frame (void)
   DEFSYM (Qframep, "framep");
   DEFSYM (Qframe_live_p, "frame-live-p");
   DEFSYM (Qframe_windows_min_size, "frame-windows-min-size");
+  DEFSYM (Qwindow_pixel_to_total, "window--pixel-to-total");
   DEFSYM (Qexplicit_name, "explicit-name");
   DEFSYM (Qheight, "height");
   DEFSYM (Qicon, "icon");

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Mon, 02 Mar 2015 18:09:40 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 19972@debbugs.gnu.org
> 
> OK.  The fix for Emacs 25 is attached.  Please try it.
> 
> I'm not yet sure whether to fix this for Emacs 24.5 as well.

Depends on whether this is a regression, and if so, since when.  Do
you know?

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 >> I'm not yet sure whether to fix this for Emacs 24.5 as well.
 >
 > Depends on whether this is a regression, and if so, since when.  Do
 > you know?

2013-12-13 or 2013-12-04 I think.  The problem is that the fix would
have to be applied in change_frame_size_1 in dispnew.c and the relevant
parts have changed a lot in Emacs 25.  So it would not get any reliable
testing from users of Emacs 25.

martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Mon, 02 Mar 2015 19:12:28 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: joostkremers@fastmail.fm, 19972@debbugs.gnu.org
> 
>  >> I'm not yet sure whether to fix this for Emacs 24.5 as well.
>  >
>  > Depends on whether this is a regression, and if so, since when.  Do
>  > you know?
> 
> 2013-12-13 or 2013-12-04 I think.  The problem is that the fix would
> have to be applied in change_frame_size_1 in dispnew.c and the relevant
> parts have changed a lot in Emacs 25.  So it would not get any reliable
> testing from users of Emacs 25.

Then let's wait with applying to the branch until after 24.5 is
released.

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 > OK.  The fix for Emacs 25 is attached.  Please try it.

Pushed as 2cc23f1..1903e25  master -> master.

Please try again with most recent trunk/master.

Thanks, martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[Joost Kremers]

On Tue, Mar 03 2015, martin rudalics <rudalics@gmx.at> wrote:
>  > OK.  The fix for Emacs 25 is attached.  Please try it.
>
> Pushed as 2cc23f1..1903e25  master -> master.
>
> Please try again with most recent trunk/master.

Current master (1903e25) fixes it.

-- 
Joost Kremers
Life has its moments

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 > Current master (1903e25) fixes it.

Thanks for checking.  I doubt that I will fix this for Emacs 24.5.  If
I'm not mistaken, this bug must have existed ever since.

martin

bug#19972: 24.4; Font size change doesn't update (window-total-width)

[martin rudalics]

 >  > Current master (1903e25) fixes it.
 >
 > Thanks for checking.  I doubt that I will fix this for Emacs 24.5.  If
 > I'm not mistaken, this bug must have existed ever since.

Closing this bug which should have been fixed with Emacs 25 long ago.

Thanks, martin

bug#19972: Font size change doesn't update (window-total-width)

[Steve Purcell]

- Consider the case of full-screen frames, which never change in pixel size. The window-width should change when the font size changes in this case too.
- set-frame-font is a built-in function with a KEEP-SIZE param which tells it to try to preserve the pixel-size of the frame after the font has changed: my code is copied from there.

So there really shouldn’t be any assumption that the frame size will necessarily change when the font changes.

-Steve

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> From: Steve Purcell <steve@sanityinc.com>
> Date: Mon, 2 Mar 2015 07:57:26 +0000
> 
> - Consider the case of full-screen frames, which never change in pixel size.

They do for me.  See the previous messages.

> So there really shouldn’t be any assumption that the frame size will necessarily change when the font changes.

In this case, Emacs itself changes the frame size, so it can expect it
to change.

I think there's some X event due to the window manager that then
resizes the frame back, but we either don't react to it, or somehow
interpret it incorrectly.

bug#19972: Font size change doesn't update (window-total-width)

[Steve Purcell]

> 
> On 2 Mar 2015, at 13:27, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Steve Purcell <steve@sanityinc.com>
>> Date: Mon, 2 Mar 2015 07:57:26 +0000
>> 
>> - Consider the case of full-screen frames, which never change in pixel size.
> 
> They do for me.  See the previous messages.


I’m on OS X, and NS Emacs uses the native full-screen support there, so Emacs isn’t managing the pixel size directly.

And indeed it’s only in that native full-screen mode that window-size doesn’t get updated for me, so perhaps that’s the only real problem here.

Given that window-width returns a number based on both the current frame/window size and the width of the ‘default face, then if the value is going to be stored for later re-use, any change to the default face should also cause it to be recomputed.

What I’m picking up is that only frame/window size changes currently cause that recomputation, hence this issue.

bug#19972: Font size change doesn't update (window-total-width)

[Steve Purcell]

I should also mention that toggling between fullscreen and normal (at least on NS) is another operation which tangibly changes the window width, but doesn’t seem to result in the result of “(window-width)” changing.

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> From: Steve Purcell <steve@sanityinc.com>
> Date: Mon, 2 Mar 2015 14:09:45 +0000
> 
> I should also mention that toggling between fullscreen and normal (at least on NS) is another operation which tangibly changes the window width, but doesn’t seem to result in the result of “(window-width)” changing.

It does here.

bug#19972: Font size change doesn't update (window-total-width)

[Jan D.]

Steve Purcell skrev den 2015-03-02 15:09:
> I should also mention that toggling between fullscreen and normal (at
> least on NS) is another operation which tangibly changes the window
> width, but doesn’t seem to result in the result of “(window-width)”
> changing.
>

It does here (on NS).  80 => 360 and then 80 again.

	Jan D.

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> From: Steve Purcell <steve@sanityinc.com>
> Date: Mon, 2 Mar 2015 14:07:27 +0000
> 
> Given that window-width returns a number based on both the current frame/window size and the width of the ‘default face, then if the value is going to be stored for later re-use, any change to the default face should also cause it to be recomputed.

That's not how things work in Emacs.  We recompute window metrics when
we resize the window, and frame metrics when we resize the frame.
Changing the default face's font triggers one such resize, and the
values that are supposed to change are recomputed.

> What I’m picking up is that only frame/window size changes currently cause that recomputation, hence this issue.

Maybe you are right, but I'm not yet convinced, because I don't yet
have a clear picture of what causes the frame to be resized back to
the display size.  The OP is on GNU/Linux, so native NS features
cannot be the explanation there.

bug#19972: Font size change doesn't update (window-total-width)

[Jan D.]

Hi.

Eli Zaretskii skrev den 2015-03-02 14:27:
>> From: Steve Purcell <steve@sanityinc.com>
>> Date: Mon, 2 Mar 2015 07:57:26 +0000
>>
>> - Consider the case of full-screen frames, which never change in pixel size.
>
> They do for me.  See the previous messages.
>
>> So there really shouldn’t be any assumption that the frame size will necessarily change when the font changes.
>
> In this case, Emacs itself changes the frame size, so it can expect it
> to change.

In X you can never be sure.  You can request a frame change but it can 
be denied.  For example, fullscreen or tiling window manager.  There 
should be no assumption that what Emacs request w.r.t. frame size 
actually occurs.

>
> I think there's some X event due to the window manager that then
> resizes the frame back, but we either don't react to it, or somehow
> interpret it incorrectly.

No, the window manager denies the original frame resize.  There is no 
"resizing back".

	Jan D.

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Mon, 02 Mar 2015 18:42:56 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> CC: 19972@debbugs.gnu.org
> 
> No, the window manager denies the original frame resize.  There is no 
> "resizing back".

Where in the code does this denial happen?

bug#19972: Font size change doesn't update (window-total-width)

[Jan D.]

Eli Zaretskii skrev 2015-03-02 18:56:
>> Date: Mon, 02 Mar 2015 18:42:56 +0100
>> From: "Jan D." <jan.h.d@swipnet.se>
>> CC: 19972@debbugs.gnu.org
>>
>> No, the window manager denies the original frame resize.  There is no
>> "resizing back".
>
> Where in the code does this denial happen?
>

In the window manager code.

	Jan D.

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Mon, 02 Mar 2015 20:06:55 +0100
> From: "Jan D." <jan.h.d@swipnet.se>
> CC: steve@sanityinc.com, 19972@debbugs.gnu.org
> 
> Eli Zaretskii skrev 2015-03-02 18:56:
> >> Date: Mon, 02 Mar 2015 18:42:56 +0100
> >> From: "Jan D." <jan.h.d@swipnet.se>
> >> CC: 19972@debbugs.gnu.org
> >>
> >> No, the window manager denies the original frame resize.  There is no
> >> "resizing back".
> >
> > Where in the code does this denial happen?
> >
> 
> In the window manager code.

I meant where/how does Emacs know that its request to resize was
denied?

bug#19972: Font size change doesn't update (window-total-width)

[Jan D.]

Hi.



2 mar 2015 kl. 20:52 skrev Eli Zaretskii <eliz@gnu.org>:

>> Date: Mon, 02 Mar 2015 20:06:55 +0100
>> From: "Jan D." <jan.h.d@swipnet.se>
>> CC: steve@sanityinc.com, 19972@debbugs.gnu.org
>> 
>> Eli Zaretskii skrev 2015-03-02 18:56:
>>>> Date: Mon, 02 Mar 2015 18:42:56 +0100
>>>> From: "Jan D." <jan.h.d@swipnet.se>
>>>> CC: 19972@debbugs.gnu.org
>>>> 
>>>> No, the window manager denies the original frame resize.  There is no
>>>> "resizing back".
>>> 
>>> Where in the code does this denial happen?
>> 
>> In the window manager code.
> 
> I meant where/how does Emacs know that its request to resize was
> denied?

When an X window is resized, it gets a ConfigureNotify event.  When the resize is denied, no event arrives.  That is why Emacs on X only considers ConfigureNotify as resizes.  If lisp code tries to resize, we make the request, but nothing is updated until we get a ConfigureNotify.

      Jan D.

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> From: "Jan D." <jan.h.d@swipnet.se>
> Date: Mon, 2 Mar 2015 21:19:14 +0100
> Cc: "steve@sanityinc.com" <steve@sanityinc.com>,
>  "19972@debbugs.gnu.org" <19972@debbugs.gnu.org>
> 
> > I meant where/how does Emacs know that its request to resize was
> > denied?
> 
> When an X window is resized, it gets a ConfigureNotify event.  When the resize is denied, no event arrives.  That is why Emacs on X only considers ConfigureNotify as resizes.  If lisp code tries to resize, we make the request, but nothing is updated until we get a ConfigureNotify.

OK, thanks.

But I don't see anything like that on MS-Windows: we do have a call to
change_frame_size when we receive a WM_SIZE message, but running the
recipe in this thread doesn't cause WM_SIZE to be received, and the
call to change_frame_size, if it is done, comes via
internal-set-lisp-face-attribute and modify-frame-parameters,
i.e. directly from Lisp.  (When the frame is maximized,
change_frame_size is not called at all.)

Martin, can you tell what is the equivalent of the above X processing
on MS-Windows?  Does Emacs implement a similar logic internally?

bug#19972: Font size change doesn't update (window-total-width)

[martin rudalics]

 > But I don't see anything like that on MS-Windows: we do have a call to
 > change_frame_size when we receive a WM_SIZE message, but running the
 > recipe in this thread doesn't cause WM_SIZE to be received,

There should be one for a normally sized frame.

 > and the
 > call to change_frame_size, if it is done, comes via
 > internal-set-lisp-face-attribute and modify-frame-parameters,
 > i.e. directly from Lisp.  (When the frame is maximized,
 > change_frame_size is not called at all.

Neither on X, hopefully ;-)

 > )
 >
 > Martin, can you tell what is the equivalent of the above X processing
 > on MS-Windows?  Does Emacs implement a similar logic internally?

I'm not sure I understand what you mean.  Basically, on Windows we
process the sizes immediately when issuing a size request.  "Process" in
this context means to store the sizes in the frame structure and resize
the frame's windows accordingly.

We do that in the change_frame_size call on line 6173 of w32term.c
(because Drew wanted to see the possible future effect immediately in
the frame sizes).  When Windows gets back to us via a WM_SIZE message we
might eventually call change_frame_size too (on line 5180 of w32term.c)
but do so only if the requested sizes differ from the already stored
ones.  The sizes usually differ when the request was initiated by
Windows (like when the user clicks at the maximize button or mouse-drags
a frame edge) and usually do not differ when the request was initiated
by Lisp code before.

On X we don't process the sizes immediately but rather loop until we get
a notifcation event (similar to WM_SIZE) or a timeout expires.  In the
latter case the frame would have remained unchanged while on Windows it
would have changed (due to the call of line 6173).  So far I have not
seen any inconsistencies on Windows.  These would appear as decorations
that are either too large or too small for our frame.  In any case, a
refusal to resize our window without any notification (like seen by the
OP of the current thread on NS) would obviously hit us on Windows.

When I asked you back then whether we could implement something similar
to the X code on Windows you told me that Windows doesn't have anything
comparable to ConfigureNotify so I didn't pursue the idea any further.
If and when problems pop up with the current code we might have to
reconsider that.

martin

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Tue, 03 Mar 2015 18:47:21 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: steve@sanityinc.com, 19972@debbugs.gnu.org
> 
>  > But I don't see anything like that on MS-Windows: we do have a call to
>  > change_frame_size when we receive a WM_SIZE message, but running the
>  > recipe in this thread doesn't cause WM_SIZE to be received,
> 
> There should be one for a normally sized frame.

We don't do anything with it, probably because the frame was already
resized.

>  > Martin, can you tell what is the equivalent of the above X processing
>  > on MS-Windows?  Does Emacs implement a similar logic internally?
> 
> I'm not sure I understand what you mean.  Basically, on Windows we
> process the sizes immediately when issuing a size request.  "Process" in
> this context means to store the sizes in the frame structure and resize
> the frame's windows accordingly.
> 
> We do that in the change_frame_size call on line 6173 of w32term.c
> (because Drew wanted to see the possible future effect immediately in
> the frame sizes).  When Windows gets back to us via a WM_SIZE message we
> might eventually call change_frame_size too (on line 5180 of w32term.c)
> but do so only if the requested sizes differ from the already stored
> ones.  The sizes usually differ when the request was initiated by
> Windows (like when the user clicks at the maximize button or mouse-drags
> a frame edge) and usually do not differ when the request was initiated
> by Lisp code before.

IOW, we don't wait with a resize until we get a notification, but
instead resize the frame itself, and then might resize again when we
receive WM_SIZE.  Question: why not wait for WM_SIZE, and only resize
after it arrives?  That would emulate better what X does, and also
prevent the second resize.  No?

> When I asked you back then whether we could implement something similar
> to the X code on Windows you told me that Windows doesn't have anything
> comparable to ConfigureNotify so I didn't pursue the idea any further.

I don't remember saying that (and don't know X well enough to make
such assertions to begin with), but in any case, you just explained
that I was wrong, and there is a Windows message equivalent to
ConfigureNotify.

bug#19972: Font size change doesn't update (window-total-width)

[martin rudalics]

 >> There should be one for a normally sized frame.
 >
 > We don't do anything with it, probably because the frame was already
 > resized.

Precisely.

 > IOW, we don't wait with a resize until we get a notification, but
 > instead resize the frame itself, and then might resize again when we
 > receive WM_SIZE.  Question: why not wait for WM_SIZE, and only resize
 > after it arrives?  That would emulate better what X does, and also
 > prevent the second resize.  No?

Usually there's no second resize because Windows does what we asked for.
And the first resize is here to fix bug#16028.

 >> When I asked you back then whether we could implement something similar
 >> to the X code on Windows you told me that Windows doesn't have anything
 >> comparable to ConfigureNotify so I didn't pursue the idea any further.
 >
 > I don't remember saying that (and don't know X well enough to make
 > such assertions to begin with), but in any case, you just explained
 > that I was wrong, and there is a Windows message equivalent to
 > ConfigureNotify.

Which?

martin

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Tue, 03 Mar 2015 19:36:02 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, steve@sanityinc.com, 19972@debbugs.gnu.org
> 
>  >> When I asked you back then whether we could implement something similar
>  >> to the X code on Windows you told me that Windows doesn't have anything
>  >> comparable to ConfigureNotify so I didn't pursue the idea any further.
>  >
>  > I don't remember saying that (and don't know X well enough to make
>  > such assertions to begin with), but in any case, you just explained
>  > that I was wrong, and there is a Windows message equivalent to
>  > ConfigureNotify.
> 
> Which?

WM_SIZE, no?

bug#19972: Font size change doesn't update (window-total-width)

[martin rudalics]

 >> Which?
 >
 > WM_SIZE, no?

Hmmm...  I have to think this over.

martin

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Wed, 04 Mar 2015 16:10:40 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, steve@sanityinc.com, 19972@debbugs.gnu.org
> 
>  >> Which?
>  >
>  > WM_SIZE, no?
> 
> Hmmm...  I have to think this over.

Feel free to ignore, btw.  But to clarify, what I had in mind was call
MoveWindow, and wait for WM_SIZE before we call change_frame_size.  I
have no idea whether this is a good idea, though.

But in any case, are you saying that if we call change_frame_size with
dimensions that Windows doesn't like (can that happen?), then we will
get a WM_SIZE message telling us to change the size to something else?
Does this really happen under some conditions?

bug#19972: Font size change doesn't update (window-total-width)

[martin rudalics]

 > Feel free to ignore, btw.  But to clarify, what I had in mind was call
 > MoveWindow, and wait for WM_SIZE before we call change_frame_size.  I
 > have no idea whether this is a good idea, though.

It's not the idea that bothers me but the implementation.  Looking at
what Jan did in x_wait_for_event it seems very unlikely that I could
come up with an equivalent solution.  Think of the input un-/blocking
part:

   int level = interrupt_input_blocked;
   ...
   while (f->wait_event_type)
     {
       pending_signals = true;
       totally_unblock_input ();
       /* XTread_socket is called after unblock.  */
       block_input ();
       interrupt_input_blocked = level;

Would this work on Windows?  And on Gtk he does

       (void)gtk_events_pending ();
       gdk_flush ();

before calling x_wait_for_event.  Would we have to flush old messages on
Windows and if so how?  All this is probably over my head.

 > But in any case, are you saying that if we call change_frame_size with
 > dimensions that Windows doesn't like (can that happen?

I'm quite confident that Drew will eventually come up with an
appropriate scenario.

 > ), then we will
 > get a WM_SIZE message telling us to change the size to something else?
 > Does this really happen under some conditions?

ISTR that I was suprised by Windows once or twice doing that but I can't
give you any details any more.  Windows is very attentive in this
regard.  OTOH it is by far the most permissive system wrt which changes
it allows.

martin

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Wed, 04 Mar 2015 19:45:39 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, steve@sanityinc.com, 19972@debbugs.gnu.org
> 
>  > Feel free to ignore, btw.  But to clarify, what I had in mind was call
>  > MoveWindow, and wait for WM_SIZE before we call change_frame_size.  I
>  > have no idea whether this is a good idea, though.
> 
> It's not the idea that bothers me but the implementation.  Looking at
> what Jan did in x_wait_for_event it seems very unlikely that I could
> come up with an equivalent solution.  Think of the input un-/blocking
> part:
> 
>    int level = interrupt_input_blocked;
>    ...
>    while (f->wait_event_type)
>      {
>        pending_signals = true;
>        totally_unblock_input ();
>        /* XTread_socket is called after unblock.  */
>        block_input ();
>        interrupt_input_blocked = level;
> 
> Would this work on Windows?  And on Gtk he does
> 
>        (void)gtk_events_pending ();
>        gdk_flush ();
> 
> before calling x_wait_for_event.  Would we have to flush old messages on
> Windows and if so how?  All this is probably over my head.

I don't see why do we have to block and wait.  Why not simply go about
our business, and let the WM_SIZE message come in when it does, and be
handled?

bug#19972: Font size change doesn't update (window-total-width)

[Jan D.]

Hi.

> 4 mar 2015 kl. 19:59 skrev Eli Zaretskii <eliz@gnu.org>:
> 
> I don't see why do we have to block and wait.  Why not simply go about
> our business, and let the WM_SIZE message come in when it does, and be
> handled?

x_wait_for_event is only to try to cater for Lisp code that expects a resize to occur at once.
I think there was a bug for it.

In general, X (and NS) does go about its business and wait for the equivalent of WM_SIZE to arrive.  There is no 
corresponding x_wait_for_event in NS, so it does just that.

	Jan D.

bug#19972: Font size change doesn't update (window-total-width)

[martin rudalics]

 > I don't see why do we have to block and wait.  Why not simply go about
 > our business, and let the WM_SIZE message come in when it does, and be
 > handled?

Because of Bug#16028 :-(

martin

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Thu, 05 Mar 2015 09:06:21 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, steve@sanityinc.com, 19972@debbugs.gnu.org
> 
>  > I don't see why do we have to block and wait.  Why not simply go about
>  > our business, and let the WM_SIZE message come in when it does, and be
>  > handled?
> 
> Because of Bug#16028 :-(

Which part of that bug disallows the above?

bug#19972: Font size change doesn't update (window-total-width)

[martin rudalics]

 >>   > I don't see why do we have to block and wait.  Why not simply go about
 >>   > our business, and let the WM_SIZE message come in when it does, and be
 >>   > handled?
 >>
 >> Because of Bug#16028 :-(
 >
 > Which part of that bug disallows the above?

Well, before the "fix" of bug#16028 Emacs behaved as you described
above.

Suppose an application wants to add 5 lines and 5 columns to a frame.
It can do that in one call

(set-frame-size nil (+ (frame-width) 5) (+ (frame-height) 5))

or via

(progn
   (set-frame-width nil (+ (frame-width) 5))
   (set-frame-height nil (+ (frame-height) 5)))

I suppose that most people would consider these forms idempotent.

However, before the fix, `set-frame-height' could fail because Emacs has
to tell Windows (via AdjustWindowRect) what the desired window width is.
But the width Emacs knows about at that time is still that from before
the `set-frame-width' call.

On X this scenario doesn't fail because Emacs usually loops long enough
until the width value has been updated.  I don't know how NS handles it.

Similar scenarios can be devised when changing any of the values
affected by `frame-inhibit-implied-resize'.

martin

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Thu, 05 Mar 2015 19:14:39 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, steve@sanityinc.com, 19972@debbugs.gnu.org
> 
> Suppose an application wants to add 5 lines and 5 columns to a frame.
> It can do that in one call
> 
> (set-frame-size nil (+ (frame-width) 5) (+ (frame-height) 5))
> 
> or via
> 
> (progn
>    (set-frame-width nil (+ (frame-width) 5))
>    (set-frame-height nil (+ (frame-height) 5)))
> 
> I suppose that most people would consider these forms idempotent.
> 
> However, before the fix, `set-frame-height' could fail because Emacs has
> to tell Windows (via AdjustWindowRect) what the desired window width is.
> But the width Emacs knows about at that time is still that from before
> the `set-frame-width' call.

Did we try back then to sleep a few tens of milliseconds after each
such call?

bug#19972: Font size change doesn't update (window-total-width)

[martin rudalics]

 > Did we try back then to sleep a few tens of milliseconds after each
 > such call?

On Windows never.  On X we do so since Jan's change from 2009-10-21.

martin

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Thu, 05 Mar 2015 22:15:20 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: jan.h.d@swipnet.se, steve@sanityinc.com, 19972@debbugs.gnu.org
> 
>  > Did we try back then to sleep a few tens of milliseconds after each
>  > such call?
> 
> On Windows never.

Maybe we should.  Just sleeping 20 milliseconds, say, shouldn't be a
problem when resizing is in progress.

bug#19972: Font size change doesn't update (window-total-width)

[martin rudalics]

 > Maybe we should.  Just sleeping 20 milliseconds, say, shouldn't be a
 > problem when resizing is in progress.

Looking at x_wait_for_event I wonder what the Windows equivalents for
event->type and ConnectionNumber might be.  If only you could come up
with some preliminary code ...

martin

bug#19972: Font size change doesn't update (window-total-width)

[Eli Zaretskii]

> Date: Fri, 06 Mar 2015 10:21:28 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 19972@debbugs.gnu.org
> 
>  > Maybe we should.  Just sleeping 20 milliseconds, say, shouldn't be a
>  > problem when resizing is in progress.
> 
> Looking at x_wait_for_event I wonder what the Windows equivalents for
> event->type and ConnectionNumber might be.

Maybe I'm missing something obvious, but the Windows equivalent of
event->type quite clearly seems to be the WM_* messages handled by
w32_read_socket.

As for ConnectionNumber: Windows doesn't have any such thing, since we
only support a single "X display" on Windows.

> If only you could come up with some preliminary code ...

I don't think I will have time for that, sorry.  And that's not a big
loss, since I'm hardly an expert on this stuff.

bug#19972: Font size change doesn't update (window-total-width)

[Drew Adams]

> So there really shouldn’t be any assumption that the frame size
> will necessarily change when the font changes.

I disagree strongly.  And several of my libraries depend on this
longstanding feature.

I have no objection, if you want to be able to do things
differently, e.g., as a user option.  But please do not consider
removing this Emacs feature.

bug#19972: Font size change doesn't update (window-total-width)

[Steve Purcell]

> On 2 Mar 2015, at 14:44, Drew Adams <drew.adams@oracle.com> wrote:
> 
>> So there really shouldn’t be any assumption that the frame size
>> will necessarily change when the font changes.
> 
> I disagree strongly.  And several of my libraries depend on this
> longstanding feature.
> 
> I have no objection, if you want to be able to do things
> differently, e.g., as a user option.  But please do not consider
> removing this Emacs feature.


This concern is really tangential to the issue at hand: we would presumably all like window-total-width to reliably return an up-to-date value, and I doubt that any fix for that specific failure would affect anyone's existing code.

In any case, it’s already possible for the frame’s pixel size to remain unchanged even when the font changes: that’s what inevitably happens in the OS-managed fullscreen case described here.

bug#19972: Font size change doesn't update (window-total-width)

[martin rudalics]

 > - Consider the case of full-screen frames, which never change in pixel
 >   size. The window-width should change when the font size changes in
 >   this case too.

This is the case (hopefully) with Emacs 25 but not with Emacs 24.5.
Although some window managers may refuse to change the frame size even
with Emacs 24.5 as we've learned here.

 > - set-frame-font is a built-in function with a KEEP-SIZE param which
 >   tells it to try to preserve the pixel-size of the frame after the
 >   font has changed: my code is copied from there.

If you look at the implementation of this you will see that it first
resizes the frame (via x_new_font) and then tries to size it back to the
original size.  This will fail miserably when the frame was maximized
before (because maximization is a state and not just a specific size)
and will fail when the frame size was not an integral multiple of its
default character size (because `set-frame-font' does some strange
rounding).  So never ever use `set-frame-font' with KEEP-SIZE non-nil.
With Emacs 25 you can do, for example,

(let ((frame-inhibit-implied-resize t))
   (custom-push-theme 'theme-face 'default 'user 'set '((t (:height 128))))
   (face-spec-recalc 'default (selected-frame)))

unless you have set `frame-inhibit-implied-resize' to non-nil already.
Which currently causes `window-total-width' to return a wrong value ;-)

 > So there really shouldn’t be any assumption that the frame size will
 > necessarily change when the font changes.

Emacas <= 24.5 at least _always_ tries to change it.

martin

bug#19972: Font size change doesn't update (window-total-width)

[Steve Purcell]

On 2 Mar 2015, at 17:10, martin rudalics <rudalics@gmx.at> wrote:
> 
> > - Consider the case of full-screen frames, which never change in pixel
> >   size. The window-width should change when the font size changes in
> >   this case too.
> 
> This is the case (hopefully) with Emacs 25 but not with Emacs 24.5.
> Although some window managers may refuse to change the frame size even
> with Emacs 24.5 as we've learned here.



It’s not the case on OS X with Emacs HEAD from 19th Feb, at least.



> > - set-frame-font is a built-in function with a KEEP-SIZE param which
> >   tells it to try to preserve the pixel-size of the frame after the
> >   font has changed: my code is copied from there.
> 
> If you look at the implementation of this you will see that it first
> resizes the frame (via x_new_font) and then tries to size it back to the
> original size.  This will fail miserably when the frame was maximized
> before (because maximization is a state and not just a specific size)
> and will fail when the frame size was not an integral multiple of its
> default character size (because `set-frame-font' does some strange
> rounding).  So never ever use `set-frame-font' with KEEP-SIZE non-nil.
> With Emacs 25 you can do, for example,
> 
> (let ((frame-inhibit-implied-resize t))
>  (custom-push-theme 'theme-face 'default 'user 'set '((t (:height 128))))
>  (face-spec-recalc 'default (selected-frame)))
> 
> unless you have set `frame-inhibit-implied-resize' to non-nil already.


Interesting: I hadn’t seen that. The above snippet still results in a changed frame size on my system, though.

bug#19972: Font size change doesn't update (window-total-width)

[martin rudalics]

 >>> - Consider the case of full-screen frames, which never change in pixel
 >>>    size. The window-width should change when the font size changes in
 >>>    this case too.
 >>
 >> This is the case (hopefully) with Emacs 25 but not with Emacs 24.5.
 >> Although some window managers may refuse to change the frame size even
 >> with Emacs 24.5 as we've learned here.
 >
 >
 >
 > It’s not the case on OS X with Emacs HEAD from 19th Feb, at least.

I meant that with Emacs 25 full-screen frames should never change in
pixel size when the default font changes.  On all platforms.  And people
should see the `window-total-width' problem on all systems with current
trunk.  Have you tried the patch I posted in this thread?

 >> With Emacs 25 you can do, for example,
 >>
 >> (let ((frame-inhibit-implied-resize t))
 >>   (custom-push-theme 'theme-face 'default 'user 'set '((t (:height 128))))
 >>   (face-spec-recalc 'default (selected-frame)))
 >>
 >> unless you have set `frame-inhibit-implied-resize' to non-nil already.
 >
 >
 > Interesting: I hadn’t seen that. The above snippet still results in a changed frame size on my system, though.

We would have to investigate that.  It might mean that OS X changes the
frame size deliberately.  But Emacs should not request such a change
with the above snippet.

martin