How to get SE to render and navigate Confluence Wiki Markup / Markdown better?

[SimonHF]

I create some bigger Confluence pages using their ASCII Wiki Markup / Markdown syntax [1] in SE, and then I can copy and paste the entire page into Confluence. This has the advantage of me not having to fiddle with the Confluence web page GUI for each and every detail while editing.

How can I get SE to render the syntax nicer, and even let me navigate the syntax better? The syntax allows headers to be defined and it would be great if SE allowed me to navigate these headers more easily (like it does with showing a list of functions, etc).

Thanks in advance!

[1] https://confluence.atlassian.com/doc/confluence-wiki-markup-251003035.html

[Clark]

I took a quick look at the link.

Are you typing things like the following in SlickEdit which is NOT markdown but has some similarities?

Code: [Select]

h1. Biggest heading

# Here
#* is
#* an
# example
#* of
#* a
# mixed
# list

# Here's a sentence.
## This is a sub-list point.
### Third list level.
### Another point at the third level.
## And a second sub-list point.
# Here's another sentence.

What file extension do you use for the above text (assuming I'm on the right track)?

Markdown is very picky with leading blank space. Indent can totally change what happens. Also blank lines can end a section which changes color coding. It looks like this language does not have any of these complexities. It looks like most of the markup is just some leading characters.

Can the text markup span multiple lines?
If so, does a blank line stop the span?

Can the text markup be nested like this?   "*bold _BoldAndItalic_ bold*"

Documentation looks very limited and there are no tools we could use to reverse engineer details. There will be no way for us to know if we implemented it correctly.  Tagging h1./h2./h3. would be very easy. The color coding could be hard but only due to documentation.

[SimonHF]

Yep, that's the sort of thing. It's not actual 'markdown' but confluence uses the terms 'wiki markup' and 'wiki markdown' in their docs. Many items are single line, but there are exceptions, e.g.:

Code: [Select]

{toc}

h1. Biggest heading

h2. Smaller heading

h3. Smaller heading still

h4. Much smaller heading

* Bullet point
** Indented bullet point

{noformat}
Verbatim multiple
lines
go here
{noformat}

Which file extension? I don't think there is an official extension, so I could just make one up, e.g. *.con.txt ? Or whatever?

Yes, it's a pretty simple syntax with the formatting syntax being what is detailed at that link [1] including the 'text effects' and I'm not sure if they can be nested. And then also 'macros' [2] can be sprinkled in and AFAIK they are always of this format {...} but could get longer, e.g. [3]:

Code: [Select]

{toc:printable=true|style=square|maxLevel=2|indent=5px|minLevel=2|class=bigpink|exclude=[1//2]|type=list|outline=true|include=.*}

And then certain macros could be considered multi line, e.g. [4]:

Code: [Select]

{code:title=This is my title|theme=FadeToGrey|linenumbers=true|language=java|firstline=0001|collapse=true}
This is my code
{code}

[1] https://confluence.atlassian.com/doc/confluence-wiki-markup-251003035.html
[2] https://confluence.atlassian.com/doc/macros-139387.html
[3] https://confluence.atlassian.com/doc/table-of-contents-macro-182682099.html
[4] https://confluence.atlassian.com/doc/code-block-macro-139390.html

[Clark]

The macro syntax is interesting. It's a bit like XML but with attributes that aren't quoted, vertical bar which delimits attributes, and uses braces instead of <>. Also, there's no special syntax for ending the tag (it's not {/code} but just {code}). Which tags are multi-line must be hard wired based on the tag name (i.e code macro is multi-line).

We can always make up a file extension and map it to a language. Seems like the Language name should be "Confluence Markup" or "Confluence Wiki Markup". Extension could be ".conmarkup" but you will be able to add others.

Given that fact that there probably won't be many customers using whatever we put together here, I can't promise we will add this. At a minimum, we would have to cut corners and leave out XML-like color coding for macros and embedded language color coding for "{code language=Java}...{code}".  Even with leaving this out, a simple color coding profile (a bunch of regex config stuff- not writing code) and a tiny Slick-C macro for tagging headings would go a long way. The tag headings Slick-C macro would be similar to markdown_proc_search() which is very few lines of code.