Add goUp options to pop URL anchor/fragment/hash & query string

[ravindUwU]

Description

This PR,

• Changes how goUp manipulates the URL, using a URL object to parse/get/set its components where possible.

• Adds 2 count-compatible Boolean options to goUp:

  • popAnchor removes the anchor/hash/fragment from the URL.
    example.com/a?b=c#d → example.com/a?b=c.

  • popQuery removes query params and the anchor from the URL.
    example.com/a?b=c#d → example.com/a.

Fixes #3763. Also relevant: #1344.

Usage

• map gu goUp
example.com/a/b?c=d#e → example.com/a → example.com

• map gu goUp popAnchor
example.com/a/b?c=d#e → example.com/a/b?c=d → example.com/a → example.com

• map gu goUp popQuery
example.com/a/b?c=d#e → example.com/a/b → example.com/a → example.com

• map gu goUp popAnchor popQuery
example.com/a/b?c=d#e → example.com/a/b?c=d → example.com/a/b → example.com/a → example.com

Subdomains

#3763 also suggests popping subdomains, but it's unclear how/if port numbers should be manipulated when navigating up a subdomain. e.g., should goUp from owo.example.com:1337 navigate to,

• owo.example.com (dropped port)?
• example.com:1337 (dropped subdomain)?
• example.com (both dropped)?

IMO, there is no correct option here because it depends on what's at the URL, so I think it'd be best to leave the host name as-is. This would also be consistent with goToRoot 🤔.

[philc]

Please expand on your use cases which requires popping the query string or anchor often enough for it to be a command or option.

For my own usage, I think the default behavior of goUp today is what I most generally want: go one path upward, and remove any query strings or anchors along the way, without needing several invocations. If accurate, then we shouldn't change that default behavior by making the first invocation remove the query string or hash anchor if present.

I find removing query strings and anchors to be rare. When I need to do it, I use ge to edit the current url, and ctrl-w on Mac (which deletes a whole word) to remove hunks of the URL. This is fast enough for me. If I wanted to copy and paste the URL without the anchor portion, I would copy it with yy and edit it after pasting.

[ravindUwU]

Hi @philc 👋

expand on your use cases which requires popping the query string or anchor

Personally, removing the anchor is something I do quite often! e.g., I'd follow a link to the documentation for the System.IO.DirectoryInfo.GetFiles(String, EnumerationOptions) .NET method overload. This link has the anchor #system-io-directoryinfo-getfiles(system-string-system-io-enumerationoptions), which I'd like to remove to form the link to the documentation of the .NET method group. My options are to,

1. Visit the link to the .NET method group from elsewhere on the same page (e.g., sidebar). But, what if there is no sidebar, or it is collapsed or out of view by default?
2. (Similar to what you suggested) Ctrl+L to focus the URL bar, End to go to the end of the URL, Ctrl+Backspace 9 times and then a final Backspace to delete word-by-word until the anchor and the # is removed, finally Enter to accept. But, that's a lot of key presses!
3. Or if goUp can remove the anchor if it exists, simply, goUp.

Popping the query string on the other hand isn't something I do often. (Edit because this just happened). Popping the query string might be useful when, e.g., I'm on the Discord server search page for a specific search term https://discord.com/servers?query=huh and I want to drop the search term (in this case ?query=huh) to visit their server list, which is simply https://discord.com/servers. My options are to,

1. Scroll uppppppppppp to locate the "x" button in the search bar on the page, and press it (which in this case is possible with Vimium; but there are many websites with small, interactive elements that aren't marked as such using accessibility attributes (role, tabindex, etc.), and therefore aren't detected by Vimium).
2. Ctrl+L, End, Ctrl+Backspace twice, Backspace once more, Enter.
3. Or if goUp can remove the query string if it exists, simply, goUp.

then we shouldn't change that default behavior ...

Agreed; the default behaviour should not change. This PR adds these as opt-in options so they are disabled by default, and can be enabled by those who find them useful.