Bug 208309 - [formatter] RFE: smarter management of indentation margins overflows
Summary: [formatter] RFE: smarter management of indentation margins overflows
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 enhancement with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-10-31 15:47 EDT by Philippe Verdy CLA
Modified: 2008-06-06 04:27 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Philippe Verdy CLA 2007-10-31 15:47:04 EDT
Build ID: 3.1.0

Steps To Reproduce:
Currently there are options in the editor to set the indentation size (4 spaces per indentation level), and an option to set the maximum line length.

However in some code, the indentation goes so far that it it can even exhast the maximum line length, or leaves a ridiculous number of usable positions in the line.

I'd like to have an option that allows specifying a "maximum indentation margin" (for example 40 characters, for linesize=80). If this option is enabled, then another option can be selected that
* either forbids adding other indentation
* or allows the indentation to "cycle back to a lower indentation level", with several choices: for example the level of the content of the block of the declaring member, or the level of the block of the top-level declaring class/interface (this should be level 1, i.e. 4 spaces by default, but will be controled by the respective indentation settings), or simply a fixed left margin position (for example the first column, i.e. no space margin). This choice will be used to compute the "minimum indentation margin".

This would really make the code easier to read, by avoiding excessive linewraps, while still allowing easy identification of block levels. Example:

 Level 1
     Level 2
         Level 3
            Level 4
                Level 5
     Level 6 // cycles indentation back to lower level (2 instead of 6)
         Level 7 // use level 3 instead of 7...
             Level 8
                Level 9
     Level 10
         Level 11
     Level 10
                Level 9
             Level 8
         Level 7
     Level 6
               Level 5
               Level 5
           Level 4
           Level 4
               Level 5
           Level 4
       Level 3
       Level 3
           Level 4
       Level 3
    Level 2
 Level 1

(In this example, the max level is set to a small value, but most common settings would be to set linesize between 72 and 80 columns, and max indentation margin between 40 and 60 columns). To compute the effective indentation margin for an indentation level, you just need a simple modulo operation, by first computing the minimum column number according to the preference (here I show an example with a minimum indentation margin computed and equal to 4 according to the user preference).

Finally, for indenting expressions, there should be an option so that all operands of binary operators (including the assignment operator or method parameters that have the same priority are indented identically: either they can fit on the current line without any linewrap within them, or they will wrap before the whole element as necessary, and then will be indented at the same level as other operands at the same expression priority level. The information should come from the expression parser.

So instead of:

   <----- LINE ------>
   x = a * b + c * d *
       2 + e * f + g *
       h + x;

I'd like to have the expression parsed as an additive expression where all terms are a complete unit ("a * b", "c * d * 2", "e * f", "g * h", "x") that must wrap and indent equally if they wrap:

   <----- LINE ------>
   x = a * b +
       c * d * 2 +
       e * f +
       g * h + x;

(note that "x" fits in the mximum line length, so it does not wrap here.)
This grouping is much more logical, and makes expressions much easier to read and understand. The idea is that expressions are parsed at each priority level, forming a list of operands; each operand will then try to fit in the current line size set by the current indentation level, and if it does not fit, then it will be broken first into its operands at the same grouping level, but recursively indenting them for the next priority level.

Here also, the priority levels should be converted into margin positions using the settings for the "maximum indentation margin" (and "minimum indentation margin" if indendation cycling is enabled).

Finally, the contents of parentheses should have the same options as braces (including the possibility of aligning the matching parenthese pairs, if the content contains linewraps, by forcing a final wrap beore the closing parenthese.) This would help reading complex expressions that have lots of parenthesesn notably within code generated automatically by external tools like ANTLR (a parser/lexer generator), or code optimizers.