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.
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:
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.
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 Window-managers and ECB). With such a window-manager ECB and BBDB should work together very well under all circumstances!
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)))) )))
There can be a conflict between ECB and cygwin-mount.el if the following conditions are true:
cygwin-mount-build-mount-table-asynchto not nil
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
first *AFTER* ECB is activated. This can be done with the hook
(add-hook 'ecb-activate-hook (function (lambda () (require 'cygwin-mount) (setq cygwin-mount-build-mount-table-asynch t) (cygwin-mount-activate))))
ECB works perfectly with the desktop-saver desktop.el. Normally there should be nothing to do for you.
But if you encounter problems (e.g. that desktop tries to activate ECB for
each buffer it loads) then you should add the following entry to the option
If you still encounter problems then you should add entries for all the
minor-mode of the semantic-package to
desktop-minor-mode-table, so for
example add also:
(semantic-decoration-mode nil) (semantic-idle-completions-mode nil) (semantic-idle-tag-highlight-mode nil) (semantic-idle-summary-mode nil) (semantic-idle-scheduler-mode nil) (senator-isearch-semantic-mode nil) (senator-minor-mode nil) (semantic-highlight-func-mode nil) (semantic-stickyfunc-mode nil) (semantic-show-parser-state-mode nil) (semantic-show-unmatched-syntax-mode nil (semantic-highlight-edits-mode nil
Normally this should not be necessary, because semantic is already prepared to
work perfectly with desktop.el. But if there are problems it's worth a try.
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
ecb-tip-of-the-day) fixes the compatibility-problems
with desktop.el. Just try it out!
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.
In most cases ECB works very well with ediff (see option
ecb-run-ediff-in-ecb-frame). But currently suspending ediff
ediff-suspend and restoring the ediff-session (e.g. with
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
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 ;-)
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 Window-managers and ECB). With such a window-manager ECB and Gnus should work together very well under all circumstances!
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 persistent compile-window is used
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.
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.
vc-delete-logbuf-window must be set to nil during
active ECB. This can be done with the hooks mentioned in Elisp programming.
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 Window-managers and ECB). With such a window-manager ECB and VM should work together very well under all circumstances!
winner-mode is autom. disabled as long as ECB is running. ECB
has its own window-management which is completely incompatible with
winner-mode makes also not really sense
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.
Xrefactory (also known as Xref, X-ref and Xref-Speller), the refactoring browser for (X)Emacs1, 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 - Window-managers and ECB).
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 Window-managers and ECB).
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):
(defecb-advice XXX before ecb-compatibility-advices "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.
Please note: You have to define such compatibility advices exactly as
demonstrated in the example above, i.e. you must use the macro
defecb-advice and you have to use the advice-set
ecb-compatibility-advices (see the documentation of this macro)! The
advice-class is not necessary
before, it can be
around too. Never use
defadvice for ECB-advices!
If such an advice solves the problem then please send a note 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 Submitting problem report). This report should contain a detailed description which command of which package fails under which circumstances!