GNU Flymake
***********

This manual is for GNU Flymake (version 0.3, April 2004), which is a
universal on-the-fly syntax checker for GNU Emacs.

   Copyright © 2004–2019 Free Software Foundation, Inc.

     Permission is granted to copy, distribute and/or modify this
     document under the terms of the GNU Free Documentation License,
     Version 1.3 or any later version published by the Free Software
     Foundation; with no Invariant Sections, with the Front-Cover Texts
     being “A GNU Manual,” and with the Back-Cover Texts as in (a)
     below.  A copy of the license is included in the section entitled
     “GNU Free Documentation License”.

     (a) The FSF’s Back-Cover Text is: “You have the freedom to copy and
     modify this GNU manual.”

1 Using Flymake
***************

Flymake is a universal on-the-fly buffer checker implemented as an Emacs
minor mode.  To use Flymake, you must first activate ‘flymake-mode’ by
using the command ‘flymake-mode’.

   When enabled, Flymake collects information about problems in the
buffer, called “diagnostics”, from one or more different sources, or
“backends”, and then visually annotates the buffer by highlighting
problematic buffer regions with a special face.

   It also displays an overall buffer status in the mode line containing
totals for different types of diagnostics.

   Syntax check is done “on-the-fly”.  It is started whenever

   • ‘flymake-mode’ is started, unless ‘flymake-start-on-flymake-mode’
     is nil;

   • a newline character is added to the buffer, unless
     ‘flymake-start-syntax-check-on-newline’ is nil;

   • some changes were made to the buffer more than ‘0.5’ seconds ago
     (the delay is configurable in ‘flymake-no-changes-timeout’).

   Syntax check can also be started manually by typing the ‘M-x
flymake-start <RET>’ command.

   ‘flymake-goto-next-error’ and ‘flymake-goto-prev-error’ are commands
