Confusion about buffer ordering | buffer tagging and naming #1695
Comments
|
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.
|
I have just done |
|
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?
|
|
In the end, I believe In terms of UX, tabs are poor since they don't scale, so it's only natural that The |
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... |
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 |
|
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.
|
|
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.
|
|
Sorry, just realized that you wrote the same thing with `C-1`, I had
missed that in the original post! :p
|
That would be a fabulous UI and completely solve my use-case.
Another good idea.
That is an action on a buffer-source: just mark the buffers to cluster. |
"1" to "0" could be viewed as tags too, but be assigned to user-defined tagging commands (could be tags "1" to "0" with 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 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 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 |
|
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?
|
|
How would 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. |
And then we could store the clusters in the Hmm, seems to be overlapping a lot with tags. Maybe clusters are just tags in the end. |
|
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 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
Then there is no way to
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 |
|
Thinking a little bit more about it, I doubt anyone would want to go through all those steps to set extra tags like Finding a way to combine those tags without extra steps for Still dependent on using |
|
@Kabouik I like your analysis, I agree with all your points. |
Ambrevar
added
good-first-issue
|
I just had a look at Firefox' "tab containers". It seems to me that they offer the following features:
And... that's it? Seems to be quite different from what we are trying to achieve here. For the rest of this discussion, I propose to drop the term "cluster" and use "group" instead, it's more accessible. So what are the use cases and features we would like from tags / groups?
All in all, it seems that all command that leverage All that's left to do is defining and setting the groups.
Thoughts? EDIT: Clarified what |
|
On Use-case: have This feels orthogonal to the groups idea and perhaps a bit like emacs registers: they should be quick to set and quick to jump to where quick means "very low number of keystrokes". If one carries on the register analogy, only one buffer could be pointed to by a register at any time and that buffer could be changed at any time by simply overwriting. The whole UI would be If you add the possibility to persist the registers then you have a lightweight version of "pinning tabs" from chromium. |
|
For pinning buffers, see #1608. I don't know if we can conflate tags and pinned buffers. Thoughts?
I don't understand what you mean, can you rephrase? I think my proposal allows you to achieve what you want. Does that make sense? |
OK: pinned means different things to different people. I don't mean pinned in the sense of #1608 but pinned as chromium does it: pinned tabs are placed at the head of the buffer-list in fixed order and so the first eight can be jumped to with
This was a reaction to yr proposal
This seems to suggest that
This is exactly what I want! Thank you for taking these concerns seriously! |
|
I am not familiar with tab containers in Firefox, but another extension that might be worth checking is Tree Style Tabs, which allows arranging tabs as trees (automatically or manually).
Yes to all, but the beyond-group commands should still be available of course. Maybe there could be a prefix keybinding to restrict all Same with
I guess per-window groups wouldn't hurt but that's a comment from someone who doesn't use multiple windows. If (3) "tags persist and are restored when Nyxt restarts" is confirmed, then maybe a (5) As said above, I would rather imagine a prefix to restrict commands to a group or not, but perhaps the added value wouldn't be worth it. (6) If no tag (7) Good idea yup.
Hum, so In my opinion, If I am not wrong, this allows @franburstall to do what he wants as long as he makes sure he doesn't give the same digit tag to several buffers (but if he does, he can easily edit the matching buffers and remove some with |
Not quite. It makes changing a buffer's numeric tag way more tedious. As I have said before, my use-case is orthogonal to the general story of groups or tags and is more like emacs registers. However, one can superimpose what I want on the tags infrastructure if there would be a |
|
True, changing a buffer tag would indeed require an extra step with what I wrote above:
1. `C-s-1`: buffer `1`
2. `C-s-2`: buffer `1` `2`
3. `C-s-1`: buffer `2`
Step 3 would not be necessary if `C-s-2` removed all pre-existing tags from the current buffer. However, it would allow having several buffers with `2` (or any other tag with the same command structure, even words) and `C-2`'s behaviour (do nothing, switch, show matching buffers in prompt or tiles) could depend on the number of matching buffers (0, 1, or more, respectively).
But I agree that there should be a `remove-tag-buffer` (remove only `tag` if suffixed with "tag", remove everything if suffixed with "*"), or an extra `clear-tags-buffer` to remove everything if this suffix system is not trivial to implement for `remove-tag-buffer`. From there, it would be straightforward to make a macro on a keybinding that first does `remove-tag-buffer "*"` on current buffer (or all buffers if configured that way) and then does `tag-buffer "1"` on current buffer, and this macro could even be provided with vanilla Nyxt, yet made with the same bricks as the tag system.
…On 2021-08-02 18:52 Fran Burstall ***@***.***> wrote:
> If I am not wrong, this allows @franburstall to do what he wants as
> long as he makes sure he doesn't give the same digit tag to several
> buffers (but if he does, he can easily edit the matching buffers and
> remove some with `C-s-1` on other buffers to toggle `1` off or with
> the opposite of `tag-buffer`), while avoiding making different
> commands for this use case and tagging use cases.
Not quite. It makes *changing* a buffer's numeric tag way more
tedious. As I have said before, my use-case is orthogonal to the
general story of groups or tags and is more like emacs registers.
However, one can superimpose what I want on the tags infrastructure
if there would be a `remove-tags` command that removed a given tag
from all buffers. Given that, I could then roll my own.
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1695 (comment)
196
|
|
@pdelfino @aartaka @jmercouris Any opinion on this? |
|
I tend to agree with the WM metaphor of @Kabouik here -- tags that can be freely assigned to any number of buffers, with buffers having 0 to many tags feel usful. If the tag-switching command refers to a tag assigned to only one buffer, then simply switch, otherwise prompt. Tag-removing commands can simply have What I didn't see here is the idea of arbitrary key tags. It'd be nice to have
Restoration of tagged buffers at startup feels similar to pinning. More so: it feels like superset of pinning -- you don't have one pinned group of buffers, you have several of those, restorable at startup! Sounds like an implicit API one can exploit for productivity :D |
|
I need more time to think about this. I'm not yet certain. |
|
Maybe it's a bit late to get this in 3.0. Unless someone has time to send a PR soon enough of course... |
aartaka
changed the title
|
I stumbled upon the River window manager today, which does use a tag system, and I think the way it was implemented could be useful to the discussion here: https://github.com/riverwm/river/wiki/How-tags-work |
Dropping the 3.0 tag then? |
|
I would say so. While this is a very cool feature that Nyxt should have at some point, it requires careful design. |
|
No longer important, due to #3598. |
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-lastAnything that uses a
buffer-sourceoffers 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-lasthits a good proportion of the use-cases for this model.Next/previous model
-
switch-buffer-next-
switch-buffer-previous-
list-buffers-
show-buffers-panelThis is non-volatile but utterly unpredictable: it imposes a tree structure on the output of
buffer-listwhich comes from a call toalex:hash-table-valueswhich 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-2could 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>)
The text was updated successfully, but these errors were encountered: