RE: wanted: someone to integrate frame-resizing code

[Drew Adams]

Stefan wrote:

 > - if special-display-buffer-names or special-display-regexp specifies
 >   specific sizes, it should still be obeyed.

Absolutely. There are several ways this can be done, depending on how the
automatic resizing is implemented.

If the built-in display functions (display-buffer etc.) do the automatic
resizing (my implementation), users can just make sure their
special-display-function (or the function in the
special-display-buffer-names arg) inhibits resizing (a la inhibit-read-only)
when calling display-buffer or whatever.

Or, if we provide separate no-resize versions of the display functions (a la
find-file-noselect), users can just make sure to call one of those.

BTW, the same consideration holds for any other code that resizes a frame to
a specific size. There is nothing special here about "special". :)


 > - resizing existing frames is risky: you want to make sure you don't undo
 >   what the user did manually.  So I'd refrain from doing it except for
 >   frames where the user specifically asked for it.

Yes, we must not undo what the user did. No, resizing existing frames is not
"risky" - we just need to do it only when appropriate, and not step on the
user.

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.

Again, there were a couple corner cases where I had to ensure there was no
resizing upon display: compile and occur are the only ones I encountered,
but there may be others. (I did this just by locally binding an inhibit
variable around the call to display-buffer.)

A sophisticated implementation that corresponds exactly to the requirements
I listed previously might be ideal. But even my simple solution is
preferable (IMO) to restricting users to on-demand resizing. I've used
automatic resizing for years, and never had it conflict with manual
resizing.

And of course, users can turn automatic resizing off. And it doesn't affect
frames with more than one window (resize-frame, as a command, can be used in
multi-window frames: the selected-window is determinant).


 >   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.


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

Reason?

Automatic resizing is just as handy for file buffers. 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). 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. It doesn't matter whether or not a buffer is
associated with a file.

Try it. Ce n'est pas le fil a couper le beurre, mais c'est utile.

BTW, since there is some discussion about word-wrapping lately - We could
choose to make the resizing-inhibit variable buffer-local and inhibit
resizing in long-line, word-wrapping modes.


 >   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.
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.


 > - don't enlarge the frame to be larger than the user's screen (which
might
 >   be significantly smaller than what x-display-pixel-height claims).

The doc string of command shrink-frame-to-fit (resize-frame) explains the
algorithm.

There is a (user-definable) maximum frame height and width. By default,
these limits are calculated relative to the display size and the frame's
character size (based on user-definable max percentages). They can also be
specified absolutely.

There is also a (user-definable) minimum frame height and width for new
non-empty frames.

There is also a (user-definable) minimum frame height and width for new
empty frames. In fact, there are two: one for normal empty frames and one
for special empty frames (default, if no special-frame-function).

The only problem I've had with using x-display-pixel-height/width is when I
run Emacs on a different machine than my display - for instance, if I run
Emacs on a workstation (with a large display), and access it from a laptop
(with a small display). In that case, I just impose an absolute max size,
based on my target display size. I know of no way for Emacs to figure out
what the remote display I'm using is like. If there is a way, we should use
it.

Are there other circumstances where screen size can be "significantly
smaller" than the display? I'm not aware of a better measure of display size
in pixels than x-display-pixel-height/width. If there is one, that should be
used instead.


BTW - I mentioned too, in an earlier mail, that I have not tried this code
with images or a mixture of font sizes. Perhaps some adjustment will be
necessary to accomodate these. The current resizing code uses
set-frame-size. It counts lines and measures maximum line-width (in
characters) to determine the needed frame height (lines) and width (cols).

 - Drew