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: Non-semantic sources, Next: Hide-show, Prev: Compile-window on demand, Up: Tips and tricks Parsing and displaying non-semantic sources =========================================== 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. See *Note Definition of semantic- and non-semantic-sources:: for a description of "semantic-sources" and "non-semantic-sources". If support of non-semantic-sources is enabled then ECB will display the contents of all sources which can be displayed by speedbar too. This comes from the fact that ECB uses speedbar-logic to parse sources with imenu or etags. In most cases imenu-parsing is preferable over etags-parsing because imenu operates on Emacs-buffers and needs no external tool and therefore parsing works also if current contents of a buffer are not saved to disk. This section describes all important aspects about parsing and displaying file-contents of file-types not supported by semantic but by imenu and/or etags. Enabling parsing and displaying of non-semantic-sources ------------------------------------------------------- Enabling is simply done with the option `ecb-process-non-semantic-files'. ECB offers an option `ecb-non-semantic-parsing-function' to specify on a major-mode basis which parsing-method should be used: imenu or etags. Normally there should be no need to change this option but read the documentation of this option (*note ecb-non-semantic::) for further details. IMPORTANT: * If imenu-parsing should be used then the option `speedbar-use-imenu-flag' must be set to not `nil'! * If some non-semantic-sources are not parsed (i.e. there is an empty Methods-buffer) and you think that they should then maybe they are neither supported by imenu nor by etags or you have to check the options `ecb-non-semantic-parsing-function' and `speedbar-dynamic-tags-function-list' and - especially for etags - `speedbar-fetch-etags-parse-list', `speedbar-fetch-etags-arguments' and `speedbar-fetch-etags-command'. * Even with support for semantic-, imenu- and etags-parsing there will remain some file-types rsp. `major-modes' which are not parse-able, neither by semantic, imenu nor etags. This is no problem because these files simply have an empty Methods-buffer. But nevertheless you will get a message "Sorry, no support for a file of that extension" which comes from the speedbar-library and can not switched off. Therefore if a `major-mode' is known as not parse-able by semantic, imenu or etags it can be added to the option `ecb-non-semantic-exclude-modes' and then it will be excluded from being tried to parsed and this (annoying) message will not occur. Automatic rescanning/reparsing of non-semantic-sources ------------------------------------------------------ In contrast to semantic (see `global-semantic-auto-parse-mode') there is no built-in mechanism for autom. reparsing non-semantic-sources and then updating the contents of the Methods-buffer. For non-semantic-sources you have always at least to call `ecb-rebuild-methods-buffer' (bound to `C-c . r') or saving the source-file (if `ecb-auto-update-methods-after-save' is true) to update the Method-buffer(1). Depending on the parsing-mechanism the following options have to be switched on so ECB can rebuild the methods-buffer for non-semantic-sources: * imenu: The imenu-option `imenu-auto-rescan' must be enabled and `imenu-auto-rescan-maxout' has to be set big enough to auto-parse big files too! But this results not directly in an autom. updated Method-buffer. This is first done after calling the command `ecb-rebuild-methods-buffer' or saving the source-file (if `ecb-auto-update-methods-after-save' is true). * etags: Only if `ecb-auto-save-before-etags-methods-rebuild' is switched on the command `ecb-rebuild-methods-buffer' rebuilds the method-buffer with current source-contents. See description of this option for an explanation. Tip: If you want to program your own real. automatic rescan/reparse/rebuild mechanism for non-semantic-sources you can do: Adding to `after-change-functions' a function F which either runs itself `ecb-rebuild-methods-buffer-for-non-semantic' or which adds only another function FF to an idle-timer and the function FF runs `ecb-rebuild-methods-buffer-for-non-semantic'. The latter approach has the advantage that the reparse/rebuild is not performed immediately after every change but first after Emacs is idle for a senseful interval (e.g. 4 seconds) after last change. Of course the function FF has to cancel its own idle-timer at the end, so the next idle-timer is first started again after the next change (i.e. by function F which is still contained in `after-change-functions'. Customizing the display of the tokens ------------------------------------- For non-semantic-sources ECB uses does no special organizing of tokens in groups and sub-tokens but it completely uses the token-hierarchy the imenu- and etags-parsers of speedbar return. So the displayed token hierarchy can only be customized with some options speedbar offers for this: `speedbar-tag-hierarchy-method', `speedbar-tag-group-name-minimum-length', `speedbar-tag-split-minimum-length' and `speedbar-tag-regroup-maximum-length'. See the speedbar documentation for details about these options. With the option `ecb-method-non-semantic-face' you can define the face used for displaying the tokens in the Method-buffer for non-semantic-sources. `ecb-non-semantic-methods-initial-expand' can be useful too. ---------- Footnotes ---------- (1) Maybe future versions of ECB (> 1.94) will offer an autom. mechanism for this.  File: ecb.info, Node: Hide-show, Next: Window-managers and ECB, Prev: Non-semantic sources, Up: Tips and tricks Using hide-show from the methods-buffer-menu ============================================ The popup-menu of the Methods-buffer offer two entries for either hiding or showing the block which is related to the selected token (that token for which the popup-menu was opened): * "Jump to token and hide block": Jumps to the token and calls `hs-hide-block' from the hideshow-library which is shipped with (X)Emacs. After that the block is hidden, i.e. only the header-line of that token (method, variable etc.) is visible, the rest is hidden behind the "...". * "Jump to token and show block": Jumps to the token and calls `hs-show-block'. This shows the related hidden block if the block was hidden via `hs-hide-block' or the menu-entry "Jump to token and hide block" (s.a.). For this feature the library `hideshow.el' is used which should normally being included in the (X)Emacs-distribution. If this library is not loaded into Emacs, ECB does this automatically before the first call to one of these menu-entries. IMPORTANT: If in some `major-mode' hiding and showing does not work as you expect it to work then you must probably add an entry for this `major-mode' to the hideshow-variable `hs-special-modes-alist'. See the documentation of this variable for further details. One example of such a `major-mode' is `jde-mode' of the Java Development Environment JDEE; just add an entry for it like the already contained entries for `c++-mode' or `java-mode' and hiding and showing will work for you with JDEE too.  File: ecb.info, Node: Window-managers and ECB, Prev: Hide-show, Up: Tips and tricks Support of several Emacs-window-managers ======================================== There are several window-managers available which offer an easy interface to jump between different window-configurations within the same frame. A window configuration is the layout of windows and associated buffers within a frame. There is always at least one configuration, the current configuration. You can create new configurations and cycle through the layouts in either direction. Window configurations are often named or numbered, and you can jump to and delete named rsp. numbered configurations. Without special support by ECB these window-managers would not work in combination with ECB! ECB currently supports the following managers: * winring.el: Written by Barry A. Warsaw , available at * escreen.el: Written by Noah Friedman , available at *IMPORTANT*: With one of these window-managers installed and active you can run applications like Gnus, VM or BBDB in the same frame as ECB! Just use different window-configurations (winring.el) or escreens (escreen.el) for ECB and the other applications. Especially with winring.el you can give every configuration a descriptive name like "ECB" or "Gnus"; afterwards you can jump to a window-configuration by name! The rest of this section describes how to enable the special ECB-support for these window-managers and how to use them. Enabling of the support ----------------------- Every support must be enabled explicitly: * winring: Call `ecb-winman-winring-enable-support'. This *MUST* be done *BEFORE* the first call to any winring-command, so also before calling `winring-initialize'! * escreen: Call `ecb-winman-escreen-enable-support'. This *MUST* be done *BEFORE* the first call to any escreen-command, so also before calling `escreen-install'! If a window-manager-support should be enabled autom. after Emacs-start just put the following into your `.emacs': (ecb-winman-winring-enable-support) (winring-initialize) ;; or - if you like escreen more (ecb-winman-escreen-enable-support) (escreen-install) Usage of a window-manager in combination with ECB ------------------------------------------------- After enabling the support of one of the supported window-managers just go on as described in the commentary or introduction of the respective library-file(s) of the window-manager. Here is a short description: * winring: First you have to define how to identify the ECB-window-configuration, i.e. the configuration with activated ECB. This done with the option `ecb-winman-winring-name'. There is always only one window-configurations with name `ecb-winman-winring-name'! Then run `winring-initialize'. If ECB is active then the resulting window-configuration is the ECB-window-configuration. Otherwise you can create the ECB-window-configuration when you first time call `winring-new-configuration' with name equal to `ecb-winman-winring-name'. In general you can run all commands of the winring-library. If you jump to the ECB-window-configuration then ECB will be autom. activated and if you leave the ECB-window-configuration then ECB will autom. deactivated. * escreen: First you have to define how to identify the ECB-escreen i.e. that escreen with activated ECB. This done with the option `ecb-winman-escreen-number'. There is always only one escreen with number `ecb-winman-escreen-number'! Then run `escreen-install' (deactivates ECB if currently running). After that you can call `escreen-create-screen' and `escreen-goto-screen'(1). These commands autom. activate ECB if creating or selecting the escreen with number `ecb-escreen-number' (default = 1) and autom. deactivate ECB if leaving the ECB-escreen. Disabling the support --------------------- There is normally no need to do this but nevertheless it can be done by `ecb-winman-escreen-disable-support' rsp. `ecb-winman-winring-disable-support'. ---------- Footnotes ---------- (1) And of course all other `escreen-goto-*' commands!  File: ecb.info, Node: Elisp programming, Next: Conflicts and bugs, Prev: Tips and tricks, Up: Top Entry points for Elisp programmers ********************************** This chapter describes how ECB can be used/programmed/driven by an Elisp-program. This contains: * Menu: * List of variables:: Which variables an Elisp-program can use * List of hooks:: All available hooks * tree-buffer:: Some words to the tree-buffer-library * Adviced functions:: How to deal with the adviced functions * The layout-engine:: Programming new layouts and special windows  File: ecb.info, Node: List of variables, Next: List of hooks, Prev: Elisp programming, Up: Elisp programming Variables for Elisp-programs ============================ Variables an Elisp-program can use beyond those ones mentioned in *Note The layout-engine::: * `ecb-source-path-functions' Look at the documentation of these variables to get a description.  File: ecb.info, Node: List of hooks, Next: tree-buffer, Prev: List of variables, Up: Elisp programming Available hooks of ECB ====================== The following hooks are available: * `ecb-activate-before-new-frame-created-hook' * `ecb-activate-before-layout-draw-hook' * `ecb-activate-hook' * `ecb-before-activate-hook' * `ecb-before-deactivate-hook' * `ecb-common-tree-buffer-after-create-hook' * `ecb-current-buffer-sync-hook' * `ecb-deactivate-hook' * `ecb-directories-buffer-after-create-hook' * `ecb-hide-ecb-windows-after-hook' * `ecb-hide-ecb-windows-before-hook' * `ecb-history-buffer-after-create-hook' * `ecb-methods-buffer-after-create-hook' * `ecb-redraw-layout-after-hook' * `ecb-redraw-layout-before-hook' * `ecb-show-ecb-windows-after-hook' * `ecb-show-ecb-windows-before-hook' * `ecb-sources-buffer-after-create-hook' Look at the documentation of these hooks to get a detailed description.  File: ecb.info, Node: tree-buffer, Next: Adviced functions, Prev: List of hooks, Up: Elisp programming The library tree-buffer.el ========================== The library tree-buffer.el is ECB independent and can be used for other applications too. But such an application is not allowed to use any of the variables of tree-buffer.el especially not the variable *tree-buffers*! `tree-buffers': Only for internal use. It contains all tree-buffers of current Emacs-instance, means *all* tree-buffers of *all* applications which uses currently tree-buffers. Every application must store its own collection of tree-buffers in an own variable! For example: ECB stores its tree-buffer set in `ecb-tree-buffers'! An application may only use the methods tree-buffer.el provides but no internal variables!  File: ecb.info, Node: Adviced functions, Next: The layout-engine, Prev: tree-buffer, Up: Elisp programming How to deal with the adviced window-functions ============================================= ECB offers for packages which work during activated ECB three macros for easy temporally(1) using all original-functions, all adviced functions or only some adviced functions: - `ecb-with-original-functions' - `ecb-with-adviced-functions' - `ecb-with-some-adviced-functions' For a detailed explanation of each macro read the documentation with `describe-function'! ---------- Footnotes ---------- (1) I.e. regardless of the settings in `ecb-advice-window-functions'!  File: ecb.info, Node: The layout-engine, Prev: Adviced functions, Up: Elisp programming How to program new layouts and new special windows ================================================== There are two aspects concerning this topic: 1. Programming a new layout which contains several special ECB-windows like directories, sources, methods, history or other special windows and arranging them in a new outline. 2. Creating complete new special windows (e.g. a local-variable window for a graphical debugger like JDEbug of JDEE), adding them to a layout and synchronizing them with the edit-window. The former one covers merely the layout-programming aspect which is explained in the first subsection of this chapter whereas the latter one covers all aspects of creating new special windows and what is necessary to synchronize it with the edit-window of ECB. This is explained in the second subsection which will refers to the first subsection. * Menu: * Programming a new layout:: How to program a new layout * Programming special windows:: Aspects of programming special windows * Possible layout-outlines:: The wide range of possible layouts * The layout-engine API:: The complete layout-engine API  File: ecb.info, Node: Programming a new layout, Next: Programming special windows, Prev: The layout-engine, Up: The layout-engine How to program a new layout --------------------------- If you just want creating a new layout with the standard ECB-windows like directories, sources, methods, history and speedbar it's is strongly recommended to define the new layout interactively with the command `ecb-create-new-layout' (*note Creating a new ECB-layout::). If you want creating a new layout and if this layout should contain other special windows than the standard ECB-windows then it's still recommended to define this layout interactively with `ecb-create-new-layout' and using the option to give the created windows user-defined types. For every user defined type you have then just to program the necessary buffer-set function. For all the details see *Note Creating a new ECB-layout::. But if you do not like the interactive way (because you are tough and brave) but you want programming the new layout with Elisp then use the macro `ecb-layout-define' (the following definition has stripped the prefix "ecb-" for better indexing this manual): - Macro: layout-define name type &rest create-code Creates a new ECB-layout with name NAME. TYPE is the type of the new layout and is literal, i.e. not evaluated. It can be left, right, top or left-right. DOC is the docstring for the new layout-function "ecb-layout-function-". CREATE-CODE is all the lisp code which is necessary to define the ECB-windows/buffers. This macro adds the layout with NAME and TYPEto the internal variable `ecb-available-layouts'. Preconditions for CREATE-CODE: 1. Current frame is splitted at least in one edit-window and the "column" (for layout types left, right and left-right) rsp. "row" (for a top layout) for the special ECB-windows/buffers. The width of the "column" rsp. the height of the "row" is always defined with the option `ecb-windows-width' rsp. `ecb-windows-height'. Depending on the value of the option `ecb-compile-window-height' there is also a compile window at the bottom of the frame which is stored in `ecb-compile-window'. 2. All windows are not dedicated. 3. Neither the edit-window nor the compile-window (if there is one) are selected for types left, right and top. For type left-right the left column-window is selected 4. All ECB-advices for the functions in `ecb-advice-window-functions' are disabled! Things CREATE-CODE has to do: 1. Splitting the ECB-tree-windows-column(s)/row (s.a.) in all the ECB-windows the layout should contain (directories, sources, methods and history). The split must not be done with other functions than `ecb-split-hor' and `ecb-split-ver'! It is recommended not to to use a "hard" number of split-lines or -rows but using fractions between -0.9 and +0.9! Tip: It is recommended to spilt from right to left and from bottom to top or with other words: First create the right-most and bottom-most special windows! 2. Making each special ECB-window a dedicated window. This can be done with one of the following functions: - `ecb-set-directories-buffer' - `ecb-set-sources-buffer' - `ecb-set-methods-buffer' - `ecb-set-history-buffer' - `ecb-set-speedbar-buffer' Each layout can only contain one of each tree-buffer-type! In addition to these functions there is a general macro `ecb-with-dedicated-window'. This macro performs any arbitrary code in current window and makes the window autom. dedicated at the end. This can be used by third party packages like JDEE to create arbitrary ECB-windows besides the standard tree-windows. To make a special ECB-window a dedicated window either one of the five functions above must be used or a function(!) which calls in turn the macro `ecb-with-dedicated-window'. See the documentation of this macro how to use it! Such a function is called a "dedicated setter" and must(!) use `ecb-with-dedicated-window' to make the window dedicated! 3. Every(!) special ECB-window must be dedicated as described in 2. 4. CREATE-CODE must work correctly regardless if there is already a compile-window (stored in `ecb-compile-window') or not (`ecb-compile-window' is nil). Things CREATE-CODE can do or can use: 1. The value of `ecb-compile-window' which contains the compile-window (if there is one). Using the values of `ecb-compile-window-height', `ecb-windows-width', `ecb-windows-height'. Things CREATE-CODE must NOT do: 1. Splitting the edit-window 2. Creating a compile-window 3. Deleting the edit-window, the compile-window (if there is any) or the ECB-windows-column(s)/row (see Precondition 1.) 4. Referring to the value of `ecb-edit-window' because this is always nil during CREATE-CODE. Postconditions for CREATE-CODE: 1. The edit-window must be the selected window and must not be dedicated and not be splitted. 2. Every window besides the edit-window \(and the compile-window) must be a dedicated window \(e.g. a ECB-tree-window). Use this macro to program new layouts within your `.emacs' or any other file which is loaded into your Emacs. After loading the file(s) with all the new layout-definitions you can use it by customizing the option `ecb-layout-name' to the appropriate name or with the command `ecb-change-layout'. With the function `ecb-layout-undefine' you can remove a layout from the list of available layouts: - Function: layout-undefine name Unbind ecb-layout-function-, ecb-delete-window-ecb-windows-, ecb-delete-other-windows-ecb-windows- and remove `NAME' from `ecb-available-layouts'. Here is an example for a new layout programmed with `ecb-layout-define': (ecb-layout-define "my-own-layout" left nil ;; The frame is already splitted side-by-side and point stays in the ;; left window (= the ECB-tree-window-column) ;; Here is the creation code for the new layout ;; 1. Defining the current window/buffer as ECB-methods buffer (ecb-set-methods-buffer) ;; 2. Splitting the ECB-tree-windows-column in two windows (ecb-split-ver 0.75 t) ;; 3. Go to the second window (other-window 1) ;; 4. Defining the current window/buffer as ECB-history buffer (ecb-set-history-buffer) ;; 5. Make the ECB-edit-window current (see Postcondition above) (select-window (next-window))) This layout definition defines a layout with name "my-own-layout" which looks like: ------------------------------------------------------- | | | | | | | | | | Methods | | | | | | | | | | Edit | | | | | | | |--------------| | | | | | History | | | | | ------------------------------------------------------- | | | Compilation | | | -------------------------------------------------------  File: ecb.info, Node: Programming special windows, Next: Possible layout-outlines, Prev: Programming a new layout, Up: The layout-engine All aspects of programming special windows ------------------------------------------ ECB offers a flexible programmable layout-engine for other packages to display their own contents and informations in special ECB-windows. An example could be a graphical debugger which offers a special window for displaying local variables and another special window for messages from the debugger-process (like JDEbug of JDEE(1)). This section explains all aspects of programming new special windows, adding them to a new layout and synchronizing them with edit-window of ECB. This can be done best with an easy example which nevertheless covers all necessary aspects to be a good example and skeleton for complex tools (like a graphical debugger) which want to use the layout-engine of ECB do display their own information. Here comes the example: The outline of the example layout: .................................. ------------------------------------------------------- |Bufferinfo for : |[prior] | |Type: file |[next] | |Size: 23456 | | |Modes: rw-rw-rw- | | |-----------------------------------------------------| | | | | | | | | | edit-window | | | | | | | | | ------------------------------------------------------- | | | compilation-window | | | ------------------------------------------------------- The description of the layout-contents ...................................... The top-left window always displays informations about the current buffer in the selected edit-window. This window demonstrates how autom. synchronizing a special window/buffer of a layout with current edit-window. The top-right window contains an read-only "action-buffer" and offers two buttons which can be used with the middle mouse-button to scroll the edit-window. This is not very senseful but it demonstrates how to control the edit-window with actions performed in a special window/buffer of a layout. (If you have not set a compilation-window in `ecb-compile-window-height' then the layout contains no durable compilation window and the other windows get a little more place). The example code ................ Now let have us a look at the several parts of the Elisp-program needed to program this new example layout. ECB contains a library `ecb-examples.el' which contains the full working code of this example. To test this example and to play with it you can load this library into Emacs (with `load-library' for example) and then calling `ecb-change-layout' (bound to `C-c . lc') and inserting "example-layout1" as layout-name. An alternative is calling `ecb-examples-activate' and `ecb-examples-deactivate'. For details see file `ecb-examples.el'. The following steps only contain code-skeletons to demonstrate the principle. The full working code is available in `ecb-examples.el'. The bufferinfo buffer of the example .................................... The name of the bufferinfo buffer: (defconst ecb-examples-bufferinfo-buffer-name " *ECB buffer info*") Two helper functions for displaying infos in a special buffer: (defun ecb-examples-print-file-attributes (buffer filename) (ecb-with-readonly-buffer buffer (erase-buffer) (insert (format "Bufferinfo for %s:\n\n" filename)) ;; insert with the function `file-attributes' some ;; informations about FILENAME. )) (defun ecb-examples-print-non-filebuffer (buffer buffer-name) (ecb-with-readonly-buffer buffer (erase-buffer) ;; analogous to `ecb-examples-print-file-attributes' )) The main synchronizing function added to `ecb-current-buffer-sync-hook' for autom. evaluation by `ecb-current-buffer-sync' which runs dependent on the values of `ecb-window-sync' and `ecb-window-sync-delay'. This function synchronizes the bufferinfo buffer with the current buffer of the edit-window if that buffer has changed. (defun ecb-examples-bufferinfo-sync () (ecb-do-if-buffer-visible-in-ecb-frame 'ecb-examples-bufferinfo-buffer-name ;; here we can be sure that the buffer with name ;; `ecb-examples-bufferinfo-buffer-name' is displayed in a ;; window of `ecb-frame' ;; The macro `ecb-do-if-buffer-visible-in-ecb-frame' locally ;; binds the variables visible-buffer and visible-window!! See ;; documentation of this macro! (let ((filename (buffer-file-name (current-buffer)))) (if (and filename (file-readable-p filename)) ;; real filebuffers ;; here we could add a smarter mechanism; ;; see ecb-examples.el (ecb-examples-print-file-attributes visible-buffer filename) ;; non file buffers like help-buffers etc... (setq ecb-examples-bufferinfo-last-file nil) (ecb-examples-print-non-filebuffer visible-buffer (buffer-name (current-buffer))) )))) The function which makes the bufferinfo-buffer dedicated to a window. (defun ecb-examples-set-bufferinfo-buffer () (ecb-with-dedicated-window ecb-examples-bufferinfo-buffer-name 'ecb-examples-set-bufferinfo-buffer (switch-to-buffer (get-buffer-create ecb-examples-bufferinfo-buffer-name)) (setq buffer-read-only t))) This is all what we need for the special bufferinfo buffer. We have demonstrated already three of the important functions/macros of the layout-engine API of ECB: `ecb-with-readonly-buffer', `ecb-do-if-buffer-visible-in-ecb-frame' and `ecb-with-dedicated-window' (*note The layout-engine API::. Especially the second macro is strongly recommended for programming good synchronizing functions which do not waste CPU! The action buffer of the example ................................ The name of the action-buffer: (defconst ecb-examples-action-buffer-name " *ECB action buffer*") Two helper functions for creating a readonly action-buffer with a special local key-map for the middle-mouse-button and two buttons [prior] and [next]: (defun ecb-examples-insert-text-in-action-buffer (text) (let ((p (point))) (insert text) (put-text-property p (+ p (length text)) 'mouse-face 'highlight))) (defun ecb-examples-action-buffer-create () (save-excursion (if (get-buffer ecb-examples-action-buffer-name) (get-buffer ecb-examples-action-buffer-name) (set-buffer (get-buffer-create ecb-examples-action-buffer-name)) ;; we setup a local key-map and bind middle-mouse-button ;; see ecb-examples.el for the full code ;; insert the action buttons [prior] and [next] and ;; make it read-only (ecb-with-readonly-buffer (current-buffer) (erase-buffer) (ecb-examples-insert-text-in-action-buffer "[prior]") ;; analogous for the [next] button ) (current-buffer)))) The function which performs the actions in the action-buffer if clicked with the middle-mouse button onto a button [next] or [prior]. (defun ecb-examples-action-buffer-clicked (e) (interactive "e") (mouse-set-point e) (let ((line (buffer-substring (ecb-line-beginning-pos) (ecb-line-end-pos)))) (cond ((string-match "prior" line) (ecb-select-edit-window) (call-interactively 'scroll-down)) ((string-match "next" line) ;; analogous for [next] )))) The function which makes the action-buffer dedicated to a window. (defun ecb-examples-set-action-buffer () (let ((buf-name (buffer-name (ecb-examples-action-buffer-create)))) (ecb-with-dedicated-window buf-name 'ecb-examples-set-action-buffer (switch-to-buffer (buffer-name (ecb-examples-action-buffer-create)))))) We do not need more code for the action buffer. All of the code is standard emacs-lisp which would also needed if used without ECB. Adding the bufferinfo- and action-buffer to a new layout ........................................................ Now we add the bufferinfo- and the action-buffer to a new layout of type top with name "example-layout1": (ecb-layout-define "example-layout1" top ;; dedicating the bufferinfo window to the bufferinfo-buffer (ecb-examples-set-bufferinfo-buffer) ;; creating the action-window (ecb-split-hor 0.75) ;; dedicate the action window to the action-buffer (ecb-examples-set-action-buffer) ;; select the edit-window (select-window (next-window))) This all what we need to define the new layout. See *Note Programming a new layout:: for more details of the pure layout-programming task. Synchronizing the bufferinfo-buffer automatically ................................................. The last thing we have to do is to synchronize the bufferinfo-buffer with current edit-window. We do this by adding `ecb-examples-bufferinfo-sync' to the hook `ecb-current-buffer-sync-hook'' (The file `ecb-examples.el' shows a smarter mechanism for (de)activating the new layout and the synchronization but this works also very well). (add-hook 'ecb-current-buffer-sync-hook 'ecb-examples-bufferinfo-sync) Activating and deactivating new layouts ....................................... Because a set of new special windows integrated in a new layout is often just the GUI of a complete tool (like a graphical debugger) we demonstrate here the complete activation and deactivation of such a tool or at least of the tool-GUI. We decide that the GUI of our example "tool" needs a compile-window with height 5 lines and the height of the special windows "row" on top should be exactly 6 lines (normally width and height of the special windows should be a fraction of the frame, but here we use 6 lines(2) Here comes the (de)activation code. The code for saving and restoring the state before activation (the full code is available in `ecb-examples.el': (defun ecb-examples-preactivation-state(action) (cond ((equal action 'save) ;; code for saving the state ) ((equal action 'restore) ;; code for restoring the state ))) The following function activates the GUI of our example tool: (defun ecb-examples-activate () (interactive) ;; activating the synchronization of the bufferinfo-window (add-hook 'ecb-current-buffer-sync-hook 'ecb-examples-bufferinfo-sync) ;; saving the state (ecb-examples-preactivation-state 'save) ;; switch to our preferred layout (setq ecb-windows-height 6) (setq ecb-compile-window-height 5) (ecb-layout-switch "example-layout1")) This function deactivates the GUI of our example-tool and restores the state as before activation: (defun ecb-examples-deactivate () (interactive) (remove-hook 'ecb-current-buffer-sync-hook 'ecb-examples-bufferinfo-sync) (ecb-examples-preactivation-state 'restore) (ecb-layout-switch ecb-layout-name)) Now we have all code for the new layout and the new layout-buffers. The example is ready for use; just load `ecb-examples.el' (s.a.). ---------- Footnotes ---------- (1) JDEE is available at (2) You can change the code in the file `ecb-examples.el' to use a frame-fraction of 0.2 instead of 6 hard lines, just try it!  File: ecb.info, Node: Possible layout-outlines, Next: The layout-engine API, Prev: Programming special windows, Up: The layout-engine The wide range of possible layout-outlines ------------------------------------------ In the two previous sections *Note Programming a new layout:: and *Note Programming special windows:: we have explained in detail how to program new layouts and how to program new special windows/buffers and adding them to a new layout. The intention of this section is to be a summary what are the real restrictions for a new layout-outline programmed with `ecb-layout-define'. This is necessary because until now we just programmed "obvious" layouts, means layout which are in principle very similar to the standard ones which means one big edit-window and some special windows "around" this edit-window. This section will show you that a layout can have also very different outlines. OK, here are the real restrictions and conditions for a layout programmed with `ecb-layout-define': 1. It must have exactly one edit-window regardless of its size. 2. All other windows created within the CREATE-CODE body of `ecb-layout-define' (*note Programming a new layout::) must be dedicated to their buffers. 3. All the dedicated windows must (exclusive!) either reside on the left, right, top or left-and-right side of the edit-window. This will be defined with the TYPE-argument of `ecb-layout-define' (*note Programming a new layout::). You see, there are only three restrictions/conditions. These and only these must be fulfilled at layout-programming. Demonstrating what this really means and how flexible the layout-engine of ECB really is, can be done best with some "pathological" layout-outlines. All the following are correct layouts (working code is added below each layout): The following is a top layout with three vertical layered special windows. ------------------------------------------------------------------ | | | Upper special window | | | |----------------------------------------------------------------| | | | Middle special window | | | |----------------------------------------------------------------| | | | Lower special window | | | |================================================================| | | | Edit-window(s) | | (can be splitted in two windows) | ------------------------------------------------------------------ | | | Compilation-window (optional) | | | ------------------------------------------------------------------ Here is the code for that top layout (all buffers are dummy-buffers): ;; The "dedicated setter" functions: (defun ecb-set-usw-buffer () (ecb-with-dedicated-window "Upper special window" 'ecb-set-usw-buffer (switch-to-buffer (get-buffer-create "Upper special window")))) (defun ecb-set-msw-buffer () (ecb-with-dedicated-window "Middle special window" 'ecb-set-msw-buffer (switch-to-buffer (get-buffer-create "Middle special window")))) (defun ecb-set-lsw-buffer () (ecb-with-dedicated-window "Lower special window" 'ecb-set-lsw-buffer (switch-to-buffer (get-buffer-create "Lower special window")))) ;; The layout itself: (ecb-layout-define "example-layout3" top nil ;; here we have an edit-window and above one top window which we can ;; now split in several other windows. Dependent on the value of ;; `ecb-compile-window-height' we have also a compile-window at the ;; bottom. (ecb-set-usw-buffer) (ecb-split-ver 0.33) (ecb-set-msw-buffer) (ecb-split-ver 0.5) (ecb-set-lsw-buffer) ;; select the edit-window. (select-window (next-window))) The following is a left-right layout which has six special windows in the left-"column" and one big special window in the right-"column". For left-right layouts the left-"column" and the right-"column" have always the same width. ------------------------------------------------------------------ | | | | | | Left1 | Left5 | | | | | | | | |-------------| | | | | | | | | | | | | | | | | | | | | | | Left2| Left3|-------| Edit-window(s) | Right1 | | | | | (can be splitted | | | | | | in two windows) | | | | | | | | |-------------| | | | | | | | | | Left4 | Left6 | | | | | | | | ------------------------------------------------------------------ | | | Compilation-window (optional) | | | ------------------------------------------------------------------ Here is the code for that left-right layout, again with dummy-buffers (depending to your screen-resolution you will need a quite big value for `ecb-windows-width', e.g. 0.4): Here is one of the "dedicated setter" functions(1): (defun ecb-set-left1-buffer () (ecb-with-dedicated-window "Left1" 'ecb-set-left1-buffer (switch-to-buffer (get-buffer-create "Left1")))) Here is the layout-definition itself: (ecb-layout-define "example-layout2" left-right nil ;; here we have an edit-window and left and right two windows each ;; with width `ecb-windows-width'. Dependent to the value of ;; `ecb-compile-window-height' we have also a compile-window at the ;; bottom. (ecb-set-left1-buffer) (ecb-split-hor 0.66 t) (ecb-split-ver 0.75) (ecb-set-left4-buffer) (select-window (previous-window (selected-window) 0)) (ecb-split-ver 0.25 nil t) (ecb-set-left2-buffer) (ecb-split-hor 0.5) (ecb-set-left3-buffer) (select-window (next-window (next-window))) (ecb-set-left5-buffer) (ecb-split-ver 0.5) (ecb-set-left6-buffer) (select-window (next-window (next-window))) (ecb-set-right1-buffer)) ;; select the edit-window (select-window (previous-window (selected-window) 0))) Especially the last example should demonstrate that even very complicated layouts are easy to program with `ecb-layout-define'. If such layouts are senseful is another topic ;-) ---------- Footnotes ---------- (1) The "dedicated setter functions" for all these ecb-windows/buffers are not explicitly described - they look all like `ecb-set-left1-buffer' - of course with different buffer-names!  File: ecb.info, Node: The layout-engine API, Prev: Possible layout-outlines, Up: The layout-engine The complete layout-engine API of ECB ------------------------------------- This section lists all functions, macros, variables and user-options the layout-engine API of ECB offers foreign packages. Call `describe-function' rsp. `describe-variable' to get a detailed description. Functions for programming with layouts and special ecb-windows: - ecb-available-layouts-member-p - ecb-canonical-ecb-windows-list - ecb-compile-window-live-p - ecb-do-if-buffer-visible-in-ecb-frame - ecb-edit-window-live-p - ecb-get-current-visible-ecb-buffers - ecb-layout-define - ecb-layout-switch - ecb-layout-undefine - ecb-point-in-compile-window - ecb-point-in-ecb-window - ecb-point-in-edit-window - ecb-select-edit-window - ecb-split-hor - ecb-split-ver - ecb-with-dedicated-window Utility functions/macros: - ecb-enlarge-window - ecb-fix-filename - ecb-window-live-p - ecb-with-readonly-buffer Some other maybe useful functions/macros: - ecb-with-adviced-functions - ecb-with-original-functions - ecb-with-some-adviced-functions Some useful *READONLY* variables: - ecb-compile-window - ecb-edit-window - ecb-last-edit-window-with-point - ecb-last-source-buffer User-options and hooks related to the layout-engine API: - ecb-current-buffer-sync-hook - ecb-hide-ecb-windows-after-hook - ecb-hide-ecb-windows-before-hook - ecb-redraw-layout-after-hook - ecb-redraw-layout-before-hook - ecb-show-ecb-windows-after-hook - ecb-show-ecb-windows-before-hook - ecb-windows-height - ecb-windows-width - ecb-compile-window-height  File: ecb.info, Node: Conflicts and bugs, Next: FAQ, Prev: Elisp programming, Up: Top Known conflicts and bugs of ECB ******************************* This chapter describes all already known conflicts with other packages and also the known (and currently unfixed) bugs of ECB. If possible then a practicable solution or workaround is described. * Menu: * Conflicts:: Known conflicts with other packages * Bugs:: Known bugs