GNU bug report logs - #14627
24.2; Vertical frame size shrinking

Previous Next

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

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

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

From: Karl Brodowsky <bk1 <at> gmx.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.2; Vertical frame size shrinking
Date: Sat, 15 Jun 2013 16:22:01 +0200

In GNU Emacs 24.2.1 (x86_64-suse-linux-gnu, GTK+ Version 3.6.4)
 of 2013-02-21 on build16
Windowing system distributor `The X.Org Foundation', version 11.0.11302000
Configured using:
 `configure '--with-pop' '--without-hesiod' '--with-kerberos'
 '--with-kerberos5' '--with-xim' '--with-wide-int' '--enable-autodepend'
 '--prefix=/usr' '--mandir=/usr/share/man' '--infodir=/usr/share/info'
 '--datadir=/usr/share' '--localstatedir=/var'
 '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib' '--with-x'
 '--with-sound' '--with-sync-input' '--with-xpm' '--with-jpeg'
 '--with-tiff' '--with-gif' '--with-png' '--with-rsvg' '--with-dbus'
 '--without-gpm' '--with-x-toolkit=gtk3' '--x-includes=/usr/include'
 '--x-libraries=/usr/lib64:/usr/share/X11' '--with-xft' '--with-libotf'
 '--with-m17n-flt' '--build=x86_64-suse-linux'
 'build_alias=x86_64-suse-linux' 'CFLAGS=-fmessage-length=0 -O2 -Wall
 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables
 -fasynchronous-unwind-tables -g -D_GNU_SOURCE -std=gnu89 -pipe
 -Wno-pointer-sign -Wno-unused-variable -Wno-unused-label
 -Wno-unprototyped-calls -fno-optimize-sibling-calls
 -DSYSTEM_PURESIZE_EXTRA=55000 -DSITELOAD_PURESIZE_EXTRA=10000 '
 'LDFLAGS=-Wl,-O2 -Wl,--hash-size=65521''

uname -a
Linux <hostname> 3.7.10-1.11-desktop #1 SMP PREEMPT Thu May 16 20:27:27
UTC 2013 (adf31bb) x86_64 x86_64 x86_64 GNU/Linux

lsb-release -a
LSB Version:    n/a
Distributor ID:    openSUSE project
Description:    openSUSE 12.3 (x86_64)
Release:    12.3
Codename:    Dartmouth


Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: POSIX
  value of $LC_TIME: nil
  value of $LANG: C
  value of $XMODIFIERS: @im=local
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  shell-dirtrack-mode: t
  show-paren-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
~bk1/etc/emacs/scala-mode-auto hides ~bk1/etc/emacs/scala/scala-mode-auto
~bk1/etc/emacs/scala-mode-indent hides
~bk1/etc/emacs/scala/scala-mode-indent
~bk1/etc/emacs/scala-mode-ui hides ~bk1/etc/emacs/scala/scala-mode-ui
~bk1/etc/emacs/scala-mode-feature-tags hides
~bk1/etc/emacs/scala/scala-mode-feature-tags
~bk1/etc/emacs/scala-mode hides ~bk1/etc/emacs/scala/scala-mode
~bk1/etc/emacs/scala-mode-feature-speedbar hides
~bk1/etc/emacs/scala/scala-mode-feature-speedbar
~bk1/etc/emacs/scala-mode-feature-electric hides
~bk1/etc/emacs/scala/scala-mode-feature-electric
~bk1/etc/emacs/scala-mode-navigation hides
~bk1/etc/emacs/scala/scala-mode-navigation
~bk1/etc/emacs/scala-mode-constants hides
~bk1/etc/emacs/scala/scala-mode-constants
~bk1/etc/emacs/scala-mode-lib hides ~bk1/etc/emacs/scala/scala-mode-lib
~bk1/etc/emacs/scala-mode-variables hides
~bk1/etc/emacs/scala/scala-mode-variables
~bk1/etc/emacs/scala-mode-fontlock hides
~bk1/etc/emacs/scala/scala-mode-fontlock
~bk1/etc/emacs/scala-mode-feature hides
~bk1/etc/emacs/scala/scala-mode-feature
~bk1/etc/emacs/scala-mode-inf hides ~bk1/etc/emacs/scala/scala-mode-inf
~bk1/etc/emacs/maple hides /usr/share/emacs/site-lisp/maple
~bk1/etc/emacs/psvn hides /usr/share/emacs/site-lisp/psvn
~bk1/etc/emacs/finder-inf hides /usr/share/emacs/24.2/lisp/finder-inf
~bk1/etc/emacs/comint hides /usr/share/emacs/24.2/lisp/comint
~bk1/etc/emacs/cyrillic hides /usr/share/emacs/24.2/lisp/language/cyrillic

