[Docutils-develop] [docutils:feature-requests] Re: #85 Enable easily-typed hard line-breaks in paragraphs.

[jon <j7...@us...>]

Günter Milde wrote:
>I would not like to read a novel with "semantic line breaks".

Neither would I.  :)

Not *everything* I write has semantic breaks,
but in explanatory writing, I think they can help comprehension,
when combined with clear simple sentence structure.

A few lines I wrote yesterday provide a good *example* of how I use them,
as well as being a *description* of how I use them:

>I break lines on sentence breaks,
sometimes on phrase breaks within sentences,
and sometimes just to make line lengths close to equal.
>
>I don't like to let line-breaking be semantically random,
as it is when allowed to wrap to whatever the page width is. 

And of course, as you can see in my messages,
where a semantic break can be made at a reasonable line length,
I make it, rather than make a non-semantic break a few words later.
This is second nature to me now, not much extra thought is required.

I'm not too keen on the idea of "semantic empty lines",
as I hope to be able to write in the way that comes to me naturally,
without thinking about extra artifice to  achieve the desired result.

Very short paragraphs are common in punchy journalistic writing,
but that style doesn't often suit my subject matter.

Thanks anyway.  :)



---

** [feature-requests:#85] Enable easily-typed hard line-breaks in paragraphs.**

**Status:** open
**Group:** Default
**Labels:** linebreaks 
**Created:** Sat Jan 01, 2022 08:21 AM UTC by jon
**Last Updated:** Sun Jan 02, 2022 12:19 PM UTC
**Owner:** nobody


During the last few weeks I've spent some time
carefully studying reStructuredText and Python-Markdown.

I would prefer to write with reStructuredText,
but Markdown has one feature that is lacking in reST:
easy-to-type line-breaks in paragraphs.

I'm addicted to semantic line breaking.
I think in medium-length phrases that can fit in one line.
Probably this was heightened by working with video subtitles,
but I've always felt that prose can be understood more quickly
if the line-breaks fall between semantic units.

Even when I can't make semantic units fit neatly,
I still like to control where the lines break.

An extension for Python-Markdown, nl2br,
completely disables markdown's removal of line-breaks,
so I can simply write the way I usually do.

With another markdown extension, you type a backslash
to indicate that you want to keep the following line-break.

I'm aware of the methods available in reST:
starting every line of a block with `| `,
or typing something like `|br|` at the end of a line.
They're not really suitable to use with every line of every paragraph.

Perhaps the removal of line-breaks from paragraphs is baked so deeply into reST 
that it's not practical to change the current behaviour?

Anyway, my question/feature-request is: can you make 
either or both of the following methods available to users?

1. Preferably, set a document-wide parameter 
   that causes actual line-breaks in paragraphs to be kept.

2. If that's not practical, create a hard line-break 
   by typing a backslash immediately before a line-break 
   (with or without a space before the backslash).

I'd like to convert my reST docs to html5, using `<br>\n` for line breaks.

I don't understand why arbitrary line-breaks are the norm. In early email and code editors line length was limited, but I don't see why any form of markup or markdown expects people to insert them these days. When I don't want semantic breaks, I simply don't insert any breaks at all, and then a paragraph is a single unbroken line that gets wrapped at the margins. Why isn't *this* the norm?

Hope my point of view makes at least a little sense to you.



---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.