이건 특별히 강한 의견이 없는데, 저작권 기호를 직접 입력해야 하는 경우가 너무 드물어서 이 단축키를 제거해도 될 것 같아요. 매우 드문 유용성과 꽤 흔하지만(보기 안 좋은) 목록 형식인 (a) (b) (c) 사이의 균형이 그렇다는 거죠. @sam, 이 특정 단축키를 완전히 제거하는 데는 문제가 없습니다.
markdown-it의 master 브랜치에서 커밋 7b8969ce5cb2edc54f2c1aa39a85a3a08076337d 기준으로, 관련 소스 파일은 lib/rules_core/replacements.js이며, 관련 테스트 픽스처는 test/fixtures/markdown-it/typographer.txt입니다.
모든 치환은 하드코딩되어 있습니다. 여기에는 "범위 한정 약어(scoped abbreviations)"로 묶인 (c) → (c), (tm) → ™, (r) → (r), 그리고 (p) → (p)가 포함됩니다.
참고로, 저는 §에 대해 (p)가 나오는 것을 이해하지 못하겠습니다. 이는 거의 확실하게 음반 기호(phonorecord symbol)인 ℗여야 합니다.
이 문제를 몇 가지 시도해 보고, “typographer” 기능을 더 구성 가능하게 만드는 패치를 만들어 볼 수 있을지 확인해 보겠습니다.
제가 파악한 바로는, 그는 새로운 메이저 버전에서도 깨지는 변경사항(breaking changes)을 도입하는 것을 매우 꺼립니다. (P)가 §로 렌더링되는 것 같은 사소한 변경도 마찬가지입니다. 또한 typographer: true가 여전히 작동하더라도, typographer: {A: true, B: false} 스타일의 옵션을 허용하는 것에 대해서는 인식된 복잡성 때문에 매우 거부감을 보입니다.
글의 행간을 읽는다면, 그는 영어로 글을 쓰는 러시아계 개발자인 것 같습니다. 하지만 그가 markdown-it을 이미 완성된 것으로 보고 있다는 느낌을 받습니다.
감사한 마음을 전하면서, 구현을 포크해서 ES Modules로 다시 작성하고, 현재 번들에 포함된 플러그인 성격의 기능들(링크화 및 치환, 타이포그래퍼의 문장 부호 치환 포함)을 모두 제거하는 것이 가치가 있을지도 모른다고 생각합니다.
메인터이너는 번호가 없는 번들에서 중복된 코드에 대한 지적에 관심이 없습니다. 또한 “사용자의 100%가 요구하지 않는” 또는 플러그인 구현을 차단하는 것이 아닌, 비브레이킹 API 변경 사항에도 관심이 없습니다. 이는 일종의 딜레마를 초래합니다. 왜냐하면 해당 프로젝트는 실제로는 플러그인 성격이 강한 두 개의 서브모듈(링크화 및 스마트 구두점)을 함께 배포하고 있으며, 그 철학에 따라 이러한 기능은 자체적인 작은 npm 패키지로 분리되어야 하기 때문입니다. 이런 일은 가끔 발생합니다.
참고로, markdown-it에는 최근 상당한 릴리스가 있었습니다. 특히 지난해 11월에 Alex Kocharin이 성능 개선을 발표한 것이 주목할 만합니다.
(c)를 수정하고 (p)를 처리하며, 화살표 등 다른 사항도 원하는 대로 처리하려면, 가장 좋은 방법은 코어에서 링크화와 스마트 구두점 서브모듈을 제거하고 대신 Discourse에서 플러그인으로 로드하는 패치를 제안하는 것입니다. GitHub Action 또는 cron 작업을 사용하여 markdown-it 마스터 브랜치를 주시하고 자동 리베이스를 시도해 보세요. 메인터이너가 변경 사항에 대해 이 정도로 보수적인 태도를 유지한다면, 해당 패치는 상당한 기간 동안 깨끗하게 적용될 것입니다. CommonJS 대신 ES Modules로 재작성하는 것과 같은 큰 변화가 없는 한 말입니다.
