Giter Site home page Giter Site logo

Comments (9)

aadcg avatar aadcg commented on June 5, 2024

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.

from nyxt.

lansingthomas avatar lansingthomas commented on June 5, 2024

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."

from nyxt.

lrustand avatar lrustand commented on June 5, 2024

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.

from nyxt.

aadcg avatar aadcg commented on June 5, 2024

@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.

from nyxt.

lrustand avatar lrustand commented on June 5, 2024

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.

from nyxt.

aadcg avatar aadcg commented on June 5, 2024

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.

from nyxt.

lrustand avatar lrustand commented on June 5, 2024

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.

from nyxt.

aadcg avatar aadcg commented on June 5, 2024

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!

from nyxt.

aadcg avatar aadcg commented on June 5, 2024

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:

from nyxt.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.