From: Eli Zaretskii <eliz@gnu.org>
To: Juri Linkov <juri@linkov.net>
Cc: 37667@debbugs.gnu.org
Subject: bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs
Date: Fri, 01 Nov 2019 09:43:23 +0200 [thread overview]
Message-ID: <83o8xwm484.fsf@gnu.org> (raw)
In-Reply-To: <87o8xwskw6.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 31 Oct 2019 22:46:49 +0200)
> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Thu, 31 Oct 2019 22:46:49 +0200
>
> Detection of truncation is necessary as a separate function to decide
> whether to display arrow buttons in the tab-line. When the tab-line
> is not truncated and displayed in its entirety, then there is no need
> to display arrow buttons for hscrolling.
>
> >> We need to detect whether the current tab is before the right truncation point
> >> (so it is visible), or after the truncation (so the current tab is not visible).
> >
> > You already keep the number of tabs you've hscrolled off the display,
> > right?
>
> Yes, the number of hscrolled tabs is kept in the window parameter.
>
> > So if you also keep the number of the current tab, the above
> > decisions become trivial, no? Or what am I missing?
>
> To get the ordinal number of the current tab is trivial indeed, but when
> due to the large number of tabs preceding the current tab on the left side
> from it, it gets pushed off-screen behind the right window edge, we need
> to set the window parameter for the number of hscrolled tabs to such
> number of tabs that will reduce the length of displayed tabs on
> the left side from the current tab, so it becomes visible again.
>
> C code is only need to calculate the number of tabs to cut on the left
> side from the current tab to make it visible.
AFAIU, there are several alternatives of how to go about the arrow
buttons that hscroll the tab-line:
. Always display both of them, but make one or both of them do
nothing when scrolling in that direction makes no sense.
. Display one arrow on the left and another on the right, and decide
whether or not to display the right one in display_mode_line,
depending on whether you hit (last_visible_x - arrow_width) while
producing glyphs.
. Add a new function, exposed to Lisp, to provide indication for
whether the right arrow will be needed, then use a proper
tab-line-format to actually display the arrow.
It sounds like you decided to use the last alternative, but did you
consider the other two? The first one sounds the easiest to me. the
last one has a disadvantage that it does the tab-line processing
twice, once to determine whether the right arrow is needed, and then
again to actually display the tab-line. Also note that adding the
right arrow will leave less screen estate for the tabs, so you need to
account for this somehow in your decision whether that arrow is
needed, lest displaying the arrow will make yet another tab partially
visible.
If you want to implement the last one, then you need a function
that calls display_mode_line and returns a truncation indication
depending on the state of it.glyph_row->truncated_on_right_p. The
simplest way to achieve that is to add a new argument to
display_mode_line, which, when non-NULL, will be a pointer to the flag
where to return to the caller the truncation indication; then make
display_mode_line set that flag according to the truncated_on_right_p
flag.
Let me know if the above makes sense, or if you have more questions.
next prev parent reply other threads:[~2019-11-01 7:43 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 18:55 bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs Eli Zaretskii
2019-10-10 22:25 ` Juri Linkov
2019-10-11 7:16 ` Eli Zaretskii
2019-10-13 22:39 ` Juri Linkov
2019-10-14 7:00 ` Eli Zaretskii
2019-10-14 21:47 ` Juri Linkov
2019-10-15 9:09 ` Eli Zaretskii
2019-10-15 18:07 ` Juri Linkov
2019-10-15 18:46 ` Eli Zaretskii
2019-10-15 19:10 ` Eli Zaretskii
2019-10-15 22:39 ` Juri Linkov
2019-10-16 16:51 ` Eli Zaretskii
2019-10-16 22:39 ` Juri Linkov
2019-10-17 7:20 ` Eli Zaretskii
2019-10-17 22:34 ` Juri Linkov
2019-10-18 6:57 ` Eli Zaretskii
2019-10-20 22:28 ` Juri Linkov
2019-10-21 7:58 ` Eli Zaretskii
2019-10-21 22:20 ` Juri Linkov
2019-10-22 15:16 ` Eli Zaretskii
2019-10-22 21:19 ` Juri Linkov
2019-10-23 16:10 ` Eli Zaretskii
2019-10-28 22:38 ` Juri Linkov
2019-10-29 12:01 ` Eli Zaretskii
2019-10-30 0:35 ` Juri Linkov
2019-10-30 15:59 ` Eli Zaretskii
2019-10-30 23:59 ` Juri Linkov
2019-10-31 14:25 ` Eli Zaretskii
2019-10-31 0:03 ` Juri Linkov
2019-10-31 14:30 ` Eli Zaretskii
2019-10-31 20:46 ` Juri Linkov
2019-11-01 7:43 ` Eli Zaretskii [this message]
2019-11-02 19:06 ` Juri Linkov
2019-11-02 19:28 ` Eli Zaretskii
2019-11-02 22:36 ` Juri Linkov
2019-11-17 21:44 ` Juri Linkov
2019-11-18 16:18 ` Eli Zaretskii
2019-11-18 21:57 ` Juri Linkov
2019-11-19 16:51 ` Eli Zaretskii
2019-11-19 22:25 ` Juri Linkov
2019-11-20 3:45 ` Eli Zaretskii
2019-11-20 22:40 ` Juri Linkov
2019-11-21 8:23 ` martin rudalics
2019-11-21 14:20 ` Eli Zaretskii
2019-11-21 21:56 ` Juri Linkov
2019-11-22 8:16 ` martin rudalics
2019-10-11 8:17 ` martin rudalics
2019-10-13 22:31 ` Juri Linkov
2019-10-14 6:51 ` Eli Zaretskii
2019-10-14 20:07 ` Juri Linkov
2019-10-14 20:22 ` Eli Zaretskii
2019-10-14 21:50 ` Juri Linkov
2019-10-15 6:26 ` Eli Zaretskii
2019-10-15 17:54 ` Juri Linkov
2019-10-16 18:14 ` martin rudalics
2019-10-16 20:58 ` Juri Linkov
2019-10-17 8:25 ` martin rudalics
2020-09-20 11:24 ` Lars Ingebrigtsen
2020-09-20 11:27 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83o8xwm484.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=37667@debbugs.gnu.org \
--cc=juri@linkov.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).