그냥 솔직히 까고 말하면, 마크다운은 나쁘지 않은 마크업 언어지만 최상의 선택도 아니다. 특히 위키 문법과 비교했을 때 영 아닌 부분도 있다. 이런 부분을 보완하고자 한다. (후략)
_강조_
vs. *강조*
). 대부분의 경우 이런 케이스에서는 한 쪽이 문제가 있는 경우가 대부분이다. 다른 문법으로 쓰여진 문서는 어렵지 않게 기계적으로 변환할 수 있어야 한다.mod_negotiation
같은 게 밑줄로 인식될 일은 이제 없겠지).*강조* (기존의 _강조_는 작동하지 않는다.)
*강조 *여기도 강조* 여기는 강조하지 않음
*강조*여기도강조* 여기는 강조하지 않음
이 줄은* 전혀 *강조되지 않으며 별표 두 개는 그대로 남는다
_*이것도 강조하지 않음*_ (_는 공백이 아니니까)
그리고 * 이 별표도 그대로 출력
**좀 더 강한 강조** (역시 기존의 __강한 강조__는 작동하지 않는다.)
***조조조좀 더 강한 강조***
**강한 강조 *안에 쪼금 더 강한 강조* 강한 강조**
*강조 **안에 훨씬 강한 강조** 강조*
*강조하지 않음** (별표 세 개도 그대로 출력)
**강조하지 않음* (별표 세 개도 그대로 출력)
**강한 강조* 여기도 강한 강조** (중간의 별 하나는 그대로 출력)
**강조하지 않음 *강조** 여전히 강조* (맨 앞과 중간의, 연속된 별 두 개 두 번은 그대로 출력)
강조. 안에 들어 있는 텍스트를 강조함을 나타낸다. 강조의 정도는 별표의 갯수를 통해 조절할 수 있다. 결과적으로 나오는 포매팅은 꼭 이탤릭이나 볼드체일 필요는 없다. (마크다운의 두 문법 중 하나를 채택, 별표 세 개 이상은 마크다운에 없음)
*
와, 같은 또는 다른 낱말의 맨 뒤에 있는 첫번째의 n개의 연속된 *
문자로 구성됨.
a***b
안에는 정확히 3개의 연속된 *
가 들어 있으며 한 개나 두 개의 연속된 *
가 들어 있진 않다.*
문자는 강조의 끝으로 치지 않는다. 따라서 별표 갯수가 다른 강조가 서로 섞여 있는 경우 앞쪽에서 시작하는 강조는 처리되지 않을 수도 있다. (예: **a *b** c*
의 경우 a
는 한참 뒤에 **
가 나오지 않으면 절대로 강한 강조가 되지 않는다.)*
는 어떤 경우에도 변환되지 않으며, 그대로 출력된다.*
문자는 그대로 출력된다.이 문법의 권장되는 출력은 HTML에서는 <em>...</em>
(별표 한 개)이거나 <strong>...</strong>
(별표 두 개 이상), LaTeX에서는 \emph{...}
(별표 한 개 이상)이다.
인라인 문법:
그냥 텍스트
{*중첩 강조*}
//항상 이탤릭//
`코드`
`코드`{.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에 묶이게 됨
(하나만 올 때는 ~를 안 쓰는 한 안 묶임)
~~~~~~~~~~~~~~~~
레퍼런스 문법은 좀 더 다듬을 필요 있음
표 문법은 아직 확정 안 됨
확장 문법은 아직 확정 안 됨