Loading a frame bookmark should restore geometry and explicit frame name even when reusing an existing frame

[shipmints]

Thanks to @pinaceaepinus via #32 (comment) for reporting this.

[shipmints]

See PR #53 which supersedes #49 which I will now rescind.

[shipmints]

@pinaceaepinus try this branch shipmints-frame-handler-name-geometry-logic from https://github.com/shipmints/bufferlo.git and see if this addresses your frame name (and potentially geometry) issues.

Follow the procedure here or use your own, similar, method #46 (comment)

[pinaceaepinus]

Great, this restores the frame name now (bufferlo-bookmark-frame-load-make-frame is nil). Thank you! :)

However, the geometry is not restored.

(With bufferlo-bookmark-frame-load-make-frame 'restore-geometry, the geometry is restored in a new frame)

[shipmints]

Try setting bufferlo-bookmark-frame-load-make-frame to 'reuse-restore-geometry. The updated documentation is in the branch I shared with you. I should have been clearer.

[pinaceaepinus]

Try setting bufferlo-bookmark-frame-load-make-frame to 'reuse-restore-geometry. The updated documentation is in the branch I shared with you. I should have been clearer.

Yes, the geometry is restored with 'reuse-restore-geometry as advertised. :)

I observe that when loading a set with two frames, option 'reuse-restore-geometry is not relevant. That makes sense as it's not obvious which of the two frame-bookmarks should be restored in the current frame.

In #32 you wrote:

The docs for the frame restoring options are here https://github.com/florommel/bufferlo/blob/main/README.org#frame-bookmark-options though I've added one option to the list for bufferlo-bookmark-frame-load-make-frame to accommodate the use case you brought up. If you refine your workflow to use the other options, I'd be curious if you adopt those.

Hmm, so here is my current workflow:

• To work on bigger or longer project/feature, I switch to a dedicated virtual desktop / workspace (window manager layer)
• There, I usually have to emacs frames open
  • something-dev (with tabs and buffers of source files, magit, ....) - frame is fullscreen
  • something-notes (with tabs and buffers of project's main org file for notes/tasks, man buffer, info buffers, ...) - frame 50% width and centered
• I bookmark these two frames as a bufferlo set.

So when continuing on a project/feature after e.g. a restart of the computer, I usually switch to a dedicated virtual desktop, fire up an emacs client and restore the corresponding bufferlo set. This opens the two bookmarked frames, resulting in three frames on that virtual desktop. As I have no use for the initial emacs client frame, I close it. I guess sooner or later I will look for a way to avoid this initial emacs client frame as I only use it to restore the bufferlo set bookmark on the desired virtual desktop.

So given this background, my use case is best served with

  (setq bufferlo-bookmark-frame-persist-frame-name t) ; default nil
  (setq bufferlo-bookmark-frame-load-make-frame 'restore-geometry) ; make a new frame and restore geometry

Currently, I don't use the other values for these variables.

[shipmints]

bufferlo sets with multiple frames use the Emacs frameset package to persist frames and you can either use Emacs's own geometry handler or the bufferlo one. There are two user options that control this behavior bufferlo-frameset-restore-geometry which controls which method geometry gets persisted in the frameset itself, and bufferlo-set-restore-geometry-policy which controls how geometry is restored. I suppose it is a bit confusing that sets are treated differently than vanilla frame bookmarks.

[pinaceaepinus]

OK. Is your comment "just" a (relevant) observation for this issue?

I'm asking because it feels a bit like there is a suggestion behind it that might improve something for my use case and I fail to extract that suggestion or the advantage for my case :)

[shipmints]

It's definitely a suggestion to look at the two user options mentioned. That it might be confusing is something we can refine over time, if we choose to unify bufferlo frame and framset controls.

[pinaceaepinus]

It's definitely a suggestion to look at the two user options mentioned. That it might be confusing is something we can refine over time, if we choose to unify bufferlo frame and framset controls.

From an user's perspective the question comes up why two methods exist. The help/description of bufferlo-frameset-restore-geometry does not answer the question. The README seems to provide the reason:

(setq bufferlo-frameset-restore-geometry 'native) ; uses `frameset-restore' geometry handling (buggy pre Emacs 31)

[shipmints]

Yes, the whole thing is tricky. We can collapse these in the future as bufferlo users move to Emacs 31+.