search

atlas-engineer / nyxt

Nyxt - the hacker's browser.
https://nyxt-browser.com/
9.87k stars 413 forks source link

Buffer IDs do not persist #2583

Open franburstall opened 2 years ago

franburstall commented 2 years ago

Describe the bug

Once more I do not know if this is a bug or a feature request.

I would like to persist a list of favoured buffers and had thought that I could simply save a list of buffer id's to disk.

However, I discover that the mapping from id's to buffers does not survive a restart. That is, the buffers in a restored session have different ids after a restart..

Should this be the case? I thought ids used to persist.

If not, is there a way to accomplish my goal?

Information

ASDF version: 3.3.1 ASDF registries: (NYXT-SOURCE-REGISTRY ENVIRONMENT-SOURCE-REGISTRY USER-SOURCE-REGISTRY USER-SOURCE-REGISTRY-DIRECTORY DEFAULT-USER-SOURCE-REGISTRY SYSTEM-SOURCE-REGISTRY SYSTEM-SOURCE-REGISTRY-DIRECTORY DEFAULT-SYSTEM-SOURCE-REGISTRY) Critical dependencies: (/home/fran/common-lisp/nyxt/_build/cl-cffi-gtk/gtk/cl-cffi-gtk.asd /home/fran/common-lisp/nyxt/_build/cl-gobject-introspection/cl-gobject-introspection.asd /home/fran/common-lisp/nyxt/_build/cl-webkit/webkit2/cl-webkit2.asd)

aartaka commented 2 years ago

Does store-history-by-name work for your use-case?

franburstall commented 2 years ago

No. I want to persist a subset of the buffers: really I want to persist an ordered list of up to 9 buffers. See #1695 for the context: I want to save the "tagged" state of some buffers.

I thought I could just save a vector of buffer-ids but those ids point to different buffers after a restart.

Ambrevar commented 2 years ago

Indeed the buffer IDs have only one guarantee: to be unique. They are random on each start, including when restoring a session. This is by design.

Do you want to save a session or a subset of the global history tree? I guess that latter would be more general.

We could tweak store-history-by-name to prune unselected buffers. That's quite easy.

Does the buffer ID really matter though? Why do you want to keep the buffers ordered? If it's tagging that you want, then we need to introduce buffer names, IDs are not the right concept here.

franburstall commented 2 years ago

Does the buffer ID really matter though? Why do you want to keep the buffers ordered? If it's tagging that you want, then we need to introduce buffer names, IDs are not the right concept here.

I just want to tag a subset of buffers with some numbers in the range 1 through 9 so I can quickly switch to them via keys C-3 etc and persist these choices. Everything else is an implementation detail: my current implementation is simply a vector of buffers and C-3 switches to the buffer in the third entry of the vector. This does not serialise and I was hoping that buffer ids would be a simple alternative. I now understand that they aren't and wonder if there is any existing alternative for my use-case.

jmercouris commented 2 years ago

You could write a function that checks for a buffer, and if it doesn't exist, opens a new buffer with said URL.

Pseudocode:

look for buffer with URL if found, switch to buffer if not found open new buffer with URL

then you could map that to C-1 -> C-9. Unless it matters that it be restored buffers with some state from previous executions.

franburstall commented 2 years ago

Unless it matters that it be restored buffers with some state from previous executions.

Well, state like buffer history would be nice!

I am surprised that the (somewhat opaque to me) history mechanism in nyxt does not supply a simple way to persist a reference to a buffer!

aartaka commented 2 years ago

Well, Nyxt history library is designed in such a way that it both does not need to and does not know of buffers. But I'm pretty sure we can still sort and store it in a buffer-aware fashion. Just need to experiment with the code (no promises, I'm buzy with lots of stuff atm xD)

EDIT: lits -> lots

Ambrevar commented 2 years ago

@franburstall I believe the best way to achieve what you want is to introduce buffer names. This way you can uniquely identify buffers, and from there do what you want.

Introducing buffer names is a simple as adding a new name slot to the buffer class. Pull request welcome :)

aartaka commented 2 years ago

@franburstall I believe the best way to achieve what you want is to introduce buffer names. This way you can uniquely identify buffers, and from there do what you want.

Introducing buffer names is a simple as adding a new name slot to the buffer class. Pull request welcome :)

@Ambrevar, tagged buffers are a different, and as appealing of a use-case! See #1695 (also by @franburstall), for example (it's 3.0-labelled, but the way!)

Ambrevar commented 2 years ago

I know, I know, here I'm just suggesting to introduce a name slot, not a tag slot.

For instance, buffer with ID 345 would have name "web-buffer2" by default, and the name could be settable by the user at run-time. The name is guaranteed to be unique, like in Emacs.

When restoring the session, the name would be restored, but the ID would be different as is currently the case.

Tags are different because they are a list of strings, and each tag can be shared by multiple buffers.

franburstall commented 2 years ago

When restoring the session, the name would be restored, but the ID would be different as is currently the case.

I am having some difficulty getting my mind around persisting any new slot of the buffer class, be it a name or a list of tags. I am assuming that I should use the history mechanism for this. IIUC, the entity in a history-tree data structure corresponding to a buffer is an owner but the place for storing data is an entry inside a node belonging to the owner (perhaps the current-node of the owner?). But that will not work for this use-case because the same node can have many owners!

It is entirely likely I have misunderstood many things here but the following implementation-independent question remains: how to persist (that is save and later restore) data that belong to a buffer rather than one of the web-pages recorded by whatever history mechanism?

Ambrevar commented 2 years ago

Oh right, I forgot that we only store the IDs and we haven't fixed #2064 yet. So with #2064 in mind, we would store more:

aartaka commented 2 years ago

Wait, why store modes? #2490 should fix #2064.

Ambrevar commented 2 years ago

@aartaka In the end it seems that your last comment was wrong: #2490 does not fix #2064. Correct?

So we still need to store modes.

I thought a bit more about this: still unclear we need buffer names and how we would use it. However tags seem in higher demand (see also #1695), so maybe we can focus on tags for now.

To fix it all in one go, here is what I suggest:

At this point, #2064 and this issue should be fixed.

1695 would still not be completely fixed as we need to derive and API for buffer tags. Maybe some simple commands like buffer-set-tags would do for now.

aartaka commented 2 years ago

Sounds like a plan!

Ambrevar commented 2 years ago

And... this obviously does not work, because tags and modes are buffer-specific, not URL-specific. So we must store it either:

Thoughts?

Ambrevar commented 2 years ago

The problem is that while the buffer ID is constant for a given owner, the modes and the tags may change, and we don't have an htree API point to update them. Trickier than I thought...

Ambrevar commented 2 years ago

See #2627 for an untested design draft.