Adding Vim-style marks to the hints feature

[caminante-blanco]

My biggest issue with the hints menu in extensions like vimium is that the keystrokes necessary to perform an action on a given website are unmemorizable and unpredictable. For me, this can really hamper the usefulness of hints for navigation. Ideally, the workflow would be more similar to switching between vim buffers, where you know that :b 2 will always do exactly the same thing.

For example, I use the web client for Google messages, and every time I switch to the browser window in my tiling window manager, I have to press f, parse what the hint for the message text-box is, and type it. If I could count on that keybind being consistent, I could commit it to muscle memory, but it's different for every page, and maybe even from tab to tab.

My thought is that maybe the UX can be improved by taking a page out of the marks feature in vim. The workflow would be as follows:

1. Setting a Mark (Mark Mode)

• The user presses m in normal mode to enter "mark mode."
• This would bring up the same hints overlay as pressing f.
• The user types the existing hint characters for an element (e.g., 'a' or 'ey').
• Immediately after, the user types the new, desired string for the mark (e.g., '1' or 'iu').
• The user presses Escape to save the new mark. The association is now saved for that element on that specific webpage (URL).

2. Using a Mark (Hint Mode)

• The user presses f to bring up the hints, as they normally would.
• The hinting system will now prioritize any saved marks for the current page, displaying the custom, user-defined names instead of the dynamically generated ones. For example, the element previously marked as 'iu' will now appear with the 'iu' hint.
• All other hintable elements will still be available with their standard, dynamically generated hints.
• The user can then type the mark name ('iu') to interact with the element, just like a regular hint.

3. Storing marks across browser sessions

A fingerprint of the marked elements could be stored as a JSON object, containing things like inner text, id attributes, the dom path, etc. I don't work in web dev much, so I'm not sure what best practices are here, but it seems like a solvable problem. For my use case at least, I don't need it to be perfect, just a little resilient to website changes.

4. Files to change

From what I understand, some changes would need to be made to hinting.mts, hints.mts, keymaps.mts, and a new file named marks.mts or something equivalent.

I'm no typescript expert, and I know this is probably not a super urgent or essential feature, but it's one I'm interested in, and would be happy to work on. I just thought I would put it out there, and see if anyone had any thoughts.

[roceb]

I like this idea.

[RobertCraigie]

Thia is a cool idea, thank you! I have considered the "hints should be stable" problem briefly before but didn't put as much thought into it as you have :)

I'm not quite sure yet whether I'd want marks to be be something like this, or more similar to vim marks, which could also be pretty useful. e.g. if you're frequently switching between a couple tabs or within the same tab, vim-style marks would be quite nice.

Regardless, I am on board with adding a feature like this! It might just end up going under a different name / default keymap.

I especially like your proposed UX flow for setting and using marks. I'll note that, depending on the website, being resistant to DOM changes could be quite difficult, and impossible to achieve fully. That said, I don't think that's a huge deal - especially if it'd be easy to customise how the elements are matched.

Maybe this is crazy, but it might make sense to define a "managed" glide.ts, similar to how Firefox has user.js and prefs.js, and store the marks there instead of coming up with a JSON object notation. This would make it super easy to copy the marks that glide generates automatically into your own glide.ts, so you can track / tweak them.

---

For what it's worth, you could make hints stable today by calling glide.hints.show() directly and passing a custom picker which you could then use to sort the returned hints so that the element you want to be stable is shown first. (obviously this is much less ergonomic than your proposed solution)

See

glide/src/glide/browser/base/content/plugins/keymaps.mts

Lines 44 to 49 in 81e21d0

	glide.keymaps.set(
	"normal",
	"gI",
	() => glide.hints.show({ auto_activate: true, editable: true, pick: hinting.pickers.biggest_area }),
	{ description: "Focus the largest editable element on the page" },
	);

and

glide/src/glide/browser/base/content/hinting.mts

