RE: `fit-window-to-buffer-as-displayed'?

[Drew Adams]

> > 1. Am I missing something - is there something that would 
> > help with this? Something that would give me the actual
> > height and width of a buffer as
> > currently displayed (e.g. in pixels)?
> 
> At the time fit-window-to-buffer-as-displayed is called, the 
> text might not be completely displayed yet.

Well obviously one would call `fit-window-to-buffer-as-displayed' only after
(one knew that) it was displayed. ;-)

And if it were called when not displayed then, in that situation, we could
either have it be a no-op or have it do what `fit-window-to-buffer' does now.

> > 2. If not, could that please be added to Emacs?  (I'll file 
> > an enhancement
> 
> Agreed, please.

Done - bug #7822.

> > request if it makes sense.)  Either a new function,
> > `fit-window-to-buffer-as-displayed' or (better, IMO) an 
> > enhancement to `fit-window-to-buffer' that adds an optional
> > parameter AS-DISPLAYED.
> 
> No need for a new parameter: it's a bug-fix.

That means that you interpret `fit-window-to-buffer' as though it should
_always_ fit the window to the buffer _as displayed_.

I think there can be use cases for its current behavior.  And use cases for just
fitting to the buffer text, ignoring all display considerations (treating it as
plain, fixed-width text, no more).

> It's not trivial to fix, tho, and it's not clear which kind 
> of primitive the C code could/should provide in order to make
> it possible.

I figured it would not be trivial.

And I'm guessing the result might be only partially effective (correct).  That's
one reason why I think there should be the option (either via a parameter or a
separate function) to _not_ have it try to take into account all display
characteristics.

IOW, you should be able to have the window fit the buffer text in simpler ways,
including the way we fit it now.

> Maybe we could simply do something like a binary search, 
> where each loop iteration forces redisplay, then checks with
> posn-point if EOB is right at the end of the window.

I probably have nothing to offer wrt the implementation.  I do think though that
this is bound to be somewhat complex and success is likely to be partial and
conditional (works for some display artifacts in some situations, but is not
perfect).  There are a lot of different things one can do with display, even
just counting the `display' text/overlay property.  (And note that some of them
take place beyond buffer positions, so tests involving (point) won't necessarily
cut the mustard.)

For this reason I think the behavior (what it tries to do) should be under
programmer control.  We already have something that "works" for what it does.
Complicating the behavior to try to do better might make some situations better,
but someone might still want simpler behavior (e.g. what we have now) sometimes.

[I generally prefer to give users and programmers more control, _especially_
when faced with an all-encompassing wannbe-all-powerful DWIM. ;-)]