Why is treemacs using a nondeterministic buffer name?

[minad]

I am experimenting with a bookmark-based approach which stores the current view (open buffers and windows). Treemacs already seems to integrate nicely with bookmarks and sets its own bookmark-make-record-function. However the window state restoration cannot restore the treemacs window since the buffer name is non-deterministic. So I wonder about the reason for that?

My bookmark-view code lives in https://github.com/minad/bookmark-view/blob/master/bookmark-view.el in case you are interested. Basically it restores the buffers using bookmark-jump and restores the window layout afterwards with window-state-put. It is a very simple thing without any special casing.

[Alexander-Miller]

Treemacs buffers have a scope in which they live. By default the only scope available the current frame - every frame you create will have its own unique treemacs buffer that can display any one of your workspaces. Packages like treemacs-persp can add an additional scope type based on the current perspective.

Since multiple treemacs buffers can exist at the same time their names must be made unique, and the easiest way to achieve that is to include their scopes' names, that is why you get buffers with names like *Treemacs-Scoped-Buffer-#<frame emacs@am-laptop 0x558b33ab64e0>*.

Basically it restores the buffers using bookmark-jump and restores the window layout afterwards with window-state-put

Is that supposed to survive an Emacs restart? That's not going to work then, there's a bunch of backing data structures that treemacs needs that have no way of being saved or reused as of now - just look at the value of treemacs-dom in a treemacs buffer for the most obvious example.

[minad]

Since multiple treemacs buffers can exist at the same time their names must be made unique, and the easiest way to achieve that is to include their scopes' names, that is why you get buffers with names like Treemacs-Scoped-Buffer-#<frame emacs@am-laptop 0x558b33ab64e0>.

Ok, I don't really understand what scope means here, but mainly the hex-id is a problem in my case. Is this the object id of the frame? Would it be possible to use something deterministic instead or offer an option to disable that? If that's not possible I could try if I can somehow remove the id by putting an advice at the right place. I am usually only having a single frame.

Is that supposed to survive an Emacs restart? That's not going to work then, there's a bunch of backing data structures that treemacs needs that have no way of being saved or reused as of now - just look at the value of treemacs-dom in a treemacs buffer for the most obvious example.

Yes it is supposed to. Why should that not work? I am using bookmark-make-record to generate the record, such that if a buffer installs its own bookmark record function, the record will be created by that buffer-specific function and the correct handler will be used for restoration.

I should add - this obviously only works if buffers play by the rules, meaning they are either backed by a file or have their own handler. Treemacs seems to belong to the well-behaving category (modulo the restore bug and modulo this non-determinism, but the non-determinism has nothing to do with the bookmark mechanism, only with restoring the windows to the right place after loading the bookmarks.)

[minad]

After looking at the scope code, maybe I should define my own scope class in order to overwrite this behavior. I will try this.

Edit: Or maybe I just hack this as follows...

(cl-defmethod treemacs-scope->current-scope-name ((_ (subclass treemacs-frame-scope)) frame) "foo")

Edit 2: With the hack my restoration function seems to work even after restarting Emacs. I would still be interested to hear your opinion about this. Maybe there is a better solution.

[Alexander-Miller]

Ok, I don't really understand what scope means here,

There's the scope types, e.g. frames in general, and an actual scope a treemacs buffer is visible in - an actual instance of an Emacs frame.

Is this the object id of the frame?

It's the print representation of a frame, I don't know how that string is derived. You can see a frame's id by calling (selected-frame) or passing a frame to format "%s".

Yes it is supposed to. Why should that not work?

Treemacs' bookmark handling wasn't implemented by me, but was a PR. I don't really use bookmarks myself either, so I'm not all that familiar with these things work.

With the hack my restoration function seems to work even after restarting Emacs. I would still be interested to hear your opinion about this. Maybe there is a better solution.

It'll work, but I'd prefer you didn't need such hacks to work with treemacs. I just don't think treemacs' scoping and the general restore mechanism you've implemented can really work together (it's pretty much the same story why treemacs doesn't support desktop-save-mode). We probably need to pick the lesser evil out of

• Using a "global" scope so it's clear which treemacs buffer should be restored
• Try and come up with static names, e.g. with treemacs trying to use something like a `frame-name´ frame parameter
• special casing or excluding treemacs on your end

[minad]

Treemacs' bookmark handling wasn't implemented by me, but was a PR. I don't really use bookmarks myself either, so I'm not all that familiar with these things work.

Me too, but I am probably going to change that. It seems bookmarks are quite powerful. And if you look at bookmark-view, it is ridiculously simple to get persistent views/perspectives. I am sure it is not as powerful as perspective etc but I always like it when things can be done purely using the basic emacs functionality.

It'll work, but I'd prefer you didn't need such hacks to work with treemacs.

Me too. An alternative would be to implement my own class, which somehow makes the hack less evil.

I just don't think treemacs' scoping and the general restore mechanism you've implemented can really work together (it's pretty much the same story why treemacs doesn't support desktop-save-mode).

I don't understand why you keep saying that. If bookmarks work with treemacs, there is nothing in the way of supporting the bookmark-based restore mechanism. The underlying datastructures and everything are restored by the treemacs bookmark handler. The only thing is the window state, which relies on associating buffers with windows by name. And since treemacs changes the name when restarting emacs, this does not work. If I manage to make that deterministic, I am fine. I mean it works, I tested it with the foo-hack. Treemacs restores everything nicely (except if selecting a tag due to #745).

special casing or excluding treemacs on your end

I already have that functionality, but this would be like kind of giving up. Supporting treemacs is also a nice test to see if things work with buffer bookmark handlers...

Using a "global" scope so it's clear which treemacs buffer should be restored

It is not clear to me what you mean by that.

Try and come up with static names, e.g. with treemacs trying to use something like a `frame-name´ frame parameter

Yes, that would be nice. I never liked seing this treemacs frame id in buffer lists, even if it is an implementation detail and mostly hidden.

[Alexander-Miller]

I don't understand why you keep saying that.

Late night architectural-philosophical thoughts about treemacs buffer and scope identities. Also general confusion about what exactly is missing. I don't feel as pessimistic today. Still, I do need to try and use your code to get a proper grasp for what's missing.

It is not clear to me what you mean by that.

That's an idea for a simple scope type that would always work. Don't scope treemacs by anything, just always show the same buffer. No more different names for different scopes when there is only one permanent global scope.

Yes, that would be nice. I never liked seing this treemacs frame id in buffer lists,

What lists do you see it in? The space at the start of the name should hide the buffer from anything interactive.

[minad]

That's an idea for a simple scope type that would always work. Don't scope treemacs by anything, just always show the same buffer. No more different names for different scopes when there is only one permanent global scope.

This sounds like what my hack is doing 😁

What lists do you see it in? The space at the start of the name should hide the buffer from anything interactive.

Well it is internal, only if I am inspecting stuff, e.g. while writing bookmark-view. A while ago I still used ido-mode and there the buffer wasn't hidden for some reason. But I think there is nothing to fix here on the side of treemacs. Treemacs is doing the right thing with the space prefix. Only the non-deterministic name bothers me ;)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Alexander-Miller]

Stayin alive.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Alexander-Miller]

Stayin alive.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.