that allow easy navigation to the next/previous erroneous line,
respectively.  If might be a good idea to map them to ‘M-n’ and ‘M-p’ in
‘flymake-mode’, by adding to your init file:

     (define-key flymake-mode-map (kbd "M-n") 'flymake-goto-next-error)
     (define-key flymake-mode-map (kbd "M-p") 'flymake-goto-prev-error)

   Flymake is a universal syntax checker in the sense that it’s easily
extended to support new backends (see Extending Flymake).

   Historically, Flymake used to accept diagnostics from a single
backend, albeit a reasonably flexible one.

   This backend isn’t (yet) obsolete, and so is still available as a
fallback and active by default (see The legacy Proc backend).  It
works by selecting a syntax check tool from a preconfigured list
(compiler for C++ files, ‘perl’ for Perl files, etc.), and executing it
in the background, passing it a temporary file which is a copy of the
current buffer, and parsing the output for known error/warning message
patterns.

1.1 Syntax check statuses
=========================

When enabled, Flymake displays its status in the mode line, which
provides a visual summary of diagnostic collection.  It may also hint at
certain exceptional situations encountered when communicating with
backends.

   The following statuses are defined:

[NERRORS           Normal operation.  NERRORS and NWARNINGS are,
NWARNINGS ...]     respectively, the total number of errors and
                   warnings found during the last buffer check, for all
                   backends.  They may be followed by other totals for
                   other types of diagnostics
                   (see Flymake error types).

‘Wait’             Some Flymake backends haven’t reported since the
                   last time they where questioned.  It is reasonable
                   to assume that this is a temporary delay and Flymake
                   will resume normal operation soon.

‘!’                All the configured Flymake backends have disabled
                   themselves: Flymake cannot annotate the buffer and
                   action from the user is needed to investigate and
                   remedy the situation (see Backend exceptions).

‘?’                There are no applicable Flymake backends for this
                   buffer, thus Flymake cannot annotate it.  To fix
                   this, a user may look to extending Flymake and add a
                   new backend (see Extending Flymake).

1.2 Backend exceptions
======================

Some backends may take longer than others to respond or complete, and
some may decide to _disable_ themselves if they are not suitable for the
current buffer or encounter some unavoidable problem.  A disabled
backend is not tried again for future checks of the current buffer.

   The commands ‘flymake-reporting-backends’, ‘flymake-running-backends’
and ‘flymake-disabled-backends’ show the backends currently used and
those which are disabled.

   Toggling ‘flymake-mode’ off and on again, or invoking ‘flymake-start’
with a prefix argument is one way to reset the disabled backend list, so
that they will be tried again in the next check.

   Flymake also uses a simple logging facility for indicating important
points in the control flow.  The logging facility sends logging messages
to the ‘*Flymake log*’ buffer.  The information logged can be used for
resolving various problems related to Flymake.  For convenience, a
shortcut to this buffer can be found in Flymake’s menu, accessible from
the top menu bar or just left of the status indicator.

   Logging output is controlled by the Emacs ‘warning-minimum-log-level’
and ‘warning-minimum-level’ variables.

1.3 Customizable variables
==========================

This section summarizes customization variables used for the
configuration of the Flymake user interface.

‘flymake-no-changes-timeout’
     If any changes are made to the buffer, syntax check is
     automatically started after this many seconds, unless the user
     makes another change, which resets the timer.

‘flymake-start-syntax-check-on-newline’
     A boolean flag indicating whether to start syntax check immediately
     after a newline character is inserted into the buffer.

‘flymake-start-on-flymake-mode’
     A boolean flag indicating whether to start syntax check immediately
     after enabling ‘flymake-mode’.

‘flymake-error’
     A custom face for highlighting regions for which an error has been
     reported.

‘flymake-warning’
     A custom face for highlighting regions for which a warning has been
     reported.

‘flymake-note’
     A custom face for highlighting regions for which a note has been
     reported.

‘flymake-error-bitmap’
     A bitmap used in the fringe to mark lines for which an error has
     been reported.

‘flymake-warning-bitmap’
     A bitmap used in the fringe to mark lines for which a warning has
     been reported.

‘flymake-fringe-indicator-position’
     Which fringe (if any) should show the warning/error bitmaps.

‘flymake-wrap-around’
     If non-nil, moving to errors with ‘flymake-goto-next-error’ and
     ‘flymake-goto-prev-error’ wraps around buffer boundaries.

2 Extending Flymake
*******************

Flymake can primarily be extended in one of two ways:

  1. By changing the look and feel of the annotations produced by the
     different backends.

  2. By adding a new buffer-checking backend.

   The following sections discuss each approach in detail.

2.1 Customizing Flymake error types
===================================

The variable ‘flymake-diagnostic-types-alist’ is looked up by Flymake
every time an annotation for a diagnostic is created in the buffer.
Specifically, this variable holds a table of correspondence between
symbols designating diagnostic types and an additional sub-table of
properties pertaining to each diagnostic type.

   Both tables are laid out in association list (see
Association Lists (elisp)) format, and thus can be conveniently
accessed with the functions of the ‘assoc’ family.

   You can use any symbol-value association in the properties sub-table,
but some symbols have special meaning as to where and how Flymake
presents the diagnostic:

   • ‘bitmap’, an image displayed in the fringe according to
     ‘flymake-fringe-indicator-position’.  The value actually follows
     the syntax of ‘flymake-error-bitmap’ (see Customizable variables).
     It is overridden by any ‘before-string’ overlay
     property.

   • ‘severity’ is a non-negative integer specifying the diagnostic’s
     severity.  The higher the value, the more serious is the error.  If
     the overlay property ‘priority’ is not specified, ‘severity’ is
     used to set it and help sort overlapping overlays.

   • Every property pertaining to overlays (see Overlay Properties (elisp)),
     except ‘category’ and ‘evaporate’.  These properties
     are used to affect the appearance of Flymake annotations.

     As an example, here’s how to make errors (diagnostics of the type
     ‘:error’) stand out even more prominently in the buffer, by raising
     the characters using a ‘display’ overlay property.

          (push '(display . (raise 1.2))
                (cdr (assoc :error flymake-diagnostic-types-alist)))

   • ‘flymake-category’ is a symbol whose property list is considered
     the default for missing values of any other properties.

   Three default diagnostic types, ‘:error’, ‘:warning’ and ‘:note’ are
predefined in ‘flymake-diagnostic-types-alist’.  By default each lists a
single ‘flymake-category’ property whose value is, respectively, the
symbols ‘flymake-error’, ‘flymake-warning’ and ‘flymake-note’.

   These category symbols’ plists is where the values of customizable
variables and faces such as ‘flymake-error-bitmap’ are found.  Thus, if
you change their plists, Flymake may stop honoring these user
customizations.

   The ‘flymake-category’ special property is also especially useful for
backends which create diagnostics objects with non-default types that
differ from an existing type by only a few properties (see Flymake utility functions).

   As an example, consider configuring a new diagnostic type
‘:low-priority-note’ that behaves much like the ‘:note’ priority but
without an overlay face.

     (add-to-list
      'flymake-diagnostic-types-alist
      `(:low-priority-note . ((face . nil)
                              (flymake-category . flymake-note))))

   As you might have guessed, Flymake’s annotations are implemented as
overlays (see Overlays (elisp)).  Along with the properties that you
specify for the specific type of diagnostic, Flymake adds the property
‘flymake-diagnostic’ to these overlays, and sets it to the object that
the backend created with ‘flymake-make-diagnostic’.

   Since overlays also support arbitrary keymaps, you can use this along
with the functions ‘flymake-diagnostics’ and ‘flymake-diagnostic-text’
(see Flymake utility functions) to create interactive annotations,
such as in the following example of binding a ‘mouse-3’ event (middle
mouse button click) to an Internet search for the text of a ‘:warning’
or ‘:error’.

     (defun my-search-for-message (event)
       (interactive "e")
       (let* ((diags (flymake-diagnostics (posn-point (event-start event))))
              (topmost-diag (car diags)))
         (eww-browse-url
            (concat
             "https://duckduckgo.com/?q="
             (replace-regexp-in-string " "
                                       "+"
                                       (flymake-diagnostic-text topmost-diag)))
            t)))

     (dolist (type '(:warning :error))
       (let ((a (assoc type flymake-diagnostic-types-alist)))
         (setf (cdr a)
               (append `((mouse-face . highlight)
                         (keymap . ,(let ((map (make-sparse-keymap)))
                                      (define-key map [mouse-2]
                                        'my-search-for-message)
                                      map)))
                       (cdr a)))))

2.2 Backend functions
=====================

Flymake backends are Lisp functions placed in the special hook
‘flymake-diagnostic-functions’.

   A backend’s responsibility is to diagnose the contents of a buffer
for problems, registering the problem’s positions, type, and summary
description.  This information is collected in the form of diagnostic
objects created by the function ‘flymake-make-diagnostic’ (see Flymake utility functions),
and then handed over to Flymake, which proceeds to
annotate the buffer.

   A request for a buffer check, and the subsequent delivery of
diagnostics, are two key events of the interaction between Flymake and
backend.  Each such event corresponds to a well-defined function calling
convention: one for calls made by Flymake into the backend via the
backend function, the other in the reverse direction via a callback.  To
be usable, backends must adhere to both.

   Backend functions must accept an arbitrary number of arguments:

   • the first argument is always REPORT-FN, a callback function
     detailed below;

   • the remaining arguments are keyword-value pairs of the form
     ‘(:KEY VALUE :KEY2 VALUE2...)’.  Currently, Flymake provides no
     such arguments, but backend functions must be prepared to accept
     (and possibly ignore) any number of them.

   Whenever Flymake or the user decide to re-check the buffer, backend
