In LongLineBreaker.pas, why does PositionScore() have to use indexes. This is screwing up the whole object-orientedness of that class. I just can not grasp what is going on in there.
Can you not put that code in TSourceToken or TParseTreeNode so that it calculates PositionScore value for itself against another (supplied) Token.
Another one:
In PreProcessorParseTree.pas, why does TPreProcessorParseTree class have to keep a 'current item index'?
To understand what might be going on, one has to study and understand the whole X thousand lines.
This is not fair on posterity --or even the human race. Can't you get rid of that, and let the called function return the current index.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
LongLinebreaker is probably the most difficult of the formatting processes. Not difficult to understand (though it probably is that) but difficult to write. I spent a lot of time on it. This is because it does a difficult task. Where (and if) to break a line is a matter of taste and judgment, and people will never agree completely on these.
The indenter is also complex, but its decisions are easier to classify as "correct" or "incorrect", not just "worse" or "better".
In an ideal world there would be 2 or 3 different linebreakers written by different people, and the user would select the one whose style they preferred. In an ideal world the users would have the time and energy to understand something that complex :)
PositionScore is really just encoding the fuzzy feeling that it's best to break the line near the end of the line (MaxLineLength), but that is not symmetrical - the "goodness" of the position for linebreaking drops of sharply to the right, but slowly to the left. And if you break the line before the first bit of text, that's also useless.
The PositionScore algorithm considers the point that the point 3/4 of the way from the start of the line to MaxLineLength is best for line breaking.
If you uncomment the text at the end of the longlinebreaker file, it will generate a text file, which if imported into excel and graphed, will show you the shape of the position scoring function.
This score for position is combined with score for bracket nesting level (BracketScore), and for breaking really near the end of the line's text (NearEndScore) and for the particular token (e.g. break after a '+', not before, ) in ScoreToken.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Can you not put that code in TSourceToken or TParseTreeNode so that it calculates PositionScore value for itself against another (supplied) Token.<
PositionScore is only needed by the LongLinebreaker, and is a particular of this Linebreaker's aesthetic sense. It's not fundamental to the TSourceToken, and is better hidden in the line breaker unit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
TpreProcessorParseTree keeps an index because for the same reason that BuildParseTree now uses one - to scan through the unit, which has by this stage been digested into a list of tokens, and process them.
In this case however, the intent is to mark some of the tokens as PreProcessedOut = true so that BuildParseTree won't even look at them.
e.g all the code between '{$IFDEF FOO}' and '{$ENDIF}' could be marked PreProcessedOut = true.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In LongLineBreaker.pas, why does PositionScore() have to use indexes. This is screwing up the whole object-orientedness of that class. I just can not grasp what is going on in there.
Can you not put that code in TSourceToken or TParseTreeNode so that it calculates PositionScore value for itself against another (supplied) Token.
Another one:
In PreProcessorParseTree.pas, why does TPreProcessorParseTree class have to keep a 'current item index'?
To understand what might be going on, one has to study and understand the whole X thousand lines.
This is not fair on posterity --or even the human race. Can't you get rid of that, and let the called function return the current index.
LongLinebreaker is probably the most difficult of the formatting processes. Not difficult to understand (though it probably is that) but difficult to write. I spent a lot of time on it. This is because it does a difficult task. Where (and if) to break a line is a matter of taste and judgment, and people will never agree completely on these.
The indenter is also complex, but its decisions are easier to classify as "correct" or "incorrect", not just "worse" or "better".
In an ideal world there would be 2 or 3 different linebreakers written by different people, and the user would select the one whose style they preferred. In an ideal world the users would have the time and energy to understand something that complex :)
PositionScore is really just encoding the fuzzy feeling that it's best to break the line near the end of the line (MaxLineLength), but that is not symmetrical - the "goodness" of the position for linebreaking drops of sharply to the right, but slowly to the left. And if you break the line before the first bit of text, that's also useless.
The PositionScore algorithm considers the point that the point 3/4 of the way from the start of the line to MaxLineLength is best for line breaking.
If you uncomment the text at the end of the longlinebreaker file, it will generate a text file, which if imported into excel and graphed, will show you the shape of the position scoring function.
This score for position is combined with score for bracket nesting level (BracketScore), and for breaking really near the end of the line's text (NearEndScore) and for the particular token (e.g. break after a '+', not before, ) in ScoreToken.
> Can you not put that code in TSourceToken or TParseTreeNode so that it calculates PositionScore value for itself against another (supplied) Token.<
PositionScore is only needed by the LongLinebreaker, and is a particular of this Linebreaker's aesthetic sense. It's not fundamental to the TSourceToken, and is better hidden in the line breaker unit.
TpreProcessorParseTree keeps an index because for the same reason that BuildParseTree now uses one - to scan through the unit, which has by this stage been digested into a list of tokens, and process them.
In this case however, the intent is to mark some of the tokens as PreProcessedOut = true so that BuildParseTree won't even look at them.
e.g all the code between '{$IFDEF FOO}' and '{$ENDIF}' could be marked PreProcessedOut = true.