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

[Drew Adams]

> >> 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 how do you know and/or make sure it's *completely* displayed?

You might not be able to know for sure - hence the smily.

But likely you would not want to call it before you added `display' properties
etc. that you wanted to be taken into account for the fitting.  Of course
calling it after such code has finished is still no guarantee.  You can try
forcing redisplay, but in many cases that won't be necessary.

The point is that calls to fit the window to what is displayed would
intentionally be made after the buffer has been displayed in all its glory.
Whether that intention is realized in all cases is another story.

> > 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.
> 
> But fit-window-to-buffer doesn't work right in many cases, so 
> that'd not be a complete solution.

Any bugs should be fixed, of course.  By "what it does now" I was referring to
the current intended behavior of taking into account screen lines, not text
lines.

> > 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).
> 
> Maybe there can be, but I can't think of any of them, so I 
> think they'd be very far fetched and insignificant.
> 
> > 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.)
> 
> There's no point trying to add support for some properties 
> but not all: adding support for all properties is likely to be easier
> because it'd rely on (re)using the existing display code.

I agree with the attempt.  I was only suggesting that the job might not be
simple.  You mentioned checking `posn-point' in a loop.  I pointed out that some
display happens outside of any positions that point can assume - outside of the
buffer text altogether (e.g. margins).

Anyway, making `fit-window-to-buffer' take display artifacts into account would
be an improvement.  If you want to have it always take all such into account
(i.e. not let programmers pick & choose), that's still a fine improvement.
Let's please do it.