emacs-devel
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]