Fix typographer interpretation of (p)

[kemitchell]

This tiny PR corrects typographer mode's interpretation of (p) and (P).

Currently, those strings get replaced with §, the section symbol. But (p), when used to identify intellectual property rights, like (c) and (tm) and (r), maps to ℗, the phonogram symbol.

Wikipedia has a decent page on the symbol, with references to various treaties and national laws that give it meaning.

[puzrin]

Sorry, no such breaking changes. This in not fix.

[kemitchell]

I understand breakage, but did not know your policy. Perhaps this might better belong behind a configuration flag.

In any event, (P) resolving to the section sign is clearly wrong.

[SamSaffron]

@puzrin any objections to a PR that makes the list of substitutions configurable, alternative is kind of messy cause we would have to duplicate quite a bit of code?

typographer: { replacementFn: fn } perhaps?

[kemitchell]

FYI, I have a PR coming for { rare: false, intellectualProperty: false, quotes: true }.

[puzrin]

Guys, i argee, current (p) substitution is strange. I don't remember what i drank before decided to add that :). But:

• Breaking changes are not welcome (without very strong reasons).
• Change one strange thing to another strange thing is not nice.

Probably, i would agree to just drop that pattern. Need to discuss available alternatives.

@puzrin any objections to a PR that makes the list of substitutions configurable, alternative is kind of messy cause we would have to duplicate quite a bit of code?

typographer: { replacementFn: fn } perhaps?

• I certainly don't like idea to make options more complex.
• The first question for any core change request is "why this can not be done via plugins".

---

If you wish to summarize suggestions - probably worth open new issue.

[puzrin]

FYI, I have a PR coming for { rare: false, intellectualProperty: false, quotes: true }.

@kemitchell please, don't PR breaking changes without discussing. All breaking changes are rejected by default. I feel unconmfortable to reject PRs :)

[SamSaffron]

@puzrin it can be done with a plugin, but I am not a fan of carrying the same code twice in the js payload, probably does not matter that much in the big scheme. Ideally if we just do this by turning off typographer we can build markdown.it without typographer.

[kemitchell]

Understand the strong compatibility guarantee. But I don't agree this is changing one strange thing to another.

Among lawyers, common digraphs for § include s. and S.. At the same time, (P) is clearly ASCII for ℗, and has been used that way in e-mails and text files for decades. If markdown-it currently rendered (c) as ¶, the pilcrow or paragraph symbol, that would be a clear error, too.

Что касается крепких напитков --- ничего страшнего. )))

[puzrin]

@SamSaffron i don't like tendency to clutter api with more and more options. So, everything is directed to external plugins by default. Core code is minimalistic, that's intended.

[SamSaffron]

understood, but can we build core without typographer?

[puzrin]

Among lawyers, common digraphs for § include s. and S.. At the same time, (P) is clearly ASCII for ℗, and has been used that way in e-mails and text files for decades.

At the time i added existing replacement (many years ago), i could not find conflicting alternatives :(

Anyway, making something work completely different is much worse than just make it not work. So,

• i'm ok to drop (p)
• i'm not ok to change result.

understood, but can we build core without typographer?

I don't know possibility to do it without ass pain. But we could discuss conflicting things and try to resolve those.

[kemitchell]

The replacements and smartquotes submodules, which make up the typographer functionality, are hard coded and dynamically loaded in parser_core.js via require. You'd need to fork to drop typographer, but the patch would be small, and might apply cleanly for quite a while, especially with the hard compat policy.

[kemitchell]

@puzrin if you want it to stay as-is, so be it. Thank you for the work on this module you've done so far. You certainly don't owe me any more work, especially in a direction you don't like.

[puzrin]

• I could drop (p), if it's really an annoying conflict.
• I don't like to make options more complex.

---

Note, i reject only concrete implementations, not report of "problem". I agree, conflict exists and existing (p) is strange. If it's important for you - create an issue with your thoughts.

[kemitchell]

@puzrin I'm not so interested in this pull request that I want to discuss it at length in an issue, as well.

I wanted to make you aware of the problem, and I see that you are aware. Thanks for your attention.

[puzrin]

#763

Added memo (without deadline). If you need to enforce priority - feel free to write your thoughts.