Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Line indent info for each line (blockquotes, lists) #1

Open
puzrin opened this issue Jan 11, 2017 · 1 comment
Open

Line indent info for each line (blockquotes, lists) #1

puzrin opened this issue Jan 11, 2017 · 1 comment

Comments

@puzrin
Copy link
Member

puzrin commented Jan 11, 2017

Problem

  • In blockquotes, lists and other similar containers, each line can have custom indent.
  • In nested container indent are stacked.

How to store this info in AST?

  • not convenient to create line wrapper, because it will be very difficult to traverse inline tokens.
  • could store as part of other token, first on current string.
    • not convenient, because any type of inline token can have such info.
  • could store as special invisible token indent
    • will it be a problem for inline traverse (for text content)
    • should we store separate indents for every nested block or single indent (in each line)

Checklist

  • Make sure text autowrap can be implemented with suggested indent format.
  • Make sure AST -> markdown is ok.
@geyang
Copy link

geyang commented Mar 15, 2017

Each node can have:

^____- [ ] some text↩
 ^--^ indent
     ^ bullet-list token
      ^ space
       ^____________^ list content
                     ^ end of line (carriage return)
        ^_^ task-list token (todo)

A potential solution is:

AST:
[ 
    <bullet-list-open toke-content="-   " indent="        ">,
    <inline>list content blah blah blah</inline>,
    <bullet-list-close token-content="↩">
]

as long as this AST syntax is consistent it's fine. I don't know how other parsers do it but my guess is they either emphasize speed, easy of quick lookup, ease of consumption or storage space requirements.

I think if we stick with what markdonw-it uses now, incremental changes in the token array is going to allow current plug-ins to work.

but you might not want current plug-ins to work to force plug-in upgrade, so that they are more consistent. This is a general trade-off that you might need to consider. A plug-in compatibility warning might be enough to push people to go do it right though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants