Deprecated: The each() function is deprecated. This message will be suppressed on further calls in /home/zhenxiangba/zhenxiangba.com/public_html/phproxy-improved-master/index.php on line 456
This is ecb.info, produced by makeinfo version 4.2 from ecb.texi. INFO-DIR-SECTION GNU Emacs Lisp START-INFO-DIR-ENTRY * ECB: (ecb). Emacs Code Browser END-INFO-DIR-ENTRY  File: ecb.info, Node: The edit-window, Next: Temp- and compile-buffers, Prev: Using the keyboard, Up: Usage of ECB Working with the edit-window ============================ ECB offers you all what you need to work with the edit-window as if the edit-window would be the only window 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' The behavior of the adviced functions is (slightly simplified): * All these adviced functions behaves exactly like their corresponding original functions but they always act as if the edit-window(s) of ECB would be the only window(s) of the ECB-frame. So the edit-window(s) of ECB seems to be a normal Emacs-frame to the user. * If there is a durable compile-window (*note Temp- and compile-buffers::) then all compilation-buffers in the sense of `ecb-compilation-buffer-p' will be displayed in the compile-window. * If called in another frame than the ECB-frame these functions behave exactly like the not adviced original versions! ATTENTION: If you want to work within the edit-window with splitting and unsplitting the edit-window(s) it is highly recommended to use the adviced-functions of ECB instead of the original Emacs-functions (see above). Per default ECB advices all of the functions mentioned above but with the option `ecb-advice-window-functions' you can customizes which functions should be adviced by ECB. Please read carefully the documentation of this option! Another interesting option in the context of the edit-window and these adviced functions is `ecb-layout-always-operate-in-edit-window'! Documentation of the adviced window functions --------------------------------------------- This section describes for every adviced window function (s.a.) how it differs from the original version. Only the differences are mentioned, so if you want the full documentation of such a function call `describe-function' or `C-h f'. - Command: other-window ARG &optional ALL-FRAMES Around-advice `ecb': The ECB-version of `other-window'. Works exactly like the original function with the following ECB-adjustment: The behavior depends on `ecb-other-window-jump-behavior'. - Command: delete-window &optional WINDOW Around-advice `ecb': The ECB-version of `delete-window'. Works exactly like the original function with the following ECB-adjustment: If optional argument WINDOW is nil (i.e. probably called interactively): If called in a splitted edit-window then it works like as if the two parts of the splitted edit window would be the only windows in the frame. This means the part of the splitted edit-window which contains the point will be destroyed and the other part fills the whole edit-window. If called in an unsplitted edit-window then nothing is done. If called in any other window of the current ECB-layout there are two alternatives: - If the function is contained in `ecb-layout-always-operate-in-edit-window' it jumps first in the (first) edit-window and does then itīs job. - Otherwise an error is reported. If optional argument WINDOW is a live window (i.e. called from program): If WINDOW is an edit-window then this window is deleted, otherwise an error is reported. - Command: delete-other-windows &optional WINDOW Around-advice `ecb': The ECB-version of `delete-other-windows'. Works exactly like the original function with the following ECB-adjustment: If optional argument WINDOW is nil (i.e. probably called interactively): If called in a splitted edit-window then it works like as if the two parts of the splitted edit window would be the only windows in the frame. This means the part of the splitted edit-window which contains the point fills the whole edit-window. - If called in an unsplitted edit-window then nothing is done. - If called in one of the ecb-windows then the current one is maximized, i.e. the other ecb-windows (not the edit-windows!) are deleted. - If called in the compile window there are two alternatives: If the function is contained in `ecb-layout-always-operate-in-edit-window' it jumps first in the (first) edit-window and does then itīs job. Otherwise an error is reported. If optional argument WINDOW is a live 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 WINDOW is an ecb-window then only the other ecb-windows are deleted and in all other cases an error is reported. - Command: delete-windows-on BUFFER &optional FRAME Around-advice `ecb': The ECB-version of `delete-windows-on'. Works exactly like the original function with the following ECB-adjustment: An error is reported if BUFFER is an ECB-tree-buffer. These windows are not allowed to be deleted. - Command: split-window &optional WINDOW SIZE HORFLAG Around-advice `ecb': The ECB-version of `split-window'. The meaning of WINDOW must be one of the edit-windows of ECB otherwise an error is reported. If the edit-window is already splitted then nothing will be done. Besides this (e.g. called for a window in another frame than the `ecb-frame') it behaves like the original version. - Command: split-window-vertically Around-advice `ecb': The ECB-version of `split-window-vertically'. Works exactly like the original function with the following ECB-adjustment: Called in an unsplitted edit-window then the edit window will be splitted vertically. If called in an already splitted edit-window then nothing is done. If called in any other window of the current ECB-layout it stops with an error if this function is not contained in `ecb-layout-always-operate-in-edit-window'. - Command: split-window-horizontally Around-advice `ecb': The ECB-version of `split-window-horizontally'. Works exactly like the original function with the following ECB-adjustment: Called in an unsplitted edit-window then the edit window will be splitted horizontally. If called in an already splitted edit-window then nothing is done. If called in any other window of the current ECB-layout it stops with an error if this function is not contained in `ecb-layout-always-operate-in-edit-window'! - Command: display-buffer BUFFER &optional NOT-THIS-WINDOW FRAME Around-advice `ecb': Makes this function compatible with ECB if called in or for the ecb-frame. It displays all buffers which are "compilation-buffers" in the sense of `ecb-compilation-buffer-p' in the compile-window of ECB. If the compile-window is temporally hidden then it will be displayed first. If there is no compile-window (`ecb-compile-window-height' is nil) then it splits the edit-window if unsplitted and displays BUFFER in the other edit-window but only if `pop-up-windows' is not nil (otherwise the edit-window will not splitted). If called from outside the edit-area for a non-"compilation-buffers" (s.a.) then it behaves as if called from within an edit-window if `display-buffer' is contained in `ecb-layout-always-operate-in-edit-window': It depends on `pop-up-windows' if the edit-window is automatically splitted ot not. If `ecb-layout-always-operate-in-edit-window' does not contain `display-buffer' then the buffer is displayed in the edit-window without splitting it (if unsplitted). If called for other frames it works like the original version. - Command: switch-to-buffer BUFFER &optional NORECORD Around-advice `ecb': The ECB-version of `switch-to-buffer'. Works exactly like the original but with the following enhancements for ECB: "compilation-buffers" in the sense of `ecb-compilation-buffer-p' will be displayed always in the compile-window of ECB (if `ecb-compile-window-height' is not nil) - if the compile-window is temporally hidden then it will be displayed first. If you do not want this you have to modify the options `ecb-compilation-buffer-names', `ecb-compilation-major-modes' or `ecb-compilation-predicates'. If called for non "compilation-buffers" (s.a.) from outside the edit-area of ECB it behaves as if called from an edit-window if `switch-to-buffer' is contained in the option `ecb-layout-always-operate-in-edit-window'. Otherwise an error is reported. - Command: switch-to-buffer-other-window BUFFER &optional FRAME Around-advice `ecb': The ECB-version of `switch-to-buffer-other-window'. Works exactly like the original but with some adaptions for ECB so this function works in a "natural" way: If called in any special ecb-window of the current ECB-layout then it goes always to the first edit-window and then goes on as if called from this edit-window. If a compile-window is used (i.e. `ecb-compile-window-height' is not nil) then "compilation-buffers" in the sense of `ecb-compilation-buffer-p' are always displayed in the compile-window. If the compile-window is temporally hidden then it will be displayed first. If no compile-window is used it behaves like the original. If called from within the compile-window then "compilation-buffers" will be displayed still there and all other buffers are displayed in one of the edit-windows - if the destination-buffer is already displayed in one of the edit-windows then this one is used otherwise it behaves like the original. If called within an edit-window it behaves like the original function except for compilation-buffers (if a compile-window is used, see above). - Function: other-window-for-scrolling Around-advice `ecb': This function determines the window which is scrolled if any of the "other-window-scrolling-functions" is called (e.g. `scroll-other-window'). If edit-window is splitted, point stays in the "other" edit-window and there is no durable compilation-window then always the first edit-window is chosen.  File: ecb.info, Node: Temp- and compile-buffers, Next: The Methods buffer, Prev: The edit-window, Up: Usage of ECB Temp- and compile-buffers display in ECB ======================================== If you call any help in Emacs, e.g. by calling `describe-function', or if you do a completion in the minibuffer, then Emacs displays the result-buffer in another window. This behavior you have also in ECB. Standard Emacs behavior ----------------------- If the edit-window is already splitted then the temp-buffer is displayed in the "other" edit-window otherwise the edit-window will be splitted first. The variables `temp-buffer-max-height' and `temp-buffer-resize-mode' (the latter one does not exist in 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: Using a durable compile window ------------------------------ With the option `ecb-compile-window-height' you can define if the ECB layout should contain per default a compile-window at the bottom (just specify the number of lines which should be used for the compile-window at the bottom of the frame). If "yes" ECB displays all buffers for which the function `ecb-compilation-buffer-p' returns not nil (e.g. all output of compilation-mode (compile, grep etc.) or all temp-buffers like *Help*-buffers) in this special window. In general: With the options `ecb-compilation-buffer-names', `ecb-compilation-major-modes' and `ecb-compilation-predicates' you can define which buffers should be displayed in the compile-window of ECB (for example if you call `switch-to-buffer' or `display-buffer' or if you run `compile' or if you display *Help*-buffers). Per default these are all temp-buffers like *Help*-buffers, all compile- and grep buffers, *Occur*-buffers etc. See the default values of these options. With the command `ecb-toggle-compile-window' (bound to `C-c . \') you can toggle the visibility of the compile-window (*note 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 *Note ecb-compilation::): * With the option `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'. * With the option `ecb-enlarged-compilation-window-max-height' you specify how `ecb-toggle-compile-window-height' should enlarge the compile-window. * With the command `ecb-cycle-through-compilation-buffers' (*note Interactive ECB commands::) you can cycle through all current open compilation-buffers (in the sense of `ecb-compilation-buffer-p') very fast. What to do if there are problems with the compile-window -------------------------------------------------------- Normally displaying temp- and compilation-buffers (or more general: displaying buffer for which `ecb-compilation-buffer-p' is not nil) should work reliable. But if there are problems which you can not handle with the options `ecb-compilation-buffer-names', `ecb-compilation-major-modes' or `ecb-compilation-predicates' then please go on like follows: 1. Set the option `ecb-layout-debug-mode' to not nil. 2. Reproduce the wrong behavior exactly by repeating all the operations which lead to the problem. If possible then restart Emacs before reproducing the problem so you can begin from the beginning! 3. Now send immediately a bug report with `ecb-submit-problem-report'. 4. Set `ecb-layout-debug-mode' back to nil if you do not want further debugging output in the *Messages* buffer"  File: ecb.info, Node: The Methods buffer, Next: The ECB-layout, Prev: Temp- and compile-buffers, Up: Usage of ECB Using and customizing the ECB-Methods buffer ============================================ ECB is mostly designed to display parsing information for files supported by semantic. But from version 1.94 on 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: - "semantic-sources": These are file-types for which a semantic grammar is available, so the files are parse-able by semantic. These sources are supported best by ECB and most of the following options and descriptions are related to these file-types. Examples are programming-sources like C++, C, Java, Emacs-Lisp and Texinfo-file and some more. - "non-semantic-sources": For these files there is no semantic-grammar available so they can not be parsed by semantic. Examples are Perl-, LaTeX- and TeX-files. But for many of these files imenu and/or etags parsers exist. ECB supports now parsing and displaying these file-types too and it uses for this some speedbar-logic. This chapter describes how to use and customize the Methods-buffer of ECB. * Menu: * Visiting tokens:: Possible actions after visiting a token * Expanding:: Explicit and automatic expanding * Customizing the display:: How to customize the Methods-buffer display * Rebuilding the Methods:: When to rebuild the Methods-buffer  File: ecb.info, Node: Visiting tokens, Next: Expanding, Prev: The Methods buffer, Up: The Methods buffer Possible actions after visiting a token --------------------------------------- You visit a token by clicking with either the primary oder secondary mouse-button (or by hitting 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 and if the edit-window is splitted) and puts the point onto the first line of the clicked token. But you can define if after this "basic" token-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 token) or define own actions. You can set different actions for different major-modes. All this is done via the option `ecb-token-visit-post-actions'. The following actions are currently predefined: - `ecb-token-visit-highlight-token-header' - `ecb-token-visit-smart-token-start' - `ecb-token-visit-recenter' - `ecb-token-visit-recenter-top' - `ecb-token-visit-goto-doc-start' - `ecb-token-visit-narrow-token' See the documentation of these function for details what they do. Per default ECB performs the actions `ecb-token-visit-smart-token-start' and `ecb-token-visit-highlight-token-header' for all major-modes.  File: ecb.info, Node: Expanding, Next: Customizing the display, Prev: Visiting tokens, Up: The Methods buffer Explicit and automatic expanding of the ECB-methods-buffer ---------------------------------------------------------- Explicit expanding to a certain expanding level ............................................... 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 tokens with a certain indentation-level. So you can either expand no tokens (or with other words collapse all tokens) or expand all tokens so see the contents of a buffer at one glance. Or you can expand exactly that tokens 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. Automatic expanding the ECB-methods-buffer .......................................... If the option `ecb-highlight-token-with-point' is switched on, then then always that node in the method-buffer is highlighted which belongs to the current semantic-token under point in the 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-token-tree' or even easier with the command `ecb-toggle-auto-expand-token-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!  File: ecb.info, Node: Customizing the display, Next: Rebuilding the Methods, Prev: Expanding, Up: The Methods buffer Customizing the display of the Methods-buffer --------------------------------------------- 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 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 "tokens" to ECB which displays them in a browse-able form in its Method-buffer. See *Note ECB Methods-buffer:: for information how to use the Methods-buffer. There are several options to customize which tokens ECB should display in general, if the tokens should be collapsed or expanded, how to fontify them (i.e. syntax-highlighting) and something more. `ecb-show-tokens' Which semantic-tokens (e.g. types, methods, variables etc.) should be displayed and should they be collapsed, flattened or expanded. Sorting is also possible. `ecb-font-lock-tokens' `ecb-type-token-display' How to fontify the tokens in the Method-buffer `ecb-token-display-function' ECB and semantic offer several predefined functions for displaying the tokens. Here you can customize, what informations tokens should contain (only the method-name or the whole signature or something else) and what notation should be used, e.g. UML or not. These are the most important options for this topic but it is recommended to have a look into the customize-group `ecb-methods' (*note 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!  File: ecb.info, Node: Rebuilding the Methods, Prev: Customizing the display, Up: The Methods buffer Rebuilding the Methods-buffer ----------------------------- 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: - semantic-sources: The command `global-semantic-auto-parse-mode' switches on autom. reparsing of semantic-sources. - non-semantic-sources (imenu supported): You can switch on autom. rescanning/reparsing with the option `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'). - non-semantic-sources (etags supported): For these sources there is no built-in auto-rescan mechanism, because etags is an external tool it can only operate on the saved file-contents. So rescanning the buffer contents would need to save the buffer before. Therefore there is no built-in auto-rescan mechanism because this would always result in saving the buffer and running an external tool. But of course you can program such a an etags-auto-rescan mechanism for yourself! 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!  File: ecb.info, Node: The ECB-layout, Next: Hiding the ECB windows, Prev: The Methods buffer, Up: Usage of ECB Changing, customizing, redrawing and creating layouts ===================================================== 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. * Menu: * Changing the ECB-layout:: How to change and customize the layout * Redrawing the ECB-layout:: How and when redrawing the layout * Changing window sizes:: Changing sizes of the ECB-windows * Fixing window sizes:: Fixing sizes of the ECB-windows * Creating a new ECB-layout:: Interactively creating new layouts