* bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw
@ 2022-11-26 21:46 Gabriel
2022-11-27 6:19 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Gabriel @ 2022-11-26 21:46 UTC (permalink / raw)
To: 59620
[-- Attachment #1: Type: text/plain, Size: 839 bytes --]
Severity: bug
Description:
The global-mode-string is wrongly positioned in tab-bar when using
"emacs -nw" and multiple windows. The bug only happens with emacs -nw.
Steps:
1) emacs -Q -nw (master "af545234314601ba3dcd8bf32e0d9b46e1917f79")
2) Eval the following to add display-time-mode right-aligned to tab-bar:
(progn
(display-time-mode 1)
(setopt tab-bar-format '(tab-bar-format-tabs-groups
tab-bar-separator
tab-bar-format-align-right
tab-bar-format-global))
(tab-bar-mode 1))
3) Split window right: C-x 3
Result: the global-mode-string will be wrongly positioned. It expected
to be right-aligned to the current frame, but it's right-aligned to the
left window. The position is correct while minibuffer has focus. See
attached images.
[-- Attachment #2: one-window.png --]
[-- Type: image/png, Size: 46605 bytes --]
[-- Attachment #3: bug.png --]
[-- Type: image/png, Size: 57348 bytes --]
[-- Attachment #4: minibuffer-focus.png --]
[-- Type: image/png, Size: 56507 bytes --]
[-- Attachment #5: Type: text/plain, Size: 13 bytes --]
---
Gabriel
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw
2022-11-26 21:46 bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw Gabriel
@ 2022-11-27 6:19 ` Eli Zaretskii
2022-11-27 8:05 ` Gabriel
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2022-11-27 6:19 UTC (permalink / raw)
To: Gabriel; +Cc: 59620
> From: Gabriel <gabriel376@hotmail.com>
> Date: Sat, 26 Nov 2022 18:46:08 -0300
>
> 1) emacs -Q -nw (master "af545234314601ba3dcd8bf32e0d9b46e1917f79")
>
> 2) Eval the following to add display-time-mode right-aligned to tab-bar:
>
> (progn
> (display-time-mode 1)
> (setopt tab-bar-format '(tab-bar-format-tabs-groups
> tab-bar-separator
> tab-bar-format-align-right
> tab-bar-format-global))
> (tab-bar-mode 1))
>
> 3) Split window right: C-x 3
>
> Result: the global-mode-string will be wrongly positioned. It expected
> to be right-aligned to the current frame, but it's right-aligned to the
> left window. The position is correct while minibuffer has focus. See
> attached images.
Looks like tab-bar-format-align-right is evaluated with the wrong window
being the selected one: it should use the tab-bar pseudo-window to do what
you expect.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw
2022-11-27 6:19 ` Eli Zaretskii
@ 2022-11-27 8:05 ` Gabriel
2022-11-28 7:54 ` Juri Linkov
0 siblings, 1 reply; 9+ messages in thread
From: Gabriel @ 2022-11-27 8:05 UTC (permalink / raw)
To: 59620
Eli Zaretskii <eliz@gnu.org> writes:
>
> Looks like tab-bar-format-align-right is evaluated with the wrong window
> being the selected one: it should use the tab-bar pseudo-window to do what
> you expect.
I don't know what is the root cause, but it's a reasonable hypothesis.
Not sure why it only affects "emacs -nw", though.
Do you know how to get the tab-bar pseudo-window? It seems that
"f->tab_bar_window" it's not exposed from C to elisp.
Anyway, I think it's a bug. Maybe Juri can help on this. I will try to
find a fix, but I can't promise.
---
Gabriel
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw
2022-11-27 8:05 ` Gabriel
@ 2022-11-28 7:54 ` Juri Linkov
2022-11-28 12:58 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2022-11-28 7:54 UTC (permalink / raw)
To: Gabriel; +Cc: 59620
>> Looks like tab-bar-format-align-right is evaluated with the wrong window
>> being the selected one: it should use the tab-bar pseudo-window to do what
>> you expect.
>
> I don't know what is the root cause, but it's a reasonable hypothesis.
> Not sure why it only affects "emacs -nw", though.
>
> Do you know how to get the tab-bar pseudo-window? It seems that
> "f->tab_bar_window" it's not exposed from C to elisp.
Unless Eli can suggest how to fix `(space :align-to (- right (,hpos)))
to work on TTY frames the same way as it works on GUI frames,
I could try to rewrite it to avoid the keyword `right', i.e. to use
`(space :align-to (,hpos-from-left)) where hpos-from-left could be
calculated by using string-pixel-width on the text from the left side.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw
2022-11-28 7:54 ` Juri Linkov
@ 2022-11-28 12:58 ` Eli Zaretskii
2022-11-28 17:29 ` Juri Linkov
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2022-11-28 12:58 UTC (permalink / raw)
To: Juri Linkov; +Cc: gabriel376, 59620
> Cc: 59620@debbugs.gnu.org
> From: Juri Linkov <juri@linkov.net>
> Date: Mon, 28 Nov 2022 09:54:17 +0200
>
> >> Looks like tab-bar-format-align-right is evaluated with the wrong window
> >> being the selected one: it should use the tab-bar pseudo-window to do what
> >> you expect.
> >
> > I don't know what is the root cause, but it's a reasonable hypothesis.
> > Not sure why it only affects "emacs -nw", though.
> >
> > Do you know how to get the tab-bar pseudo-window? It seems that
> > "f->tab_bar_window" it's not exposed from C to elisp.
>
> Unless Eli can suggest how to fix `(space :align-to (- right (,hpos)))
> to work on TTY frames the same way as it works on GUI frames,
> I could try to rewrite it to avoid the keyword `right', i.e. to use
> `(space :align-to (,hpos-from-left)) where hpos-from-left could be
> calculated by using string-pixel-width on the text from the left side.
I replied without paying attention to the -nw part, sorry.
On TTY frames the tab bar is not a window, so what I wrote is impossible,
and thus avoiding the 'right' part in the align-to spec is a good idea
regardless.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw
2022-11-28 12:58 ` Eli Zaretskii
@ 2022-11-28 17:29 ` Juri Linkov
2022-11-28 18:34 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2022-11-28 17:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gabriel376, 59620
[-- Attachment #1: Type: text/plain, Size: 595 bytes --]
> On TTY frames the tab bar is not a window, so what I wrote is impossible,
> and thus avoiding the 'right' part in the align-to spec is a good idea
> regardless.
Avoiding the 'right' part in align-to has such a drawback that while
resizing the frame the position of the aligned element is not updated
immediately. It's updated only when display-time refreshes the time on
the tab bar. The position relative to the right edge has no such problem.
So better to leave the 'right' part on GUI frames, and switch to counting
from the left only on TTY frames where frames are resized less often:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tab-bar-format-align-right.patch --]
[-- Type: text/x-diff, Size: 719 bytes --]
diff --git a/lisp/tab-bar.el b/lisp/tab-bar.el
index eb4cec48619..cabad9d7d5e 100644
--- a/lisp/tab-bar.el
+++ b/lisp/tab-bar.el
@@ -936,7 +936,10 @@ tab-bar-format-align-right
(hpos (progn
(add-face-text-property 0 (length rest) 'tab-bar t rest)
(string-pixel-width rest)))
- (str (propertize " " 'display `(space :align-to (- right (,hpos))))))
+ (str (propertize " " 'display
+ (if window-system
+ `(space :align-to (- right (,hpos)))
+ `(space :align-to (,(- (frame-inner-width) hpos)))))))
`((align-right menu-item ,str ignore))))
(defun tab-bar-format-global ()
^ permalink raw reply related [flat|nested] 9+ messages in thread
* bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw
2022-11-28 17:29 ` Juri Linkov
@ 2022-11-28 18:34 ` Eli Zaretskii
2022-12-02 7:59 ` Juri Linkov
0 siblings, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2022-11-28 18:34 UTC (permalink / raw)
To: Juri Linkov; +Cc: gabriel376, 59620
> From: Juri Linkov <juri@linkov.net>
> Cc: gabriel376@hotmail.com, 59620@debbugs.gnu.org
> Date: Mon, 28 Nov 2022 19:29:38 +0200
>
> Avoiding the 'right' part in align-to has such a drawback that while
> resizing the frame the position of the aligned element is not updated
> immediately. It's updated only when display-time refreshes the time on
> the tab bar. The position relative to the right edge has no such problem.
> So better to leave the 'right' part on GUI frames, and switch to counting
> from the left only on TTY frames where frames are resized less often:
That would require you to make sure this code always runs in the context of
the tab-bar (pseudo)window. If that can be ensured, fine.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw
2022-11-28 18:34 ` Eli Zaretskii
@ 2022-12-02 7:59 ` Juri Linkov
2022-12-02 15:01 ` Eli Zaretskii
0 siblings, 1 reply; 9+ messages in thread
From: Juri Linkov @ 2022-12-02 7:59 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: gabriel376, 59620-done
>> Avoiding the 'right' part in align-to has such a drawback that while
>> resizing the frame the position of the aligned element is not updated
>> immediately. It's updated only when display-time refreshes the time on
>> the tab bar. The position relative to the right edge has no such problem.
>> So better to leave the 'right' part on GUI frames, and switch to counting
>> from the left only on TTY frames where frames are resized less often:
>
> That would require you to make sure this code always runs in the context of
> the tab-bar (pseudo)window. If that can be ensured, fine.
Since this can't be ensured, I pushed a simpler patch to emacs-29,
and closed.
^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw
2022-12-02 7:59 ` Juri Linkov
@ 2022-12-02 15:01 ` Eli Zaretskii
0 siblings, 0 replies; 9+ messages in thread
From: Eli Zaretskii @ 2022-12-02 15:01 UTC (permalink / raw)
To: Juri Linkov; +Cc: gabriel376, 59620-done
> From: Juri Linkov <juri@linkov.net>
> Cc: gabriel376@hotmail.com, 59620-done@debbugs.gnu.org
> Date: Fri, 02 Dec 2022 09:59:57 +0200
>
> > That would require you to make sure this code always runs in the context of
> > the tab-bar (pseudo)window. If that can be ensured, fine.
>
> Since this can't be ensured, I pushed a simpler patch to emacs-29,
> and closed.
Thanks, but I think the code needs to use window-system the function, not
the variable, so that you could ask about the currently-selected frame. We
generally don't want to use window-system the variable too much.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-12-02 15:01 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-11-26 21:46 bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw Gabriel
2022-11-27 6:19 ` Eli Zaretskii
2022-11-27 8:05 ` Gabriel
2022-11-28 7:54 ` Juri Linkov
2022-11-28 12:58 ` Eli Zaretskii
2022-11-28 17:29 ` Juri Linkov
2022-11-28 18:34 ` Eli Zaretskii
2022-12-02 7:59 ` Juri Linkov
2022-12-02 15:01 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).