Comparing 96b950755b..3b68f1dc7a - lore

torque/lore

Fork 0

Author	SHA1	Message	Date
torque	3b68f1dc7a	config: add terminated strings This was the final feature I wanted to add to the format. Also some other things have been cleaned up a little bit (for example, the inline parser does not need the dangling key to be attached to each stack level just like the normal parser doesn't). There was also an off-by-one error that bugged out detecting the pathological case of a flow list consisting of only an empty string (`[ ]`, not to be mistaken for the empty list `[]`). Mixed multiline strings are a bit confusing but internally consistent. > what character does this string end with? \| ends with a newline character because that's the style of the second-to-last line. However, seeing \| last makes my brain think it should end with a space. The reason it ends with a newline is because our concatenation strategy consists of appending to the string early (as soon as a line is added) rather than lazily. This is a tradeoff, though. while lazy appending would make this result more intuitive (the string would end with a space) and it would allow us to remove the self-proclaimed cheesy hack, it would make the opposite boundary condition a confusing: > \| what character does this string start with? With lazy appending, this string would start with a space (despite > making it look like it should start have a leading newline). While both of these are likely to be uncommon edge cases, it doesn't seem we can have it both ways. Of the two options, I think the current logic is a little bit more clear.	2023-09-17 23:09:26 -07:00

Author

SHA1

Message

Date

torque

3b68f1dc7a

config: add terminated strings

This was the final feature I wanted to add to the format. Also some
other things have been cleaned up a little bit (for example, the
inline parser does not need the dangling key to be attached to each
stack level just like the normal parser doesn't). There was also an
off-by-one error that bugged out detecting the pathological case of a
flow list consisting of only an empty string (`[ ]`, not to be
mistaken for the empty list `[]`).

Mixed multiline strings are a bit confusing but internally consistent.

    > what character does this string end with?
    |

ends with a newline character because that's the style of the
second-to-last line. However, seeing | last makes my brain think it
should end with a space. The reason it ends with a newline is because
our concatenation strategy consists of appending to the string early
(as soon as a line is added) rather than lazily. This is a tradeoff,
though.  while lazy appending would make this result more intuitive
(the string would end with a space) and it would allow us to remove
the self-proclaimed cheesy hack, it would make the opposite boundary
condition a confusing:

    >
    | what character does this string start with?

With lazy appending, this string would start with a space
(despite > making it look like it should start have a leading
newline). While both of these are likely to be uncommon edge cases, it
doesn't seem we can have it both ways. Of the two options, I think the
current logic is a little bit more clear.

2023-09-17 23:09:26 -07:00

1 changed files with 785 additions and 834 deletions

1113

src/config.zig

View File

File diff suppressed because it is too large Load Diff

Compare commits

1 Commits

master ... 3b68f1dc7a

1113

src/config.zig

View File

Compare commits

1 Commits master ... 3b68f1dc7a

1113 src/config.zig View File

1 Commits

master ... 3b68f1dc7a

1113

src/config.zig

View File