| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This chapter describes in a detailed manner all aspects of using the Emacs Code Browser.
| 4.1 Working with the mouse in the ECB-windows | Working with the mouse | |
| 4.2 Working with the keyboard in the ECB-windows | Working with the keyboard | |
| 4.3 Working with the edit-window(s) of the edit-area | How to use the edit-area | |
| 4.4 Temp- and compile-buffers display in ECB | Displaying temp- and compilation-buffers | |
| 4.5 How the "other window" is determined by ECB | How the "other window" is determined | |
| 4.6 Using and customizing the ECB-Methods buffer | Using and customizing the Methods-buffer | |
| 4.7 Applying filters to the special ECB-tree-buffers | Applying filters to the ECB-tree-buffers | |
| 4.8 Changing, customizing, redrawing and creating layouts | Changing, customizing, redrawing, creating | |
| 4.9 Hiding/Showing the ECB windows | ||
| 4.10 Maximizing the ECB windows | ||
| 4.11 Back- and forward navigation like a browser | ||
| 4.12 Synchronization of the ECB-windows | Auto./manual synchronizing the ECB-windows | |
| 4.13 Stealthy background-tasks of ECB | ||
| 4.14 Interactive ECB commands | All interactive user-commands of ECB |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Normally you get best usage if you use ECB with a mouse. ECB distinguishes between a primary and a secondary mouse-button.
With the option ecb-primary-secondary-mouse-buttons the following
combinations of primary and secondary mouse-buttons are possible:
If you change this during ECB is activated you must deactivate and activate ECB again to take effect.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A click with the primary button causes the main effect in each ECB-buffer:
ecb-mouse-click-destination.
ecb-mouse-click-destination.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A click with the primary mouse-button while the SHIFT-key is pressed is called the POWER-click and does the following (depending on the ECB-buffer where the POWER-click occurs):
ecb-cache-directory-contents).
ecb-tag-visit-post-actions). But this works only for sources
parsed by semantic, not by imenu or etags!
Per default the complete node-name of an item in a tree-buffer is
displayed in the echo-area if the mouse moves over it, regardless if
the related window is the active one or not. You get the same effect
always after a POWER-click. In general: Via
ecb-show-node-info-in-minibuffer you can specify in a detailed
manner for every ECB tree-buffer when and which node-info should be
displayed in the minibuffer.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The secondary mouse-button is for opening (jumping to) the file in
another edit-window (see the documentation of the option
ecb-mouse-click-destination).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In each ECB-buffer mouse-3 (= right button) opens a special context popup-menu for the clicked item where you can choose several senseful actions.
With the options ecb-directories-menu-user-extension,
ecb-sources-menu-user-extension,
ecb-methods-menu-user-extension and
ecb-history-menu-user-extension you can add statically new
commands to the popup-menus. See the docstring of
ecb-directories-menu-user-extension for more details.
With the options ecb-directories-menu-user-extension-function,
ecb-sources-menu-user-extension-function,
ecb-methods-menu-user-extension-function and
ecb-history-menu-user-extension-function you can add new
commands to the popup-menus in a dynamic manner. See the docstring of
ecb-directories-menu-user-extension-function for more details.
With the options ecb-directories-menu-sorter,
ecb-sources-menu-sorter, ecb-methods-menu-sorter and
ecb-history-menu-sorter you can even re-arrange all the entries
of the popup-menus.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In each tree-buffer of ECB you can easily scroll left and right with
the mouse if the option ecb-tree-easy-hor-scroll is not
nil.
The reason for this is: XEmacs has horizontal scroll-bars so invisible parts beyond the right window-border of a tree-buffer can always made visible very easy.
GNU Emacs does not have hor. scroll-bars so especially with the mouse
it is quite impossible to scroll smoothly right and left. The
functions scroll-left and scroll-right can be annoying
and are also not bound to mouse-buttons.
ECB offers three ways for smoothly hor. scrolling with GNU Emacs if
ecb-tree-easy-hor-scroll is a positive integer-value S:
C-M-mouse-3 are bound to
scrolling left rsp. right with scroll-step window-width - 2.
This is NOT done for XEmacs cause of its horizontal scrollbars. If you want scrolling left and right with the mouse in XEmacs then activate the horizontal scrollbars.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ECB offers the ecb-mode-map which binds the most important
functions of ECB to keys so you can easily use ECB in every
window(14) without
a mouse.
IMPORTANT: Do not modify ecb-mode-map directly! The option
ecb-key-map defines all ECB keybindings, including a common
prefix-key (This is by default C-c .). If there are conflicts
with other minor-modes or packages you can define very easy another
prefix. Please read carefully the description of ecb-key-map
(see section 5.3.1 Group ecb-general).!
The following sections describe special topics about using the keyboard in the ECB-tree-buffers:
| 4.2.1 Navigation and Selection in a tree-buffer | Keyboard navigation/selection in a tree-buffer | |
| 4.2.2 Incremental search for a node in current tree-buffer | Find nodes as fast as possible | |
| 4.2.3 Adding personal keybindings | Adding personal keybindings to a tree-buffer | |
| 4.2.4 Using the popup-menu of a tree-buffer from keyboard. | Using the popup-menus from keyboard. |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In the ECB-buffers RETURN and TAB are the most important keys:
ecb-tree-RET-selects-edit-window and the function
ecb-toggle-RET-selects-edit-window which is bound to C-t
in each tree-buffer of ECB!
The RETURN and TAB keys can not be (re)defined with ecb-key-map!
If you set ecb-tree-navigation-by-arrow to not nil then the left- and
right-arrow keys work in the ECB tree-window in the following smart way:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Each display-able key (e.g. all keys normally bound to self-insert-command)
is appended to the current search-pattern. The tree-buffer tries to jump to the
first node which matching the current search-pattern either as substring or as
prefix (see below). If no match is found then nothing is done. There are some
special keys:
For better overlooking the current search-pattern is shown in the echo area.
After selecting a node with RET the search-pattern is cleared out. With
ecb-tree-incremental-search you can specify if the current search-pattern
must be a real prefix of the node (default) or if any substring is matched.
For faster and easier finding the right node in a ecb-window the incremental search ignores the following non interesting stuff:
This means: Just type in the prefix (rsp. a substring) of a class-,
variable-, method-, directory- or filename and ECB will bring you as
fast as possible to the node you want. Incremental node-search uses
the value of case-fold-search.
Tip: The ecb-minor-mode offers you in the ecb-mode-map
(customizable via ecb-key-map) some keys for selecting every window
of the ecb-frame. This makes window-selection a childīs play. For
example you can jump into the method-window by hitting C-c . gm.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
There are five hooks which can be used for adding personal keybindings to the ECB tree-buffers:
ecb-common-tree-buffer-after-create-hook
ecb-directories-buffer-after-create-hook
ecb-sources-buffer-after-create-hook
ecb-methods-buffer-after-create-hook
ecb-history-buffer-after-create-hook
These hooks are called directly after tree-buffer creation so they can
be used to add personal local keybindings(15) either to all tree-buffers
(ecb-common-tree-buffer-after-create-hook) or just to a certain
tree-buffer. Here is a list which keys MUST NOT be rebound:
ecb-toggle-RET-selects-edit-window.
The following example binds C-a to some useful code in ALL tree-buffers and C-d to even more useful code ONLY in the directories buffer:
(add-hook 'ecb-common-tree-buffer-after-create-hook
(lambda ()
(local-set-key (kbd "C-a")
(lambda ()
(interactive)
(message "ECB is great!")))))
(add-hook 'ecb-directories-buffer-after-create-hook
(lambda ()
(local-set-key (kbd "C-d")
(lambda ()
(interactive)
(message "ECB is wonderful!")))))
|
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
A popup-menu of a tree-buffer can be activated from keyboard with the
command tree-buffer-show-menu-keyboard which is bound to
M-m in every tree-buffer. How the popup-menu is displayed
depends if this command is called with a prefix-argument or not:
If called without a prefix-arg then the popup-menu is displayed graphically as if it would be activated via mouse (for GNU Emacs this works perfectly but for XEmacs there is a bug which results in a wrong menu-position - but the menu itself works also with XEmacs).
If called with a prefix-arg (C-u M-m) then the popup-menu is displayed with the tmm-mechanism (like the Emacs-[menu-bar] is displayed when `tmm-menubar' is called). This tmm-display is only available for GNU Emacs.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
other-window
delete-window
delete-other-windows
delete-windows-on
split-window-horizontally
split-window-vertically
split-window
display-buffer
switch-to-buffer
switch-to-buffer-other-window
other-window-for-scrolling
balance-windows
The behavior of the adviced functions is (slightly simplified):
ecb-compilation-buffer-p will be displayed in the
compile-window.
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!
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
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.
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:
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.
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.
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!
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.
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.
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.
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.
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!
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!
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.
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.
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).
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.
ecb: When called in the ecb-frame then
only the edit-windows are balanced.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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-are will be splitted first 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 compilation output-buffers (e.g. after a compile or
grep) and the variable compilation-window-height.
This is default behavior of ECB. But there is also another way to display such buffers: Using a durable extra window at the bottom of the ECB-frame:
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 section 4.14 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 5.3.8 Group ecb-compilation):
ecb-compile-window-temporally-enlarge you can
allow Emacs to enlarge temporally the ECB-compile-window in some
situations. Please read the comment of this option. See also the
description of the command
ecb-toggle-compile-window-height.
ecb-enlarged-compilation-window-max-height you
specify how ecb-toggle-compile-window-height should
enlarge the compile-window.
ecb-cycle-through-compilation-buffers
(see section 4.14 Interactive ECB commands) you can cycle through all current
open compilation-buffers (in the sense of
ecb-compilation-buffer-p) very fast.
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
ecb-layout-debug-mode to not nil.
ecb-submit-problem-report.
ecb-layout-debug-mode back to nil if you do not want
further debugging output in the *Messages* buffer"
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 durable 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 durable
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 next(16) window after the current window as
"other window".
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
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
frame(17).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
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.
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.
Like above but the compile-window will be added to the subset of the edit-windows.
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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:
ecb-frame
ecb-where-is-point - see the
documentation of this function for details.
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ECB is mostly designed to display parsing information for files supported by semantic. But beginning with version 1.94 it also supports other parsing engines like imenu and etags, so also files not supported by semantic but by imenu/etags can be displayed in the Method-buffer of ECB. Therefore we have to introduce some terminology:
This chapter describes how to use and customize the Methods-buffer of ECB.
| 4.6.1 Possible actions after visiting a tag | ||
| 4.6.2 Explicit and automatic expanding of the ECB-methods-buffer | Explicit and automatic expanding | |
| 4.6.3 Customizing the display of the Methods-buffer | How to customize the Methods-buffer display | |
| 4.6.4 Rebuilding the Methods-buffer | When to rebuild the Methods-buffer |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
You visit a tag by clicking with either the primary oder secondary
mouse-button (or by hitting RET or C-RET if using the
keyboard) onto a node in the Methods-tree-buffer of ECB. This simply
selects the "right" edit-window (depends if clicked with the primary
or secondary button, in how many windows the edit-area is splitted and
the value of ecb-mouse-click-destination) and puts the point
onto the first line of the clicked tag.
But you can define if after this "basic" tag-visit-action more
additional actions should be performed by ECB. You can either use some
of the predefined actions (e.g. highlighting the header-line of the
tag) or define own actions. You can set different actions for
different major-modes. All this is done via the option
ecb-tag-visit-post-actions.
The following actions are currently predefined:
ecb-tag-visit-highlight-tag-header
ecb-tag-visit-smart-tag-start
ecb-tag-visit-recenter
ecb-tag-visit-recenter-top
ecb-tag-visit-goto-doc-start
ecb-tag-visit-narrow-tag
See the documentation of these function for details what they do.
Per default ECB performs the actions
ecb-tag-visit-smart-tag-start and
ecb-tag-visit-highlight-tag-header for all major-modes.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
With the command ecb-expand-methods-nodes (bound to C-c .
x) you can get a fast overlook of the contents of the source-buffer,
because this command allows precisely expanding all tags with a
certain indentation-level. So you can either expand no tags (or with
other words collapse all tags) or expand all tags so see the contents
of a buffer at one glance. Or you can expand exactly that tags of a
certain indentation level.
Which node-types are expanded (rsp. collapsed) by this command
depends for semantic-sources on the options
ecb-methods-nodes-expand-spec and
ecb-methods-nodes-collapse-spec! For non-semantic-sources always
all node-types are expanded/collapsed, i.e. the two options above
takes no effect for these files.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
With the popup-menu of the methods-buffer an even more precise expansion is possible because it allows not only expanding all tags (see above) but offers in addition expanding only the current-node (for which the menu was activated) to an exact level of expansion:
All menu-entries are label with an expansion-"level" whereas level specifies precisely which level of nodes should be expanded. level means the indentation-level of the NODE itself and its (recursive) subnodes relative to the NODE itself.
So a level value X means that all (sub)nodes with an indentation-level <= X relative to NODE are expanded and all other are collapsed.
Examples:
Expanding the current node with the popup-menu ignores the settings in
the options ecb-methods-nodes-expand-spec and
ecb-methods-nodes-collapse-spec!
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
With the option ecb-show-tags you tell ECB how to display tags
of a certain tag-class (see section 4.6.3 Customizing the display of the Methods-buffer). Among other
things you can tell ECB that a certain tag-class should be combined
under an expanded or collapsed bucket-node. But such a setting defines
the expansion-state of such a bucket-node only direct afterwards the
buffer has been (re)parsed, which can occur after opening a file,
after autom. reparsing the buffer via semantic or after manually
rebuilding the methods-buffer of ECB.
The tag-class type (classes, interfaces, enumerations etc.) is
divided into several subtypes by semantic. The subtypes are stings
which names exactly if the tag with tag-class type is a class,
an interface, an enumeration, a typedef etc. With the option
ecb-type-tag-expansion you can tell ECB if these type-tags
should be autom. expanded after (reparsing) a buffer (see above) or if
they should be displayed collapsed - so all its members (methods,
variables etc.) are hidden.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If the option ecb-highlight-tag-with-point is switched on, then
always that node in the method-buffer is highlighted which belongs to
the current semantic-tag under point in the current active
edit-window. But if this node is invisible (probably because its
parent node is collapsed) then no node is highlighted if the auto.
expanding feature is switched off.
You can either switch on this feature with the option
ecb-auto-expand-tag-tree or even easier with the command
ecb-toggle-auto-expand-tag-tree.
There is another option
ecb-expand-methods-switch-off-auto-expand which makes both
explicit and auto. expanding best working together. See the
documentation of this option to get the details.
The autom. expanding feature is only available for semantic-sources!
Previous versions of ECB have always fully expanded the whole tree in the Methods-buffer if the current tag in the source-buffer was not visible in the current tree - e.g. because the variables-bucket was collapsed or the containing type of a tag (e.g. the class of a method) was collapsed. So in most cases much more was expanded as needed to make the current tag visible.
The mechanism of ECB 2.22 and higher only expands the needed parts of the tree-buffer to make the related node visible: First we try to highlight the current tag with current expansion-state of the Methods-buffer. If the node is not visible so the tag can not be highlighted then we go upstairs the ladder of type-tags the current tag belongs to (e.g. we expand successive the nodes of the whole class-hierachy of the current method-tag until the related node becomes visible). If there is no containing type for the current tag then the node of the tag is probably contained in a toplevel-bucket which is currently collapsed; in this case we expand only this bucket-node and try highlighting again. Only if this has still no success then we expand the full tree-buffer and try to highlight the current tag.
There is another option
ecb-auto-expand-tag-tree-collapse-other: If this option is set
then auto. expanding the tag-tree collapses all not related nodes.
This means that all nodes which have no relevance for the currently
highlighted node will be collapsed, because they are not necessary to
make the highlighted node visible. This feature is switched off by
default because if always collapses the complete Methods-tree before
the following highlighting of the node for the current tag expands the
needed parts of the tree-buffer.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The ECB-Methods buffer is probably the most important browsing window offered by ECB. It displays all parsing informations of the current source-buffer (the buffer displayed in the current active edit-window).
Normally ECB gets all informations displayed in this Methods-buffer from the semantic-library - at least for semantic-sources. This library parses auto. the current source-buffer in the edit-window of ECB and returns all information in form of tags to ECB which displays them in a browse-able form in its Method-buffer. See 2.3 ECB Methods-buffer for information how to use the Methods-buffer.
There are several options to customize which tags ECB should display in general, if the tags should be collapsed or expanded, how to fontify them (i.e. syntax-highlighting) and something more.
ecb-show-tags
ecb-show-tags you specify how ECB should
display the tags returned by the semantic parser. Semantic divides its
tags in several so called tag classes. A tag-class is always a
symbol and can be for example type (tags which represent a
class(18), a interface, an enumeration etc.),
function (tags which represent function or methods),
variable (variables and attributes), include
(import-statements) etc. There is no predefined superset of allowed
tag-class-symbols because each language-parser can define its own
tag-classes. But to get an overview of the most common tag-classes see
the default value of the option ecb-show-tags.
With the option ecb-show-tags you can now specify how ECB
should display tags of a certain tag-class in a certain major-mode.
You can tell ECB that all tags of a tag-class X should be
displayed in an expanded bucket and all tags of a tag-class Y
should be displayed in a collapsed bucket and all tags of a tag-class
Z should be displayed flattened (means not contained in a
expandable/collapsable bucket-node). These settings can be made
separately for each major-mode but you can also define a
default-display which takes effect when for a major-mode no special
setting can be found in ecb-show-tags.
For every tag-class you can tell ECB how the tags should be sorted.
ecb-font-lock-tags
ecb-type-tag-display
ecb-tag-display-function
These are the most important options for this topic but it is
recommended to have a look into the customize-group ecb-methods
(see section 5.3.5 Group ecb-methods) and check all the options offered there!
All these options are only relevant for semantic-sources and take no effect for non-semantic-sources!
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
In almost all cases there is NO need to manually rebuild the method-buffer, because it is always done automatically if necessary; the mechanism depends on the sources:
global-semantic-auto-parse-mode switches on autom.
reparsing of semantic-sources.
imenu-auto-rescan. But nevertheless you have to manually
rebuild the Method-buffer (with the autom. updated imenu-tags) via the
command ecb-rebuild-methods-buffer (bound to C-c . r).
Besides for etags-supported non-semantic-sources there exist a few rare scenarios also for the other sources where a complete manual rebuild can be necessary. Here is one example:
Depending on the semantic-version: If an Elisp-file is parsed which contains a defun X in the middle where the closing ) is missing, then semantic parses only until this defun X is reached and you will get an incomplete ECB-method buffer. In such a case you must complete the defun X and then completely reparse the Elisp-file and rebuild the ECB method buffer!
A complete manually rebuild is done by
ecb-rebuild-methods-buffer. For etags-parsed
non-semantic-sources this causes an automatic saving of the
source-buffer because otherwise etags would not operate with the
latest contents!
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To get a fast and good overlook of the contents of a tree-buffer ECB offers a filter-mechanism for the Directories-, Sources-, the History- and the Methods-buffer.
| 4.7.1 Applying filters to the Directories-buffer | ||
| 4.7.2 Applying filters to the Sources-buffer | ||
| 4.7.3 Applying filters to the History-buffer | ||
| 4.7.4 Applying filters to the Methods-buffer |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
With the option ecb-excluded-directories-regexps certain
directories can be excluded from being displayed in the
directories-browser of ECB. This can be done by defining regular
expressions. If the name of a directory matches at least one of the
regexps of this option the directory is not displayed in the
directories-tree-buffer.
The option ecb-sources-exclude-cvsignore allows to exclude
source-files from the sources-tree-buffer if their name is listed in a
so called `.cvsignore'-file. This option is a list of regular
expressions and if a directory-name matches at least one of these
regexps then all files listed in the `.cvsignore'-file of this
directory are not displayed in the sources-tree-buffer.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The command ecb-sources-filter allows to filter these
tree-buffer either by a regular expression or by an extension (e.g.
java, cc, el for java-, c++- rsp elisp-sources). This functionality is
also available via the popup-menu of the Sources-tree-buffer.
The currently applied filter is indicated in the modeline of the related tree-buffer. Applying a new filter replaces an eventually already applied filter.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The option ecb-source-file-regexps allow to specify which
source-files should be displayed and which not. This is done on a
directory-basis, ie. for each directory-regexp the files to display
can be specified. See the documentation of this option for all
details.
In addition to this option you should also know the option
ecb-sources-exclude-cvsignore (see section 4.7.1 Applying filters to the Directories-buffer).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The command ecb-history-filter allows to filter these
tree-buffer either by a regular expression or by an extension (e.g.
java, cc, el for java-, c++- rsp elisp-sources). This functionality is
also available via the popup-menu of the History-tree-buffer.
The currently applied filter is indicated in the modeline of the related tree-buffer. Applying a new filter replaces an eventually already applied filter.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The option ecb-history-exclude-file-regexps allows to exclude
source-files from being historized (ie. displayed in the
History-buffer). Despite the fact that the History-buffer already
excludes all non-file-buffers there can be still buffers which name
you do not wat to be displayed in the history. These are file-buffer
like `TAGS' or `semantic.cache' which store
meta-informations used by Emacs and its tools (etags, semantic etc.).
These files can be excluded via
ecb-history-exclude-file-regexps.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The commands ecb-methods-filter,
ecb-methods-filter-regexp,
ecb-methods-filter-protection,
ecb-methods-filter-tagclass,
ecb-methods-filter-function,
ecb-methods-filter-delete-last,
ecb-methods-filter-nofilter allows to filter the tags/nodes of
the Methods-buffer by several criterias. As for the Sources- and the
History-buffer the same functionality is also available via the
popup-menu of the Methods-buffer.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ecb-methods-filter offers
only the tag-classes of the current mode. This means for sources not
supported by semantic the tag-class filter will not be offered. And
for semantic-supported sources exactly these tag-classes are offered
the semantic-parser for the current major-mode offers. For example
texi-sources can only be filtered by the tag-classes "Definitions"
and "Sections" and java-sources can be filtered by "Methods",
"Variables", "Classes" etc. In general the semantic-variable
semantic-symbol->name-assoc-list is used to get the right
tag-classes.
ecb-show-tokens. If currently some of the above filters are
applied they will be all removed.
Be aware that the tag-list specified by the option
ecb-show-tags is the basis of all filters, i.e. tags which are
excluded by that option will never be shown regardless of the filter
type here!
All tags which match the applied filter(s) will be displayed in the Methods-buffer. Such a filter is only applied to the current source-buffer, i.e. each source-buffer can have its own tag-filters.
These tag-filters can also applied to sources which are not supported by the semantic-parser but "only" by imenu or etags. But because for these sources not all information are avaiable the protection- and tag-class filter are not offered with such "non-semantic"-sources. See 8.14 Parsing and displaying non-semantic sources for further details about working with source-files not supported by the semantic-parser.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
But if ecb-methods-filter is called with a prefix-argument then
an inverse filter is applied to the Methods-buffer, i.e. all tags
which do NOT match the choosen filter will be displayed in
the Methods-buffer!
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Per default the choosen filter will be applied on top of already
existing filters. This means that filters applied before are combined
with the new filter. This behavior can changed via the option
ecb-methods-filter-replace-existing.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The current active filter will be displayed in the modeline of the Methods-buffer [regexp, prot (= protection), tag-class, function (= filter-function)]. If an inverse filter has been applied then this is signalized by a preceding caret ^. If currently more than 1 filter is applied then always the top-most filter is displayed in the modeline but the fact of more than 1 filter is visualized by the number of the filters - included in parens. You can see all currently applied filters by moving the mouse over the filter-string in modeline of the Methods-buffer: They will displayed as help-echo.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The new option ecb-default-tag-filter allow to define default
tag-filters for certain files which are applied automatically after
loading such a file into a buffer. The possible filters are the same
as offered by the command ecb-methods-filter and they are
applied in the same manner - the only difference is they are applied
automatically. The files can be specified on a combined major-mode-
and filename-regexp-basis.
Usage-example: This can be used to display in outline-mode files (e.g. `NEWS') only the level-1-headings by defining a filter regexp "^\* .*".
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The term ECB-layout means in which windows the ECB-frame is divided. This chapter describes all aspects concerning this layout, especially changing, customizing, redrawing and also creating new layouts.
| 4.8.1 Changing and customizing the ECB-layout | How to change and customize the layout | |
| 4.8.2 Redrawing the ECB-layout | How and when redrawing the layout | |
| 4.8.3 Changing the sizes of the special ECB-windows | Changing sizes of the ECB-windows | |
| 4.8.4 Fixing the sizes of the special ECB-windows | Fixing sizes of the ECB-windows | |
| 4.8.5 Interactively creating new layouts |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ECB offers several predefined layouts with different sets and also different locations of ECB-windows. See below the "ascii-screenshot" of all currently built-in layouts(19).
In addition to these predefined layouts you can either interactively
create new layouts "by example" (see section 4.8.5 Interactively creating new layouts)
or program new layouts with the macro ecb-layout-define
(see section 9.5 How to program new layouts and new special windows). The former method is the recommended
one!
There are two ways to interactively change the layout:
ecb-layout-name and store it for future
Emacs sessions.
ecb-toggle-layout-sequence and the command
ecb-toggle-layout (see section 8.4 Simulating speedbar without an extra frame). For just
selecting another layout during current Emacs-session use the command
ecb-change-layout.
With the option ecb-show-sources-in-directories-buffer you can
define if sources are displayed in the directory-window of a layout
(see section 2.1 ECB Directories-buffer).
In addition to the general layout you can specify if the layout should
contain a durable compilation-window at the bottom of the frame, see
ecb-compile-window-height (see section 4.4 Temp- and compile-buffers display in ECB).
Maybe you want also change the look&feel of the tree-buffers. Then you
can change the general style of the tree-buffers with the option
ecb-tree-buffer-style and the location of the collapse- and
expand-symbols and the indentation of sub-nodes in a tree. See
ecb-tree-indent and ecb-tree-expand-symbol-before. More
details about the different tree-buffer-styles are described in
8.17 Displaying the trees of the ECB-windows with different styles.
Here are all currently available layouts (for creating own new layouts
see 4.8.5 Interactively creating new layouts); just customize the option
ecb-layout-name to the related name:
------------------------------------------------------- | | | | Directories | | | | | | | | | | | |--------------| | | | | | | Sour | Hist | Edit | | | | | | | | | |--------------| | | | | | Methods | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | | | | | | Directories | | | | | | | | | | | |--------------| Edit | | | | | | | | | | | Sources | | | | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | Directories | | | | | | | | | | | |--------------| | | | | | Sources | Edit | | | | | | | |--------------| | | | | | Methods | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | | | | | | Directories | | | | | | | | | | | |--------------| Edit | | | | | | | | | | | | | | Sour | Hist | | | | | | | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | Directories | | | | | | | | | | | |--------------| | | | | | Sources | Edit | | | | | | | |--------------| | | | | | History | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | Directories | | | | | | | | |--------------| | | | | | | | Edit | Sources | | | | | | | | |--------------| | | | | | Methods | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | Sources | | |--------------| | | | | | | | | | | | Methods | Edit | | | | | | | | | | |--------------| | | History | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | | | | | Directories | Sources | Methods | | | | | | | | | |-----------------------------------------------------| | | | | | | | | | Edit | | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | Directories | | | | | | | | | | | | | | | | | |--------------| Edit | | | | | History | | | | | |--------------| | | | | | Methods | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | Directories | | | | | |--------------| | | | | | Sources | | | | | |--------------| Edit | | | | | Methods | | | | | | | | |--------------| | | History | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | Methods | | | | | |-----------------------------------------------------| | | | | | | | | | Edit | | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | | | | | | | | | | | | | | | | | | Methods | Edit | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | | | | | | Methods | Edit | | | | | | | | | | | | | | | | |--------------| | | | | | | Sou | Hist | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | | | | | | Methods | Edit | | | | | | | | | | | | | | | | |--------------| | | | | | History | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | | | | | | | | | | | | | | | | | | History | Edit | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | | | | | | | | | | | | | | | | | | Directories | Edit | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | | | | | | Directories | Edit | | | | | | | | | | | | | | | | |--------------| | | | | | History | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | Directories | | | | | | | | | | | | | | | | | |--------------| Edit | | | | | | | | | | | Methods | | | | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | Directories | | Methods | | | | | | | | | | | | | | | | | | | | | |-------------| Edit | | | | | | | Sources | | | | | | | |-------------| | | | | | | | History | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | Directories | | Methods | | | | | | | | | | | | | | | | | | | | | | | Edit | | |-------------| |-------------| | | | | | Sources | | History | | | | | | | | | | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | | Directories | | Methods | | | | | | | | | | | | | | | | | | | | | | | Edit | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
------------------------------------------------------- | | | | Directories | | | | | | | | | | | | | | | | | |-------------| | | | | | | | | | | | Speedbar | | | | | | | | | | | ------------------------------------------------------- | | | Compilation | | | ------------------------------------------------------- |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you have unintentionally destroyed the ECB-layout, you can always
restore the layout with calling ecb-redraw-layout. This is even
true, if you get messages like "wrong-type-argument window-live-p
#<window 222>".
If the variable ecb-redraw-layout-quickly is not nil then the redraw
is done by the ecb-redraw-layout-quickly function, otherwise by
ecb-redraw-layout-full. But it's strongly recommended to use the
quick redraw only if you have really slow machines where a full redraw
takes several seconds because the quick redraw is not really safe and
may have some drawbacks! On normal machines the full redraw should be
done in << 1s!
Please read the documentation of the command ecb-redraw-layout!
See also the hooks ecb-redraw-layout-after-hook and
ecb-redraw-layout-before-hook!
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The standard width and height of the special ECB-windows is defined
with the options ecb-windows-width and
ecb-windows-height. But changing these options always
influences all layouts which is not always desired.
ECB offers to re-adjust the width and height of the ECB-windows (e.g. by dragging the windows-borders via the mouse) and then saving exactly these current window-sizes for the current layout so after activating this layout all windows have autom. the stored sizes.
This is done via the option ecb-layout-window-sizes and the
commands ecb-store-window-sizes,
ecb-restore-window-sizes and
ecb-restore-default-window-sizes.
Here is an example how to resize and store the sizes of the ECB-windows of layout "left1":
ecb-change-layout (C-c . lc)
ecb-store-window-sizes
After this layout "left1" will be always drawn with the new sizes
until you call ecb-restore-default-window-sizes during layout
"left1" is active.
Please note: ecb-store-window-sizes stores the width
and height of the windows per default as fractions of the width (rsp.
height) of the ECB-frame, so the stored sizes are always correct
regardless of the current frame-size! But if called with a prefix
argument then fixed sizes are stored.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GNU Emacs 21 introduced a new feature which can fix the sizes of a
window displaying a certain buffer even after resizing the frame. This
new feature is driven by the new buffer-local variable
window-size-fixed.
ECB offers an option ecb-fix-window-size for fixing the sizes
of the special ECB-windows/buffers even after frame-resizing. The fix
type (valid values are nil, t, width and
height) can either be set on a layout-basis (means a different
value for each layout) or one value can be set for all layouts. In the
latter case there is an additional value auto which choose
autom. the senseful fix-type depending on the current layout-type: For
top-layouts the fix-type height and for all other layout-types
the fix-type width.
Probably the most senseful value is auto for all layouts
because it makes less sense to fix the height of the ecb-windows in a
left-, right- or leftright-layout. Same for fixing the width in a
top-layout.
Note: With current Emacs 21.2.X there seems to be no distinction
between width, height and t. Therefore this
option takes no effect (means all ecb-windows have always unfixed
sizes) if ecb-compile-window-height is not nil.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
If you want to create your own ECB-layout then you can do this very
easy "by example" with the command ecb-create-new-layout.
This command creates a new empty frame and offers a small set of keys
to create the new layout by splitting windows.
ecb-create-new-layout and this couple of keys are your guide
during the layout-creation-process(20).
After calling ecb-create-new-layout you will be asked which
type of layout you want to create: "left", "right", "top" or
"left-right". Here you specify where the ECB-tree-windows/buffers
should be located in the ECB-frame:
Depending on the type you choose the window is splitted by the values
of the options ecb-windows-width (types "left", "right" and
"left-right") or ecb-windows-height (type "top").
Afterwards you will see a frame like follows (here the layout-type is "left-right"):
-----------------------------------------------------------------
|<point> | | |
| | ECB-layout creation mode | |
| | ======================== | |
| | | |
| | <This is a durable help-screen> | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
-----------------------------------------------------------------
|
| ,---
`---| Splitted by the value of |
The big window (here the middle window) will be the edit-area of the new layout and can not be selected, deleted or splitted during the creation process. It displays the help-screen for the layout-creation mode. Here all the available commands are displayed.
The small window(s) (here the left and right windows) can be splitted by you wherever you want (C-s). The left one contains the point. You must give every ECB-tree-window you create a type (C-t) which can be either
This can be either "directories", "sources", "methods", "history" or "speedbar".
In this case you insert "other" after hitting C-t and you will
then be asked for the name of the user-defined type. You can insert
any arbitrary type name X. But to get this layout working you have to
define a function with name ecb-set-X-buffer whereas X is the
name of the user-defined type you have specified during
layout-creation.
This function ecb-set-X-buffer has first to switch to the
buffer you want to display in this window and then making this window
dedicated. You have to use the macro ecb-with-dedicated-window
in such a function!
Here is an example: Suppose you have inserted as type name "example"
then you have to define and load a function
ecb-set-example-buffer which could be defined like follows:
(defun ecb-set-example-buffer ()
(ecb-with-dedicated-window
" *ECB example-buffer*"
'ecb-set-example-buffer
(switch-to-buffer (get-buffer-create " *ECB example-buffer*"))))
|
If you forget to define such a function for the user-defined type then
nevertheless ECB will draw this layout but it will use the
default-function ecb-set-default-ecb-buffer instead.
If you are satisfied with your new layout just hit C-q. You will
be asked for a new layout-name (TAB-completion is offered to get a
list of all names already in use) and after inserting a new(!) name
the new layout is saved in the file defined by the option
ecb-create-layout-file. The new layout is now available via the
option ecb-layout-name.
There is no need for you to load the file
ecb-create-layout-file manually into your Emacs because it's
automatically loaded by ECB!
Please note: During the layout-creation process only the commands displayed in the help-screen are available. ALL other commands are temporally disabled (even the mouse-commands).
For programming new layouts with emacs-lisp see 9.5 How to program new layouts and new special windows.
With the command ecb-delete-new-layout you can delete
previously created layouts (TAB-completion is offered for all names of
user created layouts).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
With ecb-toggle-ecb-windows, ecb-hide-ecb-windows and
ecb-show-ecb-windows you can hide/show all the ECB windows
without changing the activation state of ECB and also without
deactivating the advices for delete-other-windows and/or
delete-window. This is most useful if you use a layout like
"top2" (see section 8. Tips and tricks) or if you want to have maximum space
for editing and you don't need the browsing windows all the time.
The following sequence of hooks is evaluated during showing again the hidden ECB-windows:
ecb-show-ecb-windows-before-hook
ecb-redraw-layout-before-hook
ecb-redraw-layout-after-hook
ecb-show-ecb-windows-after-hook
The following sequence of hooks is evaluated during hiding the ECB-windows:
ecb-hide-ecb-windows-before-hook
ecb-redraw-layout-before-hook
ecb-redraw-layout-after-hook
ecb-hide-ecb-windows-after-hook
If the special ECB-windows are hidden (e.g. by `ecb-toggle-ecb-windows') all adviced functions behave as their originals. So the frame can be used as if ECB would not be active but ECB IS still active in the "background" and all ECB-commands and all ECB-keybindings can be used. Of course some of them doesn't make much sense but nevertheless they can be called. Toggling the visibility of the ECB-windows preserves the splitting-state of the edit-area: If you hide the ECB-windows then the frame will be divided in the same window-layout the edit-area had before the hiding and if you show the ECB-windows again the edit-area will be divided into all the edit-windows the ECB-frame had before the showing.
Therefore it should be enough to hide the ECB-windows to run other Emacs-applications which have their own window-layout-managing. There should be no conflicts. But nevertheless the most recommended method for running ECB and other applications (e.g. xrefactory, Gnus etc.) in the same frame is to use a window-manager like winring.el or escreen.el (see section 8.16 Support of several Emacs-window-managers).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
To get a better overlook about the contents of a certain ECB-window every ECB-window can be "maximized", means all other ECB-windows are deleted so only the edit-window(s) and this maximized ECB-window are visible (and maybe a compile-window if active). There are several ways to do this:
delete-other-windows(21) (bound to C-x 1) in one of
the ECB windows.
ecb-maximize-window-directories,
ecb-maximize-window-sources, ecb-maximize-window-methods,
ecb-maximize-window-history or
ecb-maximize-window-speedbar or the bound short-cuts for those
commands.
ecb-cycle-maximized-ecb-buffers which
cycles through all ecb-buffers of current layout by maximizing exactly
one of the ecb-windows after every cycle-step.
ecb-maximize-ecb-window-after-selection and then
just by selecting an ECB-window. "Deselecting" an ECB-window brings
back all ECB-windows of current layout.
delete-other-window. ECB now supports this mechanism by binding
a toggle-command to mouse-2 in the modeline of each tree-buffer:
If all ECB-windows are visible then this command maximizes the current
tree-window and if current tree-window is maximized all ECB-windows
are displayed again. XEmacs binds a popup-menu with some window
commands to button-3 in its modeline. ECB supports this
mechanism by replacing this menu by a menu which offers exactly 2
commands: Maximizing current tree-window and displaying all
ECB-windows.
Minimizing such a maximized ECB-window, i.e. bringing back to its
original size, can simply be done by redrawing the layout via the
command ecb-redraw-layout (bound to C-c . lr).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
With ECB you can "browse" in your source-files like with a web-browser. This means ECB stores the current buffer- and window-position relative to the current tag(22) in the edit-window after
ECB offers two commands ecb-nav-goto-next (C-c . n) and
ecb-nav-goto-previous (C-c . p) to go forward and
backward within this navigation history-list. These commands are also
available via the menu "ECB --> Navigate".
Aside normal "location-browsing" this is useful for example in a
scenario where the buffer is narrowed to a tag (see
ecb-tag-visit-post-actions):
Now you will edit at the same place in the function.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Per default ECB synchronizes automatically the contents of the ECB-windows/tree-buffers with the current active edit-window (rsp. the current buffer of the edit window):
This windows is synchronized to display the directory where the
source-file which is displayed in the current active edit-window is
located. If the source-path (i.e. an element of the option
ecb-source-path) containing this directory is not expanded it
will be auto. expanded according to the value of the option
ecb-auto-expand-directory-tree (see section 5.3.3 Group ecb-directories).
The ECB-sources-buffer contains after synchronizing all the sources of the directory of the "current" source-file displayed in the edit-window. The entry of the "current" source-file is highlighted.
Contains after synchronizing all the tags of the buffer in the current selected edit-window, i.e. all methods, variables etc... depending of the major-mode.
Highlights the entry of the buffer displayed in the current active edit-window if this buffer is a source-file.
This feature can be customized with the option ecb-window-sync:
If active then the synchronization takes place always a buffer changes in an edit window or if another edit-window with another buffer will be selected, if deactivated then never. But you can also set this option to a list of major-modes and then the sync. will only be done if the major-mode of the current buffer belongs NOT to this list.
But in every case the synchronization takes only place if the
major-mode of the current-buffer in the current selected edit-window
has a relation to files or directories. Examples for the former one
are all programming-language-modes like c++-mode or
java-mode, Info-mode too, an example for the latter one
is dired-mode. For all major-modes related to
non-file/directory-buffers like help-mode,
customize-mode and others never a synchronization will be done!
It's recommended to exclude at least Info-mode because it makes
no sense to synchronize the ECB-windows after calling the Info help.
Per default also dired-mode is excluded but it can also making
sense to synchronize the ECB-directories/sources windows with the
current directory of the dired-buffer in the edit-window.
If you often need to toggle between autom. synchronization on and off
then customizing the option ecb-window-sync is inefficient and
therefore ECB offers the command ecb-toggle-window-sync.
Please note: With the command ecb-window-sync you can
do a manually synchronization if the automatic one is switched off or
if you just want to do this!
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ECB performs some tasks stealthy in the background and also interruptable by the user because these tasks can be time-consuming and could otherwise block ECB. Currently the following tasks are performed stealthy and in the background by ECB:
ecb-prescan-directories-for-emptyness for a description.
ecb-sources-perform-read-only-check.
ecb-vc-enable-support.
All of these tasks (e.g. checking if a directory is empty or not) perform a certain action for all directories or sources displayed in the current visible tree-buffers of ECB. Normally there should be no annoying delay for the user because each of these tasks will be only performed when Emacs is idle and will be interrupted immediatelly when a user hits a key or clicks the mouse but especially for remote-directories one single action (e.g. checking if a certain directory is empty or checking the VC-state of a sourcefile in such a remote directory) can be very time-consuming and such a single action is not interruptable (an interrupt can only occur between the single-actions for two directories or sources) For a further discussion how to deal best with remote directories see 8.8 Working with remote directories.!
ECB offers for all stealthy tasks three steps of activation:
t:
Switch on this feature.
unless-remote:
Switch on this feature but not for remote directories. The term
"remote" means here directories which are used via tramp, ange-ftp
or efs. So mounted directories are counted not as remote directories
here even if such a directory is maybe hosted on a remote machine. But
normally only directories in a LAN are mounted so there should be no
performance-problems with such mounted directories.
nil:
Switch off this feature completely.
In combination with the option ecb-stealthy-tasks-delay these
three choices allows already adapting the stealthy tasks to most
needs. But to offer finest granularity for which directories a certain
stealthy task should be switched on and for which not ECB offers for
every stealthy task an additional option which allows a finer
adjustment:
ecb-prescan-directories-exclude-regexps.
ecb-read-only-check-exclude-regexps
ecb-vc-directory-exclude-regexps
These options take only effect when the related task is not completely switched off but then they allow excluding certain directories (or the sources of directories) from being processed by a certain stealthy task.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
ECB offers a lot of interactive commands. Some of these commands prompt the user in the minibuffer if called with a prefix argument.
Example: If ecb-clear-history is called with a prefix argument
then you will be prompted in the minibuffer with:
Clear from history: [all, not-existing-buffers, existing-buffers] |
You can choose one of the options enclosed in brackets with TAB-completion; hitting RET direct after the prompt chooses auto. the first offered option (in the example above "all").
Please note: The following interactive commands of ECB are
listed without the prefix "ecb-" (e.g. the command
ecb-activate is listed with name "activate"). This has been
done for a better readable command index. See section Command Index.
ecb-layout-name. This function raises always
the ECB-frame if called from another frame. This is the same as
calling ecb-minor-mode with a positive argument.
ecb-history-sort-method afterwards the history
is sorted either by name or by extension. If
ecb-history-sort-method is nil the most recently used buffers
are on the top of the history and the seldom used buffers at the
bottom.
ecb-layout-name but
only for current Emacs-session.
ecb-compile-window. If the
currently opened buffer within the compilation window is not a
compilation buffer, we jump to the first compilation buffer. If not we
try to loop through all compilation buffers. If we hit the end we go
back to the beginning.
If CHOOSE-BUFFER is not nil then the user will be
prompted for the compilation-buffer to switch to.
ecb-create-new-layout and delete this layout. This means the
layout-definition is removed from the file
ecb-create-layout-file and the layout-function and associated
aliases are unbound.
If FULL-NEWS is not nil then the NEWS-file is displayed in another window.
If saving is possible this command display where the options would be
saved. It is that file Emacs uses to save customize-settings. This
file is "computed" from the settings in custom-file and
user-init-file (see the documentation of these variables).
ECB automatically makes a backup-file of that file which will be modified by storing the upgraded rsp. renamed ECB-options. This backup file gets a unique name by adding a suffix ".before_ecb_<version>" to the name of the modified file. If such a file already exists ECB adds a unique number to the end of the filename to make the filename unique. This is a safety mechanism if something fails during storing the upgraded options, so you never lose the contents of your customization-file!
ecb-download-url must be set correct, whereas the default value of
this option should always be correct.
If ecb-download-package-version-type is set to -1 (means asking
for a version) then you will be ask in the minibuffer for the version
to download. Otherwise ECB downloads autom. the latest version
available for the type specified in
ecb-download-package-version-type. If no newer version than the
current one is available no download will be done.
For details about downloading and what requirements must be satisfied
see function ecb-package-download and option
ecb-download-package-version-type!
After successful downloading the new ECB will be installed in a
subdirectory of ecb-download-install-parent-dir. After adding
this subdirectory to load-path and restarting Emacs the new ECB
version can be activated by ecb-activate.
If current running ECB is installed as regular XEmacs-package and not with the archive available at the ECB website then this function asks for proceeding!
ecb-cedet-url must be set correct,
whereas the default value of this variable should always be correct.
If ecb-download-package-version-type is set to -1 (means asking
for a version) then you will be ask in the minibuffer for the version
to download. Otherwise ECB downloads autom. the latest version
available for the type specified in
ecb-download-package-version-type. If no newer version than the
current one is available no download will be done.
For details about downloading and what requirements must be satisfied
see function ecb-package-download and option
ecb-download-package-version-type!
After successful downloading the new semantic will be installed in a
subdirectory of ecb-download-install-parent-dir. After adding
this new subdirectory to load-path and restarting Emacs the new
semantic version is loaded and is used after next start of ECB.
If current running semantic is installed as regular XEmacs-package and not with the archive available at the semantic website then this function asks for proceeding!
This command asks in the minibuffer for an indentation level LEVEL. With this LEVEL you can precisely specify which level of nodes should be expanded. LEVEL means the indentation-level of the nodes.
A LEVEL value X means that all nodes with an indentation-level <= X are expanded and all other are collapsed. A negative LEVEL value means all visible nodes are collapsed.
Nodes which are not indented have indentation-level 0!
Which node-types are expanded (rsp. collapsed) by this command
depends on the options ecb-methods-nodes-expand-spec and
ecb-methods-nodes-collapse-spec! With optional argument
FORCE-ALL all tags will be expanded/collapsed regardless of
the values of these options.
Examples:
Note 1: This command switches off auto. expanding of the method-buffer
if ecb-expand-methods-switch-off-auto-expand is not nil. But it
can be switched on again quickly with
ecb-toggle-auto-expand-tag-tree or [C-c . a].
Note 2: All this is only valid for file-types parsed by semantic. For
other file types which are parsed by imenu or etags (see
ecb-process-non-semantic-files) FORCE-ALL is always true!
ecb-eshell-synchronize is not nil.
ecb-expand-methods-nodes.
Be aware that for deep structured paths and a lot of source-paths this command can last a long time - depending of machine- and disk-performance.
ecb-compile-window.
ecb-use-speedbar-instead-native-tree-buffer is dir then
goto to the speedbar-window.
ecb-mouse-click-destination is set to
last-point.
ecb-use-speedbar-instead-native-tree-buffer is method
then goto to the speedbar-window.
ecb-use-speedbar-instead-native-tree-buffer is source
then goto to the speedbar-window.
jde-complete)!. The source-file is searched first in
jde-sourcepath, then in jde-global-classpath, then in
$CLASSPATH, then in current-directory.
Works only for classes where the source-code (i.e. the *.java-file) is available.
semantic--symbol->name-assoc-list. The are normally methods,
variables etc.
ecb-show-tokens. If currently some of the above filters are
applied they will be all removed.
The protection-, current-type- and the tag-class-filter are only available for semantic-supported sources.
Be aware that the tag-list specified by the option
ecb-show-tags is the basis of all filters, i.e. tags which are
excluded by that option will never be shown regardless of the filter
type here!
All tags which match the applied filter(s) will be displayed in the Methods-buffer.
If called with a prefix-argument or when optional arg INVERSE is not nil then an inverse filter is applied to the Methods-buffer, i.e. all tags which do NOT match the choosen filter will be displayed in the Methods-buffer!
Per default the choosen filter will be applied on top of already
existing filters. This means that filters applied before are combined
with the new filter. This behavior can changed via the option
ecb-methods-filter-replace-existing. But regardless of the
setting in ecb-methods-filter-replace-existing applying one of
the not-inverse filters protection, tag-class or current-type always
replaces exactly already existing filters of that type. On the other
hand applying more than one inverse tag-class- or protection-filter
can make sense.
Such a filter is only applied to the current source-buffer, i.e. each source-buffer can have its own tag-filters.
The current active filter will be displayed in the modeline of the Methods-buffer [regexp, prot (= protection), tag-class, function (= filter-function)]. If an inverse filter has been applied then this is signalized by a preceding caret ^. If currently more than 1 filter is applied then always the top-most filter is displayed in the modeline but the fact of more than 1 filter is visualized by the number of the filters - included in parens. You can see all currently applied filters by moving the mouse over the filter-string in modeline of the Methods-buffer: They will displayed as help-echo.
See the option ecb-default-tag-filter if you search for
automatically applied default-tag-filters.
ecb-methods-filter.
ecb-methods-filter.
ecb-methods-filter.
ecb-methods-filter.
ecb-methods-filter.
ecb-methods-filter.
ecb-methods-filter.
nil if the minor mode is
enabled.
Examples when a call to this function can be necessary:
ecb-process-non-semantic-files) because for these
buffers there is no built-in auto-rebuild mechanism. For these buffers
this command calls ecb-rebuild-methods-buffer-for-non-semantic.
For non-semantic-sources supported by etags the option
ecb-auto-save-before-etags-methods-rebuild is checked before
rescanning the source-buffer and rebuilding the methods-buffer.
If point is in one of the ecb-windows or in the compile-window then this command rebuids the methods-buffer with the contents of the source-buffer the last selected edit-window.
Do not call this command from elisp-program but only interactively!
Called without a prefix-argument the state of the ECB-frame-layout will preserved. This means:
ecb-compile-window-height.
ecb-windows-width and ecb-windows-height) or
as stored with ecb-store-window-sizes.
If called with ONE prefix-argument ([C-u]) then the layout will
be drawn with all ECB-windows and also with a visible compile-window
(when ecb-compile-window-height is not nil). The
splitting-state of the edit-area will be preserved.
If called with TWO prefix-arguments (i.e. hitting [C-u] twice: ([C-u] [C-u]) then an emergency-redraw will be performed. This means the same as if called with one prefix-argument (s.a.) but the splitting-state of the edit-area will NOT be preserved but all edit-windows besides the current one will be deleted. Use this only if there are some anomalies after standard redraws!
If the variable ecb-redraw-layout-quickly is not nil then the
redraw is done by the ecb-redraw-layout-quickly function,
otherwise by ecb-redraw-layout-full.
Please not: It's strongly recommended to use the quick redraw only if you have really slow machines where a full redraw takes several seconds because the quick redraw is not really safe and has some annoying drawbacks! On normal machines the full redraw should be done in << 1s so there should be no need for the quick version!
ecb-layout-window-sizes and command
ecb-store-window-sizes.
ecb-frame if ECB is activated - otherwise reports
an error.
ecb-show-help-format. If called with
prefix argument, i.e. if FORMAT is not nil then the user is
prompted to choose the format of the help (Info or HTML). If an error
about not finding the needed help-file occurs please take a look at
the options ecb-help-info-start-file and
ecb-help-html-start-file!
Note: If you got ECB as a standard XEmacs-package maybe the HTML-online-documentation is not included.
ecb-tip-of-the-day is not nil or if
called interactively.
ecb-source-file-regexps and
ecb-sources-exclude-cvsignore).
Such a filter is only applied to the current selected directory, i.e. each directory has its own filtered sources-buffer.
ecb-redraw-layout or ecb-restore-window-sizes is called.
To reset the window sizes to their default values call
ecb-restore-default-window-sizes. Please read also the
documentation of ecb-layout-window-sizes!
The windows sizes are stored per default as fractions of current
frame-width and -height of the ecb-frame, so the stored values will
"work" for other frame sizes too. If a permanent compile-window is
visible then ECB will tell you that window-sizes should be stored with
hidden compile-window and ask you if you want proceed; if you proceed
then the window-heights will be stored as fractions of current
(frame-height minus current visible compile-window-height) so you
should ensure that the current compile-window has its standard-height
as specified in ecb-compile-window-height!. If FIX is not
nil (means called with a prefix argument) then always the fixed values
of current width and height are stored!
ecb-auto-expand-tag-tree is saved so it can be used for
the next switch on by this command.
ecb-compile-window-height! If called and
ecb-compile-window-height is nil then ECB asks for the height
of the compile-window, sets this height as new value of
ecb-compile-window-height and displays the compile-window (so
if you have called this command by mistake and you do not want a
compile-window you have to quit with C-g).
ecb-compile-window is enlarged or not. If
ARG > 0 then shrink or enlarge the the compile-window according
to the value of ecb-enlarged-compilation-window-max-height. But
never shrink below the value of ecb-compile-window-height. If
ARG <= 0 then shrink ecb-compile-window to
ecb-compile-window-height and if ARG is nil then toggle
the enlarge-state.
ecb-toggle-layout-sequence (See also option
ecb-show-sources-in-directories-buffer). Note: This function
works by changing the options ecb-layout-name but only for
current Emacs-session.
If optional argument LAST-ONE is not nil (e.g. called with a
prefix-arg) then always the last selected layout was choosen
regardless of the setting in ecb-toggle-layout-sequence. The
last selected layout is always that layout which was current direct
before the most recent layout-switch. So now a user can switch to
another layout via `ecb-change-layout' and always come back to his
previous layout via [C-u] ecb-toggle-layout.
ecb-scroll-other-window-scrolls-compile-window. With prefix
argument ARG, set it to t, otherwise to nil. For
all details about the scroll-behavior of scroll-other-window
see the advice documentation of other-window-for-scrolling.
ecb-window-sync is saved so it can be used for the
next switch on by this command. See also the option
ecb-window-sync.
Depending on the contents of current buffer this command performs different synchronizing tasks but only if ECB is active and point stays in an edit-window.
In addition to this the hooks in ecb-current-buffer-sync-hook
run.
Most of these functions are also available via the menu "ECB" and
also via the ECB key-map with prefix C-c . (see
ecb-minor-mode for a complete list of the keybindings).
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by XEmacs shared group account on December, 19 2009
using texi2html 1.65.