Consider consolidating all link hints commands to one: LinkHints.activate

[philc]

Today we have several very similar link hints commands. Each one specifies an option to a core command.

To improve this and allow people to combine these orthogonal options together, we could move to one command, LinkHints.activate, which takes parameters to customize its behavior:

• action: open, focus, hover, copy
• destination/placement: current tab, new tab, new window
• multiple: i.e. open many at once; currently LinkHints.activateModeWithQueue
• focus on open: whether to switch immediately to the new tab
• incognito: whether the destination should be an incognito window

This would make it seamless to add in long-tail use cases for the link hints command, like opening a link in a new window rather than a new tab (#3450).

These are the historical reasons we have separate commands for each parameter:

1. We added each link hints variant one at a time over many years.
2. The ability to have user-specified options on Vimium commands was added much later.
3. The only way we expose documentation about commands is in the help dialog, which even today doesn't have a way of listing and explaining the various options that some commands accept. However, we're progressing the UX towards this capability. Now the help dialog shows if a user has added any options to commands they've bound; next is to implement a better UX for documenting all commands and their allowed options (see [RFC] Add a (painfully) minimal commands listing #2827 for inspiration).

Backwards compatibility: we can either migrate people's existing configurations at the time they are read, or we can indefinitely support e.g. LinkHints.activateModeToOpenInNewTab as an alias for LinkHints.activate destination=newTab.

Related: #1948.

[UncleSnail]

I'm all for this, and can help with implementation if you like.
As mentioned, we would want UX for seeing all available options before we make the change. Have there been any updates on this/do you have a desired UX? If you have a plan, or want me to help develop one, I can implement it. This is a feature I also want.

For backwards compatibility, this will likely be a recurring issue, so we should make a "future-proof" solution.
Personally, I think a "translator" that governs how commands should be mapped to new versions is a good option, but it could cause problems.
We can link each translation definition to a deprecation version of Vimium, and map to a human-readable version (or just write a description). This way we can create a breaking changes list and make a note to the user when their config is updated that lets them see what the old/new commands are and the version that required the change. The config could then be automatically updated so that non-existent commands are never run.
This seems better than supporting old commands in general. However, it could mean performance losses since we would probably need to check the user's config for old commands every time Vimium reads from the config to avoid JS errors, correct? We could do almost the same thing with a mapping from old to new command that takes place on command run, and doesn't change their config. Then when the options page is opened, we make notes of any deprecated commands and give them a replacement line (with an option to automatically accept all changes).
This way we would never need to validate configs except on the options page (where they can change), and we still get user migration help, but old commands would still work.

Let me know what you think. We can start a new migration discussion and/or I can implement the above solution if that works for you.

[philc]

I don't have comments on the migration logistics for now. I've been working on the command listing UX which will lay some ground work for this.

[UncleSnail]

I don't have comments on the migration logistics for now. I've been working on the command listing UX which will lay some ground work for this.

Okay, just let me know if you want help with the UX design or implementation.