[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fix width tabs
From: |
Matthias Meulien |
Subject: |
Re: Fix width tabs |
Date: |
Mon, 21 Feb 2022 13:38:36 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) |
Juri Linkov <juri@linkov.net> writes:
>>>> If you want, you could try experimenting by writing a function
>>>> for tab-bar-tab-name-function with padding every tab name
>>>> by proportional amount of space.
>>>
>>> I'll try this. Thanks a lot!
>>
>> If you need the fixed width also for tabs with explicit names,
>> then a better option would be write a formatting function for
>> tab-bar-tab-name-format-function.
I tried the following (not trying to dynamically compute the tabs width
to start with and disabling support for close buttons):
(defun my-tab-bar-tab-name-format (tab i)
(propertize
(truncate-string-to-width
(format
(concat "%-" (number-to-string tab-bar-tab-name-truncated-max) "s")
(alist-get 'name tab))
tab-bar-tab-name-truncated-max 0 ?m t)
'face (funcall tab-bar-tab-face-function tab)))
(setq tab-bar-tab-name-format-function 'my-tab-bar-tab-name-format)
Unfortunately it doesn't play well with variable pitch font, and the
display property "min-width" isn't honored in tab-bar. I guess my naive
approach won't be sufficient...
> OTOH, I can't imagine how you could implement a formatting function
> without requiring two-pass tabs generation that is highly inefficient:
> after the first pass you get the number of tabs, groups of tabs,
> and their names. Then on the second pass you can pad names
> with required amount of space proportional to the total number of tabs.
>
> So a more efficient implementation would be to modify the strings
> that represent the tab names in the result of tab-bar-format-list
> (e.g. by using advice-add for experimentation). But a drawback is
> that then you need to rely on the details of implementation of the
> internal data structure.
I understand.
--
Matthias