The other window - ECB - the Emacs Code Browser
Description: ECB - the Emacs Code Browser

Next: The Methods window, Previous: Temp- and compile-buffers, Up: Usage of ECB

### 6.5 How the “other window” is determined by ECB

Normally all windows in an Emacs-frame are arranged in a cyclic order and window-selecting-commands like `other-window` or window-scrolling-commands like `scroll-other-window` choose simply the next1 window after the current window as “other window”.

#### 6.5.1 “Other window”-basics in ECB

With a typical window-layout of ECB such a cyclic order of all windows in the ECB-frame does not make sense because it would be not very intuitive and against that what the user wants to “say” when calling `other-window` or `scroll-other-window`.

Therefore ECB divides the whole set of windows of the ECB-frame in several subsets:

- The edit-windows of the edit-area
- The special tree-windows for browsing-tasks
- The compile-window at the bottom (if there is one)
- The minibuffer-window of the ECB-frame (if active)

Each of these subsets will be treated as a cyclic ordered subset, i.e. all windows in each of these subsets are ordered as the function `walk-windows` would visit the windows when the windows of a subset would be the only windows of a frame2.

#### 6.5.2 Builtin “other window” behaviors of ECB

ECB now offers to specify the behavior of commands like `other-window` or `scroll-other-window` within the ECB-frame. This can be done with the option `ecb-other-window-behavior`. This option offers several builtin behaviors:

- All windows of the ECB-frame are considered

  ECB will cycle through all windows of the ECB-frame or scroll simply the next window in the ECB-frame, means it behaves like the original `other-window` rsp. the original `other-window-for-scrolling`.

- Only the windows of the edit-area are considered

  ECB will only cycle through the edit-windows of ECB or only scroll another edit-window. If the selected window is not an edit-window then all windows are taken into account.

- The edit-windows and the compile-window are considered

  Like above but the compile-window will be added to the subset of the edit-windows.

- Behave as smart and intuitive as possible

  This is the default behavior of ECB. ECB tries to choose the `other-window`-destination or the “other window” to scroll in a smart and intuitive way: If point is in one of the edit-windows and if the edit-area is splitted then always the “next” edit-window is choosen (whereas the next edit-window of the last edit-window is the first edit-window)- if the edit-area is unsplitted then the compile-window is used if there is one. In the context of an `other-window`-call the ARG of `other-window` will be taken into account.

  If one of the special ecb-windows is selected then always the “next” ecb-window is choosen (whereas the next ecb-window of the last ecb-window is the first ecb-window). In the context of an `other-window`-call the ARG of `other-window` will be taken into account. If there is only one ecb-window then ECB considers also the edit-windows.

  If the compile-window is selected then always the last edit-window which had the point will be used unless `other-window` has been called with a prefix-argument unequal 1.

Regardless of the different behaviors above ECB handles the situation of an active minibuffer during a call to `other-window` or `scroll-other-window` like follows:

If the minibuffer-window is selected then ECB always chooses the window `minibuffer-scroll-window` points to (when this variable is set, otherwise the compile-window or the last selected edit-window is choosen) when the called command is called to choose the 1. next window (always true for scrolling another window or true when `other-window` called without prefix-arg or with prefix-arg equal 1). Otherwise the window ARG steps away is choosen (in case of `other-window`).

If there is an active minibuffer but the minibuffer-window is not selected then `other-window` and `scroll-other-window` behave like the original version.

#### 6.5.3 User-defined “other window” behavior

In addition to the builtin “other window” behaviors ECB offers a user to completely define for himself how ECB should choose another window for scrolling it or selecting it. This can be done with the option `ecb-other-window-behavior` too because this option can also have a function-symbol as value:

Such a function gets seven arguments:

1. A canonical list of all currently visible windows of the `ecb-frame`
2. A canonical list of all currently visible edit-windows
3. A canonical list of all currently visible ecb-windows
4. The window-object of the compile-window if there is any.
5. The minibuffer-window of the ECB-frame if there is an active minibuffer.
6. The result of the function `ecb-where-is-point` - see the documentation of this function for details.
7. An integer which indicates how many steps away from the current selected window the “other-window” is. Is nil when this function is called in another context than for `other-window`.

The function has to return a window-object which is then used as “other window” for the command `other-window` or for scrolling another window (e.g. with `scroll-other-window`). Such a function has to handle properly all situation for itself.

Here is an example for such a function:

       (defun ecb-get-other-window-smart (win-list
                                          edit-win-list
                                          ecb-win-list
                                          comp-win
                                          minibuf-win
                                          point-loc
                                          nth-window)
         "Implements the smart-setting of `ecb-other-window-behavior'."
         (if minibuf-win
             ;; if we have an active mini-buffer we delegate this to
             ;; `ecb-get-other-window-minibuf-active'
             (ecb-get-other-window-minibuf-active win-list
                                                  edit-win-list
                                                  ecb-win-list
                                                  comp-win
                                                  minibuf-win
                                                  point-loc
                                                  nth-window)
           ;; here we have no active minibuffer!
           (let ((nth-win (or nth-window 1)))
             (cond ((equal point-loc 'ecb)
                    (ecb-next-listelem ecb-win-list (selected-window) nth-win))
                   ((equal point-loc 'compile)
                    (if (= nth-win 1)
                        (or (and ecb-last-edit-window-with-point
                                 (window-live-p ecb-last-edit-window-with-point)
                                 ecb-last-edit-window-with-point)
                            (car edit-win-list))
                      (ecb-next-listelem (append edit-win-list
                                                 (list (selected-window)))
                                         (selected-window)
                                         nth-win)))
                   (t ;; must be an edit-window
                    (ecb-next-listelem (append edit-win-list
                                               (if (and comp-win
                                                        (= (length edit-win-list)
                                                           1))
                                                   (list comp-win)))
                                       (selected-window)
                                       nth-win))))))

This example implements the builtin smart behavior described above.

#### Footnotes

[1] `other-window` allows to select ARG'th different window, i.e. the window ARG steps away from current window in the cyclic order of the windows

[2] `other-window` uses the same window-ordering as `walk-windows`