마크다운 프라임

그냥 솔직히 까고 말하면, 마크다운은 나쁘지 않은 마크업 언어지만 최상의 선택도 아니다. 특히 위키 문법과 비교했을 때 영 아닌 부분도 있다. 이런 부분을 보완하고자 한다. (후략)

기능

• 마크다운에서 아주 이상하게 문제가 있는 문법이 아니면 수용 (mostly compatible).
• 같은 기능을 하는 문법이 둘 이상 있을 경우 하나만 수용 (_강조_ vs. *강조*). 대부분의 경우 이런 케이스에서는 한 쪽이 문제가 있는 경우가 대부분이다. 다른 문법으로 쓰여진 문서는 어렵지 않게 기계적으로 변환할 수 있어야 한다.
• 일반 텍스트가 문법으로 인식될 수 있는 케이스를 최대한 배제 (밑줄 강조를 없앴으니 mod_negotiation 같은 게 밑줄로 인식될 일은 이제 없겠지).
• 자주 쓰이지만 전혀 표준화되지 않은 문법을 명확히 한다.
• 명확한 의미론과 문법. HTML을 베이스로 삼지 않는다(물론 preferred output은 있지만).
• 무엇을 확장할 수 있고 무엇을 확장할 수 없는지 명확히 함. 이게 되지 않기 때문에 같은 마크다운인데도 확장에 따라 엉망인 것이다.

구성

인라인 문법

*강조* (기존의 _강조_는 작동하지 않는다.)
*강조 *여기도 강조* 여기는 강조하지 않음
*강조*여기도강조* 여기는 강조하지 않음
이 줄은* 전혀 *강조되지 않으며 별표 두 개는 그대로 남는다
_*이것도 강조하지 않음*_ (_는 공백이 아니니까)
그리고 * 이 별표도 그대로 출력

**좀 더 강한 강조** (역시 기존의 __강한 강조__는 작동하지 않는다.)
***조조조좀 더 강한 강조***
**강한 강조 *안에 쪼금 더 강한 강조* 강한 강조**
*강조 **안에 훨씬 강한 강조** 강조*
*강조하지 않음** (별표 세 개도 그대로 출력)
**강조하지 않음* (별표 세 개도 그대로 출력)
**강한 강조* 여기도 강한 강조** (중간의 별 하나는 그대로 출력)
**강조하지 않음 *강조** 여전히 강조* (맨 앞과 중간의, 연속된 별 두 개 두 번은 그대로 출력)

강조. 안에 들어 있는 텍스트를 강조함을 나타낸다. 강조의 정도는 별표의 갯수를 통해 조절할 수 있다. 결과적으로 나오는 포매팅은 꼭 이탤릭이나 볼드체일 필요는 없다. (마크다운의 두 문법 중 하나를 채택, 별표 세 개 이상은 마크다운에 없음)

• 낱말의 맨 앞에 있는 n개의 연속된 *와, 같은 또는 다른 낱말의 맨 뒤에 있는 첫번째의 n개의 연속된 * 문자로 구성됨.
  • 참고: 여기서 “낱말의 맨 앞”은 앞에 있는 글자가 공백 문자이거나 줄의 시작이고 뒤에 있는 글자가 낱말 글자인 경우, 즉 낱말 경계[boundary]에 있음을 의미한다. “낱말의 맨 뒤”도 마찬가지. 이 용법은 후에서도 계속 사용.
  • 참고: “n개의 연속된 …”은 해당 문맥에서 가장 길게 뻗을 수 있는 n을 나타낸다. a***b 안에는 정확히 3개의 연속된 *가 들어 있으며 한 개나 두 개의 연속된 *가 들어 있진 않다.
• 다만, 강조의 시작과 끝 사이에 다른 강조 문법이 들어 있을 경우 그 강조 문법 안에 들어 있는 연속된 * 문자는 강조의 끝으로 치지 않는다. 따라서 별표 갯수가 다른 강조가 서로 섞여 있는 경우 앞쪽에서 시작하는 강조는 처리되지 않을 수도 있다. (예: **a *b** c*의 경우 a는 한참 뒤에 **가 나오지 않으면 절대로 강한 강조가 되지 않는다.)
• 낱말의 맨 앞이나 맨 뒤에 없는 *는 어떤 경우에도 변환되지 않으며, 그대로 출력된다.
• 강조는 한 줄(주의: 한 “문단”이 아님) 안에서만 적용될 수 있다. 변환되지 않은 * 문자는 그대로 출력된다.
• 같은 별표 갯수를 가진 강조 문법은 중첩(nest)될 수 없다.

