]> git.donarmstrong.com Git - perltidy.git/commitdiff
update CHANGES to note change in default encoding
authorSteve Hancock <perltidy@users.sourceforge.net>
Mon, 23 Mar 2020 22:33:36 +0000 (15:33 -0700)
committerSteve Hancock <perltidy@users.sourceforge.net>
Mon, 23 Mar 2020 22:33:36 +0000 (15:33 -0700)
CHANGES.md
bin/perltidy

index f411d7ccbc554785f304e5d6b7e40e0884a74961..798671dcf3ea029898429cda2d3ea8a0c5cab68e 100644 (file)
@@ -8,6 +8,13 @@
       latin-1.  Also, specific encodings of input files other than utf8 may
       now be given, for example --character-encoding=euc-jp.
 
+      The default encoding has been set to be 'guess' instead of 'none'. I
+      do not like to change defaults, but this seems like the best 
+      default choice, since it should make perltidy
+      work properly with both older latin-1 and newer utf8 files.  I have done
+      extensive testing and haven't found any problems, but I will open
+      an issue at git for comments in case this causes problems.
+
     - Fix for git#22, Preserve function signature on a single line. An
       unwanted line break was being introduced when a closing signature paren
       followed a closing do brace.
index 9c69542fe6827e299367a090389ffa4fc4dec771..b11bf2b9700049966369435b117230c569251faf 100755 (executable)
@@ -590,8 +590,8 @@ this flag is in effect.
 This flag indicates the character encoding, if any, of the input data stream.
 Perltidy does not look for the encoding directives in the soure stream, such
 as B<use utf8>, and instead relies on this flag to determine the encoding.
-(It has to be this way because perltidy is often working on snippets of code
-rather than a complete file).
+(Note that perltidy often works on snippets of code rather than complete files
+so it cannot rely on B<use utf8> directives).
 
 The possible values for B<s> are (1) the name of an encoding recognized by the
 Encode.pm module, (2) B<none> if no encoding is used, or (3) <guess> if