Update the sv_pvprintify() spec.

[p5sagit/p5-mst-13.2.git] / pod / perltodo.pod

diff --git a/pod/perltodo.pod b/pod/perltodo.pod
index 39aa37f..dab73b9 100644 (file)
--- a/pod/perltodo.pod
+++ b/pod/perltodo.pod
@@ -28,6 +28,29 @@ always be set to true, but it needs to be set to false when F<utf8.pm>
 is being compiled. (To stop Perl trying to autoload the C<utf8>
 pragma...)
 
+=head2 Create a char *sv_printify(sv, STRLEN *lenp, UV flags)
+
+For displaying PVs with control characters, embedded nulls, and Unicode.
+This would be useful for printing warnings, or data and regex dumping,
+not_a_number(), and so on.
+
+Requirements: should handle both byte and UTF8 strings.  isPRINT()
+characters printed as-is, character less than 256 as \xHH, Unicode
+characters as \x{HHH}.  Don't assume ASCII-like, either, get somebody
+on EBCDIC to test the output.
+
+Possible options, controlled by the flags:
+- whitespace (other than ' ' of isPRINT()) printed as-is
+- use isPRINT_LC() instead of isPRINT()
+- print control characters like this: "\cA"
+- print control characters like this: "^A"
+- non-PRINTables printed as '.' instead of \xHH
+- use \OOO instead of \xHH
+- use the C/Perl-metacharacters like \n, \t
+- have a maximum length for the produced string (read it from *lenp)
+- append a "..." to the produced string if the maximum length is exceeded
+- really fancy: print unicode characters as \N{...}
+
 =head2 Autoload byte.pm
 
 When the lexer sees, for instance, C<bytes::length>, it should
@@ -68,6 +91,11 @@ They have some tricks Perl doesn't yet implement.
 Artur Bergman's C<iThreads> module is a start on this, but needs to
 be more mature.
 
+=head2 make perl_clone optionally clone ops
+
+So that pseudoforking, mod_perl, iThreads and nvi will work properly
+(but not as efficiently) until the regex engine is fixed to be threadsafe.
+
 =head2 Work out exit/die semantics for threads
 
 =head2 Typed lexicals for compiler
@@ -418,9 +446,9 @@ There are a few suggestions for what to do with C<perldoc>: maybe a
 full-text search, an index function, locating pages on a particular
 high-level subject, and so on.
 
-=head2 Install .3p man pages
+=head2 Install .3p manpages
 
-This is a bone of contention; we can create C<.3p> man pages for each
+This is a bone of contention; we can create C<.3p> manpages for each
 built-in function, but should we install them by default? Tcl does this,
 and it clutters up C<apropos>.
 
@@ -429,6 +457,7 @@ and it clutters up C<apropos>.
 Simon Cozens promises to do this before he gets old.
 
 =head2 Update POSIX.pm for 1003.1-2
+
 =head2 Retargetable installation
 
 Allow C<@INC> to be changed after Perl is built.
@@ -468,7 +497,9 @@ code.
 There is a patch for this, but it may require Unicodification.
 
 =head2 Compile to real threaded code
+
 =head2 Structured types
+
 =head2 Modifiable $1 et al.
 
     ($x = "elephant") =~ /e(ph)/;
@@ -690,11 +721,13 @@ This would break old code; use C<do{{ }}> instead.
 Not needed now we have lexical IO handles.
 
 =head2 format BOTTOM
+
 =head2 report HANDLE
 
 Damian Conway's text formatting modules seem to be the Way To Go.
 
 =head2 Generalised want()/caller())
+
 =head2 Named prototypes
 
 These both seem to be delayed until Perl 6.
@@ -747,7 +780,7 @@ Suggesting this on P5P B<will> cause a boring and interminable flamewar.
 
 =head2 "class"-based lexicals
 
-Use flyweight objects, secure hashes or, dare I say it, pseudohashes instead.
+Use flyweight objects, secure hashes or, dare I say it, pseudo-hashes instead.
 
 =head2 byteperl
 
@@ -760,3 +793,13 @@ done manually, with C<goto &whoami;>. (However, MJD has found that
 C<goto &whoami> introduces a performance penalty, so maybe there should
 be a way to do this after all: C<sub foo {START: ... goto START;> is
 better.)
+
+=head2 Make "use utf8" the default
+
+There is a patch available for this, search p5p archives for
+the Subject "[EXPERIMENTAL PATCH] make unicode (utf8) default"
+but this would be unacceptable because of backward compatibility:
+scripts could not contain B<any legacy eight-bit data>.  Also would
+introduce a measurable slowdown of at least few percentages since all
+regular expression operations would be done in full UTF-8.
+