nice environment

[Ducasse]

I got the following idea. Since environment is only for microdown environment

<!environment|title=foo
<!nested|path=123

code

>

!>

we could support tabs to get

<!environment|title=foo
   <!nested|path=123

 code
 ```

!>

[Ducasse]

This would improve reading for slides and many others and we could make it available.

[kasperosterbye]

This can be done by removing leading tabs prior to parsing - should be easy to code. Might be tricky for one who do not know the rule and get tangled up in this. That is, tabs are removed in environment, but kept in codeblock and $$-scripts (you might have extensions in a language which depends on tabs).

I think we should do it.

[kasperosterbye]

After having looked deeper into the parser, this is not an easy one at all.

Basically addLineAndReturnNextNode:in all paragraph level blocks must be recoded to

• handle leading tabs differently, and
• remember indentation level of input to allow for the right number of tabs to be removed

That said, there are 17 implementors, and new ones have not been added for several years.

[Ducasse]

Good to know. I will talk with gaylord may be this is too complex for him.

[kasperosterbye]

This might actually be done in a different manner, namely by the parser treating prefix tab as non-existing with respect to parsing, but keeping them intact for the body.

That leaves the issue of how to let the indented code block both support tabs, and also not be too deeply indented. It can be a localised issue to code block, which can figure out on its own what is code indention and what is microdown source indent

• Either by counting the number of prefixed tabs to the first line in the code (as the first line typically do not have any indentation)
• running through the lines in the code, and find the minimal number of prefixed tabs.

Either of these two methods can be used by codeblock to tell which tabs are from microdown, and which are from code indentation.

[Ducasse]

I kind of understand what you mean :) Now I think that you mean environment? Because the nesting should only be in environment. I thought that what we could do is we count the number of tab

<?environment
onetab <?nested stuf
onetab or "I put onetabl only because we could have optional tabbing"
onetab onetab <?deeper nested
onetab onetab ?>
onetab ?> "end of nested stuf
?> end of environment

[kasperosterbye]

😁 I think I will attempt a PR, and express me in code. There is often a 😈 in the details 😦 though

[kasperosterbye]

However, the real problem is in the imbedded code in your original example, as the code itself should not be imbedded in the output corresponding the the indentation of the input.

[Ducasse]

I did not get not be imbedded in the output corresponding

[kasperosterbye]

Input could be:

<!env1
⟼<!env2
⟼⟼\```
⟼⟼some code
⟼⟼⟼some indented code.
⟼⟼more code
⟼⟼⟼⟼with deep indentation
⟼⟼\```
⟼!>
!>

tabs ignored by parser, but given verbatim to codeblock, so codeblock is getting this:

⟼⟼some code
⟼⟼⟼some indented code.
⟼⟼more code
⟼⟼⟼⟼with deep indentation

codeblock finds the minimal prefix tab level in this is 2. Hence the actual code to be presented is:

some code
⟼some indented code.
more code
⟼⟼with deep indentation

[Ducasse]

This issue is related to https://github.com/pillar-markup/Microdown/issues/707