develooper Front page | perl.perl5.changes | Postings from March 2018

[perl.git] branch blead updated. v5.27.9-106-ga2d13ee089

From:
Father Chrysostomos
Date:
March 5, 2018 17:56
Subject:
[perl.git] branch blead updated. v5.27.9-106-ga2d13ee089
Message ID:
E1esuLl-0001n6-IP@git.dc.perl.space
In perl.git, the branch blead has been updated

<https://perl5.git.perl.org/perl.git/commitdiff/a2d13ee089a08f2c4ac0472a6d54e14e83a4eab4?hp=ab82787b570c2b70044e783462318c4c4c089ca6>

- Log -----------------------------------------------------------------
commit a2d13ee089a08f2c4ac0472a6d54e14e83a4eab4
Author: Father Chrysostomos <sprout@cpan.org>
Date:   Mon Mar 5 09:55:34 2018 -0800

    perldiag: Rewrap an entry for better splain output
    
    The splain utility (aka diagnostics.pm) blindly strips out pod formatting
    without rewrapping the text (I think rewrapping would be overkill).  This
    means that formatting like ‘L<Note [5] in
    perlrecharclass|perlrecharclass/[5]>’ turns into a simple ‘Note [5] in
    perlrecharclass’, which can mess up the indentation.
    
    Rewrap the entry to compensate, plus a few other tweaks to improve
    the appearance of the right margin.

-----------------------------------------------------------------------

Summary of changes:
 pod/perldiag.pod | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/pod/perldiag.pod b/pod/perldiag.pod
index 124f1fb248..891989c423 100644
--- a/pod/perldiag.pod
+++ b/pod/perldiag.pod
@@ -3384,8 +3384,8 @@ ambiguities and conflicts in following the Standard, and the locale has
 chosen an approach that differs from Perl's.
 
 One of these is because that, contrary to the claims, Unicode is not
-completely locale insensitive.  Turkish and some related languages have
-two types of C<"I"> characters.  One is dotted in both upper- and
+completely locale insensitive.  Turkish and some related languages
+have two types of C<"I"> characters.  One is dotted in both upper- and
 lowercase, and the other is dotless in both cases.  Unicode allows a
 locale to use either the Turkish rules, or the rules used in all other
 instances, where there is only one type of C<"I">, which is dotless in
@@ -3400,14 +3400,14 @@ The other common cause is for the characters
 
 These are probematic.  The C standard says that these should be
 considered punctuation in the C locale (and the POSIX standard defers to
-the C standard), and Unicode is generally considered a superset of the C
-locale.  But Unicode has added an extra category, "Symbol", and
+the C standard), and Unicode is generally considered a superset of
+the C locale.  But Unicode has added an extra category, "Symbol", and
 classifies these particular characters as being symbols.  Most UTF-8
 locales have them treated as punctuation, so that L<ispunct(2)> returns
-non-zero for them.  But a few locales have it return 0.   Perl takes the
-first approach, not using C<ispunct()> at all (see L<Note [5] in
-perlrecharclass|perlrecharclass/[5]>), and this message is raised to
-notify you that you are getting Perl's approach, not the locale's.
+non-zero for them.  But a few locales have it return 0.   Perl takes
+the first approach, not using C<ispunct()> at all (see L<Note [5] in
+perlrecharclass|perlrecharclass/[5]>), and this message is raised to notify you that you
+are getting Perl's approach, not the locale's.
 
 =item Locale '%s' may not work well.%s
 

-- 
Perl5 Master Repository



nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About