functions are called as detailed above, and are expected to initiate
this check, but aren’t in any way required to complete it before
exiting: if the computation involved is expensive, as is often the case
with large buffers, that slower task should be scheduled for the future
using asynchronous sub-processes (see Asynchronous Processes (elisp))
or other asynchronous mechanisms.

   In any case, backend functions are expected to return quickly or
signal an error, in which case the backend is disabled (see Backend exceptions).

   If the function returns, Flymake considers the backend to be
“running”.  If it has not done so already, the backend is expected to
call the function REPORT-FN passed to it, at which point Flymake
considers the backend to be “reporting”.  Backends call REPORT-FN by
passing it a single argument REPORT-ACTION followed by an optional list
of keyword-value pairs of the form
‘(:REPORT-KEY VALUE :REPORT-KEY2 VALUE2...)’.

   Currently accepted values for REPORT-ACTION are:

   • A (possibly empty) list of diagnostic objects created by
     ‘flymake-make-diagnostic’, causing Flymake to annotate the buffer
     with this information.

     A backend may call REPORT-FN repeatedly in this manner, but only
     until Flymake considers that the most recently requested buffer
     check is now obsolete, because, say, buffer contents have changed
     in the meantime.  The backend is only given notice of this via a
     renewed call to the backend function.  Thus, to prevent making
     obsolete reports and wasting resources, backend functions should
     first cancel any ongoing processing from previous calls.

   • The symbol ‘:panic’, signaling that the backend has encountered an
     exceptional situation and should be disabled.

   Currently accepted REPORT-KEY arguments are:

   • ‘:explanation’, whose value should give user-readable details of
     the situation encountered, if any.

   • ‘:force’, whose value should be a boolean suggesting that Flymake
     consider the report even if it was somehow unexpected.

2.2.1 Flymake utility functions
-------------------------------

Before delivering them to Flymake, backends create diagnostic objects by
calling the function ‘flymake-make-diagnostic’.

 -- Function: flymake-make-diagnostic buffer beg end type text
     Make a Flymake diagnostic for BUFFER’s region from BEG to END.
     TYPE is a key to ‘flymake-diagnostic-types-alist’ and TEXT is a
     description of the problem detected in this region.

   These objects’ properties can be accessed with the functions
‘flymake-diagnostic-backend’, ‘flymake-diagnostic-buffer’,
‘flymake-diagnostic-text’, ‘flymake-diagnostic-beg’,
‘flymake-diagnostic-end’ and ‘flymake-diagnostic-type’.

   Additionally, the function ‘flymake-diagnostics’ will collect such
objects in the region you specify.

 -- Function: flymake-diagnostics beg end
     Get a list of Flymake diagnostics in the region determined by BEG
     and END.  If neither BEG or END is supplied, use the whole buffer,
     otherwise if BEG is non-‘nil’ and END is ‘nil’, consider only
     diagnostics at BEG.

   It is often the case with external syntax tools that a diagnostic’s
position is reported in terms of a line number, and sometimes a column
number.  To convert this information into a buffer position, backends
can use the following function:

 -- Function: flymake-diag-region buffer line &optional col
     Compute BUFFER’s region (BEG .  END) corresponding to LINE and COL.
     If COL is ‘nil’, return a region just for LINE.  Return ‘nil’ if
     the region is invalid.

   For troubleshooting purposes, backends may record arbitrary
exceptional or erroneous situations into the Flymake log buffer (see
Backend exceptions):

 -- Macro: flymake-log level msg &optional args
     Log, at level LEVEL, the message MSG formatted with ARGS.  LEVEL is
     passed to ‘display-warning’ (see Warning Basics (elisp)), which
     is used to display the warning in Flymake’s log buffer.

2.2.2 An annotated example backend
----------------------------------

This section presents an annotated example of a complete working Flymake
backend.  The example illustrates the process of writing a backend as
outlined above.

   The backend in question is used for checking Ruby source files.  It
uses asynchronous sub-processes (see Asynchronous Processes (elisp)),
a common technique for performing parallel processing in Emacs.

   The following code needs lexical binding (see Using Lexical Binding (elisp))
to be active.

     ;;; ruby-flymake.el --- A ruby Flymake backend  -*- lexical-binding: t; -*-
     (defvar-local ruby--flymake-proc nil)

     (defun ruby-flymake (report-fn &rest _args)
       ;; Not having a ruby interpreter is a serious problem which should cause
       ;; the backend to disable itself, so an error is signaled.
       ;;
       (unless (executable-find
                "ruby") (error "Cannot find a suitable ruby"))
       ;; If a live process launched in an earlier check was found, that
       ;; process is killed.  When that process's sentinel eventually runs,
       ;; it will notice its obsoletion, since it have since reset
       ;; `ruby-flymake-proc' to a different value
       ;;
       (when (process-live-p ruby--flymake-proc)
         (kill-process ruby--flymake-proc))

       ;; Save the current buffer, the narrowing restriction, remove any
       ;; narrowing restriction.
       ;;
       (let ((source (current-buffer)))
         (save-restriction
           (widen)
           ;; Reset the `ruby--flymake-proc' process to a new process
           ;; calling the ruby tool.
           ;;
           (setq
            ruby--flymake-proc
            (make-process
             :name "ruby-flymake" :noquery t :connection-type 'pipe
             ;; Make output go to a temporary buffer.
             ;;
             :buffer (generate-new-buffer " *ruby-flymake*")
             :command '("ruby" "-w" "-c")
             :sentinel
             (lambda (proc _event)
               ;; Check that the process has indeed exited, as it might
               ;; be simply suspended.
               ;;
               (when (eq 'exit (process-status proc))
                 (unwind-protect
                     ;; Only proceed if `proc' is the same as
                     ;; `ruby--flymake-proc', which indicates that
                     ;; `proc' is not an obsolete process.
                     ;;
                     (if (with-current-buffer source (eq proc ruby--flymake-proc))
                         (with-current-buffer (process-buffer proc)
                           (goto-char (point-min))
                           ;; Parse the output buffer for diagnostic's
                           ;; messages and locations, collect them in a list
                           ;; of objects, and call `report-fn'.
                           ;;
                           (cl-loop
                            while (search-forward-regexp
                                   "^\\(?:.*.rb\\|-\\):\\([0-9]+\\): \\(.*\\)$"
                                   nil t)
                            for msg = (match-string 2)
                            for (beg . end) = (flymake-diag-region
                                               source
                                               (string-to-number (match-string 1)))
                            for type = (if (string-match "^warning" msg)
                                           :warning
                                         :error)
                            collect (flymake-make-diagnostic source
                                                             beg
                                                             end
                                                             type
                                                             msg)
                            into diags
                            finally (funcall report-fn diags)))
                       (flymake-log :warning "Canceling obsolete check %s"
                                    proc))
                   ;; Cleanup the temporary buffer used to hold the
                   ;; check's output.
                   ;;
                   (kill-buffer (process-buffer proc)))))))
           ;; Send the buffer contents to the process's stdin, followed by
           ;; an EOF.
           ;;
           (process-send-region ruby--flymake-proc (point-min) (point-max))
           (process-send-eof ruby--flymake-proc))))

     (defun ruby-setup-flymake-backend ()
       (add-hook 'flymake-diagnostic-functions 'ruby-flymake nil t))

     (add-hook 'ruby-mode-hook 'ruby-setup-flymake-backend)

