s/\.pretty/.gist/g

S02-bits.pod

@@ -1995,16 +1995,16 @@ some modules will rely on the ability to roundtrip values with C<eval>.  As
 such, overriding C<.perl> with a different format (globally using
 C<MONKEY_TYPING>, or for specific classes unless special care is taken to
 maintain parsability) is unwise.  Code which does not depend on C<.perl>'s
-definition should use C<.pretty> instead to allow more control.
+definition should use C<.gist> instead to allow more control.
 
-=head2 The C<.pretty> method
+=head2 The C<.gist> method
 
-C<.pretty>, by contrast with C<.perl>, returns a flexible form of an object
+C<.gist>, by contrast with C<.perl>, returns a flexible form of an object
 intended for human interpretation.  Specific user classes are encouraged to
-override C<.pretty> to do something appropriate, and it is completely
-acceptable to monkey patch C<.pretty> methods while doing debugging, without
-risk of breaking any used module.  C<.pretty>, like any method, will accept
-and ignore unrecognized named arguments; implementations of C<.pretty> are
+override C<.gist> to do something appropriate, and it is completely
+acceptable to monkey patch C<.gist> methods while doing debugging, without
+risk of breaking any used module.  C<.gist>, like any method, will accept
+and ignore unrecognized named arguments; implementations of C<.gist> are
 encouraged to standardize on a set of flags.
 
 [Some conjectural suggestions:
@@ -2014,7 +2014,7 @@ encouraged to standardize on a set of flags.
     :charset($obj)  Represent unrecognized characters as escapes
     :ascii          Short for some instantiation of :charset
 
-Conjecturally, C<.pretty> on system-defined classes could redispatch to
+Conjecturally, C<.gist> on system-defined classes could redispatch to
 C<&*PRETTYPRINTER> or some similar system, allowing for a more disciplined
 way to change pretty formats.