Some notes.

One issue with the "hints" mode is that adding text to the page may shift it relative to the viewport. Considering this, a possible algorithm:

• mark position
• mark first link whose box starts on screen
• loop over layout tree, add hints in DOM to all rendered links whose box starts inside the screen
• reshape
• shift screen by (marked link position) - (old marked link position)
• eat user input (link number)
• remove hints from DOM
• jump back to marked position
• load link number (or do nothing if user canceled)

It's more complex than I expected, but not unmanageable. I wonder if it works with an acceptable latency on larger pages...

LIST_MENU (I think you mean that one, SELECT_MENU is different) is much easier:

• collect anchor href + textContent from DOM
• retrieve nearest link (w3m does something like getCursorClickable, but findPrevLink seems better)
• open menu, with initial item set to nearest link

It doesn't mess with the DOM, and needs no reflow (i.e. is probably faster). OTOH with many links on the screen it may be annoying to find the preferred one, as the menu can only display one link per line.

Aesthetically, a menu would, in my opinion, look a lot cleaner and, therefore, better :). However, you are right that it may appear challenging to find the right link. Besides, the menu approach is only known to w3m users, while the hints mode would be already familiar to anyone, who was previously accustomed with some of its variations via numerous extensions for GUI browsers (or even at the OS level), so the UX would be more widespread and even to some degree more consistent.

The menu approach would probably require more interaction from a user, too: when opening a menu, a user will have to scroll it with their eyes to find the right link (and maybe even press some additional keys for that). While with the hints, a user is usually already looking at the link they want to jump or to open. Then they invoke the hints mode, and the hint appears exactly at their sight, so they just press it -- and voilà.

However, in the end, of course, it's up to you, the developer, to decide, which way to choose. Unfortunately, can't really help you much here :).

The menu approach would probably require more interaction from a user, too: when opening a menu, a user will have to scroll it with their eyes to find the right link (and maybe even press some additional keys for that).

Yeah, that's my main concern. e.g. on the HN front page the 5th submission (~at the middle of a 24 line screen) is already at the 2nd LIST_MENU page.

I'm personally into the idea of a "hints" mode.

Could it be an option to overwrite a few chars of the link text to add [1] (with a (hopefully) special color to indicate that it's a hint) to avoid having to reshape? I'm thinking of how qutebrowser displays its hints, which tends to overlap with the link text itself. Though, some links can be shorter than 3 chars, I don't really know how one could deal with that.

(Also I think I prefer [a-zA-Z]+ hints)

~cutenice wrote:

I'm personally into the idea of a "hints" mode.

Could it be an option to overwrite a few chars of the link text to add [1] (with a (hopefully) special color to indicate that it's a hint) to avoid having to reshape? I'm thinking of how qutebrowser displays its hints, which tends to overlap with the link text itself. Though, some links can be shorter than 3 chars, I don't really know how one could deal with that.

Yeah, I hadn't suggested this because it needs absolute positioning, and that didn't really work for inline boxes (i.e. most links) until two days ago.

It wouldn't skip the reshape, but at least we could drop the screen shifting logic. Maybe it's better UX too; even if a hint fully obscures a short link, you can just exit hint mode to see it again.

(Well, there is one problem left: right now, images don't really respect Z ordering, so it's impossible to draw text above them. But image links are less common, so they can be ignored for the initial implementation.)