bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters'


From: Drew Adams
Subject: bug#22105: 25.1.50; REGRESSION - `modify-frame-parameters'
Date: Sun, 6 Dec 2015 22:03:12 -0800 (PST)

I really hope that you can fix this problem.  It is important to the way
I use Emacs.  I'm reporting this from a dev snapshot (master), but the
same recipe exhibits the same problem with (pre)release 25 builds.

Starting with a build of 2014-10-20, my code that thumbifies frames
(shrinks them to thumbnail size, and restores them) has been broken.
There is no problem with release 24.5 (which came out after 2014-10-20,
IIRC, but from a different dev branch) or with earlier releases or
builds.

All builds since then have problems for frame thumbifying, but there has
seemingly been a lot of changes to the frame code, so the broken
behavior has changed in different ways over the past year or so.  For
this reason of instability (dev changes), and because debugging these
problem(s) seems to take me a long time, I've not filed a bug report
about this until now.

I have a recipe to reproduce a problem, but I don't know whether it is
the only problem.  In general, thumbifying not only does not resize
frames properly, it even changes - if I thumbify & dethumbify the same
frame repeatedly - the thumb size can change a lot.

But such wild changes are not what you will see with this test recipe.
The recipe here reports a single problem that is easy to see.

[This is not the same as bug #14032, which was fixed, though I see now
(after long hours of debugging) that the description seems a bit
similar.  In particular, suppressing the use of scroll bars does not
help.]


To reproduce the problem, use the attached file, test-thumb.el.  Start
with: runemacs.exe -Q --debug-init -l "/PATH/TO/test-thumb.el"

You will use `C-z' to thumbify and dethumbify the *scratch* frame (it's
a toggle).  There is a call to `debug' in `thumfr-thumbify-frame', which
thumbifies.  To see the problem quickly you can comment that out.

The intended behavior (and the behavior in Emacs release 24.5 and prior)
is that once a frame has been thumbified, thumbifying it again, after
dethumbifying, should show it in the same way - its frame parameters
should be restored to those it had when first thumbified.  And this,
regardless of whether the dethumbified frame has changed parameter
values.  IOW, the shape etc. of a thumbnail frame should be determined
once and for all the first time the frame is thumbified.

The behavior instead is that thumbifying results in mirroring the latest
unthumbified frame parameters (with only the `font' parameter changed).
At least that's what I see with the recipe, which shows this problem for
parameter `height'.

Essentially the recipe is this:

1. Thumbify, then dethumbify, to see the expected behavior (can be
   repeated).

2. Then when unthumbified, manually resize the frame, to reduce its
   height noticeably.  Then thumbify.  The thumbnail frame should be the
   same size (e.g., same height) as before, but instead it mirrors the
   aspet ratio of the frame before thumbifying (reduced height).

Below is the detailed recipe.  Note that if you comment-out the call to
`(debug)', or if you just use `c' when the debugger opens, then you can
see the problem - the call to `modify-frame-parameters' after `(debug)'
seems to do nothing.

If instead you use `d' to step through the debugger, so that the first
sexp (the call to `modify-frame-parameters) is stepped through, then
there is no problem - the frame gets the proper size because of that
call.  It is as if the call to `modify-frame-parameters' is ignored
(or optimized away?), unless the debugger steps through it.


RECIPE 1:

1. runemacs.exe -Q --debug-init -l "/PATH/TO/test-thumb.el"

2. Optional, to see frame parameters using `C-o' (command `foo', at end
   of file): `C-x 5 b *Messages*'.

3. With buffer *scratch* selected (focused): `C-z', to thumbify.
   Then `c' to skip through the debugger.

4. `C-z', to dethumbify.

5. Repeat #3 and #4 as many times as you like.  No problem, so far.

6. With the frame normal size (dethumbified), manually (e.g., with
   the mouse) resize it to reduce the height noticeably.

7. `C-z', to thumbify.  Use `c' to skip through the debugger.

You will see that the thumbified height (e.g. aspect ratio) reflects
what the unthumbified height had.  This is the bug.  The thumbnail
should be the same as before - its height should not change.

The call to `enlarge-font' just before that `modify-frame-parameters'
shrinks the frame proportionately, so after manually reducing the
height, the result is a similarly reduced-height thumbnail.  But the
`modify-frame-parameters' that follows `enlarge-font' should correct
this by restoring the set of frame parameters that were recorded from
the first thumbifying.  (They are recorded in frame parameter
`thumfr-non-thumbnail-frame'.)


RECIPE 2: Same as RECIPE 1, but this time, at step 7, step through the
debugger.  You will see that there is no bug - the thumbified frame has
the right height.  The code is correct, I think.  But that call to
`modify-frame-parameters' does not seem to do what it should, unless you
step through it with the debugger.

The behavior without using the debugger at all (e.g., with `(debug)'
commented out) shows the bug too.  The call to `modify-parameters' seems
to be optimized away or otherwise neglects to apply the parameter
changes.  The height parameter (as an example) is left as it was after
the call to `enlarge-font'.

Here is perhaps a clue to the problem: Variable `thumfr-frame-parameters'
has value ((menu-bar-lines . 0)).  If you comment-out that line, to
give it a value of (()), then there is no bug.  You can also uncomment
the commented-out lines, to give it a value of, say,
((tool-bar-lines . 0) (scroll-bar-width . 6) (scroll-bar-height . 6)),
and then there is no bug either.  It seems that it is the presence of
the `menu-bar-lines' sexp that is problematic.

I think this bug was introduced on or before 2014-10-20.  At least
that's when I started seeing similar problems.  Thanks for taking
a look.


In GNU Emacs 25.1.50.1 (i686-pc-mingw32)
 of 2015-12-04
Bzr revision: ffefb6e899fbcdcbd79cb34292d57b7bc3043fcc
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk --enable-checking=yes
 --enable-check-lisp-object-type --without-compress-install 'CFLAGS=-Og
 -ggdb3' LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

Attachment: test-thumb.el
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]