Add combined version of hinting modes

[lrustand]

Is your feature request related to a problem? Please describe.
The default hinting mode is great with the ability to type in link text in addition to the hint labels in order to narrow down the results, but the prompt buffer is taking up too much screen real estate and is covering up the links on the bottom of the page. Vi hinting mode hides the prompt buffer, but only allows to type the actual hints and not the link text like the default hinting mode. Additionally, the hint labels do not get narrowed down when typing in either of the modes, only the prompt buffer results get narrowed down.

Describe the solution you'd like
I suggest adding a combination of the default hinting mode and the vi hinting mode, where the text input works like in the default hinting and the prompt buffer is hidden.

Describe alternatives you've considered
I tried using the vi hinting mode, but I really miss being able to narrow hte results down by typing in some of the link text.

Additional context
Add any other context or screenshots about the feature request here.

[aadcg]

Related to #2972.

This is important, but not our top most priority right now.

While the mode can be improved, the request is somewhat inconsistent. In order to choose a link via some of its text, the prompt buffer is paramount since there may be multiple matches. Also the prompt buffer enables acting on several links at once via actions-on-return.

[lansingthomas]

relevant design idea from a user:

"Link Hints: I know Nyxt already has this built in, but the Firefox extension only requires typing the letters in the hint, and not pressing enter to select an item. If Nyxt had an option so that if there is just one remaining hint in the list it could be selected automatically, that would be awesome."

[lrustand]

While the mode can be improved, the request is somewhat inconsistent. In order to choose a link via some of its text, the prompt buffer is paramount since there may be multiple matches.

No, the request is not inconsistent, but maybe you are misunderstanding something. There is no need for the prompt buffer in the mode I am suggesting. I am suggesting that the hint labels are narrowed down while typing. If we need to choose between several matching links we could still cycle through the remaining hint labels with a keybind. Yes, I see the value of acting on several links at once, and this is possible in the default mode, but not in vi mode or the mode I propose, so here the user would need to choose modes based on what they value most.

if there is just one remaining hint in the list it could be selected automatically

I agree with this, which is the behaviour I expect from hinting, at least when typing the exact hint letters. This would be nice to have, even as a toggleable option.

[aadcg]

@lrustand you're suggesting a mode that follows :emacs as its hinting-type but the prompt buffer is collapsed and the hints are narrowed down. The former can be achieved by invoking command toggle-suggestions-display, i.e. you can easily define a command that calls follow-hint followed by toggle-suggestions-display. The latter should probably be the default behavior, and it is already done for :vi mode. PRs welcome :)

I agree with this, which is the behaviour I expect from hinting, at least when typing the exact hint letters. This would be nice to have, even as a toggleable option.

This is the default behavior in :vi since it deals with hints in view port and it only acts on a single hint. In :emacs it is manifestly unreasonable to exit the prompt when it is narrowed down to a single suggestion since they may want to mark it.

---

Nyxt is configurable, but that doesn't mean that it must support all use cases. Each user has its requirements, so we should stick to the most general and reasonable default. Specific workflows can be achieved by personal configuration or public extensions.

[lrustand]

The former can be achieved by invoking command toggle-suggestions-display, i.e. you can easily define a command that calls follow-hint followed by toggle-suggestions-display.

Thanks for letting me know about toggle-suggestions-display, I will try it out and if it works, then great!

In :emacs it is manifestly unreasonable to exit the prompt when it is narrowed down to a single suggestion since they may want to mark it.

I hear what you are saying, and I agree that the current behaviour should be the default, but I still would like to have the ability to toggle it with an option. Also, if it is unreasonable or not should be up to each user to decide for themselves, no?

Nyxt is configurable, but that doesn't mean that it must support all use cases. Each user has its requirements, so we should stick to the most general and reasonable default. Specific workflows can be achieved by personal configuration or public extensions.

