REBOL3 tracker
  0.9.12 beta
Ticket #0002211 User: anonymous

Project:

Previous Next
rss
TypeIssue Statussubmitted Date30-Mar-2015 06:26
Versionr3 master CategoryUnspecified Submitted byfork
PlatformAll Severitymajor Prioritynormal

Summary Rethink Newline and Indentation Handling in multi-line strings
Description It is often the case that one wishes to use a multi-line string in indented code. What *looks* the best would be:

    list [
        item {
            This is multi-line content
            For this particular list item
        }
    ]

Despite looking the best, that is throwing in a leading newline, a trailing newline, and 12 space characters at the start of each line. It is more likely that the author intended to get string data equivalent to:

"This is multi-line content^|For this particular list item"

One current choice is to express the string as:

    list [
        item {This is multi-line content
For this particular list item}
    ]

But a better choice would seem to be to assume that if an open brace has no non-whitespace content after it on a line, it does not suggest a newline...and that if a close brace has no non-whitespace content before it on a line, it does not suggest a newline either. Escaped newlines could be put at the lead or tail of the content, but to keep the first characters "pretty" an escape on the opening brace could be done via the trick from #2210 as ^|^

The next step would be to consider the start of content to be aligned with the leftmost character column in the string. The caret-followed-by-space rule could be extended to mark a different starting column:

    list [
        item {
            This is multi-line content
        ^   But the caret shows us where it actually begins
        }
    ]

In this extension of the rule, the caret marks the column and thus counts as a space itself. It could be on a single line, or on every line for clarity.

Alignment-wise, this isn't as clean when the caret is intended to mark a single space position prior to a non-space character. In those cases, a ^_ escape would need to be used and would add one more "source" character to the string; possibly throwing off the visual alignment. Yet this is likely very uncommon.
Example code

			

Assigned ton/a Fixed in- Last Update31-Mar-2015 04:59


Comments
(0004624)
Gregg
31-Mar-2015 04:59

This ticket, along with the other recent escape-focused tickets, raise important questions. I don't have answers right now, but would like to see them discussed more. We have a few contexts to consider: Literal Redbol that we write, data sourced from somewhere else (e.g., user input), and Ren.

Thanks to Brian for bringing these issues up. Now is a good time to think about them.

Date User Field Action Change
31-Mar-2015 04:59 Gregg Comment : 0004624 Added -
30-Mar-2015 06:29 Fork Description Modified -
30-Mar-2015 06:26 Fork Ticket Added -