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.