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

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

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

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

Yes.

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


        Stefan