Buffer tree!

[Ambrevar]

This addresses #854 as well as some points mentioned in #1573 and in #565.

This changes the logic of switch-buffer-previous and switch-buffer-next to finally fix the long-standing issue of "jumping-around buffer last-access".

Now to go to the last visited buffer, use the new switch-buffer-last.

switch-buffer-previous visits the previous siblings (siblings are sorted by ID), switch-buffer-next to the next.

Questions before we can merge: can we browse the whole tree (including children and parents) with just switch-buffer-previous and switch-buffer-next?
To do so with just 2 commands we'd need to keep track of the visited parents (this is OK, can store it as a buffer slot). Is this what we want?

Example:

• root
  • childA
    • subchildA1
    • subchildA2
  • childB
    • subchildB1
    • subchildB2

If we are on childA, successive calls to switch-buffer-next should visit, in order:

• subchildA1
• subchildA2
• childB
• subchildB1
• subchildB2
• root
• childA

and we loop.

Does that make the most sense?

[jmercouris]

Looks great. I would like to make some tweaks to the appearance of this and list-buffers. When the tree depth gets too great, it can become visually hard to read.

[jmercouris]

I'll push some stylistic changes to this branch and then merge.

[Ambrevar]

Don't merge yet, I'd like to tweak some other things. In particular, I'd like to merge the command into the original list-buffers command.

[jmercouris]

OK!

[Ambrevar]

When the tree depth gets too great, it can become visually hard to read.

What about making the roots collapsable?

[Ambrevar]

Also what's your take on my question in the original post about the tree traversal?
Shall we add more commands or just have 2 commands that traverse the whole tree in a depth-first fashion?

[jmercouris]

I believe few people have the sufficient mental model to keep in mind the tree structure. I think they will be very surprised by switch-buffer-next and switch-buffer-previous if we make it utilize the tree.

I suggest keeping this model as simple as possible and leaving it the way it is.

[jmercouris]

With regards to adding two more commands, I don't see the advantage it provides over simply utilizing switch-buffer.

[jmercouris]

Lastly, with regards to making roots collapsible; I will work on that CSS, it might be a little bit tricky though.

[Ambrevar]

I believe few people have the sufficient mental model to keep in mind the tree structure. I think they will be very surprised by switch-buffer-next and switch-buffer-previous if we make it utilize the tree.

I suggest keeping this model as simple as possible and leaving it the way it is.

I think there is a misunderstanding. I believe that the current implement is confusing, because switch-buffer-previous and switch-buffer-next does cycle through all buffers!

So what I'm suggesting instead is to flatten the tree in a reproducible way and have the commands rotate over the result. This way the commands will behave like C-tab and C-shift-tab in other browsers.

[Ambrevar]

To clarify: I'm precisely trying to abstract the tree away from the user.

[jmercouris]

I am trying to say this:

I believe a list sorted by last access is more intuitive than a flattened tree.

[jmercouris]

Now, why does our C-tab equivalent not work as in other browsers? I believe it does not work because we treat each keypress as an individual command and update the access time on EACH press for EACH buffer. In a traditional browser or GUI system, the last access for a program does not get updated until you release control and select your new program or tab.

[Ambrevar]

Now, why does our C-tab equivalent not work as in other browsers? I believe it does not work because we treat each keypress as an individual command and update the access time on EACH press for EACH buffer. In a traditional browser or GUI system, the last access for a program does not get updated until you release control and select your new program or tab.

I don't think that's correct: in other browsers, tabs are ordered, so C-tab can trivially cycle across all tabs. Last access is not used. This is essentially what I'm trying to do by flattening the tree.

[Ambrevar]

I believe a list sorted by last access is more intuitive than a flattened tree.

This is the implementation on master, and it does not work as you've indicated in your other answer. As soon as we switch to the next buffer, the last access time is updated, thus preventing the user from cycling through all buffers. This is not the right approach.

[jmercouris]

OK, so we wish to emulate a traditional browser and NOT a WM application switcher. Then your flattened tree approach is appropriate.

[jmercouris]

My confusion arises from the fact that you wanted C-tab and C-shift-tab to cycle in the past, which is the behavior one expects from a WM application switcher, and not a browser. Now I see that you would like to switch it to the behavior of a traditional browser. That is fine with me!

[Ambrevar]

I'm confused, it the same thing for me. Can you give a precise example of a "WM application switcher" use?

[jmercouris]

Pressing Cmd + Tab in macOS uses most recency to sort applications.

Pressing Control + Tab in Safari presents the list in a fixed order.

[jmercouris]

Please let me know when I can make changes to this branch. (The style/collapsing functionality).

[Ambrevar]

Can you give more details? I believe that what you mean is that `Cmd+Tab` shows a _list_ of applications sorted by recency. It does not switch to the application before the user has selectted and confirmed. Note that this is different from `switch-buffer-next` and `switch-buffer-previous` which go directly to the next buffer, without showing a menu. Thus ordering by frequency cannot work. Does that make sense?

[Ambrevar]

Please go ahead, I'm on init-file recovery right now.

[Ambrevar]

@aartaka Thoughts on this?

[aartaka]

Looks right! I haven't digged deep enough into the code, though.

[Ambrevar]

I've just pushed the full implementation of the buffer tree traversal.

So now if you've got a tree as in the original post, say you are on ChildA, pressing switch-buffer-next will always bring you to subchildA1, and switch-buffer-previous will always bring you to ChildA, regardless of the last access time.

This essentially emulates "fixed tab positions" from popular browsers.

Ready to merge for me, let me know what you think.

[jmercouris]

I suggest: Let's first merge the spinneret changes, then we convert this to spinneret, and then merge it.

[Ambrevar]

OK, I'm on it!

[Ambrevar]

Merged with b1e2443.