Features:
(shadow sort gnus-util mail-extr warnings 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 mail-prsvr mail-utils cc-mode cc-fonts cc-guess cc-menus cc-cmds
cc-styles cc-align cc-engine cc-vars cc-defs tabify nxml-uchnm rng-xsd
xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc rng-uri rng-parse
nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns nxml-mode
nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc xmltok dired-aux sql
thingatpt mule-util grep compile dabbrev rect shell pcomplete comint
ring locate dired regexp-opt help-mode easymenu view misearch
multi-isearch vc-git server k-iso-insert iso-insert extra-konvers
asc2iso konvers xxx-konvers iso-konvers ws-minor ws-markerfun
ws-searchfun latin-1 cmode-extra hilit19 meta-arrow shift-arrow paren
preview-latex tex-site auto-loads ispell time-date delsel lpr disp-table
tooltip ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar
dnd fontset image fringe lisp-mode register page menu-bar rfn-eshadow
timer select scroll-bar mouse jit-lock font-lock syntax facemenu
font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face files text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

What I do:
start emacs
maximize the window
split with C-x 3
open a directory with C-x C-f /tmp
click on left and right half of emacs
The height of my emacs frame shrinks a little bit every time I do so, so
I am loosing about one line of text when clicking to the left half and
back to the right half.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Karl Brodowsky <bk1 <at> gmx.net>
Cc: 14627 <at> debbugs.gnu.org
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Mon, 19 Aug 2013 20:56:14 +0200

Hello.

15 jun 2013 kl. 16:22 skrev Karl Brodowsky <bk1 <at> gmx.net>:

> 
> What I do:
> start emacs
> maximize the window
> split with C-x 3
> open a directory with C-x C-f /tmp
> click on left and right half of emacs
> The height of my emacs frame shrinks a little bit every time I do so, so
> I am loosing about one line of text when clicking to the left half and
> back to the right half.

I can't reproduce this on OpenSuse 12.3, with 24.2 or the trunk.
What dont do you use, and what is your screen size?
You did not mention what window manager you run, I used kwin. 

	Jan D.
 

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Karl Brodowsky <bk1 <at> gmx.net>
Cc: "14627 <at> debbugs.gnu.org" <14627 <at> debbugs.gnu.org>
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Mon, 19 Aug 2013 21:15:29 +0200

Aargh...

19 aug 2013 kl. 20:56 skrev Jan Djärv <jan.h.d <at> swipnet.se>:

> Hello.
> 
> 15 jun 2013 kl. 16:22 skrev Karl Brodowsky <bk1 <at> gmx.net>:
> 
>> 
>> What I do:
>> start emacs
>> maximize the window
>> split with C-x 3
>> open a directory with C-x C-f /tmp
>> click on left and right half of emacs
>> The height of my emacs frame shrinks a little bit every time I do so, so
>> I am loosing about one line of text when clicking to the left half and
>> back to the right half.
> 
> I can't reproduce this on OpenSuse 12.3, with 24.2 or the trunk.
> What dont do you use, and what is

  dont -> font

> your screen size?
> You did not mention what window manager you run, I used kwin. 
> 
>    Jan D.
> 
> 
> 

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Thu, 22 Aug 2013 13:32:30 +0200

On Mon, 19 Aug 2013 20:56:14 +0200 Jan Djärv <jan.h.d <at> swipnet.se> wrote:

> Hello.
>
> 15 jun 2013 kl. 16:22 skrev Karl Brodowsky <bk1 <at> gmx.net>:
>
>> 
>> What I do:
>> start emacs
>> maximize the window
>> split with C-x 3
>> open a directory with C-x C-f /tmp
>> click on left and right half of emacs
>> The height of my emacs frame shrinks a little bit every time I do so, so
>> I am loosing about one line of text when clicking to the left half and
>> back to the right half.
>
> I can't reproduce this on OpenSuse 12.3, with 24.2 or the trunk.
> What dont do you use, and what is your screen size?
> You did not mention what window manager you run, I used kwin. 

I don't see the shrinking with the OP's recipe, but I do see it if,
instead of `C-x C-f /tmp RET', I do `C-h i' to open Info: switching
between the Info and scratch windows shrinks the maximized frame
vertically.

In GNU Emacs 24.3.50.3 (x86_64-suse-linux-gnu, GTK+ Version 3.4.4)
 of 2013-08-07 on rosalinde
Bzr revision: 113738 eliz <at> gnu.org-20130807151423-mhw4d72032gg0eho
Windowing system distributor `The X.Org Foundation', version 11.0.11203000
System Description:	openSUSE 12.2 (x86_64)

Qt: 4.8.4
KDE Development Platform: 4.9.5 "release 4"
KWin: 4.9.5 "release 4"

Configured using:
 `configure --without-toolkit-scroll-bars CFLAGS=-g3 -O0'

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Steve Berman
(I may not be able to follow up for a week or so.)

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Thu, 22 Aug 2013 13:51:33 +0200

On Thu, 22 Aug 2013 13:32:30 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Mon, 19 Aug 2013 20:56:14 +0200 Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>
>> Hello.
>>
>> 15 jun 2013 kl. 16:22 skrev Karl Brodowsky <bk1 <at> gmx.net>:
>>
>>> 
>>> What I do:
>>> start emacs
>>> maximize the window
>>> split with C-x 3
>>> open a directory with C-x C-f /tmp
>>> click on left and right half of emacs
>>> The height of my emacs frame shrinks a little bit every time I do so, so
>>> I am loosing about one line of text when clicking to the left half and
>>> back to the right half.
>>
>> I can't reproduce this on OpenSuse 12.3, with 24.2 or the trunk.
>> What dont do you use, and what is your screen size?
>> You did not mention what window manager you run, I used kwin. 
>
> I don't see the shrinking with the OP's recipe, but I do see it if,
> instead of `C-x C-f /tmp RET', I do `C-h i' to open Info: switching
> between the Info and scratch windows shrinks the maximized frame
> vertically.
>
> In GNU Emacs 24.3.50.3 (x86_64-suse-linux-gnu, GTK+ Version 3.4.4)
>  of 2013-08-07 on rosalinde
> Bzr revision: 113738 eliz <at> gnu.org-20130807151423-mhw4d72032gg0eho
> Windowing system distributor `The X.Org Foundation', version 11.0.11203000
> System Description:	openSUSE 12.2 (x86_64)
>
> Qt: 4.8.4
> KDE Development Platform: 4.9.5 "release 4"
> KWin: 4.9.5 "release 4"
>
> Configured using:
>  `configure --without-toolkit-scroll-bars CFLAGS=-g3 -O0'
>
> Important settings:
>   value of $LANG: en_US.UTF-8
>   value of $XMODIFIERS: @im=local
>   locale-coding-system: utf-8-unix
>   default enable-multibyte-characters: t
>
> Steve Berman
> (I may not be able to follow up for a week or so.)

One quick followup: the shrinking happens with (at least) this font:

xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Thu, 22 Aug 2013 13:59:59 +0200

On Thu, 22 Aug 2013 13:51:33 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:

> On Thu, 22 Aug 2013 13:32:30 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>
>> On Mon, 19 Aug 2013 20:56:14 +0200 Jan Djärv <jan.h.d <at> swipnet.se> wrote:
>>
>>> Hello.
>>>
>>> 15 jun 2013 kl. 16:22 skrev Karl Brodowsky <bk1 <at> gmx.net>:
>>>
>>>> 
>>>> What I do:
>>>> start emacs
>>>> maximize the window
>>>> split with C-x 3
>>>> open a directory with C-x C-f /tmp
>>>> click on left and right half of emacs
>>>> The height of my emacs frame shrinks a little bit every time I do so, so
>>>> I am loosing about one line of text when clicking to the left half and
>>>> back to the right half.
>>>
>>> I can't reproduce this on OpenSuse 12.3, with 24.2 or the trunk.
>>> What dont do you use, and what is your screen size?
>>> You did not mention what window manager you run, I used kwin. 
>>
>> I don't see the shrinking with the OP's recipe, but I do see it if,
>> instead of `C-x C-f /tmp RET', I do `C-h i' to open Info: switching
>> between the Info and scratch windows shrinks the maximized frame
>> vertically.
>>
>> In GNU Emacs 24.3.50.3 (x86_64-suse-linux-gnu, GTK+ Version 3.4.4)
>>  of 2013-08-07 on rosalinde
>> Bzr revision: 113738 eliz <at> gnu.org-20130807151423-mhw4d72032gg0eho
>> Windowing system distributor `The X.Org Foundation', version 11.0.11203000
>> System Description:	openSUSE 12.2 (x86_64)
>>
>> Qt: 4.8.4
>> KDE Development Platform: 4.9.5 "release 4"
>> KWin: 4.9.5 "release 4"
>>
>> Configured using:
>>  `configure --without-toolkit-scroll-bars CFLAGS=-g3 -O0'
>>
>> Important settings:
>>   value of $LANG: en_US.UTF-8
>>   value of $XMODIFIERS: @im=local
>>   locale-coding-system: utf-8-unix
>>   default enable-multibyte-characters: t
>>
>> Steve Berman
>> (I may not be able to follow up for a week or so.)
>
> One quick followup: the shrinking happens with (at least) this font:
>
> xft:-unknown-DejaVu Sans Mono-normal-normal-normal-*-15-*-*-*-m-0-iso10646-1

And another quick followup:

The shrinking does not happen when the tool bar is detached or
tool-bar-mode is turned off.

Steve Berman

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>,
 Jan Djärv <jan.h.d <at> swipnet.se>
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Thu, 22 Aug 2013 14:15:55 +0200

> I don't see the shrinking with the OP's recipe, but I do see it if,
> instead of `C-x C-f /tmp RET', I do `C-h i' to open Info: switching
> between the Info and scratch windows shrinks the maximized frame
> vertically.

Does the frame shrink more and more when you repeatedly switch to info?
Or does it shrink just once and stick to that size afterwards?

martin

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>,
 Jan Djärv <jan.h.d <at> swipnet.se>
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Thu, 22 Aug 2013 14:25:43 +0200

On Thu, 22 Aug 2013 14:15:55 +0200 martin rudalics <rudalics <at> gmx.at> wrote:

>> I don't see the shrinking with the OP's recipe, but I do see it if,
>> instead of `C-x C-f /tmp RET', I do `C-h i' to open Info: switching
>> between the Info and scratch windows shrinks the maximized frame
>> vertically.
>
> Does the frame shrink more and more when you repeatedly switch to info?
> Or does it shrink just once and stick to that size afterwards?
>
> martin

It keeps shrinking (window-height decreases by one each time), until the
minibuffer is no longer displayable, then it stops shrinking.

Steve Berman

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>,
 Jan Djärv <jan.h.d <at> swipnet.se>
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 09:10:16 +0200

> It keeps shrinking (window-height decreases by one each time), until the
> minibuffer is no longer displayable, then it stops shrinking.

I think we have two bugs here:

(1) A maximized frame should never shrink due to a font change.

(2) There seems to be a rounding error present which always chooses to
    shrink the frame when changing the toolbar size.

If Jan does not find the cause of these, maybe someone who can reproduce
the problem could step in so we can debug it?

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14627 <at> debbugs.gnu.org, bk1 <at> gmx.net, stephen.berman <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 11:20:34 +0300

> Date: Fri, 23 Aug 2013 09:10:16 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>
> 
> I think we have two bugs here:

I think we have three.

> (1) A maximized frame should never shrink due to a font change.
> 
> (2) There seems to be a rounding error present which always chooses to
>      shrink the frame when changing the toolbar size.

 (3) Why does a frame change its size when one clicks on it?

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14627 <at> debbugs.gnu.org, bk1 <at> gmx.net, stephen.berman <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 10:55:38 +0200

>  (3) Why does a frame change its size when one clicks on it?

The OP says that he clicks "to the left half and back to the right half"
which here translates to switches from one window to the other.
Together with Stephen's observations this seems to indicate that the
toolbar contents change, probably with a different default font.  And
since Emacs can change the frame size when changing a font size ...

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14627 <at> debbugs.gnu.org, bk1 <at> gmx.net, stephen.berman <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 12:25:41 +0300

> Date: Fri, 23 Aug 2013 10:55:38 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: stephen.berman <at> gmx.net, 14627 <at> debbugs.gnu.org, bk1 <at> gmx.net
> 
>  >  (3) Why does a frame change its size when one clicks on it?
> 
> The OP says that he clicks "to the left half and back to the right half"
> which here translates to switches from one window to the other.
> Together with Stephen's observations this seems to indicate that the
> toolbar contents change, probably with a different default font.  And
> since Emacs can change the frame size when changing a font size ...

The toolbar displays no text (at least on my system), only images, so
font size should have no significance, only the sizes of the images
should matter.  And why would the _default_ font size in two windows
of the same frame be different, anyway, when the recipe includes no
commands that should have any effect on the font?

Anyway, does the toolbar really change its size in this recipe?  It
doesn't on my system.

So sorry, but I still think there's some mystery here.  Putting a
breakpoint in the relevant primitives and showing the C and Lisp
backtraces when those break might show what am I missing.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14627 <at> debbugs.gnu.org, bk1 <at> gmx.net, stephen.berman <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 12:21:25 +0200

> The toolbar displays no text (at least on my system), only images, so
> font size should have no significance, only the sizes of the images
> should matter.

IIUC when I change the default font size on Windows, the frame's line
height changes and the pixel size of the toolbar changes too.  On
Windows this won't matter, but when an external toolbar changes size it
might and trigger the rounding effect I mentioned earlier.  But maybe
you're right and it's the images that change size.

> And why would the _default_ font size in two windows
> of the same frame be different, anyway, when the recipe includes no
> commands that should have any effect on the font?

More so because windows don't have a default face.  The OP uses cyrillic
and Stephen invokes Info, could these give a clue?  Can face remapping
or buffer local faces have any impact?

> Anyway, does the toolbar really change its size in this recipe?  It
> doesn't on my system.

According to Stephen the toolbar matters.  I don't know about the OP but
at least he has `tool-bar-mode' turned on.

> So sorry, but I still think there's some mystery here.  Putting a
> breakpoint in the relevant primitives and showing the C and Lisp
> backtraces when those break might show what am I missing.

Right.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14627 <at> debbugs.gnu.org, bk1 <at> gmx.net, stephen.berman <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 13:33:23 +0300

> Date: Fri, 23 Aug 2013 12:21:25 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: stephen.berman <at> gmx.net, 14627 <at> debbugs.gnu.org, bk1 <at> gmx.net
> 
>  > The toolbar displays no text (at least on my system), only images, so
>  > font size should have no significance, only the sizes of the images
>  > should matter.
> 
> IIUC when I change the default font size on Windows, the frame's line
> height changes and the pixel size of the toolbar changes too.  On
> Windows this won't matter, but when an external toolbar changes size it
> might and trigger the rounding effect I mentioned earlier.  But maybe
> you're right and it's the images that change size.

If the toolbar is not drawn by Emacs (a.k.a. "external toolbar"), how
can any changes in Emacs's default font change the size of the
toolbar?  I'd need to see a recipe for that, and also some explanation
from someone who understands how that external toolbar works and what,
if anything, does its size have to do with the Emacs fonts.

>  > And why would the _default_ font size in two windows
>  > of the same frame be different, anyway, when the recipe includes no
>  > commands that should have any effect on the font?
> 
> More so because windows don't have a default face.

??? Of course, they do: they start with the frame's defaults.

> The OP uses cyrillic and Stephen invokes Info, could these give a
> clue?

I don't think so, certainly not with Info.

> Can face remapping or buffer local faces have any impact?

Yes, they can.  But the recipe didn't include any face remapping.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14627 <at> debbugs.gnu.org, bk1 <at> gmx.net, stephen.berman <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 12:46:01 +0200

>> More so because windows don't have a default face.
>
> ??? Of course, they do: they start with the frame's defaults.

What I wanted to state here is that two windows on the same frame can't
have different default faces.

>> The OP uses cyrillic and Stephen invokes Info, could these give a
>> clue?
>
> I don't think so, certainly not with Info.

Info has a special toolbar.

martin

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14627 <at> debbugs.gnu.org, bk1 <at> gmx.net, stephen.berman <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 14:10:38 +0300

> Date: Fri, 23 Aug 2013 12:46:01 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: stephen.berman <at> gmx.net, 14627 <at> debbugs.gnu.org, bk1 <at> gmx.net
> 
>  >> The OP uses cyrillic and Stephen invokes Info, could these give a
>  >> clue?
>  >
>  > I don't think so, certainly not with Info.
> 
> Info has a special toolbar.

Right, but we already talked about that: only image sizes can change
the toolbar's size.

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: martin rudalics <rudalics <at> gmx.at>, bk1 <at> gmx.net, stephen.berman <at> gmx.net,
 14627 <at> debbugs.gnu.org
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 18:22:16 +0200

Hello.

23 aug 2013 kl. 13:10 skrev Eli Zaretskii <eliz <at> gnu.org>:

>> Date: Fri, 23 Aug 2013 12:46:01 +0200
>> From: martin rudalics <rudalics <at> gmx.at>
>> CC: stephen.berman <at> gmx.net, 14627 <at> debbugs.gnu.org, bk1 <at> gmx.net
>> 
>>>> The OP uses cyrillic and Stephen invokes Info, could these give a
>>>> clue?
>>> 
>>> I don't think so, certainly not with Info.
>> 
>> Info has a special toolbar.
> 
> Right, but we already talked about that: only image sizes can change
> the toolbar's size.

In 99 cases out of 100 these cases are due to either the inherent race in wm_size_hints or bugs in the window manager.  In this case it is probably the latter.

I suspect the tool bar changes for the OP.  That makes Emacs send new wm_size_hints to the window manager, telling it what the base- and increment sizes are.  If the tool bar changes, the base size changes (the size not counted against resize increments, i.e. font size).  Normally a window manager shall then make sure Emacs frame has the appropriate size, i.e.

    height = base_y + inc_y * n

where n is an integer.

But in this case the frame is maximized, so the window manager should do nothing, like all other window managers.

A possible workaround is not to update size hints when Emacs is maximized or fullscreen.

	Jan D.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: rudalics <at> gmx.at, bk1 <at> gmx.net, stephen.berman <at> gmx.net, 14627 <at> debbugs.gnu.org
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 20:39:23 +0300

> From: Jan Djärv <jan.h.d <at> swipnet.se>
> Date: Fri, 23 Aug 2013 18:22:16 +0200
> Cc: martin rudalics <rudalics <at> gmx.at>,
>  14627 <at> debbugs.gnu.org,
>  bk1 <at> gmx.net,
>  stephen.berman <at> gmx.net
> 
> A possible workaround is not to update size hints when Emacs is maximized or fullscreen.

I think we should take that workaround.

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

From: Karl Brodowsky <bk1 <at> gmx.net>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 stephen.berman <at> gmx.net, 14627 <at> debbugs.gnu.org
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 19:55:28 +0200

| A possible workaround is not to update size hints when Emacs is
maximized or fullscreen. Jan D.
Since this seems to be an issue with KDE4, which is not so uncommon as
window manager, I would agree.

Karl

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

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14627 <at> debbugs.gnu.org, bk1 <at> gmx.net,
 Jan Djärv <jan.h.d <at> swipnet.se>, stephen.berman <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 19:55:07 +0200

>> A possible workaround is not to update size hints when Emacs is maximized or fullscreen.
>
> I think we should take that workaround.

I'm afraid this won't help always.  According to Stephen the frame
"keeps shrinking (window-height decreases by one each time), until the
minibuffer is no longer displayable, then it stops shrinking".  So in
his case the frame has ceased to be maximized for quite some time.

martin

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14627 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stephen.berman <at> gmx.net,
 bk1 <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 19:58:13 +0200

Hello.

23 aug 2013 kl. 19:55 skrev martin rudalics <rudalics <at> gmx.at>:

> >> A possible workaround is not to update size hints when Emacs is maximized or fullscreen.
> >
> > I think we should take that workaround.
> 
> I'm afraid this won't help always.  According to Stephen the frame
> "keeps shrinking (window-height decreases by one each time), until the
> minibuffer is no longer displayable, then it stops shrinking".  So in
> his case the frame has ceased to be maximized for quite some time.

I don't understand your reasoning.  If we prevent the shrinking from maximized, how is that not solving the problem?

	Jan D.

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

From: Karl Brodowsky <bk1 <at> gmx.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14627 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Jan Djärv <jan.h.d <at> swipnet.se>, stephen.berman <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 20:02:44 +0200

On 08/23/13 19:55, martin rudalics wrote:
> >> A possible workaround is not to update size hints when Emacs is
> maximized or fullscreen.
> >
> > I think we should take that workaround.
>
> I'm afraid this won't help always.  According to Stephen the frame
> "keeps shrinking (window-height decreases by one each time), until the
> minibuffer is no longer displayable, then it stops shrinking".  So in
> his case the frame has ceased to be maximized for quite some time.
But if the first shrink moves Emacs out of the "maximized" state, then
this should
help, because the first shrink would not happen.

But for non-maximized-emacs-frames the issue remains.

Karl

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

From: martin rudalics <rudalics <at> gmx.at>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 14627 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stephen.berman <at> gmx.net,
 bk1 <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 20:06:23 +0200

> I don't understand your reasoning.  If we prevent the shrinking from maximized, how is that not solving the problem?

Because apparently a frame may shrink in a non-maximized state too
(maybe maximization is always needed to trigger the process but I
wouldn't be sure).

martin

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

From: martin rudalics <rudalics <at> gmx.at>
To: Karl Brodowsky <bk1 <at> gmx.net>
Cc: 14627 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Jan Djärv <jan.h.d <at> swipnet.se>, stephen.berman <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 20:06:28 +0200

> But for non-maximized-emacs-frames the issue remains.

Can you produce the shrinking in a non-maximized state?

martin

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

From: Karl Brodowsky <bk1 <at> gmx.net>
To: martin rudalics <rudalics <at> gmx.at>, Jan Djärv
 <jan.h.d <at> swipnet.se>
Cc: 14627 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, stephen.berman <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 23 Aug 2013 20:14:36 +0200

On 08/23/13 20:06, martin rudalics wrote:
>> But for non-maximized-emacs-frames the issue remains.
>
> Can you produce the shrinking in a non-maximized state?
No, in non-maximized state it behaves well.

If it is no maximized, but using up the whole height (or as much as I
can use up), I see a shrinking by one line and then it remains stable,
with some flickering, or let's say shrinking and growing by a few
pixels, but in the end when I click back and forth many times there is
no major change in size observable.

Karl

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Karl Brodowsky <bk1 <at> gmx.net>
Cc: martin rudalics <rudalics <at> gmx.at>, Eli Zaretskii <eliz <at> gnu.org>,
 stephen.berman <at> gmx.net, 14627 <at> debbugs.gnu.org
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Sat, 24 Aug 2013 10:45:09 +0200

Hello.

23 aug 2013 kl. 19:55 skrev Karl Brodowsky <bk1 <at> gmx.net>:

> | A possible workaround is not to update size hints when Emacs is
> maximized or fullscreen. Jan D.
> Since this seems to be an issue with KDE4, which is not so uncommon as
> window manager, I would agree.
> 

I've checked in the workaround.  As I haven't seen the problem I don't know if it does anything, so please test it.

Thanks,

	Jan D.

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

From: martin rudalics <rudalics <at> gmx.at>
To: Karl Brodowsky <bk1 <at> gmx.net>
Cc: 14627 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Jan Djärv <jan.h.d <at> swipnet.se>, stephen.berman <at> gmx.net
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Sat, 24 Aug 2013 10:55:34 +0200

> If it is no maximized, but using up the whole height (or as much as I
> can use up), I see a shrinking by one line and then it remains stable,
> with some flickering, or let's say shrinking and growing by a few
> pixels, but in the end when I click back and forth many times there is
> no major change in size observable.

Do the behaviors you describe (maximized/non-maximized) occur when you
turn off `tool-bar-mode'?  If so, does the toolbar change its contents
and/or height when you switch windows?  Does it occur when you use C-x o
instead of clicking with the mouse?  Does the toolbar change when both
windows display the same buffer?  Can you reproduce the behavior with
emacs -Q?  Can you see the behavior described by Stephen in this thread?

martin

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>,
 Eli Zaretskii <eliz <at> gnu.org>, martin rudalics <rudalics <at> gmx.at>
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Sun, 08 Sep 2013 23:09:53 +0200

On Sat, 24 Aug 2013 10:45:09 +0200 Jan Djärv <jan.h.d <at> swipnet.se> wrote:

> Hello.
>
> 23 aug 2013 kl. 19:55 skrev Karl Brodowsky <bk1 <at> gmx.net>:
>
>> | A possible workaround is not to update size hints when Emacs is
>> maximized or fullscreen. Jan D.
>> Since this seems to be an issue with KDE4, which is not so uncommon as
>> window manager, I would agree.
>> 
>
> I've checked in the workaround.  As I haven't seen the problem I don't know if
> it does anything, so please test it.

I've now updated and confirm that with the recipe I gave -- frame
maximized with side by side windows, one containing an Info buffer --
switching between the windows no longer causes the frame to shrink
vertically.  The only oddity is that when the Info buffer is selected
there is an empty space the width of the frame one line high below the
minibuffer.

However, there is still a shrinking problem.  In KDE clicking the
frame's (i.e. WM window's) maximize button with mouse-2 instead of
mouse-1 maximizes the frame vertically but not horizontally.  When I do
this, then split windows (either vertically or horizontally), open an
Info buffer in one window and switch between the windows, then the frame
still (i.e. even with your patch) shrinks vertically by one line for
each switch back to the Info buffer.  If I drag the border of an
unmaximized frame to make it vertically fill the desktop and repeat the
recipe, no shrinking occurs.  And if I maximize the frame horizontally
by clicking the maximize button with mouse-3 and repeat the recipe,
there is also no shrinking.

