Node:The edit-area, Next:, Previous:Using the keyboard, Up:Usage of ECB


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 offers you to advice the following functions so they work best with ECB:

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

ATTENTION: If you want to work within the edit-area with splitting and unsplitting (i.e. deleting) the edit-window(s) it is highly recommended to use the adviced-functions of ECB instead of the original Emacs-functions (see above). Per default ECB advices all of the functions mentioned above but with the option ecb-advice-window-functions you can customizes which functions should be adviced by ECB. Please read carefully the documentation of this option!

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

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.

other-window ARG &optional ALL-FRAMES Command
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.

delete-window &optional WINDOW Command
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.

delete-other-windows &optional WINDOW Command
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.

delete-windows-on BUFFER &optional FRAME Command
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.

split-window &optional WINDOW SIZE HORFLAG Command
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.

split-window-horizontally Command
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!

split-window-vertically Command
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!

display-buffer BUFFER &optional NOT-THIS-WINDOW FRAME Command
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.

switch-to-buffer BUFFER &optional NORECORD Command
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.

switch-to-buffer-other-window BUFFER &optional FRAME Command
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).

other-window-for-scrolling Function
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.

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