+=encoding utf8
=head1 NAME
=head1 Pod Definitions
-Pod is embedded in files, typically Perl source files -- although you
+Pod is embedded in files, typically Perl source files, although you
can write a file that's nothing but Pod.
A B<line> in a file consists of zero or more non-newline characters,
than space or tab (and terminated by a newline or end-of-file).
(I<Note:> Many older Pod parsers did not accept a line consisting of
-spaces/tabs and then a newline as a blank line -- the only lines they
+spaces/tabs and then a newline as a blank line. The only lines they
considered blank were lines consisting of I<no characters at all>,
terminated by a newline.)
is a module or program that converts Pod to some other format (HTML,
plaintext, TeX, PostScript, RTF). A B<Pod processor> might be a
formatter or translator, or might be a program that does something
-else with the Pod (like wordcounting it, scanning for index points,
+else with the Pod (like counting words, scanning for index points,
etc.).
Pod content is contained in B<Pod blocks>. A Pod block starts with a
line that matches <m/\A=[a-zA-Z]/>, and continues up to the next line
-that matches C<m/\A=cut/> -- or up to the end of the file, if there is
+that matches C<m/\A=cut/> or up to the end of the file if there is
no C<m/\A=cut/> line.
=for comment
=for comment
Hm, I wonder what it would look like if
you tried to write a BNF for Pod from this.
-
+
=head3 Dr. Strangelove, or: How I Learned to
Stop Worrying and Love the Bomb
In other words, the Pod processing handler for "head1" will apply the
same processing to "Did You Remember to CE<lt>use strict;>?" that it
-would to an ordinary paragraph -- i.e., formatting codes (like
+would to an ordinary paragraph (i.e., formatting codes like
"CE<lt>...>") are parsed and presumably formatted appropriately, and
whitespace in the form of literal spaces and/or tabs is not
significant.
# <- that's the 0th column
=head1 Foo
-
+
Stuff
-
+
$foo->bar
-
+
=cut
Here, "=head1 Foo" and "=cut" are command paragraphs because the first
whitespace character (and there's no "=begin"..."=end" region around).
The "=begin I<identifier>" ... "=end I<identifier>" commands stop
-paragraphs that they surround from being parsed as data or verbatim
+paragraphs that they surround from being parsed as ordinary or verbatim
paragraphs, if I<identifier> doesn't begin with a colon. This
is discussed in detail in the section
L</About Data Paragraphs and "=beginE<sol>=end" Regions>.
is a heading. That text may contain formatting codes. Examples:
=head1 Object Attributes
-
+
=head3 What B<Not> to Do!
=item "=pod"
it must be ignored. Examples:
=pod
-
+
This is a plain Pod paragraph.
-
+
=pod This text is ignored.
=item "=cut"
# This is the first line of program text.
sub foo { # This is the second.
-It is an error to try to I<start> a Pod black with a "=cut" command. In
+It is an error to try to I<start> a Pod block with a "=cut" command. In
that case, the Pod processor must halt parsing of the input file, and
must by default emit a warning.
below. Formatting codes are not expanded. Examples:
=over 3
-
+
=over 3.5
-
+
=over
=item "=item"
below. Examples:
=item
-
+
=item *
-
+
=item *
-
+
=item 14
-
+
=item 3.
-
+
=item C<< $thing->stuff(I<dodad>) >>
-
+
=item For transporting us beyond seas to be tried for pretended
offenses
-
+
=item He is at this time transporting large armies of foreign
mercenaries to complete the works of death, desolation and
tyranny, already begun with circumstances of cruelty and perfidy
=item "=begin formatname"
+=item "=begin formatname parameter"
+
This marks the following paragraphs (until the matching "=end
formatname") as being for some special kind of processing. Unless
"formatname" begins with a colon, the contained non-command
L</About Data Paragraphs and "=beginE<sol>=end" Regions>.
It is advised that formatnames match the regexp
-C<m/\A:?[-a-zA-Z0-9_]+\z/>. Implementors should anticipate future
-expansion in the semantics and syntax of the first parameter
-to "=begin"/"=end"/"=for".
+C<m/\A:?[−a−zA−Z0−9_]+\z/>. Everything following whitespace after the
+formatname is a parameter that may be used by the formatter when dealing
+with this region. This parameter must not be repeated in the "=end"
+paragraph. Implementors should anticipate future expansion in the
+semantics and syntax of the first parameter to "=begin"/"=end"/"=for".
=item "=end formatname"
This is synonymous with:
=begin formatname
-
+
text...
-
+
=end formatname
That is, it creates a region consisting of a single paragraph; that
to use "=for formatname text..." to express "text..." as a verbatim
paragraph.
+=item "=encoding encodingname"
+
+This command, which should occur early in the document (at least
+before any non-US-ASCII data!), declares that this document is
+encoded in the encoding I<encodingname>, which must be
+an encoding name that L<Encode> recognizes. (Encode's list
+of supported encodings, in L<Encode::Supported>, is useful here.)
+If the Pod parser cannot decode the declared encoding, it
+should emit a warning and may abort parsing the document
+altogether.
+
+A document having more than one "=encoding" line should be
+considered an error. Pod processors may silently tolerate this if
+the not-first "=encoding" lines are just duplicates of the
+first one (e.g., if there's a "=encoding utf8" line, and later on
+another "=encoding utf8" line). But Pod processors should complain if
+there are contradictory "=encoding" lines in the same document
+(e.g., if there is a "=encoding utf8" early in the document and
+"=encoding big5" later). Pod processors that recognize BOMs
+may also complain if they see an "=encoding" line
+that contradicts the BOM (e.g., if a document with a UTF-16LE
+BOM has an "=encoding shiftjis" line).
+
=back
If a Pod processor sees any command other than the ones listed
B<< $foo->bar(); >>
With this syntax, the whitespace character(s) after the "CE<lt><<"
-and before the ">>" (or whatever letter) are I<not> renderable -- they
+and before the ">>" (or whatever letter) are I<not> renderable. They
do not signify whitespace, are merely part of the formatting codes
themselves. That is, these are all synonymous:
and so on.
+Finally, the multiple-angle-bracket form does I<not> alter the interpretation
+of nested formatting codes, meaning that the following four example lines are
+identical in meaning:
+
+ B<example: C<$a E<lt>=E<gt> $b>>
+
+ B<example: C<< $a <=> $b >>>
+
+ B<example: C<< $a E<lt>=E<gt> $b >>>
+
+ B<<< example: C<< $a E<lt>=E<gt> $b >> >>>
+
=back
In parsing Pod, a notably tricky part is the correct parsing of
This formatting code is syntactically simple, but semantically
complex. What it means is that each space in the printable
-content of this code signifies a nonbreaking space.
+content of this code signifies a non-breaking space.
Consider:
Both signify the monospace (c[ode] style) text consisting of
"$x", one space, "?", one space, ":", one space, "$z". The
difference is that in the latter, with the S code, those spaces
-are not "normal" spaces, but instead are nonbreaking spaces.
+are not "normal" spaces, but instead are non-breaking spaces.
=back
would parse as equivalent to this:
- C<$foo-E<lt>bar>
+ C<$foo-E<gt>bar>
instead of as equivalent to a "C" formatting code containing
only "$foo-", and then a "bar>" outside the "C" formatting code. This
two paragraphs:
I<I told you not to do this!
-
+
Don't make me say it again!>
...must I<not> be parsed as two paragraphs in italics (with the I
above code must parse as if it were:
I<I told you not to do this!>
-
+
Don't make me say it again!E<gt>
(In SGMLish jargon, all Pod commands are like block-level
0xEF 0xBB 0xBF
=for comment
- If toke.c is modified to support UTF32, add mention of those here.
+ If toke.c is modified to support UTF-32, add mention of those here.
=item *
=for comment
If/WHEN some brave soul makes these heuristics into a generic
- text-file class (or file discipline?), we can presumably delete
+ text-file class (or PerlIO layer?), we can presumably delete
mention of these icky details from this file, and can instead
- tell people to just use appropriate class/discipline.
+ tell people to just use appropriate class/layer.
Auto-recognition of newline sequences would be another desirable
- feature of such a class/discipline.
+ feature of such a class/layer.
HINT HINT HINT.
=for comment
Minimal examples:
%% POD::Pod2PS v3.14159, using POD::Parser v1.92
-
+
<!-- Pod::HTML v3.14159, using POD::Parser v1.92 -->
-
+
{\doccomm generated by Pod::Tree::RTF 3.14159 using Pod::Tree 1.08}
-
+
.\" Pod::Man version 3.14159, using POD::Parser version 1.92
Formatters may also insert additional comments, including: the
Pod parsers should not, by default, try to coerce apostrophe (') and
quote (") into smart quotes (little 9's, 66's, 99's, etc), nor try to
turn backtick (`) into anything else but a single backtick character
-(distinct from an openquote character!), nor "--" into anything but
+(distinct from an open quote character!), nor "--" into anything but
two minus signs. They I<must never> do any of those things to text
in CE<lt>...> formatting codes, and never I<ever> to text in verbatim
paragraphs.
=item *
When rendering Pod to a format that has two kinds of hyphens (-), one
-that's a nonbreaking hyphen, and another that's a breakable hyphen
+that's a non-breaking hyphen, and another that's a breakable hyphen
(as in "object-oriented", which can be split across lines as
"object-", newline, "oriented"), formatters are encouraged to
-generally translate "-" to nonbreaking hyphen, but may apply
+generally translate "-" to non-breaking hyphen, but may apply
heuristics to convert some of these to breaking hyphens.
=item *
Pod parsers, when processing a series of verbatim paragraphs one
after another, should consider them to be one large verbatim
paragraph that happens to contain blank lines. I.e., these two
-lines, which have an blank line between them:
+lines, which have a blank line between them:
use Foo;
which all Pod formatters must render faithfully. Characters
in the ranges 0-31 and 127-159 should not be used (neither as
literals, nor as EE<lt>number> codes), except for the
-literal byte-sequences for newline (13, 13 10, or 13), and tab (9).
+literal byte-sequences for newline (13, 13 10, or 10), and tab (9).
Characters in the range 160-255 refer to Latin-1 characters (also
defined there by Unicode, with the same meaning). Characters above
presumably does not I<need> special treatment by a Pod processor;
" 0 1 2 3 " doesn't look like a number in any base, so it would
presumably be looked up in the table of HTML-like names. Since
-there is (and cannot be) an HTML-like entity called " 0 1 2 3 ",
+there isn't (and cannot be) an HTML-like entity called " 0 1 2 3 ",
this will be treated as an error. However, Pod processors may
treat "EE<lt> 0 1 2 3 >" or "EE<lt>e-acute>" as I<syntactically>
invalid, potentially earning a different error message than the
such sequences in the target output format. A converter to *roff
would, for example know that "\xE9" (whether conveyed literally, or via
a EE<lt>...> sequence) is to be conveyed as "e\\*'".
-Similarly, a program rendering Pod in a MacOS application window, would
+Similarly, a program rendering Pod in a Mac OS application window, would
presumably need to know that "\xE9" maps to codepoint 142 in MacRoman
-encoding that (at time of writing) is native for MacOS. Such
+encoding that (at time of writing) is native for Mac OS. Such
Unicode2whatever mappings are presumably already widely available for
common output formats. (Such mappings may be incomplete! Implementers
are not expected to bend over backwards in an attempt to render
=item *
-It is up to individual Pod formatter to display good judgment when
+It is up to individual Pod formatter to display good judgement when
confronted with an unrenderable character (which is distinct from an
unknown EE<lt>thing> sequence that the parser couldn't resolve to
anything, renderable or not). It is good practice to map Latin letters
with diacritics (like "EE<lt>eacute>"/"EE<lt>233>") to the corresponding
unaccented US-ASCII letters (like a simple character 101, "e"), but
-clearly this is often not feasable, and an unrenderable character may
+clearly this is often not feasible, and an unrenderable character may
be represented as "?", or the like. In attempting a sane fallback
(as from EE<lt>233> to "e"), Pod formatters may use the
%Latin1Code_to_fallback table in L<Pod::Escapes|Pod::Escapes>, or
=item *
-Some Pod formatters output to formats that implement nonbreaking
+Some Pod formatters output to formats that implement non-breaking
spaces as an individual character (which I'll call "NBSP"), and
-others output to formats that implement nonbreaking spaces just as
+others output to formats that implement non-breaking spaces just as
spaces wrapped in a "don't break this across lines" code. Note that
at the level of Pod, both sorts of codes can occur: Pod can contain a
NBSP character (whether as a literal, or as a "EE<lt>160>" or
"EE<lt>nbsp>" code); and Pod can contain "SE<lt>foo
IE<lt>barE<gt> baz>" codes, where "mere spaces" (character 32) in
-such codes are taken to represent nonbreaking spaces. Pod
+such codes are taken to represent non-breaking spaces. Pod
parsers should consider supporting the optional parsing of "SE<lt>foo
IE<lt>barE<gt> baz>" as if it were
"fooI<NBSP>IE<lt>barE<gt>I<NBSP>baz", and, going the other way, the
=item *
-Some processors may find it the C<SE<lt>...E<gt>> code easiest to
+Some processors may find that the C<SE<lt>...E<gt>> code is easiest to
implement by replacing each space in the parse tree under the content
of the S, with an NBSP. But note: the replacement should apply I<not> to
spaces in I<all> text, but I<only> to spaces in I<printable> text. (This
Besides the NBSP character discussed above, implementors are reminded
of the existence of the other "special" character in Latin-1, the
-"soft hyphen" chararacter, also known as "discretionary hyphen",
+"soft hyphen" character, also known as "discretionary hyphen",
i.e. C<EE<lt>173E<gt>> = C<EE<lt>0xADE<gt>> =
C<EE<lt>shyE<gt>>). This character expresses an optional hyphenation
point. That is, it normally renders as nothing, but may render as a
Throughout this document, "Pod" has been the preferred spelling for
the name of the documentation format. One may also use "POD" or
-"pod". For the the documentation that is (typically) in the Pod
+"pod". For the documentation that is (typically) in the Pod
format, you may use "pod", or "Pod", or "POD". Understanding these
distinctions is useful; but obsessing over how to spell them, usually
is not.
=item Second:
-The possibly inferred link-text -- i.e., if there was no real link
+The possibly inferred link-text; i.e., if there was no real link
text, then this is the text that we'll infer in its place. (E.g., for
"LE<lt>Getopt::Std>", the inferred link text is "Getopt::Std".)
=item Third:
The name or URL, or undef if none. (E.g., in "LE<lt>Perl
-Functions|perlfunc>", the name -- also sometimes called the page --
+Functions|perlfunc>", the name (also sometimes called the page)
is "perlfunc". In "LE<lt>/CAVEATS>", the name is undef.)
=item Fourth:
The section (AKA "item" in older perlpods), or undef if none. E.g.,
-in L<Getopt::Std/DESCRIPTION>, "DESCRIPTION" is the section. (Note
+in "LE<lt>Getopt::Std/DESCRIPTIONE<gt>", "DESCRIPTION" is the section. (Note
that this is not the same as a manpage section like the "5" in "man 5
crontab". "Section Foo" in the Pod sense means the part of the text
-that's introduced by the heading or item whose text is "Foo".
+that's introduced by the heading or item whose text is "Foo".)
=back
'url', # what sort of link
"http://www.perl.org/" # original content
+ L<Perl.org|http://www.perl.org/>
+ => "Perl.org", # link text
+ "http://www.perl.org/", # possibly inferred link text
+ "http://www.perl.org/", # name
+ undef, # section
+ 'url', # what sort of link
+ "Perl.org|http://www.perl.org/" # original content
+
Note that you can distinguish URL-links from anything else by the
fact that they match C<m/\A\w+:[^:\s]\S*\z/>. So
C<LE<lt>http://www.perl.comE<gt>> is a URL, but
<h1><a name="About_the_-M_Operator">About the <code>-M</code>
Operator</h1>
-
+
...
-
+
<a href="somedoc#About_the_-M_Operator">About the <code>-M</code>
Operator" in somedoc</a>
L<B<ummE<234>stuff>|...>
For C<LE<lt>...E<gt>> codes without a "name|" part, only
-C<EE<lt>...E<gt>> and C<ZE<lt>E<gt>> codes may occur -- no
-other formatting codes. That is, authors should not use
-"C<LE<lt>BE<lt>Foo::BarE<gt>E<gt>>".
+C<EE<lt>...E<gt>> and C<ZE<lt>E<gt>> codes may occur. That is,
+authors should not use "C<LE<lt>BE<lt>Foo::BarE<gt>E<gt>>".
Note, however, that formatting codes and ZE<lt>>'s can occur in any
and all parts of an LE<lt>...> (i.e., in I<name>, I<section>, I<text>,
At time of writing, C<LE<lt>nameE<gt>> values are of two types:
either the name of a Pod page like C<LE<lt>Foo::BarE<gt>> (which
might be a real Perl module or program in an @INC / PATH
-directory, or a .pod file in those places); or the name of a UNIX
+directory, or a .pod file in those places); or the name of a Unix
man page, like C<LE<lt>crontab(5)E<gt>>. In theory, C<LE<lt>chmodE<gt>>
in ambiguous between a Pod page called "chmod", or the Unix man page
"chmod" (in whatever man-section). However, the presence of a string
in parens, as in "crontab(5)", is sufficient to signal that what
is being discussed is not a Pod page, and so is presumably a
-UNIX man page. The distinction is of no importance to many
+Unix man page. The distinction is of no importance to many
Pod processors, but some processors that render to hypertext formats
may need to distinguish them in order to know how to render a
given C<LE<lt>fooE<gt>> code.
=item *
-Previous versions of perlpod allowed for a C<LE<lt>sectionE<gt>> syntax
-(as in "C<LE<lt>Object AttributesE<gt>>"), which was not easily distinguishable
-from C<LE<lt>nameE<gt>> syntax. This syntax is no longer in the
-specification, and has been replaced by the C<LE<lt>"section"E<gt>> syntax
-(where the quotes were formerly optional). Pod parsers should tolerate
-the C<LE<lt>sectionE<gt>> syntax, for a while at least. The suggested
-heuristic for distinguishing C<LE<lt>sectionE<gt>> from C<LE<lt>nameE<gt>>
-is that if it contains any whitespace, it's a I<section>. Pod processors
-may warn about this being deprecated syntax.
+Previous versions of perlpod allowed for a C<LE<lt>sectionE<gt>> syntax (as in
+C<LE<lt>Object AttributesE<gt>>), which was not easily distinguishable from
+C<LE<lt>nameE<gt>> syntax and for C<LE<lt>"section"E<gt>> which was only
+slightly less ambiguous. This syntax is no longer in the specification, and
+has been replaced by the C<LE<lt>/sectionE<gt>> syntax (where the slash was
+formerly optional). Pod parsers should tolerate the C<LE<lt>"section"E<gt>>
+syntax, for a while at least. The suggested heuristic for distinguishing
+C<LE<lt>sectionE<gt>> from C<LE<lt>nameE<gt>> is that if it contains any
+whitespace, it's a I<section>. Pod processors should warn about this being
+deprecated syntax.
=back
with no accompanying paragraph. The middle item is an example:
=over
-
+
=item 1
-
+
Pick up dry cleaning.
-
+
=item 2
-
+
=item 3
-
+
Stop by the store. Get Abba Zabas, Stoli, and cheap lawn chairs.
-
+
=back
=item *
content. That is, authors should not have an empty region like this:
=over
-
+
=back
Pod processors seeing such a contentless "=over" ... "=back" region,
=item Porro
=item Quisquam Est
-
+
Qui dolorem ipsum quia dolor sit amet, consectetur, adipisci
velit, sed quia non numquam eius modi tempora incidunt ut
labore et dolore magnam aliquam quaerat voluptatem.
"Ut Enim". In that case, you'd want to format it like so:
Neque
-
+
Porro
-
+
Quisquam Est
Qui dolorem ipsum quia dolor sit amet, consectetur, adipisci
velit, sed quia non numquam eius modi tempora incidunt ut
Ut Enim
-But (for the forseeable future), Pod does not provide any way for Pod
+But (for the foreseeable future), Pod does not provide any way for Pod
authors to distinguish which grouping is meant by the above
"=item"-cluster structure. So formatters should format it like so:
Ut Enim
-That is, there should be (at least roughtly) equal spacing between
+That is, there should be (at least roughly) equal spacing between
items as between paragraphs (although that spacing may well be less
than the full height of a line of text). This leaves it to the reader
to use (con)textual cues to figure out whether the "Qui dolorem
a specific format:
=begin rtf
-
+
\par{\pard\qr\sa4500{\i Printed\~\chdate\~\chtime}\par}
-
+
=end rtf
The exact same effect could, incidentally, be achieved with a single
Another example of a data paragraph:
=begin html
-
+
I like <em>PIE</em>!
-
+
<hr>Especially pecan pie!
-
+
=end html
If these were ordinary paragraphs, the Pod parser would try to
I<identifier> begins with a colon, I<can> contain commands. For example:
=begin :biblio
-
+
Wirth's classic is available in several editions, including:
-
+
=for comment
hm, check abebooks.com for how much used copies cost.
-
+
=over
-
+
=item
-
+
Wirth, Niklaus. 1975. I<Algorithmen und Datenstrukturen.>
Teubner, Stuttgart. [Yes, it's in German.]
-
+
=item
-
+
Wirth, Niklaus. 1976. I<Algorithms + Data Structures =
Programs.> Prentice-Hall, Englewood Cliffs, NJ.
-
+
=back
-
+
=end :biblio
Note, however, a "=begin I<identifier>"..."=end I<identifier>"
nor "=item". For example, this may be considered invalid:
=begin somedata
-
+
This is a data paragraph.
-
+
=head1 Don't do this!
-
+
This is a data paragraph too.
-
+
=end somedata
A Pod processor may signal that the above (specifically the "=head1"
I<not> be treated as an error:
=begin somedata
-
+
This is a data paragraph.
-
+
=cut
-
+
# Yup, this isn't Pod anymore.
sub excl { (rand() > .5) ? "hoo!" : "hah!" }
-
+
=pod
-
+
This is a data paragraph too.
-
+
=end somedata
And this too is valid:
=begin someformat
-
+
This is a data paragraph.
-
+
And this is a data paragraph.
-
+
=begin someotherformat
-
+
This is a data paragraph too.
-
+
And this is a data paragraph too.
-
+
=begin :yetanotherformat
=head2 This is a command paragraph!
This is an ordinary paragraph!
-
+
And this is a verbatim paragraph!
-
+
=end :yetanotherformat
-
+
=end someotherformat
-
+
Another data paragraph!
-
+
=end someformat
The contents of the above "=begin :yetanotherformat" ...
Also consider this valid structure:
=begin :biblio
-
+
Wirth's classic is available in several editions, including:
-
+
=over
-
+
=item
-
+
Wirth, Niklaus. 1975. I<Algorithmen und Datenstrukturen.>
Teubner, Stuttgart. [Yes, it's in German.]
-
+
=item
-
+
Wirth, Niklaus. 1976. I<Algorithms + Data Structures =
Programs.> Prentice-Hall, Englewood Cliffs, NJ.
=back
-
+
Buy buy buy!
-
+
=begin html
-
+
<img src='wirth_spokesmodeling_book.png'>
-
+
<hr>
-
+
=end html
-
+
Now now now!
-
+
=end :biblio
There, the "=begin html"..."=end html" region is nested inside
paragraphs. I.e., these should be tolerated:
=for html
-
+
=begin html
-
+
=end html
-
+
=begin :biblio
-
+
=end :biblio
Incidentally, note that there's no easy way to express a data
paragraph starting with something that looks like a command. Consider:
=begin stuff
-
+
=shazbot
-
+
=end stuff
There, "=shazbot" will be parsed as a Pod command "shazbot", not as a data
is, they must properly nest. For example, this is valid:
=begin outer
-
+
X
-
+
=begin inner
-
+
Y
-
+
=end inner
-
+
Z
-
+
=end outer
while this is invalid:
=begin outer
-
+
X
-
+
=begin inner
-
+
Y
-
+
=end outer
-
+
Z
-
+
=end inner
-
+
This latter is improper because when the "=end outer" command is seen, the
currently open region has the formatname "inner", not "outer". (It just
happens that "outer" is the format name of a higher-up region.) This is
an error. Processors must by default report this as an error, and may halt
-processing the document containing that error. A corrolary of this is that
-regions cannot "overlap" -- i.e., the latter block above does not represent
+processing the document containing that error. A corollary of this is that
+regions cannot "overlap". That is, the latter block above does not represent
a region called "outer" which contains X and Y, overlapping a region called
"inner" which contains Y and Z. But because it is invalid (as all
apparently overlapping regions would be), it doesn't represent that, or
Similarly, this is invalid:
=begin thing
-
+
=end hting
This is an error because the region is opened by "thing", and the "=end"
This is also invalid:
=begin thing
-
+
=end
This is invalid because every "=end" command must have a formatname
https://perl5.git.perl.org / perl5.git / blobdiff