Comments (9)
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.
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.
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.
@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.
The former can be achieved by invoking command
toggle-suggestions-display
, i.e. you can easily define a command that callsfollow-hint
followed bytoggle-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.
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.
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.
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.
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)
- Ope new URL from the command line HOT 4
- Crash when deleting the last buffer if setting vi-normal keybindings in document-mode. HOT 2
- Nyxt website should prominently link to Nyxt github HOT 1
- GitHub Sponsors? HOT 1
- Duplicate nyxt website should be consolidated to one canonical version through 301 redirects HOT 1
- Nyxt crashes when changing buffers repeatedly HOT 11
- Running from source: `Component "swank/exts" not found` HOT 3
- minor typo in `assets/nyxt.metainfo.xml` (commit 655588b) HOT 1
- Gemini not always rendering as expected HOT 3
- Blank Page upon startup HOT 3
- Screen flickering on wayland and nvidia drivers HOT 1
- Broken clipboard commands on WSL (using Guix) HOT 6
- Links to nx-router and nx-tailor in EXTENSIONS.org are broken. HOT 3
- Consistent Hang With `search-auto-complete t` HOT 7
- Unable to navigate to gmail.com HOT 4
- Unable to login to gemini sites that require a self cert HOT 1
- Invalid Git submodule HOT 2
- Render Dark/Transparent/Blurred Screen When Loading Instead of White Flash HOT 2
- Function imports in cl-gobject-introspection & fset are incompatible with SBCL 2.4.5 HOT 2
- Unhandled floating point interrupt when starting Nyxt on the most recent SBCL (2.4.5)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nyxt.