Yes, I agree 100%. I'm not asking for any defaults to be changed, only to be able to configure it how I want. I don't think what I'm proposing is unreasonable at all, the behaviour I'm describing is exactly how link hinting worked in either Tridactyl or Pentadactyl (don't remember which), and I do believe Qutebrowser can be configured to work like this as well.

Also, this does not really need to be a separate mode. It could just as well be a set of configuration options for example show-prompt-when-hinting and auto-choose-last-matching-hint.

[aadcg]

Also, if it is unreasonable or not should be up to each user to decide for themselves, no? [...] I'm not asking for any defaults to be changed, only to be able to configure it how I want. I don't think what I'm proposing is unreasonable at all, the behaviour I'm describing is exactly how link hinting worked in either Tridactyl or Pentadactyl

See #2865 for context. If a set of parameters is available for configuration, then we must ensure that all combinatorial combinations make sense. It is our responsibility to ensure that the configuration space isn't broken by design. By configuration space I mean the set of parameters that is easily configured, e.g. mode slots. It is important to distinguish that kind of configuration, which is bounded by what the API provides, from arbitrary configuration, which is still made possible by loading arbitrary code in the config file.

The kind of hint behaviour that you have described, up to my best understanding, is achieved by the command below. I don't consider it good enough. Example, at https://en.wikipedia.org/wiki/Cave_In there's a link called "Discography". But invoking custom-follow-hint and typing "di" will open the link whose hint overlay matches that string.

(define-command-global custom-follow-hint ()
  "Experimental prompt for element hints and open them in the current buffer."
  (prompt :prompt "Interact with element"
          :extra-modes (list 'nyxt/mode/hint-prompt-buffer:hint-prompt-buffer-mode)
          :auto-return-p t
          :history nil
          :height :fit-to-prompt
          :hide-suggestion-count-p nil
          :sources
          (make-instance
           'nyxt/mode/hint::hint-source
           :enable-marks-p t
           :filter-preprocessor
           (lambda (suggestions source input)
             (declare (ignore source))
             (loop for suggestion in suggestions
                   for hint = (prompter:value suggestion)
                   for hinted-element-id = (nyxt/dom:get-nyxt-id hint)
                   if (str:starts-with-p input
                                         (prompter:attributes-default suggestion)
                                         :ignore-case t)
                     do (nyxt/mode/hint::set-hint-visibility hint "visible")
                     and do (when (nyxt/mode/hint::show-hint-scope-p (find-submode 'nyxt/mode/hint:hint-mode))
                              (ps-eval
                                (nyxt/ps:add-class-nyxt-id hinted-element-id
                                                           "nyxt-element-hint")))
                     and do (nyxt/mode/hint::dim-hint-prefix hint (length input))
                     and collect suggestion
                   else do (nyxt/mode/hint::set-hint-visibility hint "hidden")
                        and do (when (nyxt/mode/hint::show-hint-scope-p (find-submode 'nyxt/mode/hint:hint-mode))
                                 (ps-eval
                                   (nyxt/ps:remove-class-nyxt-id hinted-element-id
                                                                 "nyxt-element-hint")))))
           :actions-on-return
           (list (lambda-command click* (elements)
                   (dolist (element (rest elements))
                     (nyxt/dom:click-element element))
                   (nyxt/dom:click-element (first elements))
                   nil)
                 (lambda-command focus* (elements)
                   (dolist (element (rest elements))
                     (nyxt/dom:focus-select-element element))
                   (nyxt/dom:focus-select-element (first elements))
                   nil))
           :constructor
           (lambda (source)
             (declare (ignore source))
             (nyxt/mode/hint::add-hints
              :selector "a, button, input, textarea, details, select")))
          :after-destructor (lambda () (with-current-buffer (current-buffer)
                                         (nyxt/mode/hint::remove-hints)))))

---

As mentioned, hint-mode will be fully reviewed and I do agree that are ways to improve it. But that piece of work needs to be very well thought out. In the mean time, have fun experimenting with custom hint commands.

[lrustand]

Thanks, that's great! This solves one part of my initial request. The narrowing of hint labels when typing parts of the hint works well, but I'm still having problems getting link text matching to work, it only matches against the hint labels.

One slightly strange thing with this hint command is that the current selection is always somewhere off screen and I have to press down arrow 3-5 times before the selection is a hint that is actually on the screen. After some more testing I realize that this happens in the default hinting mode as well.

there's a link called "Discography". But invoking custom-follow-hint and typing "di" will open the link whose hint overlay matches that string.

Yes, that is true and I forgot about this problem. This could be solved in a few different ways:

• Using numbers as hint labels
• Require the user to choose if there is more than one matching hint
• Match upper case against hint labels and lower case against link text (or vice versa)

The first one should already be possible through user configuration, and the second one seems like a sane default. Number 3 is more experimental I think, but seems like it could work pretty smooth. The other browser where I've seen this behaviour used option 1.

Also, all types of hinting has some drawback. For me personally this would be a big improvement even though it has this small "drawback". These sort of things depend very much on personal preference though, so this is why it makes sense to have these things as configuration options.

I see that similar hinting style has been suggested in #2972, and that you did not think it was a good idea to use numbers. You highlighted a problem when the link contains numbers. I have however used this exact hinting style for several years previously and never ran into this problem in practice. And it could be very easily circumvented by just typing a different part of the link text that does not contain numbers, or falling back to using the hint label in these specific edge cases. Also, point two in the list above.

If a set of parameters is available for configuration, then we must ensure that all combinatorial combinations make sense

I don't agree with this at all, I think it is up to the user to make sure their configuration combination makes sense. Having a powerful set of config options always makes it possible to do stupid stuff, and I'm sure there are plenty of ways to combine some of the options that already exist in Nyxt in ways that don't make sense too.

You seem to dismiss a lot of very sensible user suggestions simply because it is not something you personally would like to use, instead of allowing it to be a configuration option that the users that do find it useful can enable. These things obviously have some demand since there has been several similar issues.

As mentioned, hint-mode will be fully reviewed and I do agree that are ways to improve it. But that piece of work needs to be very well thought out. In the mean time, have fun experimenting with custom hint commands.

Nice, I'm looking forward to see the outcome of this! I will try to experiment a bit with some custom hint commands, although I'm still a beginner lisper. Your code above will be a good starting point for me.

[aadcg]

Some pointers towards your goal:

I'm still having problems getting link text matching to work, it only matches against the hint labels.

Because hints-alphabet covers the whole Latin alphabet (by default) and the prompt exists when a match is found. You have mentioned ways around it, namely to set the alphabet to numeric characters.

One slightly strange thing with this hint command is that the current selection is always somewhere off screen

Tip: tweak prompter:actions-on-current-suggestion such that it highlights the hint and it calls nyxt/dom:focus-select-element.

---

You seem to dismiss a lot of very sensible user suggestions simply because it is not something you personally would like to use, instead of allowing it to be a configuration option that the users that do find it useful can enable. [...] Also, all types of hinting has some drawback.

I don't think I have mentioned any of my personal preferences when it comes to hint-mode. Instead, I've stressed the fact that the default behaviour plus the combinatorial explosion of easy-to-configure parameters should have no gotchas. Users are free to pursue they own version of hint-mode as to mimic the behavior of other tools, or to contribute it to Nyxt.

---

I will try to experiment a bit with some custom hint commands, although I'm still a beginner lisper. Your code above will be a good starting point for me.

That was precisely my goal. Happy hacking!

[aadcg]

We have had many users over the years claiming that it is unacceptable for hint-mode to have the prompt buffer hide a considerable part of the main buffer. I still hold that view since the first time I tried Nyxt.

But now that we have the command toggle-suggestions-display, we can have the best of both worlds by raising the prompt buffer when needed, instead of forcing it by default. All it would take would be a simple tweak in query-hints. Additionally, we could recover slot fit-to-prompt-p that was deprecated in commit 0594c45 as to set whether the prompt buffer should be up or down when hinting-type is set to :emacs.

Reviewing hint-mode implies re-analyzing:

• Add combined version of hinting modes #3241
• Improve semantics of hint-mode's user options  #2865
• conqeror-style hinting | making hinting more intuitive/comfortable #2972
• 0594c45