Re: Infrastructural complexity.

[Lennart Borgman]

On Fri, Jul 24, 2009 at 6:08 PM, martin rudalics<address@hidden> wrote:
>> I did not mean giving the zero height ot width. That would be
>> confusing. I meant visibility as a new property.
>
> Whose going to handle that property?  The display-engine?


I do not know how it is implemented so I can't say exactly how. What I
mean is that they should be handled by those part as they did not
exist. (That of course means for example jumping over them in some
lists etc.)


>> - Rotate
>> - Transpose
>
> What's the precise semantics of these operations?  Which window
> variables should be changed?  I suppose what you mean is shuffling
> around the buffers displayed in those windows.


Rotating the visual window structure. Transposing the visual window structure.

Buffers should move with the windows (visulally).


>> - Resizing.
>>
>> Actually the reszing code when putting back a window tree in winsav
>> was one of the most frustrating pieces of code I have written because
>> it had to fight what the C code was doing. I think the resizing code
>> is one of those pieces that should be written in C. It should be much
>> more simple there (the logic I mean ...).
>
> The resizing logic is the most difficult one (IMHO also due to the fact
> that Emacs is allowed to delete windows when they get to small).  What's
> worse is that in most cases resizing operations are not reversible.
> That is, starting from an initial configuration, enlarging some window
> first and shrinking it by the same amount afterwards often won't get you
> back to the initial configuration.  However, resizing is a problem ECB
> users should have got used to.  IIRC they can always refetch a specific
> configuration from a set of saved ones.


In that case there are code in winsav.el for it.