เปรียบเทียบและตัดกันภาษามาร์กอัปที่มีน้ำหนักเบา [ปิด]


90

โปรดระบุภาษามาร์กอัปขนาดเล็กที่เป็นที่นิยมมากที่สุดและเปรียบเทียบจุดแข็งและจุดอ่อน ภาษาเหล่านี้ควรเป็นมาร์กอัปที่มีวัตถุประสงค์ทั่วไปสำหรับร้อยแก้วทางเทคนิคเช่นสำหรับเอกสารประกอบ (เช่น Haml ไม่นับ)

ดูเพิ่มเติม: Markdown กับ ReStructuredText


คำตอบ:


115

ฉันรู้ภาษาหลักสามภาษาที่ใช้กันทั่วไปในชุมชนการเขียนโปรแกรมและเทคโนโลยีที่ยิ่งใหญ่กว่า: Textile, Markdown และ reStructuredText ทั้งสามสามารถเรียนรู้ได้ภายในสองสามชั่วโมงหรือ "มีปีก" โดยใช้แผ่นโกงใกล้ ๆ

สิ่งทอ

  • ใช้โดย Redmine และชุมชน Ruby
  • 113 คำถามที่ติดแท็กใน Stack Overflow
  • คล้ายกับ HTML มากที่สุด แต่แหล่งที่มาที่อ่านได้น้อยที่สุด
  • รายการที่ซ้อนกันง่ายที่สุดของทั้งสามภาษา
  • ไม่เข้าใจสำหรับผู้ที่ไม่ใช่โปรแกรมเมอร์หรือผู้ที่ไม่รู้ HTML
  • เหมาะอย่างยิ่งสำหรับเอกสารขนาดสั้นที่ซับซ้อน (พร้อมลิงก์รายการซ้อนโค้ด HTML ที่กำหนดเอง) ตัวอย่างเช่นเอกสารสั้น ๆ วิธีการบล็อกหรือเนื้อหา CMS
  • การอ้างอิงไวยากรณ์

Markdown

  • ดูเหมือนจะไม่มี "ชุมชน" ภาษาบ้าน ๆ แต่ ...
  • 1274 คำถามที่ติดแท็กใน Stack Overflow *
  • เน้นความสามารถในการอ่านซอร์สโค้ดคล้ายกับประเพณีอีเมล
  • การฝัง HTML ที่ตรงไปตรงมา (คุณเพียงแค่พิมพ์แท็กออกไป)
  • ไม่มีวิธีสร้างตารางนอกจากการฝัง HTML
  • คุณรู้อยู่แล้วถ้าคุณรู้จัก Stack Overflow
  • ง่ายต่อการเรียนรู้หากคุณรู้จัก reStructuredText แล้ว
  • ที่อยู่อีเมลอัตโนมัติทำให้สับสนสำหรับรูปแบบ <address@example.com> (พร้อมวงเล็บเหลี่ยม)
  • การอ้างอิงไวยากรณ์

reStructuredText (AKA ReST)

  • เป็นที่นิยมในชุมชน Python
  • 285 คำถามที่ติดแท็กใน Stack Overflow
  • ความมั่นใจเล็กน้อยเกี่ยวกับช่องว่างและการจัดตำแหน่งหากคุณถามฉัน
  • รายการ (โดยเฉพาะรายการที่ซ้อนกัน) และย่อหน้าดูเหมือนจะเข้ากันได้ดี
  • อ่านได้โดยผู้ที่ไม่ใช่โปรแกรมเมอร์
  • เฉพาะรูปแบบที่สามารถสร้างสารบัญ (ผ่านส่วนขยายในการใช้งานการอ้างอิง Python)
  • แปลงเป็นรูปแบบอื่นโดยตรงเช่น PDF และ XML
  • เหมาะสำหรับเอกสารขนาดใหญ่ที่มีร้อยแก้วจำนวนมาก (เช่นทางเลือกแทน docbook สำหรับคู่มือผู้ใช้)
  • การอ้างอิงไวยากรณ์

4
สำหรับผู้ใช้ ReST sphinx.pocoo.orgดูเหมือนจะเป็นเครื่องมือที่ดีมากสำหรับคอลเลกชันเอกสารอ้างอิงที่มีโครงสร้างแบบต้นไม้ขนาดใหญ่
bendin

6
ฉันไม่มีปัญหากับรายการและย่อหน้าใน reStructuredText เมื่อฉันห่อสิ่งต่างๆใน Emacs ในความเป็นจริงพวกเขาทำงานเหมือนกับที่ฉันคาดหวังไว้ :-)
Martin Geisler

1
มีส่วนขยายของ Markdown ที่อนุญาตให้เขียนตารางใน ASCII
Jakub Narębski

1
ReST มีการสนับสนุนเครื่องมือที่ยอดเยี่ยมเช่นกันเช่นnotex.ch ที่ใช้เบราว์เซอร์เป็นเครื่องมือที่ดีในการทดลองเรียนรู้และใช้ ReST (อิงตามแบ็กเอนด์ sphinx.pocoo.org)
hsk81

31

คุณอาจพิจารณาasciidoc

  • มาร์กอัปที่ค่อนข้างอ่านได้
  • การใช้บรรทัดคำสั่งตรงไปตรงมา
  • บางคนอาจมองว่ามันค่อนข้าง 'จู้จี้จุกจิก' (เทียบกับความยืดหยุ่น) เมื่อเทียบกับไวยากรณ์
  • docbook และ (x) html เอาต์พุต

2
น่าเสียดายที่ asciidoc มีไวยากรณ์ที่น่ากลัวสำหรับรายการที่มีหลายย่อหน้า: คุณต้องแยกพวกเขาด้วยบรรทัดเดียวที่มีเพียงเครื่องหมายบวก (ใช่ "+")
Martin Geisler

4
@ มาร์ติน: รายการแบบหลายย่อหน้าสำคัญจริงหรือ? หากคุณต้องการมากกว่าหนึ่งย่อหน้าหัวเรื่อง / ส่วนจะไม่เหมาะสมไปกว่ารายการหรือไม่?
Steve S

ข้อได้เปรียบที่ใหญ่ที่สุดของ AsciiDoc คือรองรับคุณสมบัติอื่น ๆ อีกมากมาย มันสามารถสร้างหนังสือมีส่วนทิปเอาท์พุตมากมาย ... powerman.name/doc/asciidoc
Wernight

21

หน้า Wikipedia ในภาษามาร์กอัปที่มีน้ำหนักเบามีการเปรียบเทียบที่ดีระหว่างตัวเลือกต่างๆรวมถึงการแสดงไวยากรณ์สำหรับการใช้งานทั่วไป (ส่วนหัวตัวหนาตัวเอียง ฯลฯ )


5

ฉันพยายามที่จะครอบคลุมภาษามาร์กอัปที่มีน้ำหนักเบาทั้งหมดที่นี่:

http://www.subspacefield.org/~travis/static_blog_generators.html

อย่างที่คุณเห็นมันเริ่มต้นด้วย "ฉันจะสร้างบล็อกที่ปลอดภัยได้อย่างไร" นั่นคือบล็อกที่สร้าง HTML แบบคงที่และฉันพบว่าตัวเองติดอยู่ในภาษามาร์กอัประบบเทมเพลต ฯลฯ

อัปเดต

ฉันเน้นเฉพาะ LWML ที่มีการใช้งาน python และอยู่ที่นี่:

http://www.subspacefield.org/~travis/python_lightweight_markup_languages.html

จนถึงตอนนี้ฉันได้ลอง markdown และ ReST แล้วและฉันชอบอย่างหลังดีกว่าสำหรับทุกอย่างยกเว้นตัวอย่าง HTML ที่ฝังอยู่ในหน้าอื่น ๆ ตารางอ้างอิงข้ามลิงค์ทางอ้อม ฯลฯ ...


4

สำหรับเอกสาร? แล้วdoxygenล่ะ?
ฉันใช้มันสำหรับโปรเจ็กต์ c / c ++ บางอย่างที่ฉันต้องการจัดทำเป็นเอกสาร แม้ว่าคุณจะสามารถ 'ละเมิด' ได้เช่นเดียวกับที่ผู้เขียน doxygen ใช้สำหรับเอกสาร doxygen

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.