pods, comments: Fix up e.g. i.e.

README.vos

@@ -30,7 +30,7 @@ To build perl from its source code on the Stratus V Series platform
 you must have OpenVOS Release 17.1.0 or later, GNU Tools Release
 3.5 or later, and the C/POSIX Runtime Libraries.
 
-Follow the normal instructions for building perl; e.g, enter bash, run
+Follow the normal instructions for building perl; e.g., enter bash, run
 the Configure script, then use "gmake" to build perl.
 
 =head1 INSTALLING PERL IN OPENVOS

README.win32

@@ -482,7 +482,7 @@ important that one of the following values appears in Config.pm:
 
     make='nmake'	# MakeMaker emits nmake syntax
     any other value	# MakeMaker emits generic make syntax
-    			    (e.g GNU make, or Perl make)
+                        #   (e.g., GNU make, or Perl make)
 
 If the value doesn't match the 'make' program you want to use,
 edit Config.pm to fix it.

ext/File-Glob/TODO

@@ -3,7 +3,7 @@ Some issues left to take care of:
   o sane ~ handling on non-Unix platforms
 
      Currently on non-Unix, when the glob code encounters a tilde glob
-     (.e.g ~user/foo or ~/.cshrc), it simply returns that pattern
+     (e.g., ~user/foo or ~/.cshrc), it simply returns that pattern
      without doing any expansion (meaning perl will weed it out since a
      file of that name isn't likely to exist).
 

ext/VMS-Filespec/lib/VMS/Filespec.pm

@@ -53,7 +53,7 @@ string manipulations; the routines do not check the details of syntax
 when running under VMS, conversions from VMS syntax use the $PARSE
 service to expand specifications, so illegal syntax, or a relative
 directory specification which extends above the tope of the current
-directory path (e.g [---.foo] when in dev:[dir.sub]) will cause
+directory path (e.g., [---.foo] when in dev:[dir.sub]) will cause
 errors.  In general, any legal file specification will be converted
 properly, but garbage input tends to produce garbage output.  
 
@@ -223,7 +223,7 @@ This document was last revised 8-DEC-2007, for Perl 5.10.0
 package VMS::Filespec;
 require 5.006;
 
-our $VERSION = '1.13';
+our $VERSION = '1.14';
 
 # If you want to use this package on a non-VMS system,
 # uncomment the following line.

gv.c

@@ -21,7 +21,7 @@
 
 /*
 =head1 GV Handling and Stashes
-A GV is a structure which corresponds to a Perl typeglob, ie *foo.
+A GV is a structure which corresponds to a Perl typeglob, I<i.e.>, *foo.
 It is a structure that holds a pointer to a scalar, an array, a hash etc,
 corresponding to $foo, @foo, %foo.
 

peep.c

@@ -601,7 +601,7 @@ S_maybe_multiconcat(pTHX_ OP *o)
 
     /* Benchmarking seems to indicate that we gain if:
      * * we optimise at least two actions into a single multiconcat
-     *    (e.g concat+concat, sassign+concat);
+     *    (e.g., concat+concat, sassign+concat);
      * * or if we can eliminate at least 1 OP_CONST;
      * * or if we can eliminate a padsv via OPpTARGET_MY
      */

pod/perlmodlib.PL

@@ -646,7 +646,7 @@ To be fully compatible with the Exporter and MakeMaker modules you
 should store your module's version number in a non-my package
 variable called $VERSION.  This should be a positive floating point
 number with at least two digits after the decimal (i.e., hundredths,
-e.g, C<$VERSION = "0.01">).  Don't use a "1.3.2" style version.
+e.g., C<$VERSION = "0.01">).  Don't use a "1.3.2" style version.
 See L<Exporter> for details.
 
 It may be handy to add a function or method to retrieve the number.

pod/perlobj.pod

@@ -163,7 +163,7 @@ object.
 You will sometimes see older books or documentation mention "blessing a
 reference" or describe an object as a "blessed reference", but this is
 incorrect. It isn't the reference that is blessed as an object; it's
-the thing the reference refers to (i.e. the referent).
+the thing the reference refers to (I<i.e.>, the referent).
 
 =head2 A Class is Simply a Package
 X<class> X<package> X<@ISA> X<inheritance>
@@ -364,7 +364,7 @@ In this example, we will get the following output:
 This demonstrates how C<SUPER> is resolved. Even though the object is
 blessed into the C<C> class, the C<speak()> method in the C<B> class
 can still call C<SUPER::speak()> and expect it to correctly look in the
-parent class of C<B> (i.e the class the method call is in), not in the
+parent class of C<B> (I<i.e.>, the class the method call is in), not in the
 parent class of C<C> (i.e. the class the object belongs to).
 
 There are rare cases where this package-based resolution can be a