File: Background-information.html

package info (click to toggle)
ecb 2.32-1
  • links: PTS
  • area: main
  • in suites: etch, etch-m68k, lenny, squeeze
  • size: 5,236 kB
  • ctags: 1,790
  • sloc: lisp: 24,391; makefile: 143; sh: 57
file content (87 lines) | stat: -rw-r--r-- 4,094 bytes parent folder | download
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
<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="Background%20information">Background information</a>,
Previous:<a rel=previous accesskey=p href="User-interface.html#User%20interface">User interface</a>,
Up:<a rel=up accesskey=u href="Auto.-option-upgrading.html#Auto.%20option-upgrading">Auto. option-upgrading</a>
<hr><br>

<h4>Background information</h4>

<p>Big packages like ECB will be enhanced and developed continuously so
sometimes a new version must be released. Such packages offer in
general a lot of customizable options so probably some of these
options change the type or are renamed because the old type and/or
name of the option makes no sense in the new release.

<p>Especially options which have changed the type of their value are now
a problem for the user which want to upgrade to the latest
ECB-version: If the user has saved a certain value for option X in its
file <code>.emacs</code> but the type of this saved value doesn't match the
new defined type in the defcustom-form after an ECB-upgrade then there
can occur serious problems like ECB can not be started anymore or even
Emacs can not be started without errors.

<p>Until now there was only one way to fix these problems: The user must
manually edit his file <code>.emacs</code> and remove all entries for
options which have now another type. After this and after restarting
Emacs the new default-values of the type-changed options in the new
ECB-release are active and the user can go on using Emacs and ECB. But
this approach to fix the incompatible-option-problem has two serious
drawbacks:

<ol type=1 start=1>
</p><li>The user must manually edit the customize-section in his file
<code>.emacs</code>. This should normally not be done and if then only by
old-handed Emacs-users.

<li>The customized value of the option X in the old-release (with the old
type) is lost because after removing the related entry from the
file <code>.emacs</code> the new default-value is active, so the user must
re-customize the option X.
</ol>

<p>OK, this is one half of the option-upgrade-problem but a new ECB-release
can also rename a option from name X to name Y because the new name Y makes
much more sense and/or is more mnemonic. If only the name has changed but
not the type this is not a serious problem like above but also annoying
because the customized value of the old-option X takes no effect in the new
release but instead the default-value of the new-option Y is now active. 
But nevertheless this problem has the drawback number 2 (see above).

<p>The last category of upgrade-problems is a renamed option which has also
changed its type.

<p>ECB has a solution for all these problems:

<ul>

<li>It checks all customized values of all ECB-options if they are still
type-compatible. If not then it tries to upgrade the old-value to the
new value-type and if this is not possible then it resets the option
to the new default value and offers then to store it via customize in
the .emacs-file (or in any file which is used for customized options). 
But ECB does not touch any customization-file without asking the user!

<li>It offers a special constant <code>ecb-upgradable-option-alist</code> which
allows the ECB-maintainers to define special transformings for renamed
options so even the value of an old-option X can be savely transformed
to the new-option Y and the old setting is not lost. 
</ul>

<p>All these checks and transformings are done at beginning of activating
ECB - if the option <code>ecb-auto-compatibility-check</code> is not nil. If
ECB has recognized incompatible or renamed options it does its
upgrading/reseting-job so all ECB-options have correct types so ECB
can start correct. After ECB is started it displays a list of all
upgraded or reseted option with their old and new values.

</body></html>