Handling of newline in body text

[politza]

If I have a heading like this

* Heading
  Da keine PLZ/Stadt Liste bekannt, sind diese Spalten auch nicht
  funktional abhaengig, denn die Eingaben kommen vom Anwender und
  sind damit von freier Form. (Der erste Anwender wuerde den
  Zusammenhang fuer alle nachfolgenden festlegen.)

it is displayed in orglzy like this

* Heading
    Da keine PLZ/Stadt Liste bekannt,
  sind diese Spalten auch nicht
    funktional abhaengig, denn die
  Eingaben kommen vom Anwender und
    sind damit von freier Form. 
  (Der erste Anwender wuerde den
    Zusammenhang fuer alle
   nachfolgenden festlegen.)

So, every line-break seems to be regarded as the start of a new paragraph. Instead it should be regarded as normal white-space. I feel like I'm doing something wrong. Don't people fill their org-files anymore ?

By the way, thank you for your very useful program.

[nevenz]

Do you use org-adapt-indentation? Perhaps it's not handled well. With not enough horizontal space (so lines wrap).

[rdeterre]

I see the same issue here. To confirm that it is not caused by any setting in org-mode, here is a screenshot of a file with two paragraphs seen in Emacs' fundamental mode. The first paragraph is not filled (it's just one long line), while the second is.

In orgzly, the first paragraph looks OK and the second has line feeds at the "wrong" places.

[nevenz]

Thanks, so that's definitely just line wrapping then. There's not enough horizontal space to display entire line. If you rotate the phone, it might fit.

Support for horizontal scrolling would fix this. See #74.

[rdeterre]

On my phone, 80 character lines do fit with the screen rotated if the font is set to small. On the other hand, it sounds like horizontal scrolling would not solve the issue in portrait mode, with default size fonts or smaller phones. Instead, users would need to scroll horizontally to read every line of text. This would make the app hard to use for example when reading a recipe written with org-chef while cooking.

A solution could be for the paragraphs (and maybe other markup elements ?) to be interpreted from the org markup, rather than displaying the raw text on screen.

[phrxmd]

Is this an orgzly issue or an org-java issue? It seems to be related to the parsing of paragraphs. It should be an easy fix - but one that potentially generates round-trip issues, e.g. if you read a file in Orgzly and it parses your paragraphs and then writes them out again, your line breaks might be gone or might be in different places.

[phrxmd]

Thanks, so that's definitely just line wrapping then. There's not enough horizontal space to display entire line. If you rotate the phone, it might fit.

Support for horizontal scrolling would fix this. See #74.

Actually I disagree with @nevenz and also with the "feature" label. It's a bug. Paragraphs that consist of lines with newlines at the end get mangled in display and are hard to read - not because screens are too small, but because they're treated as lines with newline, not as paragraphs.

[nevenz]

A solution could be for the paragraphs (and maybe other markup elements ?) to be interpreted from the org markup, rather than displaying the raw text on screen.

Paragraphs that consist of lines with newlines at the end get mangled in display and are hard to read - not because screens are too small, but because they're treated as lines with newline, not as paragraphs.

Emacs doesn't do this either. You can toggle-truncate-lines to either cut the lines and have to scroll horizontally to see the rest, or wrap them, in which case you get the same result as in Orgzly (visible line breaks).

if you read a file in Orgzly and it parses your paragraphs and then writes them out again, your line breaks might be gone or might be in different places.

Right, we can't modify user's data, only display it differently in the app.

It could be org-java utility function that recognizes paragraphs and strips new-line characters. That result would be then displayed only in notebook (content in notes list) and notes' view mode. It might be tricky though, as such text is often used together with other stuff, likes tables, lists etc.

[phrxmd]

A solution could be for the paragraphs (and maybe other markup elements ?) to be interpreted from the org markup, rather than displaying the raw text on screen.

Paragraphs that consist of lines with newlines at the end get mangled in display and are hard to read - not because screens are too small, but because they're treated as lines with newline, not as paragraphs.

Emacs doesn't do this either. You can toggle-truncate-lines to either cut the lines and have to scroll horizontally to see the rest, or wrap them, in which case you get the same result as in Orgzly (visible line breaks).

I think Emacs behaviour is not comparable here, not least because Emacs gives you auto-fill-mode which leads to the desired behaviour (an easy-to-read paragraph that maintains indentation). Of course that modifies the data, so it works only if you're unconcerned with leaving user data unmodified. Emacs users probably don't bother about that when editing their org files in text modes, for Orgzly users that may be different.

if you read a file in Orgzly and it parses your paragraphs and then writes them out again, your line breaks might be gone or might be in different places.

Right, we can't modify user's data, only display it differently in the app.

It could be org-java utility function that recognizes paragraphs and strips new-line characters.

And line-initial whitespace; some users format their org-mode text blocks like this:

**** This is a headline
     And this is a block of text. It consists
     of long lines with line breaks at the end, 
     while maintaining constant indentation
     at the same level as the headline.

In Orgzly these paragraphs can become quite awkward to read as soon as your screen is too narrow to accommodate the line length. Zooming, horizontal scrolling etc. would make it a bit easier on the eyes at least. But it would lead to awkward user interaction, e.g. when scrolling you'd have to scroll right and left all the time to read every line.

That result would be then displayed only in notebook (content in notes list) and notes' view mode. It might be tricky though, as such text is often used together with other stuff, likes tables, lists etc.

I agree that inside tables & similar constructs the approach probably wouldn't work. But for a start it would already be useful enough for text and maybe list paragraphs, which I guess is like 99% of most people's org-mode content. If you encounter a table within a paragraph, that's usually an indicator that the paragraph ends :)

[nevenz]

I think Emacs behaviour is not comparable here, not least because Emacs gives you auto-fill-mode which leads to the desired behaviour (an easy-to-read paragraph that maintains indentation). Of course that modifies the data, so it works only if you're unconcerned with leaving user data unmodified. Emacs users probably don't bother about that when editing their org files in text modes, for Orgzly users that may be different.

Yes, I'm mostly concerned about modifying text from Orgzly. I don't think that's the option.

toggle-truncate-lines is presentation-only setting, which is why I think we can use it for comparison.

Another example: If I resize Emacs window, text is not modified if it can't fit the screen anymore.

And line-initial whitespace; some users format their org-mode text blocks like this

It's probably better to handle this when parsing the org file for the first time like it's done for planning times and drawers here (either by detecting it or using a preference).

It's different from paragraphs as it's very closely related to org's (configurable) format. If you were to use JSON (for example) you wouldn't have indenting issue, but you'd still have new-lines/paragraphs in {content: "text"}, as that's user input.

[phrxmd]

Yes, I'm mostly concerned about modifying text from Orgzly. I don't think that's the option.
toggle-truncate-lines is presentation-only setting, which is why I think we can use it for comparison.
Another example: If I resize Emacs window, text is not modified if it can't fit the screen anymore.

I agree that Orgzly shouldn't modify the file just to format it in a pretty way. In Emacs, if you don't work in visual-line-mode, a properly aligned paragraph is always just one M-q away, but at the cost of changing the file.

In Orgzly it should be presentation-only, like enabling format=flowed support for displaying e-mail messages.

It's probably better to handle this when parsing the org file for the first time like it's done for planning times and drawers here (either by detecting it or using a preference).

It's different from paragraphs as it's very closely related to org's (configurable) format. If you were to use JSON (for example) you wouldn't have indenting issue, but you'd still have new-lines/paragraphs in {content: "text"}, as that's user input.

Thanks for the code example, that's very useful.

Some Emacs modes, like Enriched mode, have a distinction between soft and hard newlines. Soft newlines are what occurs inside paragraphs (and can be reflowed). Hard newlines are all other newlines and remain. It's up to the Emacs mode to decide how to treat them.

Maybe there would be a way to distinguish, during parsing, some newlines that are semantically "soft", and offer the option to visually reflow them inside the paragraph during display.