10. Conflicts and bugs of ECB

This chapter describes what to do when there are conflicts with other packages and also the known (and currently unfixed) bugs of ECB. If possible (and in most cases it is possible ;-) then a practicable solution or workaround is described.

10.1 Conflicts with other packages

This chapter contains a list of already known conflict between ECB and other packages and how to solve them - in most cases ECB already contains a suitable workaround.

That is followed by a general recipe what you can do when you have detected a conflict between ECB and a package is not listed in the know-conflicts-section.

10.1.1 Proved workarounds or recommendations for other packages

Here is a list of packages which are proved to work properly with ECB and if not (i.e. there are conflicts) then helpful solutions/hints/workarounds are offered:

10.1.1.1 Package avoid.el

With GNU Emacs 20.X ECB must deactivate mouse-avoidance-mode if the option ecb-show-node-info-in-minibuffer activates for at least one ECB tree-buffer 'if-too-long or 'always. This is done automatically but only as long ECB is activated.

10.1.1.2 Package bs.el

The package bs.el offers a nifty buffer-selection buffer. The main command of this package is bs-show. With ECB < 2.20 this command does not really working well within activated ECB. But as of version 2.20 of ECB there should be no problems using this package.

If you add "*buffer-selection*" as buffer-name to the option ecb-compilation-buffer-names then ECB will always display the buffer-selection buffer of bs in the compile-window (if there is one). Otherwise bs will use the edit-area to do its job.

10.1.1.3 Package BBDB

As of ECB 2.21 there should be no conflicts between BBDB and ECB, so BBDB can be used even when the ECB-windows are visible.

But if you encounter problems then it is recommened to use one of the window-managers escreen.el or winring.el (see section 8.16 Support of several Emacs-window-managers). With such a window-manager ECB and BBDB should work together very well under all circumstances!

10.1.1.4 Package calendar.el

With activated ECB calendar does not shrink itīs window to the small size but splits the window equally. But if you add this to your `.emacs' it works:

(add-hook 'initial-calendar-window-hook
          (function (lambda ()
                      (when (and ecb-minor-mode
                                 (ecb-point-in-edit-window))
                        ;; if no horizontal split then nothing
                        ;; special to do
                        (or (= (frame-width) (window-width))
                            (shrink-window (- (window-height) 9))))
                     )))

10.1.1.5 Package cygwin-mount.el

There can be a conflict between ECB and cygwin-mount.el if the following conditions are true:

• You are working with cygwin-mount.el (sounds clear :-)
• You have set cygwin-mount-build-mount-table-asynch to not nil
• ECB is automatically started after starting Emacs (e.g. with ecb-auto-activate or calling ecb-activate in window-setup-hook)
• Your Emacs-setup contains a call of cygwin-mount-activate.

Under these circumstances Emacs 21.X sometimes eats up the whole CPU (at least with Windows XP) and the cygwin-mount-table is never build.

But there is an easy work-around: Call cygwin-mount-activate first *AFTER* ECB is activated. This can be done with the hook ecb-activate-hook:

(add-hook 'ecb-activate-hook
          (function (lambda ()
                      (require 'cygwin-mount)
                      (setq cygwin-mount-build-mount-table-asynch t)
                      (cygwin-mount-activate))))

10.1.1.6 Package desktop.el

ECB works perfectly with the desktop-saver desktop.el. But to ensure this the option desktop-minor-mode-table MUST contain the following entry:

(ecb-minor-mode nil)

Without this entry desktop.el tries for each buffer it loads after Emacs-start to enable ecb-minor-mode and therefore to start ECB. This conflicts with ECB! Therefore you must add the entry above to desktop-minor-mode-table!

Further it is strongly recommended to add entries for all the minor-mode of the semantic-package to desktop-minor-mode-table, so for example add also:

(semantic-show-unmatched-syntax-mode nil)
(semantic-stickyfunc-mode nil)
(senator-minor-mode nil)
(semantic-idle-scheduler-mode nil)

Which modes you have to add depends on which modes of semantic you use. But to get sure you should add all minor-modes of the semantic-package because these modes are normally activated by the related "global" command (e.g. global-semantic-show-unmatched-syntax-mode) or by adding the minor-mode to the related major-mode-hook.

It has also been reported that just disabling the Tip-Of-The-Day (option: ecb-tip-of-the-day) fixes the compatibility-problems with desktop.el. Just try it out!

10.1.1.7 Package edebug (Lisp Debugger)

It is strongly recommended to run edebug only when the ECB-windows are hidden. With visible ECB-windows there will probably serious conflicts between the ECB-layout and the edebug-window-manager.

10.1.1.8 Package ediff.el

In most cases ECB works very well with ediff (see option ecb-run-ediff-in-ecb-frame). But currently suspending ediff with ediff-suspend and restoring the ediff-session (e.g. with command eregistry) does confuse the window-management of ECB.

If you often use ediff in a scenario where you suspend ediff and reactivate it later then it is recommended to exit ECB first (ecb-deactivate or ecb-minor-mode)!

10.1.1.9 Package follow-mouse.el

The following is only relevant for Emacs 20.X!

ECB works very well with follow-mouse if follow-mouse is turned on BEFORE ECB is activated (e.g. within the ecb-activate-hook). But if you activate follow-mouse first after ECB is already activated, then the follow-mouse stuff prevents the complete node-name to be displayed in the echo-area if mouse moves over it. Because ECB has a much more intelligent mouse tracking mechanism than follow-mouse the follow-mouse stuff profit from ECB and works even better and saver as without activated ECB!

10.1.1.10 Package func-menu.el

This package has been reported to produce some conflicts under some circumstances when ECB is activated. Some of them could be reproduced by the ECB-maintainer. So the recommendation is to disable func-menu-support when using ECB. Normally using func-menu makes no sense in combination with ECB because ECB provides the same and even more informations as func-menu - so func-menu is redundant ;-)

10.1.1.11 Package Gnus (Newsreader)

As of ECB 2.21 there should be no conflicts between Gnus and ECB, so Gnus can be used even when the ECB-windows are visible.

But if you encounter problems then it is recommened to use one of the window-managers escreen.el or winring.el (see section 8.16 Support of several Emacs-window-managers). With such a window-manager ECB and Gnus should work together very well under all circumstances!

10.1.1.12 Package JDEE (Java Development Environment)

JDEE has a lot of "dialogs" where the user can select among several choices. An example is importing classes via the command jde-import-find-and-import. These dialogs are strongly designed to work in an environment where a new temporary window is created, the contents of the dialog are displayed in the new window, the user select his choice and hits [OK]. After that the new window is deleted and the selection is performed (for example the chosen import statement are inserted in the source-buffer.

Caution: ECB can work very well with this dialogs but only if the buffer-name of these dialog-buffers (normally "Dialog") is not contained in the option ecb-compilation-buffer-names. So do not add the string "Dialog" to this option!

Please Note: Regardless if a durable compile-window is used (i.e. ecb-compile-window-height is not nil) or not, these JDEE-dialogs will always being displayed by splitting the edit-window of ECB and not within the compile-window.

10.1.1.13 Package scroll-all.el (scroll-all-mode)

ECB advices scroll-all-mode so it is working correct during running ECB. This means if point stays in an edit-window and the edit-window is splitted then all edit-windows are scrolled by scroll-all-mode and no other window! If point stays in any other window just this selected window is scrolled. This is the only senseful behavior of scroll-all-mode with ECB.

10.1.1.14 Package VC (Version Control)

The variable vc-delete-logbuf-window must be set to nil during active ECB. This can be done with the hooks mentioned in 9. Entry points for Elisp programmers.

10.1.1.15 Package VM (Emacs Mail-Client)

As of ECB 2.21 there should be no conflicts between VM and ECB, so VM can be used even when the ECB-windows are visible.

But if you encounter problems then it is recommened to use one of the window-managers escreen.el or winring.el (see section 8.16 Support of several Emacs-window-managers). With such a window-manager ECB and VM should work together very well under all circumstances!

10.1.1.16 Package winner.el (winner-mode)

winner-mode is autom. disabled as long as ECB is running. ECB has its own window-management which is completely incompatible with winner-mode! But winner-mode makes also not really sense with ECB.

10.1.1.17 Package wb-line-number.el

Do not use the package wb-line-number.el in combination with ECB - it will not work and it will not work under any circumstances and there is no way to make it work together and there will be no way in the future!

The reason behind that is: wb-line-number.el uses additional dedicated windows to display the line-numbers. And ECB can not work if there there are additional dedicated windows - additional to that ones created by ECB.

10.1.1.18 Application xrefactory

Xrefactory (also known as Xref, X-ref and Xref-Speller), the refactoring browser for (X)Emacs(46), can be used during running ECB regardless if the ECB-windows are visible or not. There should be no conflicts as of ECB versions >= 2.21.

If there are conflicts with the Xref-browser then the most recommended way is to use one of the window-manager escreen.el or winring.el (and then use different escreens or window-configurations for ECB and Xrefactory-browsing - 8.16 Support of several Emacs-window-managers).

10.1.2 What to do for unknown conflicts with other packages

As of version 2.20 the layout-engine of ECB is so flexible that normally there should be no conflicts with other packages unless these packages have their own complete window-layout-management (e.g. Gnus, BBDB, Xrefactory). But these packages can and should be handled very well with the window-manager-support of ECB (see section 8.16 Support of several Emacs-window-managers).

So if you detect an unknown (i.e. not listed in the conflicts-list in the next subsection) conflict with a small package and some of its commands and you have installed an ECB-version < 2.20 the first task you have to do is to upgrade to a version >= 2.20!

If this doesn't solve the problem a very probable reason for the conflict is that the command fails if called from another window than an edit-window of the ecb-frame. So please check if the problem disappears if you call the failing command from an edit-window of ECB. If this is true then you you can add the following code to your .emacs (and of course replace the XXX with the failing command):

(defadvice XXX (before ecb activate)
  "Ensures `XXX' works well when called from another window