3 The legacy “Proc” backend
***************************

The backend ‘flymake-proc-legacy-backend’ was originally designed to be
extended for supporting new syntax check tools and error message
patterns.  It is also controlled by its own set of customization
variables

3.1 Customization variables for the Proc backend
================================================

‘flymake-proc-allowed-file-name-masks’
     A list of ‘(filename-regexp, init-function, cleanup-function
     getfname-function)’ for configuring syntax check tools.  See
     Adding support for a new syntax check tool.

‘flymake-proc-master-file-dirs’
     A list of directories for searching a master file.  See Locating a master file.

‘flymake-proc-get-project-include-dirs-function’
     A function used for obtaining a list of project include dirs (C/C++
     specific).  See Getting the include directories.

‘flymake-proc-master-file-count-limit’
‘flymake-proc-check-file-limit’
     Used when looking for a master file.  See Locating a master file.

‘flymake-proc-err-line-patterns’
     Patterns for error/warning messages in the form ‘(regexp file-idx
     line-idx col-idx err-text-idx)’.  See Parsing the output.

‘flymake-proc-diagnostic-type-pred’
     A function to classify a diagnostic text as particular type of
     error.  Should be a function taking an error text and returning one
     of the symbols indexing ‘flymake-diagnostic-types-alist’.  If
     non-nil is returned but there is no such symbol in that table, a
     warning is assumed.  If nil is returned, an error is assumed.  Can
     also be a regular expression that should match only warnings.  This
     variable replaces the old ‘flymake-warning-re’ and
     ‘flymake-warning-predicate’.

‘flymake-proc-compilation-prevents-syntax-check’
     A flag indicating whether compilation and syntax check of the same
     file cannot be run simultaneously.  See Interaction with other modes.

3.2 Adding support for a new syntax check tool
==============================================

Syntax check tools are configured using the
‘flymake-proc-allowed-file-name-masks’ list.  Each item of this list has
the following format:

     (filename-regexp, init-function, cleanup-function, getfname-function)

‘filename-regexp’
     This field is used as a key for locating init/cleanup/getfname
     functions for the buffer.  Items in
     ‘flymake-proc-allowed-file-name-masks’ are searched sequentially.
     The first item with ‘filename-regexp’ matching buffer filename is
     selected.  If no match is found, ‘flymake-mode’ is switched off.

‘init-function’
     ‘init-function’ is required to initialize the syntax check, usually
     by creating a temporary copy of the buffer contents.  The function
     must return ‘(list cmd-name arg-list)’.  If ‘init-function’ returns
     null, syntax check is aborted, but ‘flymake-mode’ is not switched
     off.

‘cleanup-function’
     ‘cleanup-function’ is called after the syntax check process is
     complete and should take care of proper deinitialization, which is
     usually deleting a temporary copy created by the ‘init-function’.

‘getfname-function’
     This function is used for translating filenames reported by the
     syntax check tool into “real” filenames.  Filenames reported by the
     tool will be different from the real ones, as actually the tool
     works with the temporary copy.  In most cases, the default
     implementation provided by Flymake,
     ‘flymake-proc-get-real-file-name’, can be used as
     ‘getfname-function’.

   To add support for a new syntax check tool, write the corresponding
‘init-function’ and, optionally, ‘cleanup-function’ and
‘getfname-function’.  If the format of error messages reported by the
new tool is not yet supported by Flymake, add a new entry to the
‘flymake-proc-err-line-patterns’ list.

   The following sections contain some examples of configuring Flymake
support for various syntax check tools.

3.2.1 Example—Configuring a tool called directly
------------------------------------------------

