PythonTidy
Chuck Rhode
code, so I wrote one:
http://www.lacusveris.com/PythonTidy/PythonTidy.python
Now, I'm looking for beta-testers. Compensation is a bit on the low
side. In fact it's limited to the satisfaction of helping out.
Thanks.
--
.. Chuck Rhode, Sheboygan, WI, USA
Roberto Bonvallet
> I couldn't find a routine to clean up, regularize, and reformat Python
> code, so I wrote one:
>
> http://www.lacusveris.com/PythonTidy/PythonTidy.python
>
> Now, I'm looking for beta-testers. Compensation is a bit on the low
> side. In fact it's limited to the satisfaction of helping out.
$ cat test.py
#!/usr/bin/env python2.5
# vim: set fileencoding=utf-8 :
for i in xrange ( 3) :
print i
$ python2.5 PythonTidy.python < test.py
#!/usr/bin/python
# -*- coding: utf-8 -*-
for i in xrange(3):
print i
About changing the shebang line: I'll take it as a bug.
About changing the encoding declaration from vim-style to emacs-style:
I'll take it as an insult :)
Both are comments, and should be left that way. Besides, there is no
officially preferred way for each of them. BTW, in a recent thread on
this newsgroup, most people said they preferred #!/usr/bin/env python over
#!/usb/bin/python for the shebang line. See http://tinyurl.com/yngmfr .
Best regards.
--
Roberto Bonvallet
Laurent Pointal
> Chuck Rhode wrote:
>> I couldn't find a routine to clean up, regularize, and reformat Python
>> code, so I wrote one:
>>
>> http://www.lacusveris.com/PythonTidy/PythonTidy.python
>>
>> Now, I'm looking for beta-testers. Compensation is a bit on the low
>> side. In fact it's limited to the satisfaction of helping out.
>
> # vim: set fileencoding=utf-8 :
...
> # -*- coding: utf-8 -*-
> About changing the shebang line: I'll take it as a bug.
> About changing the encoding declaration from vim-style to emacs-style:
> I'll take it as an insult :)
This is not "emacs-style", this is Python normalized source encoding
directive for correct interpretation of u"..." strings by Python
interpreter.
See http://www.python.org/dev/peps/pep-0263/
A+
Laurent.
Roberto Bonvallet
> ...
>> # vim: set fileencoding=utf-8 :
> ...
>> # -*- coding: utf-8 -*-
> ...
>
> directive for correct interpretation of u"..." strings by Python
> interpreter.
>
> See http://www.python.org/dev/peps/pep-0263/
The -*- syntax is emacs-style. The encoding directive is anything that
matches r"coding[=:]\s*([-\w.]+)". The docs recommend to use either
emacs-style or vim-style. See http://docs.python.org/ref/encodings.html
Cheers,
--
Roberto Bonvallet
Richie Hindle
[Roberto]
> # vim: set fileencoding=utf-8 :
> ...
> # -*- coding: utf-8 -*-
> ...
> I'll take it as an insult :)
[Laurent]
> This is not "emacs-style", this is Python normalized source encoding
> directive for correct interpretation of u"..." strings by Python
> interpreter.
So is "# vim: set fileencoding=utf-8". Anything matching
"coding[:=]\s*([-\w.]+)" on the first or second line counts.
> See http://www.python.org/dev/peps/pep-0263/
Yes, you should. 8-)
--
Richie Hindle
ric...@entrian.com
Marc 'BlackJack' Rintsch
> Roberto Bonvallet a écrit :
>> # vim: set fileencoding=utf-8 :
> ...
>> # -*- coding: utf-8 -*-
> ...
>> About changing the shebang line: I'll take it as a bug.
>> About changing the encoding declaration from vim-style to emacs-style:
>> I'll take it as an insult :)
>
> This is not "emacs-style", this is Python normalized source encoding
> directive for correct interpretation of u"..." strings by Python
> interpreter.
>
> See http://www.python.org/dev/peps/pep-0263/
Where does it say it has to be emacs-style? It just uses that style as
example as far as I can see. The real definition is a regexp:
coding[:=]\s*([-\w.]+)
So the vim-style is fine. No need to replace it.
Ciao,
Marc 'BlackJack' Rintsch
Laurent Pointal
> See http://www.python.org/dev/peps/pep-0263/
Aye, sorry for my missreading...
[seem I hurt the emacs guy]
Chuck Rhode
> About changing the shebang line: I'll take it as a bug.
> About changing the encoding declaration from vim-style to
> emacs-style: I'll take it as an insult :)
Ooh! <wounded>
> Both are comments, and should be left that way. Besides, there is no
> officially preferred way for each of them. BTW, in a recent thread on
> this newsgroup, most people said they preferred #!/usr/bin/env python over
> #!/usb/bin/python for the shebang line. See http://tinyurl.com/yngmfr .
Thanks for the link. I was unaware of the /usr/bin/env technique and
the controversy surrounding it.
Thanks, too, for trying *PythonTidy*.
As you have no doubt perceived, *PythonTidy* is *not* "table driven."
It is a script after all. I decided before writing it that I didn't
really need to externalize all the options; nevertheless, most are
declared near the beginning where they sit just begging for end-user
involvement. See: CODING_SPEC and SHEBANG. *PythonTidy* is all about
consistency, consistency, and consistency. You can use it to
standardize shebangs and coding across a whole library of Python
scripts.
--
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: http://LacusVeris.com/WX
.. 25° — Wind NW 13 mph
Roberto Bonvallet
[...]
> Thanks, too, for trying *PythonTidy*.
No, thanks you for writing such a tool!
> [...] nevertheless, most [options] are declared near the beginning where
> they sit just begging for end-user involvement. See: CODING_SPEC and
> SHEBANG.
The fact that I immediately noticed them and came up with an example to
raise both issues is a indicator of how easy it would be to customize the
script :)
Cheers!
--
Roberto Bonvallet
Thomas Heller
> I couldn't find a routine to clean up, regularize, and reformat Python
> code, so I wrote one:
>
> http://www.lacusveris.com/PythonTidy/PythonTidy.python
>
> Now, I'm looking for beta-testers. Compensation is a bit on the low
> side. In fact it's limited to the satisfaction of helping out.
>
This looks very good, to me. The two things that bother me
at the moment are how the comments are formatted (dunno if that can be
customized or changed easily), and it would be good if the script took
command line args instead of working as a filter only.
Thanks,
Thomas
Chuck Rhode
reply is below.
> The two things that bother me at the moment are how the comments are
> formatted (dunno if that can be customized or changed easily), and
> it would be good if the script took command line args instead of
> working as a filter only.
Thank you for trying PythonTidy.
o Command-line args: Please give an example of a standard command that
I might emulate w.r.t. standard argument use.
o Comments: Input is parsed twice: I use *tokenize.generate_tokens* to
extract the comments and *compiler.parse* to generate the Abstract
Syntax Tree (AST). Other applications usually use the AST to generate
bytecode, so it contains no information about comments. The tokens
list identifies keywords (and comments and some whitespace) but
doesn't group them into statements. I need both: comments *and*
functional grouping. Fortunately both the AST and the tokens list
carry line numbers to reference the source. Unfortunately the AST
line numbers are relative to functional groups and do not necessarily
apply to the particular keywords that introduce each group. This
makes fixing the position of comments relative to reconstructed code a
bit of a challenge. For example, when a comment has a line number in
the beginning/ending range of what would normally be considered one
command, I have to assume it is an inline comment regardless of how it
may have appeared in the original code.
Out-of-line comments should appear pretty much as they did in the
original code, however. Can you provide an example where they do not?
Would you prefer that they be left justified or wrapped? >-~
Doc strings (for modules, class declarations, and functions) are
another matter. PythonTidy should not mess with them (unless
LEFTJUST_DOC_STRINGS is True). They should appear exactly as
originally written.
I was taught that code ought to be self documenting and that comments
more often than not diminish readability by padding the code beyond
what can be comprehended on one page (screen). I use them only
minimally and am not greatly inconvenienced when they are moved around
a little.
--
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: http://LacusVeris.com/WX
.. 21° — Wind N 8 mph
Thomas Heller
> Thomas Heller wrote this on Thu, Nov 30, 2006 at 09:50:25PM +0100. My
> reply is below.
>
>> The two things that bother me at the moment are how the comments are
>> formatted (dunno if that can be customized or changed easily), and
>> it would be good if the script took command line args instead of
>> working as a filter only.
>
> Thank you for trying PythonTidy.
>
> o Command-line args: Please give an example of a standard command that
> I might emulate w.r.t. standard argument use.
Well, at least it would be nice if I could call
'PythonTidy.py mymodule.py' to tidy up the mymodule.py file.
> o Comments: Input is parsed twice: I use *tokenize.generate_tokens* to
> extract the comments and *compiler.parse* to generate the Abstract
> Syntax Tree (AST). Other applications usually use the AST to generate
> bytecode, so it contains no information about comments. The tokens
> list identifies keywords (and comments and some whitespace) but
> doesn't group them into statements. I need both: comments *and*
> functional grouping. Fortunately both the AST and the tokens list
> carry line numbers to reference the source. Unfortunately the AST
> line numbers are relative to functional groups and do not necessarily
> apply to the particular keywords that introduce each group. This
> makes fixing the position of comments relative to reconstructed code a
> bit of a challenge. For example, when a comment has a line number in
> the beginning/ending range of what would normally be considered one
> command, I have to assume it is an inline comment regardless of how it
> may have appeared in the original code.
>
> Out-of-line comments should appear pretty much as they did in the
> original code, however. Can you provide an example where they do not?
> Would you prefer that they be left justified or wrapped? >-~
Here is part of a diff before and after running PythonTidy on it:
<start>
- def comptr_setitem(self, index, value):
- # We override the __setitem__ method of the
- # POINTER(POINTER(interface)) type, so that the COM
- # reference count is managed correctly.
- #
- # This is so that we can implement COM methods that have to
- # return COM pointers more easily and consistent. Instead of
- # using CopyComPointer in the method implementation, we can
- # simply do:
- #
- # def GetTypeInfo(self, this, ..., pptinfo):
- # if not pptinfo: return E_POINTER
- # pptinfo[0] = a_com_interface_pointer
- # return S_OK
+ def comptr_setitem(self, index, value): # We override the __setitem__ method of the
+ # POINTER(POINTER(interface)) type, so that the COM
+ # reference count is managed correctly.
+ #
+ # This is so that we can implement COM methods that have to
+ # return COM pointers more easily and consistent. Instead of
+ # using CopyComPointer in the method implementation, we can
+ # simply do:
+ #
+ # def GetTypeInfo(self, this, ..., pptinfo):
+ # if not pptinfo: return E_POINTER
+ # pptinfo[0] = a_com_interface_pointer
+ # return S_OK
<end>
Can this be customized?
> Doc strings (for modules, class declarations, and functions) are
> another matter. PythonTidy should not mess with them (unless
> LEFTJUST_DOC_STRINGS is True). They should appear exactly as
> originally written.
>
> I was taught that code ought to be self documenting and that comments
> more often than not diminish readability by padding the code beyond
> what can be comprehended on one page (screen). I use them only
> minimally and am not greatly inconvenienced when they are moved around
> a little.
>
Thomas
Chuck Rhode
> Here is part of a diff before and after running PythonTidy on it:
>
> <start>
> - def comptr_setitem(self, index, value):
> - # We override the __setitem__ method of the
> - # POINTER(POINTER(interface)) type, so that the COM
> - # reference count is managed correctly.
> + def comptr_setitem(self, index, value): # We override the __setitem__ method of the
> + # POINTER(POINTER(interface)) type, so that the COM
> + # reference count is managed correctly.
>
> Can this be customized?
I am able to rationalize why this happens, but you are correct: This
behavior is not appropriate. I am testing several changes, one of
which should prevent it in all cases, obviating the need for a custom
switch.
--
.. Chuck Rhode, Sheboygan, WI, USA
.. 1979 Honda Goldwing GL1000 (Geraldine)
.. Weather: http://LacusVeris.com/WX
.. 10° — Wind S 5 mph
Chuck Rhode
> Chuck Rhode schrieb:
> > o Command-line args: Please give an example of a standard command that
> > I might emulate w.r.t. standard argument use.
> Well, at least it would be nice if I could call
> 'PythonTidy.py mymodule.py' to tidy up the mymodule.py file.
I've uploaded a new version of PythonTidy:
o http://www.lacusveris.com/PythonTidy/PythonTidy-1.4.python
It fixes several problems. Also it allows file names as arguments.
> Here is part of a diff before and after running PythonTidy on it:
> <start>
> - def comptr_setitem(self, index, value):
> - # We override the __setitem__ method of the
> - # POINTER(POINTER(interface)) type, so that the COM
> - # reference count is managed correctly.
> + def comptr_setitem(self, index, value): # We override the __setitem__ method of the
> + # POINTER(POINTER(interface)) type, so that the COM
> + # reference count is managed correctly.
> Can this be customized?
This problem has been fixed I think. No customization should be
required to keep block comments from being rendered as in-line
comments.
Wolfgang Grafen reported that PythonTidy crashed in Python-2.4 because
new Abstract Syntax Tree node types introduced in Python-2.5 weren't
available. It was trivial to check availability, so PythonTidy should
now run in Python-2.4. However, this has not been thoroughly tested
and is not guaranteed.
PythonTidy can now recode string literals if required, although this
capability is turned off by default. See RECODE_STRINGS.
Docstrings will henceforward be enclosed in double quotes when
feasible.
--
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: http://LacusVeris.com/WX
.. 30° — Wind WSW 10 mph — Sky overcast.
Chuck Rhode
and I have received a couple of complaints, which I hope I have
addressed satisfactorily -- plenty good enough for a beta test. The
basic concept stands.
PythonTidy.py cleans up, regularizes, and reformats the text of
Python scripts:
http://www.LacusVeris.com/PythonTidy/PythonTidy.python
What next? Is it appropriately submitted to the Cheese Shop?
--
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: http://LacusVeris.com/WX
.. 3° — Wind W 8 mph
Thomas Heller
> That went well. PythonTidy has been looked at at least 10**2 times,
> and I have received a couple of complaints, which I hope I have
> addressed satisfactorily -- plenty good enough for a beta test. The
> basic concept stands.
Sure.
There is still one major issue. pythonTidy uses open(input-file, "rb") to
open the Python module to tidy up. That does not work on Windows,
at least if the file has (as it should) "\r\n" newlines.
I suggest you open the file with open(input-file, "rU").
For output, PythonTidy generates "\n" line endings, this should also be changed
on Windows.
And another wish from me:
PythonTidy outputs strings with single quotes, while my own style is to
use double quotes (I don't think that pep8 prefers one over the other).
Is it possible to customize this?
> PythonTidy.py cleans up, regularizes, and reformats the text of
> Python scripts:
>
> http://www.LacusVeris.com/PythonTidy/PythonTidy.python
>
> What next? Is it appropriately submitted to the Cheese Shop?
>
Of course.
Thomas
rzed
news:mailman.1125.1165331...@python.org:
> That went well. PythonTidy has been looked at at least 10**2
> times, and I have received a couple of complaints, which I hope
> I have addressed satisfactorily -- plenty good enough for a beta
> test. The basic concept stands.
>
> PythonTidy.py cleans up, regularizes, and reformats the text of
> Python scripts:
>
> http://www.LacusVeris.com/PythonTidy/PythonTidy.python
>
> What next? Is it appropriately submitted to the Cheese Shop?
>
I ran PythonTidy on a wxPython sample, and found that wx.CONSTANTS
were being translated to wx.Constants, which won't do at all.
In general, there is very little case manipulation that should be
done in a case-sensitive language; I suppose this is controllable
by one or more of the options, but it wasn't clear on casual
observation what would do the trick.
The idea of PythonTidy is not bad, but there should be a minimal
option that essentially reindents and nothing more. Adding other
style preferences should (in my opinion) be something like
checklist items. For example, I don't necessarily need a shebang
or coding line for my purposes, but without going into the code
and commenting out lines, I can't readily suppress them. As it
stands now, I can't trust PythonTidy to do the right thing on
unfamiliar code, and I can't readily try out various options by
simply activating or deactivating them; if I could, it would be
much more useful to me.
--
rzed
Chuck Rhode
below.
> I ran PythonTidy on a wxPython sample, and found that wx.CONSTANTS
> were being translated to wx.Constants, which won't do at all.
Find the first line in the PythonTidy code where the following global
variables are declared and change them as follows:
PERSONAL = False # This eliminates case manipulation.
> The idea of PythonTidy is not bad, but there should be a minimal
> option that essentially reindents and nothing more. ... For example,
> I don't necessarily need a shebang or coding line for my purposes,
> but without going into the code and commenting out lines, I can't
> readily suppress them.
Yes, it's too bad that PythonTidy doesn't have an *.rc file or a *.cfg
file or an *.ini file or an *.xml file or a Registry entry or a Gnome
configuration or its own graphical front end or a gob of command-line
options, but that's just the way it is.
SHEBANG = '' # This removes the shebang line from the output.
CODING_SPEC = '' # This removes the coding specification from the output.
> As it stands now, I can't trust PythonTidy to do the right thing on
> unfamiliar code, and I can't readily try out various options by
> simply activating or deactivating them; if I could, it would be much
> more useful to me.
PythonTidy should be run only on code that is already familiar or that
will rapidly become so in the near future.
--
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: http://LacusVeris.com/WX
.. 25° — Wind SSW 20 mph — Sky overcast. Precipitation.
Chuck Rhode
reply is below.
> I suggest you open the file with open(input-file, "rU").
This doesn't work so pretty good while reading from sys.stdin, so I'm
still at the drawing board.
--
.. Chuck Rhode, Sheboygan, WI, USA
.. 1979 Honda Goldwing GL1000 (Geraldine)
.. Weather: http://LacusVeris.com/WX
.. 27° — Wind S 15 mph — Sky overcast.
Chuck Rhode
reply is below.
> There is still one major issue. pythonTidy uses open(input-file,
> "rb") to open the Python module to tidy up. That does not work on
> Windows, at least if the file has (as it should) "\r\n" newlines.
Thank you for challenging my parochial world view.
I have posted yet another version of PythonTidy:
http://www.lacusveris.com/PythonTidy/PythonTidy-1.5.python
This one is omnivorous wrt to newlines.
> For output, PythonTidy generates "\n" line endings, this should also
> be changed on Windows.
When OVERRIDE_NEWLINE = None, the first newline encountered on input
is the one used throughout the output; otherwise, you can set it to
what you want, e.g, OVERRIDE_NEWLINE = '\n'.
> PythonTidy outputs strings with single quotes, while my own style is
> to use double quotes (I don't think that pep8 prefers one over the
> other). Is it possible to customize this?
Here is a new global: DOUBLE_QUOTED_STRINGS = True.
--
.. Chuck Rhode, Sheboygan, WI, USA
.. Weather: http://LacusVeris.com/WX
.. 30° — Wind WNW 15 mph — Sky overcast.
Thomas Heller
> Thomas Heller wrote this on Tue, Dec 05, 2006 at 07:06:30PM +0100. My
> reply is below.
>
>> There is still one major issue. pythonTidy uses open(input-file,
>> "rb") to open the Python module to tidy up. That does not work on
>> Windows, at least if the file has (as it should) "\r\n" newlines.
>
> Thank you for challenging my parochial world view.
>
> I have posted yet another version of PythonTidy:
>
> http://www.lacusveris.com/PythonTidy/PythonTidy-1.5.python
>
> This one is omnivorous wrt to newlines.
>
>> For output, PythonTidy generates "\n" line endings, this should also
>> be changed on Windows.
>
> When OVERRIDE_NEWLINE = None, the first newline encountered on input
> is the one used throughout the output; otherwise, you can set it to
> what you want, e.g, OVERRIDE_NEWLINE = '\n'.
>
>> PythonTidy outputs strings with single quotes, while my own style is
>> to use double quotes (I don't think that pep8 prefers one over the
>> other). Is it possible to customize this?
>
> Here is a new global: DOUBLE_QUOTED_STRINGS = True.
>
Thanks,
Thomas
cjco...@linuxfoundation.org
First, thank you for creating this tool.
next, I would recommend perltidy as a program to emulate. I'll paste the output of perltidy --help below.
http://perltidy.sourceforge.net/
I could probably write a wrapper script to do this if you'd like.
Cheers,
C.J.
$ perltidy --help
This is perltidy version 20140328, a perl script indenter. Usage:
perltidy [ options ] file1 file2 file3 ...
(output goes to file1.tdy, file2.tdy, file3.tdy, ...)
perltidy [ options ] file1 -o outfile
perltidy [ options ] file1 -st >outfile
perltidy [ options ] <infile >outfile
Options have short and long forms. Short forms are shown; see
man pages for long forms. Note: '=s' indicates a required string,
and '=n' indicates a required integer.
I/O control
-h show this help
-o=file name of the output file (only if single input file)
-oext=s change output extension from 'tdy' to s
-opath=path change path to be 'path' for output files
-b backup original to .bak and modify file in-place
-bext=s change default backup extension from 'bak' to s
-q deactivate error messages (for running under editor)
-w include non-critical warning messages in the .ERR error output
-syn run perl -c to check syntax (default under unix systems)
-log save .LOG file, which has useful diagnostics
-f force perltidy to read a binary file
-g like -log but writes more detailed .LOG file, for debugging scripts
-opt write the set of options actually used to a .LOG file
-npro ignore .perltidyrc configuration command file
-pro=file read configuration commands from file instead of .perltidyrc
-st send output to standard output, STDOUT
-se send all error output to standard error output, STDERR
-v display version number to standard output and quit
Basic Options:
-i=n use n columns per indentation level (default n=4)
-t tabs: use one tab character per indentation level, not recommeded
-nt no tabs: use n spaces per indentation level (default)
-et=n entab leading whitespace n spaces per tab; not recommended
-io "indent only": just do indentation, no other formatting.
-sil=n set starting indentation level to n; use if auto detection fails
-ole=s specify output line ending (s=dos or win, mac, unix)
-ple keep output line endings same as input (input must be filename)
Whitespace Control
-fws freeze whitespace; this disables all whitespace changes
and disables the following switches:
-bt=n sets brace tightness, n= (0 = loose, 1=default, 2 = tight)
-bbt same as -bt but for code block braces; same as -bt if not given
-bbvt block braces vertically tight; use with -bl or -bli
-bbvtl=s make -bbvt to apply to selected list of block types
-pt=n paren tightness (n=0, 1 or 2)
-sbt=n square bracket tightness (n=0, 1, or 2)
-bvt=n brace vertical tightness,
n=(0=open, 1=close unless multiple steps on a line, 2=always close)
-pvt=n paren vertical tightness (see -bvt for n)
-sbvt=n square bracket vertical tightness (see -bvt for n)
-bvtc=n closing brace vertical tightness:
n=(0=open, 1=sometimes close, 2=always close)
-pvtc=n closing paren vertical tightness, see -bvtc for n.
-sbvtc=n closing square bracket vertical tightness, see -bvtc for n.
-ci=n sets continuation indentation=n, default is n=2 spaces
-lp line up parentheses, brackets, and non-BLOCK braces
-sfs add space before semicolon in for( ; ; )
-aws allow perltidy to add whitespace (default)
-dws delete all old non-essential whitespace
-icb indent closing brace of a code block
-cti=n closing indentation of paren, square bracket, or non-block brace:
n=0 none, =1 align with opening, =2 one full indentation level
-icp equivalent to -cti=2
-wls=s want space left of tokens in string; i.e. -nwls='+ - * /'
-wrs=s want space right of tokens in string;
-sts put space before terminal semicolon of a statement
-sak=s put space between keywords given in s and '(';
-nsak=s no space between keywords in s and '('; i.e. -nsak='my our local'
Line Break Control
-fnl freeze newlines; this disables all line break changes
and disables the following switches:
-anl add newlines; ok to introduce new line breaks
-bbs add blank line before subs and packages
-bbc add blank line before block comments
-bbb add blank line between major blocks
-kbl=n keep old blank lines? 0=no, 1=some, 2=all
-mbl=n maximum consecutive blank lines to output (default=1)
-ce cuddled else; use this style: '} else {'
-dnl delete old newlines (default)
-l=n maximum line length; default n=80
-bl opening brace on new line
-sbl opening sub brace on new line. value of -bl is used if not given.
-bli opening brace on new line and indented
-bar opening brace always on right, even for long clauses
-vt=n vertical tightness (requires -lp); n controls break after opening
token: 0=never 1=no break if next line balanced 2=no break
-vtc=n vertical tightness of closing container; n controls if closing
token starts new line: 0=always 1=not unless list 1=never
-wba=s want break after tokens in string; i.e. wba=': .'
-wbb=s want break before tokens in string
Following Old Breakpoints
-kis keep interior semicolons. Allows multiple statements per line.
-boc break at old comma breaks: turns off all automatic list formatting
-bol break at old logical breakpoints: or, and, ||, && (default)
-bok break at old list keyword breakpoints such as map, sort (default)
-bot break at old conditional (ternary ?:) operator breakpoints (default)
-boa break at old attribute breakpoints
-cab=n break at commas after a comma-arrow (=>):
n=0 break at all commas after =>
n=1 stable: break unless this breaks an existing one-line container
n=2 break only if a one-line container cannot be formed
n=3 do not treat commas after => specially at all
Comment controls
-ibc indent block comments (default)
-isbc indent spaced block comments; may indent unless no leading space
-msc=n minimum desired spaces to side comment, default 4
-fpsc=n fix position for side comments; default 0;
-csc add or update closing side comments after closing BLOCK brace
-dcsc delete closing side comments created by a -csc command
-cscp=s change closing side comment prefix to be other than '## end'
-cscl=s change closing side comment to apply to selected list of blocks
-csci=n minimum number of lines needed to apply a -csc tag, default n=6
-csct=n maximum number of columns of appended text, default n=20
-cscw causes warning if old side comment is overwritten with -csc
-sbc use 'static block comments' identified by leading '##' (default)
-sbcp=s change static block comment identifier to be other than '##'
-osbc outdent static block comments
-ssc use 'static side comments' identified by leading '##' (default)
-sscp=s change static side comment identifier to be other than '##'
Delete selected text
-dac delete all comments AND pod
-dbc delete block comments
-dsc delete side comments
-dp delete pod
Send selected text to a '.TEE' file
-tac tee all comments AND pod
-tbc tee block comments
-tsc tee side comments
-tp tee pod
Outdenting
-olq outdent long quoted strings (default)
-olc outdent a long block comment line
-ola outdent statement labels
-okw outdent control keywords (redo, next, last, goto, return)
-okwl=s specify alternative keywords for -okw command
Other controls
-mft=n maximum fields per table; default n=40
-x do not format lines before hash-bang line (i.e., for VMS)
-asc allows perltidy to add a ';' when missing (default)
-dsm allows perltidy to delete an unnecessary ';' (default)
Combinations of other parameters
-gnu attempt to follow GNU Coding Standards as applied to perl
-mangle remove as many newlines as possible (but keep comments and pods)
-extrude insert as many newlines as possible
Dump and die, debugging
-dop dump options used in this run to standard output and quit
-ddf dump default options to standard output and quit
-dsn dump all option short names to standard output and quit
-dln dump option long names to standard output and quit
-dpro dump whatever configuration file is in effect to standard output
-dtt dump all token types to standard output and quit
HTML
-html write an html file (see 'man perl2web' for many options)
Note: when -html is used, no indentation or formatting are done.
Hint: try perltidy -html -css=mystyle.css filename.pl
and edit mystyle.css to change the appearance of filename.html.
-nnn gives line numbers
-pre only writes out <pre>..</pre> code section
-toc places a table of contents to subs at the top (default)
-pod passes pod text through pod2html (default)
-frm write html as a frame (3 files)
-text=s extra extension for table of contents if -frm, default='toc'
-sext=s extra extension for file content if -frm, default='src'
A prefix of "n" negates short form toggle switches, and a prefix of "no"
negates the long forms. For example, -nasc means don't add missing
semicolons.
If you are unable to see this entire text, try "perltidy -h | more"
For more detailed information, and additional options, try "man perltidy",
or go to the perltidy home page at http://perltidy.sourceforge.net