Next: , Previous: The edit-area, Up: Usage of ECB


6.4 Temp- and compile-buffers display in ECB

If you call any help in Emacs, e.g. by calling describe-function, or if you do a completion in the minibuffer, then Emacs displays the result-buffer in another window. This behavior you have also in ECB.

6.4.1 Standard Emacs behavior

6.4.1.1 Gnu Emacs 21.x, 22.x and XEmacs 21.4:

If the edit-area is already splitted into at least two edit-windows then the temp-buffer is displayed in another edit-window otherwise the edit-area will be splitted first vertically into two edit-windows, one above the other. The variables temp-buffer-max-height and temp-buffer-resize-mode (for GNU Emacs) and temp-buffer-shrink-to-fit (for XEmacs) work also correctly with ECB.

Same for all completion-buffer and “compile”-like output-buffers (e.g. after a compile or grep) and the variable compilation-window-height1.

6.4.1.2 Gnu Emacs 23.x

Gnu Emacs 23 has a much smarter window-manager for displaying temporary buffers (like help-buffers) and “compile”-buffers (like real compilation outputs but also grep-outputs, completions etc.). Therefore ECB uses completely the logic of Emacs 23 and does exactly what Emacs 23 would do without activated ECB: This means mainly that the split-behavior depends on the settings of the options split-width-threshold and split-height-threshold.

Please note: If you are wondering why displaying temporary-buffers (like help, compile, grep, completion etc.) shows different behavior compared to deactivated ECB, then you probably have to adjust the values of the options split-width-threshold and split-height-threshold to the sizes of the edit-area of ECB (at least nearly).

This is default behavior of ECB. But there is also another way to display such buffers: Using a persistent extra window at the bottom of the ECB-frame, named the “compile-window”:

6.4.2 Using a persistent compile window

With the option ecb-compile-window-height you can define if the ECB layout should contain per default a compile-window at the bottom (just specify the number of lines which should be used for the compile-window at the bottom of the frame). If “yes” ECB displays all buffers for which the function ecb-compilation-buffer-p returns not nil (e.g. all output of compilation-mode (compile, grep etc.) or all temp-buffers like *Help*-buffers) in this special window.

In general: With the options ecb-compilation-buffer-names, ecb-compilation-major-modes and ecb-compilation-predicates you can define which buffers should be displayed in the compile-window of ECB (for example if you call switch-to-buffer or display-buffer or if you run compile or if you display *Help*-buffers). Per default these are all temp-buffers like *Help*-buffers, all compile- and grep buffers, *Occur*-buffers etc. See the default values of these options.

With the command ecb-toggle-compile-window (bound to C-c . \) you can toggle the visibility of the compile-window (see Interactive ECB commands).

There are some more useful options and commands related to the compile-window of ECB (to see all options for the compile-window see the customization group ecb-compilation):

ECB offers the same compile-window functionality regardless if the ECB-window are hidden or not. The state of the compile-window will be preserved when toggling the ecb-windows or when maximizing one ecb-windows! So you have the advantage of one special window for all help-, grep or compile-output (see above) also when the ecb-windows are hidden - a window which will not be deleted if you call delete-other-windows (bound to C-x 1) for one of the edit-windows. In general: All features of the compile-window work with hidden ecb-windows exactly as when the ecb-windows are visible.

6.4.3 What to do if there are problems with the compile-window

Normally displaying temp- and compilation-buffers (or more general: displaying buffer for which ecb-compilation-buffer-p is not nil) should work reliable. But if there are problems which you can not handle with the options ecb-compilation-buffer-names, ecb-compilation-major-modes or ecb-compilation-predicates then please go on like follows:

  1. Set the option ecb-layout-debug-mode to not nil.
  2. Reproduce the wrong behavior exactly by repeating all the operations which lead to the problem. If possible then restart Emacs before reproducing the problem so you can begin from the beginning!
  3. Now send immediately a bug report with ecb-submit-problem-report.
  4. Set ecb-layout-debug-mode back to nil if you do not want further debugging output in the *Messages* buffer"

6.4.4 Handling special-display-buffers

Emacs offers three options for a special-display-handling of certain buffers: special-display-function, special-display-buffer-names and special-display-regexps (see the Emacs manual for a description of these options). ECB offers an option ecb-ignore-special-display for specification in which situations ECB should take account for the values of these special-display-options.

Default-behavior of ECB is to ignore these special-display-options when a persistent compile-window is active (i.e. ecb-compile-window-height is not nil). But with ecb-ignore-special-display you can tell ECB, that either always the special-display-options should be ignored as long as ECB is active or that they should be never igored regardless if a persistent compile-window is set or not. In the latter case using display-buffer or pop-to-buffer takes always account for the values of these options - like the original behavior of Emacs.


Footnotes

[1] It goes without saying that is is also true for grep-window-height and all other “compile”-modes.