Re: wanted: someone to integrate frame-resizing code

[Stefan Monnier]

> Even using my simple implementation, I never encountered a problem as a
> user: automatic resizing only takes place when the buffer is displayed (e.g.
> display-buffer), so it's not done after you resize a frame manually.

I regularly (tho not often) do C-x 5  f <somefile> where <somefile> is
already in an open frame.  This basically has the effect of raising that
frame and it should not resize it (even tho it does get "displayed" in the
sense that pop-to-buffer is called on it).
[ I don't distinguish between pop-to-buffer and display-buffer here. ]

>> Maybe you could allow resizing existing frames when they get deiconified,
>> but even that sounds risky.

> No, just the opposite. We do *not* want to resize a frame when it is
> deiconified. A user should be able to manually size a frame, iconify it, do
> some stuff, and deiconify it to exactly the same position and size.  We want
> to automatically resize a frame only when it is displayed.

I meant "deiconified by pop-to-buffer", not manually of course.
[ I don't like to use "displayed" since it doesn't mean anything precise. ]

>> - resizing frames showing the content of a file is probably not a great idea.
> Reason?

None other than my gut feeling.

> Automatic resizing is just as handy for file buffers.

Of course it's true that it's not uncommon to open a file just to look at
it, but if not, a short frame might just turn out inconvenient as soon as
I start adding text to the file.

> You never see wrapped-around or truncated text, and you save a lot of
> manual fiddling, resizing frames (you can still fiddle, if you want).

I never fiddle with the horizontal size of file buffers: if text gets
wrapped around, I want to fix the text, not the frame.

> If I'm editing a short, narrow buffer and I switch to a longer, wider
> buffer, I want the frame to be the right size for the latter.

All my file frames are vertically maximized (and 80 columns).
[ And I virtually never switch buffers in a frame. ]

> It doesn't matter whether or not a buffer is associated with a file.

Could be.  I just know that I currently manage the two very differently,
mostly because I use the two kinds of buffers very differently: in file
buffers, I edit, I move around, etc, whereas in non-file buffers
I generally don't do much more than click on a few things.

>> More generally, if the elisp code doesn't call
>> shrink-window-if-larger-than-buffer, it's likely that the frame's size
>> shouldn't be changed either.

> Not sure I follow you.  This has nothing to do with resizing windows.

Why not?  shrink-window-if-larger-than-buffer is basically the same as you
code, if you consider that it's typically used for single-frame Emacs
instances where Emacs manages all the windows whereas your code works for
multi-frame Emacs instances where the window manager manages the windows
(indirectly by managing the frames).

> Automatic frame resizing is done only when the selected window is alone in
> the frame (one-window-p).  Whether code resizes windows or not is not
> pertinent to what should happen when each window is in its own frame.
> It's a different UI model.

I don't find it very different: Emacs's windows don't overlap, but
otherwise it's pretty similar.

> Are there other circumstances where screen size can be "significantly
> smaller" than the display?

When I connect my 1280x1024 external monitor to my 1024x768 laptop, I get
a virtual screen of 1304x1024 or 1280x1792 pixels (where some are
non-displayed, some are displayed on the laptop's screen and the rest is on
the external monitor).

> I'm not aware of a better measure of display size in pixels than
> x-display-pixel-height/width.

Neither am I.

The above email is not a comment about your code.  It's just some comments
based on my own use pattern.  I don't claim it has any kind of
representative quality.


        Stefan