In this example, we will add support for ‘perl’ as a syntax check tool.
‘perl’ supports the ‘-c’ option which does syntax checking.

   First, we write the ‘init-function’:

     (defun flymake-proc-perl-init ()
       (let* ((temp-file (flymake-proc-init-create-temp-buffer-copy
                          'flymake-proc-create-temp-inplace))
              (local-file (file-relative-name
                           temp-file
                           (file-name-directory buffer-file-name))))
         (list "perl" (list "-wc " local-file))))

   ‘flymake-proc-perl-init’ creates a temporary copy of the buffer
contents with the help of ‘flymake-proc-init-create-temp-buffer-copy’,
and builds an appropriate command line.

   Next, we add a new entry to the
‘flymake-proc-allowed-file-name-masks’:

     (setq flymake-proc-allowed-file-name-masks
           (cons '(".+\\.pl$"
                   flymake-proc-perl-init
                   flymake-proc-simple-cleanup
                   flymake-proc-get-real-file-name)
                 flymake-proc-allowed-file-name-masks))

   Note that we use standard ‘cleanup-function’ and ‘getfname-function’.

   Finally, we add an entry to ‘flymake-proc-err-line-patterns’:

     (setq flymake-proc-err-line-patterns
           (cons '("\\(.*\\) at \\([^ \n]+\\) line \\([0-9]+\\)[,.\n]"
                   2 3 nil 1)
                 flymake-proc-err-line-patterns))

3.2.2 Example—Configuring a tool called via make
------------------------------------------------

In this example we will add support for C files syntax checked by ‘gcc’
called via ‘make’.

   We’re not required to write any new functions, as Flymake already has
functions for ‘make’.  We just add a new entry to the
‘flymake-proc-allowed-file-name-masks’:

     (setq flymake-proc-allowed-file-name-masks
           (cons '(".+\\.c$"
                   flymake-proc-simple-make-init
                   flymake-proc-simple-cleanup
                   flymake-proc-get-real-file-name)
                 flymake-proc-allowed-file-name-masks))

   ‘flymake-proc-simple-make-init’ builds the following ‘make’ command
line:

     (list "make"
           (list "-s" "-C"
                 base-dir
                 (concat "CHK_SOURCES=" source)
                 "SYNTAX_CHECK_MODE=1"
                 "check-syntax"))

   ‘base-dir’ is a directory containing the ‘Makefile’, see
Locating the buildfile.

   Thus, ‘Makefile’ must contain the ‘check-syntax’ target.  In our case
this target might look like this:

check-syntax:
	gcc -o /dev/null -S ${CHK_SOURCES} || true

The format of error messages reported by ‘gcc’ is already supported by
Flymake, so we don’t have to add a new entry to
‘flymake-err-line-patterns’.  Note that if you are using Automake, you
may want to replace ‘gcc’ with the standard Automake variable ‘COMPILE’:

check-syntax:
	$(COMPILE) -o /dev/null -S ${CHK_SOURCES} || true

3.3 Implementation overview
===========================

‘flymake-proc-legacy-backend’ saves a copy of the buffer in a temporary
file in the buffer’s directory (or in the system temporary directory,
for Java files), creates a syntax check command and launches a process
with this command.  The output is parsed using a list of error message
patterns, and error information (file name, line number, type and text)
is saved.  After the process has finished, Flymake highlights erroneous
lines in the buffer using the accumulated error information.

   Syntax check is considered possible if there’s an entry in
‘flymake-proc-allowed-file-name-masks’ matching buffer’s filename and
its ‘init-function’ returns non-‘nil’ value.

   Two syntax check modes are distinguished:

  1. Buffer can be syntax checked in a standalone fashion, that is, the
     file (its temporary copy, in fact) can be passed over to the
     compiler to do the syntax check.  Examples are C/C++ sources (‘.c’,
     ‘.cpp’) and Java (‘.java’).

  2. Buffer can be syntax checked, but additional file, called master
     file, is required to perform this operation.  A master file is a
     file that includes the current file, so that running a syntax check
     tool on it will also check syntax in the current file.  Examples
     are C/C++ headers (‘.h’, ‘.hpp’).

   These modes are handled inside init/cleanup/getfname functions, see
Adding support for a new syntax check tool.

   The Proc backend contains implementations of all functionality
required to support different syntax check modes described above (making
temporary copies, finding master files, etc.), as well as some
tool-specific (routines for Make, Ant, etc.) code.

3.4 Making a temporary copy
===========================

After the possibility of the syntax check has been determined, a
temporary copy of the current buffer is made so that the most recent
unsaved changes could be seen by the syntax check tool.  Making a copy
is quite straightforward in a standalone case (mode ‘1’), as it’s just
saving buffer contents to a temporary file.

   Things get trickier, however, when master file is involved, as it
requires to

   • locate a master file
   • patch it to include the current file using its new (temporary)
     name.

   Locating a master file is discussed in the following section.

   Patching just changes all appropriate lines of the master file so
that they use the new (temporary) name of the current file.  For
example, suppose current file name is ‘file.h’, the master file is
‘file.cpp’, and it includes current file via ‘#include "file.h"’.
Current file’s copy is saved to file ‘file_flymake.h’, so the include
line must be changed to ‘#include "file_flymake.h"’.  Finally, patched
master file is saved to ‘file_flymake_master.cpp’, and the last one is
passed to the syntax check tool.

3.5 Locating a master file
==========================

Master file is located in two steps.

   First, a list of possible master files is built.  A simple name
matching is used to find the files.  For a C++ header ‘file.h’, the Proc
backend searches for all ‘.cpp’ files in the directories whose relative
paths are stored in a customizable variable
‘flymake-proc-master-file-dirs’, which usually contains something like
‘("." "./src")’.  No more than ‘flymake-proc-master-file-count-limit’
entries is added to the master file list.  The list is then sorted to
move files with names ‘file.cpp’ to the top.

   Next, each master file in a list is checked to contain the
appropriate include directives.  No more than
‘flymake-proc-check-file-limit’ of each file are parsed.

   For ‘file.h’, the include directives to look for are ‘#include
"file.h"’, ‘#include "../file.h"’, etc.  Each include is checked against
a list of include directories (see Getting the include directories)
to be sure it points to the correct ‘file.h’.

   First matching master file found stops the search.  The master file
is then patched and saved to disk.  In case no master file is found,
syntax check is aborted, and corresponding status (‘!’) is reported in
the mode line.  See Syntax check statuses.

