Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Whitespace handling #18

Open
tmedwards opened this issue Apr 29, 2020 · 6 comments
Open

Whitespace handling #18

tmedwards opened this issue Apr 29, 2020 · 6 comments
Assignees
Labels
enhancement New feature or request investigate Information gathering is needed

Comments

@tmedwards
Copy link
Owner

Should whitespace handling be changed? Currently, there are a couple basic mechanisms to control line breaks, but not much more than that.

Spacing control

There are no current spacing control mechanisms.

Line break control

The two basic mechanisms of line break control are (in order of implementations): line continuations and the no-break features—in order: nobr tag, <<nobr>> macro, Config.passages.nobr setting.

Line continuations: (markup-based)

  • Pros: Allow precise control over line breaks by eliding them.
  • Cons: Must be used consistently.

No-breaks: (source editing-based)

  • Pros: Do not require consistent use, being more fire-and-forget.
  • Cons: Sloppier control over line breaks by converting them to spaces.
  • Issues: Incompatible with any markup that requires line positioning—e.g., line continuations, headings, etc—and can break <<script>> code.

A potential fix for both of the issues of the no-break features would be to make them, essentially, markup-based as well by simply having them disable the lineBreak parser. The downside would be that the nobr tag could not be converted over thus and would need to be dropped, leaving only the macro and global setting.

@greyelf
Copy link

greyelf commented Apr 29, 2020

What are the downsides of reversing the behaviour?

  1. End-of-line Line-breaks are automatically removed (not replaced)
  2. The end-user needs to uses standard HTML means for adding 'spacing' between elements.
    eg. <br> <p> <div> &npsp; etc...
  3. [optional] Multiple consecutive line-breaks are replaced with either (1 or more)<br> elements or a 'wrapper' element around the previous block of content?

@tmedwards
Copy link
Owner Author

tmedwards commented Apr 29, 2020

Sorry, I'm not following. Reversing which behavior?

If you mean make the no-break features work by removing line breaks, then both issues are largely unaffected—i.e., they're still issues. The specific problem there isn't what's being done so much as how it's being done—i.e., modifying the source before anything else sees it versus as part of normal process—though, what's being done is sub-optimal as well.

@greyelf
Copy link

greyelf commented Apr 30, 2020

What I meant is changing the processing so that it treats line-breaks the same way that a web-browser do when they are encounter in HTML, (eg. it ignores them, unless in <pre> etc...)
And instead teach the end-user to use HTML means (or a form of markup) for spacing out content.

@tmedwards
Copy link
Owner Author

So, remove the lineBreak parser and no-break features. 😲

That's definitely an idea, though, like the changing the syntax one, it's on the outer limits.

What I mean is that lots of users do use the no-break features, but my feeling is that those are the squeaky wheels and most actually do make use of the lineBreak parser. Ditching it has the potential to break a lot of layouts.

I do like the idea in principle though.

@ChapelR
Copy link

ChapelR commented Apr 30, 2020

If blocks are introduced (I recognize that this is a suggestion on a suggestion on a suggestion) you could add features like nobr and even silently to the blocks themselves through some sort of syntax. Maybe tags or some other syntax element at the start of a block.

@tmedwards tmedwards transferred this issue from another repository Aug 2, 2020
@tmedwards tmedwards self-assigned this Aug 2, 2020
@tmedwards tmedwards added enhancement New feature or request investigate Information gathering is needed labels Aug 2, 2020
@Uzume
Copy link

Uzume commented Oct 20, 2020

If you reverse the behavior, that does not mean you cannot still have means to optionally turn it back on--you could by default ignore newlines much like the browser does and fall back to the scv2 default behavior upon nlbr tag, <<nlbr>> macro, Config.passages.nlbr setting to turn it back on.

I picked "nlbr" because it was short (in fact the same size as "nobr") and means "newline break" meaning newlines get treated as markup and are turned into line breaks (<br>, <p>, <div>, etc.) in the output. In fact that could be an argument (at least to the macro and config setting) to tell which type of breaking the author wanted newlines turned in to.

This was referenced Oct 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request investigate Information gathering is needed
Projects
None yet
Development

No branches or pull requests

4 participants