Confusion about buffer ordering | buffer tagging and naming

[franburstall]

Describe the bug
I am not sure if this is a bug or a feature request or just a rant but I am finding it very difficult to reason about buffer navigation.

We want to efficiently navigate between buffers by keyboard in the absence of visual clues (the long line of tabs we see at the top of chrome or firefox). This means that we (or at least I) need a mental model of buffers and the relations between them. The problem is that nyxt offers TWO models and only one of them is predictable.

Last access model
-switch-buffer
-switch-buffer-last
Anything that uses a buffer-source offers a list of buffers sorted by last-access. This is predictable and often what we want but, by its very nature, it is volatile.

The very wonderful switch-buffer-last hits a good proportion of the use-cases for this model.

Next/previous model
-switch-buffer-next
-switch-buffer-previous
-list-buffers
-show-buffers-panel
This is non-volatile but utterly unpredictable: it imposes a tree structure on the output of buffer-list which comes from a call to alex:hash-table-values which I guess has no idea about sort order. In particular, newly created buffers get slotted into the ordering at apparently random places. This is the case even when the tree structure is flat, so that is not the issue. Moreover, I know no way to change this ordering (in chrome/firefox, I would use a mouse to place tabs next to each other).

Why I care
I would very much like to be able to arrange three buffers in such a way that switch-buffer-next/prev moves between them (think three-way cut/paste tasks: there are times when the admin part of my life is dominated such things, sigh)

Suggestions
I guess what I am suggesting is that a rational but user-adjustable ordering underlie the next/previous model. Perhaps start with buffer creation order?

Extra marks for some kind of pinning: mark buffers to be permanently first/second/... in this ordering so that keys like C-1, C-2 could switch to those quickly.

Nyxt version: 2.1.1-413-g69dbf721
Renderer version: GI-GTK
Operating system kernel: Linux 4.19.0-17-amd64
Lisp implementation: SBCL 2.1.1 (Dynamic space size: 1073741824)
Features: (:SLYNK :WEBKIT2 :WEBKIT2-2.32 :WEBKIT2-PASTE-PLAINTEXT :WEBKIT2-TRACKING
:WEBKIT2-MUTE :WEBKIT2-EMOJI :WEBKIT2-MEDIA :WEBKIT2-SANDBOXING :GTK-3-22
:GTK-3-20 :GTK-3-18 :GTK-3-16 :GTK-3-14 :GTK-3-12 :GTK-3-10 :GTK-3-8 :GTK-3-6
:GTK-3-4 :GTK :GDK-3-22 :GDK-3-20 :GDK-3-18 :GDK-3-16 :GDK-3-14 :GDK-3-12
:GDK-3-10 :GDK-3-8 :GDK-3-6 :GDK-3-4 :CAIRO-1-10 :CAIRO-1-12 :GDK-PIXBUF
:GLIB-2-30 :GLIB-2-32 :GLIB-2-34 :GLIB-2-36 :GLIB-2-38 :GLIB-2-40 :GLIB-2-42
:GLIB-2-44 :GLIB-2-46 :GLIB-2-48 :GLIB-2-50 :GLIB-2-52 :GLIB-2-54 :GLIB-2-56
:GLIB-2-58 :GLIB :NYXT-2 :FSET-EXT-STRINGS :CUSTOM-HASH-TABLE-NATIVE :SWANK
:PLUMP-UTF-32 :GLOBAL-VARS :DECLARE-TYPES :PARENSCRIPT :NAMED-READTABLES
:21BIT-CHARS :CHUNGA :FLEXI-STREAMS :CLOSER-MOP :CL-PPCRE-UNICODE :CL-UNICODE
:CL-PPCRE :BORDEAUX-THREADS :SPLIT-SEQUENCE CHIPZ-SYSTEM:GRAY-STREAMS
:FAST-IO-SV :FAST-IO :SBCL-USES-SB-ROTATE-BYTE :ASDF-SYSTEM-CONNECTIONS
:CL-JSON-CLOS :CL-JSON :THREAD-SUPPORT CFFI-FEATURES:FLAT-NAMESPACE
CFFI-FEATURES:X86-64 CFFI-FEATURES:UNIX :CFFI CFFI-SYS::FLAT-NAMESPACE
ALEXANDRIA::SEQUENCE-EMPTYP :QUICKLISP :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3
:ASDF2 :ASDF :OS-UNIX :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :X86-64 :GENCGC
:64-BIT :ANSI-CL :COMMON-LISP :ELF :IEEE-FLOATING-POINT :LINUX :LITTLE-ENDIAN
:PACKAGE-LOCAL-NICKNAMES :SB-LDB :SB-PACKAGE-LOCKS :SB-THREAD :SB-UNICODE
:SBCL :UNIX)

