|
1 |
| -# SwiftFormat Pretty Printer |
| 1 | +# swift-format Pretty Printer |
| 2 | + |
| 3 | +> :warning: **NOTE:** Some of the information in this document is out of date |
| 4 | +> and needs to be rewritten. |
2 | 5 |
|
3 | 6 | ## Introduction
|
4 | 7 |
|
5 |
| -The algorithm used in the SwiftFormat pretty printer is based on the "simple" |
| 8 | +The algorithm used in the swift-format pretty printer is based on the "simple" |
6 | 9 | version of the algorithm described by Derek Oppen in his paper [*Pretty
|
7 | 10 | Printing*](http://i.stanford.edu/pub/cstr/reports/cs/tr/79/770/CS-TR-79-770.pdf)
|
8 | 11 | (1979). It employs two functions: *scan* and *print*. The *scan* function
|
9 | 12 | accepts a stream of tokens and calculates the lengths of these tokens. It then
|
10 | 13 | passes the tokens and their computed lengths to *print*, which handles the
|
11 | 14 | actual printing of the tokens, automatically inserting line breaks and indents
|
12 | 15 | to obey a given maximum line length. We describe in detail how these functions
|
13 |
| -have been implemented in SwiftFormat. |
| 16 | +have been implemented in swift-format. |
14 | 17 |
|
15 | 18 | ## Tokens
|
16 | 19 |
|
@@ -434,7 +437,7 @@ value is appended to the length array, and added to `total`.
|
434 | 437 | ## Print
|
435 | 438 |
|
436 | 439 | The purpose of the *print* phase is to print the contents of a syntax node to
|
437 |
| -the console or to append it to a string buffer as we do in SwiftFormat. It |
| 440 | +the console or to append it to a string buffer as we do in swift-format. It |
438 | 441 | tracks the remaining space left on the line, and it decides whether or not to
|
439 | 442 | insert a line break based on the length of the token. It uses the following
|
440 | 443 | variables to track state in between calls to `print`:
|
@@ -551,14 +554,14 @@ equivalent to the maximum line width.
|
551 | 554 | ## Differences from Oppen's Algorithm
|
552 | 555 |
|
553 | 556 | For those who might already be familiar with Oppen's pretty-printing algorithm,
|
554 |
| -described below are ways in which SwiftFormat's pretty-printer differs from |
| 557 | +described below are ways in which swift-format's pretty-printer differs from |
555 | 558 | Oppen's.
|
556 | 559 |
|
557 | 560 | ### Absence of a "stream"
|
558 | 561 |
|
559 | 562 | Oppen's algorithm was designed to run like a server. It accepts tokens one at a
|
560 | 563 | time ad infinitum, so it requires a buffer to accumulate tokens. It prints them
|
561 |
| -out as it goes along. All of SwiftFormat's tokens are already available as an |
| 564 | +out as it goes along. All of swift-format's tokens are already available as an |
562 | 565 | array in memory, so we don't need a buffer. We access the token array directly,
|
563 | 566 | rather than using a separate `stream`.
|
564 | 567 |
|
|
0 commit comments