Perltidy TODO List
    This is a "wish-list" of features to add and things to do. All of these
    are of interest, but there is no particular schedule for implementing
    them.

  XML Output
    The ability to write a tokenized script in XML format looks very useful.
    This would allow the creation of simple utilities to reliably manipulate
    perl code.

    The output will be controlled by a switch --format=s, or simply -f=s,
    where s would be html, xml, or tidy. The current -html flag would be
    mapped into -format=html.

  Fix numerous little formatting issues
    There is, and always will be, a large number of relatively minor
    formatting issues that need to be addressed. I'm working on them as time
    permits. Some of the most interesting have to do with automatically
    deciding the best number of columns to use for a table.

  BUGS
    There are still a couple of bugs listed in the BUGS file that need to be
    fixed. These are low priority compared to formatting issues, but need to
    be done.

  improved ?: formatting
    I intend to associate an indentation level with ?: statements in a
    future release. this will make nested ?: statements more readable.

  Improved Vertical Alignment
    Coding modifications are underway to improve the vertical alignment
    logic.

  Implement 'Vertical Tightness' parameters
    At present, perltidy usually breaks open container when they contain
    multiple lines. For example, using perltidy -lp,

            %romanNumerals = (
                               one   => 'I',
                               two   => 'II',
                               three => 'III',
                               four  => 'IV',
                               five  => 'V',
                               six   => 'VI',
                               seven => 'VII',
                               eight => 'VIII',
                               nine  => 'IX',
                               ten   => 'X'
            );

    Some prefer to keep the container unbroken, if possible, like this:

            %romanNumerals = ( one   => 'I',
                               two   => 'II',
                               three => 'III',
                               four  => 'IV',
                               five  => 'V',
                               six   => 'VI',
                               seven => 'VII',
                               eight => 'VIII',
                               nine  => 'IX',
                               ten   => 'X');

    Parameters to control this are being studied. They could be, for
    example, paren-vertical-tightness, square-bracket-vertical-tightness,
    brace-vertical-tightness. This update requires further development of
    the vertical alignment logic, and will probably be implemented in steps.

  Documentation
    A FAQ is being written to explain some of the more subtle formatting
    issues, and to give examples of different styles.

    The tokenizer needs extensive documentation before it can be released as
    a separate module.

  HTML writer
    The HTML writer does not colorize interpolated identifiers in here
    documents or quoted strings. The tokenizer outputs interpolation
    information for here docs; it still needs to be updated to do this for
    multiline quotes. Then code needs to be written to scan for and markup
    identifiers.

  Further Modularization
    The current version, which uses just a single module, will be further
    subdivided.

  Tokenization issues
    There are some subtle issues with distinguishing block types that should
    be addressed to make the tokenizer more correct, even though they do not
    interfere with code beautification. For example, in most cases the type
    of a brace is known when it is encountered. But given this coding

     sub something {
         {
            bla, bla
         }
         ..
     }

    we have to examine the first couple of tokens of the interior braces to
    see if it is a code block or anonymous hash reference. This needs to be
    done. Also, brace types of something like ${ ... } are not currently
    labeled as code blocks because this simplifies formatting. However, this
    should be done eventually for correctness.

    Token type 'M' (for Method) has been reserved for subroutine definition
    names. It needs to be implementd; I've patched around this in the html
    writer for now. I'm considering new token types for prototypes and
    attributes, to simplify parsing and formatting.

  Outdent block comments as a group
    At present, the decision to outdent a long block comment, when that
    option is used, is made on a line-by-line basis. Instead, the decision
    should be made for a sequence of comments as a group, so that the result
    is not ragged. This is a relatively straightforward update.

  Option to reformat block comments
    I'm looking into an option to use Text::Autoformat to reformat comments.
    Thanks to Tim Maher for this suggestion. I made some preliminary tests
    on code from a variety of sources and decided that this is probably best
    left for an interactive tool, something like a spelling checker, which
    would walk through a file looking for groups of comments, and present a
    proposed a reformatting to the user with a Y/N response request.

    One way to do this would be to first implement the XML feature mentioned
    above, and then write a separate utility to read and process the XML.

  Switch/Case formatting
    There is a request to have perltidy format switch/case statements.

