View menu consistency and length

[bpasero]

We are filling the "View" menu more and more with text editor specific things:

Bringing this up as a UX issue to think about if this is scaling going forward. Especially in the context of VSCode supporting custom editors and notebooks, I think this may not be the right solution, at the minimum maybe have a sub menu?

//cc @hediet

[miguelsolorio]

Would a menu item like Editor Features > make sense either in the first group or at the end?

[gjsjohnmurray]

Would a menu item like Editor Features > make sense either in the first group or at the end?

Putting it near the top would give its submenu more vertical space to grow into.

[daviddossett]

Would a menu item like Editor Features > make sense either in the first group or at the end?

To clarify, would that capture just these items? 👍 if so. Seems like it would fit nicely under Editor Layout >.

[miguelsolorio]

Here's to clarify what I meant: if we look at the "categories" it makes sense to be placed in the first group:

but, it also seems like it would fit inside of the other submenu groups even though they are different categories:

[daviddossett]

The second option is what I had in mind since it feels more closely aligned to how the editor is configured. The first section roughly seems like a place to do something once vs. toggling elements on/off.

[miguelsolorio]

The argument against that is those two items (Appearance and Editor Layout) are layout specific, whereas these would be feature toggles, so a little different.

[bpasero]

Yes, +1 for grouping into a category. I think somewhere close to "Editor Layout" is OK since that applies to editors.

One thing to consider is that afaik these toggles only apply to text editors, not all editors.