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.

[sbatten]

As @jrieken pointed out, this has a high chance of causing anger for a minor beautification. Based on his experience, he would not move forward with this for the most popular commands in the menu. This looks to be Word Wrap.

Should we keep word wrap where it is and add a submenu entry below that named: "Additional Editor Options"

[daviddossett]

As a gut reaction it feels strange to split these out into a single option + all others folded into a submenu. Would these still be in this section?

Or would everything be put back at the bottom like it was before? If so I might argue for us to simply revert to what was there before vs. some in-between solution.

[sbatten]

I would guess it makes sense to keep it on the bottom. It seems the original problem is that we keep adding to this list so we cannot scale it. So having the top/high-use ones in the main entry and overflowing has some merit, but I agree that in between feels strange.

[sbatten]

@jrieken was your experience in the top level menu or for a context menu entry? if it was a context menu, I would imagine the usage was significantly higher, but I'd like to verify that through data. Could you share the command id?

[jrieken]

Yeah, those was the editor context menu. It's already one or two years ago but I remember folks missed some but not all peek actions. Like peek references/definition are popular but peek implementation isn't etc. We decided all go-to commands are more popular than any peek command. That looks nice/stable but wasn't a good choice. That's why I am in favour of a hybrid approach

[bpasero]

Works for me, thanks!