Re: moving window handling into lisp

[Lennart Borgman]

On Thu, Aug 20, 2009 at 8:15 PM, martin rudalics<address@hidden> wrote:

> Every resize operation may delete windows.  But some like the minibuffer
> resize operations and `adjust-window-trailing-edge' save the
> window-configuration around resize calls to avoid that windows get
> deleted.  I'm not sure whether that's of any help for you, though.


Thanks. I had no idea about that. I will think about it.


>> 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.
>
> I still don't understand what a "level" is.


All children to a window are on the same level.


>> 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 that's what the functions `set-new-window-height' and
> `set-new-window-width' I proposed earlier should do.


Do I understand you right, do you say: These should set the size
without any checking.


>>> 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.
>
> I can't because at that time the window still exists and you don't
> delete windows.  I need a resize function that's executed _as part of_
> the Emacs command `delete-window'.
>
>> It does not depend on the actuall configuration, just
>> the fictive configuration you tell about.
>
> How do I tell it about a "fictive configuration"?  You want all those
> links to the next, previous, parent windows be valid, I suppose.


You can make a lisp copy of the configuration. This copy should
contain just the info needed to compute the new sizes. If you want the
sizes after deletion then just do not include the window you want to
delete in the copy.


>> 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.
>
> The canonical way to handle this is keeping "the other configuration" in
> a window-configuration, something Stefan wants to avoid.  I don't get at
> what you mean by "pointer swapping".  If such pointer swapping were as
> easy as you believe, we could have used that all the time instead of
> saving window-configurations.


I thought a window-configuration was a copy with the information
necessary to recreate the window configuration. That is a totally
different thing and can't be done the way I suggest.


I am not sure that what I suggest is that very easy to do. I thought
you should comment on it, but we are miscommunicating for some reason.

I have not looked at the implementation, but I know you have so I am
asking you. (I have rephrased and clarified my question below.)

I guessed there must be some pointer (in a general sense) for each
frame to the root window. I do not know the actual implementation, but
I just glanced at it. Unfortunately it takes some time for me to read
C so I guess a little. I can see there is a Lisp_Object called
root_window in struct frame. This is the pointer I am talking about.

My question (and suggestion) to you is this: Would it be possible to
temporarily replace the frames root_window with a new window when the
frame size gets so small that the window configuration does not fit?
Whether this is easy (or perhaps even possible) is of course dependent
on the details in this implementation.

It depends on for example on how drawing of windows are done. Is
drawing of a frame something that starts from the frame and then goes
down to look at the windows? Or does the windows live a life on their
on in this regard? I have assumed the former when I suggested to just
swap the roor_window pointer. You know more about the implementation
details and can probably give a better answer.


Maybe I should have explained this from the beginning, but I believed
you should answer something like the above to my suggestion. I am
sorry for beeing too short.


>> 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".)
>
> Do you know any application proposing to enlarge its window?


I thinks I have seen such cases, yes. (But I do not remember where now.)

You seem to suggest that it would be hard to understand for the user.
In that case, why?


>> - undeleting seems terribly confusing from a users point of view.
>
> You do undelete all the time.  It's completely transparent.


How can it be transparent if windows disappears and reappears? I must
be misunderstanding you somehow...


>> - size-0 windows in a case like this would be the same.
>
> Many applications do that.


Can you explain how you mean?


>> - we probably can't prevetn resizing with all window managers.
>
> martin
>