as an edit-window. Does nothing if called in another frame
as the `ecb-frame'."
  (when (equal (selected-frame) ecb-frame)
    (unless (ecb-point-in-edit-window)
      (ecb-select-edit-window))))

This before-advice runs before the command XXX and ensures that the XXX is called from within an edit-window if the current selected window is not an edit-window. It does nothing if called for another frame as the ecb-frame.

If such an advice solves the problem then please send a not with the solution to the ECB-mailing-list or direct to the ECB-maintainer so the solution can be integrated in the next ECB-release

If calling from an edit-window fails too then please file a complete bug-report to the ECB-mailing-list (see section 6. Submitting a problem report). This report should contain a detailed description which command of which package fails under which circumstances!

10.2 Known bugs

This section describes all currently known bugs of ECB. The maintainers of ECB try to fix these bugs as soon as possible.

10.2.1 Following the source-file link in a help-buffer

The following bug occurs only in ECB-versions < 1.96 and is fixed since ECB 1.96!!

This bug only occurs if a compile-window is used and visible!

If you call functions like describe-function which displays a help-buffer in the compile-window, then you will often get an output like this in the compile-window:

ecb-activate is an interactive compiled Lisp function in `ecb'.
(ecb-activate)

Activates the ECB...

The link to `ecb' is normally a click-able link, means if you click with the middle-mouse button onto it the file is opened (in our example `ecb.el' would be opened.

If you click onto it when the help-buffer is already the current buffer (i.e. the compile-window is already selected before the click!) then all is working fine (i.e. the file is opened in the edit-window), but if you click onto the link without selecting the compile-window before (i.e. the edit-window is the current selected window) then the file is opened in the compile-window which is probably not what you want. Not a big problem but annoying.

The only available workaround is, first selecting the compile-window and then clicking onto the link!

10.2.2 Extra history-entries for JDEE source-buffers

ECB on occasions creates an extra edit buffer for entries in the history window. For example, let say there are three entries in the history window:

Test1
Test2
Test3

In the edit window Test1 file is edited. When clicked on Test2 entry in history, on occasion instead of switching to the existing buffer for Test2, a new edit buffer is opened for Test2 file. At this point, there are four entries in the history as follows:

Test2
Test2<2>
Test1
Test3

This document was generated by XEmacs shared group account on December, 19 2009 using texi2html 1.65.