Markdown: Add an option to re-enable Prettier 2.x's automatic space insertion in CJK

[smikitky]

Please add an option to bring back the Prettier 2.x's behavior of automatically inserting spaces between Latin and Japanese characters.

This page, linked from the 3.0 release note, says:

TL;DR: inserting spaces (but not U+0020 itself) is the job of viewers and such, not formatters like Prettier!!! PRETTIER MUST """NEVER""" BREAK DOCUMENTS BY DOING SUCH A THING!!!! ONCE IT DO, IT CAN """NEVER""" UNDO!!!
要点: アキ（半角スペース自体ではない）を挿入する行為は表示ソフトの責務であり、Prettierのようなフォーマッタの責務ではありません！Prettierがこんなことをやらかすことにより、文書を破壊する行為は到底認められるものではありません。

Yes, I fully understand that it's basically the job of a typesetting algorithm to adjust the visual space between a Latin letter and a Japanese letter. For example, I understand that professional-grade typesetting engines such as Adobe InDesign (via 文字組みアキ量設定) and $\mathrm{\LaTeX}$ (via \xkanjiskip) have a built-in support for neatly adjusting spaces between different character types. InDesign even ignores space characters in source text and adjusts spaces according to its own typesetting rules. I myself never use spaces when writing source code for $\mathrm{\LaTeX}$.

However, unfortunately, not all Japanese text is processed by such great typesetting software before it is displayed. And there is one type of software that is widely used, but notorious for being terrible at Japanese typesetting — it's called internet browsers! There is no CSS rule that can control the space between a kanji and a Latin character (yet). As a result, many design-conscious people make it a rule to intentionally insert a space character between a Japanese letter and a Latin letter only when writing HTML (and Markdown!) Idealists may say this is a hacky workaround, but it's the most practical solution to get the desired output on browsers for now, and many real documents stick to this style (Vue, Photoshop, AWS, Google Cloud, Microsoft and GitHub, just to name a few).

I also have heavily relied on Prettier's automatic space insertion, and the removal of this "feature" is blocking me from upgrading to 3.x. It's fine to change the default, but please don't remove the existing feature entirely based on the opinion of one side. Ultimately, this is a matter of style similar to "tabs vs spaces"; forcing one style will please some people but inevitably offend others, and advocates of each style have their own reasons. Since this "feature" has actually been available for many years, I don't think it's permissible to not leave it even as an option. Besides, since Markdown's biggest advantage is its ease of use, it is wrong to assume that people always want a Markdown linter just for writing some README and such.

[sosukesuzuki]

We would not add an option for this. I believe that the feature of inserting a space between CJ and Latin characters should not have implemented in the first place. Please use an alternative tool for this.

I prefer the style of writing Japanese with a space between Japanese and Latin characters. But I think it is not Prettier's responsibility.

[smikitky]

But why? The explanations and reasons I could find in the release note and #6385 are:

1. There are many people who dislike this behavior.
   → Indeed, but there are also many people who liked the previous behavior. Such people didn't even bothered to visit 6385. While it is "pollution" to some, it is a nice feature to others.
2. It affects AST / visual output.
   → Indeed, but so does prose-wrap=always. It makes changes that are often very noticeable in the final output, so this is a feature that sacrifices the AST-level consistency in favor of visual cleanness of the source code. I personally always turn prose-wrap off exactly because it affects the output unpredictably, but what's the reason for keeping (and even improving) one of these features and removing the other?
3. Linters can do this for you.
   → Yes of course, but saying that will defeat the purpose of Prettier itself. Technically, linters can detect all the styling problems Prettier can solve, but people love Prettier because it's a formatter, not a linter. I do use textlint for large documentation projects, but few people want to install it just for a few Markdown files.
4. It's a non-goal of Prettier; it shouldn't have been implemented in the first place.
   → Maybe, but this feature was there, and many people relied on it. This is the first time I saw Prettier completely erase a feature that is already there and not even leave an option.

@sosukesuzuki I am surprised to learn that the person who wrote that release note actually prefers the "with-spaces" style. That release note simply refers to this breaking change as an "improvement". When I first read it, I thought no one in the team was aware of the inconvenience it would cause. If the dev team was aware of the inconvenience but still made this decision based on a philosophical reason such as "It's a non-goal in the first place", that should be clearly explained in the release note.

[tats-u]

@smikitky FYI there's a choice to create a plugin to recover the previous behavior.
I've done the opposite and you can reuse: https://github.com/tats-u/prettier-plugin-md-nocjsp

Indeed, but so does prose-wrap=always.

