Describe the bug
When creating a new block and a phrase is entered that does not match any existing blocks, backspacing will not re-display applicable blocks.
Steps to reproduce the behavior:
Reference above gif.
Once the phrase is backspaced to a point where there are block type matches, said block type matches should be displayed.
Desktop (please complete the following information):
- OS: Windows 10
- Device: Desktop
- Version: 0.16.1
I’m not sure this is totally necessary to say, but I think it’s worth pointing out that the gif illustrates the issue in a slightly confusing or misleading way. It shows you leaving the block and creating a new one (i.e. “enter”) before backspacing back into the original one to hopefully invoke auto-complete again, as you state. But this is probably intended and necessary behavior.
Once you leave the block, it is no longer automatically interpreting the slash as a “slash command”. This may be for the best. Imagine for example if you have a block of text that includes a slash/slash like this and you later click onto it to edit that text, with no intention to invoke the “slash menu”. To work as you demonstrate, I think it would have to parse the text and invoke the slash menu every time you go into edit on a block that includes one.
That said, even if you do not leave the block, you are correct that the slash menu auto-complete stops working once it gets into a no-match situation, even if you backspace without enter/newline. So this is definitely a bug. I just thought it might need clarifying a little. Sorry if I’ve stepped on your toes, not my intention.
Hey, @gray @Oshyan!
We will fix the behavior when nothing was found for this kind of situation. That’s a bug.
So we are going to leave the ability to use / as a simple text symbol and make a less strict condition for longer text with typos like