3.6 Getting the include directories
===================================

Two sets of include directories are distinguished: system include
directories and project include directories.  The former is just the
contents of the ‘INCLUDE’ environment variable.  The latter is not so
easy to obtain, and the way it can be obtained can vary greatly for
different projects.  Therefore, a customizable variable
‘flymake-proc-get-project-include-dirs-function’ is used to provide the
way to implement the desired behavior.

   The default implementation,
‘flymake-proc-get-project-include-dirs-imp’, uses a ‘make’ call.  This
requires a correct base directory, that is, a directory containing a
correct ‘Makefile’, to be determined.

   As obtaining the project include directories might be a costly
operation, its return value is cached in the hash table.  The cache is
cleared in the beginning of every syntax check attempt.

3.7 Locating the buildfile
==========================

The Proc backend can be configured to use different tools for performing
syntax checks.  For example, it can use direct compiler call to syntax
check a perl script or a call to ‘make’ for a more complicated case of a
C/C++ source.  The general idea is that simple files, like Perl scripts
and HTML pages, can be checked by directly invoking a corresponding
tool.  Files that are usually more complex and generally used as part of
larger projects, might require non-trivial options to be passed to the
syntax check tool, like include directories for C++.  The latter files
are syntax checked using some build tool, like Make or Ant.

   All Make configuration data is usually stored in a file called
‘Makefile’.  To allow for future extensions, Flymake uses a notion of
buildfile to reference the “project configuration” file.

   Special function, ‘flymake-proc-find-buildfile’ is provided for
locating buildfiles.  Searching for a buildfile is done in a manner
similar to that of searching for possible master files.  In case there’s
no build file, the syntax check is aborted.

   Buildfile values are also cached.

3.8 Starting the syntax check process
=====================================

The command line (command name and the list of arguments) for launching
a process is returned by the initialization function.  The Proc backend
then just starts an asynchronous process and configures a process filter
and sentinel, which are used for processing the output of the syntax
check tool.  When exiting Emacs, running processes will be killed
without prompting the user.

3.9 Parsing the output
======================

The output generated by the syntax check tool is parsed in the process
filter/sentinel using the error message patterns stored in the
‘flymake-proc-err-line-patterns’ variable.  This variable contains a
list of items of the form ‘(regexp file-idx line-idx err-text-idx)’,
used to determine whether a particular line is an error message and
extract file name, line number and error text, respectively.  Error type
(error/warning) is also guessed by matching error text with the
‘^[wW]arning’ pattern.  Anything that was not classified as a warning is
considered an error.  Type is then used to sort error menu items, which
shows error messages first.

   The Proc backend is also able to interpret error message patterns
missing err-text-idx information.  This is done by merely taking the
rest of the matched line (‘(substring line (match-end 0))’) as error
text.  This trick allows making use of a huge collection of error
message line patterns from ‘compile.el’.  All these error patterns are
appended to the end of ‘flymake-proc-err-line-patterns’.

   The error information obtained is saved in a buffer local variable.
The buffer for which the process output belongs is determined from the
process-id->buffer mapping updated after every process launch/exit.

3.10 Interaction with other modes
=================================

The only mode the Proc backend currently knows about is ‘compile’.

   The Proc backend can be configured to not start syntax check if it
thinks the compilation is in progress, by testing the
‘compilation-in-progress’ variable.  The reason why this might be useful
is saving CPU time in case both syntax check and compilation are very
CPU intensive.  The original reason for adding this feature, though, was
working around a locking problem with MS Visual C++ compiler.  The
variable in question is
‘flymake-proc-compilation-prevents-syntax-check’.

   The Proc backend also provides an alternative command for starting
compilation, ‘flymake-proc-compile’.  It just kills all the active
syntax check processes before calling ‘compile’.