Lines 185 to 204 in 81e21d0

	biggest_area: (hints) => {
	if (!hints.length) {
	return [];
	}
	let biggest_hint = hints[0]!;
	let biggest_area = hints[0]!.element.offsetWidth * hints[0]!.element.offsetHeight;
	for (let i = 1; i < hints.length; i++) {
	const hint = hints[i]!;
	const area = hint.element.offsetWidth * hint.element.offsetHeight;
	if (area > biggest_area) {
	biggest_hint = hint;
	biggest_area = area;
	}
	}
	return [biggest_hint];
	},

for a builtin example of this at play.

---

For example, I use the web client for Google messages, and every time I switch to the browser window in my tiling window manager, I have to press f, parse what the hint for the message text-box is, and type it.

Additionally, I don't know what the UI looks like but I suspect this will work - try pressing gI next time you're on that tab ;)

[peff]

In my experience, just walking the DOM and assigning in order is enough for most sites to give you predictable hints. Tridactyl's "numeric" hint mode works this way, and you can get the same behavior with this tiny patch:

diff --git a/src/glide/browser/base/content/browser-commands.mts b/src/glide/browser/base/content/browser-commands.mts
index 3e8cc60..5e1a70e 100644
--- a/src/glide/browser/base/content/browser-commands.mts
+++ b/src/glide/browser/base/content/browser-commands.mts
@@ -170,7 +170,7 @@ class GlideCommandsClass {

     for (let i = 0; i < hints.length; i++) {
       const hint = hints[i]!;
-      hint.label = labels[i]!;
+      hint.label = (i+1).toString();

       const hint_div = DOM.create_element("div", {
         className: `glide-reset glide-internal-hint-marker`,diff

I'd love for it to be a real feature, but I wasn't sure of the right way to integrate it. One option is to just have a config option for "numeric hints". Allowing a custom function (that could obviously just yield 1..hints.length) would be more flexible. But what I'd really like to be able to do is say "this is how hints are always generated", rather than having to pass the picker function to each call to glide.hints or :hint.

[RobertCraigie]

I'd love for it to be a real feature, but I wasn't sure of the right way to integrate it. One option is to just have a config option for "numeric hints". Allowing a custom function (that could obviously just yield 1..hints.length) would be more flexible

I haven't checked how tridactyl exposes this exactly but generically my philosophy is that if other similar projects have a dedicated config option for a feature, it'd make sense to do the same in glide. Even if there's a more powerful / flexible way that it could also be achieved.

Definitely agree that allowing a custom function to generate the labels would also be a useful feature to include.

But what I'd really like to be able to do is say "this is how hints are always generated", rather than having to pass the picker function to each call to glide.hints or :hint.

Yeah for this particular suggestion, I can see an option along the lines of this working quite well:

glide.o.hint_label_style = "numeric";

Does need a naming bikeshed though, any suggestions welcome.

[RobertCraigie]

btw in the latest version you can now use a basic form of numeric hints with:

glide.o.hint_chars = "123456789";

[NonlinearFruit]

Leap.nvim's (github) solution to this problem is interesting.

Leap's approach (as far as I know)

In Leap's "hint" mode:

1. the hint is the beginning of the word. So if you want to jump to apples, the hint would be ap
2. hints are also always (?) two letters
3. if the first two letters are not unique, a 3 random character is added to the hint
4. hints are displayed in line
   1. since the first 2 letters of the hint are already known, they aren't displayed
   2. when an ambiguous hint is started, the 3rd letter of the displayed text is changed to a random character (see screenshot)

screenshot of searching `le` with multiple matches

Since there are multiple jump locations for le, a random hint character (s and f) is displayed inline to pick which one you want.

(source)

Issues Applying to Glide

1. There are a lot of clickable things that don't display text
   • A solution could be using accessibility features (when available) like labels and alt text
2. This doesn't make every hint predictable
   • Could be combine with other solutions here to make the 3rd random character of the hint stable/consistent