2 @c This is part of the GNU Emacs Lisp Reference Manual.
3 @c Copyright (C) 1990, 1991, 1992, 1993, 1995, 1998 Free Software Foundation, Inc.
4 @c See the file elisp.texi for copying conditions.
5 @setfilename ../info/tips
6 @node Tips, GNU Emacs Internals, System Interface, Top
7 @appendix Tips and Conventions
9 @cindex standards of coding style
10 @cindex coding standards
12 This chapter describes no additional features of Emacs Lisp. Instead
13 it gives advice on making effective use of the features described in the
14 previous chapters, and describes conventions Emacs Lisp programmers
18 * Coding Conventions:: Conventions for clean and robust programs.
19 * Compilation Tips:: Making compiled code run fast.
20 * Documentation Tips:: Writing readable documentation strings.
21 * Comment Tips:: Conventions for writing comments.
22 * Library Headers:: Standard headers for library packages.
25 @node Coding Conventions
26 @section Emacs Lisp Coding Conventions
28 Here are conventions that you should follow when writing Emacs Lisp
29 code intended for widespread use:
33 Since all global variables share the same name space, and all functions
34 share another name space, you should choose a short word to distinguish
35 your program from other Lisp programs. Then take care to begin the
36 names of all global variables, constants, and functions with the chosen
37 prefix. This helps avoid name conflicts.
39 This recommendation applies even to names for traditional Lisp
40 primitives that are not primitives in Emacs Lisp---even to
41 @code{copy-list}. Believe it or not, there is more than one plausible
42 way to define @code{copy-list}. Play it safe; append your name prefix
43 to produce a name like @code{foo-copy-list} or @code{mylib-copy-list}
46 If you write a function that you think ought to be added to Emacs under
47 a certain name, such as @code{twiddle-files}, don't call it by that name
48 in your program. Call it @code{mylib-twiddle-files} in your program,
49 and send mail to @samp{bug-gnu-emacs@@gnu.org} suggesting we add
50 it to Emacs. If and when we do, we can change the name easily enough.
52 If one prefix is insufficient, your package may use two or three
53 alternative common prefixes, so long as they make sense.
55 Separate the prefix from the rest of the symbol name with a hyphen,
56 @samp{-}. This will be consistent with Emacs itself and with most Emacs
60 It is often useful to put a call to @code{provide} in each separate
61 library program, at least if there is more than one entry point to the
65 If a file requires certain other library programs to be loaded
66 beforehand, then the comments at the beginning of the file should say
67 so. Also, use @code{require} to make sure they are loaded.
70 If one file @var{foo} uses a macro defined in another file @var{bar},
71 @var{foo} should contain this expression before the first use of the
75 (eval-when-compile (require '@var{bar}))
79 (And the library @var{bar} should contain @code{(provide '@var{bar})},
80 to make the @code{require} work.) This will cause @var{bar} to be
81 loaded when you byte-compile @var{foo}. Otherwise, you risk compiling
82 @var{foo} without the necessary macro loaded, and that would produce
83 compiled code that won't work right. @xref{Compiling Macros}.
85 Using @code{eval-when-compile} avoids loading @var{bar} when
86 the compiled version of @var{foo} is @emph{used}.
89 When defining a major mode, please follow the major mode
90 conventions. @xref{Major Mode Conventions}.
93 When defining a minor mode, please follow the minor mode
94 conventions. @xref{Minor Mode Conventions}.
97 If the purpose of a function is to tell you whether a certain condition
98 is true or false, give the function a name that ends in @samp{p}. If
99 the name is one word, add just @samp{p}; if the name is multiple words,
100 add @samp{-p}. Examples are @code{framep} and @code{frame-live-p}.
103 If a user option variable records a true-or-false condition, give it a
104 name that ends in @samp{-flag}.
107 @cindex reserved keys
108 @cindex keys, reserved
109 Please do not define @kbd{C-c @var{letter}} as a key in your major
110 modes. These sequences are reserved for users; they are the
111 @strong{only} sequences reserved for users, so do not block them.
113 Instead, define sequences consisting of @kbd{C-c} followed by a control
114 character, a digit, or certain punctuation characters. These sequences
115 are reserved for major modes.
117 Changing all the Emacs major modes to follow this convention was a lot
118 of work. Abandoning this convention would make that work go to waste,
119 and inconvenience users.
122 Sequences consisting of @kbd{C-c} followed by @kbd{@{}, @kbd{@}},
123 @kbd{<}, @kbd{>}, @kbd{:} or @kbd{;} are also reserved for major modes.
126 Sequences consisting of @kbd{C-c} followed by any other punctuation
127 character are allocated for minor modes. Using them in a major mode is
128 not absolutely prohibited, but if you do that, the major mode binding
129 may be shadowed from time to time by minor modes.
132 Function keys @key{F5} through @key{F9} without modifier keys are
133 reserved for users to define.
136 Do not bind @kbd{C-h} following any prefix character (including
137 @kbd{C-c}). If you don't bind @kbd{C-h}, it is automatically available
138 as a help character for listing the subcommands of the prefix character.
141 Do not bind a key sequence ending in @key{ESC} except following
142 another @key{ESC}. (That is, it is OK to bind a sequence ending in
143 @kbd{@key{ESC} @key{ESC}}.)
145 The reason for this rule is that a non-prefix binding for @key{ESC} in
146 any context prevents recognition of escape sequences as function keys in
150 Anything which acts like a temporary mode or state which the user can
151 enter and leave should define @kbd{@key{ESC} @key{ESC}} of
152 @kbd{@key{ESC} @key{ESC} @key{ESC}} as a way to escape.
154 For a state which accepts ordinary Emacs commands, or more generally any
155 kind of state in which @key{ESC} followed by a function key or arrow key
156 is potentially meaningful, then you must not define @kbd{@key{ESC}
157 @key{ESC}}, since that would preclude recognizing an escape sequence
158 after @key{ESC}. In these states, you should define @kbd{@key{ESC}
159 @key{ESC} @key{ESC}} as the way to escape. Otherwise, define
160 @kbd{@key{ESC} @key{ESC}} instead.
163 Applications should not bind mouse events based on button 1 with the
164 shift key held down. These events include @kbd{S-mouse-1},
165 @kbd{M-S-mouse-1}, @kbd{C-S-mouse-1}, and so on. They are reserved for
169 Special major modes used for read-only text should usually redefine
170 @kbd{mouse-2} and @key{RET} to trace some sort of reference in the text.
171 Modes such as Dired, Info, Compilation, and Occur redefine it in this
175 When a package provides a modification of ordinary Emacs behavior, it is
176 good to include a command to enable and disable the feature, Provide a
177 command named @code{@var{whatever}-mode} which turns the feature on or
178 off, and make it autoload (@pxref{Autoload}). Design the package so
179 that simply loading it has no visible effect---that should not enable
180 the feature. Users will request the feature by invoking the command.
183 It is a bad idea to define aliases for the Emacs primitives. Use the
184 standard names instead.
187 Redefining (or advising) an Emacs primitive is discouraged. It may do
188 the right thing for a particular program, but there is no telling what
189 other programs might break as a result.
192 If a file does replace any of the functions or library programs of
193 standard Emacs, prominent comments at the beginning of the file should
194 say which functions are replaced, and how the behavior of the
195 replacements differs from that of the originals.
198 Please keep the names of your Emacs Lisp source files to 13 characters
199 or less. This way, if the files are compiled, the compiled files' names
200 will be 14 characters or less, which is short enough to fit on all kinds
204 Don't use @code{next-line} or @code{previous-line} in programs; nearly
205 always, @code{forward-line} is more convenient as well as more
206 predictable and robust. @xref{Text Lines}.
209 Don't call functions that set the mark, unless setting the mark is one
210 of the intended features of your program. The mark is a user-level
211 feature, so it is incorrect to change the mark except to supply a value
212 for the user's benefit. @xref{The Mark}.
214 In particular, don't use any of these functions:
218 @code{beginning-of-buffer}, @code{end-of-buffer}
220 @code{replace-string}, @code{replace-regexp}
223 If you just want to move point, or replace a certain string, without any
224 of the other features intended for interactive users, you can replace
225 these functions with one or two lines of simple Lisp code.
228 Use lists rather than vectors, except when there is a particular reason
229 to use a vector. Lisp has more facilities for manipulating lists than
230 for vectors, and working with lists is usually more convenient.
232 Vectors are advantageous for tables that are substantial in size and are
233 accessed in random order (not searched front to back), provided there is
234 no need to insert or delete elements (only lists allow that).
237 The recommended way to print a message in the echo area is with
238 the @code{message} function, not @code{princ}. @xref{The Echo Area}.
241 When you encounter an error condition, call the function @code{error}
242 (or @code{signal}). The function @code{error} does not return.
243 @xref{Signaling Errors}.
245 Do not use @code{message}, @code{throw}, @code{sleep-for},
246 or @code{beep} to report errors.
249 An error message should start with a capital letter but should not end
253 Many commands that take a long time to execute display a message that
254 says @samp{Operating...} when they start, and change it to
255 @samp{Operating...done} when they finish. Please keep the style of
256 these messages uniform: @emph{no} space around the ellipsis, and
257 @emph{no} period at the end.
260 Try to avoid using recursive edits. Instead, do what the Rmail @kbd{e}
261 command does: use a new local keymap that contains one command defined
262 to switch back to the old local keymap. Or do what the
263 @code{edit-options} command does: switch to another buffer and let the
264 user switch back at will. @xref{Recursive Editing}.
267 In some other systems there is a convention of choosing variable names
268 that begin and end with @samp{*}. We don't use that convention in Emacs
269 Lisp, so please don't use it in your programs. (Emacs uses such names
270 only for special-purpose buffers.) The users will find Emacs more
271 coherent if all libraries use the same conventions.
274 Try to avoid compiler warnings about undefined free variables, by adding
275 @code{defvar} definitions for these variables.
277 If you bind a variable in one function, and use it or set it in another
278 function, the compiler warns about the latter function unless the
279 variable has a definition. But often these variables have short names,
280 and it is not clean for Lisp packages to define such variable names.
281 Therefore, you should rename the variable to start with the name prefix
282 used for the other functions and variables in your package.
285 Indent each function with @kbd{C-M-q} (@code{indent-sexp}) using the
286 default indentation parameters.
289 Don't make a habit of putting close-parentheses on lines by themselves;
290 Lisp programmers find this disconcerting. Once in a while, when there
291 is a sequence of many consecutive close-parentheses, it may make sense
292 to split the sequence in one or two significant places.
295 Please put a copyright notice on the file if you give copies to anyone.
296 Use a message like this one:
299 ;; Copyright (C) @var{year} @var{name}
301 ;; This program is free software; you can redistribute it and/or
302 ;; modify it under the terms of the GNU General Public License as
303 ;; published by the Free Software Foundation; either version 2 of
304 ;; the License, or (at your option) any later version.
306 ;; This program is distributed in the hope that it will be
307 ;; useful, but WITHOUT ANY WARRANTY; without even the implied
308 ;; warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
309 ;; PURPOSE. See the GNU General Public License for more details.
311 ;; You should have received a copy of the GNU General Public
312 ;; License along with this program; if not, write to the Free
313 ;; Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
317 If you have signed papers to assign the copyright to the Foundation,
318 then use @samp{Free Software Foundation, Inc.} as @var{name}.
319 Otherwise, use your name.
322 @node Compilation Tips
323 @section Tips for Making Compiled Code Fast
324 @cindex execution speed
327 Here are ways of improving the execution speed of byte-compiled
333 @cindex timing programs
334 @cindex @file{profile.el}
335 @cindex @file{elp.el}
336 Profile your program with the @file{profile} library or the @file{elp}
337 library. See the files @file{profile.el} and @file{elp.el} for
341 Use iteration rather than recursion whenever possible.
342 Function calls are slow in Emacs Lisp even when a compiled function
343 is calling another compiled function.
346 Using the primitive list-searching functions @code{memq}, @code{member},
347 @code{assq}, or @code{assoc} is even faster than explicit iteration. It
348 can be worth rearranging a data structure so that one of these primitive
349 search functions can be used.
352 Certain built-in functions are handled specially in byte-compiled code,
353 avoiding the need for an ordinary function call. It is a good idea to
354 use these functions rather than alternatives. To see whether a function
355 is handled specially by the compiler, examine its @code{byte-compile}
356 property. If the property is non-@code{nil}, then the function is
359 For example, the following input will show you that @code{aref} is
360 compiled specially (@pxref{Array Functions}):
364 (get 'aref 'byte-compile)
365 @result{} byte-compile-two-args
370 If calling a small function accounts for a substantial part of your
371 program's running time, make the function inline. This eliminates
372 the function call overhead. Since making a function inline reduces
373 the flexibility of changing the program, don't do it unless it gives
374 a noticeable speedup in something slow enough that users care about
375 the speed. @xref{Inline Functions}.
378 @node Documentation Tips
379 @section Tips for Documentation Strings
381 @tindex checkdoc-minor-mode
382 @findex checkdoc-minor-mode
383 Here are some tips and conventions for the writing of documentation
384 strings. You can check many of these conventions by running the command
385 @kbd{M-x checkdoc-minor-mode}.
389 Every command, function, or variable intended for users to know about
390 should have a documentation string.
393 An internal variable or subroutine of a Lisp program might as well have
394 a documentation string. In earlier Emacs versions, you could save space
395 by using a comment instead of a documentation string, but that is no
399 The first line of the documentation string should consist of one or two
400 complete sentences that stand on their own as a summary. @kbd{M-x
401 apropos} displays just the first line, and if it doesn't stand on its
402 own, the result looks bad. In particular, start the first line with a
403 capital letter and end with a period.
405 The documentation string can have additional lines that expand on the
406 details of how to use the function or variable. The additional lines
407 should be made up of complete sentences also, but they may be filled if
411 For consistency, phrase the verb in the first sentence of a
412 function's documentation string as an infinitive with ``to'' omitted. For
413 instance, use ``Return the cons of A and B.'' in preference to ``Returns
414 the cons of A and B@.'' Usually it looks good to do likewise for the
415 rest of the first paragraph. Subsequent paragraphs usually look better
416 if they have proper subjects.
419 Write documentation strings in the active voice, not the passive, and in
420 the present tense, not the future. For instance, use ``Return a list
421 containing A and B.'' instead of ``A list containing A and B will be
425 Avoid using the word ``cause'' (or its equivalents) unnecessarily.
426 Instead of, ``Cause Emacs to display text in boldface,'' write just
427 ``Display text in boldface.''
430 Do not start or end a documentation string with whitespace.
433 Format the documentation string so that it fits in an Emacs window on an
434 80-column screen. It is a good idea for most lines to be no wider than
435 60 characters. The first line can be wider if necessary to fit the
436 information that ought to be there.
438 However, rather than simply filling the entire documentation string, you
439 can make it much more readable by choosing line breaks with care.
440 Use blank lines between topics if the documentation string is long.
443 @strong{Do not} indent subsequent lines of a documentation string so
444 that the text is lined up in the source code with the text of the first
445 line. This looks nice in the source code, but looks bizarre when users
446 view the documentation. Remember that the indentation before the
447 starting double-quote is not part of the string!
450 When the user tries to use a disabled command, Emacs displays just the
451 first paragraph of its documentation string---everything through the
452 first blank line. If you wish, you can choose which information to
453 include before the first blank line so as to make this display useful.
456 A variable's documentation string should start with @samp{*} if the
457 variable is one that users would often want to set interactively. If
458 the value is a long list, or a function, or if the variable would be set
459 only in init files, then don't start the documentation string with
460 @samp{*}. @xref{Defining Variables}.
463 The documentation string for a variable that is a yes-or-no flag should
464 start with words such as ``Non-nil means@dots{}'', to make it clear that
465 all non-@code{nil} values are equivalent and indicate explicitly what
466 @code{nil} and non-@code{nil} mean.
469 When a function's documentation string mentions the value of an argument
470 of the function, use the argument name in capital letters as if it were
471 a name for that value. Thus, the documentation string of the function
472 @code{/} refers to its second argument as @samp{DIVISOR}, because the
473 actual argument name is @code{divisor}.
475 Also use all caps for meta-syntactic variables, such as when you show
476 the decomposition of a list or vector into subunits, some of which may
481 When a documentation string refers to a Lisp symbol, write it as it
482 would be printed (which usually means in lower case), with single-quotes
483 around it. For example: @samp{`lambda'}. There are two exceptions:
484 write @code{t} and @code{nil} without single-quotes.
487 When a documentation string refers to a Lisp symbol, write it as it
488 would be printed (which usually means in lower case), with single-quotes
489 around it. For example: @samp{lambda}. There are two exceptions: write
490 t and nil without single-quotes. (In this manual, we use a different
491 convention, with single-quotes for all symbols.)
494 Help mode automatically creates a hyperlink when a documentation string
495 uses a symbol name inside single quotes, if the symbol has either a
496 function or a variable definition. You do not need to do anything
497 special to make use of this feature. However, when a symbol has both a
498 function definition and a variable definition, and you want to refer to
499 just one of them, you can specify which one by writing one of the words
500 @samp{variable}, @samp{option}, @samp{function}, or @samp{command},
501 immediately before the symbol name. (Case makes no difference in
502 recognizing these indicator words.) For example, if you write
505 This function sets the variable `buffer-file-name'.
509 then the hyperlink will refer only to the variable documentation of
510 @code{buffer-file-name}, and not to its function documentation.
512 If a symbol has a function definition and/or a variable definition, but
513 those are irrelevant to the use of the symbol that you are documenting,
514 you can write the word @samp{symbol} before the symbol name to prevent
515 making any hyperlink. For example,
518 If the argument KIND-OF-RESULT is the symbol `list',
519 this function returns a list of all the objects
520 that satisfy the criterion.
524 does not make a hyperlink to the documentation, irrelevant here, of the
525 function @code{list}.
528 Don't write key sequences directly in documentation strings. Instead,
529 use the @samp{\\[@dots{}]} construct to stand for them. For example,
530 instead of writing @samp{C-f}, write the construct
531 @samp{\\[forward-char]}. When Emacs displays the documentation string,
532 it substitutes whatever key is currently bound to @code{forward-char}.
533 (This is normally @samp{C-f}, but it may be some other character if the
534 user has moved key bindings.) @xref{Keys in Documentation}.
537 In documentation strings for a major mode, you will want to refer to the
538 key bindings of that mode's local map, rather than global ones.
539 Therefore, use the construct @samp{\\<@dots{}>} once in the
540 documentation string to specify which key map to use. Do this before
541 the first use of @samp{\\[@dots{}]}. The text inside the
542 @samp{\\<@dots{}>} should be the name of the variable containing the
543 local keymap for the major mode.
545 It is not practical to use @samp{\\[@dots{}]} very many times, because
546 display of the documentation string will become slow. So use this to
547 describe the most important commands in your major mode, and then use
548 @samp{\\@{@dots{}@}} to display the rest of the mode's keymap.
552 @section Tips on Writing Comments
554 We recommend these conventions for where to put comments and how to
559 Comments that start with a single semicolon, @samp{;}, should all be
560 aligned to the same column on the right of the source code. Such
561 comments usually explain how the code on the same line does its job. In
562 Lisp mode and related modes, the @kbd{M-;} (@code{indent-for-comment})
563 command automatically inserts such a @samp{;} in the right place, or
564 aligns such a comment if it is already present.
566 This and following examples are taken from the Emacs sources.
570 (setq base-version-list ; there was a base
571 (assoc (substring fn 0 start-vn) ; version to which
572 file-version-assoc-list)) ; this looks like
578 Comments that start with two semicolons, @samp{;;}, should be aligned to
579 the same level of indentation as the code. Such comments usually
580 describe the purpose of the following lines or the state of the program
581 at that point. For example:
585 (prog1 (setq auto-fill-function
589 (force-mode-line-update)))
593 Every function that has no documentation string (presumably one that is
594 used only internally within the package it belongs to), should have
595 instead a two-semicolon comment right before the function, explaining
596 what the function does and how to call it properly. Explain precisely
597 what each argument means and how the function interprets its possible
601 Comments that start with three semicolons, @samp{;;;}, should start at
602 the left margin. Such comments are used outside function definitions to
603 make general statements explaining the design principles of the program.
608 ;;; This Lisp code is run in Emacs
609 ;;; when it is to operate as a server
610 ;;; for other processes.
614 Another use for triple-semicolon comments is for commenting out lines
615 within a function. We use triple-semicolons for this precisely so that
616 they remain at the left margin.
620 ;;; This is no longer necessary.
621 ;;; (force-mode-line-update)
622 (message "Finished with %s" a))
626 Comments that start with four semicolons, @samp{;;;;}, should be aligned
627 to the left margin and are used for headings of major sections of a
628 program. For example:
636 The indentation commands of the Lisp modes in Emacs, such as @kbd{M-;}
637 (@code{indent-for-comment}) and @key{TAB} (@code{lisp-indent-line}),
638 automatically indent comments according to these conventions,
639 depending on the number of semicolons. @xref{Comments,,
640 Manipulating Comments, emacs, The GNU Emacs Manual}.
642 @node Library Headers
643 @section Conventional Headers for Emacs Libraries
644 @cindex header comments
645 @cindex library header comments
647 Emacs has conventions for using special comments in Lisp libraries
648 to divide them into sections and give information such as who wrote
649 them. This section explains these conventions. First, an example:
653 ;;; lisp-mnt.el --- minor mode for Emacs Lisp maintainers
655 ;; Copyright (C) 1992 Free Software Foundation, Inc.
658 ;; Author: Eric S. Raymond <esr@@snark.thyrsus.com>
659 ;; Maintainer: Eric S. Raymond <esr@@snark.thyrsus.com>
660 ;; Created: 14 Jul 1992
665 ;; This file is part of GNU Emacs.
667 ;; Free Software Foundation, Inc., 59 Temple Place - Suite 330,
668 ;; Boston, MA 02111-1307, USA.
672 The very first line should have this format:
675 ;;; @var{filename} --- @var{description}
679 The description should be complete in one line.
681 After the copyright notice come several @dfn{header comment} lines,
682 each beginning with @samp{;; @var{header-name}:}. Here is a table of
683 the conventional possibilities for @var{header-name}:
687 This line states the name and net address of at least the principal
688 author of the library.
690 If there are multiple authors, you can list them on continuation lines
691 led by @code{;;} and a tab character, like this:
695 ;; Author: Ashwin Ram <Ram-Ashwin@@cs.yale.edu>
696 ;; Dave Sill <de5@@ornl.gov>
697 ;; Dave Brennan <brennan@@hal.com>
698 ;; Eric Raymond <esr@@snark.thyrsus.com>
703 This line should contain a single name/address as in the Author line, or
704 an address only, or the string @samp{FSF}. If there is no maintainer
705 line, the person(s) in the Author field are presumed to be the
706 maintainers. The example above is mildly bogus because the maintainer
709 The idea behind the @samp{Author} and @samp{Maintainer} lines is to make
710 possible a Lisp function to ``send mail to the maintainer'' without
711 having to mine the name out by hand.
713 Be sure to surround the network address with @samp{<@dots{}>} if
714 you include the person's full name as well as the network address.
717 This optional line gives the original creation date of the
718 file. For historical interest only.
721 If you wish to record version numbers for the individual Lisp program, put
725 In this header line, place the name of the person who adapted the
726 library for installation (to make it fit the style conventions, for
730 This line lists keywords for the @code{finder-by-keyword} help command.
731 Please use that command to see a list of the meaningful keywords.
733 This field is important; it's how people will find your package when
734 they're looking for things by topic area. To separate the keywords, you
735 can use spaces, commas, or both.
738 Just about every Lisp library ought to have the @samp{Author} and
739 @samp{Keywords} header comment lines. Use the others if they are
740 appropriate. You can also put in header lines with other header
741 names---they have no standard meanings, so they can't do any harm.
743 We use additional stylized comments to subdivide the contents of the
744 library file. Here is a table of them:
747 @item ;;; Commentary:
748 This begins introductory comments that explain how the library works.
749 It should come right after the copying permissions, terminated by a
750 @samp{Change Log}, @samp{History} or @samp{Code} comment line. This
751 text is used by the Finder package, so it should make sense in that
754 @item ;;; Documentation
755 This has been used in some files in place of @samp{;;; Commentary:},
756 but @samp{;;; Commentary:} is preferred.
758 @item ;;; Change Log:
759 This begins change log information stored in the library file (if you
760 store the change history there). For most of the Lisp
761 files distributed with Emacs, the change history is kept in the file
762 @file{ChangeLog} and not in the source file at all; these files do
763 not have a @samp{;;; Change Log:} line.
766 This begins the actual code of the program.
768 @item ;;; @var{filename} ends here
769 This is the @dfn{footer line}; it appears at the very end of the file.
770 Its purpose is to enable people to detect truncated versions of the file
771 from the lack of a footer line.