bug#39649: 27.0.60; tab-line doesn't scroll

bug#39649: 27.0.60; tab-line doesn't scroll

[João Guerra]

tab-line doesn't scroll despite tab-line-auto-hscroll being set to t.

When having several buffers open and switching to one that is not
currently visible in the tab-line the tab-line won't auto-scroll.
Video example: https://youtu.be/TDBeox2tQoA

In GNU Emacs 27.0.60 (build 1, x86_64-w64-mingw32)
 of 2019-12-28 built on CIRROCUMULUS
Repository revision: 21c3020fcec0a32122d2680a391864a75393031b
Repository branch: emacs-27
Windowing system distributor 'Microsoft Corp.', version 10.0.18363
System Description: Microsoft Windows 10 Pro (v10.0.1909.18363.535)

Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install -C 'CFLAGS=-O2 -static -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: PTG
  locale-coding-system: cp1252

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

> tab-line doesn't scroll despite tab-line-auto-hscroll being set to t.
>
> When having several buffers open and switching to one that is not
> currently visible in the tab-line the tab-line won't auto-scroll.

This is an intentional feature: auto-scroll is disabled after
the first time when you scroll the tab-line manually.

Otherwise you won't be able to scroll the tab-line with the
mouse-wheel or using the arrow buttons when auto-scrolling
is still in effect during manual scrolling.