ASDF version: 3.3.1
Critical dependencies: (/home/fran/common-lisp/nyxt/_build/submodules/cl-cffi-gtk/gtk/cl-cffi-gtk.asd
/home/fran/common-lisp/nyxt/_build/quicklisp-client/dists/quicklisp/software/cl-gobject-introspection-20210124-git/cl-gobject-introspection.asd
/home/fran/common-lisp/nyxt/_build/submodules/cl-webkit/webkit2/cl-webkit2.asd)

Quicklisp dist version: 2021-06-30
Quicklisp client version: 2020-01-04
Local project directories: (/home/fran/common-lisp/nyxt/_build/submodules/
/home/fran/common-lisp/nyxt/_build/quicklisp-client/local-projects/)
Critical dependencies(#<SYSTEM cl-cffi-gtk / cl-cffi-gtk-20201220-git / quicklisp 2021-06-30>
#<SYSTEM cl-gobject-introspection / cl-gobject-introspection-20210124-git / quicklisp 2021-06-30>
#<SYSTEM cl-webkit2 / cl-webkit-20210630-git / quicklisp 2021-06-30>)

[Ambrevar]

The tree is ordered by buffer ID, which maps creation order. Does that make more sense? We should document it more. What else would you suggest? About re-ordering, I'm not sure how to do it, but I guess we add a "buffer child position" slot to buffers that the user could modify. The list-buffers command is also very handy for navigating the tree.

[franburstall]

The tree is ordered by buffer ID, which maps creation order.

I have just done list-buffers and the buffer ids listed in display order are 11, 9, 5, 4, 3, 2, 6.

[Ambrevar]

It's a tree, if "6" was a child buffer at some point it's normal that it appears there. Can you send a precise recipe if you think there is a bug?

[Ambrevar]

In the end, I believe switch-buffer-next and switch-buffer-previous are only rarely useful. They are mostly here to allow cycling through all buffers in a reliable order to mimick the equivalent feature of tab-based browsers.

In terms of UX, tabs are poor since they don't scale, so it's only natural that switch-buffer-next doesn't scale either.

The list-buffers or fuzzy-searchable switch-buffer are much better approaches in my opinion.

[franburstall]

It's a tree, if "6" was a child buffer at some point it's normal that it appears there. Can you send a precise recipe if you think there is a bug.

I am not sure if "6" was ever a child buffer but it is not now (according to list-buffers in tree display). But I am not sure what provokes the parent-child relationship. For example: when I am in a web-buffer and fire a help-buffer---is the help-buffer a child? This is an instance where I see the buffer list not in :id order sometimes. I am afraid that this does not count as "reliable" for me.

If I have the time, I shall see if I can a reproducible recipe...

[franburstall]

In the end, I believe switch-buffer-next and switch-buffer-previous are only rarely useful. They are mostly here to allow cycling through all buffers in a reliable order to mimick the equivalent feature of tab-based browsers.

In terms of UX, tabs are poor since they don't scale, so it's only natural that switch-buffer-next doesn't scale either.

The list-buffers or fuzzy-searchable switch-buffer are much better approaches in my opinion.

I mostly agree, but for work, I frequently need to be able to switch between a small number of buffers with minimum key-strokes and here switch-buffer needs too many key-strokes and list-buffers sends us back to point-and-click.

[Ambrevar]

A child buffer is one when opened by clicking on a link of a web page to be opened in a new buffer. `follow-hint-new-buffer`, C-button1, etc. generate child buffers. We lack documentation here for sure.

[Ambrevar]

What about key-marking buffers? Press C-shift-1 to mark the current buffer to "1", then at any point you can press `C-1` to switch back to this buffer. Same with `C-2`, etc. Would that be a good UI? Another (non mutually exclusive) option would be to create buffer clusters and have `switch-buffer-next` and `switch-buffer-previous` stick to this cluster. A cluster could for instance be a branch of the tree. Or it could be buffers matching some tags. See also #1654 How do we interactively define a cluster? Could have 2 commands, `narrow-buffer-cluster` and `widen-buffer-cluster` to echo Emacs narrowing commands.

[Ambrevar]

Sorry, just realized that you wrote the same thing with `C-1`, I had missed that in the original post! :p

[franburstall]

What about key-marking buffers? Press C-shift-1 to mark the current buffer to "1", then at any point you can press C-1 to switch back to this buffer. Same with C-2, etc. Would that be a good UI?

That would be a fabulous UI and completely solve my use-case.

Another (non mutually exclusive) option would be to create buffer
clusters and have switch-buffer-next and switch-buffer-previous
stick to this cluster.

Another good idea.

How do we interactively define a cluster?

That is an action on a buffer-source: just mark the buffers to cluster.

[Kabouik]

What about key-marking buffers? Press C-shift-1 to mark the current buffer to "1", then at any point you can press C-1 to switch back to this buffer. Same with C-2, etc. Would that be a good UI?

"1" to "0" could be viewed as tags too, but be assigned to user-defined tagging commands (could be tags "1" to "0" with C-s-1 to C-s-0, but users could prefer categories like "work", "hobby", "reading", "dev", etc., pretty much like workspaces in a tiling WM). This would combine the "quick-tag from keybindings" feature, configurable domain tagging rules, while retaining the ability to set one-time tags on the go from the prompt when in need for a tag that was not predefined in config.

I also like the idea of commands to cycle through buffers within a cluster (or tag). That is what I had in mind with tags when the prompt is open (this allows combining multiple tags and cycling through the filtered matches), but for sure it would be good to also be able to define keys for switching tabs within the current-cluster when the prompt is not visible.

I don't see a trivial way to do assign a single cluster to a combination of tags at once unless there is a clear cluster-buffers command to invoke the prompt, filter buffers (or not) with the text input, and multi-select buffers that should be clustered together. But not sure if this would be necessary.

For single-tag clusters, it would not be necessary since buffers that share the same tag could automatically be clustered together (and buffers with multiple tags would be found in multiple clusters); this way switch-buffer-next-within-cluster and switch-buffer-previous-within-cluster could cycle within the current cluster without first needing to manually set clusters if buffers have been tagged. Or tags could also be mutually exclusive if things need to be kept simple; assigning one tag to an already tagged buffer would overwrite the previous tag, though that's more limiting.

[Ambrevar]

Should we view "0".."9" as tags though? Considering they've got to be unique, and that they may be defined per-window, I'm tempting to think that no, it "marks" should be different from tags. If we forget about per-window marks for now, then it's doable to implement conflate the idea of marks and tags: when pressing `C-1`, Nyxt would simply prompt the list of all buffers tagged with "1". If there is just one, switch to it directly. Thoughts?

[Ambrevar]

How would switch-buffer-next-within-cluster work if we allow multiple tags per buffer? Would it AND the tags?

The benefit of tags is that they compose. If we restrict ourselves to a single tag per buffer, then they are not really tags anymore but groups.

[Ambrevar]

That is an action on a buffer-source: just mark the buffers to cluster.

And then we could store the clusters in the window, a bit like marks?

Hmm, seems to be overlapping a lot with tags. Maybe clusters are just tags in the end.

[Kabouik]

It would be great to find the most parcimonious system, with as few commands/concepts as possible for as many situations as possible to reduce the overlap.

The way I was seeing it, "0" to "9" are tags and it is up to the user to use them only once (for quick buffer switching with C-0 to C-9) or to group multiple clusters under the same digit, in which case the prompt lists the corresponding switch-buffer-suffix (suffixes being "0" to "9") and wait for user selection within those as you suggested, instead of directly switching. When buffer tiling (= window splitting) is a thing, then all matching buffers could be shown and tiled at once directly, optionally (perhaps with a keybinding variation to trigger tiling instead of showing the matching list in the prompt).

This is pretty much the behaviour of all tiling WMs I have used: you get 10 workspaces, to which you assign windows automatically with WM_CLASS rules or manually with keybindings and window manipulation. Then when you switch among workspaces, if only one window was assigned to the workspace, you see it maximized, else you see all windows therein (which in Nyxt could be both tiling buffers when the feature is implemented, or listing them in the prompt as you said above).

For switch-buffer-next-within-cluster, I am struggling too when thinking whether clusters should be synonyms of tags or would bring something useful if both concepts are orthogonal. If we go with a tag concept only, and set tags this way:

• Buffer 1 dev perso
• Buffer 2 dev work
• Buffer 3 work reading
• Buffer 4 kittens hobby

Then there is no way to switch-buffer-next-within-cluster among tags that are dev OR work, because switch-buffer-next-within-cluster could only cycle within unique tags. But since buffers can be assigned multiple tags, one could also invoke switch-buffer, input "dev OR work" (in a lispy way) to filter, and assign a new group1 tag to all results:

• Buffer 1 dev perso group1
• Buffer 2 dev work group1
• Buffer 3 work reading group1
• Buffer 4 kittens hobby

Then, if Nyxt can tell which tag has been used as a filter to switch to a new buffer in the first place (could it?), then the browser could use that initial tag to define the boundaries of switch-buffer-next-within-cluster. I don't know if that is clear, and maybe I didn't think it through.