summaryrefslogtreecommitdiff
path: root/info/emacs-14
blob: 8b28d91c4c9881ac73d7bb65314c722553b03801 (plain)
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
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
This is Info file ../info/emacs, produced by Makeinfo-1.49 from the
input file emacs.texi.

   This file documents the GNU Emacs editor.

   Copyright (C) 1985, 1986, 1988, 1992 Richard M. Stallman.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "The GNU Manifesto", "Distribution" and "GNU
General Public License" are included exactly as in the original, and
provided that the entire resulting derived work is distributed under the
terms of a permission notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "The GNU Manifesto",
"Distribution" and "GNU General Public License" may be included in a
translation approved by the author instead of in the original English.


File: emacs,  Node: Concepts of VC,  Next: Editing with VC,  Up: Version Control

Concepts of Version Control
---------------------------

   When a file is under version control, we also say that it is
"registered" in the version control system.  Each registered file has a
corresponding "master file" which represents the file's present state
plus its change history, so that you can reconstruct from it either the
current version or any specified earlier version.  Usually the master
file also records a change comment for each version.

   The file that is maintained under version control is sometimes called
the "work file" corresponding to its master file.

   To examine a file, you "check it out".  This extracts a version of
the file (typically, the most recent) from the master.  If you want to
edit the file, you must check it out "locked".  Only one user can do
this at a time for any given source file.  When you are done with your
editing, you must "check in" the new version.  This records the new
version in the master file, and unlocks the source file so that other
people can lock it and thus modify it.

   These are the basic operations of version control. Checking in and
checking out both use the single Emacs command `C-x C-q'
(`vc-toggle-read-only').


File: emacs,  Node: Editing with VC,  Next: Variables for Check-in/out,  Prev: Concepts of VC,  Up: Version Control

Editing with Version Control
----------------------------

   When you visit a file that is maintained using version control, the
mode line displays `RCS' or `SCCS' to inform you that version control
is in use, and also (in case you care) which low-level system the file
is actually stored in.  Normally, such a source file is read-only, and
the mode line indicates this with `%%'.)

   These are the commands that you use to edit a file maintained with
version control:

`C-x C-q'
     Check the visited file in or out.

`C-x v u'
     Revert the buffer and the file to the last checked in version.

`C-x v c'
     Remove the last-entered change from the master for the visited
     file. This undoes your last check-in.

`C-x v i'
     Register the visited file in version control.

(`C-x v' is the prefix key for version control commands; all of these
commands except for `C-x C-q' start with `C-x v'.)

   If you want to edit the file, type `C-x C-q'
(`vc-toggle-read-only').  This "checks out" and locks the file, so that
you can edit it.  The file is writable after check-out, but only for
you, not for anyone else.

   Emacs does not save backup files for source files that are maintained
with version control.  If you want to make backup files despite version
control, set the variable `vc-make-backups' to a non-`nil' value.

   When you are finished editing the file, type `C-x C-q' again. When
used on a file that is checked out, this command checks the file in. 
But check-in does not start immediately; first, you must enter a "log
entry"--a description of the changes in the new version. `C-x C-q' pops
up a buffer for you to enter this in.  When you are finished typing in
the log entry, type `C-c C-c' to terminate it; this is when actual
check-in takes place.

   Once you have checked in your changes, the file is unlocked, so that
other users can lock it and modify it.

   Normally the work file exists all the time, whether it is locked or
not.  If you set `vc-keep-workfiles' to `nil', then checking in a new
version with `C-x C-q' deletes the work file; but any attempt to visit
the file with Emacs creates it again.

   Actually, it is not impossible to lock a file that someone else has
locked.  If you try to check out a file that is locked, `C-x C-q' asks
you whether you want to "steal the lock."  If you say yes, the file
becomes locked by you, but a message is sent to the person who had
formerly locked the file, to inform him or her of what has happened.

   If you want to discard your current set of changes and revert to the
last version checked in, use `C-x v u' (`vc-revert-buffer'). This
cancels your last check-out, leaving the file unlocked.  If you want to
make a different set of changes, you must first check the file out
again.  `C-x v u' requies confirmation, unless it sees that you haven't
made any changes since the last checked-in version.

   `C-x v u' is also the command to use if you lock a file and then
don't actually change it.

   You can even cancel a change after checking it in, with `C-x v c'
(`vc-cancel-version').  Normally, `C-x v c' reverts your workfile and
buffer to the previous version (the one that precedes the version that
is deleted), but you can prevent the reversion by giving the command a
prefix argument.  Then the buffer does not change.

   This command with a prefix argument is useful when you have checked
in a change and then discover a trivial error in it; you can cancel the
erroneous check-in, fix the error, and repeat the check-in.

   Be careful when invoking `C-x v c', as it is easy to throw away a
lot of work with it.  To help you be careful, this command always asks
for confirmation with `yes'.

   You can register the visited file for version control using
`C-x v i' (`vc-register').  This uses RCS if RCS is installed on your
system; otherwise, it uses SCCS.

   By default, the initial version number is 1.1.  If you want to use a
different number, give `C-x v i' a prefix argument; then it reads the
initial version number using the minibuffer.

   After `C-x v i', the file is unlocked and read-only.  Type `C-x C-q'
if you wish to edit it.

   If `vc-initial-comment' is non-`nil', `C-x v i' reads an initial
comment (much like a log entry) to describe the purpose of this source
file.


File: emacs,  Node: Variables for Check-in/out,  Next: Comparing Versions,  Prev: Editing with VC,  Up: Version Control

