Wishlist

[ghost]

I discovered Vieb yesterday and after a few configurations, I'm already using it as my default browser over Firefox. In that short time, I've found a list of things that would be HUGE improvements to vieb. Two points are more problems than ideas, I'm putting them so i don't have to make another issue. Here they are, in order of importance (for me):

• Fuzzy finding with :buffer: i think a large part of [n]vim users use plugins like Telescope or fzf instead of the default :buffer command. Additionally, with fzf-lua's "buffers" picker, buffers are sorted by recently used order. This is especially helpful when you're browsing multiple tabs and can't remember all of their names. I don't see a use case for having tabs sorted by their buffer number since you can use the alt+[1-9] shortcuts to browse them.

• Firefox's "Cycle through tabs in recently used order": This can be found in about:preferences → General → Tabs. It serves the same purporse as the previous suggestion except that adds a preview of the tab. This feature is not unique to firefox, GNOME and Windows have it for cycling through windows instead of tabs.

• Improve action.startFollowCurrentTab performance: It's slow on Youtube and unusable in online documentations. For example, press f in awk documentation.

This confuses me as intuitively, follow mode performance should not be affected by the page size but by the number of visible links on the screen.

• Improve "[next/previous]SearchMatch" performance: Search mode it's faster enough to find all results and show them in the scrollbar but not to cycle through them even on the same screen view. Try searching for the string "url" on the help page and then press "n". Using “a” would make it more noticeable but you don't normally search for single letters.

I'm not sure what the problem itself is, but if I can help, I've that sioyek has a “super_fast_search” option that indexes the whole PDF to make the search faster in exchange for consuming more memory. This same idea could be applied to do some prerendering if that's the problem.

• Fuzzy finding with the TOC: Here's a video from sioyek:

125321313-cf050180-e351-11eb-9275-c2759c684af5.mp4

• A option to create bindings that copy some part of the url: I was going to suggest an action to copy the url without parameters, which is really what i need, but this allows for better flexibility. Here's a rough idea of how it's useful:
  • Example url:
    https://sub.domain.com/path1/path2?param=abc#test
  • Some possible maps:
    • nmap ycd <url:host> will copy https://sub.domain.com
    • nmap ycp <url:host+path> will copy https://sub.domain.com/path1/path2
    • nmap ycP <url:host+path+parameters> will copy https://sub.domain.com/path1/path2?param=abc#test

I'm aware of the existence of gu, gs, gU and gS. This idea is mainly for copying a url to save it to a text file instead of using it to navigate.

[Jelmerro]

• Fuzzy finders are slow, for a few reasons. First, I do NOT want native binaries in there as that will break a lot of custom Vieb builds. This has resulted in me testing pretty much all major ones made in JavaScript, but all I have found so far have been between 4-100 times slower than the current custom implementation has been. The current one is not fuzzy which makes the checks much easier of course, but it's been the main reason it has not been replaced as of yet (same is true for not completing Highlight matched text in the navbar #223 actually). As for the index order, I think this would make a fine setting when combined with the lastusedtab feature as per below.
• I have not seen much use for such a feature personally, but it should theoretically not be that difficult, given that recent tabs are already stored for the lastusedtab feature. You can find help for it with :h lastusedtab or press B and check the mapsuggest commands.
• It's slow on big pages, because currently it is preferring accurate links over fast links. A middle ground would be ideal, but for example links that are half outside of the page or are inside containers not fully in screen have previously been invisible in follow mode and it was very annoying, hence the current implementation. I welcome any PRs on this that manage to speed up follow mode without compromising accuracy, but so far it has been one or the other.
• I have no clue what is wrong with searches, I am simply using the native Electron/Chromium APIs for it, yet it is much slower than in Chromium. I currently have no time to look into it in detail, but it is on my radar (as are most of these, but most things on your list take seriously long to do right sadly).
• These are easy enough, that's definitely a good first issue to work on, but I might add them after I'm done doing a fairly big refactor I am currently working on.