이 문법의 권장되는 출력은 HTML에서는 <em>...</em>(별표 한 개)이거나 <strong>...</strong>(별표 두 개 이상), LaTeX에서는 \emph{...}(별표 한 개 이상)이다.

unstructured yet

인라인 문법:

그냥 텍스트
{*중첩 강조*}
//항상 이탤릭//
`코드`
`코드`{.lang}
``역따옴표(`)를 포함한 코드``
2^{3} (항상 중괄호로 묶여야 함)
2_{3} (항상 중괄호로 묶여야 함)
{%abbr#foo.bar.baz{ abbr id="foo" class="bar baz" }}
어쩌구 저쩌구 [^fnref]
어쩌구 저쩌구 ^[인라인 주석]
[링크](http://example.com/)
[링크](http://example.com/ "자세한 설명")
[링크][ref]
[링크][^fnref]
[ [키워드 링크]] 앞에 있는 공백은 ikiwiki 버그때문에 넣은 것이므로 알아서 지울 것
[ [키워드 링크]](실제 키워드)
[ [키워드 링크]](실제 키워드 "자세한 설명")
![이미지 설명](http://example.com/test.png)
![이미지 설명](http://example.com/test.png "자세한 설명")

블록 문법:

% 메타데이터 (pandoc과 다름)

==============================
제목줄 (reST와 같은 규칙을 따름)
==============================

-------------------------------------
{3} 명시적으로 번호를 붙인 2단계 제목줄
-------------------------------------

명시적으로 링크 이름이 붙은 3단계 제목줄 {#third-section}
-----------------------------------------------------
제목 아래에 곧바로 첫 문단이 올 수 있음 (그러나 반대는 불가)

보통 문단

~ 명시적인 문단 (어느 위치에서나 p 태그를 생산함)

* 순서 없는 리스트
+ 계속
- 계속

1. 순서 있는 리스트
(2) 계속
3) 계속
IV. 계속
(V) 계속
VI) 계속
vii. 계속
(viii) 계속
ix) 계속

#. 자동으로 번호가 붙은 리스트
(#) 계속
#) 계속

정의 목록
:     정의설명
      이 부분은 한 paragraph로 치지 않음
:     이 부분은 새로운 dd로 만들어짐

좀 더 복잡한 정의 목록
:   ~ 정의설명
      이 부분은 새로운 paragraph로 침
    ~ 이렇게 하면 dd 안에 p가 두 개 들어 감

낱말에 링크 이름 걸긔 {#some-term}
:     좀 더 일반화된 문법은 아랫쪽 참고     

~~~~~~
코드 블록 (더 이상 단순 들여쓰기는 코드가 아님)
~~~~~~

* * *
- - -
+++++

(위의 것들 다 rule에 해당함)

> 인용
>> 더 인용
>> ~~~~~~~~~~~~~~~
   코드도 인용 (들여쓰기된 만큼 삭제됨. 들여쓰기가 모자라면 들여쓰기만 자름)
   ~~~~~~~~~~~~~~~

> {%article}
> 커스텀 태그를 사용?

아래 문법들은 pandoc이 왠진 몰라도 잘라 먹어서 앞에 `[`를 덧붙여야 함

ref]: http://example.com/

ref2]: http://example.com/ "설명 텍스트"

^fnref]:
  여러 가지 쓸데 없는 주석
  꼭 반드시 `:` 다음에 바로 와야 하는 건 아님(여러 문단이 될 수 있음)
  ~~~~~~~~~~~~~~~~
  이런 식으로 코드 같은 문단 문법이 들어 와도 들여쓰기만 확실하면 오케이
  다만 "암시적으로" 다른 모든 문단이 p에 묶이게 됨
  (하나만 올 때는 ~를 안 쓰는 한 안 묶임)
  ~~~~~~~~~~~~~~~~

레퍼런스 문법은 좀 더 다듬을 필요 있음

표 문법은 아직 확정 안 됨

확장 문법은 아직 확정 안 됨