It seems to me that this should be fine because shortcodes are converted to blocks, which can't be inline. cc @ellatrix

I've only checked the default shortcodes, though. Perhaps there is some 3rd party shortcode that could be converted into inline formats. However, I don't see that's possible to do right now with the transformations API.

Yeah, I think it's fine if all the tests pass.

I disagree, I think it's fairly important to respect any third-party inline shortcodes. In my experience, the use cases are many and contemplate anything from inline formatting to marking positions in the document. (The question of whether shortcodes remain the right tool is not ours to ask here!)

It seems to me that this should be fine because shortcodes are converted to blocks, which can't be inline

Because even shortcodes that don't have a known associated block type will be picked up by the catch-all Shortcode block, we would be suddenly forcing all shortcodes to be block-like. One could let the editor differentiate between shortcodes with a known block type (which can never be inline) and unknown shortcodes (which may or not be inline), but I'd honestly stay away from implementing that. It would introduce a lot of complexity for little benefit.

Instead, it would be more interesting if the block editor were smart enough to decide when a pasted shortcode is meant to be inline or not. If it is, the editor should abstain from trying to make it a block. Concretely, these are some behaviours to consider:

1. Start a new line (i.e. a blank Paragraph) and paste a shortcode → Add a block for that shortcode.
2. Place the caret in the middle of some text and paste a shortcode → Insert the shortcode text verbatim, no new blocks.
3. Place the caret at the end of a paragraph of text and paste a shortcode → …? (up to us to decide)

I disagree, I think it's fairly important to respect any third-party inline shortcodes. In my experience, the use cases are many and contemplate anything from inline formatting to marking positions in the document. (The question of whether shortcodes remain the right tool is not ours to ask here!)

It seems to me that this should be fine because shortcodes are converted to blocks, which can't be inline

Because even shortcodes that don't have a known associated block type will be picked up by the catch-all Shortcode block, we would be suddenly forcing all shortcodes to be block-like. One could let the editor differentiate between shortcodes with a known block type (which can never be inline) and unknown shortcodes (which may or not be inline), but I'd honestly stay away from implementing that. It would introduce a lot of complexity for little benefit.

Instead, it would be more interesting if the block editor were smart enough to decide when a pasted shortcode is meant to be inline or not. If it is, the editor should abstain from trying to make it a block. Concretely, these are some behaviours to consider:

1. Start a new line (i.e. a blank Paragraph) and paste a shortcode → Add a block for that shortcode.
2. Place the caret in the middle of some text and paste a shortcode → Insert the shortcode text verbatim, no new blocks.
3. Place the caret at the end of a paragraph of text and paste a shortcode → …? (up to us to decide)

I didn't see this code at the time of approval. I feel like this belongs in the paste handler together with the rest of the short code logic?

I think code may have changed since your approval and Miguel's. I didn't think of pinging you for your re-approval after Miguel's approved changes, sorry.

However, I don't know how we can move this logic to the paste handler. The trick here is to switch to BLOCKS mode if 1) we're in an empty line and 2) the pasted text is a shortcode. This logic requires knowledge of the rich text value and the pasted content. My thinking was that having this on the rich-text component would make sense as we already do the same for URLs. How does this look? Happy to refactor if another approach is preferred.

Also the dependencies are missing in the package file

Also the dependencies are missing in the package file

Aside: I thought we had an ESLint rule which verified that any referenced dependencies should be listed in package.json 🤔

Ouch 😞 Here's the fix for the missing dependency #22086

Not sure I've done this before so I may have missed something.

Very strange indeed. It fails locally!

 ⇒ npm run lint-js                                                        

> gutenberg@8.0.0 lint-js /Users/andrew/Documents/Code/gutenberg
> wp-scripts lint-js


/Users/andrew/Documents/Code/gutenberg/packages/block-editor/src/components/rich-text/index.js
  42:1  error  '@wordpress/shortcode' should be listed in the project's dependencies. Run 'npm i -S @wordpress/shortcode' to add it  import/no-extraneous-dependencies

✖ 1 problem (1 error, 0 warnings)

The Travis job for this PR didn't report anything neither for all subsequent PRs. Just looked at the logs and there aren't any messages about the failure either (it could be that the exit code was wrong for some reason but the message was there).

I can confirm that npm run lint-js and npm run lint do fail locally on master prior to the merge of #22086 Puzzling.

Aside: I thought we had an ESLint rule which verified that any referenced dependencies should be listed in package.json 🤔

Oh, that's unfortunate, I let my guard down too. 😞

I didn't see this code at the time of approval. I feel like this belongs in the paste handler together with the rest of the short code logic?

Perhaps, but there are a lot of symmetries with what we do with pasted URLs and embeds. Whatever we do, we should do for both shortcodes and embeds. Perhaps that means letting pasteHandler choose whether to force mode: 'BLOCKS' when initial mode is 'AUTO'; perhaps that means exposing a utility like inferMode or shouldForceBlocksMode from @wordpress/blocks that RichText can use.

Very strange indeed. It fails locally!

After some more debugging, I think I've figured it out.

Fix (and debugging details) at: #22088

Sorry, I don't mind the code, it's something we can always easily change. I was thinking we could also pass empty state to the raw handler. I just thought it might be nice to keep shortcode dependencies in the raw handler since it already depends on it and RichText doesn't. I just noticed the code when I saw the package error.