1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
|
<html lang="en">
<head>
<title>ECB - the Emacs Code Browser</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name=description content="ECB - the Emacs Code Browser">
<meta name=generator content="makeinfo 4.2">
<link href="http://www.gnu.org/software/texinfo/" rel=generator-home>
</head>
<body>
<p>
Node:<a name="Conflicts">Conflicts</a>,
Next:<a rel=next accesskey=n href="Bugs.html#Bugs">Bugs</a>,
Previous:<a rel=previous accesskey=p href="Conflicts-and-bugs.html#Conflicts%20and%20bugs">Conflicts and bugs</a>,
Up:<a rel=up accesskey=u href="Conflicts-and-bugs.html#Conflicts%20and%20bugs">Conflicts and bugs</a>
<hr><br>
<h3>Conflicts with other packages</h3>
<p>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.
<p>But in front of this "know-conflicts-and-solutions-list" a general
recipe is given what you can do when you have detected a conflict
between ECB and a package not listed in the know-conflicts-section.
<h4>What to do for unknown conflicts with other packages</h4>
<p>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 <a href="Window-managers-and-ECB.html#Window-managers%20and%20ECB">Window-managers and ECB</a>).
<p>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!
<p>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):
<br><pre>(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))))
</pre>
<p>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.
<p>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
<p>If calling from an edit-window fails too then please file a complete
bug-report to the ECB-mailing-list (see <a href="Submitting-problem-report.html#Submitting%20problem%20report">Submitting problem report</a>). This report should contain a detailed description which
command of which package fails under which circumstances!
<h4>Known conflicts and proper solutions/work-arounds</h4>
<p>Here is a list of known conflicts of ECB with other packages and
helpful solutions/hints/workarounds:
<h5>Package avoid.el</h5>
<p>With GNU Emacs 20.X ECB must deactivate <code>mouse-avoidance-mode</code> if the
option <code>ecb-show-node-info-in-minibuffer</code> activates for at least one
ECB tree-buffer 'if-too-long or 'always. This is done automatically
but only as long ECB is activated.
<h5>Package bs.el</h5>
<p>The package bs.el offers a nifty buffer-selection buffer. The main
command of this package is <code>bs-show</code>. 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.
<p>If you add "*buffer-selection*" as buffer-name to the option
<code>ecb-compilation-buffer-names</code> 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.
<h5>Package BBDB</h5>
<p>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.
<p>But if you encounter problems then it is recommened to use one of the
window-managers escreen.el or winring.el (see <a href="Window-managers-and-ECB.html#Window-managers%20and%20ECB">Window-managers and ECB</a>). With such a window-manager ECB and BBDB should work together
very well under all circumstances!
<h5>Package calculator.el</h5>
<p>The following is only for ECB-versions < 2.20. From beginning with
version 2.20 there are no conflicts with the package calculator.el!
<p>If the edit-window is already splitted then calling <code>calculator</code> uses
the whole "other" edit-window for the calculator. With an unsplitted
edit-window the calculator window has itŽs normal size of about 2
lines. Therefore itŽs recommended to set <code>calculator-electric-mode</code>
during ECB activation to not nil so calculator uses always the
echo-area instead of creating a new small window!
<h5>Package calendar.el</h5>
<p>With activated ECB <code>calendar</code> does not shrink itŽs window to the small
size but splits the window equally. But if you add this to your
<code>.emacs</code> it works:
<br><pre>(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))))
)))
</pre>
<h5>Package cygwin-mount.el</h5>
<p>There can be a conflict between ECB and cygwin-mount.el if the
following conditions are true:
<ul>
<li>You are working with cygwin-mount.el (sounds clear :-)
<li>You have set <code>cygwin-mount-build-mount-table-asynch</code> to not
nil
<li>ECB is automatically started after starting Emacs (e.g. with
<code>ecb-auto-activate</code> or calling <code>ecb-activate</code> in
<code>window-setup-hook</code>)
<li>Your Emacs-setup contains a call of <code>cygwin-mount-activate</code>.
</ul>
<p>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.
<p>But there is an easy work-around: Call <code>cygwin-mount-activate</code>
first *AFTER* ECB is activated. This can be done with the hook
<code>ecb-activate-hook</code>:
<br><pre>(add-hook 'ecb-activate-hook
(function (lambda ()
(require 'cygwin-mount)
(setq cygwin-mount-build-mount-table-asynch t)
(cygwin-mount-activate))))
</pre>
<h5>Package edebug (Lisp Debugger)</h5>
<p>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.
<h5>Package ediff.el</h5>
<p>In most cases ECB works very well with ediff (see option
<code>ecb-run-ediff-in-ecb-frame</code>). But currently suspending ediff
with <code>ediff-suspend</code> and restoring the ediff-session (e.g. with
command <code>eregistry</code>) does confuse the window-management of ECB.
<p>If you often use ediff in a scenario where you suspend ediff and
reactivate it later then it is recommended to exit ECB first
(<code>ecb-deactivate</code> or <code>ecb-minor-mode</code>)!
<h5>Package escreen.el</h5>
<p>Beginning with version 1.96 ECB supports the window-manager
escreen.el. See <a href="Window-managers-and-ECB.html#Window-managers%20and%20ECB">Window-managers and ECB</a>.
<h5>Package follow-mouse.el</h5>
<p>The following is only relevant for Emacs 20.X!
<p>ECB works very well with follow-mouse if follow-mouse is turned on
<strong>BEFORE</strong> ECB is activated (e.g. within the
<code>ecb-activate-hook</code>). 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!
<h5>Package Gnus (Newsreader)</h5>
<p>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.
<p>But if you encounter problems then it is recommened to use one of the
window-managers escreen.el or winring.el (see <a href="Window-managers-and-ECB.html#Window-managers%20and%20ECB">Window-managers and ECB</a>). With such a window-manager ECB and Gnus should work together
very well under all circumstances!
<h5>Package JDEE (Java Development Environment)</h5>
<p>JDEE has a lot of "dialogs" where the user can select among several
choices. An example is importing classes via the command
<code>jde-import-find-and-import</code>. 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.
<p><strong>Caution</strong>: 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 <code>ecb-compilation-buffer-names</code>. So do not
add the string "Dialog" to this option!
<p><strong>Please Note</strong>: Regardless if a durable compile-window is used
(i.e. <code>ecb-compile-window-height</code> 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.
<h5>Package scroll-all.el (scroll-all-mode)</h5>
<p>ECB advices <code>scroll-all-mode</code> 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
<code>scroll-all-mode</code> and no other window! If point stays in any
other window just this selected window is scrolled. This is the only
senseful behavior of <code>scroll-all-mode</code> with ECB.
<h5>Package tmm.el (Text mode menu)</h5>
<p>In general this library does not work perfectly with ECB. Beginning
with version 1.95.2 ECB autom. ensures that every code which uses
<code>tmm-prompt</code> (e.g. <code>tmm-menubar</code>) works.
<h5>Package VC (Version Control)</h5>
<p>The variable <code>vc-delete-logbuf-window</code> must be set to nil during
active ECB. This can be done with the hooks mentioned in <a href="Elisp-programming.html#Elisp%20programming">Elisp programming</a>.
<h5>Package VM (Emacs Mail-Client)</h5>
<p>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.
<p>But if you encounter problems then it is recommened to use one of the
window-managers escreen.el or winring.el (see <a href="Window-managers-and-ECB.html#Window-managers%20and%20ECB">Window-managers and ECB</a>). With such a window-manager ECB and VM should work together very
well under all circumstances!
<h5>Package winner.el (winner-mode)</h5>
<p><code>winner-mode</code> is autom. disabled as long as ECB is running. ECB
has its own window-management which is completely incompatible with
<code>winner-mode</code>! But <code>winner-mode</code> makes also not really sense
with ECB.
<h5>Package winring.el</h5>
<p>Beginning with version 1.96 ECB supports the window-manager
winring.el. See <a href="Window-managers-and-ECB.html#Window-managers%20and%20ECB">Window-managers and ECB</a>.
<h5>Application xrefactory</h5>
<p>Xrefactory (also known as Xref, X-ref and Xref-Speller), the
refactoring browser for (X)Emacs<a rel=footnote href="#fn-1"><sup>1</sup></a>, 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.
<p>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 - <a href="Window-managers-and-ECB.html#Window-managers%20and%20ECB">Window-managers and ECB</a>).
<hr><h4>Footnotes</h4>
<ol type="1">
<li><a name="fn-1"></a>
<p>Xrefactory is available at
<a href="http://www.xref-tech.com">http://www.xref-tech.com</a>
</p>
</ol><hr>
</body></html>
|