Taming the Command Zoo

[smblott-github]

We get many (perfectly reasonable) requests for new commands (here's one: #1264). However, in my view, we already have too many commands. We need a way of taming the command zoo.

Here's one idea:

• Currently, count prefixes have no meaning for o, and b.
• o open in current tab.
• 1o open in current tab (for symmetry).
• 2o open in a new tab.
• 3o open in a new window.
• And similarly for bookmarks.

And, for mappings:

map o Vomnibar.activate        # open in current tab
map o cur Vomnibar.activate    # open in current tab (variant of above, for symmetry)
map O tab Vomnibar.activate    # open in a new tab
map w win Vomnibar.activate    # open in a new window

Existing bindings would be grandfathered or migrated. No need for three versions of each command. Probably, a similar thing can be done for link hints.

If we were able to cut the number of vomnibar and link-hint commands by two thirds, we'd have a lot more room for maneuver.

[mrmr1993]

Why don't we allow commands to take arguments as part of the binding? Then we can hugely reduce the number of commands (and have some kind of seperate list of arguments for each command).

Still, the options dialog is a pain. We need a way to show more commands without making it even harder to find the one(s) you're looking for.

[smblott-github]

Why don't we allow commands to take arguments as part of the binding?

What do you have in mind? You could reformulate the suggestion above as:

map o Vomnibar.activate cur
map O Vomnibar.activate tab
map w Vomnibar.activate win

and consider cur, tab and win to be arguments. Do you have other examples in mind?

[mrmr1993]

Yup, that looks better to me! Perhaps for Vomnibar we could have

o Vomnibar.activate omni cur
B Vomnibar.activate bookmark tab
etc.

I would also think about grouping the scroll up/down commands as two commands that takes an argument step, halfpage, page. Obviously link hints also lend themselves easily to similar treatment.

As for the options dialog, we could show all bindings beside the base functions, and have them expandable to the specific cases when clicked. Eg.

o, O, b, B, T | activate the Vomnibar

Might expand to

o | activate the Vomnibar O | activate the Vomnibar and open in new tab b | activate the Vomnibar to search bookmarks B | activate the Vomnibar to search bookmarks in a new tab T | activate the Vomnibar to choose a tab to switch to

(I'm away from my computer, so you'll have to excuse that these aren't the descriptions we actually use.)

[smblott-github]

Yup, that looks better to me! Perhaps for Vomnibar we could have

Yes. I agree. But now I'm starting to think of these not as arguments, but as flags. Imagine the explanation...

---

Some commands can be customised via flags.

• Commands which navigate by URL (Vomnibar.activate, LinkHints.activate, duplicateTab, openCopiedUrl, (perhaps) createTab):
  • where: cur, tab, win
• Vomnibar.activate:
  • type: book, omni, tabs
• Commands which scroll (scroll):
  • direction: up, down, left, right
  • amount: step, half, page, max (max is gg and G).
  • That takes twelve commands down to one (plus a handful of obvious flags).
• Commands which change or move tabs:
  • direction: left, right
  • amount: min, max (defaults to 1 or count)

---

Instead of having NxM commands to describe, we have N commands plus M flags. The explanation is simple, it would easily fit in the freed-up space on the help page.

I can see us, a couple of years from now, having a thread Taming the Flag Zoo.

(Edit. This has been edited for clarity and formatting.)

[mrmr1993]

Nice, I like it!

[mrmr1993]

We get many (perfectly reasonable) requests for new commands (here's one: #1264). However, in my view, we already have too many commands.

@smblott-github in what way did you mean that we have "too many commands"? The only way that makes sense to me is that we have too many commands to display to the user in the help dialog.

Running with this assumption, a really easy fix seems to be to push all but the basic commands out of the help dialog and onto a separate page:

• we stop needing a scrollable modal window (which is bad UX);
• there's no pressure to reduce the number of commands;
• there's space to discuss quirks (eg. we can't activate hover styles for LinkHints.activateModeToHover in #1032, we don't detect elements with click handlers for LinkHints.activate, etc.);
• users are more likely to search (searching in a modal dialog is weird);
• users searches for commands don't interact with the underlying page (eg. try opening help and searching for "scroll" on this page);
• the help dialog would be a place where (mainly new) users go to "get help" with using the extension (instead of being our sole user-facing documentation for commands).

Would this deal with your concerns?

[mrmr1993]

@smblott-github request for comment here (or on #1280). I'd like to start working on a bundled documentation page, if it is indeed a reasonable suggestion.

[smblott-github]

@mrmr1993. I'm still not sure. Let me think about it. You could do the minimum amount of work possible to get some screen shots. Or do a mock up. Sometimes seeing something helps clarify one's thinking.

[mrmr1993]

At this early stage, I'm just planning a page containing a table with headings

mappings	description	command name	quirks

[dragon788]

I like where this is going. You can never have too many flags, unless you make it impossible to dump a raw list of them out somewhere. In my experience across a ton of command line driven systems, the only bad option is one that isn't easily accessible or is completely undocumented.

I've joked with my friend that I really need to write an infinite recursion tool in Python that calls every tool on a given system with a dictionary of commands and then read the STDOUT of the commands to find more options to pass until I have a complete map of every possible command and option. It really SHOULDN'T be that hard.