Subject: bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

From: Eli Zaretskii <[email-masked]>
Date: Tue, 22 Oct 2019 18:16:00 +0300

> From: Juri Linkov <[email-masked]>
> Cc: [email-masked]
> Date: Tue, 22 Oct 2019 01:20:42 +0300
> 
> This is so overwhelming that I'm still struggling with understanding the
> details of the display engine.  If hscrolling was already implemented
> for the header-line, we could just copy the existing solution to the
> tab-line.

Maybe I should simply sit down and write the code for doing this.

> So I looked how packages cope with the requirement of keeping hscrolling
> of the header-line in sync with hscrolling of the buffer, and found that
> the 'proced' package uses so simple solution that we could just do
> the same.  This is what it does:
> 
> (defun proced-header-line ()
>   "Return header line for Proced buffer."
>   (list (propertize " "
>                     'display
>                     (list 'space :align-to
>                           (line-number-display-width 'columns)))
>         (if (<= (window-hscroll) (length proced-header-line))
>             (replace-regexp-in-string ;; preserve text properties
>              "\\(%\\)" "\\1\\1"
>              (substring proced-header-line (window-hscroll))))))
> 
> i.e. it just cuts scrolled content from the beginning.

But that won't work with variable-pitch fonts and with different
images for the add and close buttons, would it?  Also, doesn't
tab-line-format allow faces (which could change font size) and dynamic
elements via the likes of :eval, like mode-line does?  these would
prevent you from finding where to cut the content, no?

But if this works, by all means go ahead and install something like
that.

Thanks.