Birch Markdown package updated to paste Markdown text and create outline

I’ve just updated the birch-markdown accept pasted Markdown text and create the appropriate Birch outline for it.

I’m using CommonMark to do the parsing, and then I create a Birch outline based off the CommonMark AST. The next step needed is to go from Birch outline to CommonMark AST. And then it will be possible to generate HTML from a Birch outline, or eventually convert the AST it right back into Markdown text.

I think this gets Markdown support to a proof of concept phase, I’m confident with more time it can be made to work well. I’m going to leave this project be for a bit and get back to basic outline work.

Some of the commands in:

  "name": "birch-markdown",
  "main": "./lib/birch-markdown",
  "version": "1.1.0",

do seem to be working – all of the ESC t [node-type letter] commands are successfully setting the data-type attribute in the selected node(s), but there seem to be some glitches at the moment in 1.1.0 (at least on my system) with the Copy and Paste Commands:

  'ctrl-cmd-c': 'birch-markdown:copy-markdown'
  'ctrl-cmd-v': 'birch-markdown:paste-markdown'

'ctrl-cmd-c' doesn’t seem to be picking up heading/header attributes created by ESC t h

and as far as I can see, 'ctrl-cmd-v' is not yet working – on my installation, from either mode it just seems to paste all the text content of the clipboard verbatim (minus line endings) into the text of one Birch node, without setting data-attributes or removing MD markup.

( Sometimes it just pastes the single string htmlblock )

I wonder if I am overlooking something ?

PS possible clue:
There seem to be two different clipboards in play here – one local clipboard containing material copied from within Atom, and another (system ?) containing material copied in other apps.

( In passing – a very minor editing thing – I notice that the for this package still cites the pre-CommonMark line-type names).

Hum… I though I’d been careful to make no incompatible changes locally. Guess not. Anyway can you please post any View > Developer > Toggle Dev Tools console logs when running into problems like this. That will often make it much easier for me to track down. Thanks!

Of course – I should have thought of including logs and errors.

Here’s one intermittent response to copying MD from an Atom text pane and then trying to 'ctrl-cmd-v': 'birch-markdown:paste-markdown' it into a Birch outline:

Press Return to create a new item.

Uncaught TypeError: Cannot read property 'bodyText' of null
Hide Stack Trace
TypeError: Cannot read property 'bodyText' of null
    at Selection.nextItemOffsetInDirection (/Users/robintrew/Code/birch-1.0.0/birch-outline-editor-package/lib/
    at Selection.selectionByModifying (/Users/robintrew/Code/birch-1.0.0/birch-outline-editor-package/lib/
    at OutlineEditor.module.exports.OutlineEditor.modifySelectionRange (/Users/robintrew/Code/birch-1.0.0/birch-outline-editor-package/lib/
    at OutlineEditor.module.exports.OutlineEditor.moveToEndOfParagraph (/Users/robintrew/Code/birch-1.0.0/birch-outline-editor-package/lib/
    at birch-outline-editor.atom.commands.add.stopEventPropagation.editor:move-to-end-of-paragraph (/Users/robintrew/Code/birch-1.0.0/birch-outline-editor-package/lib/
    at birch-outline-editor.newCommandListeners.(anonymous function) (/Users/robintrew/Code/birch-1.0.0/birch-outline-editor-package/lib/
    at CommandRegistry.module.exports.CommandRegistry.handleCommandEvent (/Applications/
    at /Applications/
    at KeymapManager.module.exports.KeymapManager.dispatchCommandEvent (/Applications/
    at KeymapManager.module.exports.KeymapManager.handleKeyboardEvent (/Applications/

The error was thrown from the birch-outline-editor package.

Ok, tracked this down… I thought I’d been careful, but this is another case of me using Birch API that I hadn’t yet shared with everyone else. The latest version of Birch 1.1.0 should fix this problem.

To use the ESC t u shortcut to set a bulleted/unordered line in the copy of the Markdown package on Github today (2015-03-22 20:00), a small edit may be needed in birch-markdown.cson in the keymaps folder:

't u': 'birch-markdown:make-unordered-list'

't u': 'birch-markdown:make-bullet-list'

(Version 1.1.1 at is fixed now )

I’ve installed the updated foldingtext-markdown package and I find that ‘t’ activatese without me having to use Esc first.

This means that I have to type ‘t’ twice because the first ‘t’ seems to trigger ‘foldingtext-markdown’.

Slight key-assignment clash there, I think, between the ESC t for Markdown types, and the new ESC t for tagging.

In the meanwhile, in my local copy, I have personally switched for the moment to ESC m for Markdown types, by editing the foldingtext-markdown.cson file, and restarting Atom.

My copy of foldingtext-markdown.cson file now contains:

Looks like I messed that up a bit in the rename. The issue is that I didn’t properly scope those keyboard shortcuts. This means that those shortcuts should apply for any keystrokes in the outline editor:

  't p': 'foldingtext-markdown:make-paragraph'
  't h': 'foldingtext-markdown:make-header'

But really it should be: (I just pushed the fix to the repository)

  't p': 'foldingtext-markdown:make-paragraph'
  't h': 'foldingtext-markdown:make-header'

That extra outlineMode scopes those shortcuts so they only work when in “outline mode”. Then they will no longer conflict with normal text entry. You can find more information on how Atom key maps work here:

@garmain And now reading the next post @complexpoint is also right, the t conflicts with the t used to start tags. This is a separate issue, and in the current state it actually should work, but it’s not ideal.

It should work like this:

  1. Press t and wait for a time period and then tags will popup.

  2. Press t p and when the Markdown package is install the current items should be matched as a paragraph immediately.

What’s happening is that Atom sees that the first t is both a match and a partial match of a bigger patter. In that case it will wait for a bit to see if it gets more input, and if it doesn’t it will match the first match “edit tags”.

So it works, but isn’t idea since it creates a delay anytime you want to use edit tags. I think @complexpoint’s solution to change to m * is good and I’ll make that change in a few minutes.

Though I expect at some point it might change again, I still haven’t taken the time to thing much about how all the keyboard shortcut possibilities should interact.


I just pushed two more updates to foldingtext-markdown.

  • Changed to use m * shortcut for setting types
  • Fixed some bugs in “Copy Markdown” command.

With that said, please remember this package isn’t really ready for prime time!


This package is still not a complete solution. But for those who want to test and keep up with changes I’ve published it to That means you can install it using:

Atom > Preferences > Install

(Search for foldingtext-markdown) and install. Instead of having to do command line stuff.

An even better you’ll automatically get notified when I updated, and be able to update in a single click.


Possibly a quirk or defect of my personal memory space, but I always had to pause to distinguish the twin words ordered and unordered when making markdown list items.

o vs u happens to feel a little less clear to me than o for order vs b for bullet (particularly now that the FTML format is using data-type="Bullet", as in the CommonMark name scheme.

In the

Atom > Open your keymap

settings (the keycap.cson file) I have added:

  'm b': 'foldingtext-markdown:make-bullet-list'

(as an alternative to the ESC m u default)

I agree that’s more consistent, and also easier to type. I’ve made that change in release now too.