Copyright (c) 2001, 2009 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 2.0, 20 March 2009), 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 3), you can specify “branches” in the latter with expressions like /home/{graham,terry/{thg/*.nee,brazil},michael/*}, which is very handy.
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 characters of the first line of its header (filling the window width if possible). 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.
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 two following 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 March 2009, its documentation can be found directly at http://www.python.org/doc/current/lib/module-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 eight following characters: space, tabulation,
newline, &, |, ~, (, and !. When
one of the six 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 in 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:
r_1 ~p_1 r_2 ~p_2 ... ~p_n-1 r_n
where r_1, ..., r_n represent regular expressions and p_1, ..., p_n-1 decimal integers.
Such an expression is said to match if and only if a match of r_1 is found within p_1 words of a match of r_2, itself found within p_2 words of a match of r_3, etc. The anchors used to count words are at the beginning of words (a single regexp can match several words). Examples:
black ~2 cat ~3 sleeping
"knights%I" ~3 say ~2 "Ni|Nee%I" ~10 "shrubber(y|ies)"
Any whitespace (spaces, tabulations or newlines) between the regexps
and the ~p_k operators is ignored and can therefore be used to
improve the readability of a near expression.
The ~p_k 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.
As of version 2.0, TDBSF supports 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). TDBSF refuses to work with a database file that contains non-ASCII characters and has no encoding declaration.
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.0 at
http://docs.python.org/3.0/library/codecs.html#id3). 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 to search through the contents of each file.
Every string read by tdbsf_front_end.py is expected in the UTF-8 encoding (for now, this means only command-line arguments, since standard input is not used for anything). Its output is also encoded in UTF-8. This is straightforward, and allows frontends to use the full Unicode character set, even if the current locale is more limited.
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.
59 Temple Place, Suite 330, Boston, MA 02111-1307 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 Library 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 an idea of what it does.
Copyright (C) 19yy 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.,
59 Temple Place, Suite 330, Boston, MA 02111-1307, 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) 20yy 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 Library General Public License instead of this License.
Copyright (C) 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 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:
A. Use in the Title Page (and on the covers, if any) a title distinct
from that of the Document, and from those of previous versions
(which should, if there were any, be listed in the History section
of the Document). You may use the same title as a previous version
if the original publisher of that version gives permission.
B. List on the Title Page, as authors, one or more persons or entities
responsible for authorship of the modifications in the Modified
Version, together with at least five of the principal authors of the
Document (all of its principal authors, if it has less than five).
C. State on the Title page the name of the publisher of the
Modified Version, as the publisher.
D. Preserve all the copyright notices of the Document.
E. Add an appropriate copyright notice for your modifications
adjacent to the other copyright notices.
F. Include, immediately after the copyright notices, a license notice
giving the public permission to use the Modified Version under the
terms of this License, in the form shown in the Addendum below.
G. Preserve in that license notice the full lists of Invariant Sections
and required Cover Texts given in the Document's license notice.
H. Include an unaltered copy of this License.
I. Preserve the section entitled “History”, and its title, and add to
it an item stating at least the title, year, new authors, and
publisher of the Modified Version as given on the Title Page. If
there is no section entitled “History” in the Document, create one
stating the title, year, authors, and publisher of the Document as
given on its Title Page, then add an item describing the Modified
Version as stated in the previous sentence.
J. Preserve the network location, if any, given in the Document for
public access to a Transparent copy of the Document, and likewise
the network locations given in the Document for previous versions
it was based on. These may be placed in the “History” section.
You may omit a network location for a work that was published at
least four years before the Document itself, or if the original
publisher of the version it refers to gives permission.
K. In any section entitled “Acknowledgements” or “Dedications”,
preserve the section's title, and preserve in the section all the
substance and tone of each of the contributor acknowledgements
and/or dedications given therein.
L. Preserve all the Invariant Sections of the Document,
unaltered in their text and in their titles. Section numbers
or the equivalent are not considered part of the section titles.
M. Delete any section entitled “Endorsements.” Such a section
may not be included in the Modified Version.
N. Do not retitle any existing section as “Endorsements”
or to conflict in title with any Invariant Section.
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 “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, 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 March 2009, 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.