This would be super tricky, cause where would we store this metadata? It really would need to be in raw which would involve a pretty ugly HTML comment or something.
I don’t know how feasible this would be to actually implement, but would it be possible to define a bbcode ‘block’ which changes the line break rules? (in a plugin)
So you would end up with something like:
This text
is on different lines
[md-linebreaks]
This text
will all be
on the same
line.
This is
another line
[/md-linebreaks]
That way it could be available to power users, without needing any metadata attached to the post
The current spec says “A renderer may also provide an option to render soft line breaks as hard line breaks.”, which I take to mean that a rendere might have an option, like a commandline or configuration option, to render hardbreaks instead of softbreaks. Even though this seems like a solution, it’s not, due to lack of granularity.
More specifically, this would mean you could turn this option on or off for a single user or perhaps even system. However, a single user might have different needs in different documents and, as shown above, even different needs within a document.
If we could somehow detect between the different types of “paragraphs” (or rather, distinguish between a paragraph and a group of lines) without adding markupt for that this would be great. Comment #41 has a proposal for this, but I simply don’t think we can come up with something that works in enough cases, so the second-best option would be to somehow mark a single paragraph, or a block of markdown, to use hard-rendered linebreaks?
I’m thinking about something along the lines of the ``` syntax that can be prefixed and postfixed to a list of blocks to make linebreaks inside them rendered hard.
In many ways, what we’re proposing here is exactly that. Within Discourse, BBCode blocks work well already for things like [details="foo"]. Maybe that’s the easiest place to start here.
But I’m also wondering whether there’s something more generic here as feedback/input we can provide upstream to commonmark to allow for blocks within a doc to use different rendering options. Do you think it’s worth exploring that further as well?
To be honest with you, its VERY super DUPER hard to convince CommonMark to make any changes. Even trivial things like image dimensions are still being discussed after years and years.
I would not count on anything really happening there, the ship is just too big to steer and the project is incredibly change averse and laser focused on just attacking the thousands of edge cases Markdown presents.
I’m curious why you think the plugin route in particular is the right place to start with this. Is this the kind of thing that may eventually make it’s way into core?
I don’t think it is too likely we will add this to core. Since this must run server side, the only other option is a plugin. Theme components have no mechanism for running server side, by design.
Что ж, это во многом зависит от того, куда вы смотрите. Рендеринг файла Markdown на GitHub или на страницах GitHub использует традиционные переносы строк. Отсутствие физических разрывов строк в тексте абзаца неудобно для отслеживания изменений, поэтому добавление неотображаемых физических разрывов строк крайне полезно для значительных текстов, которые развиваются. Многие (хотя и не большинство) сообщения на форумах обладают этим свойством.
Только в более неформальных контекстах, таких как комментарии к задачам и pull-запросам, GitHub использует нетрадиционный («GitHub Flavored») Markdown, где одиночные переносы строк имеют значение. Я уверен, что они сделали это как уступку разработчикам, которые могут быстро набрать небольшой фрагмент кода в задаче, не отступая его и не заключая в тройные обратные кавычки.
Таким образом, нетрадиционный Markdown на самом деле является более ориентированным на разработчиков выбором. Вас никто не обязывает разбивать длинные строки при вводе сообщения на форуме, и, исходя из моего опыта, большинство людей хотят видеть пустую строку между абзацами как при вводе Markdown, так и при его отображении, поэтому для большинства людей настройка по умолчанию не имеет никаких преимуществ.
