bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs
Date: Tue, 22 Oct 2019 18:16:00 +0300

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]