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

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

[Drew Adams]

`fit-window-to-buffer' uses `count-window-lines', which takes line display into
account.

In this it seems to be trying, at least somewhat, to fit the window not simply
to the buffer content (plain text, fixed-char size) but to the buffer as
actually displayed.

But it fails to take any other display stuff into account, besides visual lines.
Looking around, I haven't found any code that would help fit a window to the
buffer as it is actually displayed - to account for the size of what you
actually see: displayed images, `display' property effects, proportional text,
etc.

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

2. If not, could that please be added to Emacs?  (I'll file an enhancement
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.

3. If such an optional parameter were added, then perhaps it should also allow a
value that did not `count-window-lines' but counted buffer lines - IOW, instead
of just the halfway house of respecting display only so far as visual line
display is concerned, have 3 possibilities:

(a) buffer content without regard to display,
(b) what we have now: sensitivity only to line display, and
(c) sensitivity to all display artefacts.

For (a), we would need some defined way of treating images (whether or not they
are displayed) - perhaps based on the length of the file-name or embedded-image
code (dunno).

Wrt #1, I did find a couple of things that seem a bit related, in addition to
`count-window-lines': `image-size' and the window `vscroll' and `hscroll'
properties.  But nothing that takes the display of a whole buffer into account.
(E.g., it seems that instead of fitting the window to the image-dired display
image-dired does the opposite: scales the images to fit the window size.)

Anticipating a possible response of "this is too hard...", let me add that even
a partial solution would be helpful.  IOW, even if we couldn't immediately or
easily treat the whole problem of calculating displayed buffer size, perhaps we
could make some progress, so that `fit-window-to-buffer' might do a better job
than just adapting to screen lines.

WDOT?

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

[Stefan Monnier]

> In this it seems to be trying, at least somewhat, to fit the window
> not simply to the buffer content (plain text, fixed-char size) but to
> the buffer as actually displayed.

Yes, it tries as best it can.  It's not flawless, tho, largely for lack
of better primitive functions.

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

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

Agreed, please.

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

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.


        Stefan

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. ;-)]

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

[Stefan Monnier]

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

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.