Make a Markdown document like this (ignore the equal signs, they are just to show you the boundaries of the document content)
===
* One
* Two
Three
===
The Markdown bundle marks "Three" as markup.raw.block. This is wrong. As you'll see if you preview the document, it is the second paragraph of the second-level markup.list.unnumbered.
To make things worse, the bundle turns off wrapping in markup.raw.block, so if "Three" is a long paragraph, now you can't read it because it runs off the right side of the window.
m.
PS Granted, nested lists in Markdown are annoying and incoherent; this is one of the main reasons why I use kramdown instead. Nevertheless, the syntax coloring and wrapping should try not to get in the way of constructing one's document.
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
On 15 Feb 2014, at 11:21, Matt Neuburg wrote:
To make things worse, the bundle turns off wrapping in markup.raw.block, so if "Three" is a long paragraph, now you can't read it because it runs off the right side of the window.
I don't see that. I use the following in my ~/.tmproperties:
# Default editing configuration softWrap = true wrapColumn = 67 showWrapColumn = true snip...
[ *.txt ] fileType = "text.html.markdown" spellChecking = true snip...
On Feb 15, 2014, at 3:05 PM, Gildas Hamel gweltaz@ucsc.edu wrote:
On 15 Feb 2014, at 11:21, Matt Neuburg wrote:
To make things worse, the bundle turns off wrapping in markup.raw.block, so if "Three" is a long paragraph, now you can't read it because it runs off the right side of the window.
I don't see that. I use the following in my ~/.tmproperties:
Okay, whatever. But if you look at how "Three" is scoped in my example (shift-control-p) and it's markup.raw.block, that's the bug. How the scope is portrayed physically is, of course, variable. m.
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
On 15 Feb 2014, at 15:35, Matt Neuburg wrote:
Okay, whatever. But if you look at how "Three" is scoped in my example (shift-control-p) and it's markup.raw.block, that's the bug. How the
I didn't have the bundle development bundle on and have little understanding of these matters. This is the scope I now see for "Three":
![](cid:D407B0B8-D768-4729-A462-C2FC02420502@ucsc.edu "Screen Shot 2014-02-15 at 16.40.48.png")
On Feb 15, 2014, at 4:46 PM, Gildas Hamel gweltaz@ucsc.edu wrote:
I didn't have the bundle development bundle on and have little understanding of these matters. This is the scope I now see for "Three":
This is positively fascinating. On a different computer, my results agree with yours. I can't explain this discrepancy (yet). Thank you for testing!
NOTE: This is another of those situations where I wish TextMate had some way of telling me *how* it arrives at the scope it assigns to a given stretch of text. m.
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com
On 16 Feb 2014, at 2:21, Matt Neuburg wrote:
Make a Markdown document like this […] The Markdown bundle marks "Three" as markup.raw.block. This is wrong.
TextMate follows the specification from http://daringfireball.net/projects/markdown/syntax#list
This states “Each subsequent paragraph in a list item must be indented by either 4 spaces or one tab”.
If you run your document through babelmark you will see your document interpreted in five different ways:
http://johnmacfarlane.net/babelmark2/?normalize=1&text=*+One%0A++%0A++*+...
[…] Granted, nested lists in Markdown are annoying and incoherent
Indeed, though if you follow the specification quoted above, you should get consistent results accross markdown implementations. I actually consider it sort of a feature that TextMate’s highlight is a little fragile, as I’ve previously had cases where I did offline Markdown which looked fine, but later broke using e.g. PHP Markdown (online) or when I switched from Markdown.pl to multimarkdown (in these cases, because I didn’t consistently indent with four spaces / one tab).
Here's my contribution to the Battle of the Screen Shots:
http://apeth.net/matt/battle.png
Notice that I'm showing invisibles (line feeds). That turns out to be crucial to this example. The number of spaces _in the blank lines_ is what makes the difference here. You can go from my results to Gildas' results by taking out the spaces in Line 4.
Since it is possible to get the right answer by playing with spaces in the blank lines, I retract my bug report. As I said before, this is incoherent to start with. I thought it wasn't possible to make the Markdown bundle display (through scopes) the right answer _at all_, but I'm wrong. Fun, eh? m.
On Feb 15, 2014, at 6:42 PM, Allan Odgaard mailinglist@textmate.org wrote:
On 16 Feb 2014, at 2:21, Matt Neuburg wrote:
Make a Markdown document like this […] The Markdown bundle marks "Three" as markup.raw.block. This is wrong.
TextMate follows the specification from http://daringfireball.net/projects/markdown/syntax#list
This states “Each subsequent paragraph in a list item must be indented by either 4 spaces or one tab”.
If you run your document through babelmark you will see your document interpreted in five different ways:
http://johnmacfarlane.net/babelmark2/?normalize=1&text=*+One%0A++%0A++*+...
[…] Granted, nested lists in Markdown are annoying and incoherent
Indeed, though if you follow the specification quoted above, you should get consistent results accross markdown implementations. I actually consider it sort of a feature that TextMate’s highlight is a little fragile, as I’ve previously had cases where I did offline Markdown which looked fine, but later broke using e.g. PHP Markdown (online) or when I switched from Markdown.pl to multimarkdown (in these cases, because I didn’t consistently indent with four spaces / one tab).
-- matt neuburg, phd = matt@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 7! http://shop.oreilly.com/product/0636920031017.do iOS 7 Fundamentals! http://shop.oreilly.com/product/0636920032465.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.com