Not able to remove Heading 1

[mortmoe]

Describe the bug

If you configure Heading or HeadingWithAnchor without level 1, for example:

HeadingWithAnchor.configure({
    levels: [4, 5]
})

... all other levels will be disabled.

To Reproduce

Fork the demo and configure HeadingWithAnchor in useExtensions.ts

Expected behavior

Should be able to remove heading 1 :)

System (please complete the following information)

• mui-tiptap version: 1.8.0
• tiptap version: 2.0.4
• Browser:. Chrome

Forked the demo i codesandbox to modify and see if it would fit my needs, by altering the toolbar to remove the things I don't want. (And it does... except I only want H5 and H6 available for users)

Additional context

Had a look at the code and this seems to be where it's all originating (MenuSelectHeading.tsx line 193):

  // We have to pass a level when running `can`, so this is just an arbitrary
  // one. And we have to check `currentLevel` to prevent all other heading
  // levels from being disabled when Heading 1 is selected (see
  // https://github.com/sjdemartini/mui-tiptap/issues/197).
  const canSetHeading =
    currentLevel === 1 || !!editor?.can().setHeading({ level: 1 });

Could canSetHeading should be defined like this instead, or would that lead to other problems?

const canSetHeading = [1,2,3,4,5,6].some( lvl =>  
      currentLevel === lvl || !!editor?.can().setHeading({ level: lvl })
)

... or any other way to check that at least one heading can be set

[sjdemartini]

I guess I assumed the first heading would always be enabled if any other headings were haha, didn't expect a scenario with "skipping" headings. Your suggested fix would probably work (checking each level in succession), though may be less performant. It may be better to grab the list of enabled levels from the Heading extension configuration, and just check the first one from that.

[mortmoe]

I guess I assumed the first heading would always be enabled if any other headings were haha, didn't expect a scenario with "skipping" headings. Your suggested fix would probably work (checking each level in succession), though may be less performant. It may be better to grab the list of enabled levels from the Heading extension configuration, and just check the first one from that.

Hehe, yeah I guess that would do the trick, didn't think of that.

The use case I'm working on is for users to add a simple description to a model in my app, and some notes. We've used standard mui header font sizes in the app and the responsive font functionality built in as well. We want to limit the input format quite a lot to avoid to much of a circus in there 😀 I guess we could make a separate theme for the user input but it would be easier to just remove the largest headings and use the same theme as the rest of the app 😀