RE: frame parameter menu-bar-lines changes height of frame

[Drew Adams]

Hi Eli,

Thanks for your explanation. I understand better now.

I'm fine with this not being fixed before the release. I would ask that it
be fixed soon thereafter, if possible.

If necessary, we can reopen the discussion of what the behavior should be.
To me, it should be like the tool-bar behavior. If that's not possible in
some contexts, then those contexts can be treated specially (do the best we
can to determine menu-bar height etc.).

Showing and hiding the menu-bar should not change the frame size whenever
that is avoidable. There is no reason to reduce everything to the lowest
common denominator, if that denominator is bugged behavior. If the bugged
behavior is sometimes unavoidable, so be it, but let's not use it as the
norm.

Thx - Drew

-----------------

    > You've said that the reason to not fix this now or soon is
    that fixing it
    > would be difficult. Could you explain why menu-bar-lines is
    different from
    > tool-bar-lines in this respect?

    Because, historically, the menu bar was just a line of text at the
    upper edge of the frame (and still is, in the non-toolkit and tty
    builds).  Tool bar was never an integral number of text lines.

    > The latter works correctly. Couldn't the tool-bar-lines
    > implementation (fix) apply also to menu-bar-lines?

    Theoretically, yes.  But even the thread you cited (which started
    about a different issue, and only touched the menu bar tangentially)
    reveals that people are divided on what should be the right behavior.
    There are also other complications, IIRC: the size of the menu bar may
    not be known with some toolkits, so resizing the text area might be
    tricky.

    That is why I don't think we should try to fix this now.  The fact
    that two years have passed (actually much more, since this issue was
    discussed back when Gerd Moellmann was the head maintainer) is
    unfortunate, but I think we will shoot in our foot if we add now as
    yet additional complication in the display-related code.  I fear the
    redisplay-dont-pause changes already complicated things enough, and
    might prolong the pretest.  Emacs had this misfeature for a long time,
    and complaints, if there were any, were minimal.  I think the fix can
    wait a little longer.