Long lines of text are very hard to read and follow. This is one of the reasons people limit line lengths to e.g. 80. It's also true for printed books - they aren't anywhere as wide as conputer screens.
It's easy to limit to 80 lines by changing the browser window size, but people usually have it maximized. Perhaps either provide a hint - "it's recommended to resize the browser window to X" - or, if possible, add JS code to resize or code HERITAGE to print 80-column text.
Joining
I see the wrapping problem only with few texts, because I write heritage files in 80 columns, so no wrapping happens most of the time. But then I have another problem: Lines are too short. I write descriptions etc. with indentation:
room(0.0.0):
description: line 1
line 2
line 3
So HERITAGE displays very very short lines. If it could join lines like in Markdown, and then wrap to e.g. 80 columns, the source text formatting would be flexible and independent of the presentation.
# Wrapping
Long lines of text are very hard to read and follow. This is one of the reasons people limit line lengths to e.g. 80. It's also true for printed books - they aren't anywhere as wide as conputer screens.
It's easy to limit to 80 lines by changing the browser window size, but people usually have it maximized. Perhaps either provide a hint - "it's recommended to resize the browser window to X" - or, if possible, add JS code to resize or code HERITAGE to print 80-column text.
# Joining
I see the wrapping problem only with few texts, because I write heritage files in 80 columns, so no wrapping happens most of the time. But then I have another problem: Lines are too short. I write descriptions etc. with indentation:
room(0.0.0):
description: line 1
line 2
line 3
So HERITAGE displays very very short lines. If it could join lines like in Markdown, and then wrap to e.g. 80 columns, the source text formatting would be flexible and independent of the presentation.
I actually completely disagree that shorter lines are easier to read. Personally, I prefer my lines to be as long as the screen, and the current ability to resize your browser window to choose the length of the text seems pretty user-friendly to me. At most, I may consider an option to limit the line length without making your browser window smaller, but I am not defaulting to 80 columns.
I also don't agree that HERITAGE should add additional code to join lines. If you add a newline character, it simply becomes a newline character. The way Markdown does it is actually one of my pet peeves, as it always messes up newlines for me. A new line is a new line is simply the easiest and most consistent way to work with newlines. I feel it'd be much better to just make your text editor soft-wrap at 80 columns if that's what you prefer editing in.
I actually completely disagree that shorter lines are easier to read. Personally, I prefer my lines to be as long as the screen, and the current ability to resize your browser window to choose the length of the text seems pretty user-friendly to me. At most, I may consider an option to limit the line length without making your browser window smaller, but I am not defaulting to 80 columns.
I also don't agree that HERITAGE should add additional code to join lines. If you add a newline character, it simply becomes a newline character. The way Markdown does it is actually one of my pet peeves, as it always messes up newlines for me. A new line is a new line is simply the easiest and most consistent way to work with newlines. I feel it'd be much better to just make your text editor soft-wrap at 80 columns if that's what you prefer editing in.
In some cases, you may wish to format the text in some special way, intentionaly, and then auto-folding will ruin the formatting. So perhaps if folding etc. exists, it should be optional.
As to screen size, many people have wide screens. With several lines of text so wide, it takes some time to move your eyes from the ending of a line to the beginning of the next, and it's common to not immediately find the next line. You can accodentally re-read the same line, or skip a line. I don't have scientific data to back this, but you're right people can just resize. Since mentioning this issue inside HERITAGE can be done inside the games, I suppose it doesn't have/need to be in the engine itself.
For example I could include in one of my game, say in first_enter, a recommendation to resize the window.
But none of that solves the issue of gaps, which imho will benefit from some newline folding. When $(...)$ evaluates to false, I don't want the newlines to remain, because there's a blank gap in the middle of the text.
Hmmm this made me think.
In some cases, you may wish to format the text in some special way, intentionaly, and then auto-folding will ruin the formatting. So perhaps if folding etc. exists, it should be optional.
As to screen size, many people have wide screens. With several lines of text so wide, it takes some time to move your eyes from the ending of a line to the beginning of the next, and it's common to not immediately find the next line. You can accodentally re-read the same line, or skip a line. I don't have scientific data to back this, but you're right people can just resize. Since mentioning this issue inside HERITAGE can be done inside the games, I suppose it doesn't have/need to be in the engine itself.
For example I could include in one of my game, say in `first_enter`, a recommendation to resize the window.
But none of that solves the issue of gaps, which imho will benefit from *some* newline folding. When `$(...)$` evaluates to false, I don't want the newlines to remain, because there's a blank gap in the middle of the text.
A workaround for the issue with a blank gap when a paragraph surrounded in $()$ evaluates to false, is to end the $()$ part on the next line. So instead of:
First paragraph
$(require_here:something;Something is here.)$
Third paragraph
Use:
First paragraph
$(require_here:something;Something is here.
)$
Third paragraph
This will ensure that the extra newline also won't be shown when the expression is evaluated to false.
A workaround for the issue with a blank gap when a paragraph surrounded in `$()$` evaluates to false, is to end the `$()$` part on the next line. So instead of:
```
First paragraph
$(require_here:something;Something is here.)$
Third paragraph
```
Use:
```
First paragraph
$(require_here:something;Something is here.
)$
Third paragraph
```
This will ensure that the extra newline also won't be shown when the expression is evaluated to false.
I don't know why, but some of my newlines didn't show, let's try again, this time with (newline) on every empty line. Instead of:
First paragraph
(newline)
$(require_here:something;Something is here.)$
(newline)
Third paragraph
Use:
First paragraph
(newline)
$(require_here:something;Something is here.
)$
Third paragraph
I don't know why, but some of my newlines didn't show, let's try again, this time with (newline) on every empty line. Instead of:
```
First paragraph
(newline)
$(require_here:something;Something is here.)$
(newline)
Third paragraph
```
Use:
```
First paragraph
(newline)
$(require_here:something;Something is here.
)$
Third paragraph
```
In my opinion, this should be closed. Whoever puts the game on his website has full control over the width
of the game area and can set whatever width he wants. Or am I missing something?
In my opinion, this should be closed. Whoever puts the game on his website has full control over the width
of the game area and can set whatever width he wants. Or am I missing something?
Wrapping
Long lines of text are very hard to read and follow. This is one of the reasons people limit line lengths to e.g. 80. It's also true for printed books - they aren't anywhere as wide as conputer screens.
It's easy to limit to 80 lines by changing the browser window size, but people usually have it maximized. Perhaps either provide a hint - "it's recommended to resize the browser window to X" - or, if possible, add JS code to resize or code HERITAGE to print 80-column text.
Joining
I see the wrapping problem only with few texts, because I write heritage files in 80 columns, so no wrapping happens most of the time. But then I have another problem: Lines are too short. I write descriptions etc. with indentation:
So HERITAGE displays very very short lines. If it could join lines like in Markdown, and then wrap to e.g. 80 columns, the source text formatting would be flexible and independent of the presentation.
I actually completely disagree that shorter lines are easier to read. Personally, I prefer my lines to be as long as the screen, and the current ability to resize your browser window to choose the length of the text seems pretty user-friendly to me. At most, I may consider an option to limit the line length without making your browser window smaller, but I am not defaulting to 80 columns.
I also don't agree that HERITAGE should add additional code to join lines. If you add a newline character, it simply becomes a newline character. The way Markdown does it is actually one of my pet peeves, as it always messes up newlines for me. A new line is a new line is simply the easiest and most consistent way to work with newlines. I feel it'd be much better to just make your text editor soft-wrap at 80 columns if that's what you prefer editing in.
Hmmm this made me think.
In some cases, you may wish to format the text in some special way, intentionaly, and then auto-folding will ruin the formatting. So perhaps if folding etc. exists, it should be optional.
As to screen size, many people have wide screens. With several lines of text so wide, it takes some time to move your eyes from the ending of a line to the beginning of the next, and it's common to not immediately find the next line. You can accodentally re-read the same line, or skip a line. I don't have scientific data to back this, but you're right people can just resize. Since mentioning this issue inside HERITAGE can be done inside the games, I suppose it doesn't have/need to be in the engine itself.
For example I could include in one of my game, say in
first_enter, a recommendation to resize the window.But none of that solves the issue of gaps, which imho will benefit from some newline folding. When
$(...)$evaluates to false, I don't want the newlines to remain, because there's a blank gap in the middle of the text.A workaround for the issue with a blank gap when a paragraph surrounded in
$()$evaluates to false, is to end the$()$part on the next line. So instead of:Use:
This will ensure that the extra newline also won't be shown when the expression is evaluated to false.
I don't know why, but some of my newlines didn't show, let's try again, this time with (newline) on every empty line. Instead of:
Use:
In my opinion, this should be closed. Whoever puts the game on his website has full control over the width of the game area and can set whatever width he wants. Or am I missing something?