[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: Infrastructural complexity.
From: |
martin rudalics |
Subject: |
Re: AW: Infrastructural complexity. |
Date: |
Fri, 24 Jul 2009 18:09:44 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
> With such a window-group concept several things should/could be possible:
> - preventing a group from being be deleted by C-x 1 (AFAIK currently
> there is something going on to achieve this with a new window-flag,
This would be done with a window parameter of the internal window group
window (that parameter would have to be installed by ECB to become
effective) and an appropriate change of `delete-other-windows'. BTW, I
suppose you mean that C-x 1 invoked within a window belonging to a
window group just deletes all other windows of that group?
> IIRC implemented by Joakim for the next release 24.X?!)
> - hiding (ie. deleting) a window-group (ie. all it's windows but no others
> from outside the group)
Here this is simply `delete-window' applied to the internal window
constituting the group (some other window must be left on the frame to
make this happen).
> - saving the window-configuration of exactly one group and restoring only this
> window-group (if a frame allocates needed space)
I suppose you mean saving the group configuration, that is, windows not
belonging to the group are not saved. This can be done and you can
restore them in an arbitrary window (like the root window of a frame or
an arbitrary other window).
> - rewriting display-buffer so only a certain window-group can be
> used for displaying a buffer - or the other direction: a window-group can
> be prevented from being used by display-buffer for buffer display
The "other direction" solution will be preferred, probably. This means
a slight change in testing whether a window `display-buffer' chooses can
really be used.
> - etc...
>
> IMHO such a general window-group concept between the frame- and the window-
> concept would alleviate writing a tool like ECB (and would make a lot of its
> advices obsolete or at least much simpler)
I suppose we must get rid of all advices.
> This is the point of view of the author and maintainer of ECB ;-)
The more complete the list of issues you sketched above gets, the better
I can try to address these issues early enough.
martin
- Re: Infrastructural complexity., (continued)
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Lennart Borgman, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/25
- AW: Infrastructural complexity., klaus.berndl, 2009/07/25
- Re: AW: Infrastructural complexity.,
martin rudalics <=
- Re: AW: Infrastructural complexity., Thomas Lord, 2009/07/24
- AW: AW: Infrastructural complexity., klaus.berndl, 2009/07/25
- Re: AW: AW: Infrastructural complexity., Miles Bader, 2009/07/25
- Re: AW: AW: Infrastructural complexity., Thomas Lord, 2009/07/25
- Re: Infrastructural complexity., martin rudalics, 2009/07/24
- Re: Infrastructural complexity., Thomas Lord, 2009/07/24
- Re: Infrastructural complexity., martin rudalics, 2009/07/25
- Re: Infrastructural complexity., Stefan Monnier, 2009/07/25
- Re: Infrastructural complexity., martin rudalics, 2009/07/25
- Re: Infrastructural complexity., Stefan Monnier, 2009/07/26