Re: FW: fit-frame.el

[Stefan Monnier]

>> but it's far from clear what might be meant by "fit a frame to the
>> current buffer" (unless the current buffer is the only one 
>> shown in the frame, that is).

> What is meant by "fit a frame to the current buffer" is detailed in the doc
> string, starting with "_Fitting a non-empty buffer means_ resizing the frame
> to the smallest size such that the following are both true:".

This description is an algorithm, i.e. code written in English.
Most people are poor at reading such things, because human languages are
very ambiguous and elliptic in nature.  To make the docstring clear,
you'd need at the very least to somehow mark "fit a frame" in some kind
of special way, so people understand that this is a special term with
a very narrow meaning, explained elsewhere.  And even then it's not
clear that by "fit a frame to the current buffer" you really mean
"pretend there's no other window", especially since the resulting
behavior is just really odd.

> Why prohibit a user from using this in situations where it is useful?

Because it's clearly not a finished feature.  It's like a car without
windshield and doors and with a trunk that doesn't close: sure it can
come in handy sometimes, but to most people it's just a broken car.

When the feature is completed we can reconsider it.

>> We might also want to have a variant that only shrinks the frame.
>> Such a variant probably wouldn't need any customization.

> Only shrinks it to what size?

fit-frame can grow or shrink, depending on the situation.  I'm proposing
to provide a restriction of it that only shrinks (i.e. use the current
size as an upper bound on the desired final size).


        Stefan