Appendix A GNU Free Documentation License
*****************************************

                     Version 1.3, 3 November 2008

     Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
     <https://fsf.org/>

     Everyone is permitted to copy and distribute verbatim copies
     of this license document, but changing it is not allowed.

  0. PREAMBLE

     The purpose of this License is to make a manual, textbook, or other
     functional and useful document “free” in the sense of freedom: to
     assure everyone the effective freedom to copy and redistribute it,
     with or without modifying it, either commercially or
     noncommercially.  Secondarily, this License preserves for the
     author and publisher a way to get credit for their work, while not
     being considered responsible for modifications made by others.

     This License is a kind of “copyleft”, which means that derivative
     works of the document must themselves be free in the same sense.
     It complements the GNU General Public License, which is a copyleft
     license designed for free software.

     We have designed this License in order to use it for manuals for
     free software, because free software needs free documentation: a
     free program should come with manuals providing the same freedoms
     that the software does.  But this License is not limited to
     software manuals; it can be used for any textual work, regardless
     of subject matter or whether it is published as a printed book.  We
     recommend this License principally for works whose purpose is
     instruction or reference.

  1. APPLICABILITY AND DEFINITIONS

     This License applies to any manual or other work, in any medium,
     that contains a notice placed by the copyright holder saying it can
     be distributed under the terms of this License.  Such a notice
     grants a world-wide, royalty-free license, unlimited in duration,
     to use that work under the conditions stated herein.  The
     “Document”, below, refers to any such manual or work.  Any member
     of the public is a licensee, and is addressed as “you”.  You accept
     the license if you copy, modify or distribute the work in a way
     requiring permission under copyright law.

     A “Modified Version” of the Document means any work containing the
     Document or a portion of it, either copied verbatim, or with
     modifications and/or translated into another language.

     A “Secondary Section” is a named appendix or a front-matter section
     of the Document that deals exclusively with the relationship of the
     publishers or authors of the Document to the Document’s overall
     subject (or to related matters) and contains nothing that could
     fall directly within that overall subject.  (Thus, if the Document
     is in part a textbook of mathematics, a Secondary Section may not
     explain any mathematics.)  The relationship could be a matter of
     historical connection with the subject or with related matters, or
     of legal, commercial, philosophical, ethical or political position
     regarding them.

     The “Invariant Sections” are certain Secondary Sections whose
     titles are designated, as being those of Invariant Sections, in the
     notice that says that the Document is released under this License.
     If a section does not fit the above definition of Secondary then it
     is not allowed to be designated as Invariant.  The Document may
     contain zero Invariant Sections.  If the Document does not identify
     any Invariant Sections then there are none.

     The “Cover Texts” are certain short passages of text that are
     listed, as Front-Cover Texts or Back-Cover Texts, in the notice
     that says that the Document is released under this License.  A
     Front-Cover Text may be at most 5 words, and a Back-Cover Text may
     be at most 25 words.

     A “Transparent” copy of the Document means a machine-readable copy,
     represented in a format whose specification is available to the
     general public, that is suitable for revising the document
     straightforwardly with generic text editors or (for images composed
     of pixels) generic paint programs or (for drawings) some widely
     available drawing editor, and that is suitable for input to text
     formatters or for automatic translation to a variety of formats
     suitable for input to text formatters.  A copy made in an otherwise
     Transparent file format whose markup, or absence of markup, has
     been arranged to thwart or discourage subsequent modification by
     readers is not Transparent.  An image format is not Transparent if
     used for any substantial amount of text.  A copy that is not
     “Transparent” is called “Opaque”.

     Examples of suitable formats for Transparent copies include plain
     ASCII without markup, Texinfo input format, LaTeX input format,
     SGML or XML using a publicly available DTD, and standard-conforming
     simple HTML, PostScript or PDF designed for human modification.
     Examples of transparent image formats include PNG, XCF and JPG.
     Opaque formats include proprietary formats that can be read and
     edited only by proprietary word processors, SGML or XML for which
     the DTD and/or processing tools are not generally available, and
     the machine-generated HTML, PostScript or PDF produced by some word
     processors for output purposes only.

     The “Title Page” means, for a printed book, the title page itself,
     plus such following pages as are needed to hold, legibly, the
     material this License requires to appear in the title page.  For
     works in formats which do not have any title page as such, “Title
     Page” means the text near the most prominent appearance of the
     work’s title, preceding the beginning of the body of the text.

     The “publisher” means any person or entity that distributes copies
     of the Document to the public.

     A section “Entitled XYZ” means a named subunit of the Document
     whose title either is precisely XYZ or contains XYZ in parentheses
     following text that translates XYZ in another language.  (Here XYZ
     stands for a specific section name mentioned below, such as
     “Acknowledgements”, “Dedications”, “Endorsements”, or “History”.)
     To “Preserve the Title” of such a section when you modify the
     Document means that it remains a section “Entitled XYZ” according
     to this definition.

     The Document may include Warranty Disclaimers next to the notice
     which states that this License applies to the Document.  These
     Warranty Disclaimers are considered to be included by reference in
     this License, but only as regards disclaiming warranties: any other
     implication that these Warranty Disclaimers may have is void and
     has no effect on the meaning of this License.

  2. VERBATIM COPYING

     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.

  3. COPYING IN QUANTITY

     If you publish printed copies (or copies in media that commonly
     have printed covers) of the Document, numbering more than 100, and
     the Document’s license notice requires Cover Texts, you must
     enclose the copies in covers that carry, clearly and legibly, all
     these Cover Texts: Front-Cover Texts on the front cover, and
     Back-Cover Texts on the back cover.  Both covers must also clearly
     and legibly identify you as the publisher of these copies.  The
     front cover must present the full title with all words of the title
     equally prominent and visible.  You may add other material on the
     covers in addition.  Copying with changes limited to the covers, as
     long as they preserve the title of the Document and satisfy these
     conditions, can be treated as verbatim copying in other respects.

     If the required texts for either cover are too voluminous to fit
     legibly, you should put the first ones listed (as many as fit
     reasonably) on the actual cover, and continue the rest onto
     adjacent pages.

     If you publish or distribute Opaque copies of the Document
     numbering more than 100, you must either include a machine-readable
     Transparent copy along with each Opaque copy, or state in or with
     each Opaque copy a computer-network location from which the general
     network-using public has access to download using public-standard
     network protocols a complete Transparent copy of the Document, free
     of added material.  If you use the latter option, you must take
     reasonably prudent steps, when you begin distribution of Opaque
     copies in quantity, to ensure that this Transparent copy will
     remain thus accessible at the stated location until at least one
     year after the last time you distribute an Opaque copy (directly or
     through your agents or retailers) of that edition to the public.

     It is requested, but not required, that you contact the authors of
     the Document well before redistributing any large number of copies,
     to give them a chance to provide you with an updated version of the
     Document.

  4. MODIFICATIONS

     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 fewer than five), unless they release you
          from this requirement.

       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”, Preserve 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. For any section Entitled “Acknowledgements” or “Dedications”,
          Preserve the Title of the section, 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 to be Entitled
          “Endorsements” or to conflict in title with any Invariant
          Section.

       O. Preserve any Warranty Disclaimers.

     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.

  5. COMBINING DOCUMENTS

     You may combine the Document with other documents released under
     this License, under the terms defined in section 4 above for
     modified versions, provided that you include in the combination all
     of the Invariant Sections of all of the original documents,
     unmodified, and list them all as Invariant Sections of your
     combined work in its license notice, and that you preserve all
     their Warranty Disclaimers.

     The combined work need only contain one copy of this License, and
     multiple identical Invariant Sections may be replaced with a single
     copy.  If there are multiple Invariant Sections with the same name
     but different contents, make the title of each such section unique
     by adding at the end of it, in parentheses, the name of the
     original author or publisher of that section if known, or else a
     unique number.  Make the same adjustment to the section titles in
     the list of Invariant Sections in the license notice of the
     combined work.

     In the combination, you must combine any sections Entitled
     “History” in the various original documents, forming one section
     Entitled “History”; likewise combine any sections Entitled
     “Acknowledgements”, and any sections Entitled “Dedications”.  You
     must delete all sections Entitled “Endorsements.”

  6. COLLECTIONS OF DOCUMENTS

     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.

  7. AGGREGATION WITH INDEPENDENT WORKS

     A compilation of the Document or its derivatives with other
     separate and independent documents or works, in or on a volume of a
     storage or distribution medium, is called an “aggregate” if the
     copyright resulting from the compilation is not used to limit the
     legal rights of the compilation’s users beyond what the individual
     works permit.  When the Document is included in an aggregate, this
     License does not apply to the other works in the aggregate which
     are not themselves derivative works of the Document.

     If the Cover Text requirement of section 3 is applicable to these
     copies of the Document, then if the Document is less than one half
     of the entire aggregate, the Document’s Cover Texts may be placed
     on covers that bracket the Document within the aggregate, or the
     electronic equivalent of covers if the Document is in electronic
     form.  Otherwise they must appear on printed covers that bracket
     the whole aggregate.

  8. TRANSLATION

     Translation is considered a kind of modification, so you may
     distribute translations of the Document under the terms of section
     4.  Replacing Invariant Sections with translations requires special
     permission from their copyright holders, but you may include
     translations of some or all Invariant Sections in addition to the
     original versions of these Invariant Sections.  You may include a
     translation of this License, and all the license notices in the
     Document, and any Warranty Disclaimers, provided that you also
     include the original English version of this License and the
     original versions of those notices and disclaimers.  In case of a
     disagreement between the translation and the original version of
     this License or a notice or disclaimer, the original version will
     prevail.

     If a section in the Document is Entitled “Acknowledgements”,
     “Dedications”, or “History”, the requirement (section 4) to
     Preserve its Title (section 1) will typically require changing the
     actual title.

  9. TERMINATION

     You may not copy, modify, sublicense, or distribute the Document
     except as expressly provided under this License.  Any attempt
     otherwise to copy, modify, sublicense, or distribute it is void,
     and will automatically terminate your rights under this License.

     However, if you cease all violation of this License, then your
     license from a particular copyright holder is reinstated (a)
     provisionally, unless and until the copyright holder explicitly and
     finally terminates your license, and (b) permanently, if the
     copyright holder fails to notify you of the violation by some
     reasonable means prior to 60 days after the cessation.

     Moreover, your license from a particular copyright holder is
     reinstated permanently if the copyright holder notifies you of the
     violation by some reasonable means, this is the first time you have
     received notice of violation of this License (for any work) from
     that copyright holder, and you cure the violation prior to 30 days
     after your receipt of the notice.

     Termination of your rights under this section does not terminate
     the licenses of parties who have received copies or rights from you
     under this License.  If your rights have been terminated and not
     permanently reinstated, receipt of a copy of some or all of the
     same material does not give you any rights to use it.

  10. FUTURE REVISIONS OF THIS LICENSE

     The Free Software Foundation may publish new, revised versions of
     the GNU Free Documentation License from time to time.  Such new
     versions will be similar in spirit to the present version, but may
     differ in detail to address new problems or concerns.  See
     <https://www.gnu.org/licenses/>.

     Each version of the License is given a distinguishing version
     number.  If the Document specifies that a particular numbered
     version of this License “or any later version” applies to it, you
     have the option of following the terms and conditions either of
     that specified version or of any later version that has been
     published (not as a draft) by the Free Software Foundation.  If the
     Document does not specify a version number of this License, you may
     choose any version ever published (not as a draft) by the Free
     Software Foundation.  If the Document specifies that a proxy can
     decide which future versions of this License can be used, that
     proxy’s public statement of acceptance of a version permanently
     authorizes you to choose that version for the Document.

  11. RELICENSING

     “Massive Multiauthor Collaboration Site” (or “MMC Site”) means any
     World Wide Web server that publishes copyrightable works and also
     provides prominent facilities for anybody to edit those works.  A
     public wiki that anybody can edit is an example of such a server.
     A “Massive Multiauthor Collaboration” (or “MMC”) contained in the
     site means any set of copyrightable works thus published on the MMC
     site.

     “CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0
     license published by Creative Commons Corporation, a not-for-profit
     corporation with a principal place of business in San Francisco,
     California, as well as future copyleft versions of that license
     published by that same organization.

     “Incorporate” means to publish or republish a Document, in whole or
     in part, as part of another Document.

     An MMC is “eligible for relicensing” if it is licensed under this
     License, and if all works that were first published under this
     License somewhere other than this MMC, and subsequently
     incorporated in whole or in part into the MMC, (1) had no cover
     texts or invariant sections, and (2) were thus incorporated prior
     to November 1, 2008.

     The operator of an MMC Site may republish an MMC contained in the
     site under CC-BY-SA on the same site at any time before August 1,
     2009, provided the MMC is eligible for relicensing.

ADDENDUM: How to use this License for your documents
====================================================

To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and license
notices just after the title page:

       Copyright (C)  YEAR  YOUR NAME.
       Permission is granted to copy, distribute and/or modify this document
       under the terms of the GNU Free Documentation License, Version 1.3
       or any later version published by the Free Software Foundation;
       with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
       Texts.  A copy of the license is included in the section entitled ``GNU
       Free Documentation License''.

   If you have Invariant Sections, Front-Cover Texts and Back-Cover
Texts, replace the “with...Texts.” line with this:

         with the Invariant Sections being LIST THEIR TITLES, with
         the Front-Cover Texts being LIST, and with the Back-Cover Texts
         being LIST.

   If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.

   If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of free
software license, such as the GNU General Public License, to permit
their use in free software.