Compare commits
4 Commits
64569cd70d
...
ca9ac9ceee
Author | SHA1 | Date | |
---|---|---|---|
ca9ac9ceee | |||
4ad3cd0f79 | |||
968d2e62b0 | |||
c480ac3736 |
@ -1,2 +1,4 @@
|
||||
css/extra.scss
|
||||
dnd/template.org
|
||||
dnd/template.org
|
||||
article/perfect-markup.md
|
||||
article/perfect-markup.md
|
||||
|
48
in/article/perfect-markup.md
Normal file
48
in/article/perfect-markup.md
Normal file
@ -0,0 +1,48 @@
|
||||
# Treatise on My Perfect Lightweight Markup Language
|
||||
|
||||
## It would have...
|
||||
- org-mode style inline syntax.
|
||||
- with the ease of HTML hackery of textile.
|
||||
- with the compiled language support that Markdown offers.
|
||||
|
||||
org-mode's inline attributes map nearly 1:1 with how I personally format in plain text, you have `__underscores__` that look like *underlines*,
|
||||
`//italics//` that look like *italics*, and `**bold**` that actually looks like **bold**. I want a LML that has nearly all the same features that you'd find on
|
||||
your common or garden word-processor, and with how often I refer to D&D 5e books, I want actual, *implemented* description lists. org-mode is absolutely
|
||||
perfect for this, but it's nearly entirely confined to the single text editor it was created in. Markdown has amazing support, but as a general shorthand
|
||||
for HTML, it feels sorely lacking. Textile makes up for it's shortcomings, but it suffers from a lesser problem that also plagues org-mode's development,
|
||||
and it's syntax can feel woefully clunky at points, that being said, it has the absolute best numbered list syntax out of all of the above mentioned LMLs.
|
||||
|
||||
## Sample
|
||||
|
||||
```
|
||||
= Heading 1
|
||||
== Heading 2
|
||||
=== Heading 3
|
||||
====[id] Heading 4
|
||||
|
||||
- Here
|
||||
- is
|
||||
- an
|
||||
- unordered
|
||||
- list
|
||||
|
||||
#. Here
|
||||
#. is
|
||||
#. an
|
||||
#. ordered
|
||||
#. list
|
||||
|
||||
- Here :: is
|
||||
- a :: single
|
||||
- description :: list
|
||||
|
||||
!<an_image.png>
|
||||
|
||||
And here is **Bold**, //Italic//, __Underline__, ^^Superscript^^, & --Strikethrough-- %{color:red}We also have span support%, %(i)in diffent flavours!%
|
||||
|
||||
[Markdown's](https://en.wikipedia.org/wiki/Markdown) link format works //fine//.
|
||||
|
||||
\`\`\`c
|
||||
// So do the code blocks.
|
||||
\`\`\`
|
||||
```
|
18
in/postext/outline.md
Normal file
18
in/postext/outline.md
Normal file
@ -0,0 +1,18 @@
|
||||
# Postext
|
||||
## Requirement Levels
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119).
|
||||
## Pronounciation
|
||||
"Postext" is a combination of the words "post" and "text", so it's pronounced "pohs-text".
|
||||
## Definitions
|
||||
- `EOL` is defined as either **CR** (`0x0D`) or **CRLF** (`0x0D 0x0A`). It is RECCOMENDED you keep to either one of the two forms throughout the written document.
|
||||
## Design Rules
|
||||
1. Whatever works best for the other LMLs, we adopt.
|
||||
2. Unix philosophy is king, postext's one thing well is HTML rendering.
|
||||
3. We need enough syntax to be hackable without changing the internals.
|
||||
4. Inline style elements must always be two identical characters together; it's the only way to be sure.
|
||||
## Features
|
||||
### Inline
|
||||
- **Bold**: two (2) `*` (`0x2A`) enclosing text. Converts to `<strong>[...]</strong>`
|
||||
- **Italic**: two (2) `/` (`0x2F`) enclosing text. Converts to `<em>[...]</em>`
|
||||
- **Underline**: two (2) `_` enclosing text. Converts to `<span style="text-decoration:underline">[...]</span>`
|
||||
- **Superscript**: two (2) `^` () enclosing text. Converts to `<sup>[...]</sup>`.
|
Loading…
Reference in New Issue
Block a user