So something that has been annoying me within markdown is the default for a html reference ( <a href=... ) is to use the same window/tab.
My preference for giving out links to other sites is to have them open in a new window/tab, so as a result I use html references directly within markdown more often than not. It's a minor annoyance as its not actually that hard to type out the syntax. After all, I've done that for many years now in other editors!
One thing that has annoyed me to the point where I have 'fixed' it is that Atom has a bug where if something starts with an underscore, it must therefore be the start of a long sentence that should be displayed in italics. This is a bug which all newly opened tickets get re-pointed at issue #44 of the language-gfm module and closed if they are opened. Thankfully I've learned to check closed issues previously, so did find that out before opening a new ticket myself...
After spending a bit of time trying to remember how regex worked, I managed to figure out a fix. I modified line 40 of my local instance of the gfm.json (located at /Applications/Atom.app/Contents/Resources/app/node_modules/language-gfm/grammars/gfm.json on my system) file within the language-gfm module from:
"begin": "(?<=^|[^\\w\\d_\\{\\}])_(?!$|_|\\s)",
to:
"begin": "(?<=^|[^\\w\\d_\\{\\}])_(?!$|_|\\s|blank['\"])",
In more words, this means that if an underscore ( _ ) is found, and it isn't immediately followed by blank' or blank", then it will continue as the start of italics in markdown. This means that target='_blank' and all the words following it within the Atom editor will stop showing in a different colour and as italics while words are being electronically inked to the virtual paper. _blank_ and _blank blanky blank_ will still work of course. This is an edge case, and my implementation is a nasty hack. A hack that works, so I'm happy.
I then thought I'd fork the language-cfm module and submit the change for review as I'm sure I'm not alone in being annoyed by this bug - only to find out that this particular Atom module is written in coffeescript and not javascript as my local version is when I open the local source for that module.
I created the fork and updated it, but haven't submitted a pull request - coffee is written slightly differently to javascript (a ' is used instead of a " and escaping both highlights a syntax error in the editor). As I'm still trying to learn coffeescript (I'm writing a specific Rundeck module for our Hubot implementation within Slack) I'm not confident the regex will work after being compiled, so I am hoping it gets a more up-to-speed person to make a better (non-hack!) fix and submit it...