Sublime Forum

**jmckalex** · February 11, 2025, 2:39pm

I’m trying to adjust Sublime’s Markdown syntax highlighting in three cases so that it matches the rules of a custom variant of markdown I’ve created for myself using marked.js. The new syntax is as follows:

/this should be italics/
*This should be boldface*
__This should be underline__

Ideally, it would be awesome if nested syntax was also recognised… So that something like __underline *with bold /and italic/ was* matched__.

I realise this is probably a big task, but if someone could just point me in the general direction of what needs to be adjusted, that would be a huge help! The complexity of Sublime’s syntax highlighting system is impressive, but it makes getting started with tweaking it a bit daunting…

**gbird** · February 11, 2025, 11:55pm

I guess you could start by reverse-engineering a Markdown.sublime-syntax that someone else has built, like so:

github.com

SublimeText-Markdown/MarkdownEditing/blob/master/syntaxes/Markdown.sublime-syntax

%YAML 1.2
---
# This definition aims to meet CommonMark specifications
#   http://spec.commonmark.org/
# with GitHub Formatted Markdown extensions
#   https://github.github.com/gfm/
# and has a few extras like Markdown Extra's footnotes
#   https://michelf.ca/projects/php-markdown/extra/#footnotes
#
# The scope suffix should indicate which flavor of Markdown the feature came from,
# to help make this syntax definition easier to maintain.
name: Markdown
scope: text.html.markdown
version: 2
hidden: true

variables:
  atx_heading: (?:[ ]{,3}[#]{1,6}(?:[ \t]|$))         # between 0 and 3 spaces, followed 1 to 6 hashes, followed by at least one space or tab or by end of the line
  atx_heading_space: (?:(?=[ \t]+#+[ \t]*$)|[ \t]+|$) # consume spaces only if heading is not empty to ensure `atx_heading_end` can fully match closing hashes
  atx_heading_end: (?:[ \t]+(#+))?[ \t]*($\n?)        # \n is optional so ## is matched as end punctuation in new document (at eof)

This file has been truncated. show original

For me however, the elephant-in-the-room question is: Wouldn’t it be better/faster/more future proof to reconfigure your parser to export conventional markdown?

In every MD syntax I have ever met *word* is emphasis and **word** is bold. Why reinvent the wheel?

**jmckalex** · February 12, 2025, 12:49pm

Thanks for this! I’ll have a go at digging into the file and see if I can figure out what needs to be modified.

As for the elephant-in-the-room question… the default MD syntax for boldface and italics seems less-then-perspicuous, to me, and since marked.js makes it trivial to enable/disable syntax extensions, I don’t see a reason not to adjust the syntax to suit my preferences. It doesn’t actually break anything, and the markdown interpreter I’m building lets that syntax adjustment be disabled to go back to the standard syntax anyway.

Custom Markdown syntax highlighting