Steve Berman

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>,
 Jan Djärv <jan.h.d <at> swipnet.se>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Mon, 09 Sep 2013 14:00:33 +0200

> The only oddity is that when the Info buffer is selected
> there is an empty space the width of the frame one line high below the
> minibuffer.

Which disappears when you demaximize the frame, I suppose.

> However, there is still a shrinking problem.  In KDE clicking the
> frame's (i.e. WM window's) maximize button with mouse-2 instead of
> mouse-1 maximizes the frame vertically but not horizontally.  When I do
> this, then split windows (either vertically or horizontally), open an
> Info buffer in one window and switch between the windows, then the frame
> still (i.e. even with your patch) shrinks vertically by one line for
> each switch back to the Info buffer.  If I drag the border of an
> unmaximized frame to make it vertically fill the desktop and repeat the
> recipe, no shrinking occurs.  And if I maximize the frame horizontally
> by clicking the maximize button with mouse-3 and repeat the recipe,
> there is also no shrinking.

IIUC in his patch Jan fixed only the fully maximized and the fullscreen
cases.  So what you see is the old behavior for the partially maximized
case.

martin

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>,
 Jan Djärv <jan.h.d <at> swipnet.se>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Mon, 09 Sep 2013 14:23:47 +0200

On Mon, 09 Sep 2013 14:00:33 +0200 martin rudalics <rudalics <at> gmx.at> wrote:

>> The only oddity is that when the Info buffer is selected
>> there is an empty space the width of the frame one line high below the
>> minibuffer.
>
> Which disappears when you demaximize the frame, I suppose.

If I demaximize the frame while the Info buffer is selected and the
empty line is displayed, then the latter remains visible.  But it
disappears after switching to the other buffer, and, with the frame
demaximized, when I switch back to the Info buffer again, it now no
longer reappears.  Moreover, if I now maximize the frame again, with the
same window configuration, the empty line still doesn't reappear.  In
fact, it turns out that it only appears if I maximize the frame before
opening Info the first time; if I then kill the Info buffer with the
frame still maximized and then open Info again, the empty line no longer
appears.

>> However, there is still a shrinking problem.  In KDE clicking the
>> frame's (i.e. WM window's) maximize button with mouse-2 instead of
>> mouse-1 maximizes the frame vertically but not horizontally.  When I do
>> this, then split windows (either vertically or horizontally), open an
>> Info buffer in one window and switch between the windows, then the frame
>> still (i.e. even with your patch) shrinks vertically by one line for
>> each switch back to the Info buffer.  If I drag the border of an
>> unmaximized frame to make it vertically fill the desktop and repeat the
>> recipe, no shrinking occurs.  And if I maximize the frame horizontally
>> by clicking the maximize button with mouse-3 and repeat the recipe,
>> there is also no shrinking.
>
> IIUC in his patch Jan fixed only the fully maximized and the fullscreen
> cases.  So what you see is the old behavior for the partially maximized
> case.

