bug#15174: 24.3.50; frame shrinks vertically when enlarge or shrink it horizontally

bug#15174: 24.3.50; frame shrinks vertically when enlarge or shrink it horizontally

[Drew Adams]

This bug is very old.  Dunno whether I have reported it before (e.g.,
before the bug tracker was added).  Dunno whether it is related to the
recently reported bug #14627, which reminded me of it.

emacs -Q

Just to make it easier:

(defun enlarge-frame-horizontally (&optional increment frame)
  "Increase the width of FRAME (default: selected-frame) by INCREMENT.
INCREMENT is in columns (characters).
Interactively, it is given by the prefix argument."
  (interactive "p")
  (set-frame-width frame (+ (frame-width frame) increment)))

(global-set-key [(control meta right)] 'enlarge-frame-horizontally)

Choose any frame that is showing a menu bar.  Doesn't matter whether it
is also showing a tool bar.

Use the mouse to make the frame narrow enough that the menu bar wraps to
a second line.

Now try C-M-<right> one or more times.  The frame widens each time, but
it also shrinks vertically (the bug).

The same thing happens if you shrink the frame horizontally - same
uncalled-for vertical shrinking.

Dunno whether this is MS Windows-specific.  It is quite annoying for
someone who both (a) has multiple menu-bar menus and (b) adjusts frame
sizes using the keyboard, which I do.  I guess I've adjusted to the
annoyance over the years - I probably automatically avoid resizing
frames horizontally when they are already narrow enough to make the
menu-bar wrap.

FWIW - There used to be a somewhat similar bug that made the frame move
downward when you resized it.  That was finally fixed long ago.  Dunno
whether this problem or its solution might be related to that one.  That
one too was old enough that there was no bug number for it.

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-08-23 on ODIEONE
Bzr revision: 113986 rgm@gnu.org-20130823185841-zoy6h1qk433ibrlf
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

bug#15174: 24.3.50; frame shrinks vertically when enlarge or shrink it horizontally

[Eli Zaretskii]

severity 15174 wishlist
thanks

> Date: Fri, 23 Aug 2013 20:22:27 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> 
> Use the mouse to make the frame narrow enough that the menu bar wraps to
> a second line.

Just don't do that.  The menu bar is short enough and displays are
wide enough nowadays to make this an improbable situation.

(The technical reason behind the problem is that Emacs doesn't know
enough about the size of the menu bar, which is created by the Windows
window manager.)

bug#15174: 24.3.50; frame shrinks vertically when enlarge or shrink it horizontally

[martin rudalics]

 > emacs -Q
 >
 > Just to make it easier:
 >
 > (defun enlarge-frame-horizontally (&optional increment frame)
 >    "Increase the width of FRAME (default: selected-frame) by INCREMENT.
 > INCREMENT is in columns (characters).
 > Interactively, it is given by the prefix argument."
 >    (interactive "p")
 >    (set-frame-width frame (+ (frame-width frame) increment)))
 >
 > (global-set-key [(control meta right)] 'enlarge-frame-horizontally)
 >
 > Choose any frame that is showing a menu bar.  Doesn't matter whether it
 > is also showing a tool bar.
 >
 > Use the mouse to make the frame narrow enough that the menu bar wraps to
 > a second line.
 >
 > Now try C-M-<right> one or more times.  The frame widens each time, but
 > it also shrinks vertically (the bug).
 >
 > The same thing happens if you shrink the frame horizontally - same
 > uncalled-for vertical shrinking.

Should be fixed now with revision 118172 on trunk.

Thanks, martin

bug#15174: 24.3.50; frame shrinks vertically when enlarge or shrink it horizontally

[Drew Adams]

> Should be fixed now with revision 118172 on trunk.
> Thanks, martin

Thanks, Martin. This will be great. There don't seem to be many
Windows binaries anymore, but I will check this when I can.

I also filed bug #18720 recently, which is related.  That recipe
is from emacs -Q, with a recent snapshot (this month).  That
recipe from emacs -Q involves wrapping the menu-bar twice (so 3
lines to repro, not just 2). But in my own setup I see the same
problem when it is wrapped only twice, for some reason.

I mention #18720 in case you can check that recipe after your
fix for #15174. Perhaps it fixes both (I'm guessing/hoping so).

Thx - Drew

bug#15174: 24.3.50; frame shrinks vertically when enlarge or shrink it horizontally

[martin rudalics]

>> Should be fixed now with revision 118172 on trunk.

Bug closed.

Thanks, martin

bug#15174: 24.3.50; frame shrinks vertically when enlarge or shrink it horizontally

[Drew Adams]

> > Use the mouse to make the frame narrow enough that the menu bar wraps to
> > a second line.
> 
> Just don't do that.  The menu bar is short enough and displays are
> wide enough nowadays to make this an improbable situation.

You can relegate the bug report to the dust bin, if there is no way to
fix the bug now.  I can understand, if that is the case.

But for the record I completely disagree with the attitude or assessment
that you just expressed.

"The menu bar" is not something static, fixed once and for all when
you open the Emacs box.  It can vary wrt mode etc.  And thank goodness
for that.

And "displays are wide enough" pretty much assumes that a frame is meant
to consume lots of horizontal display space.  I don't use frames that
way.  I typically make sure that a frame fits the width of its displayed
buffer (typically one buffer per frame).

Try this, in `emacs -Q': Open a directory in Dired mode.  Hit `(' to
hide details, showing only file names.  Even if you have an extremely
long file name it is no doubt much narrower than the width of the menu
bar:

`File  Edit  Options  Buffers  Tools  Operate  Mark  Regex  Immediate
Subdir  Help'  -- oops, sorry, had to wrap it for this message ;-).
("Just don't do that", indeed.)

Most file names are probably not even half as wide as that menu bar.
"The menu bar is short enough", indeed!

Don't you think some users might not want to waste all that white space
to the right of the file names, by narrowing the frame, leaving room
for something else in their display (another Emacs frame, perhaps)?
Especially if they have a keyboard key that does just that: fits the
frame to the displayed buffer width?

Remember speed-bar?  Oh, we had to make sure it doesn't have a menu
bar or a tool bar, didn't we?  And we its truncate file names too.
Making a virtue out of necessity, perhaps?  But maybe you get the point
that there can be a use case for a frame with less than display-wide
width.

Now if Emacs had more sophisticated graphics support, so that there
were other possibilities besides just a single, rudimentary menu bar
that can only wrap, then there would be no problem.  But we make do
with what we have.

Judging by appearance and behavior, unless I'm not noticing something,
we have the same menu bar in Emacs 24 that we had in Emacs 20 (and
likely before that).  And essentially the same tool bar we had in
Emacs 22, if not 21.

I don't know about the tools (toolkit or whatever) available on MS
Windows for developers to work with, but MS products themselves are
not limited in 2013 to the same appearance and behavior they had in
2000 or 1995 wrt menu bars and tool bars.  Not that MS is super
innovative or the best model, but things have evolved some.

> (The technical reason behind the problem is that Emacs doesn't know
> enough about the size of the menu bar, which is created by the Windows
> window manager.)

And that presumably is the real reason behind your conclusions above
that "the menu bar is short enough" and "displays are wide enough":
As things stand now, the Emacs implementation is just not up to the
task of fixing this bug.

I can understand, if you say that this is a wishlist bug because the
Emacs implementation doesn't currently know how to do any better, or
cannot possibly do better given the building blocks it has to work
with now.

But it is a cop-out to blame that limitation on "the Windows window
manager", as far as I can tell.

Right now I'm using an MS Windows application from several years ago,
Outlook 2007, and there is no such limitation wrt its menu bar or any
of the other stuff it puts near the top of the "frame" (tool bar,
ribbon, whatever).

The menu bar in this and other MS Windows applications never wraps at
all, no matter how severely you narrow the frame.  Instead, its entries
are gracefully abbreviated when horizontal space is scarce - each gets
truncated separately.  And the menu bar, tool bar, etc. disappear
altogether when there is insufficient room.

This appearance and behavior too are presumably based on "the Windows
window manager", and they are completely different from what we have
with Emacs.

So OK, if we can't get this fixed now then it must go to the wishlist,
for another decade or two, perhaps.

But please, let's not pretend that the reason is either that (a) the
menu bar is always sufficiently narrow and displays are sufficiently
wide that wrapping is "an improbable situation" or (b) that's just
the way "the Windows window manager" is.

If our implementation is limited by the tools we currently have
available to build it, then fine - let's just say that.  Forget the
it's-not-a-problem-AND-anyway-it's-Microsoft's-fault refrain.