“#” is a special symbol of MD, but the way it was handled is not as good as the ordinary text. The titles at different levels should be allowed to be next to each other.
A bug of markdown's Ctrl+R panel
kingkeith
#2
I don’t think it can reasonably be called a bug, but one can probably tweak it for one’s own use - I will investigate when I next sit at a computer and have spare time
0 Likes
braver
#4
I think it may be tripping over the fact that you can “close” a heading with # too (e.g. ## heading 2 ##), so heading 1 is eating the first # of heading 2 here. That should be preventable.
Edit: might be wrong though.
Edit:
Changing - match: \s*(#*)$\n? to - match: \s*(#*)(?=\n) seems to clean this up. Apparently including the \n in the match messes it up or something. If anyone can confirm this is a good idea I can make the appropriate pull requests.
0 Likes
kingkeith
#5
the problem is that the tmPreferences that is used to ensure the headings appear in the symbol list does so using scope markup.heading, which remains unbroken due to the \n being scoped with it also, so ST sees it as one long symbol. Then the regex replacement rules leave one of heading2’s #s in place. I take back what I said earlier, I do consider it a bug - somehow I misunderstood, apologies.
- match: \s*(#*)$(?=\n) would indeed fix the problem, but I guess the original intention was to scope the newline as part of the heading… I’d capture the newline and scope it slightly differently, and ignoring/excluding that scope in the symbol list scope selector. It’d be great to get a PR in and merged before SublimeHQ release ST3 stable 
1 Like
braver
#6
The original inent can’t be recovered, it’s there in the first commits of the SublimeHQ package as well as in Markdown Extended. It probably goes as far back as the original Textmate plugin. It’s basically archeology
When converting a heading to an html h1 tag in html the newline certainly wouldn’t be put in the content of the tag. In fact, all trailing whitespace would be clipped, so it would make sense to drop back out of the scope early. Atom leaves the newline out too (if it makes a difference).
Anyway, @kingkeith you want to keep the newline in? Let me know either way and I’ll do a PR.
0 Likes
the4ever
#7
In my another post(https://forum.sublimetext.com/t/solved-please-add-2-options-for-every-kind-of-panel/30871), I also found out it was the problem of tmPreferences , and I revised it successfully. I’ll try again on this question tomorrow.
0 Likes
kingkeith
#8
I’d say keep the newline in for now, SublimeHQ likely won’t accept any major/suspicious/unknown effect/unnecessary changes at this point as it could potentially break something elsewhere. You could always present a case for changing it later. The scopes are more for ST semantics anyway, in terms of completions, color schemes and plugins, so what happens when Markdown is translated to HTML or how a competitor works may not matter as much here.
0 Likes
braver
#9
Yup, makes sense.
so what happens when Markdown is translated to HTML or how a competitor works may not matter as much here.
Yeah, totally agree, just making a counter argument. PR coming up.
1 Like
braver
#10
Well obviously I can’t seem to capture (\n?), it seems not as simple as changing it to \s*(#*)$(\n?). It tried some different approaches but adding the ? stops it from capturing the \n.
0 Likes
the4ever
#11
The writing and reading habits of the East and the West are different. Easterners are used to this format:
So I’ve modified the syntax of MD ，and the md2html converter, so it’s okay to preview or to convert to html.
Of course, this is not universal for everyone. So, I can’t say it’s a bug, but it’s really something I need to know how to fix.
0 Likes