Tracked in #14936 but no real response.

I wondered whether to fix it or not, but chose not to at the time.

In the first place, always has been impractical in Japanese and Chinese since the PR #3026 that started the controversy.

Also you can use JS (e.g. react components) and CSS to mitigate the problem without modifying the source text.

https://github.com/tats-u/jlreq-example

Note: this is just a technical demo. We have to brush up it and make it a React component.

We should use a way like this to tide us over until new CSS features to solve the problem at its root are available.

I don't want Prettier to force us to rush to the irreversible and lazy compromise solution.

[sosukesuzuki]

@smikitky First of all, thanks for your great feedback.

Indeed, but there are also many people who liked the previous behavior. Such people didn't even bothered to visit 6385. While it is "pollution" to some, it is a nice feature to others.

For me, the fact that some people dislike the previous behavior is one reason, but not the most important. I think the most important reason is that it's not the goal of Prettier.

What's the reason for keeping (and even improving) one of these features and removing the other?

Personally, I don't like prose-wrap=always either. I would like to remove that option based on my personal opinion, but I'm leaving it as it is because it has a big impact and can be disabled. I don't know how the other maintainers feel about this option.

I do use textlint for large documentation projects, but few people want to install it just for a few Markdown files.

I understand that. It might be good to have a Prettier plugin that maintains the previous behavior. Or, it might be good to create a lighter-weight Markdown formatter than textlint.

Maybe, but this feature was there, and many people relied on it. This is the first time I saw Prettier completely erase a feature that is already there and not even leave an option.

I apologize for this. However, Prettier is an opinionated code formatter. We don't add options for this reason. In terms of future direction, I think it would be good to provide a Plugin API to make it easier to write Prettier plugins that can override the default format.

[smikitky]

@tats-u Thank you for the info. A new plugin would be nice, but I'm afraid I don't have time for that. But please note that no one is trying to "force" one style here. I was just asking for an option to get back the behavior that has actually been around for years.

@sosukesuzuki Thank you. As far as I can remember, Prettier has always provided compatibility options when it has significantly changed its "opinion" (like trailingComma and arrowParen), and that's why I asked for a similar option. Still, I understand your point that this is essentially a scope issue rather than a styling issue. When I first read your release note, I somehow felt like it was trying to advocate only one style (partly because this uses a bit strong language), but I am relieved to see that this was not the case. I now understand Prettier is trying not to enforce a particular style here.

[tats-u]

@smikitky

no one is trying to "force" one style here.

Prettier maintainers do.
(many people and) I have made the opposite request (but produces the same result) to yours before, but of course it wasn't granted.

[smikitky]

Prettier maintainers do.

"Do"? Not "did"? I don't think the maintainers still enforce a particular style, but if you really think so, you should discuss it elsewhere.

[tats-u]

@smikitky

I don't think the maintainers still enforce a particular style, but if you really think so, you should discuss it elsewhere.

They will never add new options unless there's a 1000x very compelling reason to do so.
The existing options are vested interests.

https://prettier.io/docs/en/option-philosophy.html

I wish you luck in battle.

[fisker]

We already made our decision in #6385, please use other tool like textlint-ja or lint-md mentioned in the blog post. Or prettier-plugin-md-nocjsp

[smikitky]

@tats-u Ah, so by "Prettier maintainers do", you are referring to Prettier's philosophy in general, not Prettier's stance about this particular topic!

In this particular topic, Prettier's stance is this (from release note):

it’s not Prettier’s job to enforce a particular style in this case

And I understand it now.

[smikitky]

@sosukesuzuki

I admit that I misread your 3.0 release note, but even so, I feel the current release note is misleading and unfair.

Esentially, all the information that should be included in the release note would be "This is a controversial topic, but it's about prose, and it's our policy not to do anything about prose style".

I believe it was totally unnecessary to discredit one popular style as "not standard" and "contrary to official guidelines", and even link to an article with an aggressive tone like this. The current release note is written in a way that clearly supports one style over the other. I know that Prettier is an opinionated formatter, and that's exactly why I misunderstood your statements. I was under the impression that Prettier had changed its opinion 180 degrees without a compatibility option. If "no opinion" is the policy in this particular case, it shouldn't have presented opinions of only one side like that.

Do you mind if I send a PR to address this? Or is the release note final?

[sosukesuzuki]

First, Prettier's release notes are a scripted combination of changelogs written by the authors of each PR. I did not write the text for that feature. (I am ultimately responsible, of course, but that doesn't mean I understand all of its implications.)

PR for blogs is welcome. If it is good, we can accept it.