Action for selecting a scrollable element in pointer mode

[gardenappl]

Checklist

• I searched the :help documentation using / for helpful information
• I have read the frequently asked questions
• I did not find any similar issues in the issue tracker
• I prefer making an issue instead of using discussions, Matrix or Telegram

Addition or change
AFAIK the only way to scroll some nested element in a web page is to use pointer mode. It would be nice to have an action to search elements with scroll bars, rather than have to navigate to them manually.

Alternatives considered
Maybe the same shortcut could also be used in Normal mode, to focus a scrollable element, and then any following normal action.scroll* events could apply to the one focused element?

[Jelmerro]

This seems like a useful addition, but do know that the pointer actions can also be used without being in pointer mode if you map them, though you will not see the pointer and there is no current way to switch the position outside of pointer mode. I am considering to make separate scroll related actions that focus a specific area, briefly highlight it, and then remember that section to be scrolled with separate scroll actions. The issue there is that I do not know which keys are useful for doing so and how one would select an area outside of follow mode. Please let me know your thoughts and ideas related to this.

[Abdillah]

@Jelmerro Currently follow mode is affected by followelement variable, if for example I want to create a keymap to select input element only, I must do this.

# Follow input only
nmap Fi <:set followelement="inputs-insert,inputs-click"><startFollowCurrentTab>

# Follow all (normal): but may need to restore the `followelement` value
nmap f <:set followelement="url,onclick,inputs-insert,inputs-click"><startFollowCurrentTab>

If follow mode has more flexible "filter" that can be defined in a keymap, I think selecting scrollable element can be made as a filter. When it is selected, it just naturally focus on the element (hopefully without onclick) and consecutive scroll action will affect it.

The last part is to restore the scrollable element to the body, maybe using special action or "body filter" that only select one element.

[Jelmerro]

As you demonstrate, filtering the links can already be done with keymaps, so there seems to be no need to make it "more flexible". But each type of follow mode has a specific action attached to it, for example there is the regular follow mode for clicking elements, but also follow modes specifically for opening links in a new tab, copying a link or opening links in splits. I think for selecting the scroll area a new type of follow action would be added that just lists the scrollable elements. And yes, there would indeed be a need for a mapping to reset the scroll element, which would also happen on reload.

I'm also not sure how often we would need this if we were to add the option to scroll the largest scroll section in case the body is not scrollable, which is another idea I have been considering to implement for a while. This would mean that crappy sites like new reddit would no longer have the scroll issue for example, as they have a very large main scroll section, while the body is not scrollabe.

[Abdillah]

I'm also not sure how often we would need this if we were to add the option to scroll the largest scroll section

I would use this feature everyday: JIRA. Basically some mid to heavy application with sidebar should need this.

• JIRA (up to three scroll elements)
• Outline
• Dev doc with sidebar (RTD, devdocs.io, etc)

[Abdillah]

When searching on how to scroll on an element in Vieb, I imagine the keyword "focus" on element. I think the follow action variants can be greatly reduced by thinking as common browser experience: click link (with split/vsplit/newtab/newwindow argument), focus (scroll the nearest parent with scrollbar or itself), and pointer-focus (for context menu and hover and other action that has been available).

I don't have the overview of the design, pardon if I stepped on your toe.

[Jelmerro]

That's fair, I think we do need a new way to approach follow mode, just not sure if this is the right moment to do it. I would like the current flow to keep working, especially for just clicking links, but other follow mode subtypes might get a restructure in the future to make this one of the possible options. Another option would be to just make one more follow mode and make it do this and delay the restructuring for now.

Don't worry, I don't mind new ideas, in either case I'll honestly let you know if I think that it fits in Vieb, but this is a good call and I have been considering this for a while. Selecting elements for scrolling there will happen in the future anyway, just wondering what the right way to show the current focus area would be.

[KunaPrime]

This is also feature that i want/need every day. There are lot of documentation pages with navigation sidebars that are difficult to navigate because one needs to scroll sidebar first. But in general as @Abdillah mentioned, there is opportunity to clean up a bit follow mode. Specifically large text inputs also need to be scrolled most of the time (like this one i writing in right now), but also when i really want to follow something, 99,99% of time i really don't need input boxes to be visible in follow selection making clutter but this are contradicting statements. How to decide?

I propose splitting follow into select/focus and follow. Looking at code this is mostly already done internally function getAllFollowLinks is select just as far i know is not exposed to user. So there could be generally useful command :startSelect that would take list of groups to select (exacty the same format and options as currently followelemet with maybe addition of scrollable). Then user would either select one (by typing letters) or select multiple (shift + typing letters) , just like follow now, which would ultimately return list of (one or more) selected elements. This list could then be piped to actions/commands.

In this model current follow would be implemented indirectly as composition of select command and other commands:

(equivalents to current situation)

:command startFollowCurrentTab <:startSelect url,onclick,inputs-insert,inputs-click,media,image,other><:open> // alternatively <p.leftClick> instead of <:open>
:command startFollowNewTab <:startSelect url><:tabnew>
...and so on

also to select insert field

:command selecInsert <:startSelect inputs-insert><focus><toInsertMode>

finally to scroll

:command selectScroll <:startSelect scrollable><focus> // and then just scroll as usual 

benefit of this is natural mapping of these to any keys as usual and also all the behavior can be backward compatible. And this would also play nicely with proposed CLI improvements (one could issue select command to instance and wait until user selects elements in UI and then do some processing/whatever)

Sure some unusual things could happen when multiple elements are focused, for example selecting multiple inputs with :selectInput but maybe it is equivalent to multicursor modes provided by some plugins to neovim.

I also believe this would not break any existing mappings/remapping and/or custom commands