bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw

bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw

[Gabriel]

[-- 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

bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw

[Eli Zaretskii]

> 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.

bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw

[Gabriel]

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

bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw

[Juri Linkov]

>> 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.

bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw

[Eli Zaretskii]

> 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.

bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw

[Juri Linkov]

[-- 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 ()

bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw

[Eli Zaretskii]

> 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.

bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw

[Juri Linkov]

>> 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.

bug#59620: 29.0.50; Wrong global-mode-string position in tab-bar + emacs -nw

[Eli Zaretskii]

> 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.