Copyright (c) 2001-2013 Florent Rougon.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Section being “GNU GENERAL PUBLIC LICENSE”, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License”.
This manual documents the TDBSF (version 3.2.2, 29 March 2013), a small search engine for “databases” stored in a very simple (trivial) format.
--- The Detailed Node Listing ---
Introduction
Search expression syntax
The TDBSF (Trivial Database Search Facility) is a small search engine for “databases” stored in a very simple (trivial) format.
The engine is written in Python and as of March 2009, there is only one really usable user interface, written in ELisp for Emacs. However, the TDBSF is designed to ease the addition of interfaces, so this is only a matter of whether there are people wanting to use it outside Emacs or not.
The databases that can be used with the TDBSF consist of a set of text files divided into records. Each record consists of four parts—a header, a body and two parts used to identify them: the beginning-of-header (boh) and the end-of-header (eoh).
The beginning of a header is identified by a regular expression (whose syntax is defined in the “re” module for the Python programming langage). Another regular expression is used to define where it ends and therefore where the body of the record begins. The body ends where the next beginning-of-header regular expression matches or at end of the file. For instance, a record could look like this (the last two lines belong to the second record):
===============================================================
Header of the first record
As many lines as necessary
---------------------------------------------------------------
Body
of
the
first
record
===============================================================
Header of the next record...
A TDBSF database file is a file containing one or more records like that in sequence.
The TDBSF tests a search expression on each record of a database defined by its set of database files and allows the user to view/edit (depending on the interface used) the matching records.
I wrote this software because my father used during years an old shareware to retreive some data stored in “databases” as described above, which has severe limitations, is not easily extensible and only works on MS-DOS and some versions of MS Windows. The TDBSF enables him to solve these problems while keeping its “databases” unchanged. Besides, it is much more powerful and fast than the original tool.
Supposing you have followed the instructions in the INSTALL file, here is what you have to do in order to use the TDBSF with the Emacs interface1:
A search expression consists of regular expressions combined with
optional parentheses and the following operators: & (logical
and), | (logical or), ! (logical not) and near
expressions (for instance, foo ~4 bar ~2 baz ~3 quux is a near
expression that matches if and only if ‘foo’ and ‘bar’
are found within—at most—4 words, this occurrence of ‘bar’
being found within 2 words of an occurrence of ‘baz’ itself found
within 3 words of ‘quux’). Simple words and quoted groups of words
"like this" are valid regular expressions. Example:
swallow ~4 carry ~3 coconut & "air-speed velocity" & !European
which is the same as:
(swallow ~4 carry ~3 coconut) & "air-speed velocity" & (!European)
By the way, such expressions would probably be more useful with flags making the regular expressions case-insensitive. See Search expression syntax, for more information.
Note: after being successfully parsed, a search expression is
converted into a tree and this tree is optimized in order to maximize
the search speed for this expression. This is done by attributing a
weight to each subexpression of the search expression (a regular
expression will have a weight related to its length; for near
expressions, the weights of its elements will be multiplied together;
for & and | operators, the weights of the operands are
added, etc.). Then, the order in which the operations are performed is
chosen so that the “lighter” operations are more likely to be
performed than the “heavier” ones (base idea: in an expression such
as a & b & c, if a is false, then neither b nor
c needs to be evaluated: the whole expression is false; similar
considerations can be done with the | operator and with near
expressions).
C:/Roger/shrubberies/*.tdb
(typically Windowsish) or (on Unix):
/home/roger/shrubberies/*.tdb
The main difference between glob-module-style patterns and Unix shell-style patterns is that, with some Unix shells (not the POSIX shell as defined in the Single Unix Specification version 4), you can specify “branches” in the latter with expressions like /home/{graham,terry/{thg/*.nee,brazil},michael/*}, which is very handy. Another difference is that the “glob” module does not perform tilde expansion, contrary to the POSIX shell.
The results are presented in a summary buffer named *TDBSF Results Summary* put in TDBSF Summary mode. There is one reference to a matching record per line, displaying the file name where it was found and the first line of its header. Just hit <RET> on a line in this buffer (or click with the middle button of the mouse) and another buffer will be popped, visiting the file and showing the record in TDBSF Database File mode, where some highlighting is done to show why the record matched2.
Sometimes, one can be surprised that not all matches of a regexp that is
part of the search expression are highlighted in a matching record. This
is expected, because the way search expressions are evaluated in each
record is optimized for speed. For instance, suppose the search expression is
"cat%I" | "donkey%I" | "turkey%I" and the search engine looks for
matches of "cat%I" first (which is likely since it is the
shortest of the three regular expressions). If such matches are found,
the two other animals won't be searched for at all, much less
highlighted, since it is logically sufficient that "cat%I"
matches for the whole search expression to match. Moreover, if the
search string is header or body (remember the four options) and
the search expression matches the header of a given record, then the
body of that record won't be searched at all, and therefore not
highlighted in any way.
In TDBSF Summary mode, you can type C-c C-n or C-c C-p to jump to the next or previous matching record, respectively, visiting a new file if needed.
The following two paragraphs deal with details that can be skipped on the first reading of this manual.
Emacs markers are set in TDBSF Database File mode so that inserting or deleting text in the file will not cause any problem when jumping to the previous/next record or to any record of that file from the *TDBSF Results Summary* buffer. Also, the fontification is performed with overlays which also have markers to specify their beginning and end, therefore fontification doesn't get screwed in case of insertion/deletion in a buffer in TDBSF Database File mode.
Because of these mechanisms, TDBSF refuses to use a buffer (in order to display a record) if it is marked as modified. This is because information such as the positions where each record starts is stored into buffer-local variables when TDBSF performs a search and becomes outdated when buffers visiting TDBSF databse files are modified. If you edit a database file and want accurate jumps from the *TDBSF Results Summary* buffer to the modified buffer (through <RET> or middle click), the simplest way is to save the modified buffer and launch the search again.
A search expression is an expression which can be checked against a string (e.g. the body of a record) to see if it matches that string or not.
It is a combination of simple elements that match or don't match the
string, using the boolean and (&), or (|) and not
(!) operators as well as parentheses to force the order in
which the operations are performed (a match is considered as a boolean
“true” and a non-match as a “false”). In the TDBSF terminology,
the simplest of these elements are called atoms and are either
regular expressions or near-expressions (near-expressions will be
defined later).
Any whitespace (spaces, tabulations or newlines) between atoms and operators is ignored and can therefore be used to improve the readability of a search expression.
The regular expression syntax used by the TDBSF is that of the “re” module of the Python programming langage. As of February 2013, its documentation can be found directly at http://docs.python.org/3/library/re.html. In any case, you will find it starting from http://www.python.org/. This syntax is very powerful, therefore a bit complex and cannot be detailed here: it would result in a useless, bad duplicate.
There are two ways to embed a re-module-style regular expression (regexp) in a TDBSF search expression:
"), then it is an
unquoted regexp and consists of any character sequence that does
not include any of the following nine characters: space, tab, newline,
&, |, ~, ), (, and !. When
one of the seven first ones is found while reading an unquoted regexp,
it marks the end of the regexp (and is not included in it). When one of
the two last ones is found while reading an unquoted regexp, it is a
syntax error for the search expression.
An unquoted regexp is directly fed to the “re” module with no interpretation.
"), then it is a
quoted regexp and ends with the next non-escaped double quote.
Yes, there is an escape character in quoted regexps: \. A
quoted regexp can specify either a pattern (in the re-module
terminology) or a pattern and flags (which can make the regexp
matching case-insensitive, multiline compliant, etc.—see the
re-module documentation).
To allow for this, if the regexp contains a %, then it ends the
pattern part and the following characters belong to the flags.
Multiple flags must be separated with | as in the following
regexp:
"black cat%IGNORECASE|LOCALE|MULTILINE"
(where the two last flags are useless) which is equivalent to:
"black cat%I|L|M"
as well as to:
"black cat%I|LOCALE|M"
and so on.
The escaping mechanism was introduced to enable you to put a %
or a double quote (") in your pattern that neither ends the
pattern nor the regexp. Whenever the TDBSF encounters the escape
character \ in the pattern or the flags part of a quoted
regexp, it only and directly feeds the next character (which is said
to be escaped3) to the “re”
module. In particular, if \\ is input, a single ‘\’ is fed
to the “re” module.
Knowing all that, we can write the “good” version of the previous example:
"black\\scat%I"
which will match a ‘black cat’ with any whitespace (matched by
\s in Python re-module-style regexps) between the two words and
regardless of the case (thanks to the I flag).
Currently, I see no reason to use the escape character in the flags part since all flags consist only of (uppercase) letters (although pretty unlikely, this might change in later versions of the “re” module).
Note: you may wonder why a quoted regexp like "foo\\n" matches
‘foo’ and a following newline. This is not due to the
Python parser interpreting its \n escape sequence. The Python
parser does not process the strings in a search expression as if
they were directly written in a .py file. Here, the
interpretation of the \n sequence as a newline is done by the
“re” module itself. To match the literal string ‘foo\n’ (5
characters long), you have to use "foo\\\\n" so that the regexp
as seen by the “re” module is "foo\\n".
To summarize: a quoted regexp is split into two parts at the first
non-escaped % character to define its pattern and its flags. If
there is no non-escaped %, it defines a pattern and no flags.
Each part is fed to the “re” module after having treated all escape
sequences. Of course, the two double quotes enclosing a quoted regexp
are not fed to the “re” module.
A near expression is a combination of two or more regular expressions following the syntax:
r1 ~p1 r2 ~p2 ... ~pn-1 rn
where r1, ..., rn represent regular expressions and p1, ..., pn-1 integers (written in decimal notation).
Such an expression is said to match if and only if a match of r1 is found within p1 words of a match of r2, itself found within p2 words of a match of r3, etc. The anchors used to count words are at the beginning of words (a single regexp can match several words). Example:
nice ~2 cat
This will not only match “nice cat”, but also “nice little cat”, “nice black cat” and “cat is nice”, it will even match “nice mean cat” (!). However, it won't match “nice black and white cat”, nor “nice fat black cat”. Another example:
nice ~4 little ~1 cat
This will of course match “nice little cat”, but also “nice black and white little cat”, “nice, little cat”, “cat little and nice” and many others. A final example:
"knights%I" ~3 say ~2 "Ni|Nee%I" ~10 "shrubber(y|ies)"
In addition to the constraints defined by the ~3, ~2 and
~10 operators, this search expression will accomodate for some
uncertainty in the writing of “Ni” versus “Nee” (or any variation in
case) or “shrubbery” versus “shrubberies”.
Any whitespace (spaces, tabs or newlines) between the regexps and the
~pk operators is ignored and can therefore be used to improve
the readability of a near expression.
For now, a word is defined as a contiguous sequence of characters that are either a hyphen (‘-’) or underscore (‘_’), or for which the Python unicodedata.category function returns a string that starts with “L” (letter) or “N” (number).
The ~pk operator used in near expressions has the highest
priority. Then comes the ! operator, then the & and
finally the |.
In other words, near expressions grab as many regexps as possible,
then ! negation operators directly apply on the following
expression. & and | behave as the multiplication and the
addition of numbers respectively, in terms of priority.
If you don't want to ask you such questions, just use parentheses to force operators precedence!
Here is a search expression example using all the features available (well, not all available regarding the re-module-style regexps!):
("bridge of death%I" | "gorge of eternal peril%I") & bridgekeeper
& (three ~3 questions) & !hesitat
No, this is not a really useful example. And yes, the parenthesis
around three ~3 questions are only here to improve readability.
Since version 2.0, TDBSF has supported international character sets and encodings in database files. This is done through the use of Unicode in the search engine. The search expression can of course contain any Unicode character supported by Python's “re” module.
In order to use non-ASCII characters in a database file, the encoding must be specified in an encoding declaration (this is a sane practice that has been common for long among Emacs users and is now also required for Python source files, except when using the UTF-8 encoding). TDBSF refuses to work with a database file that contains non-ASCII characters and has no encoding declaration. (Actually, a UTF-8 Byte Order Mark is accepted as a substitute for an encoding declaration, but this practice is discouraged.)
The encoding declaration uses a format that is recognized by both Emacs and Python. It consists of a single line at the beginning of each database file, such as the following:
-*- coding: utf-8 -*-
(no need to put any space before the magic delimiter -*-)
This declaration line should be followed by a blank line, then by the header of the first record of the database file. For instance:
-*- coding: utf-8 -*-
===============================================================
Header of the first record
As many lines as necessary
---------------------------------------------------------------
Body of the first record
...
===============================================================
Header of the second record
---------------------------------------------------------------
Body of the second record
...
Any encoding supported by Python can be used in the declaration, as long
as it is ASCII-compatible (e.g., iso-8859-1, iso-8859-15,
utf-8): this is necessary, because the line specifying the
encoding is read before the encoding is known!
The list of valid encodings can be found at
html/lib/standard-encodings.html in the documentation shipped
with your Python installation (online version for Python 3 at
http://docs.python.org/3/library/codecs.html#standard-encodings). Of
course, if you use Emacs to view or edit the database files, you should
make sure that the encoding name you choose is also recognized by
Emacs. That is why utf-8 is preferable to utf_8. This is
usually easy, because both Python and Emacs recognize a few aliases for
common encodings, and Python considers spelling alternatives of encoding
names that only differ in case or use a hyphen instead of an underscore
as equivalent.
Different database files may use different encodings; everything is converted to Unicode in the engine before it starts searching through the contents of each file.
The command-line arguments of tdbsf-front-end are automatically decoded by Python from the user's “preferred encoding” (cf. locale.getpreferredencoding). Its output is also encoded in the same encoding (tdbsf-front-end uses the default behavior of Python 3 with respect to encoding).
The Emacs interface offers three variables to specify the encoding it uses
when communicating with tdbsf-front-end:
tdbsf-coding-system-for-read,
tdbsf-coding-system-for-write (both defaulting to 'utf-8) and
tdbsf-pythonioencoding (which defaults to
"utf-8:strict"). It should not be necessary to modify these
variables, as UTF-8 can encode any Unicode character.
The Python tdbsf package provides a Crawler class that
allows any Python program to use the TDBSF search engine. See the
tdbsf_api.py file for details.
It must be easy to improve the method of specifying a set of database files, for instance by reading a set of glob-module-style patterns or allowing to explore directories recursively. The main changes would affect the interfaces. If I get any request, I'll probably improve this aspect.
Copyright © 1989, 1991 Free Software Foundation, Inc.
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software—to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Lesser General Public License instead.) You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.
To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.
Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.
Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.
The precise terms and conditions for copying, distribution and modification follow.
Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.
You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.
In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.
The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.
If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.
It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.
This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.
Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and “any later version”, you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.
one line to give the program's name and a brief idea of what it does.
Copyright (C) yyyy name of author
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
Also add information on how to contact you by electronic and paper mail.
If the program is interactive, make it output a short notice like this when it starts in an interactive mode:
Gnomovision version 69, Copyright (C) year name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands ‘show w’ and ‘show c’ should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than ‘show w’ and ‘show c’; they could even be mouse-clicks or menu items—whatever suits your program.
You should also get your employer (if you work as a programmer) or your school, if any, to sign a “copyright disclaimer” for the program, if necessary. Here is a sample; alter the names:
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
signature of Ty Coon, 1 April 1989
Ty Coon, President of Vice
This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License.
Copyright © 2000 Free Software Foundation, Inc.
51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA
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 written 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 that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”.
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. (For example, 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.
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 “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and 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 has been designed to thwart or discourage subsequent modification by readers is not Transparent. 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 designed for human modification. Opaque formats include PostScript, PDF, 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 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.
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 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 publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. 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.
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 “Acknowledgments”, 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, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an “aggregate”, and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they 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 quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around 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 provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
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 http://www.gnu.org/copyleft/.
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.
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.1
or any later version published by the Free Software Foundation;
with the Invariant Sections being list their titles, with the
Front-Cover Texts being list, and with the Back-Cover Texts being list.
A copy of the license is included in the section entitled ``GNU
Free Documentation License''.
If you have no Invariant Sections, write “with no Invariant Sections” instead of saying which ones are invariant. If you have no Front-Cover Texts, write “no Front-Cover Texts” instead of “Front-Cover Texts being list”; likewise for Back-Cover Texts.
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.
[1] No other interface is really functional as of February 2013, but the TDBSF is written so that adding interfaces is as easy as possible. :-)
[2] The fontification process tries to reflect the structure of the branch of the search expression that triggered the match by for instance giving all the elements of a matching near expression the same face (a face in Emacs is a combination of a font, a color and other such attributes).
[3] The combination of the escape character and the following one forms an escape sequence.