lru-window, window--try-to-split-window, split-width-threshold

lru-window, window--try-to-split-window, split-width-threshold

[Drew Adams]

`split-width-threshold' was apparently introduced recently. Depending on its
value, the lru-window can now get split horizontally to display *Completions*
during minibuffer input.

I have code that changes the display of completions (columns, spacing etc.),
depending on the width *Completions* will have when it is displayed. Before it
is displayed, I obtain (window-width (get-lru-window)) and use that as the
assumed window width.

This is no longer adequate, however, because the effective width might be, say,
half of that if the lru window gets split horizontally to display *Completions*.
And I can't simply use half of that width systematically, because there might be
no horizontal split, depending on `split-width-threshold'. I don't know a way to
know ahead of time whether a horizontal split will occur (without reproducing
all of the code/logic of `window--try-to-split-window' - checking for dedicated
windows etc.).

I tried this: (window--try-to-split-window (get-lru-window)), figuring that I
might as  well split the lru-window myself, if it is going to be split, so that
I can get its new width and use that.

The problem with this is that once the split occurs the window that was split is
apparently no longer the lru window, so *Completions* gets displayed by
splitting yet another window. If I have two full-frame-width windows (frame
split vertically), the effect is that both windows get split when *Completions*
is displayed (and then unsplit when *Completions* is finished).

Any suggestions? What am I missing? Is there some way, say, after splitting the
lru window myself, that I can make it (or the new one) the lru again, so that
`display-buffer' will use it for *Completions*? IOW, is there a way to *set* the
lru window? Any help is welcome.

Re: lru-window, window--try-to-split-window, split-width-threshold

[martin rudalics]

 > `split-width-threshold' was apparently introduced recently. Depending on its
 > value, the lru-window can now get split horizontally to display *Completions*
 > during minibuffer input.
 >
 > I have code that changes the display of completions (columns, spacing etc.),
 > depending on the width *Completions* will have when it is displayed. Before it
 > is displayed, I obtain (window-width (get-lru-window)) and use that as the
 > assumed window width.
 >
 > This is no longer adequate, however, because the effective width might be, say,
 > half of that if the lru window gets split horizontally to display *Completions*.
 > And I can't simply use half of that width systematically, because there might be
 > no horizontal split, depending on `split-width-threshold'. I don't know a way to
 > know ahead of time whether a horizontal split will occur (without reproducing
 > all of the code/logic of `window--try-to-split-window' - checking for dedicated
 > windows etc.).

So you can't fill the buffer _after_ the splitting occurred?  Relying on
someone else to always choose the LRU window is not very clean in the
first place.

 > I tried this: (window--try-to-split-window (get-lru-window)), figuring that I
 > might as  well split the lru-window myself, if it is going to be split, so that
 > I can get its new width and use that.
 >
 > The problem with this is that once the split occurs the window that was split is
 > apparently no longer the lru window, so *Completions* gets displayed by
 > splitting yet another window.

Are you sure?  The LRU status changes with `select-window' IIUC.

 > If I have two full-frame-width windows (frame
 > split vertically), the effect is that both windows get split when *Completions*
 > is displayed (and then unsplit when *Completions* is finished).
 >
 > Any suggestions? What am I missing? Is there some way, say, after splitting the
 > lru window myself, that I can make it (or the new one) the lru again, so that
 > `display-buffer' will use it for *Completions*? IOW, is there a way to *set* the
 > lru window? Any help is welcome.

The only way I currently can think of is a dolist selecting all other
windows but the one you've chosen.

martin

RE: lru-window, window--try-to-split-window, split-width-threshold

[Drew Adams]

>  > `split-width-threshold' was apparently introduced 
>  > recently. Depending on its value, the lru-window
>  > can now get split horizontally to display *Completions*
>  > during minibuffer input.
>  >
>  > I have code that changes the display of completions 
>  > (columns, spacing etc.), depending on the width
>  > *Completions* will have when it is displayed. Before it
>  > is displayed, I obtain (window-width (get-lru-window)) and 
>  > use that as the assumed window width.
>  >
>  > This is no longer adequate, however, because the effective 
>  > width might be, say, half of that if the lru window gets
>  > split horizontally to display *Completions*.
>  > And I can't simply use half of that width systematically, 
>  > because there might be no horizontal split, depending on
>  > `split-width-threshold'. I don't know a way to know ahead
>  > of time whether a horizontal split will occur (without
>  > reproducing all of the code/logic of
>  > `window--try-to-split-window' - checking for dedicated
>  > windows etc.).
> 
> So you can't fill the buffer _after_ the splitting occurred?  
> Relying on someone else to always choose the LRU window is
> not very clean in the first place.

Right you are.

I use code similar to that used in Emacs. The formatting is done inside
`with-output-to-temp-buffer', which displays the buffer only at the end.

>  > I tried this: (window--try-to-split-window (get-lru-window)),
>  > figuring that I might as  well split the lru-window myself,
>  > if it is going to be split, so that I can get its new width
>  > and use that.
>  >
>  > The problem with this is that once the split occurs the 
>  > window that was split is apparently no longer the lru window,
>  > so *Completions* gets displayed by splitting yet another window.
> 
> Are you sure?

No. ;-) In fact, looking again at the `display-buffer' code, I see what the
problem was:

(setq window-to-use
      (or (window--try-to-split-window
           (get-largest-window frame-to-use t))
          (window--try-to-split-window
           (get-lru-window frame-to-use t))))

I split the lru window, but then `display-buffer' split the largest window, so
two were split. And that's not all. To determine which window `display-buffer'
would use, I would in fact need to duplicate a good deal of the logic from
`display-buffer'.

So I took your suggestion and displayed *Completions* first. Thx.

Re: lru-window, window--try-to-split-window, split-width-threshold

[Stefan Monnier]

>> So you can't fill the buffer _after_ the splitting occurred?  
>> Relying on someone else to always choose the LRU window is
>> not very clean in the first place.

> Right you are.
> I use code similar to that used in Emacs. The formatting is done inside
> `with-output-to-temp-buffer', which displays the buffer only at the end.

This is a more general problem, where you often want to know the width
of the window that will be used to display a buffer before filling the
buffer but you also sometimes need to know the content of the buffer in
order to choose the best size for the window that will display it.

In your case you may be able to adjust the buffer's content from
temp-buffer-show-hook (which is run after the buffer was displayed).


        Stefan

RE: lru-window, window--try-to-split-window, split-width-threshold

[Drew Adams]

> >> So you can't fill the buffer _after_ the splitting occurred?  
> >> Relying on someone else to always choose the LRU window is
> >> not very clean in the first place.
> 
> > Right you are.
> > I use code similar to that used in Emacs. The formatting is 
> > done inside `with-output-to-temp-buffer', which displays the
> > buffer only at the end.
> 
> This is a more general problem, where you often want to know the width
> of the window that will be used to display a buffer before filling the
> buffer but you also sometimes need to know the content of the 
> buffer in order to choose the best size for the window that will
> display it.
> 
> In your case you may be able to adjust the buffer's content from
> temp-buffer-show-hook (which is run after the buffer was displayed).

Right. I already looked into that. It was not helpful in my particular case, but
I agree with you in general. Thanks.