A manual need not and should not contain more than one definition for
a given name. An appendix containing a summary should use
@table rather than the definition commands.
When you write a definition using @deffn, @defun, or
one of the other definition commands, please take care to use
arguments that indicate the meaning, as with the count argument
to the forward-word function. Also, if the name of an argument
contains the name of a type, such as integer, take care that the
argument actually is of that type.
Fonts. As Texinfo is a semantic language, you should nearly never need to specify font styles with explicit font commands in definitions (see Fonts for Printing). However, you may be need to work around problems for particular output formats and/or constructs. Here are some possibilities:
@r{&keyword}, producing &keyword.
Note such keywords in definition arguments are (at present) rendered in roman in TeX, but this formatting is not done in any other output format.
@var
but avoiding upper-casing its argument in Info output.
In this and the previous point, @r resets the font from that
being used in the definition line context (slanted or typewriter) to
a roman, upright style.
@t (or even ‘@r{@t{…’, using @r
to reset font styles) to mark literal syntax
on a definition line where
text would otherwise be output in the slanted roman style.
@code would be inappropriate here as it adds quotation
marks in Info output.
Some degree of trial and error may be needed to get the result you want. As ever, how nested font commands combine depends on the output format, so should be avoided where possible.
Hopefully, such usages are kept to a minimum. One possibility is to
wrap these in @macro (see Defining New Texinfo Commands),
allowing these usages to be easily changed in the future.