-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Markdown: Add an option to re-enable Prettier 2.x's automatic space insertion in CJK #15015
Comments
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. |
But why? The explanations and reasons I could find in the release note and #6385 are:
@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. |
@smikitky FYI there's a choice to create a plugin to recover the previous behavior.
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, 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. |
@smikitky First of all, thanks for your great feedback.
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.
Personally, I don't like
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.
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. |
@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 |
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. |
They will never add new options unless there's a 1000x very compelling reason to do so. https://prettier.io/docs/en/option-philosophy.html I wish you luck in battle. |
We already made our decision in #6385, please use other tool like textlint-ja or lint-md mentioned in the blog post. Or |
@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):
And I understand it now. |
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? |
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. |
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:
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 $\mathrm{\LaTeX}$ .
\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 forHowever, 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.
The text was updated successfully, but these errors were encountered: