automatic frame-resizing

[Drew Adams]

 > 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

Stefan, your point on not resizing existing frames when raising them by
function is a valid one - I agree 100%.

If automatic frame resizing is added to Emacs, then simply raising an
existing frame (whether iconified, invisible, or already raised) should not
by itself trigger resizing. Resizing should only happen when the buffer in
the frame changes (different buffer or different contents for the same
buffer).

It is not necessary to adopt the sort of implementation of automatic frame
resizing I used, but *if* an implementation is done along those lines (that
is, if the resizing is done in display-buffer and switch-to-buffer), then it
is necessary to modify the C code for display-buffer and switch-to-buffer:
If an existing frame is simply being raised, then do not resize it.

(Pop-to-buffer, switch-to-buffer-other-frame, and
switch-to-buffer-other-window are taken care of by display-buffer;
switch-to-buffer does not use display-buffer, so it needs to be modified
separately.)

I did not try to change any C code: my implementation is a simple Lisp
hack/workaround. I just called the built-in functions from Lisp, doing a
resize-frame afterward (if one-window-p).  I don't know of any way in Lisp
to determine whether an existing frame was in fact reused by display-buffer
or switch-to-buffer. I do at least inhibit resizing in switch-to-buffer
(same frame) in the case where the original buffer and the new buffer are
the same.

So, my code does in fact step on the user by resizing upon programmatic
frame-raise and other pop-to-buffer calls like find-file. Given that I could
not change the C code, I preferred this to giving up automatic resizing for
things like find-file.

For the rest of your remarks - I don't want to belabor this. I already
mentioned that my implementation is a simple one, not ideal. I listed what I
think are the requirements for a more exact solution. I argued for adding
the functionality of automatic frame resizing, not my implementation of
that. (I also argued that my command to resize a frame could be added more
or less as is, independently of any automatic resizing.)

It sounds like your file editing is a special case, though perhaps not
uncommon: you apparently edit mainly files with the same (max) line width,
so you just use an appropriate constant frame width. In general, though,
there are lots of kinds of file, with different (max) line widths or
fill-columns. I believe that it makes as much sense to shrink-wrap a file
frame as a dired, help, info, or any other frame. (And you can always impose
a constant frame width for your file editing, if you like.)

Regarding your concern that a short file frame might be inconvenient for
appending to: a user can establish a minimum frame height in several ways.
You can use the same value you now use for your file frames, if you like.

Thanks,

   Drew

P.S. I simplified some of my code (and renamed shrink-* to resize-*); here
it is:

 - http://www.emacswiki.org/elisp/auto-resize-frames.el
 - http://www.emacswiki.org/elisp/resize-frame.el