Try translating "next"/"previous" links to history commands

[fakedrake]

Going forward and back in the pages of a search result creates a huge trail of history which is repetitive. For example consider the case:

• we are on example.com
• we do a google search
• hit: ]] x3, then [[ x2 then ]] x7 then [[ x8

We are now on page 1 but we are 19 history items away from example.com. It would be reasonable (and at times faster) ]] and to navigate history instead of click the links.

[SammysHP]

I absolutely understand the intention of this change and I like the history simplification. On the other hand the user might want to get the latest version of the page (e.g. list of forum threads, another thread was created in the meantime and going back would load a cached page).

[maxauthority]

I am also indifferent about the change. I see both advantages and disadvantages but actually what we really need ist something like Opera's fast forward/backward where you can go back to example.com with a single shortcut. So I'd rather say we should keep [[ and ]] the way they work now, but add [d and ]d commands (or may with different names) to go the the last page in the history of the current domain, and if there, to the previous domain.

[fakedrake]

I think the functionality you describe is orthogonal to this feature. An ideal solution for me (I am willing to do it) would be to break followDocumentRelationship into getDocumentRelationship and followDocumentRelationship (which just calls the former), so the user can build on top of that. How about that?

[maxauthority]

With "the user can build on top of that" you mean, users should write their own JavaScript? Sorry, but no sorry, I don't think that's a good solution ;)

Basically, your PR is about making the history easier (which I agree), but doing that for [[ and ]] alone does not really make sense to me, as many other commands would also benefit from a better history navigation (e.g. (quick-)marks, hints, macros, etc.) and most importantly just navigating with the mouse.

[fakedrake]

Well yes that's what I mean but I think a more complete interpretation would be "write their own javascript without having to copy-paste the entire followDocumentRelation function" (which is what I did). I think this change in design would improve extendability.

But to see if I understand your point correctly: you are suggesting that we should instead change the semantics of buffer.followLink (eg with an optional argument) to move across history? That's not a bad idea but isn't it a bit too pervasive?

I would argue that ]]/[[ is "semantically" closer to history navigation than the other examples you provide but I agree with your broader point.

[maxauthority]

No, my suggestion is to keep [[/]] (and buffer.followLink) the way it is, but add something like history.goto{Previous,Next}Domain() methods and bind them to some keys (probably [d and ]d) to quickly navigate the history.

…

On Mon, May 22, 2017 at 6:04 PM, Chris Perivolaropoulos < ***@***.***> wrote: Well yes that's what I mean but I think a more complete interpretation would be "write their own javascript without having to copy-paste the entire followDocumentRelation function" (which is what I did). I think this change in design would improve extendability. But to see if I understand your point correctly: you are suggesting that we should instead change the semantics of buffer.followLink (eg with an optional argument) to move across history? That's not a bad idea but isn't it a bit too pervasive? I would argue that ]]/[[ is "semantically" closer to history navigation than the other examples you provide but I agree with your broader point. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#758 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFtBrxmz-_6BIune8GFFuef22uEKPWY8ks5r8bIogaJpZM4NeIZd> .