The edit-area - ECB - the Emacs Code Browser
Description: ECB - the Emacs Code Browser

Next: Temp- and compile-buffers, Previous: Using the keyboard, Up: Usage of ECB

### 6.3 Working with the edit-window(s) of the edit-area

ECB offers you all what you need to work with the edit-area as if the edit-windows of the edit-area would be the only windows of the ECB-frame.

ECB advices the following user-commands so they work best with ECB:

- `balance-windows`
- `delete-other-windows`
- `delete-window`
- `delete-windows-on`
- `display-buffer`
- `shrink-window-if-larger-than-buffer`
- `split-window`
- `split-window-horizontally`
- `split-window-vertically`
- `switch-to-buffer`
- `switch-to-buffer-other-window`
- `other-window`
- `other-window-for-scrolling`

The behavior of the adviced functions is (slightly simplified):

- All these adviced functions behaves exactly like their corresponding original functions but they always act as if the edit-window(s) of ECB would be the only window(s) of the ECB-frame. So the edit-window(s) of ECB seems to be a normal Emacs-frame to the user. This means that you can split and delete edit-windows without any restriction - ECB ensures that neither the special ECB-windows nor the compile-window will be damaged.
- If there is a persistent compile-window (see Temp- and compile-buffers) then all compilation-buffers in the sense of `ecb-compilation-buffer-p` will be displayed in the compile-window.
- If called in another frame than the ECB-frame these functions behave exactly like the not adviced original versions!

Please note: All these advices are only enabled when ECB is enabled.

Another interesting option in the context of the edit-window and these adviced functions is `ecb-layout-always-operate-in-edit-window`!

#### 6.3.1 Documentation of the adviced window functions

This section describes for every adviced window function (s.a.) how it differs from the original version. Only the differences are mentioned, so if you want the full documentation of such a function call `describe-function` or `C-h f`.

— Command: other-window ARG &optional ALL-FRAMES

> Around-advice `ecb`: The ECB-version of `other-window`. Works exactly like the original function with the following ECB-adjustment: The behavior depends on `ecb-other-window-behavior`.

— Command: delete-window &optional WINDOW

> Around-advice `ecb`: The ECB-version of `delete-window`. Works exactly like the original function with the following ECB-adjustment:

> If optional argument WINDOW is nil (i.e. probably called interactively): If called in a splitted edit-window then it works like as if all the edit-windows would be the only windows in the frame. This means the current edit-window which contains the point will be destroyed and its place will be occupied from another one. If called in an unsplitted edit-window then nothing is done. If called in the compile-window of ECB then the compile-window will be hidden (like with `ecb-toggle-compile-window`). If called in an ecb-window of the current ECB-layout there are two alternatives:

> - If the function is contained in `ecb-layout-always-operate-in-edit-window` the right edit-window is selected (depends on the value of the option `ecb-mouse-click-destination`) and does then itﾴs job.
> - Otherwise the behavior depends on the value of the option `ecb-advice-window-functions-signal-error`.

> If optional argument WINDOW is a living window (i.e. called from program): If WINDOW is an edit-window then this window is deleted, if WINDOW is the compile-window then it will be hidden and otherwise the behavior depends on `ecb-advice-window-functions-signal-error`.

— Command: delete-other-windows &optional WINDOW

> Around-advice `ecb`: The ECB-version of `delete-other-windows`. Works exactly like the original function with the following ECB-adjustment:

> If optional argument WINDOW is nil (i.e. probably called interactively): If called in a splitted edit-window then it works like as if all the edit-windows would be the only windows in the frame. This means all other edit-windows besides the current edit-window which contains the point will be destroyed and the current edit-window fills the whole edit-area. Neither the special ecb-windows nor the compile-window will be destroyed!

> - If called in an unsplitted edit-window then either the compile-window will be hidden (if there is one) otherwise nothing is done.
> - If called in one of the ecb-windows then the current one is maximized, i.e. the other ecb-windows (not the edit-windows!) are deleted.
> - If called in the compile window there are two alternatives:
>   - If the function is contained in `ecb-layout-always-operate-in-edit-window` the right edit-window is selected (depends on the value of the option `ecb-mouse-click-destination`) and then it does itﾴs job.
>   - Otherwise the behavior depends on the value of the option `ecb-advice-window-functions-signal-error`.

> If optional argument WINDOW is a living window (i.e. called from program): If WINDOW is an edit-window then this window is maximized (i.e. the other edit-window is deleted) if there are more at least 2 edit-windows otherwise the compile-window is deleted (if there is one). If WINDOW is an ecb-window then only the other ecb-windows are deleted and in all other cases the behavior depends on `ecb-advice-window-functions-signal-error`.

— Command: delete-windows-on BUFFER &optional FRAME

> Around-advice `ecb`: The ECB-version of `delete-windows-on`. Works exactly like the original function with the following ECB-adjustment:

> An error is reported if BUFFER is an ECB-tree-buffer. These windows are not allowed to be deleted.

— Command: split-window &optional WINDOW SIZE HORFLAG

> Around-advice `ecb`: The ECB-version of `split-window`. Works exactly like the original function with the following ECB-adjustment:

> If called for a not-edit-window in the `ecb-frame` it stops with an error if `split-window` is not contained in the option `ecb-layout-always-operate-in-edit-window`! Besides this (e.g. called for a window in another frame than the `ecb-frame`) it behaves like the original version.

— Command: split-window-horizontally

> Around-advice `ecb`: The ECB-version of `split-window-horizontally`. Works exactly like the original function with the following ECB-adjustment:

> If called in any other window of the current ECB-layout it stops with an error if this `split-window-horizontally` is not contained in the option `ecb-layout-always-operate-in-edit-window`!

— Command: split-window-vertically

> Around-advice `ecb`: The ECB-version of `split-window-vertically`. Works exactly like the original function with the following ECB-adjustment:

> If called in any other window of the current ECB-layout it stops with an error if this `split-window-vertically` is not contained in the option `ecb-layout-always-operate-in-edit-window`!

— Command: display-buffer BUFFER &optional NOT-THIS-WINDOW FRAME

> Around-advice `ecb`: Makes this function compatible with ECB if called in or for the ecb-frame. It displays all buffers which are “compilation-buffers” in the sense of `ecb-compilation-buffer-p` in the compile-window of ECB. If the compile-window is temporally hidden then it will be displayed first.

> If there is no compile-window (`ecb-compile-window-height` is nil) then it splits the edit-window if unsplitted and displays BUFFER in another edit-window but only if `pop-up-windows` is not nil (otherwise the edit-window will not be splitted).

> All buffers which are not “compilation-buffers” in the sense of `ecb-compilation-buffer-p` will be displayed in one of the edit-area and `display-buffer` behaves as if the edit-windows would be the only windows in the frame.

> If BUFFER is contained in `special-display-buffer-names` or matches `special-display-regexps` then `special-display-function` will be called (if not nil). But this behavior depends on the value of the option `ecb-ignore-special-display`. The values of `same-window-buffer-names` and `same-window-regexps` are supported as well.

> See the option `ecb-ignore-display-buffer-function`!

> If called for other frames it works like the original version.

— Command: switch-to-buffer BUFFER &optional NORECORD

> Around-advice `ecb`: The ECB-version of `switch-to-buffer`. Works exactly like the original but with the following enhancements for ECB:

> “compilation-buffers” in the sense of `ecb-compilation-buffer-p` will be displayed always in the compile-window of ECB (if `ecb-compile-window-height` is not nil) - if the compile-window is temporally hidden then it will be displayed first. If you do not want this you have to modify the options `ecb-compilation-buffer-names`, `ecb-compilation-major-modes` or `ecb-compilation-predicates`.

> If called for non “compilation-buffers” (s.a.) from outside the edit-area of ECB it behaves as if called from an edit-window if `switch-to-buffer` is contained in the option `ecb-layout-always-operate-in-edit-window`. Otherwise an error is reported.

— Command: switch-to-buffer-other-window BUFFER &optional FRAME

> Around-advice `ecb`: The ECB-version of `switch-to-buffer-other-window`. Works exactly like the original but with some adaptions for ECB so this function works in a “natural” way:

> If called in any special ecb-window of the current ECB-layout then it goes always to an edit-window (which one depends on the setting in `ecb-mouse-click-destination`) and then goes on as if called from this edit-window.

> If a compile-window is used (i.e. `ecb-compile-window-height` is not nil) then “compilation-buffers” in the sense of `ecb-compilation-buffer-p` are always displayed in the compile-window. If the compile-window is temporally hidden then it will be displayed first. If no compile-window is used it behaves like the original.

> If called from within the compile-window then “compilation-buffers” will be displayed still there and all other buffers are displayed in one of the edit-windows - if the destination-buffer is already displayed in one of the edit-windows then this one is used otherwise it behaves like the original.

> If called within an edit-window it behaves like the original function except for compilation-buffers (if a compile-window is used, see above).

— Function: other-window-for-scrolling

> Around-advice `ecb`: This function determines the window which is scrolled if any of the “other-window-scrolling-functions” is called (e.g. `scroll-other-window`):

> If the option `ecb-scroll-other-window-scrolls-compile-window` is not nil (maybe set by `ecb-toggle-scroll-other-window-scrolls-compile`) and a compile-window is visible then always the current buffer in the compile-window is scrolled!

> Otherwise it depends completely on the setting in `ecb-other-window-behavior`.

— Command: balance-windows

> Around-advice `ecb`: When called in the `ecb-frame` then only the edit-windows are balanced.