Variables Affecting Check-in and Check-out
------------------------------------------

   If `vc-suppress-confirm' is non-`nil', then `C-x C-q' and `C-x v i'
can save the current buffer without asking, and `C-x v u' also operates
without asking for confirmation. (This variable does not affect `C-x v
c'; that is so drastic that it should always ask for confirmation.)

   VC mode does much of its work by running the shell commands for RCS
and SCCS.  If `vc-command-messages' is non-`nil', VC displays messages
to indicate which shell commands it runs, and additional messages when
the commands finish.

   Normally, VC assumes that it can deduce the locked/unlocked state of
files by looking at the file permissions of the work file; this is
fast.  However, if the `RCS' or `SCCS' subdirectory is actually a
symbolic link, then VC does not trust the file permissions to reflect
this status.

   You can specify the criterion for whether to trust the file
permissions by setting the variable `vc-mistrust-permissions'.  Its
value may be `t' (always mistrust the file permissions and check the
master file), `nil' (always trust the file permissions), or a function
of one argument which makes the decision.  The argument is the directory
name of the `RCS' or `SCCS' subdirectory.  A non-`nil' value from the
function says to mistrust the file permissions.

   If you find that the file permissions of work files are changed
erroneously, then you can set `vc-mistrust-permissions' to `t' so that
VC always checks the master file.


File: emacs,  Node: Log Entries,  Next: Change Logs and VC,  Prev: Snapshots,  Up: Version Control

Log Entries
-----------

   When you're editing an initial or change comment for inclusion in a
