RE: FW: fit-frame.el

["Drew Adams" <drew.adams@oracle.com>]

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

You can put "Fitting" in quotes, in "_Fitting a non-empty buffer means_", if
you think that helps (I don't). If not, propose an improvement to the doc
string.

I spent several iterations over the doc string with Richard already. If you
have a concrete suggestion, feel free to send it along.
 
> > 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.

I don't see anything that's unfinished. It works fine with one-window
frames. It works fine with more than one window also, if you want to resize
the frame so that a particular buffer (window) is displayed without
wrapping. That is the feature, and it does that fine.

You seem to be wanting something that it doesn't pretend to do. And
something that you can't even describe (!): balance window sizes in some
undefined ideal fashion. That's a different feature altogether.

> When the feature is completed we can reconsider it.

OK, forget about 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).

I understood. The question is: shrinks to what size?

It's easy enough to have a variant that does the same thing as now, but
prohibits any expansion, if that's all you mean. I don't see why that's
particularly useful, but it's easy enough to implement. 

And you can add a variant that only grows, instead of only shrinks. And a
variant that only shrinks or only grows vertically, or horizontally...

But it sounds like you're not interested, in general, so there's no sense
bothering with any of that.