Re: moving window handling into lisp

[Lennart Borgman]

On Thu, Aug 20, 2009 at 5:08 PM, martin rudalics<address@hidden> wrote:
>>> You should be able to use it for standard cases.  For more complicated
>>> cases `adjust-window-trailing-edge' will do its own resizing (and maybe
>>> delete some window along the way).  And it's the complicated cases we
>>> have to test.
>>
>> What I wrote is for the most complicated cases. Can you tell me more
>> exactly what you think does not work? You may have seen something I
>> have not seen.
>
> `adjust-window-trailing-edge', as a last consequence, calls size_window
> with nodelete_p zero, so it's allowed to delete windows.  I thought you
> wanted to avoid that.


Thanks. I did not know adjust-window-trailing-edge could delete
windows. The doc string does not tell about that. I thought it was
correct. Could you please try to get the doc string corrected to
reflect the functions current state?


>>>>> The first thing we need for each window are some functions like
>>>>> `window-parent-window', `window-prev-window', `window-next-window',
>>>>> `window-vchild', `window-hchild', `window-left-column', and
>>>>> `window-top-line'.  This should be simple.
>>>> They are in principle already available through window-tree. But yes,
>>>> having them more explicitly would be fine.
>>> Are you sure?  Then you could write the necessary wrappers.
>>
>>
>> Of course I am sure. I am using that in winsav.el. But I do not think
>> it is a good idea to write wrappers on that level. Why do you think
>> that?
>
> If you have the wrappers at hand, use them.  We can write these
> functions and think how to call them later.


I do not have them, they are not written in that form. I meant that
the information from Emacs about windows is exposed through
window-tree.


>>>>> Next we need `window-set-new-height' and `window-set-new-width' to set
>>>>> and `window-new-height' and `window-new-width' to get the new values
>>>>> for
>>>>> a window's height and width and a function called
>>>>> `window-set-new-sizes'
>>>>> which copies the new values into the old values (checking whether they
>>>> Maybe. It have to be calculated the way I have said before. Is not
>>>> that clear yet?
>>> But you have to _assign_ these values somehow (unless you try it with
>>> `adjust-window-trailing-edge').
>>
>> But I have said many times that they preferrably should be applied to
>> a whole level at once. That would be much cleaner.
>>
>> What problems do you see with that?
>
> I'm just confused, that's my only problem.  You never told me what you
> really want.  What does "they preferrably should be applied to a whole
> level at once" mean?


Oh, sorry, then I must have been unclear.

The algorithm computes level by level in the second pass (ie on its
way down) how the windows should be sized. So you have the sizes for
all windows on that level at once. You can of course use
adjust-window-trailing-edge (setting restcrictions temporary to be
able to do that), but it seems much easier to be able to set them all
at once. The routines we have now for setting window sizes does
checking that has already been done by my functions then.


>>>>> But I'm not yet sure how we can integrate the resizing algorithm into
>>>>> `delete-window'.  Think of a frame composed of two windows where one is
>>>>> a leaf window and the other a combined window with many subwindows.
>>>>> When deleting the leaf window we have to resize the combined window
>>>>> which means to run a resize algorithm which _must not fail_ to produce
>>>>> a
>>>>> perfectly valid result.  So I'm afraid that I do have to run some sort
>>>>> of a rudimentary resize algorithm in C first and apply our algorithm
>>>>> afterwards :-(
>>>> Hm. There must be something you are missing here. Why do you believe
>>>> that my algorithm can't be used. This is exactly a situation where it
>>>> can be used.
>>> When do you call it?  If you call it before the window gets deleted,
>>> _you_ have to delete the window (and all its subwindows).  If you call
>>> it after the window gets deleted but before the others are resized, the
>>> Elisp call occurs in an invalid window configuration.  How would you
>>> handle that?
>>
>>
>> The elisp code I wrote does not in any way care if the configuration
>> is valid or not. It just looks at the available size and the
>> restrictions. Is not that clear? What problem do you see with that?
>
> I can't call Elisp code in an invalid configuration.  Suppose your
> algorithm decides that it cannot resize.  What shall the display engine
> display then?  The invalid configuration?


I am trying to understand what you mean here. You can call my routines
before deletion. It does not depend on the actuall configuration, just
the fictive configuration you tell about.


>>>>> As far as frame-resizing and the necessary deletion of windows is
>>>>> concerned I think we should really run our algorithm and, if it fails,
>>>>> simply delete the least recently used window until it doesn't fail any
>>>>> more (in the worst case this will resize a fixed-size window).
>>>> So you still think we should delete windows? I do not.
>>> If someone eventually comes up with a solution that handles frame
>>> resizing (and minibuffer resizing!) I'll be the first to go for it.
>>
>> I have suggested one. You have not replied to it.
>
> No one ever has suggested a practicable solution.  AFAICT you proposed
> to ask the user what to do in that case.  That's not practicable IMO.


Not really. I suggested:

- showing an alternate single window with information that the windows
does not fit
- and also keep the other configuration so you can put it back when
the window gets large enough again.
- this should be kept by just swapping a pointer between that single
window with information and the "real" configuration.

What do you find not practical about this? (The alternate single
window should just say something like "your windows does not fit,
please make the frame larger".)


>>>> Did not Stefan say he want to avoid it too?
>>> He did not provide a solution for it - and I suppose he's smart enough
>>> not to propose one.
>>
>> You are misunderstanding him. He wants ideas. Of course he knows about
>> the difficulties.
>
> Stefan earlier said in this thread to
>
> - either somehow make it possible to undelete windows (I'd *much* rather
>  not, but maybe if we make it sufficiently restrictive it'd be OK).
> - or maybe avoid deleting the window in this case, instead leave it
>  a size-0, and delete it at some later time (when would that be?).
> - prevent frame resizing that would require deleting a window.
>
> and that's where we still are more or less.  Everything I heard from
> people since that was not told from an implementor's POV.


Hm. I answered to that that I think it is better to use a single
alternate window like above. That is very much an implementors POV.
Why don't you think it is? (I believe maybe you think so because I do
not adhere to the old routines, but I am not sure.)

I did not go into details, but:

- undeleting seems terribly confusing from a users point of view.
- size-0 windows in a case like this would be the same.
- we probably can't prevetn resizing with all window managers.


>>>> Did you seriously try to understand my suggestion for how to handle it?
>>> Did you have a serious suggestion?
>>
>> Yes.
>>
>> Martin, can I take this to the list again. I thought we would save
>> time this way, but I am starting to doubt it. Can I send this mail to
>> the list?
>
> Sure, go ahead ;-)


Ok, done. It took it off list since I thought we should discuss boring
details, but the got back to principal discussion again so here we are
on the list again!


> martin
>