Re: patch for optional inhibit of delete-other-windows(IDE feature)
| Newsgroups | gmane.emacs.devel,gmane.emacs.code-browser |
|---|---|
| Message-ID | <[email protected]> |
<[email protected]> 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. > > Ciao, > Klaus > > [email protected] wrote: -- Joakim Verona