That's also what I assumed.

Steve Berman

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

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>, Jan Djärv
 <jan.h.d <at> swipnet.se>
Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Fri, 13 Feb 2015 19:23:43 +0100

> I've now updated and confirm that with the recipe I gave -- frame
> maximized with side by side windows, one containing an Info buffer --
> switching between the windows no longer causes the frame to shrink
> vertically.  The only oddity is that when the Info buffer is selected
> there is an empty space the width of the frame one line high below the
> minibuffer.

Does this still happen with current trunk/master?

> However, there is still a shrinking problem.  In KDE clicking the
> frame's (i.e. WM window's) maximize button with mouse-2 instead of
> mouse-1 maximizes the frame vertically but not horizontally.  When I do
> this, then split windows (either vertically or horizontally), open an
> Info buffer in one window and switch between the windows, then the frame
> still (i.e. even with your patch) shrinks vertically by one line for
> each switch back to the Info buffer.  If I drag the border of an
> unmaximized frame to make it vertically fill the desktop and repeat the
> recipe, no shrinking occurs.  And if I maximize the frame horizontally
> by clicking the maximize button with mouse-3 and repeat the recipe,
> there is also no shrinking.

And this?

martin

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 14627 <at> debbugs.gnu.org, Karl Brodowsky <bk1 <at> gmx.net>,
 Jan Djärv <jan.h.d <at> swipnet.se>, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Sun, 15 Feb 2015 14:38:12 +0100

On Fri, 13 Feb 2015 19:23:43 +0100 martin rudalics <rudalics <at> gmx.at> wrote:

>> I've now updated and confirm that with the recipe I gave -- frame
>> maximized with side by side windows, one containing an Info buffer --
>> switching between the windows no longer causes the frame to shrink
>> vertically.  The only oddity is that when the Info buffer is selected
>> there is an empty space the width of the frame one line high below the
>> minibuffer.
>
> Does this still happen with current trunk/master?

No, I don't see this now.

>> However, there is still a shrinking problem.  In KDE clicking the
>> frame's (i.e. WM window's) maximize button with mouse-2 instead of
>> mouse-1 maximizes the frame vertically but not horizontally.  When I do
>> this, then split windows (either vertically or horizontally), open an
>> Info buffer in one window and switch between the windows, then the frame
>> still (i.e. even with your patch) shrinks vertically by one line for
>> each switch back to the Info buffer.  If I drag the border of an
>> unmaximized frame to make it vertically fill the desktop and repeat the
>> recipe, no shrinking occurs.  And if I maximize the frame horizontally
>> by clicking the maximize button with mouse-3 and repeat the recipe,
>> there is also no shrinking.
>
> And this?

No, I also see no shrinking problem anymore.

Steve Berman

Message #103 received at 14627-done <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Karl Brodowsky <bk1 <at> gmx.net>,
 Jan Djärv <jan.h.d <at> swipnet.se>,
 Eli Zaretskii <eliz <at> gnu.org>, 14627-done <at> debbugs.gnu.org
Subject: Re: bug#14627: 24.2; Vertical frame size shrinking
Date: Mon, 16 Feb 2015 19:35:58 +0100

>> Does this still happen with current trunk/master?
>
> No, I don't see this now.

[...]

>> And this?
>
> No, I also see no shrinking problem anymore.

Then I close this bug.

Thanks for checking, martin

Previous Next

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