ctags.rb 1.0.0

data/ext/vendor/exuberant-ctags/FAQ

@@ -0,0 +1,371 @@
+Frequently Asked Questions
+==========================
+
+    * 1.  Why do you call it "Exuberant Ctags"?
+    * 2.  Why doesn't my editor work with these tag files?
+    * 3.  What are these strange bits of text beginning with ;"?
+    * 4.  Why doesn't XEmacs' Speedbar module work with Exuberant Ctags?
+    * 5.  Why doesn't Xemacs correctly locate the tag in the source file?
+    * 6.  Why doesn't NEdit correctly locate the tag in the source file?
+    * 7.  Why can't I jump to "class::member"?
+    * 8.  How can I avoid having to specify my favorite option every time?
+    * 9.  Why do I end up on the wrong line when I jump to a tag?
+    * 10.  How do I jump to the tag I want instead of the wrong one by the
+           same name?
+    * 11.  What is "Vim"?
+    * 12.  How can I locate all references to a specific function or variable?
+    * 13.  Why does appending tags to a tag file tag so long?
+    * 14.  How do I get regex support for Win32?
+    * 15.  How should I set up tag files for a multi-level directory hierarchy?
+
+  ----------------------------------------------------------------------
+1.  Why do you call it "Exuberant Ctags"?
+
+Because one of the meanings of the word "exuberant" is:
+
+    exuberant : produced in extreme abundance : PLENTIFUL syn see PROFUSE
+
+Compare the tag file produced by Exuberant Ctags with that produced by any
+other ctags and you will see how appropriate the name is.
+
+  ----------------------------------------------------------------------
+2.  Why doesn't my editor work with these tag files?
+
+3.  What are these strange bits of text beginning with ;" which follow
+    many of the lines in the tag file?
+
+These are "extension flags". They are added in order to provide extra
+information about the tag that may be utilized by the editor in order to
+more intelligently handle tags. They are appended to the EX command part of
+the tag line in a manner that provides backwards compatibility with existing
+implementations of the Vi editor. The semicolon is an EX command separator
+and the double quote begins an EX comment. Thus, the extension flags appear
+as an EX comment and should be ignored by the editor when it processes the
+EX command.
+
+Some non-vi editors, however, implement only the bare minimum of EX commands
+in order to process the search command or line number in the third field of
+the tag file. If you encounter this problem, use the option "--format=1" to
+generate a tag file without these extensions (remember that you can set the
+CTAGS environment variable to any default arguments you wish to supply). Then
+ask the supplier of your editor to implement handling of this feature of EX
+commands.
+
+  ----------------------------------------------------------------------
+4.  Why doesn't XEmacs' Speedbar module work with Exuberant Ctags?
+
+The default command line switches used by XEmacs for "etags" are not
+compatible with Exuberant Ctags options. By default, Exuberant Ctags installs
+a symbolic link, "etags", pointing to the ctags executable. When Exuberant
+Ctags is started with the name "etags", it produces Emacs-style tag files by
+default.
+
+To fix this, add the following lines to your .emacs file, replacing the path
+to "etags" with the path where the symbolic link was installed.
+
+(autoload 'speedbar "speedbar")
+(setq speedbar-fetch-etags-command "/usr/local/bin/etags"
+      speedbar-fetch-etags-arguments '("-f" "-"))
+
+  ----------------------------------------------------------------------
+5.  Why doesn't Xemacs correctly locate the tag in the source file?
+
+This has been observed with version 20.3. It seems that when Xemacs searches
+for a tag, it searches using the tag name instead of the search string located
+in the TAGS file. This is a bug in Xemacs and does not occur in the GNU
+version of Emacs.
+
+  ----------------------------------------------------------------------
+6.  Why doesn't NEdit correctly locate the tag in the source file?
+
+Versions of NEdit prior to 5.1 did not support the extended tag file format
+generated by Exuberant Ctags by default. Either upgrade to version 5.1 or
+specify the option "--format=1" when running ctags to output the old tag file
+format.
+
+  ----------------------------------------------------------------------
+7.  Why can't I jump to "class::member"?
+
+Because, by default, ctags only generates tags for the separate identifiers
+found in the source files. If you specify the --extra=+q option, then
+ctags will also generate a second, class-qualified tag for each class member
+(data and function/method) in the form class::member for C++, and in the form
+class.method for Eiffel and Java.
+
+  ----------------------------------------------------------------------
+8.  How can I avoid having to specify my favorite option every time?
+
+Either by setting the environment variable CTAGS to your custom
+options, or putting them into a .ctags file in your home directory.
+
+  ----------------------------------------------------------------------
+9.  Why do I end up on the wrong line when I jump to a tag?
+
+By default, ctags encodes the line number in the file where macro (#define)
+tags are found. This was done to remain compatible with the original UNIX
+version of ctags. If you change the file containing the tag without
+rebuilding the tag file, the location of tag in the tag file may no longer
+match the current location.
+
+In order to avoid this problem, you can specify the option "--excmd=p",
+which causes ctags to use a search pattern to locate macro tags. I have
+never uncovered the reason why the original UNIX ctags used line numbers
+exclusively for macro tags, but have so far resisted changing the default
+behaviour of Exuberant Ctags to behave differently.
+
+  ----------------------------------------------------------------------
+10.  How do I jump to the tag I want instead of the wrong one by the
+     same name?
+
+A tag file is simple a list of tag names and where to find them. If there
+are duplicate entries, you often end up going to the wrong one because the
+tag file is sorted and your editor locates the first one in the tag file.
+
+Standard Vi provides no facilities to alter this behavior. However, Vim
+has some nice features to minimize this problem, primarly by examining all
+matches and choosing the best one under the circumstances. Vim also provides
+commands which allow for selection of the desired matching tag.
+
+  ----------------------------------------------------------------------
+11.  What is "Vim"?
+
+Vim is a vi-compatible editor available as source and compilable for any
+platform. Yeah, I know the first reaction is to shy away from this. But you
+will never regret getting it, and you will become greatly attached to its
+features, which you can learn gradually. I would be willing to say that it
+is the best vi-clone available within 4 light-years of Alpha Centauri. It
+works (nearly) exactly like standard vi, but provides some incredibly useful
+extensions (some of which I have participated in designing with the author).
+Most Linux distributions have adopted Vim as its standard vi.
+
+  ----------------------------------------------------------------------
+12.  How can I locate all references to a specific function or variable?
+
+There are several packages already available which provide this capability.
+Namely, these are: GLOBAL source code tag system, GNU id-utils, cscope,
+and cflow. As of this writing, they can be found in the following locations:
+
+GLOBAL:    http://www.gnu.org/software/global
+id-utils:  http://www.gnu.org/software/idutils/idutils.html
+cscope:    http://cscope.sourceforge.net
+cflow:     ftp://www.ibiblio.org/pub/Linux/devel/lang/c
+
+  ----------------------------------------------------------------------
+13.  Why does appending tags to a tag file tag so long?
+
+Sometimes, in an attempt to build a global tag file for all source files in
+a large source tree of many directories, someone will make an attempt to run
+ctags in append (-a) mode on every directory in the hierarchy. Each time
+ctags is invoked, its default behavior is to sort the tag file once the tags
+for that execution have been added. As the cumulative tag file grows, the sort
+time increases arithmetically.
+
+The best way to avoid this problem (and the most efficient) is to make
+use of the --recurse (or -R) option of ctags by executing the following
+command in the root of the directory hierarchy (thus running ctags only once):
+
+        ctags -R
+
+If you really insist on running ctags separately on each directory, you can
+avoid the sort pass each time by specifying the option "--sort=no". Once the
+tag file is completely built, use the sort command to manually sort the
+final tag file, or let the final invocation of ctags sort the file.
+
+  ----------------------------------------------------------------------
+14.  How do I get regex support for Win32?
+
+You need to download the GNU regex package for Win32 from the following
+location:
+
+    http://people.delphiforums.com/gjc/gnu_regex.html
+
+Then point the makefile macro, REGEX_DIR, found in mk_mvc.mak and mk_bc5.mak,
+to the directory created by extracting this archive.
+
+  ----------------------------------------------------------------------
+15.  How should I set up tag files for a multi-level directory hierarchy?
+
+There are a few ways of approaching this:
+
+1.  A local tag file in each directory containing only the tags for source
+    files in that directory.
+
+2.  One single big, global tag file present in the root directory of your
+    hierarchy, containing all tags present in all source files in the
+    hierarchy.
+
+3.  A local tag file in each directory containing only the tags for source
+    files in that directory, in addition to one single global tag file
+    present in the root directory of your hierarchy, containing all
+    non-static tags present in all source files in the hierarchy.
+
+4.  A local tag file in each directory of the hierarchy, each one
+    containing all tags present in source files in that directory and all
+    non-static tags in every directory below it (note that this implies
+    also having one big tag file in the root directory of the hierarchy).
+
+Each of these approaches has its own set of advantages and disadvantages,
+depending upon your particular conditions. Which approach is deemed best
+depends upon the following factors:
+
+A.  The ability of your editor to use multiple tag files.
+
+    If your editor cannot make use of multiple tag files (original vi
+    implementations could not), then one large tag file is the only way to
+    go if you ever desire to jump to tags located in other directories. If
+    you never need to jump to tags in another directory (i.e. the source
+    in each directory is entirely self-contained), then a local tag file
+    in each directory will fit your needs.
+
+B.  The time is takes for your editor to look up a tag in the tag file.
+
+    The significance of this factor depends upon the size of your source
+    tree and on whether the source files are located on a local or remote
+    file system. For source and tag files located on a local file system,
+    looking up a tag is not as big a hit as one might first imagine, since
+    vi implementations typically perform a binary search on a sorted tag
+    file. This may or may not be true for the editor you use. For files
+    located on a remote file system, reading a large file is an expensive
+    operation.
+
+C.  Whether or not you expect the source code to change and the time it
+    takes to rebuild a tag file to account for changes to the source code.
+
+    While Exuberant Ctags is particularly fast in scanning source code
+    (around 1-2 MB/sec), a large project may still result in objectionable
+    delays if one wishes to keep their tag file(s) up to date on a
+    frequent basis, or if the files are located on a remote file system.
+
+D.  The presence of duplicate tags in the source code and the ability to
+    handle them.
+
+    The impact of this factor is influenced by the following three issues:
+
+    1.  How common are duplicate tags in your project?
+
+    2.  Does your editor provide any facilities for dealing with duplicate
+        tags?
+
+        While standard vi does not, many modern vi implementations, such
+        as Vim have good facilities for selecting the desired match from
+        the list of duplicates. If your editor does not support duplicate
+        tags, then it will typically send you to only one of them, whether
+        or not that is the one you wanted (and not even notifying you that
+        there are other potential matches).
+
+    3.  What is the significance of duplicate tags?
+
+        For example, if you have two tags of the same name from entirely
+        isolated software components, jumping first to the match found
+        in component B while working in component A may be entirely
+        misleading, distracting or inconvenient (to keep having to choose
+        which one if your editor provides you with a list of matches).
+        However, if you have two tags of the same name for parallel builds
+        (say two initialization routines for different hosts), you may
+        always want to specify which one you want.
+
+Of the approaches listed above, I tend to favor Approach 3. My editor of
+choice is Vim, which provides a rich set of features for handling multiple
+tag files, which partly influences my choice. If you are working with
+source files on a remote file system, then I would recommend either
+Approach 3 or Approach 4, depending upon the hit when reading the global
+tag file.
+
+The advantages of Approach 3 are many (assuming that your editor has
+the ability to support both multiple tag files and duplicate tags). All
+lookups of tag located in the currect directory are fast and the local
+tag file can be quickly and easily regenerated in one second or less
+(I have even mapped a keystroke to do this easily). A lookup of a
+(necessarily non-static) tag found in another directory fails a lookup in
+the local tag file, but is found in the global tag file, which satisfies
+all cross-directory lookups. The global tag file can be automatically
+regenerated periodically with a cron job (and perhaps the local tag files
+also).
+
+Now I give an example of how you would implement Approach 3. Means of
+implementing the other approaches can be performed in a similar manner.
+
+Here is a visual representation of an example directory hierarchy:
+
+project
+  `-----misccomp
+  |       `...
+  `-----sysint
+          `-----client
+          |       `-----hdrs
+          |       `-----lib
+          |       `-----src
+          |       `-----test
+          `-----common
+          |       `-----hdrs
+          |       `-----lib
+          |       `-----src
+          |       `-----test
+          `-----server
+                  `-----hdrs
+                  `-----lib
+                  `-----src
+                  `-----test
+
+Here is a recommended solution (conceptually) to build the tag files:
+
+1.  Within each of the leaf nodes (i.e. hdrs, lib, src, test) build a tag
+    file using "ctags *.[ch]". This can be easily be done for the whole
+    hierarchy by making a shell script, call it "dirtags", containing the
+    following lines:
+
+        #!/bin/sh
+	cd $1
+	ctags *
+
+    Now execute the following command:
+
+        find * -type d -exec dirtags {} \;
+
+    These tag files are trivial (and extremely quick) to rebuild while
+    making changes within a directory. The following Vim key mapping is
+    quite useful to rebuild the tag file in the directory of the current
+    source file:
+
+        :nmap ,t :!(cd %:p:h;ctags *.[ch])&<CR><CR>
+
+2.  Build the global tag file:
+
+        cd ~/project
+        ctags --file-scope=no -R
+
+    thus constructing a tag file containing only non-static tags for all
+    source files in all descendent directories.
+
+3.  Configure your editor to read the local tag file first, then consult
+    the global tag file when not found in the local tag file. In Vim,
+    this is done as follows:
+
+        :set tags=./tags,tags,~/project/tags
+
+If you wish to implement Approach 4, you would need to replace the
+"dirtags" script of step 1 with the following:
+
+        #!/bin/sh
+	cd $1
+	ctags *
+	# Now append the non-static tags from descendent directories
+	find * -type d -prune -print | ctags -aR --file-scope=no -L-
+
+And replace the configuration of step 3 with this:
+
+        :set tags=./tags,./../tags,./../../tags,./../../../tags,tags
+
+As a caveat, it should be noted that step 2 builds a global tag file whose
+file names will be relative to the directory in which the global tag file
+is being built. This takes advantage of the Vim 'tagrelative' option,
+which causes the path to be interpreted a relative to the location of the
+tag file instead of the current directory. For standard vi, which always
+interprets the paths as relative to the current directory, we need to
+build the global tag file with absolute path names. This can be
+accomplished by replacing step 2 with the following:
+
+        cd ~/project
+	ctags --file-scope=no -R `pwd`
+
+--

data/ext/vendor/exuberant-ctags/INSTALL

@@ -0,0 +1,215 @@
+Custom Installation
+===================
+
+These installation instructions are for Unix or Unix-like platforms (or at
+least, those platforms which are able to run a Bourne shell script). If you
+are attempting to install Exuberant Ctags on some other platform, see the file
+INSTALL.oth.
+
+If you are not familiar with using the configure scripts generated by GNU
+autoconf, read the "Basic Installation" section below; then return here.
+The configure script in this package supports the following custom options:
+
+  --disable-etags               By default, "make install" will install one
+                                binary, "ctags", one man page, "ctags.1", and
+                                create links to these two files by the names
+                                "etags" and "etags.1". If you do not want to
+                                install the "etags" links, use this option.
+
+  --disable-extended-format     Ctags now appends "extension flags" to the
+                                end of each tag entry in a manner which is
+                                backwards with original Vi implementation
+                                (they are placed into an EX comment). This
+                                can be disabled via use of the ctags --format
+                                option. This configure option changes the
+                                default behavior of ctags to disable use of
+                                these extension flags (i.e. use the original
+                                tag file format).
+
+  --disable-external-sort       Use this option to force use of an internal
+                                sort algorithm. On UNIX-like systems, ctags
+                                uses the sort utility of the operating system
+                                by default because it is more memory efficient.
+
+  --enable-custom-config=FILE   Defines a custom option configuration file to
+                                establish site-wide defaults. Ctags will read
+                                the following files at startup for options:
+                                /etc/ctags.conf, /usr/local/etc/ctags.conf,
+                                $HOME/.ctags, and .ctags. If you need a
+                                different file, set this option to the full
+                                path name of the file you want to be read, and
+                                it will be read immediately before reading
+                                $HOME/.ctags.
+
+  --enable-macro-patterns       By default, line numbers are used in the tag
+                                file for #define objects, in order to remain
+                                compatible with the original UNIX ctags. This
+                                option will make the default use patterns.
+
+  --enable-maintainer-mode      Creates a special GNU-specific version of the
+                                makefile which is used to maintain Exuberant
+                                Ctags.
+
+  --enable-tmpdir=DIR           When the library function mkstemp() is
+                                available, this option allows specifying the
+                                default directory to use for temporary files
+                                generated by ctags. This default can be
+                                changed at run time by setting the environment
+                                variable TMPDIR.
+
+If you wish to change the name of the installed files, edit the makefile
+produced by the configure script ("Makefile") before performing the "make
+install" step. There are two lines at the top of the file where the names of
+the installed files may be customized.
+
+
+Basic Installation
+==================
+
+   These are generic installation instructions.
+
+   The `configure' shell script attempts to guess correct values for
+various system-dependent variables used during compilation.  It uses
+those values to create a `Makefile' in each directory of the package.
+It may also create one or more `.h' files containing system-dependent
+definitions.  Finally, it creates a shell script `config.status' that
+you can run in the future to recreate the current configuration, a file
+`config.cache' that saves the results of its tests to speed up
+reconfiguring, and a file `config.log' containing compiler output
+(useful mainly for debugging `configure').
+
+   If you need to do unusual things to compile the package, please try
+to figure out how `configure' could check whether to do them, and mail
+diffs or instructions to the address given in the `README' so they can
+be considered for the next release.  If at some point `config.cache'
+contains results you don't want to keep, you may remove or edit it.
+
+   The file `configure.in' is used to create `configure' by a program
+called `autoconf'.  You only need `configure.in' if you want to change
+it or regenerate `configure' using a newer version of `autoconf'.
+
+The simplest way to compile this package is:
+
+  1. `cd' to the directory containing the package's source code and type
+     `./configure' to configure the package for your system.  If you're
+     using `csh' on an old version of System V, you might need to type
+     `sh ./configure' instead to prevent `csh' from trying to execute
+     `configure' itself.
+
+     Running `configure' takes awhile.  While running, it prints some
+     messages telling which features it is checking for.
+
+  2. Type `make' to compile the package.
+
+  3. Optionally, type `make check' to run any self-tests that come with
+     the package.
+
+  4. Type `make install' to install the programs and any data files and
+     documentation.
+
+  5. You can remove the program binaries and object files from the
+     source code directory by typing `make clean'.  To also remove the
+     files that `configure' created (so you can compile the package for
+     a different kind of computer), type `make distclean'.
+
+Compilers and Options
+=====================
+
+   Some systems require unusual options for compilation or linking that
+the `configure' script does not know about.  You can give `configure'
+initial values for variables by setting them in the environment.  Using
+a Bourne-compatible shell, you can do that on the command line like
+this:
+     CC=c89 CFLAGS=-O2 LIBS=-lposix ./configure
+
+Or on systems that have the `env' program, you can do it like this:
+     env CPPFLAGS=-I/usr/local/include LDFLAGS=-s ./configure
+
+Compiling For Multiple Architectures
+====================================
+
+   You can compile the package for more than one kind of computer at the
+same time, by placing the object files for each architecture in their
+own directory.  To do this, you must use a version of `make' that
+supports the `VPATH' variable, such as GNU `make'.  `cd' to the
+directory where you want the object files and executables to go and run
+the `configure' script.  `configure' automatically checks for the
+source code in the directory that `configure' is in and in `..'.
+
+   If you have to use a `make' that does not supports the `VPATH'
+variable, you have to compile the package for one architecture at a time
+in the source code directory.  After you have installed the package for
+one architecture, use `make distclean' before reconfiguring for another
+architecture.
+
+Installation Names
+==================
+
+   By default, `make install' will install the package's files in
+`/usr/local/bin', `/usr/local/man', etc.  You can specify an
+installation prefix other than `/usr/local' by giving `configure' the
+option `--prefix=PATH'.
+
+   You can specify separate installation prefixes for
+architecture-specific files and architecture-independent files.  If you
+give `configure' the option `--exec-prefix=PATH', the package will use
+PATH as the prefix for installing programs and libraries.
+Documentation and other data files will still use the regular prefix.
+
+   In addition, if you use an unusual directory layout you can give
+options like `--bindir=PATH' to specify different values for particular
+kinds of files.  Run `configure --help' for a list of the directories
+you can set and what kinds of files go in them.
+
+Optional Features
+=================
+
+   Some packages pay attention to `--enable-FEATURE' options to
+`configure', where FEATURE indicates an optional part of the package.
+They may also pay attention to `--with-PACKAGE' options, where PACKAGE
+is something like `gnu-as' or `x' (for the X Window System).  The
+`README' should mention any `--enable-' and `--with-' options that the
+package recognizes.
+
+Sharing Defaults
+================
+
+   If you want to set default values for `configure' scripts to share,
+you can create a site shell script called `config.site' that gives
+default values for variables like `CC', `cache_file', and `prefix'.
+`configure' looks for `PREFIX/share/config.site' if it exists, then
+`PREFIX/etc/config.site' if it exists.  Or, you can set the
+`CONFIG_SITE' environment variable to the location of the site script.
+A warning: not all `configure' scripts look for a site script.
+
+Operation Controls
+==================
+
+   `configure' recognizes the following options to control how it
+operates.
+
+`--cache-file=FILE'
+     Use and save the results of the tests in FILE instead of
+     `./config.cache'.  Set FILE to `/dev/null' to disable caching, for
+     debugging `configure'.
+
+`--help'
+     Print a summary of the options to `configure', and exit.
+
+`--quiet'
+`--silent'
+`-q'
+     Do not print messages saying which checks are being made.  To
+     suppress all normal output, redirect it to `/dev/null' (any error
+     messages will still be shown).
+
+`--srcdir=DIR'
+     Look for the package's source code in directory DIR.  Usually
+     `configure' can determine that directory automatically.
+
+`--version'
+     Print the version of Autoconf used to generate the `configure'
+     script, and exit.
+
+`configure' also accepts some other, not widely useful, options.
+

data/ext/vendor/exuberant-ctags/INSTALL.oth

@@ -0,0 +1,73 @@
+If you are attempting to install Exuberant Ctags on a Unix-like platform
+(one that can at least run a Bourne shell script) see the file INSTALL.
+
+Installation Notes
+==================
+
+For non-Unix platforms, simple makefiles are provided:
+
+    descrip.mms   For VMS using either DEC C or VAX C
+    mk_bc3.mak    For MSDOS using Borland C/C++ 3.x
+    mk_bc5.mak    For Win32 using Borland C++ 5.5
+    mk_djg.mak    For MSDOS using DJGPP Gnu GCC (better to follow Unix install)
+    mk_manx.mak   For Amiga using Aztec/Manx C 5.0
+    mk_mingw.mak  For Win32 using MinGW
+    mk_mpw.mak    For Macintosh using MPW
+    mk_mvc.mak    For Win32 using Microsoft Visual C++
+    mk_os2.mak    For OS/2 using GCC (EMX)
+    mk_qdos.mak   For QDOS using C68
+    mk_riscos.mak For RISC OS using the GCC SDK <http://hard-mofo.dsvr.net>
+    mk_sas.mak    For Amiga using SAS/C
+
+
+Special Notes
+=============
+
+DJGPP:
+------
+
+  It is better to follow the standard Unix install on DJGPP, but this requires
+  that you use BASH and requires a fairly complete installation of GJGPP
+  packages. You can use mk_djg.mak if you can't run configure.
+
+Macintosh with MPW:
+-------------------
+
+  To build Ctags on MPW you will have to have the Metrowerks compilers
+  or you will have to edit the makefiles yourself.
+  
+  Since the makefile for MPW is called mk_mpw.mak you will have to give
+  the command: `Make -f mk_mpw.mak CTags` and then select the output
+  and execute it. Alternatively you could rename this makefile to
+  CTags.make and issue the command `Build CTags`.
+  
+  If the build process goes wrong make sure the line endings for the
+  makefile are set to MacOS (CR instead of LF).
+
+  This version of Ctags only accepts and emits unix style paths. This was
+  done since it was easier to implement (few changes in main source files)
+  and since I ported Ctags to MPW to use with Pepper which also works with
+  unix style paths internally. Besides, since we're now moving to MacOS X
+  anyway, Mac programmers are getting used to unix style paths anyway.
+  
+  Example, suppose you have a project using PowerPlant which is located in
+  'HD20:tools:PowerPlant:' and you want a tags file for all powerplant
+  sources and your projects sources. Go to the root directory of your
+  project and type:
+
+    CTags -R . '/HD20/tools/PowerPlant/'
+
+  The '.' in this command means current directory. You will also have to
+  put quotes around the full unix style path since / has a special meaning
+  in MPW.
+  
+RISC OS:
+--------
+
+  Regex support on RISC OS is available when compiled to use the RISC OS port
+  of the GNU regex library, which can be obtained from:
+ 
+    <http://www.sbellon.de/software.html>
+ 
+  Using 'Set RexEx$Path <Obey$Dir>.' in the regex-0/12 directory will ensure
+  it can be found.