Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: repeat the last key combination pointing at something #4625

Open
CouscousPie opened this issue Feb 8, 2025 · 2 comments
Open

Comments

@CouscousPie
Copy link

The classic text editor Vim has a . register, which allows to repeat the last action. This could be a useful feature for Vimium C, as well.

For instance, imagine you are trying to side-scroll through a picture gallery, that has static arrow buttons, but doesn't allow to navigate with arrow keys. You have to press f and whatever combination of two keys is then displayed on the software buttons. As the position of those never changes and the number of links on the site stays the same, the combination necessary to push the button also stays the same. This feels clumsy and unnecessary. It would be nice to just repeat the last key combination with . to then easily browse through in such a case.

For consistency, it could be a good idea to instead of literally executing the last combination of keys again, saving the element which was last interacted with and triggering a second interaction from whatever identifies this element on the html-script. Maybe a web-developer can clarify this in a more professional language.

@philg-dev
Copy link
Contributor

I do like the idea of that - I've encountered the scenario with image galleries myself a bunch and there's obviously also more generic use cases similar to that.

I personally haven't had any use case where I would like to repeat the previous operation in Vim-style with . aside from triggering link hints multiple times, so my initial thought is that a specific Vimium command to repeat the last link trigger could be implemented as a first step. Maybe a more generic concept could be done at a later point, if people find more use cases for it.

However in terms of the LinkHints.activateMode which is by default triggered with f in Vimium, I don't think it would be a wise choice to somehow "repeat the last key combination" as you described. The reason is that the "link hints" are generated dynamically according to available links that are detected on the visible viewport. In other words: it's basically impossible to guarantee that the link hint for the next/previous buttons will stay the same, even if the site structurally has the buttons at the same position all the time.

e.g.: when an image gallery has images of varying resolution / render height it might either move other clickable elements out of or into the viewport when switching between images. Another reason would be if the user scrolls the viewport ever so slightly the situation could change immediately as well.

However your idea of "saving the element which was last interacted with" could make this much more reliable:

For SPAs:
This should be quite easy to implement on single page applications that don't trigger a full page reload. In that case Vimium could simply save a reference to the specific DOM element and trigger it's .click() function again.

For non-SPAs:
On pages that are not SPAs, i.e. where a full page load is triggered, that approach wouldn't work though, since the DOM will be built up from scratch on every navigation / pagination and thus the pointer to the DOM element would no longer be valid. Some pages set HTML id attributes on such next / previous buttons, some pages set CSS classes that are uniquely used on those buttons,... but overall it's going to be quite messy to reliably find the same button again after a page load.

I think some of these issues have also been discussed in other issues regarding Vimium's goPrevious and goNext commands, which by default are keybound to [[ and ]] respectively. I remember a discussion about some webcomic sites that were all build on the same framework, where it was almost impossible to identify the next/previous buttons in a clean and reliable way generically. That was #4090

Maybe somebody knows more about that kind of stuff and can come up with an easy and reliable approach though.

@krnl0138
Copy link

krnl0138 commented Feb 9, 2025

I've come here to point out this idea as well. I see it as a Vim's dot functionality, press and repeat

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants