Re: Shouldn't emacs print long lists with newlines?

[martin rudalics <rudalics@gmx.at>]

 >> Since you can now customize 'resize-mini-frames' this restriction no
 >> longer applies (at least not as stated here).
 >
 > FWIW, resize-mini-frames doesn't work very well for me:
 >
 > - at startup it resizes the frame to a one-line frame of maybe 10-20
 >    chars long, which is oddly short.  The length is updated on the fly,
 >    but I find this a bit annoying.  Nothing too serious tho.

You could try to customize 'fit-frame-to-buffer-sizes' for this.

 > - I have my minibuffer frame at the bottom of the screen.  When it grows
 >    to two or more lines, it correctly moves up.  But when it shrinks back
 >    to a single line, it doesn't move back down, so it ends up "near" the
 >    bottom rather than at the bottom.

Attaching a frame to the bottom of the screen is more tricky.  I'm
afraid it wouldn't even help to set the second element of
'fit-frame-to-buffer-margins' to a value that just fits into the
display.

 > The second problem is probably partly linked to the window-manager, but
 > I've found size-varying windows at the bottom of the screen to be poorly
 > handled under X11 in general (not only with the window-manager
 > I'm using), so I think I'd have to move my minibuffer-only frame to the
 > top of the screen to avoid those problem :-(

The solution is to write your own function to (1) resize your frame
less noisily and, once you know its size, (2) make sure the minibuffer
frame's bottom aligns with the bottom of the workarea where it appears
and (3) set 'resize-mini-frames' to that function.

 >>> , so spreading the output on several
 >>>     lines is not always a good solution.  ]
 >
 > So this still holds :-(

It shouldn't since it negatively impacts the design of solutions for
adjustable minibuffer windows.

martin