Re: [Emacs-diffs] /srv/bzr/emacs/trunk r103444: * lisp/facemenu.el (list-colors-display): Use with-help-window (Bug#8048).

[martin rudalics]

> IIUC what the intention is, it assumes that the user wants to fit the buffer 
to
> the window and not vice versa.  In my case (dedicated window in a separate
> frame), I do not want the buffer display to expand to fill the window.  
Instead,
> I want it to remain as compact as practical, and I then fit the frame to the
> buffer.

We are talking about `with-output-to-temp-buffer' based macros here
which (1) erase the buffer, (2) fill it (in the body) with some text,
and (3) call `display-buffer'.  If you "fit the frame to the buffer" in
a separate fourth step, nothing would change for the particular case you
describe.  However, if you do something like

(let ((special-display-buffer-names special-display-buffer-names))
  (with-help-window buffer
    (with-current-buffer buffer
      (insert text)
      (setq special-display-buffer-names ...))))

and specify the frame's height for `special-display-buffer-names' from
the height of the buffer, things would change.  But you can still resize
the frame in a separate step.  The more annoying problem is how to
constrain the window splitting behavior.  Currently you can write

(let ((split-height-threshold split-height-threshold))
  (with-help-window buffer
    (with-current-buffer buffer
      (insert text)
      (setq split-height-threshold
            (* (count-lines (point-min) (point-max)) 2)))))

thus modulating the window splitting behavior of `display-buffer'.  If
we display the buffer _before_ filling it, you can't do such things any
more.

> Since there can be different user preferences and use cases, can you please
> provide for those too when designing such a change (e.g. for the default 
case)?
> IOW, let's not just assume that the window size is to be fixed and
> predetermined, and that the buffer text should be fit to that window size.

martin