Markdown toolbar: improve logic for syntax insertion depending on cursor position

[aitchiss]

This issue covers two main logic improvements for markdown formatting

1. Inserting formatting in the middle of a line or word

At the moment, we insert any formatting wherever the cursor currently is, without regard to where that is. Let's improve that:

If the cursor is in the middle of a word, and no text is selected, and an "inline" formatter is used, we format the whole word

Inline formatters are those which do not require new lines to be inserted. For example bold, italic, underline, strikethrough.

For example, (imagine the | character is a cursor) given the cursor position some|thing, pressing the bold formatter would result in **something**. i.e. when the cursor is in the middle of a word, with no text selected, then the formatter buttons behave as if the whole word had been selected.

If the cursor is in or at the end of a word, and no text is selected, and a "block" formatter is used, we bring the given word into the inserted block formatting

Block formatters are ones which require new lines on either side. For example: ordered/unordered lists, code blocks, blockquotes, new lines, headings.

Given the user has their cursor at the end of word, e.g. (imagine | character is the cursor) Something| or Some|thing, when a user uses a block formatter like unordered list, the word "Something" would be brought into the formatting, e.g.:

- Something

In other words, when the cursor is inside or at the end of the word, the formatter behaves as if the whole word had been selected

2. Ignore leading and trailing whitespace

When a user highlights trailing whitespaces on either side of a phrase, currently we treat this as part of a selection meaning we might insert e.g. **some text **. Similarly, if a user doesn't highlight the exact portion of formatted text, clicking the button will not 'undo' that syntax - e.g. if user highlights **something** (including trailing space), the result would be ****something** **.

Let's improve the UX here by ignoring any trailing/leading whitespace on a word selection. i.e. if a user highlights a word or phrase that begins and/or ends with a space, the result should be the same as if they had not selected the spaces.

[github-actions]

Thanks for the issue, we will take it into consideration! Our team of engineers is busy working on many types of features, please give us time to get back to you.

Feature requests that require more discussion may be closed. Read more about our feature request process on forem.dev.

To our amazing contributors: issues labeled bug are always up for grabs, but for feature requests, please wait until we add a ready for dev before starting to work on it.

To claim an issue to work on, please leave a comment. If you've claimed the issue and need help, please ping @forem-team. The OSS Community Manager or the engineers on OSS rotation will follow up.

For full info on how to contribute, please check out our contributors guide.

[MdSahil-oss]

@aitchiss these features looks interesting to me and I'd like to add them in dev text editor.

[Link2Twenty]

While making a POC for something else I thought it might be worth making a hook that has a bunch of editor features on it.

https://codesandbox.io/s/misty-wood-dr09ym

This is a paste URL POC but is using a hook that can be used for lot of things. One of the functions on the hook is getSelection which returns the following object.

{
  start: 2,
  end: 8,
  value: 'cheese',
  special: {
    isSpecial: true,
    type: 'bold',
    value: '**cheese**',
    start: 0,
    end: 10
  }
}

Special becomes true if the cursor is within any of these characters.

It feels like an editor hook might be the way to go if we're gonna want to have lots of flexibility.

Edit:
I got a bit carried away and made a POC toolbar too.
Even more carried away and added the ability to check where the caret is on the screen.
And now pressing @ opens a pop over panel...