高级帖子选项以覆盖 Markdown 换行设置

贡献 功能
1

Some of our advanced markdown users have been bitten by our default setting for linebreaks:

image

After furiously typing beautiful prose in vim, they paste it into the composer and are befuddled and ridiculed because their post looks like this:

I’m trying to get people in general
(and engineers more specifically)
to pair on prose.

Using an editor with line numbers,
and breaking things up by clause,
makes pairing more natural and easier.

Would it be feasible to have an advanced composer option to override the line break setting on a per post basis?

1 个赞
2

Not really — use explicit line breaks with two spaces at the end of a line or the common mark explicit line break character sequence.

3

Bummer…

Does anyone more familiar with the code have a sense for how difficult this would be to do as a plugin?

4

Note that even on GitHub which is far more developer centric than Discourse, the behavior defaults to return as a line break.

2 个赞
5

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.

Was discussed here:

3 个赞
6

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 :thinking:

10 个赞
7

Oh … a BBCode block plugin that did this would be quite straight forward, maybe 20 lines of code.

9 个赞
8

This sounds like a pretty good way forward to me!

5 个赞
9

Hey, I’m pretty psyched about the idea proposed here to do a BBCode block.

It made me think of something else though, that I want to float here to see what folks think.

I’m wondering if this is an opportunity to actually improve commonmark itself to support directives within a document for different rendering options.

There were some hints of exploring an idea like this in a few posts in this topic on the commonmark forum. For example:

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?

2 个赞
10

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.

6 个赞
11

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?

12

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.

2 个赞
13

嗯，这取决于你从哪个角度看。在 GitHub 或 GitHub Pages 中渲染 Markdown 文件时，采用的是传统的换行方式。段落文本中没有实际的换行符不利于变更追踪，因此为需要不断演变的长篇内容添加未渲染的实际换行符非常有用。许多（尽管不是大多数）论坛帖子都具有这一特性。

只有在问题（issues）和拉取请求评论（PR comments）等更随意的场景中，GitHub 才会使用非传统的“GitHub 风格”Markdown，即单换行符具有实际意义。我确信他们这样做的目的是为了迁就开发者，因为开发者可能会在问题中快速输入一小段代码，而忘记缩进或用三个反引号将其包裹起来。

因此，非传统 Markdown 实际上是更偏向开发者的选择。在撰写论坛帖子时，没有人强迫你换行长行；根据我的经验，大多数人都希望在输入 Markdown 时以及渲染后的结果中，段落之间都留有空行。因此，对于大多数人来说，默认设置并没有任何优势。