[ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

# 9. Marking Words and Phrases

In Texinfo, you can mark words and phrases in a variety of ways. The Texinfo formatters use this information to determine how to highlight the text. You can specify, for example, whether a word or phrase is a defining occurrence, a metasyntactic variable, or a symbol used in a program. Also, you can emphasize text, in several different ways.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

## 9.1 Indicating Definitions, Commands, etc.

Texinfo has commands for indicating just what kind of object a piece of text refers to. For example, metasyntactic variables are marked by `@var`, and code by `@code`. Since the pieces of text are labelled by commands that tell what kind of object they are, it is easy to change the way the Texinfo formatters prepare such text. (Texinfo is an intentional formatting language rather than a typesetting formatting language.)

For example, in a printed manual, code is usually illustrated in a typewriter font; `@code` tells TeX to typeset this text in this font. But it would be easy to change the way TeX highlights code to use another font, and this change would not affect how keystroke examples are highlighted. If straight typesetting commands were used in the body of the file and you wanted to make a change, you would need to check every single occurrence to make sure that you were changing code and not something else that should not be changed.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.1 Highlighting Commands are Useful

The highlighting commands can be used to extract useful information from the file, such as lists of functions or file names. It is possible, for example, to write a program in XEmacs Lisp (or a keyboard macro) to insert an index entry after every paragraph that contains words or phrases marked by a specified command. You could do this to construct an index of functions if you had not already made the entries.

The commands serve a variety of purposes:

`@code{sample-code}`

Indicate text that is a literal example of a piece of a program. See section `@code`.

`@kbd{keyboard-characters}`

Indicate keyboard input. See section `@kbd`.

`@key{key-name}`

Indicate the conventional name for a key on a keyboard. See section `@key`.

`@samp{text}`

Indicate text that is a literal example of a sequence of characters. See section `@samp`.

`@verb{text}`

Write a verbatim sequence of characters. See section `@verb`.

`@var{metasyntactic-variable}`

Indicate a metasyntactic variable. See section `@var`.

`@env{environment-variable}`

Indicate an environment variable. See section `@env`.

`@file{file-name}`

Indicate the name of a file. See section `@file`.

`@command{command-name}`

Indicate the name of a command. See section `@command`.

`@option{option}`

Indicate a command-line option. See section `@option`.

`@dfn{term}`

Indicate the introductory or defining use of a term. See section `@dfn`.

`@cite{reference}`

Indicate the name of a book. See section `@cite`.

`@abbr{abbreviation}`

Indicate an abbreviation, such as ‘Comput.’.

`@acronym{acronym}`

Indicate an acronym. See section `@acronym`.

`@indicateurl{uniform-resource-locator}`

Indicate an example (that is, nonfunctional) uniform resource locator. See section `@indicateurl`. (Use `@url` (see section `@url`) for live url’s.)

`@email{email-address[, displayed-text]}`

Indicate an electronic mail address. See section `@email`.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.2 `@code`{sample-code}

Use the `@code` command to indicate text that is a piece of a program and which consists of entire syntactic tokens. Enclose the text in braces.

Thus, you should use `@code` for an expression in a program, for the name of a variable or function used in a program, or for a keyword in a programming language.

Use `@code` for command names in languages that resemble programming languages, such as Texinfo. For example, `@code` and `@samp` are produced by writing ‘@code{@@code}’ and ‘@code{@@samp}’ in the Texinfo source, respectively.

It is incorrect to alter the case of a word inside an `@code` command when it appears at the beginning of a sentence. Most computer languages are case sensitive. In C, for example, `Printf` is different from the identifier `printf`, and most likely is a misspelling of it. Even in languages which are not case sensitive, it is confusing to a human reader to see identifiers spelled in different ways. Pick one spelling and always use that. If you do not want to start a sentence with a command name written all in lower case, you should rearrange the sentence.

In the printed manual, `@code` causes TeX to typeset the argument in a typewriter face. In the Info file, it causes the Info formatting commands to use single quotation marks around the text. For example,

 ```The function returns @code{nil}. ```

produces this:

The function returns `nil`.

Here are some cases for which it is preferable not to use `@code`:

• For shell command names such as `ls` (use `@command`).
• For shell options such as ‘-c’ when such options stand alone (use `@option`).
• Also, an entire shell command often looks better if written using `@samp` rather than `@code`. In this case, the rule is to choose the more pleasing format.
• For environment variable such as `TEXINPUTS` (use `@env`).
• For a string of characters shorter than a syntactic token. For example, if you are writing about ‘goto-ch’, which is just a part of the name for the `goto-char` XEmacs Lisp function, you should use `@samp`.
• In general, when writing about the characters used in a token; for example, do not use `@code` when you are explaining what letters or printable symbols can be used in the names of functions. (Use `@samp`.) Also, you should not use `@code` to mark text that is considered input to programs unless the input is written in a language that is like a programming language. For example, you should not use `@code` for the keystroke commands of XEmacs (use `@kbd` instead) although you may use `@code` for the names of the XEmacs Lisp functions that the keystroke commands invoke.

Since `@command`, `@option`, and `@env` were introduced relatively recently, it is acceptable to use `@code` or `@samp` for command names, options, and environment variables. The new commands allow you to express the markup more precisely, but there is no real harm in using the older commands, and of course the long-standing manuals do so.

Ordinarily, TeX will consider breaking lines at ‘-’ and ‘_’ characters within `@code` and related commands. This can be controlled with `@allowcodebreaks` (see section `@allowcodebreaks`).

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.3 `@kbd`{keyboard-characters}

Use the `@kbd` command for characters of input to be typed by users. For example, to refer to the characters M-a, write:

 ```@kbd{M-a} ```

and to refer to the characters M-x shell, write:

 ```@kbd{M-x shell} ```

By default, the `@kbd` command produces a different font (slanted typewriter instead of normal typewriter) in the printed manual, so users can distinguish the characters that they are supposed to type from those that the computer outputs.

In Info output, `@kbd` is usually the same as `@code`, producing ‘quotes’ around its argument. However, in typewriter-like contexts such as the `@example` environment (see section `@example`: Example Text) and `@code` command itself, the quotes are omitted, since Info format cannot use distinguishing fonts.

Since the usage of `@kbd` varies from manual to manual, you can control the font switching with the `@kbdinputstyle` command. This command has no effect on Info output. Write this command at the beginning of a line with a single word as an argument, one of the following:

code

Always use the same font for `@kbd` as `@code`.

example

Use the distinguishing font for `@kbd` only in `@example` and similar environments.

distinct

(the default) Always use the distinguishing font for `@kbd`.

You can embed another @-command inside the braces of an `@kbd` command. Here, for example, is the way to describe a command that would be described more verbosely as “press the ‘r’ key and then press the <RETURN> key”:

 ```@kbd{r @key{RET}} ```

This produces: r <RET>. (The present manual uses the default for `@kbdinputstyle`.)

You also use the `@kbd` command if you are spelling out the letters you type; for example:

 ```To give the @code{logout} command, type the characters @kbd{l o g o u t @key{RET}}. ```

This produces:

To give the `logout` command, type the characters l o g o u t <RET>.

(Also, this example shows that you can add spaces for clarity. If you explicitly want to mention a space character as one of the characters of input, write @key{SPC} for it.)

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.4 `@key`{key-name}

Use the `@key` command for the conventional name for a key on a keyboard, as in:

 ```@key{RET} ```

You can use the `@key` command within the argument of an `@kbd` command when the sequence of characters to be typed includes one or more keys that are described by name.

For example, to produce C-x <ESC> and M-<TAB> you would type:

 ```@kbd{C-x @key{ESC}} @kbd{M-@key{TAB}} ```

Here is a list of the recommended names for keys:

SPC

Space

RET

Return

LFD

Linefeed (however, since most keyboards nowadays do not have a Linefeed key, it might be better to call this character C-j)

TAB

Tab

BS

Backspace

ESC

Escape

DELETE

Delete

SHIFT

Shift

CTRL

Control

META

Meta

There are subtleties to handling words like ‘meta’ or ‘ctrl’ that are names of modifier keys. When mentioning a character in which the modifier key is used, such as Meta-a, use the `@kbd` command alone; do not use the `@key` command; but when you are referring to the modifier key in isolation, use the `@key` command. For example, write ‘@kbd{Meta-a}’ to produce Meta-a and ‘@key{META}’ to produce <META>.

As a convention in GNU manuals, `@key` should not be used in index entries.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.5 `@samp`{text}

Use the `@samp` command to indicate text that is a literal example or ‘sample’ of a sequence of characters in a file, string, pattern, etc. Enclose the text in braces. The argument appears within single quotation marks in both the Info file and the printed manual; in addition, it is printed in a fixed-width font.

 ```To match @samp{foo} at the end of the line, use the regexp @samp{foo\$}. ```

produces

To match ‘foo’ at the end of the line, use the regexp ‘foo\$’.

Any time you are referring to single characters, you should use `@samp` unless `@kbd` or `@key` is more appropriate. Also, you may use `@samp` for entire statements in C and for entire shell commands—in this case, `@samp` often looks better than `@code`. Basically, `@samp` is a catchall for whatever is not covered by `@code`, `@kbd`, or `@key`.

Only include punctuation marks within braces if they are part of the string you are specifying. Write punctuation marks outside the braces if those punctuation marks are part of the English text that surrounds the string. In the following sentence, for example, the commas and period are outside of the braces:

 ```In English, the vowels are @samp{a}, @samp{e}, @samp{i}, @samp{o}, @samp{u}, and sometimes @samp{y}. ```

This produces:

In English, the vowels are ‘a’, ‘e’, ‘i’, ‘o’, ‘u’, and sometimes ‘y’.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.6 `@verb`{<char>text<char>}

Use the `@verb` command to print a verbatim sequence of characters.

Like LaTeX’s `\verb` command, the verbatim text can be quoted using any unique delimiter character. Enclose the verbatim text, including the delimiters, in braces. Text is printed in a fixed-width font:

 ```How many @verb{|@|}-escapes does one need to print this @verb{.@a @b @c.} string or @verb{+@'e?`!`{}\+} this? ```

produces

 ```How many @-escapes does one need to print this @a @b @c string or these @'e?`{}!`\ this? ```

This is in contrast to `@samp` (see the previous section), `@code`, and similar commands; in those cases, the argument is normal Texinfo text, where the three characters `@{}` are special. With `@verb`, nothing is special except the delimiter character you choose.

It is not reliable to use `@verb` inside other Texinfo constructs. In particular, it does not work to use `@verb` in anything related to cross-referencing, such as section titles or figure captions.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.7 `@var`{metasyntactic-variable}

Use the `@var` command to indicate metasyntactic variables. A metasyntactic variable is something that stands for another piece of text. For example, you should use a metasyntactic variable in the documentation of a function to describe the arguments that are passed to that function.

Do not use `@var` for the names of particular variables in programming languages. These are specific names from a program, so `@code` is correct for them (see section `@code`{sample-code}). For example, the XEmacs Lisp variable `texinfo-tex-command` is not a metasyntactic variable; it is properly formatted using `@code`.

Do not use `@var` for environment variables either; `@env` is correct for them (see the next section).

The effect of `@var` in the Info file is to change the case of the argument to all upper case. In the printed manual and HTML output, the argument is printed in slanted type.

For example,

 ```To delete file @var{filename}, type @samp{rm @var{filename}}. ```

produces

To delete file filename, type ‘rm filename’.

(Note that `@var` may appear inside `@code`, `@samp`, `@file`, etc.)

Write a metasyntactic variable all in lower case without spaces, and use hyphens to make it more readable. Thus, the Texinfo source for the illustration of how to begin a Texinfo manual looks like this:

 ```\input texinfo @@setfilename @var{info-file-name} @@settitle @var{name-of-manual} ```

This produces:

 ```\input texinfo @setfilename info-file-name @settitle name-of-manual ```

In some documentation styles, metasyntactic variables are shown with angle brackets, for example:

 ```…, type rm ```

However, that is not the style that Texinfo uses. (You can, of course, modify the sources to ‘texinfo.tex’ and the Info formatting commands to output the `<…>` format if you wish.)

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.8 `@env`{environment-variable}

Use the `@env` command to indicate environment variables, as used by many operating systems, including GNU. Do not use it for metasyntactic variables; use `@var` instead (see the previous section).

`@env` is equivalent to `@code` in its effects. For example:

 ```The @env{PATH} environment variable … ```

produces

The `PATH` environment variable …

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.9 `@file`{file-name}

Use the `@file` command to indicate text that is the name of a file, buffer, or directory, or is the name of a node in Info. You can also use the command for file name suffixes. Do not use `@file` for symbols in a programming language; use `@code`.

Currently, `@file` is equivalent to `@samp` in its effects. For example,

 ```The @file{.el} files are in the @file{/usr/local/xemacs/lisp} directory. ```

produces

The ‘.el’ files are in the ‘/usr/local/xemacs/lisp’ directory.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.10 `@command`{command-name}

Use the `@commannd` command to indicate command names, such as `ls` or `cc`.

`@command` is equivalent to `@code` in its effects. For example:

 ```The command @command{ls} lists directory contents. ```

produces

The command `ls` lists directory contents.

You should write the name of a program in the ordinary text font, rather than using `@command`, if you regard it as a new English word, such as ‘XEmacs’ or ‘Bison’.

When writing an entire shell command invocation, as in ‘ls -l’, you should use either `@samp` or `@code` at your discretion.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.11 `@option`{option-name}

Use the `@option` command to indicate a command-line option; for example, ‘-l’ or ‘--version’ or ‘--output=filename’.

`@option` is equivalent to `@samp` in its effects. For example:

 ```The option @option{-l} produces a long listing. ```

produces

The option ‘-l’ produces a long listing.

In tables, putting options inside `@code` produces a more pleasing effect.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.12 `@dfn`{term}

Use the `@dfn` command to identify the introductory or defining use of a technical term. Use the command only in passages whose purpose is to introduce a term which will be used again or which the reader ought to know. Mere passing mention of a term for the first time does not deserve `@dfn`. The command generates italics in the printed manual, and double quotation marks in the Info file. For example:

 ```Getting rid of a file is called @dfn{deleting} it. ```

produces

Getting rid of a file is called deleting it.

As a general rule, a sentence containing the defining occurrence of a term should be a definition of the term. The sentence does not need to say explicitly that it is a definition, but it should contain the information of a definition—it should make the meaning clear.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.13 `@abbr`{abbreviation[, meaning]}

You can use the `@abbr` command for general abbreviations. The abbreviation is given as the single argument in braces, as in ‘@abbr{Comput.}’. As a matter of style, or for particular abbreviations, you may prefer to omit periods, as in ‘@abbr{Mr} Stallman’.

`@abbr` accepts an optional second argument, intended to be used for the meaning of the abbreviation.

If the abbreviation ends with a lowercase letter and a period, and is not at the end of a sentence, and has no second argument, remember to use the `@.` command (see section Not Ending a Sentence) to get the correct spacing. However, you do not have to use `@.` within the abbreviation itself; Texinfo automatically assumes periods within the abbreviation do not end a sentence.

In TeX and in the Info output, the first argument is printed as-is; if the second argument is present, it is printed in parentheses after the abbreviation. In HTML and XML, the `<abbr>` tag is used; in Docbook, the `<abbrev>` tag is used. For instance:

 ```@abbr{Comput. J., Computer Journal} ```

produces:

 ```Comput. J. (Computer Journal) ```

For abbreviations consisting of all capital letters, you may prefer to use the `@acronym` command instead. See the next section for more on the usage of these two commands.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.14 `@acronym`{acronym[, meaning]}

Use the `@acronym` command for abbreviations written in all capital letters, such as ‘NASA’. The abbreviation is given as the single argument in braces, as in ‘@acronym{NASA}’. As a matter of style, or for particular acronyms, you may prefer to use periods, as in ‘@acronym{N.A.S.A.}’.

`@acronym` accepts an optional second argument, intended to be used for the meaning of the acronym.

If the acronym is at the end of a sentence, and if there is no second argument, remember to use the `@.` or similar command (see section Ending a Sentence) to get the correct spacing.

In TeX, the acronym is printed in slightly smaller font. In the Info output, the argument is printed as-is. In either format, if the second argument is present, it is printed in parentheses after the acronym. In HTML, Docbook, and XML, the `<acronym>` tag is used.

For instance (since GNU is a recursive acronym, we use `@acronym` recursively):

 ```@acronym{GNU, @acronym{GNU}'s Not Unix} ```

produces:

 ```GNU (@acronym{GNU}'s Not Unix) ```

In some circumstances, it is conventional to print family names in all capitals. Don’t use `@acronym` for this, since a name is not an acronym. Use `@sc` instead (see section `@sc`{text}: The Small Caps Font).

`@abbr` and `@acronym` are closely related commands: they both signal to the reader that a shortened form is being used, and possibly give a meaning. When choosing whether to use these two commands, please bear the following in mind.

• - In standard English usage, acronyms are a subset of abbreviations: they include pronounceable words like ‘NATO’, ‘radar’, and ‘snafu’, and some sources also include syllable acronyms like ‘Usenet’, hybrids like ‘SIGGRAPH’, and unpronounceable initialisms like ‘FBI’.
• - In Texinfo, an acronym (but not an abbreviation) should consist only of capital letters and periods, no lowercase.
• - In TeX, an acronym (but not an abbreviation) is printed in a slightly smaller font.
• - Some browsers place a dotted bottom border under abbreviations but not acronyms.
• - It’s not essential to use either of these commands for all abbreviations; use your judgment. Text is perfectly readable without them.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.15 `@indicateurl`{uniform-resource-locator}

Use the `@indicateurl` command to indicate a uniform resource locator on the World Wide Web. This is analogous to `@file`, `@var`, etc., and is purely for markup purposes. It does not produce a link you can follow in HTML output (use the `@uref` command for that, see section `@uref`). It is useful for url’s which do not actually exist. For example:

 ```For example, the url might be @indicateurl{http://example.org/path}. ```

which produces:

 ```For example, the url might be <`http://example.org/path`>. ```

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.1.16 `@email`{email-address[, displayed-text]}

Use the `@email` command to indicate an electronic mail address. It takes one mandatory argument, the address, and one optional argument, the text to display (the default is the address itself).

In Info, the address is shown in angle brackets, preceded by the text to display if any. In TeX, the angle brackets are omitted. In HTML output, `@email` produces a ‘mailto’ link that usually brings up a mail composition window. For example:

 ```Send bug reports to @email{bug-texinfo@@gnu.org}, suggestions to the @email{bug-texinfo@@gnu.org, same place}. ```

produces

 ```Send bug reports to bug-texinfo@gnu.org, suggestions to the same place. ```

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

## 9.2 Emphasizing Text

Usually, Texinfo changes the font to mark words in the text according to what category the words belong to; an example is the `@code` command. Most often, this is the best way to mark words. However, sometimes you will want to emphasize text without indicating a category. Texinfo has two commands to do this. Also, Texinfo has several commands that specify the font in which TeX will typeset text. These commands have no effect on Info and only one of them, the `@r` command, has any regular use.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.2.1 `@emph`{text} and `@strong`{text}

The `@emph` and `@strong` commands are for emphasis; `@strong` is stronger. In printed output, `@emph` produces italics and `@strong` produces bold.

For example,

 ```@strong{Caution:} @samp{rm * .[^.]*} removes @emph{all} files in the directory. ```

produces the following in printed output and HTML:

Caution: ‘rm * .[^.]*’ removes all files in the directory.

and the following in Info:

 ```*Caution:* `rm * .[^.]*' removes _all_ files in the directory. ```

The `@strong` command is seldom used except to mark what is, in effect, a typographical element, such as the word ‘Caution’ in the preceding example.

In the Info output, `@emph` surrounds the text with underscores (‘_’), and `@strong` puts asterisks around the text.

Caution: Do not use `@strong` with the word ‘Note’; Info will mistake the combination for a cross reference. (It’s usually redundant, anyway.) Use a phrase such as Please notice or Caution instead, or the optional argument to `@quotation`—‘Note’ is allowable there.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.2.2 `@sc`{text}: The Small Caps Font

Use the ‘@sc’ command to set text in A SMALL CAPS FONT (where possible). Write the text you want to be in small caps between braces in lower case, like this:

 ```Richard @sc{Stallman} founded @acronym{GNU}. ```

This produces:

 ```Richard STALLMAN founded GNU. ```

As shown here, we recommend using `@acronym` for actual acronyms (see section `@acronym`{acronym[, meaning]}), and reserving `@sc` for special cases where you want small caps. The output is not the same (`@acronym` prints in a smaller text font, not the small caps font), but more importantly it describes the actual text more accurately.

Family names are one case where small capitals are sometimes desirable, also as shown here.

TeX typesets any uppercase letters between the braces of an `@sc` command in full-size capitals; only lowercase letters are printed in the small caps font. In the Info output, the argument to `@sc` is printed in all upper case. In HTML, the argument is uppercased and the output marked with the `<small>` tag to reduce the font size.

Since it’s redundant to mark all-uppercase text with `@sc`, `makeinfo` warns about such usage.

We recommend using regular mixed case wherever possible.

 [ < ] [ > ] [ << ] [ Up ] [ >> ] [Top] [Contents] [Index] [ ? ]

### 9.2.3 Fonts for Printing, Not Info

Texinfo provides one command to change the size of the main body font in the TeX output for a document: `@fonttextsize`. It has no effect at all in other output. It takes a single argument on the remainder of the line, which must be either ‘10’ or ‘11’. For example:

 ```@fonttextsize 10 ```

The effect is to reduce the body font to a 10pt size (the default is 11pt). Fonts for other elements, such as sections and chapters, are reduced accordingly. This should only be used in conjunction with `@smallbook` (see section Printing “Small” Books) or similar, since 10pt fonts on standard paper (8.5x11 or A4) are too small. One reason to use this command is to save pages, and hence printing cost, for physical books.

Texinfo does not at present have commands to switch the font family to use, or more general size-changing commands.

Texinfo also provides a number of font commands that specify font changes in the printed manual and (where possible) in the HTML output, but have no effect in the Info file. All the commands apply to an argument that follows, surrounded by braces.

`@b`

selects bold face;

`@i`

selects an italic font;

`@r`

selects a roman font, which is the usual font in which text is printed. It may or may not be seriffed.

`@sansserif`

selects a sans serif font;

`@slanted`

selects a slanted font;

`@t`

selects the fixed-width, typewriter-style font used by `@code`;

(The commands with longer names were invented much later than the others, at which time it did not seem desirable to use very short names for such an infrequently needed feature.)

Only the `@r` command has much use: in example-like environments, you can use the `@r` command to write comments in the standard roman font instead of the fixed-width font. This looks better in printed output, and produces a `<lineannotation>` tag in Docbook output.

For example,

 ```@lisp (+ 2 2) ; @r{Add two plus two.} @end lisp ```

produces

 ```(+ 2 2) ; Add two plus two. ```

In general, you should avoid using the other font commands. Some of them are only useful when documenting functionality of specific font effects, such as in TeX and related packages.

 [ << ] [ >> ] [Top] [Contents] [Index] [ ? ]

This document was generated by Aidan Kehoe on December 27, 2016 using texi2html 1.82.