Improve support for code blocks/block quotes nested in lists about markdownediting

[deathaxe]

I am aware of those, but supporting them causes a lot of more complexity in syntax definitions. ST's syntax engine parses text in a single run, only, while Markdown requires multiple stages to get it done right. To simulate that in a single run, many special case contexts and patterns are required to handle all combinations of those nested statements. Combined with ST's line blindnes, which requires extra complex rules to handle emphasis (italics, bold) across multiple lines, that's probably not wordth it to support all those weird edge cases. Markdown syntax is already slow enough.

[deathaxe]

... option to disable the colour change of quote blocks

That's not possible via options.

[deathaxe]

I would expect that the 'start column' for the diff highlighting within a code block should be the 'base column' of the code block, not the literal start of the line in the file.

That's unfortunatelly not possible with ST's syntax engine. We can't count and use indentation for highlighting nor does it support stripping certain amount of leading whitespace from lines of embedded code when highlighting.

If an embedded syntax relies on indentation or its absense, like diff, it just doesn't work. There's nothing this package can do to fix it.

Theoretically it would require to ship a special syntax for diff which doesn't require +/- to start at the very first column, but that's out of scope for this package.

Syntaxes are embedded by scope, so it would theoretically be possible to create a more lazy one overriding the default diff syntax, which would then be picked up.

List continuation...

Input helpers have various short commings as they rely significantly on sublime-macros with lots of regexp black magic. There's much to improve.

The noted cases shouldn't be too hard to fix, I guess.

[0xdevalias]

That's unfortunatelly not possible with ST's syntax engine.

Ah true, that's unfortunate, but fair enough. The diff highlighting aspect was definitely a minor improvement compared to some of the other idea/etc included above.

---

Theoretically it would require to ship a special syntax for diff which doesn't require +/- to start at the very first column, but that's out of scope for this package.

Syntaxes are embedded by scope, so it would theoretically be possible to create a more lazy one overriding the default diff syntax, which would then be picked up.

Thanks for the insight, that makes sense. I don't think it's a big enough issue for me to need to go down that path; but if it is for others, good to know how it theoretically could be achieved.

---

Input helpers have various short commings as they rely significantly on sublime-macros with lots of regexp black magic. There's much to improve.

The noted cases shouldn't be too hard to fix, I guess.

Yeah, that makes sense. I figured there was probably a bunch of 'black magick' going on with them.

If they can be improved for these sorts of cases, that would be awesome!

[0xdevalias]

I figured out part of the other 'rendering issue' I noticed previously:

Given this text:

- > This is some blockquote text nested in a list

It renders fine:

If we indent it 4 spaces, it loses it's highlighting/etc (presumably because it's being treated as a non-fenced codeblock):

    - > This is some blockquote text nested in a list

If we add earlier list items, it renders fine:

- This is an earlier list item
  - And another
    - > This is some blockquote text nested in a list

In some cases (which I have yet to figure out how to reproduce properly), when I am working with nested blockquotes like this, it seems to get stuck in a weird 'half and half' case, where some of the blockquote is properly noticed/rendered, but part of it is in that 'raw' state.

I'll try and pay attention when it happens again, and figure out a minimal reproduction for it.

[0xdevalias]

Ok, I found an example. Not sure if this is the only case where it happens, but it seems if there is a single _ in the proceeding line, the blockquotes on the following lines aren't coloured properly:

- https://twitter.com/_devalias/status/1753322272293896385
  - > The code is still pretty hacky.. but pulled the PoC's together into a usable script for filtering the noise in the diff output!
    > 
    > Still not perfect.. but I am really liking these stats so far!
    > 
    > For an 8.4mb _app.js file (250,022 lines):
    > 
    > Original diff: 33,399
    > Filtered: 7,516

Presumably this is because the highlighting code is assuming that I intended for that to be italics/similar.

If I quote it in backticks, you can see that the highlighting works again:

- https://twitter.com/_devalias/status/1753322272293896385
  - > The code is still pretty hacky.. but pulled the PoC's together into a usable script for filtering the noise in the diff output!
    > 
    > Still not perfect.. but I am really liking these stats so far!
    > 
    > For an 8.4mb `_app.js` file (250,022 lines):
    > 
    > Original diff: 33,399
    > Filtered: 7,516

Though ideally, that wouldn't be required to have it work (eg. GitHub's markdown highlighting seems to account for it ok)

[0xdevalias]

nods that's fair enough. It's not the end of the world, the other things mentioned earlier are definitely more 'real world UX' issues for me.

Since it's not possible/easy to do it well for all the edge cases though, I wonder if there is some validity to having the option to disable the colour change of quote blocks (without having to go and create a custom style override rule):

• #741
• #659

[0xdevalias]

Fair.