Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Frame titles not updated properly #62

Open
mikpom opened this issue Sep 27, 2023 · 11 comments
Open

Frame titles not updated properly #62

mikpom opened this issue Sep 27, 2023 · 11 comments
Assignees
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed
Milestone

Comments

@mikpom
Copy link

mikpom commented Sep 27, 2023

Greetings!

Just trying out burly. Unfortunately in my setup, frame titles which I configure to contain some dynamic information are not updated properly.

Also evaluating (force-mode-line-update t) doesn't help either. Frames continue to have the titles as restored from the bookmark. Everything is ok with the other frames (not opened by burly).

Thanks for you consideration,
-Mikhail

@alphapapa
Copy link
Owner

alphapapa commented Sep 27, 2023

Hi Mikhail,

Thanks for trying out Burly and reporting this issue. However, I don't understand exactly what the problem is. Would you please explain more exactly what is happening and what you are expecting to happen instead? And please explain exactly what you're doing, step-by-step.

@mikpom
Copy link
Author

mikpom commented Oct 16, 2023

Sorry for belated response, but looks like I managed to create a reproducible case.

So I run emacs with -Q providing path to installed burly

emacs -Q -L /path/to/burly/burly-20230917.1714

Now in *scratch* buffer I execute the following to enable burly and tweak frame title

(require 'burly)
(setq frame-title-format '((:eval
			   (format "%d" (length (window-list (window-frame)))))
			   "%b - GNU Emacs"))

Next I split the frame in two windows so the frame properly shows prepended number of windows like 2*scratch* - GNU Emacs. Then I create a bookmark for frames using interactive command burly-bookmark-frames . Finally after jumping to just created bookmark the frame is restored but has meaningless 2*Minibuf-1* - GNU Emacs title.

@alphapapa
Copy link
Owner

Thanks, now I understand.

Burly doesn't currently do anything about frame-title-format. It does set the name of tab-bar tabs when burly-tabs-mode is enabled.

If you want a frame title to be recorded and restored by Burly, you could set it as a frame parameter; see (info "(elisp) Basic Parameters") and option burly-frameset-filter-alist.

Other than that, if you have a feature request about this, please explain what you want it to do.

@mikpom
Copy link
Author

mikpom commented Oct 17, 2023

I think proper behavior is burly updating the frame title per frame-title-format spec and that's it. It is currently not so. In the case I provided no matter what you do with burly-restored frame (split in half, evaluate force-modeline-update (which is a way to update also the frame title despite modeline in the name)) the title remains incorrect.

Seems like burly blocks proper updating of the title or doesn't provide something to trigger the update. (those frame titles are coded in xdisp.c , yikes)

@alphapapa
Copy link
Owner

There may be a misunderstanding here. You manually set frame-title-format, which sets the default. If you don't want that to be the default for new frames, you shouldn't set it so.

@mikpom
Copy link
Author

mikpom commented Oct 17, 2023

Definitely there is some misunderstanding. However, I noticed that in my setup even with default frame-title-format settings title is incorrect. In vanilla emacs it has value

(multiple-frames "%b"
		 ("" "%b - GNU Emacs at " system-name))

So it should be of form {% buffer name %} - GNU Emacs at {% PC name %}. If I for example restore a frame with M-x bookmark-jump the restored frame has a title *Minibuf-1* - GNU Emacs at MyPC which is incorrect (it is incorrect because I focus on non-minibuffer window but the title is not response in burly-restored frame).

I posted an issue because believed that burly is not flexible enough to accomodate custom frame title settings but now I see problem in the default settings so it slightly changes the accents.

@alphapapa
Copy link
Owner

I'm not sure what you mean. If you look at the default value of burly-frameset-filter-alist, you'll see that it's '((name . nil)), which means that the name frame parameter is always copied. And if you look at the Elisp manual, you'll see that the name parameter takes precedence over frame-title-format.

@mikpom
Copy link
Author

mikpom commented Oct 18, 2023

Thanks to your precedence clarification I think I now understand the behavior. So the name is recorded and whenever emacs frame is created with a name parameter then frame-title-format is not even used.

However, don't you think it is strange that under whatever circumstances the frame can get Minibuf... in the title? If the original recorded frame had a dynamic title assigned per frame-title-format spec, shouldn't the restored one follow the same behavior and generate its title dynamically after windows are set up and buffers are restored using frame-title-format?

@alphapapa
Copy link
Owner

Please give a reproducible example that demonstrates exactly what you mean, i.e. step 1, 2, 3, etc.

@mikpom
Copy link
Author

mikpom commented Oct 19, 2023

  1. Start Emacs with

emacs -Q -L /path/to/burly/burly-20230917.1714/ --eval="(require 'burly)"

  1. Do M-x burly-bookmark-frames RET frames RET.
  2. Do M-x bookmark-jump RET frames RET

Result: restored frame has title *Minibuf-1* - GNU Emacs at my-PC
Expected behavior: title should be *scratch* - GNU Emacs at my-PC because the scratch buffer is one and the only buffer in the original and restored frames.

@alphapapa
Copy link
Owner

Thanks. I don't know what's causing that. I probably won't have time to work on this soon, but we'll see.

@alphapapa alphapapa self-assigned this Oct 19, 2023
@alphapapa alphapapa added the bug Something isn't working label Oct 19, 2023
@alphapapa alphapapa added this to the 0.4 milestone Oct 19, 2023
@alphapapa alphapapa added help wanted Extra attention is needed good first issue Good for newcomers labels Oct 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants