This doesn't quite have everything from the project description just yet. I'm not sure if the current implementation is easily open to modification by extensions though so I thought I'd just put up an initial review request to see if there's something big.

This bit looks a bit weird; it's for the upload image button, which is different from the other buttons because it's an input hidden in a label. It needs the _uploadImage function from RB.TextEditorView but also needs access to the input element to get the file. There must be a nicer way to do it but I'm not sure how.

The button that toggles the rich text attribute is a bit tangled up in inlineEditorView so I wasn't sure how to pull it out to display on the right hand side of the text field where I think it'd also look better in line with the rest of the buttons in the toolbar.

I'm excited to see this come together! Thanks for sticking with it :)
This review looks large. Most of it are small tasks about complying with doc/syntax standards.
There's a few bigger-ticket items:

Updating the CSS to adhere to our CSS Component styles (I go into this and provide links below).
Re-evaluating some regexes (we can talk about this in Slack if it helps).
Placement of the toolbar.

I'd knock out the easy things, update the change, and then we can talk about the bigger items.

I think it'd look nice to have this show up within the editor. Kind of like in Asana. By having it within the confines of the text area, it more directly connects it to the content.
I don't know how hard this is. It'll have to happen before we release Review Board 5 for sure, but I know you have a full-time job these days. If this ends up being a lot to figure out, I'm okay committing without this, and moving this work to our plate.

Since we're in the final stages of this, it'd be nice to move this into rb/css/ui/formatting-toolbar.less and to use our CSS component style and documentation conventions. You can see a good example of this in page-sidebar.less, and see docs here:

CSS/LessCSS Component Style Guide
Writing CSS/LessCSS Docs

It's best not to override the function. Instead, let's bind it when we pass it to the constructor below.

To stay consistent, the pattern we normally use is:

this._$toolbar.$el.appendTo(this.$el);

Two blank lines between top-level classes or functions.

Option arguments should be documented in an Option Args section, following Args. These work just like other arguments, listing names, types, and descriptions.

Can you have this wrap? You can separate it into a chain of jQuery statements.

Element building should happen in render().

This can be one line, since we're not chaining.

We currently avoid for .. in, due to Babel's expensive, verbose transpilation. Can you convert this to a standard for loop?

Missing quotes around ${id}, to make the tag valid.

The .addClass should be indented 4 spaces.

I think this can be consolidated a bit, and updated to be more explicit at the same time. How about:

const $buttons = this.btnGroups[id].map(
    buttonInfo => this._makeButton(buttonInfo));

this.$btnGroups.push($(`<div id="${id}"/>`)
    .addClass(...)
    .append($buttons));

Let's name buttonInfo options instead, and add an Option Args section so it's clear what's allowed by the caller.
Also needs a Returns.

We're largely moving to .on() instead of shortcuts like .click() for clarity (and to avoid some issues with edge cases that we've encountered in the past).
This can also be combined as:

$button.on('click', (_.isFunction(options.onClick)
                     ? options.onClick
                     : this[options.onClick].bind(this)));

For a setter, "Set the position of the cursor" would be more correct.
This also isn't specific to emphasis.

We fetch this._codeMirror multiple times. Let's pull it out into a variable to reduce lookups.

"Toggle"

A few notes:


You'll need to escape these. You should use double backticks around these, instead of quotes. The backtick one is tricky. Just say "or a backtick for code."


You mention * for italics, but the handler for the italic button uses _. We should say that in the docs here.


Much of the content in this is probably most suitable for the main doc description.

I don't think the term "emphasis" is quite right. In Markdown, it can refer to bold/italic, but not strikethrough or code. How about toggleInlineTextFormat?

Let's pull this._codeMirror out into a local variable here as well. We access it a lot.

The * should all align.

We don't use [..., ...] = ... syntax in our codebase, because Babel transforms that into some lengthy code. Let's instead pull this out as an array and then pull out the values from that.

I want to dive into this regex with you, because I'm not confident it'll do what you want.
Let's take a look at an example, using symbol='**' (as mentioned in the docs).

^[**]+|[**]+$
**sometext**

* isn't going to match the character *. In fact, it's not even valid regex by itself. What you'd need is \*\*, to get the literal characters.
Even then, [\*\*] is equivalent to [\*], since [] is used to specify a set of possible matches for a single character. The generated regexes for bold are therefore the exact same as those for italic.
What's the main purpose of this particular regex? To match tbe beginning or end of a line?
If so, I'm not sure the | is going to work correctly here in all regex implementations without a containing parens (and I'm not sure the ^ or $ are guaranteed to work as part of that).
This might be worth going into one-on-one on Slack.

The asterisks should align.

Formatting isn't quite right here. This should look like:

const newSelection = selection.replace(
    new RegExp(...),
    '');

More cases of this regex. I count 3. Once we figure out what it should be, we should have a utility function that generates it, so that we don't have to repeat it.

Asterisks should align.

Seeing inconsistency on indentation. Can you make sure this is correct all throughout?

Same note as above with the [..., ...] = ... syntax.

THis can be a single-line comment.

This can be a singline line comment.

This can be a single line comment.

This line is too long. Can you wrap the second parameter to the next line>?

No blank line here.

This needs a "Returns" section.

"Find"

We access this._codeMirror many times. Let's pull it out into a variable.

Let's make this:

for (let curToken = codeMirror.getTokenAt(cursorStart, true);
     curToken.string !== ' ' && groupStart.ch !== 0;
     curToken = codeMirror.getTokenAt(groupStart, true)) {
  groupStart.ch -= 1;
}


And same below.
This better defines the scope and purpose of curToken and keeps the logic together as a single block of code with a clear intention.

You can use -= here.

You can use -=.

We can pull this._codeMirror out into a local variable.

"Insert"

"Markdown"

Let's pull this._codeMirror out into a local variable.

All arguments to a function should align.

This line is too long.
Also, we prefer to keep logic out of the ${...} references in format strings. Let's calculate a value separately and then include it.

These lines are too long. Let's wrap:

const precedingText =
    codeMirror.getLineTokens(...)
    .filter(...)
    ...

This line is too long. Let's do:

codeMirror.setSelection({
    ch: ...,
    line: ...,
});


And use alphabetical order on the keys.

Same notes as above with the expression and line lengths.

We avoid for ... of syntax due to Babel transpiling this into an expensive block of code. Let's just use a standard for loop.