You can reset auto-scrolling by evaluating in e.g. ‘M-:’

  (set-window-parameter nil 'tab-line-hscroll nil)

But indeed this is not right way to do this - it should automatically
reset auto-scrolling at some time afterwards after finishing manually
scrolling the tab-line.  I was unable to find such a natural event on which
to reset auto-scrolling - there are too many different possible events to
choose from.  One of the most natural is to reset auto-scrolling after
manually selecting a tab.

Could you please try this patch to see if it solves your problem:

diff --git a/lisp/tab-line.el b/lisp/tab-line.el
index 8f1221abe4..86ac234f3d 100644
--- a/lisp/tab-line.el
+++ b/lisp/tab-line.el
@@ -600,6 +600,7 @@ tab-line-select-tab
   (let* ((posnp (event-start e))
          (tab (get-pos-property 1 'tab (car (posn-string posnp))))
          (buffer (if (bufferp tab) tab (cdr (assq 'buffer tab)))))
+    (set-window-parameter nil 'tab-line-hscroll nil)
     (if buffer
         (tab-line-select-tab-buffer buffer (posn-window posnp))
       (let ((select (cdr (assq 'select tab))))

bug#39649: 27.0.60; tab-line doesn't scroll

[João Guerra]

Seems to fix the issue in a specific situation, viz. after I select a
tab manually with the mouse. However, when selecting a buffer that is
already visible in the tab-line the tab-line still might get scrolled
or if I just scroll the tab-line and change to a non-visible buffer
the tab-line doesn't get scrolled. I'm a bit interested in knowing the
reasoning to not always scroll the tab-line.

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

> Seems to fix the issue in a specific situation, viz. after I select a
> tab manually with the mouse. However, when selecting a buffer that is
> already visible in the tab-line the tab-line still might get scrolled
> or if I just scroll the tab-line and change to a non-visible buffer
> the tab-line doesn't get scrolled. I'm a bit interested in knowing the
> reasoning to not always scroll the tab-line.

While you're manually scrolling the tab-line using the mouse wheel
or clicking on arrow buttons, auto-scrolling should be disabled
because it should not bring the current tab back into view immediately
on every step of manual scrolling.  Just imagine that you clicked
on the arrow button to scroll, but it has no effect because auto-scrolling
immediately moved the tab-line back to its original state.
This is why auto-scrolling should be disabled during manual scrolling.

Now the question: how to detect the moment when you stop manually
scrolling?  How would you indicate that manual scrolling is finished,
and it's time to enable auto-scrolling to bring the currently selected tab
back into view?  I have no idea.

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

>> Seems to fix the issue in a specific situation, viz. after I select a
>> tab manually with the mouse. However, when selecting a buffer that is
>> already visible in the tab-line the tab-line still might get scrolled
>> or if I just scroll the tab-line and change to a non-visible buffer
>> the tab-line doesn't get scrolled. I'm a bit interested in knowing the
>> reasoning to not always scroll the tab-line.
>
> While you're manually scrolling the tab-line using the mouse wheel
> or clicking on arrow buttons, auto-scrolling should be disabled
> because it should not bring the current tab back into view immediately
> on every step of manual scrolling.  Just imagine that you clicked
> on the arrow button to scroll, but it has no effect because auto-scrolling
> immediately moved the tab-line back to its original state.
> This is why auto-scrolling should be disabled during manual scrolling.
>
> Now the question: how to detect the moment when you stop manually
> scrolling?  How would you indicate that manual scrolling is finished,
> and it's time to enable auto-scrolling to bring the currently selected tab
> back into view?  I have no idea.

Actually, I have an idea - the right moment is when the current buffer
changes on the current tab.  This patch is the right way to handle this case:

diff --git a/lisp/tab-line.el b/lisp/tab-line.el
index 86ac234f3d..ad2b167e33 100644
--- a/lisp/tab-line.el
+++ b/lisp/tab-line.el
@@ -464,6 +464,13 @@ tab-line-format
                           (window-buffer)
                           (window-parameter nil 'tab-line-hscroll)))
          (cache (window-parameter nil 'tab-line-cache)))
+    ;; Enable auto-hscroll again after it was disabled on manual scrolling.
+    ;; The moment to enable it is when the window-buffer was updated.
+    (when (and tab-line-auto-hscroll       ; if auto-hscroll was enabled
+               (natnump (nth 2 cache-key)) ; non-negative on manual scroll
+               cache                       ; window-buffer was updated
+               (not (equal (nth 1 (car cache)) (nth 1 cache-key))))
+      (set-window-parameter nil 'tab-line-hscroll nil))
     (or (and cache (equal (car cache) cache-key) (cdr cache))
         (cdr (set-window-parameter
               nil 'tab-line-cache

bug#39649: 27.0.60; tab-line doesn't scroll

[João Guerra]

This seems better to me. However, scrolling is occurring when not
necessary, which looks kinda weird https://youtu.be/_YG0XH8XJpI

On Wed, 19 Feb 2020 at 01:51, Juri Linkov <juri@linkov.net> wrote:
>
> >> Seems to fix the issue in a specific situation, viz. after I select a
> >> tab manually with the mouse. However, when selecting a buffer that is
> >> already visible in the tab-line the tab-line still might get scrolled
> >> or if I just scroll the tab-line and change to a non-visible buffer
> >> the tab-line doesn't get scrolled. I'm a bit interested in knowing the
> >> reasoning to not always scroll the tab-line.
> >
> > While you're manually scrolling the tab-line using the mouse wheel
> > or clicking on arrow buttons, auto-scrolling should be disabled
> > because it should not bring the current tab back into view immediately
> > on every step of manual scrolling.  Just imagine that you clicked
> > on the arrow button to scroll, but it has no effect because auto-scrolling
> > immediately moved the tab-line back to its original state.
> > This is why auto-scrolling should be disabled during manual scrolling.
> >
> > Now the question: how to detect the moment when you stop manually
> > scrolling?  How would you indicate that manual scrolling is finished,
> > and it's time to enable auto-scrolling to bring the currently selected tab
> > back into view?  I have no idea.
>
> Actually, I have an idea - the right moment is when the current buffer
> changes on the current tab.  This patch is the right way to handle this case:
>
> diff --git a/lisp/tab-line.el b/lisp/tab-line.el
> index 86ac234f3d..ad2b167e33 100644
> --- a/lisp/tab-line.el
> +++ b/lisp/tab-line.el
> @@ -464,6 +464,13 @@ tab-line-format
>                            (window-buffer)
>                            (window-parameter nil 'tab-line-hscroll)))
>           (cache (window-parameter nil 'tab-line-cache)))
> +    ;; Enable auto-hscroll again after it was disabled on manual scrolling.
> +    ;; The moment to enable it is when the window-buffer was updated.
> +    (when (and tab-line-auto-hscroll       ; if auto-hscroll was enabled
> +               (natnump (nth 2 cache-key)) ; non-negative on manual scroll
> +               cache                       ; window-buffer was updated
> +               (not (equal (nth 1 (car cache)) (nth 1 cache-key))))
> +      (set-window-parameter nil 'tab-line-hscroll nil))
>      (or (and cache (equal (car cache) cache-key) (cdr cache))
>          (cdr (set-window-parameter
>                nil 'tab-line-cache

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

> This seems better to me. However, scrolling is occurring when not
> necessary, which looks kinda weird https://youtu.be/_YG0XH8XJpI

Thanks for the detailed visual bug reports - it's clear now
what should be fixed.  The following patch provides almost
prefect behavior with only one exception: it fails to switch
back from manual scrolling to automatic scrolling when
the tab-line is at its beginning, showing the first tab.
The problem is that in Emacs there is no such thing as
negative zero.

I don't understand why Emacs doesn't support signed zero.
For example in JavaScript: Math.sign(-0) => -0

Signed zero would help in the auto-hscroll implementation where
positive integers encode positions of manual scrolling and
negative integers encode positions of automatic scrolling.
And switching from manual to automatic just changes the sign.

But since positions count from zero, there is no way
to distinguish manual scrolling position from automatic
scrolling position at the beginning of the tab-line.

I have no idea how to overcome this limitation.

diff --git a/lisp/tab-line.el b/lisp/tab-line.el
index 8f1221abe4..70ca7e2204 100644
--- a/lisp/tab-line.el
+++ b/lisp/tab-line.el
@@ -464,6 +466,13 @@ tab-line-format
                           (window-buffer)
                           (window-parameter nil 'tab-line-hscroll)))
          (cache (window-parameter nil 'tab-line-cache)))
+    ;; Enable auto-hscroll again after it was disabled on manual scrolling.
+    ;; The moment to enable it is when the window-buffer was updated.
+    (when (and tab-line-auto-hscroll       ; if auto-hscroll was enabled
+               (natnump (nth 2 cache-key)) ; non-negative on manual scroll
+               cache                       ; window-buffer was updated
+               (not (equal (nth 1 (car cache)) (nth 1 cache-key))))
+      (set-window-parameter nil 'tab-line-hscroll (- (nth 2 cache-key))))
     (or (and cache (equal (car cache) cache-key) (cdr cache))
         (cdr (set-window-parameter
               nil 'tab-line-cache

bug#39649: 27.0.60; tab-line doesn't scroll

[Noam Postavsky]

Juri Linkov <juri@linkov.net> writes:

> I don't understand why Emacs doesn't support signed zero.
> For example in JavaScript: Math.sign(-0) => -0

It does, for floats (afaik, in JavaScript all numbers are floating
point).

    (copysign 1.0 -0.0) ;=> -1.0

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 407 bytes --]

>> I don't understand why Emacs doesn't support signed zero.
>> For example in JavaScript: Math.sign(-0) => -0
>
> It does, for floats (afaik, in JavaScript all numbers are floating
> point).
>
>     (copysign 1.0 -0.0) ;=> -1.0

Then if take into use floats, the distinction could be
not between positive/negative floats, but between integers/floats.

João, could you please try a new patch:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tab-line-auto-hscroll.patch --]
[-- Type: text/x-diff, Size: 5217 bytes --]

diff --git a/lisp/tab-line.el b/lisp/tab-line.el
index 8f1221abe4..754a0a95ab 100644
--- a/lisp/tab-line.el
+++ b/lisp/tab-line.el
@@ -446,17 +446,19 @@ tab-line-format-template
            (setq hscroll nil)
            (set-window-parameter nil 'tab-line-hscroll hscroll))
        (list separator
-             (when (and (integerp hscroll) (not (zerop hscroll)))
+             (when (and (numberp hscroll) (not (zerop hscroll)))
                tab-line-left-button)
-             (when (if (integerp hscroll)
-                       (< (abs hscroll) (1- (length strings)))
+             (when (if (numberp hscroll)
+                       (< (truncate hscroll) (1- (length strings)))
                      (> (length strings) 1))
                tab-line-right-button)))
-     (if hscroll (nthcdr (abs hscroll) strings) strings)
+     (if hscroll (nthcdr (truncate hscroll) strings) strings)
      (when (eq tab-line-tabs-function #'tab-line-tabs-window-buffers)
        (list (concat separator (when tab-line-new-tab-choice
                                  tab-line-new-button)))))))
 
+(defvar tab-line-auto-hscroll)
+
 (defun tab-line-format ()
   "Template for displaying tab line for selected window."
   (let* ((tabs (funcall tab-line-tabs-function))
@@ -464,6 +466,13 @@ tab-line-format
                           (window-buffer)
                           (window-parameter nil 'tab-line-hscroll)))
          (cache (window-parameter nil 'tab-line-cache)))
+    ;; Enable auto-hscroll again after it was disabled on manual scrolling.
+    ;; The moment to enable it is when the window-buffer was updated.
+    (when (and tab-line-auto-hscroll        ; if auto-hscroll was enabled
+               (integerp (nth 2 cache-key)) ; integer on manual scroll
+               cache                        ; window-buffer was updated
+               (not (equal (nth 1 (car cache)) (nth 1 cache-key))))
+      (set-window-parameter nil 'tab-line-hscroll (float (nth 2 cache-key))))
     (or (and cache (equal (car cache) cache-key) (cdr cache))
         (cdr (set-window-parameter
               nil 'tab-line-cache
@@ -490,12 +499,12 @@ tab-line-auto-hscroll
       ;; Continuation means tab-line doesn't fit completely,
       ;; thus scroll arrows are needed for scrolling.
       (setq show-arrows (> (vertical-motion 1) 0))
-      ;; Try to auto-scroll only when scrolling is needed,
+      ;; Try to auto-hscroll only when scrolling is needed,
       ;; but no manual scrolling was performed before.
       (when (and tab-line-auto-hscroll
                  show-arrows
                  ;; Do nothing when scrolled manually
-                 (not (and (integerp hscroll) (>= hscroll 0))))
+                 (not (integerp hscroll)))
         (let ((selected (seq-position strings 'selected
                                       (lambda (str prop)
                                         (get-pos-property 1 prop str)))))
@@ -503,7 +512,7 @@ tab-line-auto-hscroll
            ((null selected)
             ;; Do nothing if no tab is selected
             )
-           ((or (not (integerp hscroll)) (< selected (abs hscroll)))
+           ((or (not (numberp hscroll)) (< selected (truncate hscroll)))
             ;; Selected is scrolled to the left, or no scrolling yet
             (erase-buffer)
             (apply 'insert (reverse (seq-subseq strings 0 (1+ selected))))
@@ -520,14 +529,14 @@ tab-line-auto-hscroll
                                                     (lambda (str tab)
                                                       (eq (get-pos-property 1 'tab str) tab))))))
                   (when new-hscroll
-                    (setq hscroll (- new-hscroll))
+                    (setq hscroll (float new-hscroll))
                     (set-window-parameter nil 'tab-line-hscroll hscroll)))
               (setq hscroll nil)
               (set-window-parameter nil 'tab-line-hscroll hscroll)))
            (t
             ;; Check if the selected tab is already visible
             (erase-buffer)
-            (apply 'insert (seq-subseq strings (abs hscroll) (1+ selected)))
+            (apply 'insert (seq-subseq strings (truncate hscroll) (1+ selected)))
             (goto-char (point-min))
             (add-face-text-property (point-min) (point-max) 'tab-line)
             (when (> (vertical-motion 1) 0)
@@ -547,7 +556,7 @@ tab-line-auto-hscroll
                                                     (lambda (str tab)
                                                       (eq (get-pos-property 1 'tab str) tab))))))
                   (when new-hscroll
-                    (setq hscroll (- new-hscroll))
+                    (setq hscroll (float new-hscroll))
                     (set-window-parameter nil 'tab-line-hscroll hscroll)))))))))
       (list show-arrows hscroll))))
 
@@ -559,7 +568,7 @@ tab-line-hscroll
                  (funcall tab-line-tabs-function))))
     (set-window-parameter
      window 'tab-line-hscroll
-     (max 0 (min (+ (if (integerp hscroll) (abs hscroll) 0) (or arg 1))
+     (max 0 (min (+ (if (numberp hscroll) (truncate hscroll) 0) (or arg 1))
                  (1- (length tabs)))))
     (when window
       (force-mode-line-update t))))

bug#39649: 27.0.60; tab-line doesn't scroll

[João Guerra]

Regarding the scrolling this seems more natural to me or at least more
similar to most applications and thus to the expectations most people
might have regarding scrolling file tabs.

I did find a bug, didn't test if it was there before already:
https://youtu.be/EAM581LO__8

On Sun, 23 Feb 2020 at 01:44, Juri Linkov <juri@linkov.net> wrote:
>
> >> I don't understand why Emacs doesn't support signed zero.
> >> For example in JavaScript: Math.sign(-0) => -0
> >
> > It does, for floats (afaik, in JavaScript all numbers are floating
> > point).
> >
> >     (copysign 1.0 -0.0) ;=> -1.0
>
> Then if take into use floats, the distinction could be
> not between positive/negative floats, but between integers/floats.
>
> João, could you please try a new patch:
>

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

> Regarding the scrolling this seems more natural to me or at least more
> similar to most applications and thus to the expectations most people
> might have regarding scrolling file tabs.

Yes, I agree.

> I did find a bug, didn't test if it was there before already:
> https://youtu.be/EAM581LO__8

Thanks, I tried to reproduce the bug, but it's not reproducible.
Maybe it depends on your customization.

I see that you customizied tab-line-tabs-function to "Same mode buffers"
(tab-line-tabs-mode-buffers).  But what about other tab-line customizations?
Please send your tab-line faces customizations.  I guess the bug depends
on tab-line faces.  Or you could try to reproduce the bug with default
settings by 'emacs -Q'.

bug#39649: 27.0.60; tab-line doesn't scroll

[João Guerra]

I have the same issue with `emacs -q` and `(setq
tab-line-tabs-function #'tab-line-tabs-mode-buffers)` on GNU Emacs
27.0.60 (build 1, x86_64-w64-mingw32) of 2020-02-10.

On Mon, 24 Feb 2020 at 00:51, Juri Linkov <juri@linkov.net> wrote:
>
> > Regarding the scrolling this seems more natural to me or at least more
> > similar to most applications and thus to the expectations most people
> > might have regarding scrolling file tabs.
>
> Yes, I agree.
>
> > I did find a bug, didn't test if it was there before already:
> > https://youtu.be/EAM581LO__8
>
> Thanks, I tried to reproduce the bug, but it's not reproducible.
> Maybe it depends on your customization.
>
> I see that you customizied tab-line-tabs-function to "Same mode buffers"
> (tab-line-tabs-mode-buffers).  But what about other tab-line customizations?
> Please send your tab-line faces customizations.  I guess the bug depends
> on tab-line faces.  Or you could try to reproduce the bug with default
> settings by 'emacs -Q'.

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

Please help to understand how to reproduce this bug:

> I have the same issue with `emacs -q`

Have you tried `emacs -Q`?
I don't know if there is any difference between
`emacs -Q` and `emacs -q` on Windows.  But `emacs -q`
loads all resources so maybe it loads additional
face definitions for tab-line.

I see that left/right arrows in your bug report are XPM images.
But I don't understand how this is possible because
(info "(efaq-w32) Image support") says that Emacs has
no built-in support for XPM on Windows.

Please try to reproduce the same bug without XPM images
by evaluating these lines:

(setq tab-line-left-button " <")
(setq tab-line-right-button "> ")

Also it's possible that maybe the widths of these buttons
affect the calculations somehow.

Please also try to remove these arrow buttons temporarily with:

(setq tab-line-left-button nil)
(setq tab-line-right-button nil)

Do you see the same bug?

> on GNU Emacs 27.0.60 (build 1, x86_64-w64-mingw32) of 2020-02-10.

The compilation date is 2020-02-10.
Did you apply the patch that I sent?
I could commit the patch, then you could
update your repository if you want.

bug#39649: 27.0.60; tab-line doesn't scroll

[João Guerra]

It does have your patch, but just the latest one in this thread.
Video demonstration: https://youtu.be/xq_JMBO4SyI.
I'm using Emacs from
https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/. It does
have XPM support.

Issue still happens when I do
(setq tab-line-left-button nil)
(setq tab-line-right-button nil)

On Tue, 25 Feb 2020 at 22:33, Juri Linkov <juri@linkov.net> wrote:
>
> Please help to understand how to reproduce this bug:
>
> > I have the same issue with `emacs -q`
>
> Have you tried `emacs -Q`?
> I don't know if there is any difference between
> `emacs -Q` and `emacs -q` on Windows.  But `emacs -q`
> loads all resources so maybe it loads additional
> face definitions for tab-line.
>
> I see that left/right arrows in your bug report are XPM images.
> But I don't understand how this is possible because
> (info "(efaq-w32) Image support") says that Emacs has
> no built-in support for XPM on Windows.
>
> Please try to reproduce the same bug without XPM images
> by evaluating these lines:
>
> (setq tab-line-left-button " <")
> (setq tab-line-right-button "> ")
>
> Also it's possible that maybe the widths of these buttons
> affect the calculations somehow.
>
> Please also try to remove these arrow buttons temporarily with:
>
> (setq tab-line-left-button nil)
> (setq tab-line-right-button nil)
>
> Do you see the same bug?
>
> > on GNU Emacs 27.0.60 (build 1, x86_64-w64-mingw32) of 2020-02-10.
>
> The compilation date is 2020-02-10.
> Did you apply the patch that I sent?
> I could commit the patch, then you could
> update your repository if you want.

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

> It does have your patch, but just the latest one in this thread.
> Video demonstration: https://youtu.be/xq_JMBO4SyI.
> I'm using Emacs from
> https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/. It does
> have XPM support.

Thanks for the recipe.  I tried everything possible, but still
no bug reproduction.

Given the above, may I ask you to run some debugging diagnostics:

1. load the attached file, e.g. with M-x load-file
2. M-x global-tab-line-mode
3. perform all steps from your bug report
4. after the last step, when the tab selection fails, execute

   M-x test1 RET

and make a screenshot.  The screenshot should look like on the image attached.

I suspect that the problem comes from the tab-line fontified differently
by core and when fontified manually in the buffer.


[-- Attachment #2: screenshot1.png --]
[-- Type: image/png, Size: 22200 bytes --]

[-- Attachment #3: tab-line-1.el --]
[-- Type: application/emacs-lisp, Size: 34051 bytes --]

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

> I suspect that the problem comes from the tab-line fontified differently
> by core and when fontified manually in the buffer.

Eli, could you explain why there no wrapper around the C function
display_mode_element exposed to Lisp.  The closest function is
format-mode-line but still its formatting is different from what
display_mode_element really displays in the tab-line.

Steps to reproduce the problem:

1. emacs -Q
2. M-x global-tab-line-mode

3. C-x b test1
4. M-: (insert (format-mode-line (tab-line-format)))
5. Note how the tab uses the face tab-line-tab
   with released-button box style, but the tab-line
   doesn't use the face tab-line

6. C-x b test2
7. M-: (insert (format-mode-line (tab-line-format) 'tab-line))
8. Note how the the tab-line now uses the face tab-line,
   but this face overrides the faces of individual tabs that
   should have the face tab-line-tab with released-button box style.

I can't find a function that would insert to the current buffer
a string formatted exactly as the tab-line displayed
above the window.

bug#39649: 27.0.60; tab-line doesn't scroll

[João Guerra]

1. emacs -Q
2. M-x load-file tab-line-1.el
3. M-x global-tab-line-mode
4. M-: (setq tab-line-tabs-function #'tab-line-tabs-mode-buffers)
5. https://youtu.be/fQlrP0dlBbw

On Thu, 27 Feb 2020 at 00:19, Juri Linkov <juri@linkov.net> wrote:
>
> > It does have your patch, but just the latest one in this thread.
> > Video demonstration: https://youtu.be/xq_JMBO4SyI.
> > I'm using Emacs from
> > https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/. It does
> > have XPM support.
>
> Thanks for the recipe.  I tried everything possible, but still
> no bug reproduction.
>
> Given the above, may I ask you to run some debugging diagnostics:
>
> 1. load the attached file, e.g. with M-x load-file
> 2. M-x global-tab-line-mode
> 3. perform all steps from your bug report
> 4. after the last step, when the tab selection fails, execute
>
>    M-x test1 RET
>
> and make a screenshot.  The screenshot should look like on the image attached.
>
> I suspect that the problem comes from the tab-line fontified differently
> by core and when fontified manually in the buffer.
>

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

> 1. emacs -Q
> 2. M-x load-file tab-line-1.el
> 3. M-x global-tab-line-mode
> 4. M-: (setq tab-line-tabs-function #'tab-line-tabs-mode-buffers)
> 5. https://youtu.be/fQlrP0dlBbw

Thanks, now it's clear where the problem is:
the buffer *Messages* shows that old code is loaded,
i.e. first you load the new file tab-line-1.el
(the first line in the buffer *Messages*),
but later its functions are overridden by old file
(the third line in the buffer *Messages*).
Only the new command 'test1' remains loaded,
all other functions are overridden from old file
tab-line.el.

I believe this could be solved by changing the loading order:

1. emacs -Q
2. M-x global-tab-line-mode
   - this will load old file tab-line.el
3. M-x load-file tab-line-1.el
   - old functions will be overridden by new file tab-line-1.el

Please try this.

bug#39649: 27.0.60; tab-line doesn't scroll

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: João Guerra <joca.bt@gmail.com>,
>   39649@debbugs.gnu.org
> Date: Thu, 27 Feb 2020 01:33:00 +0200
> 
> > I suspect that the problem comes from the tab-line fontified differently
> > by core and when fontified manually in the buffer.
> 
> Eli, could you explain why there no wrapper around the C function
> display_mode_element exposed to Lisp.

Why would we need that?  The related display code is in C, so we never
needed to expose this to Lisp.

I also don't understand the relation between this question and the
recipes you show.

> The closest function is format-mode-line but still its formatting is
> different from what display_mode_element really displays in the
> tab-line.

Why is that a problem?  format-mode-line was not intended to be used
in display context.

> 1. emacs -Q
> 2. M-x global-tab-line-mode
> 
> 3. C-x b test1
> 4. M-: (insert (format-mode-line (tab-line-format)))
> 5. Note how the tab uses the face tab-line-tab
>    with released-button box style, but the tab-line
>    doesn't use the face tab-line

I don't see tab-line-tab face, I see either tab-line-tab-inactive or
tab-line-tab-current.  And the button style and its mouse-sensitive
behavior follows what I see on the real tab-line.

But maybe I don't understand what you allude to here.  What is the
"tab" in this context, and what is "tab-line"?  You have one inserted
into buffer text and one displayed on header-line-like tab-line --
which one do you allude to here?  And why do you think what is
displayed is some kind of problem?

> 6. C-x b test2
> 7. M-: (insert (format-mode-line (tab-line-format) 'tab-line))
> 8. Note how the the tab-line now uses the face tab-line,
>    but this face overrides the faces of individual tabs that
>    should have the face tab-line-tab with released-button box style.

And here I don't understand what you mean by "overrides".

> I can't find a function that would insert to the current buffer
> a string formatted exactly as the tab-line displayed
> above the window.

Why is that needed?

P.S.  I did all the testing in Emacs 27.0.90, the latest emacs-27
branch.

Thanks.

bug#39649: 27.0.60; tab-line doesn't scroll

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Date: Tue, 25 Feb 2020 23:20:10 +0200
> Cc: 39649@debbugs.gnu.org
> 
> I see that left/right arrows in your bug report are XPM images.
> But I don't understand how this is possible because
> (info "(efaq-w32) Image support") says that Emacs has
> no built-in support for XPM on Windows.

That's not what the w32 FAQ says.  It says this:

  Emacs has built in support for XBM and PBM/PGM/PPM images.  This is
  sufficient to see the monochrome splash screen and tool-bar icons.
  Since v22.2, the official precompiled binaries for Windows have bundled
  libXpm, which is required to display the color versions of those images.

IOW, XPM support is not built-in, but MS-Windows binaries of all Emacs
versions since v22.2 are distributed with the libXpm library, which
allows the w32 build to display XPM images.

bug#39649: 27.0.60; tab-line doesn't scroll

[João Guerra]

Issue no longer exists when I load your file in the end (ie. after
enabling the mode and customizing tab-line-tabs-function).

On Thu, 27 Feb 2020 at 23:39, Juri Linkov <juri@linkov.net> wrote:
>
> > 1. emacs -Q
> > 2. M-x load-file tab-line-1.el
> > 3. M-x global-tab-line-mode
> > 4. M-: (setq tab-line-tabs-function #'tab-line-tabs-mode-buffers)
> > 5. https://youtu.be/fQlrP0dlBbw
>
> Thanks, now it's clear where the problem is:
> the buffer *Messages* shows that old code is loaded,
> i.e. first you load the new file tab-line-1.el
> (the first line in the buffer *Messages*),
> but later its functions are overridden by old file
> (the third line in the buffer *Messages*).
> Only the new command 'test1' remains loaded,
> all other functions are overridden from old file
> tab-line.el.
>
> I believe this could be solved by changing the loading order:
>
> 1. emacs -Q
> 2. M-x global-tab-line-mode
>    - this will load old file tab-line.el
> 3. M-x load-file tab-line-1.el
>    - old functions will be overridden by new file tab-line-1.el
>
> Please try this.

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

> Why would we need that?  The related display code is in C, so we never
> needed to expose this to Lisp.

format-mode-line already exposes it, but fails to properly
handle its arg FACE.

> I also don't understand the relation between this question and the
> recipes you show.

format-mode-line can be used to get the same formatted string
as is displayed on the tab-line.

>> The closest function is format-mode-line but still its formatting is
>> different from what display_mode_element really displays in the
>> tab-line.
>
> Why is that a problem?  format-mode-line was not intended to be used
> in display context.

format-mode-line does the right thing for this task, but its handling
of the arg FACE is broken.

>> 1. emacs -Q
>> 2. M-x global-tab-line-mode
>>
>> 3. C-x b test1
>> 4. M-: (insert (format-mode-line (tab-line-format)))
>> 5. Note how the tab uses the face tab-line-tab
>>    with released-button box style, but the tab-line
>>    doesn't use the face tab-line
>
> I don't see tab-line-tab face, I see either tab-line-tab-inactive or
> tab-line-tab-current.  And the button style and its mouse-sensitive
> behavior follows what I see on the real tab-line.

This is correct, I meant tab-line-tab-inactive and tab-line-tab-current
that inherit from tab-line-tab.

> But maybe I don't understand what you allude to here.  What is the
> "tab" in this context, and what is "tab-line"?  You have one inserted
> into buffer text and one displayed on header-line-like tab-line --
> which one do you allude to here?  And why do you think what is
> displayed is some kind of problem?

"tab-line" visually should have an appearance defined by the face "tab-line",
i.e. grey background that can be seen at whitespace between tabs,
like in the case below.  There is no problem here.  The real problem is below.

>> 6. C-x b test2
>> 7. M-: (insert (format-mode-line (tab-line-format) 'tab-line))
>> 8. Note how the the tab-line now uses the face tab-line,
>>    but this face overrides the faces of individual tabs that
>>    should have the face tab-line-tab with released-button box style.
>
> And here I don't understand what you mean by "overrides".

Do you see the same button styles with the faces tab-line-tab-inactive and
tab-line-tab-current as in the case above like they are on the real tab-line?
These faces are lost when the arg FACE is specified.

>> I can't find a function that would insert to the current buffer
>> a string formatted exactly as the tab-line displayed
>> above the window.
>
> Why is that needed?

Actually, no other function needed.  format-mode-line does it job,
but doesn't handle its arg FACE correctly.

No wonder that handling of its arg FACE is not yet implemented.
I grepped the Emacs source code, and none of format-mode-line
function calls uses the arg FACE.

João said that everything already works, so this is
not a problem for the Emacs 27 release.

But in master format-mode-line could be fixed to implement
better merging of its arg FACE with faces already existing
on strings given in its arg FORMAT.

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

> Issue no longer exists when I load your file in the end (ie. after
> enabling the mode and customizing tab-line-tabs-function).

Thanks for checking, fix pushed.

If you want, could you try it again after the next Windows pretest will be released
(maybe after a few weeks, this is not strictly necessary, but could confirm
that there are really no more problems).

bug#39649: 27.0.60; tab-line doesn't scroll

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: joca.bt@gmail.com,  39649@debbugs.gnu.org
> Date: Sat, 29 Feb 2020 23:44:56 +0200
> 
> > Why would we need that?  The related display code is in C, so we never
> > needed to expose this to Lisp.
> 
> format-mode-line already exposes it, but fails to properly
> handle its arg FACE.

So you are saying that we already have the API exposed to Lisp, but it
(format-mode-line) doesn't work well?

> >> 6. C-x b test2
> >> 7. M-: (insert (format-mode-line (tab-line-format) 'tab-line))
> >> 8. Note how the the tab-line now uses the face tab-line,
> >>    but this face overrides the faces of individual tabs that
> >>    should have the face tab-line-tab with released-button box style.
> >
> > And here I don't understand what you mean by "overrides".
> 
> Do you see the same button styles with the faces tab-line-tab-inactive and
> tab-line-tab-current as in the case above like they are on the real tab-line?
> These faces are lost when the arg FACE is specified.

I don't think this is a bug, the code behaves as intended.  It's just
that its intent might be not what you expect, and the available
documentation doesn't help to expect what the code does.

The doc string says, inter alia:


  Optional second arg FACE specifies the face property to put on all
  characters for which no face is specified.

But what it really means is that text produced by the various
%-constructs will have FACE if the %-constructs don't provide a face.
In your case, you supply the function with a fixed string, so
specifying FACE overrides the faces you have there, see
store_mode_line_string (which is called in this case with PROPS set to
nil).

At this point let me turn the table and ask why did you need to pass
FACE to format-mode-line in your case?  What did you want to achieve?

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

>> format-mode-line already exposes it, but fails to properly
>> handle its arg FACE.
>
> So you are saying that we already have the API exposed to Lisp, but it
> (format-mode-line) doesn't work well?

Exactly.

>> Do you see the same button styles with the faces tab-line-tab-inactive and
>> tab-line-tab-current as in the case above like they are on the real tab-line?
>> These faces are lost when the arg FACE is specified.
>
> I don't think this is a bug, the code behaves as intended.  It's just
> that its intent might be not what you expect, and the available
> documentation doesn't help to expect what the code does.
>
> The doc string says, inter alia:
>
>   Optional second arg FACE specifies the face property to put on all
>   characters for which no face is specified.

It says "no face is specified", but actually the face is specified
on all characters of tabs, and the implementation doesn't follow
the documentation, e.g.:

(tab-line-format)
=>
(#(" tab1 x" 1 5 (face tab-line-tab-current)))
                       ====================

The face 'tab-line-tab-current' is on all characters, yet
(format-mode-line (tab-line-format) 'tab-line)
overwrites the face 'tab-line-tab-current' with the face 'tab-line':

(format-mode-line (tab-line-format) 'tab-line)
=>
#(" tab1 x" 1 5 (face tab-line))
                      ========

> But what it really means is that text produced by the various
> %-constructs will have FACE if the %-constructs don't provide a face.
> In your case, you supply the function with a fixed string, so
> specifying FACE overrides the faces you have there, see
> store_mode_line_string (which is called in this case with PROPS set to
> nil).

Trying to find the minimal test case, it seems working correctly
by merging faces, so there is no bug in the simplest case:

(format-mode-line (propertize "tab1" 'face 'tab-line-tab-current))
=>
#("tab1" 0 4 (face tab-line-tab-current))

(format-mode-line (propertize "tab1" 'face 'tab-line-tab-current) 'tab-line)
=>
#("tab1" 0 4 (face (tab-line-tab-current tab-line)))

In the above case tab-line-tab-current and tab-line are merged.

But the bug creeps in only when there is space between tabs:

(format-mode-line (concat " " (propertize "tab1" 'face 'tab-line-tab-current) " x"))
#(" tab1 x" 1 5 (face tab-line-tab-current))

(format-mode-line (concat " " (propertize "tab1" 'face 'tab-line-tab-current) " x") 'tab-line)
#(" tab1 x" 0 1 (face tab-line) 1 5 (face tab-line) 5 7 (face tab-line))

Here the face 'tab-line' overwrites the face 'tab-line-tab-current'.

> At this point let me turn the table and ask why did you need to pass
> FACE to format-mode-line in your case?  What did you want to achieve?

With the arg FACE it should have the same look as on the real tab-line
where tabs are placed on the line that already has the face 'tab-line'.

bug#39649: 27.0.60; tab-line doesn't scroll

[João Guerra]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

I came across something that feels a bit odd in tab-line, maybe you
can explain it.

I've been playing around with tab-line-format and noticed that what
gets displayed in the tab-line actually differs based on whether you
are using the `tab-line' face or not.

See the attached picture. Both Emacs were launched with -Q. Although
the face definition is the same in both situations the result is
different. Specially the rendered size of the characters.




On Sat, 29 Feb 2020 at 22:51, Juri Linkov <juri@linkov.net> wrote:
>
> > Issue no longer exists when I load your file in the end (ie. after
> > enabling the mode and customizing tab-line-tabs-function).
>
> Thanks for checking, fix pushed.
>
> If you want, could you try it again after the next Windows pretest will be released
> (maybe after a few weeks, this is not strictly necessary, but could confirm
> that there are really no more problems).

[-- Attachment #2: tab-line.png --]
[-- Type: image/png, Size: 49391 bytes --]

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

> I came across something that feels a bit odd in tab-line, maybe you
> can explain it.
>
> I've been playing around with tab-line-format and noticed that what
> gets displayed in the tab-line actually differs based on whether you
> are using the `tab-line' face or not.
>
> See the attached picture. Both Emacs were launched with -Q. Although
> the face definition is the same in both situations the result is
> different. Specially the rendered size of the characters.

This is how mode-line/header-line/tab-line work - they always use
hard-coded faces with names 'mode-line', 'header-line', 'tab-line',
so you can override face definitions only by customizing these faces.

bug#39649: 27.0.60; tab-line doesn't scroll

[João Guerra]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

Ok, but how does that impact the characters sizes being different?

On Thu, 5 Mar 2020, 01:22 Juri Linkov, <juri@linkov.net> wrote:

> > I came across something that feels a bit odd in tab-line, maybe you
> > can explain it.
> >
> > I've been playing around with tab-line-format and noticed that what
> > gets displayed in the tab-line actually differs based on whether you
> > are using the `tab-line' face or not.
> >
> > See the attached picture. Both Emacs were launched with -Q. Although
> > the face definition is the same in both situations the result is
> > different. Specially the rendered size of the characters.
>
> This is how mode-line/header-line/tab-line work - they always use
> hard-coded faces with names 'mode-line', 'header-line', 'tab-line',
> so you can override face definitions only by customizing these faces.
>

[-- Attachment #2: Type: text/html, Size: 1246 bytes --]

bug#39649: 27.0.60; tab-line doesn't scroll

[Juri Linkov]

> Ok, but how does that impact the characters sizes being different?

It's hard to see the differences in characters sizes.
Do you see the same problem when using colors?
For example:

(defface tab-line '((t :background "red")) "")
(defface my-tab-line '((t :background "blue")) "")
(setq tab-line-format (propertize "abcdef" 'face 'tab-line))
(setq tab-line-format (propertize "abcdef" 'face 'my-tab-line))

bug#39649: 27.0.60; tab-line doesn't scroll

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> But the bug creeps in only when there is space between tabs:
>
> (format-mode-line (concat " " (propertize "tab1" 'face
> 'tab-line-tab-current) " x"))
> #(" tab1 x" 1 5 (face tab-line-tab-current))
>
> (format-mode-line (concat " " (propertize "tab1" 'face
> 'tab-line-tab-current) " x") 'tab-line)
> #(" tab1 x" 0 1 (face tab-line) 1 5 (face tab-line) 5 7 (face tab-line))
>
> Here the face 'tab-line' overwrites the face 'tab-line-tab-current'.

The mode-line formatting machinery doesn't support having a mixture of
text properties over a single string -- for efficiency, it assumes that
the same properties are used over the entire string.  If you want
something else, you unfortunately have to use :propertize or a list of
strings.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#39649: 27.0.60; tab-line doesn't scroll

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> Issue no longer exists when I load your file in the end (ie. after
>> enabling the mode and customizing tab-line-tabs-function).
>
> Thanks for checking, fix pushed.

This bug report dealt with several somewhat related issues, but skimming
it, it seems like the reported bug was fixed.  Is there anything more to
be done here, or should this bug report be closed?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#39649: 27.0.60; tab-line doesn't scroll

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Juri Linkov <juri@linkov.net> writes:
>
>>> Issue no longer exists when I load your file in the end (ie. after
>>> enabling the mode and customizing tab-line-tabs-function).
>>
>> Thanks for checking, fix pushed.
>
> This bug report dealt with several somewhat related issues, but skimming
> it, it seems like the reported bug was fixed.  Is there anything more to
> be done here, or should this bug report be closed?

No response in three weeks, so I'm closing this bug report.  If there's
still any issues to be worked out here, perhaps opening a new bug report
would be best.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no