RE: patch for optional inhibit of delete-other-windows(IDE feature)

[klaus.berndl]

address@hidden wrote:
> <address@hidden> writes:
> 
>> Hi,
>> 
>> first of all thanks!
>> 
>> But some remarks:
>> 
>> I'm sure Emacs should offer out-of-the-box internal concepts to
>> allow IDEs like ECB setting up a window-management-engine as needed
>> by a modern IDE - this includes stuff like preventing a window from
>> being deleted by delete-other-windows and something more which has
>> been already discussed...    
>> 
>> But: I'm not sure if doing this a c-level is the right way. Why?
>> IMHO ECB should be runable with Emacs as well with XEmacs. And if
>> all these window-enhancements would be done at c-level at Emacs then
>> the incompatibilities between Emacs and XEmacs would become more and
>> more...    
>> 
>> Of course Emacs and XEmacs are already quite incompatible but IMHO
>> such important basic stuff like preventing windows from some
>> operations should be a concept both flavors should support
>> identically - at least concerning the programming interface a tool
>> like ECB would see and use...    
>> 
>> Your opinion?
> 
> This was discussed on emacs-devel, and the emacs maintainers prefered
> the C level implementation for various reasons.
> 
> IMHO this C level patch is fairly simple so it should be possible to
> apply it to xemacs also, although I dont know much about xemacs.
> Maybe someone more familiar with xemacs would care to comment.
> 
> I think its difficult to implement this particular interface on the
> lisp level, but I might be mistaken. The interface being that you
> bind a plist to the windows object, with properties that modifies the
> behaviour of windows operations.
> 
> Currently the interface appears to become very simple, and I would
> like to solicit opinions about it:
> 
> - A window property that allows you to "pin" the window, or rather
>   inhibit delete-other-windows for it. This is currently implemented.
> 
> - A window property that allows you to group windows together, such
>   that other-window only cycles between windows in the group.
> 
> From my understanding of the ECB, these two properties would help to
> implement much of the current functionality ECB now uses advice for.

Hmm, its a good starting point but not complete. Simply think of ECB
as a tool which wants to display some special windows beside an 
"edit-area" whereas the former one are used to display informational
context stuff as parsed tags of the current buffer in the edit-area
or a file- and directory tree or a buffer-history or or or...
The latter one (the edit-area) should give the user the feeling as
if all windows of this edit-area would be the only windows in the
frame so all standard operations would act as if the edit-windows
would be the only windows in the frame...

Well, a window property for preventing other windows outside the 
edit-area from being deleted or for a navigation only in the edit-
area by other-window would be a good starting point but its not the
end of the story:

What about saving and later restoring the current window layout of the
edit-area (means only these windows inside the edit-area) without
affecting the layout of the special windows?

And how to implement an option like
`ecb-layout-always-operate-in-edit-window'
(see docstring) without adviceing e.g. switch-to-buffer?

Just take a look at the docstring of the adviced `switch-to-buffer':
IMHO even with the new pins advices are needed to offer a smart and
convenient usage of an IDE like ECB...

maybe i will find next weekend the needed time to write down a small
"functional reqirement specification" which core functionality would
be required by Emacs to rewrite ECB without a lot of its advices or
at least with much simpler advices...

Ciao,
Klaus

>> 
>> Ciao,
>> Klaus
>> 
>> address@hidden wrote: