This document describes Supercite, an Emacs package for citing and attributing replies to mail and news messages.
Copyright © 1993, 2001–2024 Free Software Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover Texts being “A GNU Manual”, and with the Back-Cover Texts as in (a) below. A copy of the license is included in the section entitled “GNU Free Documentation License”.
(a) The FSF’s Back-Cover Text is: “You have the freedom to copy and modify this GNU manual.”
The manual is divided into the following chapters.
Supercite is a GNU Emacs package written entirely in Emacs Lisp. It interfaces to most of the commonly used Emacs mail user agents (MUAs) and news user agents (NUAs), and provides sophisticated facilities for the citing and attributing of message replies. Supercite has a very specific and limited role in the process of composing replies to both USENET network news and electronic mail.
The preferred way to spell Supercite is with a capital ‘S’, lowercase ‘upercite’.
Supercite is only useful in conjunction with MUAs and NUAs such as VM, Gnus, RMAIL, MH-E, etc. Supercite is typically called by the MUA after a reply buffer has been setup. Thereafter, Supercite’s many commands and formatting styles are available in that reply buffer until the reply is sent. Supercite is re-initialized in each new reply buffer.
Typical usage is as follows. You want to reply or followup to a message in your MUA. You will probably hit r (i.e., “reply”) or f (i.e., “forward”) to begin composing the reply. In response, the MUA will create a reply buffer and initialize the outgoing mail headers appropriately. The body of the reply will usually be empty at this point. You now decide that you would like to include part of the original message in your reply. To do this, you yank the original message into the reply buffer, typically with a key stroke such as C-c C-y. This sequence will invoke an MUA-specific function which fills the body of the reply with the original message and then attributes this text to its author. This is called citing and its effect is to prefix every line from the original message with a special text tag. Most MUAs provide some default style of citing; by using Supercite you gain a wider flexibility in the look and style of citations. Supercite’s only job is to cite the original message.
Because of this clear division of labor, there are useful features which are the sole responsibility of the MUA, even though it might seem that Supercite should provide them. For example, many people would like to be able to yank (and cite) only a portion of the original message. Since Supercite only modifies the text it finds in the reply buffer as set up by the MUA, it is the MUA’s responsibility to do partial yanking. See Reply Buffer Initialization.
Another potentially useful thing would be for Supercite to set up the
outgoing mail headers with information it gleans from the reply buffer.
But by previously agreed upon convention, any text above the
mail-header-separator
which separates mail headers from message
bodies cannot be modified by Supercite. Supercite, in fact, doesn’t
know anything about the meaning of these headers, and never ventures
outside the designated region. See Hints to MUA Authors, for more
details.
Supercite is invoked for the first time on a reply buffer via your MUA’s
reply or forward command. This command will actually perform citations
by calling a hook variable to which Supercite’s top-level function
sc-cite-original
has been added. When sc-cite-original
is
executed, the original message must be set up in a very specific way,
but this is handled automatically by the MUA. See Hints to MUA Authors.
The first thing Supercite does, via sc-cite-original
, is to parse
through the original message’s mail headers. It saves this data in an
information association list, or info alist. The information
in this list is used in a number of places throughout Supercite.
See Information Keys and the Info Alist.
After the mail header info is extracted, the headers are optionally removed (nuked) from the reply. Supercite then writes a reference header into the buffer. This reference header is a string carrying details about the citation it is about to perform.
Next, Supercite visits each line in the reply, transforming the line according to a customizable “script”. Lines which were not previously cited in the original message are given a citation, while already cited lines remain untouched, or are coerced to your preferred style. Finally, Supercite installs a keymap into the reply buffer so that you have access to Supercite’s post-yank formatting and reciting commands as you subsequently edit your reply. You can tell that Supercite has been installed into the reply buffer because that buffer’s modeline will display the minor mode string ‘SC’.
When the original message is cited by sc-cite-original
, it will
(optionally) be filled by Supercite. However, if you manually edit the
cited text and want to re-fill it, you must use an add-on package such
as filladapt or gin-mode. These packages can recognize
Supercited text and will fill them appropriately. Emacs’s built-in
filling routines, e.g., fill-paragraph
, do not recognize cited
text and will not re-fill them properly because it cannot guess the
fill-prefix
being used.
See Post-yank Formatting Commands, for details.
As mentioned above, Supercite provides commands to recite or uncite regions of text in the reply buffer, and commands to perform other beautifications on the cited original text, maintaining consistent and informative citations throughout. Supercite tries to be as configurable as possible to allow for a wide range of personalized citation styles, but it is also immediately useful with the default configuration, once it has been properly connected to your MUA. See Getting Connected, for more details.
A citation is the acknowledgment of the original author of a mail message in the body of the reply. There are two basic citation styles which Supercite supports. The first, called nested citations is an anonymous form of citation; in other words, an indication is made that the cited line was written by someone other that the current message author (i.e., other than you, the person composing the reply), but no reference is made as to the identity of the original author. This style should look familiar since its use on the net is widespread. Here’s an example of what a message buffer would look like using nested citations after multiple replies:
>> John originally wrote this >> and this as well > Jane said that John didn't know > what he was talking about And that's what I think too.
Note that multiple inclusions of the original messages result in a nesting of the ‘>’ characters. This can sometimes be quite confusing when many levels of citations are included since it may be difficult or impossible to figure out who actually participated in the thread, and multiple nesting of ‘>’ characters can sometimes make the message very difficult for the eye to scan.
In non-nested citations, each cited line begins with an informative string attributing that line to the original author. Only the first level of attribution will be shown; subsequent citations don’t nest the citation strings. The above dialog might look like this when non-nested citations are used:
John> John originally wrote this John> and this as well Jane> Jane said that John didn't know Jane> what he was talking about And that's what I think too.
Notice here that my inclusion of Jane’s inclusion of John’s original message did not result in a line cited with ‘Jane>John>’.
Supercite supports both styles of citation, and the variable
sc-nested-citation-p
controls which style it will use when
citing previously uncited text. When this variable is nil
(the
default), non-nested citations are used. When non-nil
, nested
citations are used.
Citation strings are composed of one or more elements. Non-nested citations are composed of four elements, three of which are directly user definable. The elements are concatenated together, in this order:
sc-citation-leader
, and has the default value of a
string containing four spaces.
sc-citation-delimiter
visually separates the citation from the
text of the line. This variable has a default value of ">"
and
for best results, the string should consist of only a single character.
sc-citation-separator
, and has the default value of
a string containing a single space.
For example, suppose you were using the default values for the above
variables, and Supercite provided the attribution string ‘Jane’.
In this case, the composed, non-nested citation string used might be
something like
" Jane> "
.
This citation string will be inserted in front of
every line in the original message that is not already cited.
Nested citations, being simpler than non-nested citations, are composed of the same elements, sans the attribution string. Supercite is smart enough to not put additional spaces between citation delimiters for multi-level nested citations.
Supercite also recognizes citations in the original article, and can transform these already cited lines in a number of ways. This is how Supercite suppresses the multiple citing of non-nested citations. Recognition of cited lines is controlled by variables analogous to those that make up the citation string as mentioned previously.
The variable sc-citation-leader-regexp
describes how citation
leaders can look, by default it matches any number of spaces or tabs.
Note that since the lisp function looking-at
is used to do the
matching, if you change this variable it need not start with a leading
"^"
.
Similarly, the variables sc-citation-delimiter-regexp
and
sc-citation-separator-regexp
respectively describe how citation
delimiters and separators can look. They follow the same rule as
sc-citation-leader-regexp
above.
When Supercite composes a citation string, it provides the attribution
automatically. The analogous variable which handles recognition of the
attribution part of citation strings is sc-citation-root-regexp
.
This variable describes the attribution root for both nested and
non-nested citations. By default it can match zero-to-many alphanumeric
characters (also “.”, “-”, and “_”). But in some situations,
Supercite has to determine whether it is looking at a nested or
non-nested citation. Thus the variable
sc-citation-nonnested-root-regexp
is used to describe only
non-nested citation roots. It is important to remember that if you
change sc-citation-root-regexp
you should always also change
sc-citation-nonnested-root-regexp
.
Mail header information keys are nuggets of information that
Supercite extracts from the various mail headers of the original
message, placed in the reply buffer by the MUA. Information is kept
in the Info Alist as key-value pairs, and can be retrieved for
use in various places within Supercite, such as in header rewrite
functions and attribution selection. Other bits of data, composed and
created by Supercite, are also kept as key-value pairs in this alist.
In the case of mail fields, the key is the name of the field, omitting
the trailing colon. Info keys are always case insensitive (as are
mail headers), and the value for a corresponding key can be retrieved
from the alist with the sc-mail-field
function. Thus, if the
following fields were present in the original article:
Date: 08 April 1991, 17:32:09 EST Subject: Better get out your asbestos suit
then, the following lisp constructs return:
(sc-mail-field "date") ==> "08 April 1991, 17:32:09 EST" (sc-mail-field "subject") ==> "Better get out your asbestos suit"
Since the argument to sc-mail-field
can be any string, it is
possible that the mail field will not be present on the info alist
(possibly because the mail header was not present in the original
message). In this case, sc-mail-field
will return the value of
the variable sc-mumble
.
Supercite always places all mail fields found in the yanked original article into the info alist. If possible, Supercite will also places the following keys into the info alist:
"sc-attribution"
¶the selected attribution string.
"sc-citation"
¶the non-nested citation string.
"sc-from-address"
¶email address extracted from the ‘From:’ field.
"sc-reply-address"
¶email address extracted from the ‘Reply-To:’ field.
"sc-sender-address"
¶email address extracted from the ‘Sender:’ field.
"sc-emailname"
¶email terminus extracted from the ‘From:’ field.
"sc-initials"
¶the author’s initials.
"sc-author"
¶the author’s full name.
"sc-firstname"
¶the author’s first name.
"sc-lastname"
¶the author’s last name.
"sc-middlename-1"
¶the author’s first middle name.
If the author’s name has more than one middle name, they will appear as
info keys with the appropriate index (e.g., "sc-middlename-2"
,
…). See Selecting an Attribution.
Supercite will insert an informative reference header at the beginning of the cited body of text, which display more detail about the original article and provides the mapping between the attribution and the original author in non-nested citations. Whereas the citation string usually only contains a portion of the original author’s name, the reference header can contain such information as the author’s full name, email address, the original article’s subject, etc. In fact any information contained in the info alist can be inserted into a reference header.
There are a number of built-in header rewrite functions supplied
by Supercite, but you can write your own custom header rewrite
functions (perhaps using the built-in ones as examples). The variable
sc-rewrite-header-list
contains the list of such header rewrite
functions. This list is consulted both when inserting the initial
reference header, and when displaying electric references.
See Electric References.
When Supercite is initially run on a reply buffer (via
sc-cite-original
), it will automatically call one of these
functions. The one it uses is defined in the variable
sc-preferred-header-style
. The value of this variable is an
integer which is an index into the sc-rewrite-header-list
,
beginning at zero.
Below are examples of the various built-in header rewrite functions.
Please note the following: first, the text which appears in the
examples below as infokey indicates that the corresponding value
of the info key from the info alist will be inserted there.
(see Information Keys and the Info Alist). For example, in sc-header-on-said
below, date and from correspond to the values of the
‘Date:’ and ‘From:’ mail headers respectively.
Also, the string ">>>>>"
below is really the value of the
variable sc-reference-tag-string
. This variable is used in all
built-in header rewrite functions, and you can customize its value to
change the tag string globally.
Finally, the references headers actually written may omit certain parts of the header if the info key associated with infokey is not present in the info alist. In fact, for all built-in headers, if the ‘From:’ field is not present in the mail headers, the entire reference header will be omitted (but this usually signals a serious problem either in your MUA or in Supercite’s installation).
sc-no-header
¶This function produces no header. It should be used instead of
nil
to produce a blank header. This header can possibly
contain a blank line after the mail-header-separator
line.
sc-no-blank-line-or-header
¶This function is similar to sc-no-header
except that any blank
line after the mail-header-separator
line will be removed.
sc-header-on-said
¶>>>>> On date, from said:
sc-header-inarticle-writes
¶>>>>> In article message-id, from writes:
sc-header-regarding-adds
¶>>>>> Regarding subject; from adds:
sc-header-attributed-writes
¶>>>>> "sc-attribution" == sc-author <sc-reply-address> writes:
sc-header-author-writes
¶>>>>> sc-author writes:
sc-header-verbose
¶>>>>> On date,
>>>>> sc-author
>>>>> from the organization of organization
>>>>> who can be reached at: sc-reply-address
>>>>> (whose comments are cited below with: "sc-cite")
>>>>> had this to say in article message-id
>>>>> in newsgroups newsgroups
>>>>> concerning the subject of subject
>>>>> see references for more details
By default, when Supercite cites the original message for the first
time, it just goes ahead and inserts the reference header indexed by
sc-preferred-header-style
. However, you may want to select
different reference headers based on the type of reply or forwarding
you are doing. You may also want to preview the reference header
before deciding whether to insert it into the reply buffer or
not. Supercite provides an optional electric reference mode
which you can drop into to give you this functionality.
If the variable sc-electric-references-p
is non-nil
,
Supercite will bring up an electric reference mode buffer and place you
into a recursive edit. The electric reference buffer is read-only, so
you cannot directly modify the reference text until you exit electric
references and insert the text into the reply buffer. But you can cycle
through all the reference header rewrite functions in your
sc-rewrite-header-list
.
You can also set a new preferred header style, jump to any header, or jump to the preferred header. The header will be shown in the electric reference buffer and the header index and function name will appear in the echo area.
The following commands are available while in electric reference mode (shown here with their default key bindings):
sc-eref-next
(n) ¶Displays the next reference header in the electric reference buffer. If
the variable sc-electric-circular-p
is non-nil
, invoking
sc-eref-next
while viewing the last reference header in the list
will wrap around to the first header.
sc-eref-prev
(p) ¶Displays the previous reference header in the electric reference buffer.
If the variable sc-electric-circular-p
is non-nil
,
invoking sc-eref-prev
will wrap around to the last header.
sc-eref-goto
(g) ¶Goes to a specified reference header. The index (into the
sc-rewrite-header-list
) can be specified as a numeric argument to
the command. Otherwise, Supercite will query you for the index in the
minibuffer.
sc-eref-jump
(j) ¶Display the preferred reference header, i.e., the one indexed by the current
value of sc-preferred-header-style
.
sc-eref-setn
(s) ¶Set the preferred reference header (i.e.,
sc-preferred-header-style
) to the currently displayed header.
sc-eref-exit
(C-j, RET, and ESC C-c) ¶Exit from electric reference mode and insert the current header into the reply buffer.
sc-eref-abort
(q, x) ¶Exit from electric reference mode without inserting the current header.
Supercite will execute the hook sc-electric-mode-hook
before
entering electric reference mode.
In most cases, all that is necessary to begin using Supercite is to add the following to ~.emacs:
(add-hook 'mail-citation-hook 'sc-cite-original)
For more details of the process, read on…
Hitting C-c C-y in your MUA’s reply buffer yanks and cites the
original message into the reply buffer. In reality, the citation of the
original message is performed via a call through a configurable hook
variable. The name of this variable has been agreed to in advance as
part of the citation interface specification. By default this
hook variable has a nil
value, which the MUA recognizes to mean,
“use your default citation function.” When you add Supercite’s
citation function to the hook, thereby giving the variable a
non-nil
value, it tells the MUA to run the hook via
run-hooks
instead of using the default citation.
Early in Supercite’s development, the Supercite author, a few MUA
authors, and some early Supercite users got together and agreed upon a
standard interface between MUAs and citation packages (of which
Supercite is currently the only known add-on :-)
. Supercite can
probably be used with most Emacs MUAs, with a greater or lesser degree
of effort.
To learn exactly how to connect Supercite to the software systems you are using, read the appropriate following sections. For details on the interface specifications, or if you are writing or maintaining an MUA, see Hints to MUA Authors.
The first thing that everyone should do, regardless of the MUA you are using is to set up Emacs so it will load Supercite at the appropriate time. This happens automatically if Supercite is distributed with your Emacs version. If not, you can set up an autoload for Supercite.
To do the latter, put the following in your .emacs file:
(autoload 'sc-cite-original "supercite" nil t)
The function sc-cite-original
is the top-level Supercite function
designed to be run from the citation hook. It expects
‘point’ and ‘mark’ to be set around the region to cite, and it
expects the original article’s mail headers to be present within this
region. Note that Supercite never touches any text outside this
region. Note further that the region need not be active
for sc-cite-original
to do its job.
See Hints to MUA Authors.
The other step in the getting connected process is to make sure your
MUA calls sc-cite-original
at the right time. As mentioned
above, some MUAs handle this differently. Read the sections that follow
pertaining to the MUAs you are using.
This chapter explains what happens when you reply and yank an original message from an MUA.
Executing sc-cite-original
performs the following steps as it
initializes the reply buffer:
sc-pre-hook
.
This hook variable is run before sc-cite-original
does any other
work. You could conceivably use this hook to set certain Supercite
variables based on the reply buffer’s mode or name (i.e., to do
something different based on whether you are replying or following up to
an article).
You can control what key Supercite uses as its keymap prefix by changing
the variable sc-mode-map-prefix
. By default, this variable is
set to C-c C-p
; a finger twister perhaps, but unfortunately the
best default due to the scarcity of available key bindings in many MUAs.
sc-mail-warn-if-non-rfc822-p
is
non-nil
, then Supercite will warn you if it finds a mail header
that does not conform to RFC 822 (or later).
This is rare and indicates a problem
either with your MUA or the original author’s MUA, or some MTA (mail
transport agent) along the way.
Once the info keys have been extracted from the mail headers, the headers are nuked from the reply buffer. You can control exactly which headers are removed or kept, but by default, all headers are removed.
There are two variables which control mail header nuking. The variable
sc-nuke-mail-headers
controls the overall behavior of the header
nuking routines. By setting this variable to 'all
, you
automatically nuke all mail headers. Likewise, setting this variable to
'none
inhibits nuking of any mail headers. In between these
extremes, you can tell Supercite to nuke only a specified list of mail
headers by setting this variable to 'specified
, or to keep only a
specified list of headers by setting it to 'keep
.
If sc-nuke-mail-headers
is set to 'specified
or
'keep
, then the variable sc-nuke-mail-header-list
is
consulted for the list of headers to nuke or keep. This variable
contains a list of regular expressions. If the mail header line matches
a regular expression in this list, the header will be nuked or kept.
The line is matched against the regexp using looking-at
rooted at
the beginning of the line.
If the variable sc-blank-lines-after-headers
is non-nil
,
it contains the number of blank lines remaining in the buffer after mail
headers are nuked. By default, only one blank line is left in the buffer.
sc-cite-region-limit
. If this variable contains an
integer, messages with more lines that this will not be cited at all,
and a warning message will be displayed. Supercite has performed
everything necessary, though, for you to manually cite only the small
portion of the original message that you want to use.
If sc-cite-region-limit
contains a non-nil
value, the
original message will always be cited, regardless of its size. If the
variable contains the value nil
, the region will never be cited
automatically. Use this if you always want to be able to edit and cite
the message manually.
The variable sc-cite-blank-lines-p
controls whether blank lines
in the original message should be cited or not. If this variable is
non-nil
, blank lines will be cited just like non-blank lines.
Otherwise, blank lines will be treated as paragraph separators.
Citing of the original message is highly configurable. Supercite’s default setup does a pretty good job of citing many common forms of previously cited messages. But there are as many citation styles out there as people on the net, or just about! It would be impossible for Supercite to anticipate every style in existence, and you probably wouldn’t encounter them all anyway. But you can configure Supercite to recognize those styles you see often. See Configuring the Citation Engine, for details.
sc-post-hook
.
This variable is very similar to sc-pre-hook
, except that it runs
after sc-cite-original
is finished. This hook is provided mostly
for completeness and backward compatibility. Perhaps it could be used to
reset certain variables set in sc-pre-hook
.
Supercite will automatically fill newly cited text from the original
message unless the variable sc-auto-fill-region-p
has a
nil
value. Supercite will also re-fill paragraphs when you
manually cite or re-cite text.
However, during normal editing, Supercite itself cannot be used to fill
paragraphs. This is a change from version 2. There are other add-on
lisp packages which do filling much better than Supercite ever did. The
two best known are filladapt and gin-mode. Both work well
with Supercite and both are available at the normal Emacs Lisp archive
sites. gin-mode works pretty well out of the box, but if you use
filladapt, you may want to run the function
sc-setup-filladapt
after loading supercite
(e.g., using with-eval-after-load
). This simply
makes filladapt a little more Supercite savvy than its default
setup.
Also, Supercite will collapse leading whitespace between the citation
string and the text on a line when the variable
sc-fixup-whitespace-p
is non-nil
. The default value for
this variable is nil
.
Its important to understand that Supercite’s automatic filling (during
the initial citation of the reply) is very fragile. That is because
figuring out the fill-prefix
for a particular paragraph is a
really hard thing to do automatically. This is especially the case when
the original message contains code or some other text where leading
whitespace is important to preserve. For this reason, many Supercite
users typically run with sc-auto-fill-region-p
(and possibly also
sc-fixup-whitespace-p
) set to nil
. They then manually
fill each cited paragraph in the reply buffer.
I usually run with both these variables containing their default values. When Supercite’s automatic filling breaks on a particular message, I will use Emacs’s undo feature to undo back before the citation was applied to the original message. Then I’ll toggle the variables and manually cite those paragraphs that I don’t want to fill or collapse whitespace on. See Variable Toggling Shortcuts.
If you find that Supercite’s automatic filling is just too fragile for
your tastes, you might consider one of these alternate approaches.
Also, to make life easier, a shortcut function to toggle the state of
both of these variables is provided on the key binding
C-c C-p C-p (with the default value of sc-mode-map-prefix
;
see Post-yank Formatting Commands).
You will noticed that the minor mode string will
show the state of these variables as qualifier characters. When both
variables are nil
, the Supercite minor mode string will display
‘SC’. When just sc-auto-fill-region-p
is non-nil
, the
string will display ‘SC:f’, and when just
sc-fixup-whitespace-p
is non-nil
, the string will display
‘SC:w’. When both variables are non-nil
, the string will
display ‘SC:fw’. Note that the qualifiers chosen are mnemonics for
the default bindings of the toggling function for each respective
variable.
See Variable Toggling Shortcuts.
Why are these variables not set to nil
by default? It is because
many users won’t manually fill paragraphs that are Supercited, and there
have been widespread complaints on the net about mail and news messages
containing lines greater than about 72 characters. So the default is to
fill cited text.
As you know, the attribution string is the part of the author’s name that will be used to composed a non-nested citation string. Supercite scans the various mail headers present in the original article and uses a number of heuristics to extract strings which it puts into the attribution association list or attribution alist. This is analogous, but different from, the info alist previously mentioned. Each element in the attribution alist is a key-value pair containing such information as the author’s first name, middle names, and last name, the author’s initials, and the author’s email terminus.
When you cite an original message, you can tell Supercite which part of
the author’s name you would prefer it to use as the attribution. The
variable sc-preferred-attribution-list
controls this; it contains
keys which are matched against the attribution alist in the given order.
The first value of a key that produces a non-nil
, non-empty
string match is used as the attribution string, and if no keys match, a
secondary mechanism is used to generate the attribution.
See Anonymous Attributions.
The following preferences are always available in the attribution alist (barring error):
"emailname"
the author’s email terminus.
"initials"
the author’s initials.
"firstname"
the author’s first name.
"lastname"
the author’s last name.
"middlename-1"
the author’s first middle name.
"sc-lastchoice"
the last attribution string you have selected. This is useful when you recite paragraphs in the reply.
"sc-consult"
¶consults the customizable list sc-attrib-selection-list
which can
be used to select special attributions based on the value of any info
key. See below for details.
"x-attribution"
the original author’s suggestion for attribution string choice. See below for details.
Middle name indexes can be any positive integer greater than zero, though it is unlikely that many authors will have more than one middle name, if that many.
At this point, let me digress into a discussion of etiquette. It is my belief that while the style of the citations is a reflection of the personal tastes of the replier (i.e., you), the attribution selection is ultimately the personal choice of the original author. In a sense it is his or her “net nickname”, and therefore the author should have some say in the selection of attribution string. Imagine how you would feel if someone gave you a nickname that you didn’t like?
For this reason, Supercite recognizes a special mail header,
‘X-Attribution:’, which if present, tells Supercite the attribution
string preferred by the original author. It is the value of this header
that is associated with the "x-attribution"
key in the
attribution alist. Currently, you can override the preference of this
key by changing sc-preferred-attribution-list
, but that isn’t
polite, and in the future Supercite may hard-code this. For now, it is
suggested that if you change the order of the keys in this list, that
"x-attribution"
always be first, or possible second behind only
"sc-lastchoice"
. This latter is the default.
The value "sc-consult"
in sc-preferred-attribution-list
has a special meaning during attribution selection. When Supercite
encounters this preference, it begins processing a customizable list of
attributions, contained in the variable sc-attrib-selection-list
.
Each element in this list contains lists of the following form:
(infokey ((regexp . attribution) (regexp . attribution) (...)))
where infokey is a key for sc-mail-field
and regexp
is a regular expression to match against the infokey’s value. If
regexp matches the infokey’s value, the attribution is
used as the attribution string. Actually, attribution can be a
string or a list; if it is a list, it is eval
uated and the return
value (which must be a string), is used as the attribution.
This can be very useful for when you are replying to net acquaintances who do not use the ‘X-Attribution:’ mail header. You may know what nickname they would prefer to use, and you can set up this list to match against a specific mail field, e.g., ‘From:’, allowing you to cite your friend’s message with the appropriate attribution.
When the author’s name cannot be found in the ‘From:’ mail
header, a fallback author name and attribution string must be supplied.
The fallback author name is contained in the variable
sc-default-author-name
and the fallback attribution string is
contained in the variable sc-default-attribution
. Default values
for these variables are "Anonymous"
and "Anon"
,
respectively. Note that in most circumstances, getting the default
author name or attribution is a sign that something is set up
incorrectly.
Also, if the preferred attribution, which you specified in your
sc-preferred-attribution-list
variable cannot be found, a
secondary method can be employed to find a valid attribution string. The
variable sc-use-only-preference-p
controls what happens in this
case. If the variable’s value is non-nil
, then
sc-default-author-name
and sc-default-attribution
are
used, otherwise, the following steps are taken to find a valid
attribution string, and the first step to return a non-nil
,
non-empty string becomes the attribution:
"x-attribution"
key.
nil
, non-empty attribution string in the
attribution alist.
sc-default-attribution
is used.
Once the attribution string has been automatically selected, a number of
things can happen. If the variable sc-confirm-always-p
is
non-nil
, you are queried for confirmation of the chosen
attribution string. The possible values for completion are those strings
in the attribution alist, however you are not limited to these choices.
You can type any arbitrary string at the confirmation prompt. The string
you enter becomes the value associated with the "sc-lastchoice"
key in the attribution alist.
Once an attribution string has been selected, Supercite will force the
string to lower case if the variable sc-downcase-p
is
non-nil
.
Two hook variables provide even greater control of the attribution
selection process. The hook sc-attribs-preselect-hook
is run
before any attribution is selected. Likewise, the hook
sc-attribs-postselect-hook
is run after the attribution is
selected (and the corresponding citation string is built), but before
these values are committed for use by Supercite. During the
post-selection hook, the local variables attribution
and
citation
are bound to the appropriate strings. By changing these
variables in your hook functions, you change the attribution and
citation strings used by Supercite. One possible use of this would be
to override any automatically derived attribution string when it is only
one character long; e.g., you prefer to use "initials"
but the
author only has one name.
Supercite employs a number of heuristics to decipher the author’s name based on value of the ‘From:’ mail field of the original message. Supercite can recognize almost all of the common ‘From:’ field formats in use. If you encounter a ‘From:’ field that Supercite cannot parse, please report this bug using M-x report-emacs-bug.
There are a number of Supercite variables that control how author names are extracted from the ‘From:’ header. Some headers may contain a descriptive title as in:
From: computer!speedy!doe (John Xavier-Doe -- Decent Hacker)
Supercite knows which part of the ‘From:’ header is email address
and which part is author name, but in this case the string "Decent
Hacker"
is not part of the author’s name. You can tell Supercite to
ignore the title, while still recognizing hyphenated names through the
use of a regular expression in the variable sc-titlecue-regexp
.
This variable has the default value of "\\\\s +-+\\\\s +"
. Any
text after this regexp is encountered is ignored as noise.
Some ‘From:’ headers may contain extra titles in the name fields
not separated by a title cue, but which are nonetheless not part of the
author’s name proper. Examples include the titles “Dr.”, “Mr.”,
“Ms.”, “Jr.”, “Sr.”, and “III” (e.g., Thurston Howe, the Third).
Also, some companies prepend or append the name of the division,
organization, or project on the author’s name. All of these titles are
noise which should be ignored. The variable sc-name-filter-alist
is used for this purpose. As implied by its name, this variable is an
association list, where each element is a cons cell of the form:
(regexp . position)
where regexp is a regular expression that is matched (using
string-match
) against each element of the ‘From:’ field’s
author name. position is a position indicator, starting at zero.
Thus to strip out all titles of “Dr.”, “Mr.”, etc. from the name,
sc-name-filter-alist
would have an entry such as:
("^\\(Mr\\|Mrs\\|Ms\\|Dr\\)[.]?$" . 0)
which only removes them if they appear as the first word in the name.
The position indicator is an integer, or one of the two special symbols
last
or any
. last
always matches against the last
word in the name field, while any
matches against every word in
the name field.
At the heart of Supercite is a regular expression interpreting engine
called Regi. Regi operates by interpreting a data structure
called a Regi-frame (or just frame), which is a list of
Regi-entries (or just entry). Each entry contains a predicate,
typically a regular expression, which is matched against a line of text
in the current buffer. If the predicate matches true, an associated
expression is eval
uated. In this way, an entire region of text
can be transformed in an awk-like manner. Regi is used
throughout Supercite, from mail header information extraction, to header
nuking, to citing text.
While the details of Regi are discussed below (see Using Regi), only those who wish to customize certain aspects of Supercite need concern themselves with it. It is important to understand though, that any conceivable citation style that can be described by a regular expression can be recognized by Supercite. This leads to some interesting applications. For example, if you regularly receive email from a co-worker that uses an uncommon citation style (say one that employs a ‘|’ or ‘}’ character at the front of the line), it is possible for Supercite to recognize this and coerce the citation to your preferred style, for consistency. In theory, it is possible for Supercite to recognize such things as uuencoded messages or C code and cite or fill those differently from normal text. None of this is currently part of Supercite, but contributions are welcome!
Regi works by interpreting frames with the function
regi-interpret
. A frame is a list of arbitrary size where each
element is an entry of the following form:
(pred func [negate-p [case-fold-search]])
Regi starts with the first entry in a frame, evaluating the pred
of that entry against the beginning of the line that ‘point’ is on.
If the pred evaluates to true (or false if the optional
negate-p is non-nil
), then the func for that entry is
eval
uated. How processing continues is determined by the return
value for func, and is described below. If pred was false
the next entry in the frame is checked until all entries have been
matched against the current line. If no entry matches, ‘point’ is
moved forward one line and the frame is reset to the first entry.
pred can be a string, a variable, a list or one of the following
symbols: t
, begin
, end
, or every
. If
pred is a string, or a variable or list that eval
uates to a
string, it is interpreted as a regular expression. This regexp is
matched against the current line, from the beginning, using
looking-at
. This match folds case if the optional
case-fold-search is non-nil
. If pred is not a
string, or does not eval
uate to a string, it is interpreted as a
binary value (nil
or non-nil
).
The four special symbol values for pred are recognized:
t
Always produces a true outcome.
begin
Always executed before the frame is interpreted. This can be used to initialize some global variables for example.
end
Always executed after frame interpreting is completed. This can be used to perform any necessary post-processing.
every
Executes whenever the frame is reset, usually after the entire frame has been matched against the current line.
Note that negate-p and case-fold-search are ignored if pred is one of these special symbols. Only the first occurrence of each symbol in a frame is used; any duplicates are ignored. Also note that for performance reasons, the entries associated with these symbols are removed from the frame during the main interpreting loop.
Your func can return certain values which control continued Regi
processing. By default, if your func returns nil
(as it
should be careful to do explicitly), Regi will reset the frame to the
first entry, and advance ‘point’ to the beginning of the next line.
If a list is returned from your function, it can contain any combination
of the following elements:
continue
This tells Regi to continue processing entries after a match, instead of resetting the frame and moving ‘point’. In this way, lines of text can have multiple matches, but you have to be careful to avoid entering infinite loops.
abort
This tells Regi to terminate frame processing. However, any end
entry is still processed.
(frame . newframe)
This tells Regi to substitute newframe as the frame it is interpreting. In other words, your func can modify the Regi frame on the fly. newframe can be a variable containing a frame, or it can be the frame in-lined.
(step . step)
Tells Regi to move step number of lines forward as it continues processing. By default, Regi moves forward one line. step can be zero or negative of course, but watch out for infinite loops.
During execution of your func, the following variables will be temporarily bound to some useful information:
curline
The current line in the buffer that Regi is looking-at
, as a string.
curframe
The current frame being interpreted.
curentry
The current frame entry being interpreted.
As mentioned earlier, Supercite uses various frames to perform
certain jobs such as mail header information extraction and mail header
nuking. However, these frames are not available for you to customize,
except through abstract interfaces such as sc-nuke-mail-header
,
et al.
However, the citation frames Supercite uses provide a lot of customizing
power and are thus available to you to change to suit your needs. The
workhorse of citation is the frame contained in the variable
sc-default-cite-frame
. This frame recognizes many situations,
such as blank lines, which it interprets as paragraph separators. It
also recognizes previously cited nested and non-nested citations in the
original message. By default it will coerce non-nested citations into
your preferred citation style, and it will add a level of citation to
nested citations. It will also simply cite uncited lines in your
preferred style.
In a similar vein, there are default frames for unciting and
reciting, contained in the variables
sc-default-uncite-frame
and sc-default-recite-frame
respectively.
As mentioned earlier (see Recognizing Citations), citations are
recognized through the values of the regular expressions
sc-citation-root-regexp
, et al. To recognize odd styles, you
could modify these variables, or you could modify the default citing
frame. Alternatively, you could set up association lists of frames for
recognizing specific alternative forms.
For each of the actions—citing, unciting, and reciting—an alist is
consulted to find the frame to use (sc-cite-frame-alist
,
sc-uncite-frame-alist
, and sc-recite-frame-alist
respectively). These frames can contain alists of the form:
((infokey (regexp . frame) (regexp . frame) ...) (infokey (regexp . frame) (regexp . frame) ...) (...))
Where infokey is a key suitable for sc-mail-field
,
regexp is a regular expression which is string-match
’d
against the value of the sc-mail-field
key, and frame is
the frame to use if a match occurred. frame can be a variable
containing a frame or a frame in-lined.
When Supercite is about to cite, uncite, or recite a region, it consults the appropriate alist and attempts to find a frame to use. If one is not found from the alist, then the appropriate default frame is used.
Once the original message has been yanked into the reply buffer, and
sc-cite-original
has had a chance to do its thing, a number of
useful Supercite commands will be available to you. Since there is wide
variety in the keymaps that MUAs set up in their reply buffers, it is
next to impossible for Supercite to properly sprinkle its commands into
the existing keymap. For this reason Supercite places its commands on a
separate keymap, putting this keymap onto a prefix key in the reply
buffer. You can customize the prefix key Supercite uses by changing the
variable sc-mode-map-prefix
. By default, the
sc-mode-map-prefix
is C-c C-p; granted, not a great choice,
but unfortunately the best general solution so far. In the rest of this
chapter, we’ll assume you’ve installed Supercite’s keymap on the default
prefix.
Probably the three most common post-yank formatting operations that you
will perform will be the manual citing, reciting, and unciting of
regions of text in the reply buffer. Often you may want to recite a
paragraph to use a nickname, or manually cite a message when setting
sc-cite-region-limit
to nil
. The following commands
perform these functions on the region of text between ‘point’ and
‘mark’. Each of them sets the undo boundary before modifying
the region so that the command can be undone in the standard Emacs
way.
Here is the list of Supercite citing commands:
sc-cite-region
(C-c C-p c) ¶This command cites each line in the region of text by interpreting the
selected frame from sc-cite-frame-alist
, or the default citing
frame sc-default-cite-frame
. It runs the hook
sc-pre-cite-hook
before interpreting the frame. With an optional
universal argument (C-u), it temporarily sets
sc-confirm-always-p
to t
so you can confirm the
attribution string for a single manual citing.
See Configuring the Citation Engine.
sc-uncite-region
(C-c C-p u) ¶This command removes any citation strings from the beginning of each
cited line in the region by interpreting the selected frame from
sc-uncite-frame-alist
, or the default unciting frame
sc-default-uncite-frame
. It runs the hook
sc-pre-uncite-hook
before interpreting the frame.
See Configuring the Citation Engine.
sc-recite-region
(C-c C-p r) ¶This command recites each line the region by interpreting the selected
frame from sc-recite-frame-alist
, or the default reciting frame
sc-default-recite-frame
. It runs the hook
sc-pre-recite-hook
before interpreting the frame.
See Configuring the Citation Engine.
Supercite will always ask you to confirm the attribution when reciting a
region, regardless of the value of sc-confirm-always-p
.
These two functions insert various strings into the reply buffer.
sc-insert-reference
(C-c C-p w) ¶Inserts a reference header into the reply buffer at ‘point’. With
no arguments, the header indexed by sc-preferred-header-style
is
inserted. An optional numeric argument is the index into
sc-rewrite-header-list
indicating which reference header to
write.
With just the universal argument (C-u), electric reference mode is
entered, regardless of the value of sc-electric-references-p
.
sc-insert-citation
(C-c C-p i) ¶Inserts the current citation string at the beginning of the line that ‘point’ is on. If the line is already cited, Supercite will issue an error and will not cite the line.
Supercite defines a number of commands that make it easier for you to toggle and set various Supercite variables as you are editing the reply buffer. For example, you may want to turn off filling or whitespace cleanup, but only temporarily. These toggling shortcut commands make this easy to do.
Like Supercite commands in general, the toggling commands are placed on
a keymap prefix within the greater Supercite keymap. For the default
value of sc-mode-map-prefix
, this will be
C-c C-p C-t.
The following commands toggle the value of certain Supercite variables which take only a binary value:
Toggles the variable sc-mail-nuke-blank-lines-p
.
Toggles the variable sc-confirm-always-p
.
Toggles the variable sc-downcase-p
.
Toggles the variable sc-electric-references-p
.
Toggles the variable sc-auto-fill-region-p
.
Toggles the variable sc-electric-circular-p
.
Toggles the variable sc-nested-citation-p
.
Toggles the variable sc-use-only-preferences-p
.
Toggles the variable sc-fixup-whitespace-p
.
The following commands let you set the value of multi-value variables,
in the same way that Emacs’s set-variable
does:
Sets the value of the variable sc-preferred-attribution-list
.
Sets the value of the variable sc-cite-region-limit
.
Sets the value of the variable sc-mail-nuke-mail-headers
.
Sets the value of the variable sc-mail-header-nuke-list
.
Sets the value of the variable sc-preferred-header-style
.
One special command is provided to toggle both
sc-auto-fill-region-p
and sc-fixup-whitespace-p
together.
This is because you typically want to run Supercite with either variable
as nil
or non-nil
. The command to toggle these variables
together is bound on C-c C-p C-p.
Finally, the command C-c C-p C-t h (also C-c C-p C-t ?) brings up a Help message on the toggling keymap.
These commands allow you to view, modify, add, and delete various bits of information from the info alist. See Information Keys and the Info Alist.
sc-mail-field-query
(C-c C-p f) ¶Allows you to interactively view, modify, add, and delete info alist key-value pairs. With no argument, you are prompted (with completion) for an info key. The value associated with that key is displayed in the minibuffer. With an argument, this command will first ask if you want to view, modify, add, or delete an info key. Viewing is identical to running the command with no arguments.
If you want to modify the value of a key, Supercite will first prompt you (with completion) for the key of the value you want to change. It will then put you in the minibuffer with the key’s current value so you can edit the value as you wish. When you hit RET, the key’s value is changed. Minibuffer history is kept for the values.
If you choose to delete a key-value pair, Supercite will prompt you (with completion) for the key to delete.
If you choose to add a new key-value pair, Supercite firsts prompts you for the key to add. Note that completion is turned on for this prompt, but you can type any key name here, even one that does not yet exist. After entering the key, Supercite prompts you for the key’s value. It is not an error to enter a key that already exists, but the new value will override any old value. It will not replace it though; if you subsequently delete the key-value pair, the old value will reappear.
sc-mail-process-headers
(C-c C-p g) ¶This command lets you re-initialize Supercite’s info alist from any set of mail headers in the region between ‘point’ and ‘mark’. This function is especially useful for replying to digest messages where Supercite will initially set up its information for the digest originator, but you want to cite each component article with the real message author. Note that unless an error during processing occurs, any old information is lost.
In June of 1989, some discussion was held between the various MUA authors, the Supercite author, and other Supercite users. These discussions centered around the need for a standard interface between MUAs and Supercite (or any future Supercite-like packages). This interface was formally proposed by Martin Neitzel on Fri, 23 Jun 89, in a mail message to the Supercite mailing list:
Martin> Each news/mail-reader should provide a form of Martin> mail-yank-original that Martin> 1: inserts the original message incl. header into the Martin> reply buffer; no indentation/prefixing is done, the header Martin> tends to be a "full blown" version rather than to be Martin> stripped down. Martin> 2: 'point' is at the start of the header, 'mark' at the Martin> end of the message body. Martin> 3: (run-hooks 'mail-yank-hooks) Martin> [Supercite] should be run as such a hook and merely Martin> rewrite the message. This way it isn't anymore Martin> [Supercite]'s job to gather the original from obscure Martin> sources. [...]
This specification was adopted, but underwent a slight modification with
the release of Emacs 19. Instead of the variable
mail-yank-hooks
, the hook variable that the MUA should provide is
mail-citation-hook
. Richard Stallman suggests that the MUAs
should defvar
mail-citation-hook
to nil
and perform
some default citing when that is the case.
If you are writing a new MUA package, or maintaining an existing MUA package, you should make it conform to this interface so that your users will be able to link Supercite easily and seamlessly. To do this, when setting up a reply or forward buffer, your MUA should follow these steps:
mail-header-separator
line and one copy below, however
there will probably be more headers below this line.
mail-citation-hook
. You will probably want to
provide some kind of default citation functions in cases where the user
does not have Supercite installed. By default, your MUA should
defvar
mail-citation-hook
to nil
, and in your
yanking function, check its value. If it finds
mail-citation-hook
to be nil
, it should perform some
default citing behavior. User who want to connect to Supercite then
need only add sc-cite-original
to this list of hooks using
add-hook
.
If you do all this your MUA will join the ranks of those that conform to this interface “out of the box.”
The Supercite package was derived from its predecessor Superyank 1.11 which was inspired by various bits of code and ideas from Martin Neitzel and Ashwin Ram. They were the folks who came up with the idea of non-nested citations and implemented some rough code to provide this style. Superyank and Supercite version 2 evolved to the point where much of the attribution selection mechanism was automatic, and features have been continuously added through the comments and suggestions of the Supercite mailing list participants.
With version 3, Supercite underwent an almost complete rewrite, benefiting in a number of ways, including vast improvements in the speed of performance, a big reduction in size of the code and in the use of Emacs resources, and a much cleaner and flexible internal architecture. Most of this work was internal and not of very great importance to the casual user. There were some changes at the user-visible level, but for the most part, the Supercite configuration variables from version 2 should still be relevant to version 3. Hopefully Supercite version 3 is faster, smaller, and much more flexible than its predecessors.
In the version 2 manual I thanked some specific people for their help in
developing Supercite 2. You folks know who you are and your continued
support is greatly appreciated. I wish to thank everyone on the
Supercite mailing list, especially the brave alpha testers, who helped
considerably in testing out the concepts and implementation of Supercite
version 3. Special thanks go out to the MUA and Emacs authors Kyle
Jones, Stephen Gildea, Richard Stallman, and Jamie Zawinski for coming
to a quick agreement on the new mail-citation-hook
interface, and
for adding the magic lisp to their code to support this.
All who have helped and contributed have been greatly appreciated.
Supercite was written by Barry Warsaw.
Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc. https://fsf.org/ Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
The purpose of this License is to make a manual, textbook, or other functional and useful document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”. You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.
A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document’s overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none.
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words.
A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not “Transparent” is called “Opaque”.
Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work’s title, preceding the beginning of the body of the text.
The “publisher” means any person or entity that distributes copies of the Document to the public.
A section “Entitled XYZ” means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.) To “Preserve the Title” of such a section when you modify the Document means that it remains a section “Entitled XYZ” according to this definition.
The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document’s license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version’s license notice. These titles must be distinct from any other section titles.
You may add a section Entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections Entitled “History” in the various original documents, forming one section Entitled “History”; likewise combine any sections Entitled “Acknowledgements”, and any sections Entitled “Dedications”. You must delete all sections Entitled “Endorsements.”
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an “aggregate” if the copyright resulting from the compilation is not used to limit the legal rights of the compilation’s users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document’s Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail.
If a section in the Document is Entitled “Acknowledgements”, “Dedications”, or “History”, the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.
You may not copy, modify, sublicense, or distribute the Document except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense, or distribute it is void, and will automatically terminate your rights under this License.
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, receipt of a copy of some or all of the same material does not give you any rights to use it.
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See https://www.gnu.org/licenses/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. If the Document specifies that a proxy can decide which future versions of this License can be used, that proxy’s public statement of acceptance of a version permanently authorizes you to choose that version for the Document.
“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any World Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works. A public wiki that anybody can edit is an example of such a server. A “Massive Multiauthor Collaboration” (or “MMC”) contained in the site means any set of copyrightable works thus published on the MMC site.
“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0 license published by Creative Commons Corporation, a not-for-profit corporation with a principal place of business in San Francisco, California, as well as future copyleft versions of that license published by that same organization.
“Incorporate” means to publish or republish a Document, in whole or in part, as part of another Document.
An MMC is “eligible for relicensing” if it is licensed under this License, and if all works that were first published under this License somewhere other than this MMC, and subsequently incorporated in whole or in part into the MMC, (1) had no cover texts or invariant sections, and (2) were thus incorporated prior to November 1, 2008.
The operator of an MMC Site may republish an MMC contained in the site under CC-BY-SA on the same site at any time before August 1, 2009, provided the MMC is eligible for relicensing.
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:
Copyright (C) year your name. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled ``GNU Free Documentation License''.
If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts, replace the “with…Texts.” line with this:
with the Invariant Sections being list their titles, with the Front-Cover Texts being list, and with the Back-Cover Texts being list.
If you have Invariant Sections without Cover Texts, or some other combination of the three, merge those two alternatives to suit the situation.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
Since all supercite commands are prepended with the string
“sc-
”, each appears under its sc-
command name and
its command name.
Since all supercite variables are prepended with the string
“sc-
”, each appears under its sc-
variable name and
its variable name.