master file, finish your entry by typing `C-c C-c'.

`C-c C-c'
     Finish the comment edit normally (`vc-finish-logentry'). This
     finishes check-in.

   To abort check-in, just don't type `C-c C-c' in that buffer.  You
can switch buffers and do other editing.  As long as you don't try to
check in another file, the comment you were editing remains in its
buffer, and you can go back to that buffer at any time to complete the
check-in.

   If you change several source files for the same reason, it is often
convenient to specify the same log entry for many of the files.  To do
this, use the history of previous log entries.  The commands `M-n',
`M-p', `M-s' and `M-r' for doing this work just like the minibuffer
history commands (except that they don't use the minibuffer).

   The history of previous log entries is actually stored in previous
pages of the log entry editing buffer; they are normally hidden by
narrowing.

   Each time you check in a file, the log entry buffer is put into VC
Log mode, which involves running two hook variables: `text-mode-hook'
and `vc-log-mode-hook'.


File: emacs,  Node: Change Logs and VC,  Next: Version Headers,  Prev: Log Entries,  Up: Version Control

Change Logs and VC
------------------

   Emacs users often record brief summaries of program changes in a file
called `ChangeLog', which is kept in the same directory as the source
files, and is usually meant to be distributed along with the source
files.  You can maintain `ChangeLog' from the version control logs with
the following command.

`C-x v a'
     Visit the current directory's change log file and create new
     entries for versions checked in since the most recent entry in the
     change log file (`vc-update-change-log').

     This command works with RCS only; it does not work with SCCS.

   For example, suppose the first line of `ChangeLog' is dated 10 April
1992, and suppose the only check-in since then was by Nathaniel
Bowditch to `rcs2log' on 8 May 1992 with log text `Ignore log messages
that start with `#'.'.  Then `C-x v a' visits `ChangeLog' and inserts
text like this:

     Fri May  8 21:45:00 1992  Nathaniel Bowditch  (nat@apn.org)
     
             * rcs2log: Ignore log messages that start with `#'.

You can then further edit as you wish.

   A log entry whose text begins with `#' is not copied to `ChangeLog'.
 For example, if you merely fix some misspellings in comments, you can
log the change with an entry beginning with `#' to avoid putting such
trivia into `ChangeLog'.

   When `C-x v a' adds several change log entries at once, it groups
related log entries together if they all are checked in by the same
author at nearly the same time.  If the log entries for several such
files all have the same text, it coalesces them into a single entry.
For example, suppose the most recent check-ins have the following log
entries:

For `vc.texinfo':
     Fix expansion typos.
For `vc.el':
     Don't call expand-file-name.
For `vc-hooks.el':
     Don't call expand-file-name.

   They appear like this in `ChangeLog':

     Wed Apr  1 08:57:59 1992  Nathaniel Bowditch  (nat@apn.org)
     
             * vc.texinfo: Fix expansion typos.
     
             * vc.el, vc-hooks.el: Don't call expand-file-name.

   Normally, `C-x v a' separates log entries by a blank line, but you
can mark several related log entries to be clumped together (without an
intervening blank line) by starting the text of each related log entry
with a label of the form `{CLUMPNAME} '.  The label itself is not
copied to `ChangeLog'.  For example, suppose the log entries are:

For `vc.texinfo':
     {expand} Fix expansion typos.
For `vc.el':
     {expand} Don't call expand-file-name.
For `vc-hooks.el':
     {expand} Don't call expand-file-name.

   Then the text in `ChangeLog' looks like this:

     Wed Apr  1 08:57:59 1992  Nathaniel Bowditch  (nat@apn.org)
     
             * vc.texinfo: Fix expansion typos.
             * vc.el, vc-hooks.el: Don't call expand-file-name.

   Normally, the log entry for file `foo' is displayed as `* foo: TEXT
OF LOG ENTRY'.  But by convention, the `:' after `foo' is omitted if
the text of the log entry starts with `(FUNCTIONNAME): '.  For example,
if the log entry for `vc.el' is `(vc-do-command): Check call-process
status.', then the text in `ChangeLog' looks like this:

     Wed May  6 10:53:00 1992  Nathaniel Bowditch  (nat@apn.org)
     
             * vc.el (vc-do-command): Check call-process status.


File: emacs,  Node: Comparing Versions,  Next: VC Status,  Prev: Variables for Check-in/out,  Up: Version Control

Comparing Versions
------------------

   To compare two versions of a file, use `C-x v =' (`vc-diff').

   Plain `C-x v =' compares the current buffer contents (saving them in
the file if necessary) with the last checked-in version of the file.
With a prefix argument, `C-x v =' reads a filename and two version
numbers, and compares those versions of the file you specify.

   If you supply a directory name instead of the name of a work file,
this command compares the two specified versions of all registered files
in that directory and its subdirectories.  You can also specify a
snapshot name (*note Snapshots::.) instead of one or both version
numbers.

   You can specify a checked-in version by its number; you can specify
the most recent checked-in version with `-'; and you can specify the
current buffer contents with `+'.  Thus, you can compare two checked-in
versions, or compare a checked-in version with the text you are editing.

   This command works by running the `diff' utility, getting the
options from the variable `diff-switches'.  It displays the output in a
special buffer in another window.


File: emacs,  Node: VC Status,  Next: Renaming and VC,  Prev: Comparing Versions,  Up: Version Control

VC Status Commands
------------------

   To get the detailed version control status of one file, type `C-x v
l' (`vc-print-log').  It displays the history of changes to the current
file, including the text of the log entries.  The output appears in a
separate window.

   When you are working on a large program, it's often useful to find
all the files that are currently locked, or all the files maintained in
version control at all.  You can do so using these commands, both of
which operate on the branch of the file system starting at the current
directory.

   You can use `C-x v d' (`vc-directory') to show all the locked files
in or beneath the current directory.  This includes all files that are
locked by any user.

   With a prefix argument, `C-x v d' shows all the version control
activity in the current directory--it lists all files in or beneath the
current directory that are maintained with version control.


File: emacs,  Node: Renaming and VC,  Next: Snapshots,  Prev: VC Status,  Up: Version Control

Renaming VC Work Files and Master Files
---------------------------------------

   When you rename a registered file, you must also rename its master
file correspondingly to get proper results.  Use `vc-rename-file' to
rename the source file as you specify, and rename its master file
accordingly.  It also updates any snapshots (*note Snapshots::.) that
mention the file, so that they use the new name; despite this, the
snapshot thus modified may not completely work (*note Snapshot
Caveats::.).

   You cannot use `vc-rename-file' on a file that is locked by someone
else.

   `vc-rename-file' is not bound to a key because it's not likely to be
used frequently.


File: emacs,  Node: Snapshots,  Next: Log Entries,  Prev: Renaming and VC,  Up: Version Control

Snapshots
---------

   A "snapshot" is a named set of file versions (one for each
registered file) that you can treat as a unit.  One important kind of
snapshot is a "release", a (theoretically) stable version of the system
that is ready for distribution to users.

* Menu:

* Making Snapshots::		The snapshot facilities.
* Snapshot Caveats::		Things to be careful of, when using snapshots.


File: emacs,  Node: Making Snapshots,  Next: Snapshot Caveats,  Up: Snapshots

Making and Using Snapshots
..........................

   There are two basic commands for snapshots; one makes a snapshot
with a given name, the other retrieves a named snapshot.

`C-x v s NAME RET'
     Define the last saved versions of every registered file in or
     under the current directory as a snapshot named NAME
     (`vc-create-snapshot').

`C-x v r NAME RET'
     Check out all registered files at or below the current directory
     level using whatever versions correspond to the snapshot NAME
     (`vc-retrieve-snapshot').

     This function reports an error if any files are locked at or below
     the current directory, without changing anything; this is to avoid
     overwriting work in progress.

   You shouldn't need to use `vc-retrieve-snapshot' very often; you can
get difference reports between two snapshots without retrieving either
one, using `C-x =' (*note Comparing Versions::.).  Thus, retrieving a
snapshot is only necessary if you need to study or compile portions of
the snapshot.

   A snapshot uses a very small amount of resources--just enough to
record the list of file names and which version belongs to the
snapshot.  Thus, you need not hesitate to create snapshots whenever
they are useful.

   You can give a snapshot name as an argument to `C-x v =' (*note
Comparing Versions::.).  Thus, you can use it to compare a snapshot
against the current files, or two snapshots against each other, or a
snapshot against a named version.


File: emacs,  Node: Snapshot Caveats,  Prev: Making Snapshots,  Up: Snapshots

Snapshot Caveats
................

   VC's snapshot facilities are modeled on RCS's named-configuration
support.  They use RCS's native facilities for this, so under VC
snapshots made using RCS are visible even when you bypass VC.

   For SCCS, VC implements snapshots itself.  The files it uses contain
name/file/version-number triples.  These snapshots are visible only
through VC.

   File renaming and deletion can create some difficulties with
snapshots. This is not a VC-specific problem, but a general design
issue in version control systems that no one has solved very well yet.

   If you rename a registered file, you need to rename its master along
with it (the function `vc-rename-file' does this automatically). If you
are using SCCS, you must also update the records of the snapshot, to
mention the file by its new name (`vc-rename-file' does this, too). 
This makes the snapshot remain valid for retrieval, but it does not
solve all problems.

   For example, some of the files in the program probably refer to
others by name.  At the very least, the makefile probably mentions the
file that you renamed.  If you retrieve an old snapshot, the renamed
file is retrieved under its new name, which is not the name that the
makefile expects.  So the program won't really work.

   If you use snapshots, don't rename either work files or master files
except by means of `vc-rename-file'.  It knows how to update snapshots
so that you can still retrieve them.  An old snapshot that refers to a
master file that no longer exists under the recorded name is invalid;
VC can no longer retrieve it.  It would be beyond the scope of this
manual to explain enough about RCS and SCCS to teach the reader how to
update the snapshots by hand.


File: emacs,  Node: Version Headers,  Prev: Change Logs and VC,  Up: Version Control

Inserting Version Control Headers
---------------------------------

   Sometimes it is convenient to put version identification strings
directly into working files.  Certain special strings called "version
headers" are replaced in each successive version by the number of that
version.

   You can use the `C-x v h' command (`vc-insert-headers') to insert a
suitable header string.

`C-x v h'
     Insert headers in a file for use with your version-control system.

   The default header string is `$ld$' for RCS and `%W%' for SCCS.  You
can specify other headers to insert by setting the variable
`vc-header-string'.  Its value (if non-`nil') should be the string to
be inserted.  You can also specify a list of strings; then each string
in the list is inserted as a separate header on a line of its own.  (It
is often important to use "superfluous" backslashes when writing a Lisp
string constant for this use, to prevent the string in the constant
from being interpreted as a header itself if the Emacs Lisp file
containing it is maintained with version control.)

   Each header is inserted surrounded by tabs, inside comment
delimiters, on a new line at the start of the buffer.  Normally the
ordinary comment start and comment end strings of the current mode are
used, but for certain modes, there are special comment delimiters for
this purpose; the variable `vc-comment-alist' specifies them.  Each
element of this list has the form `(MODE STARTER ENDER)'.

   `vc-static-header-alist' is consulted to add further strings based
on the name of the buffer.  Its value should be a list of dotted pairs;
the CAR of each pair is a regular expression that should match the
buffer name, and the CDR is the format to use on each header.  A string
is inserted for each file name pattern that matches the buffer name,
and for each header taken from `vc-header-string'.  The default value
for `vc-static-header-alist' is:

     (("\\.c$" .
       "\n#ifndef lint\nstatic char vcid[] = \"\%s\";\n\
     #endif /* lint */\n"))

which specifies insertion of a string of this form:


     #ifndef lint
     static char vcid[] = "HEADER-STRING";
     #endif /* lint */


File: emacs,  Node: Emerge,  Next: Debuggers,  Prev: Version Control,  Up: Version 19

Emerge
======

   It's not unusual for programmers to get their signals crossed and
modify the same program in two different directions.  To recover from
this confusion, you need to merge the two versions.  Emerge makes this
easier.

* Menu:

* Overview of Emerge::
* Submodes of Emerge::
* State of Difference::
* Merge Commands::
* Exiting Emerge::
* Combining in Emerge::
* Fine Points of Emerge::


File: emacs,  Node: Overview of Emerge,  Next: Submodes of Emerge,  Up: Emerge

Overview of Emerge
------------------

   To start Emerge, run one of these four commands:

`M-x emerge-files'
     Merge two specified files.

`M-x emerge-files-with-ancestor'
     Merge two specified files, with reference to a common ancestor.

`M-x emerge-buffers'
     Merge two buffers (the currently accessible portions).

`M-x emerge-buffers-with-ancestor'
     Merge two buffers (the currently accessible portions) with
     reference to a common ancestor in another buffer.

   The Emerge commands compare two texts, and display the results in
three buffers: one for each input text (the "A buffer" and the "B
buffer"), and one (the "merge buffer") where merging takes place. The
merge buffer does not show just the differences.  Rather, it shows you
the full text, but wherever the input texts differ, you can choose
which one of them to include in the merge buffer.

   If a common ancestor version is available, from which the two texts
to be merged were both derived, Emerge can use it to guess which
alternative is right.  Wherever one current version agrees with the
ancestor, Emerge presumes that the other current version is a deliberate
change which should be kept in the merged version.  Use the
"with-ancestor" commands if you want to specify a common ancestor text.
 These commands read three file or buffer names--variant A, variant B,
and the common ancestor.

   After the comparison is done and the buffers are prepared, the actual
merging starts.  You control the merging interactively by editing the
merge buffer.  The merge buffer shows you a full merged text, not just
differences.  For each point where the input texts differ, you can
choose which one of them to include in the merge buffer.

   The merge buffer has a special major mode, Emerge mode, with commands
for making these choices.  But you can also edit the buffer with
ordinary Emacs commands.

   At any given time, the attention of Emerge is focused on one
particular difference, called the "selected" difference.  This
difference is marked off in the three buffers by

     vvvvvvvvvvvvvvvvvvvv

above and

     ^^^^^^^^^^^^^^^^^^^^

below.  Emerge numbers all the differences sequentially and the mode
line always shows the number of the selected difference.

   Normally, the merge buffer starts out with the A version of the text.
But when the A version of a part of the buffer agrees with the common
ancestor, then the B version is preferred for that part.

   Normally, Emerge stores the merged output in place of the first input
text (the A file or buffer).  If you give a prefix argument to
`emerge-files' or `emerge-files-with-ancestor', it reads the name of
the output file using the minibuffer.  (This is the last file name
those commands read.)

   If you abort Emerge with `C-u q', the output is not saved.


File: emacs,  Node: Submodes of Emerge,  Next: State of Difference,  Prev: Overview of Emerge,  Up: Emerge

Submodes of Emerge
------------------

   You can choose between two modes for giving merge commands: Fast mode
and Edit mode.  In Fast mode, basic Emerge commands are single
characters, but ordinary Emacs commands are disabled.  This is
convenient if you use only Emerge commands.

   In Edit mode, all Emerge commands start with the prefix character
`C-c', and the normal Emacs commands are also available.  This allows
editing the merge buffer, but slows down Emerge operations.

   Use `e' to switch to Edit mode, and `f' to switch to Fast mode. The
mode line indicates Edit and Fast modes with `E' and `F'.

   Emerge has two additional submodes that affect how particular merge
commands work: Auto Advance mode and Skip Prefers mode.

   If Auto Advance mode is in effect, the `a' and `b' commands advance
to the next difference.  This lets you go through the merge faster
doing ordinary things.  The mode line indicates Auto Advance mode with
`A'.

   If Skip Prefers mode is in effect, the `n' and `p' commands skip
over differences in states prefer-A and prefer-B.  Thus you will only
see differences for which neither version is presumed "correct".  The
mode line indicates Skip Prefers mode with `S'.

   Use the command `emerge-auto-advance-mode' to set or clear Auto
Advance mode.  Use `emerge-skip-prefers-mode' to set or clear Skip
Prefers mode.  A positive argument turns the mode on, a nonpositive
argument turns it off, and no argument toggles it.


File: emacs,  Node: State of Difference,  Next: Merge Commands,  Prev: Submodes of Emerge,  Up: Emerge

State of a Difference
---------------------

   In the merge buffer, a difference is marked `vvvvvvvvvvvvvvvvvvvv'
above and `^^^^^^^^^^^^^^^^^^^^' below.  Such a difference can have one
of seven states:

A
     The difference is showing the A version.  The `a' command always
     produces this state; the mode line indicates it with `A'.

B
     The difference is showing the B version.  The `b' command always
     produces this state; the mode line indicates it with `B'.

default-A
default-B
     The difference is showing the A or the B state by default, because
     you haven't made a choice.  All differences start in the default-A
     state (and thus the merge buffer is a copy of the A buffer),
     except those for which one alternative is "preferred" (see below).

     When you select a difference, its state changes from default-A or
     default-B to plain A or B.  Thus, the selected difference never has
     state default-A or default-B, and these states are never displayed
     in the mode line.

     The command `d a' chooses default-A as the default state, and `d
     b' chooses default-B.  This chosen default applies to all
     differences which you haven't selected and for which no
     alternative is preferred. If you are moving through the merge
     sequentially, the differences you haven't selected are those
     following the selected one.  Thus, while moving sequentially, you
     can effectively make the A version the default for some sections
     of the merge buffer and the B version the default for others by
     using `d a' and `d b' at the end of each section.

prefer-A
prefer-B
     The difference is showing the A or B state because it is
     "preferred".  This means that you haven't made an explicit choice,
     but one alternative seems likely to be right because the other
     alternative agrees with the common ancestor.  Thus, where the A
     buffer agrees with the common ancestor, the B version is
     preferred, because chances are it is the one that was actually
     changed.

     These two states are displayed in the mode line as `A*' and `B*'.

combined
     The difference is showing a combination of the A and B states, as a
     result of the `x c' or `x C' commands.

     Once a difference is in this state, the `a' and `b' commands don't
     do anything to it unless you give them a prefix argument.

     The mode line displays this state as `comb'.


File: emacs,  Node: Merge Commands,  Next: Exiting Emerge,  Prev: State of Difference,  Up: Emerge

Merge Commands
--------------

   Here are the Merge commands for Fast mode; in Edit mode, precede
these with `C-c' and turn all the letters into control characters.

`p'
     Select the previous difference.

`n'
     Select the next difference.

`a'
     Choose the A version of this difference.

`b'
     Choose the B version of this difference.

`j'
     Select a particular difference; specify the sequence number of that
     difference as a prefix argument.

`M-x emerge-select-difference'
     Select the run of differences containing the current location. 
     You can use this command in the merge buffer or in the A or B
     buffer.

`q'
     Quit--finish the merge.  With an argument, abort the merge.

`f'
     Go into fast mode.

`e'
     Go into edit mode.

`l'
     Recenter (like `C-l') all three windows.

`-'
     Specify part of a prefix numeric argument.

`DIGIT'
     Also specify part of a prefix numeric argument.

`d a'
     Choose the A version as the default from here down in the merge
     buffer.

`d b'
     Choose the B version as the default from here down in the merge
     buffer.

`c a'
     Copy the A version of this difference into the kill ring.

`c b'
     Copy the B version of this difference into the kill ring.

`i a'
     Insert the A version of this difference at the point.

`i b'
     Insert the B version of this difference at the point.

`m'
     Put the point and mark around the difference region.

`^'
     Scroll all three windows down (like `M-v').

`v'
     Scroll all three windows up (like `C-v').

`<'
     Scroll all three windows left (like `C-x <').

`>'
     Scroll all three windows right (like `C-x >').

`|'
     Reset horizontal scroll on all three windows.

`x 1'
     Shrink the merge window to one line.  (Use `C-u l' to restore it
     to full size.)

`x c'
     Combine the two versions of this difference.

`x f'
     Show the files/buffers Emerge is operating on in Help window. (Use
     `C-u l' to restore windows.)

`x j'
     Join this difference with the following one. (`C-u x j' joins this
     difference with the previous one.)

`x s'
     Split this difference into two differences.  Before you use this
     command, position point in each of the three buffers to the place
     where you want to split the difference.

`x t'
     Trim identical lines off top and bottom of the difference. Such
     lines occur when the A and B versions are identical but differ
     from the ancestor version.


File: emacs,  Node: Exiting Emerge,  Next: Combining in Emerge,  Prev: Merge Commands,  Up: Emerge

Exiting Emerge
--------------

   The `q' (`emerge-quit') command finishes the merge, storing the
results into the output file.  It restores the A and B buffers to their
proper contents, or kills them if they were created by Emerge.  It also
disables the Emerge commands in the merge buffer, since executing them
later could damage the contents of the various buffers.

   `C-u q' aborts the merge.  Aborting means that Emerge does not write
the output file.

   If Emerge was called from another Lisp program, then its return value
is `t' or `nil' to indicate success or failure.


File: emacs,  Node: Combining in Emerge,  Next: Fine Points of Emerge,  Prev: Exiting Emerge,  Up: Emerge

Combining the Two Versions
--------------------------

   Sometimes you want to keep *both* alternatives for a particular
locus.  To do this, use `x c', which edits the merge buffer like this:

     #ifdef NEW
     VERSION FROM A FILE
     #else /* NEW */
     VERSION FROM B FILE
     #endif /* NEW */

   While this example shows C preprocessor conditionals delimiting the
two alternative versions, you can specify the strings you want by
setting the variable `emerge-combine-template' to a list of three
strings. The default setting, which produces the results shown above,
looks like this:

     ("#ifdef NEW\n"
      "#else /* NEW */\n"
      "#endif /* NEW */\n")


File: emacs,  Node: Fine Points of Emerge,  Prev: Combining in Emerge,  Up: Emerge

Fine Points of Emerge
---------------------

   You can have any number of merges going at once--just don't use any
one buffer as input to more than one merge at once, since that will
cause the read-only/modified/auto-save status save-and-restore to screw
up.

   Starting Emerge can take a long time because it needs to compare the
files.  Emacs can't do anything else until `diff' finishes.  Perhaps in
the future someone will change Emerge to do the comparison in the
background when the input files are large--then you could keep on doing
other things with Emacs until Emerge gets ready to accept commands.

   After the merge has been set up, Emerge runs the hooks in
`emerge-startup-hook'.

   During the merge, you musn't try to edit the A and B buffers
yourself. Emerge modifies them temporarily, but ultimately puts them
back the way they were.


File: emacs,  Node: Debuggers,  Next: Other New Modes,  Prev: Emerge,  Up: Version 19

Running Debuggers Under Emacs
=============================

   The GUD (Grand Unified Debugger) library provides an interface to
various symbolic debuggers from within Emacs.  We recommend the
debugger GDB, which is free software, but you can also run DBX or SDB
if you have them.

* Menu:

* Starting GUD::	How to start a debugger subprocess.
* Debugger Operation::	Connection between the debugger and source buffers.
* Commands of GUD::	Keybindings for common commands.
* GUD Customization::	Defining your own commands for GUD.


File: emacs,  Node: Starting GUD,  Next: Debugger Operation,  Up: Debuggers

Starting GUD
------------

   There are three commands for starting a debugger.  Each corresponds
to a particular debugger program.

`M-x gdb RET FILE RET'
`M-x dbx RET FILE RET'
     Run GDB or DBX in a subprocess of Emacs.  Both of these commands
     select the buffer used for input and output to the debugger.

`M-x sdb RET FILE RET'
     Run SDB in a subprocess of Emacs.  SDB's messages do not mention
     file names, so the Emacs interface to SDB depends on having a tags
     table (*note Tags::.) to find which file each function is in.  If
     you have not visited a tags table or the tags table doesn't list
     one of the functions, you get a message saying `The sdb support
     requires a valid tags table to work'.  If this happens, generate a
     valid tags table in the working directory and try again.

   You can only run one debugger process at a time.


File: emacs,  Node: Debugger Operation,  Next: Commands of GUD,  Prev: Starting GUD,  Up: Debuggers

Debugger Operation
------------------

   When you run a debugger with GUD, the debugger displays source files
via Emacs--Emacs finds the source file and moves point to the line
where the program is executing.  An arrow (`=>') indicates the current
execution line, and it stays put even if you move the cursor.

   You can start editing the file at any time.  The arrow is not part of
the file's text; it appears only on the screen.  If you do modify a
source file, keep in mind that inserting or deleting lines will throw
off the arrow's positioning; GUD has no way of figuring out which line
corresponded before your changes to the line number in a debugger
message.  Also, you'll typically have to recompile and restart the
program for your changes to be reflected in the debugger's tables.

   If you wish, you can control your debugger process entirely through
the debugger buffer, which uses a variant of Shell mode.  All the usual
commands for your debugger are available, and you can use the Shell mode
history commands to repeat them.


File: emacs,  Node: Commands of GUD,  Next: GUD Customization,  Prev: Debugger Operation,  Up: Debuggers

Commands of GUD
---------------

   GUD provides a command available in all buffers for setting
breakpoints.  This command is defined globally because you need to use
it in the source files' buffers.

`C-x SPC'
     Set a breakpoint on the line that point is on.

   The debugger buffer has a number of keybindings for invoking common
debugging commands quickly:

`C-c C-l'
     Display in another window the last line referred to in the GUD
     buffer (that is, the line indicated in the last location message).
     This runs the command `gud-refresh'.

`C-c C-s'
     Execute a single line of code (`gud-step').  If the code contains
     a function call, execution stops after entering the called
     function.

`C-c C-n'
     Execute a single line of code, stepping across entire function
     calls at full speed (`gud-next').

`C-c C-i'
     Execute a single machine instruction (`gud-stepi').

`C-c C-c'
     Continue execution until the next breakpoint, or other event that
     would normally stop the program (`gud-cont').

   The above commands are common to all supported debuggers.  If you are
using GDB or (some versions of) DBX, these additional commands are
available:

`C-c <'
     Select the next enclosing stack frame (`gud-up').  This is
     equivalent to the `up' command.

`C-c >'
     Select the next inner stack frame (`gud-down').  This is
     equivalent to the `down' command.

   If you are using GDB, two additional keybindings are available:

`C-c C-f'
     Run the program until the selected stack frame returns (or until it
     stops for some other reason).

`TAB'
     Complete the symbol in the buffer before point, using the set of
     all symbols known to GDB.

   These commands interpret a prefix argument as a repeat count, when
that makes sense.

   After each command that changes the program counter, GUD displays the
new current source line, and updates the location of the arrow.


File: emacs,  Node: GUD Customization,  Prev: Commands of GUD,  Up: Debuggers

GUD Customization
-----------------

   On startup, GUD executes one of the following hooks:
`gdb-mode-hook', if you are using GDB; `dbx-mode-hook', if you are
using DBX; and `sdb-mode-hook', if you are using SDB.  You can use
these hooks to define custom keybindings for the debugger interaction
buffer.

   Here is a convenient way to define a command that sends a particular
command string to the debugger, and set up a key binding for it in the
debugger interaction buffer:

     (gud-def FUNCTION CMDSTRING BINDING DOCSTRING)

   This defines a command named FUNCTION which sends CMDSTRING to the
debugger process, with documentation string DOCSTRING, and binds it to
BINDING in the debugger buffer's mode.  (If BINDING is `nil', this
defines the command but does not make a binding for it; you can make a
binding explicitly, perhaps using one of the above hooks.)

   Commands defined with `gud-def' handle prefix arguments by passing
them to the debugger, appended to end of CMDSTRING with a space in
between.  (This use of prefix arguments works with GDB and DBX, but not
with SDB.)

   You can also set up commands that you can send to the debugger while
in another buffer, such as a source file.  Set the variable
`gud-commands' to a list of strings containing debugger commands you
might want to send.

`C-x &'
     Send a custom command to the debugger process
     (`send-gud-command').  Normally, send the CAR of the
     `gud-commands' list; a prefix argument specifies which element of
     that list to use (counting from 0).

     If the string contains `%s', `C-x &' substitutes a numeric value
     found in the buffer at or near point.  It looks for decimal,
     octal, or hexadecimal numbers, with `0x' allowed.  This lets you
     define commands to chase pointers whose numeric values have been
     displayed.


File: emacs,  Node: Other New Modes,  Next: Key Sequence Changes,  Prev: Debuggers,  Up: Version 19

Other New Modes
===============

   There is now a Perl mode for editing Perl programs and an Icon mode
for editing Icon programs.

   C++ mode is like C mode, except that it understands C++ comment
syntax and certain other differences between C and C++.  It also has a
command `fill-c++-comment' which fills a paragraph made of comment
lines. The command `comment-region' is useful in C++ mode for commenting
out several consecutive lines, or removing the commenting out of such
lines.

   WordStar emulation is available--type `M-x wordstar-mode'. For more
information, type `C-h f wordstar-mode RET'.

   The command `C-o' in Buffer Menu mode now displays the current
line's buffer in another window but does not select it.  This is like
the existing command `o' which selects the current line's buffer in
another window.

* Menu:

* Asm Mode::		A major mode for editing assembler files.
* Edebug Mode::		A new Lisp debugger.
* Editing Binary Files::Hexl mode lets you edit a binary file as numbers.


File: emacs,  Node: Asm Mode,  Next: Edebug Mode,  Up: Other New Modes

Asm Mode
--------

   Asm mode is a new major mode for editing files of assembler code. It
defines these commands:

`TAB'
     `tab-to-tab-stop'.

`LFD'
     Insert a newline and then indent using `tab-to-tab-stop'.

`:'
     Insert a colon and then remove the indentation from before the
     label preceding colon.  Then do `tab-to-tab-stop'.

`;'
     Insert or align a comment.


File: emacs,  Node: Edebug Mode,  Next: Editing Binary Files,  Prev: Asm Mode,  Up: Other New Modes

Edebug Mode
-----------

   Edebug is a new source-level debugger for Emacs Lisp programs.

   To use Edebug, use the command `M-x edebug-defun' to "evaluate" a
function definition in an Emacs Lisp file.  We put "evaluate" in
quotation marks because it doesn't just evaluate the function, it also
inserts additional information to support source-level debugging.

   You must also do this:

     (setq debugger 'edebug-debug)

to cause errors and single-stepping to use Edebug instead of the usual
Emacs Lisp debugger.

   For more information, see `The Emacs Extensions Manual', which
should be included in the Emacs 19 distribution.


File: emacs,  Node: Editing Binary Files,  Prev: Edebug Mode,  Up: Other New Modes

Editing Binary Files
--------------------

   There is a new major mode for editing binary files: Hexl mode.  To
use it, use `M-x hexl-find-file' instead of `C-x C-f' to visit the
file.  This command converts the file's contents to hexadecimal and lets
you edit the translation.  When you save the file, it is converted
automatically back to binary.

   You can also use `M-x hexl-mode' to translate an existing buffer
into hex.  This is useful if you visit a file normally and discover it
is a binary file.

   Hexl mode has a few other commands:

`C-M-d'
     Insert a byte with a code typed in decimal.

`C-M-o'
     Insert a byte with a code typed in octal.

`C-M-x'
     Insert a byte with a code typed in hex.

`C-x ['
     Move to the beginning of a 1k-byte "page".

`C-x ]'
     Move to the end of a 1k-byte "page".

`M-g'
     Move to an address specified in hex.

`M-j'
     Move to an address specified in decimal.

`C-c C-c'
     Leave Hexl mode, going back to the major mode this buffer had
     before you invoked `hexl-mode'.


File: emacs,  Node: Key Sequence Changes,  Next: Hook Changes,  Prev: Other New Modes,  Up: Version 19

Changes in Key Sequences
========================

   In Emacs 18, a key sequence was a sequence of characters, which
represented keyboard input.

   In Emacs 19, you can still use a sequence of characters as a key
sequence, but you aren't limited to characters.  You can also use Lisp
symbols which represent terminal function keys or mouse buttons.  If the
function key has a word as its label, then that word is also the name of
the symbol which represents the function key.  Other function keys are
assigned Lisp names as follows:

`kp-add', `kp-decimal', `kp-divide', ...
     Keypad keys (to the right of the regular keyboard), with names or
     punctuation

`kp-0', `kp-1', ...
     Keypad keys with digits

`kp-f1', `kp-f2', `kp-f3', `kp-f4'
     Keypad PF keys

`left', `up', `right', `down'
     Cursor arrow keys

   A key sequence which contains non-characters must be a vector rather
than a string.

   Thus, to bind function key `f1' to `rmail', write the following:

     (global-set-key [f1] 'rmail)

(To find the name of a key, type `C-h k' and then the key.)

   To bind the right-arrow key to the command `forward-char', you can
use this expression:

     (global-set-key [right] 'forward-char)

using the Lisp syntax for a vector containing the symbol `right'.

   And this is how to make `C-x RIGHTARROW' move forward a page:

     (global-set-key [?\C-x right] 'forward-page)

where `?\C-x' is the Lisp syntax for an integer whose value is the code
for the character `C-x'.

   You can use modifier keys such as CTRL, META and SHIFT with function
keys.  To represent these modifiers, prepend the strings `C-', `M-' and
`S-' to the symbol name.  Thus, here is how to make `M-RIGHTARROW' move
forward a word:

     (global-set-key [M-right] 'forward-word)

   Emacs uses symbols to designate mouse buttons, too. The ordinary
mouse events in Emacs are "click" events; these happen when you press a
button and release it without moving the mouse. You can also get "drag"
events, when you move the mouse while holding the button down.  Drag
events happen when you finally let go of the button.

   The symbols for basic click events are `mouse-1' for the leftmost
button, `mouse-2' for the next, and so on.  Here is how you can
redefine the second mouse button to split the current window:

     (global-set-key [mouse-2] 'split-window-vertically)

   The symbols for drag events are similar, but have the prefix `drag-'
before the word `mouse'.  For example, dragging the left button
generates a `drag-mouse-1' event.

   You can also request events when the mouse button is pressed down.
These events start with `down-' instead of `drag-'.  Such events are
generated only if they have key bindings.  When you get a button-down
event, a corresponding click or drag event will always follow.

   The symbols for mouse events also indicate the status of the modifier
keys, with the usual prefixes `C-', `M-' and `S-'. These always follow
`drag-' or `down-'.

   When mouse events occur in special parts of a frame or window, such
as a mode line or a scroll bar, the event symbol shows nothing special.
 The information about the special part is implicit in other data (the
screen location of the event).  But `read-key-sequence' figures out this
aspect of the event, and encodes it with make-believe prefix keys, all
of which are symbols: `mode-line', `vertical-line',
`horizontal-scrollbar' and `vertical-scrollbar'.  Thus, to define the
command for clicking the left button in a mode line, you could use this
key sequence:

     [mode-line mouse-1]

   You are not limited to defining individual function keys or mouse
buttons; these can appear anywhere in a key sequence, just as characters
can.  You can even mix together all three kinds of inputs in one key
sequence--but mixing mouse buttons with keyboard inputs is probably not
convenient for actual use.


File: emacs,  Node: Hook Changes,  Prev: Key Sequence Changes,  Up: Version 19

Changes Regarding Hooks
=======================

   A "hook variable" is a variable that exists so that you can store in
it functions for Emacs to call on certain occasions.  (The functions
that you put in hook variables are called "hook functions".)  Emacs 19
has a new convention for naming hook variables that indicates more
reliably how to use them.

   All the variables whose names end in `-hook' are "normal hooks";
their values are lists of functions to be called with no arguments. 
You can use `add-hook' (see below) to install hook functions in these
hooks.  We have made all Emacs hooks into normal hooks except when
there is some reason this won't work.

   A few hook-like variables are "abnormal"--they don't use the normal
convention.  This is either because the user-supplied functions receive
arguments, or because their return values matter.  These variables have
names that end in `-function' (if the value is a single function) or
`-functions' (if the value is a list of functions).

   Thus, you can always tell from the variable's name precisely how to
install a new hook function in the variable.  If the name indicates a
normal hook, then you also know how to write your hook function.

   To add a hook function to a normal hook, use `add-hook'.  It takes
care of adding a new hook function to any functions already installed in
a given hook.  It takes two arguments, the hook symbol and the function
to add.  For example,

     (add-hook 'text-mode-hook 'my-text-hook-function)

is how to arrange to call `my-text-hook-function' when entering Text
mode or related modes. Two new hooks are worth noting here.  Expansion
of an abbrev first runs the hook `pre-abbrev-expand-hook'.
`kill-buffer-hook' now runs whenever a buffer is killed.