MarkdownEditing: Tab both indents the list and changes its bullet, and three releases share one build number

Three dialects in one package, and one setting in the whole document

The opening claim is modest and then the feature list is not.

The package advertises three things: editing features for the editor, colour schemes optimised for writing, and syntax definitions for three dialects, naming standard Markdown, GitHub's flavour, and MultiMarkdown. Three dialects is the interesting part, because they are not the same language and a package that claims all three is making a choice about which quirks win.

Then the feature list runs to seven groups covering roughly thirty distinct behaviours: heading display in two symbol dialogs, three ways to fold, heading style detection and maintenance while typing, list continuation and indentation, blockquote extension and conversion, inline critic markup with accept and reject bindings, reference-style link conversion and navigation, footnote insertion, and emphasis auto-pairing with four different empty-pair deletions.

Across all of that, exactly one setting is named: the key controlling list indentation bullets. One documented key for thirty behaviours is either excellent restraint or an undocumented preference, and nothing here says which.

The full documentation lives outside the repository, on a separate site built from a directory that is in the tree.

Tab indents the item and also changes the bullet character

One behaviour is worth describing on its own, because a user would not predict it.

On a blank list item, Tab indents the item and switches the list bullet to another one, cycling through three characters in a fixed order. Shift and Tab unindent and cycle the same way. Sequential presses work, so three Tabs indent three levels while rotating the bullet three times.

The rationale is visible if you follow the setting: mixing bullet characters inside one list is a common mistake when editing Markdown by hand, and rotating them on indent is a way of enforcing alternation. It is opinionated, and it is also the kind of thing that surprises someone who indents a nested list and does not expect the parent marker to change.

The escape hatch is the named setting, which lets you disable the automatic switching entirely or choose which bullets are used.

The task-list behaviour is a smaller cousin of the same idea. On a list item that is a GitHub task, Enter continues with a new blank task, and a two-key combination inside the line toggles the check mark.

Everything else in this group is conventional: Enter at the end of an item inserts the next bullet, and that is it.

Three operating systems, three keymap files, each with a space in its name

The repository root is a complete Sublime Text package, and the file list is the clearest description of what a Sublime package actually contains.

There are three keymap files, one per operating system, named with the platform in parentheses inside the filename. Sublime Text normally handles platform differences inside a single keymap, so three files is an unusual arrangement, and it means a keybinding change has to be made three times and the three can drift apart.

The rest follows the standard resource categories, all of them present at the root: a main and a context menu, a command palette entry, a preferences file, and a distraction-free settings file. Alongside them sit a first-level plugin module, a plugins directory, and the feature directories the readme implies: syntaxes for the three dialects, snippets, colour schemes, macros, tests, and a test runner configuration.

The two remaining root files are the release machinery: a batch file that builds, and a messages directory with a JSON index that supplies the notes Package Control shows when it installs or updates the package.

So the package ships its own update notes, and its own release script, in the same directory as its settings.

The release build is a Windows batch file and the formatter skips the entry point

Two root files describe how the package is built, and both are worth reading closely.

The build script is a Windows batch file. There is no shell equivalent beside it, so the packaged release path is a Windows one, which fits an ecosystem whose plugin host is a Windows-first editor but does mean the release step is not portable.

The Python configuration file is not a package manifest at all. It contains a single tool section configuring a code formatter: a line length of a hundred, a target interpreter version three years and several minor versions behind the interpreter the repository pins elsewhere, and an exclusion list.

That exclusion list is the interesting part. It excludes the version control and automation directories, both cache directories, the virtual environment, the tests, and the first-level plugin module. In other words, the file that Sublime Text loads to start the package is deliberately left unformatted.

There is also a separate lint configuration beside it, so the project runs a linter and a formatter with independent configurations and no shared rules file.

The credits section dates the documentation, and the credits section is careful

The history in this repository is unusually well kept, and it also dates the prose.

The package was originally created by one person and became a community project whose stated goal was consolidating the best features from the varied collection of Markdown packages that had existed for this editor. That framing matters: it explains why the feature list is so broad, since consolidation implies inheriting behaviours rather than designing them.

Development was headed by two people until early 2021, and current development is headed by one. There is a credit for code portions taken from another project, and a specific credit for the footnote commands, naming both the person who submitted them and the place they originated.

Then there are the two blog posts by the original author, one from May 2012 introducing the package for an earlier major version of the editor, and one from November 2013 with updates.

Those dates are the point. The feature descriptions read like they were written alongside the 2013 post, and the last commit is dated 2026-08-21. A reader should treat the readme as a summary of the design as it stood in that era, not as a current reference, and the user guide on the separate site as the place to check whether a behaviour still works.

Three releases, one build number, and a patch version that never appeared

The release tags carry a build number in front of the version, which is how the editor's package manager distinguishes one install from another.

The three most recent releases are all prefixed with the same number, and their versions are three point six point three, three point six point one, and three point six point zero.

Two things follow. The build number is supposed to increase with every release so the package manager recognises each one as an update, and here it does not, so three releases over roughly six months share one identity from the registry's point of view. And the sequence skips three point six point two: it sits chronologically between the April release and the June one, and it is not in the list, so it was never tagged.

A skipped patch number is unremarkable. A repeated build number is not, and it is the kind of detail that decides whether an update reaches users.

The package also marks the editor as its prerequisite and targets a specific Python version for its own plugin host, which for this package means the interpreter the editor embeds rather than one you install.

The critic markup is the only dialect in the file that nothing else implements

One feature group is worth reading on its own, because it is a second standard layered on top of the Markdown dialects.

Critic markup is a convention for inline review annotations, and the package highlights five forms:

{++ addition ++}
{>> comment <<}
{-- deletion --}
{== highlight==}{>> comment <<}
{~~ substitution ~> by ~~}

On top of the highlighting there are key bindings on both sides of the exchange: reviewers can add markup, and authors can accept or reject what a reviewer wrote. That makes the feature bidirectional rather than a display convention.

The emphasis on bindings is the same throughout this package, and it is what separates it from a syntax theme. Headings change level by binding, lists cycle bullets by binding, blockquotes convert by binding, footnotes are added and removed by binding, and emphasis auto-pairs around a selection. The colour schemes are the decorative part; the bindings are the product.

One setting controls all of it, and one behaviour, the list bullet cycling, is the one that has an escape hatch.

Editorial conclusion

Use it if you write Markdown in Sublime Text all day and want the editor to behave like a writing tool rather than a text editor with a grammar attached. Two things to know before you install. Tab on a blank list item does two things at once, indenting and swapping the bullet character, and that is configurable through the single setting the document names. And the package's own release history is thin: three of the visible releases share one build number, so the editor's package manager may only offer you one of them.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. SublimeText-Markdown/MarkdownEditing on GitHub