[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: `fit-window-to-buffer-as-displayed'?
From: |
Stefan Monnier |
Subject: |
Re: `fit-window-to-buffer-as-displayed'? |
Date: |
Tue, 11 Jan 2011 00:30:44 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
>> 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