From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs Date: Fri, 01 Nov 2019 09:43:23 +0200 Message-ID: <83o8xwm484.fsf@gnu.org> References: <83o8yrvzgh.fsf@gnu.org> <83mue1g845.fsf@gnu.org> <83lftlg6zc.fsf@gnu.org> <87lftlk504.fsf@mail.linkov.net> <83eezceir2.fsf@gnu.org> <87pniwuwj5.fsf@mail.linkov.net> <83blufdehy.fsf@gnu.org> <878spj57dk.fsf@mail.linkov.net> <83v9sm8rs3.fsf@gnu.org> <87blubaw63.fsf@mail.linkov.net> <83zhhu34xz.fsf@gnu.org> <8736fl91vp.fsf@mail.linkov.net> <834l0024lr.fsf@gnu.org> <87eez4pjfk.fsf@mail.linkov.net> <83ftjjzbln.fsf@gnu.org> <87d0egpjec.fsf@mail.linkov.net> <83sgnbpxq6.fsf@gnu.org> <871ruvax4p.fsf@mail.linkov.net> <835zk6p6ki.fsf@gnu.org> <87v9s53h6o.fsf@mail.linkov.net> <83imo5ng1d.fsf@gnu.org> <87o8xwskw6.fsf@mail.linkov.net> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="153876"; mail-complaints-to="usenet@blaine.gmane.org" Cc: 37667@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Nov 01 08:44:21 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iQRbY-000dsT-PP for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Nov 2019 08:44:20 +0100 Original-Received: from localhost ([::1]:57048 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iQRbX-0003r4-L8 for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Nov 2019 03:44:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45263) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iQRbI-0003qs-6X for bug-gnu-emacs@gnu.org; Fri, 01 Nov 2019 03:44:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iQRbG-0007Cc-Qo for bug-gnu-emacs@gnu.org; Fri, 01 Nov 2019 03:44:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46153) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iQRbG-0007CY-Ks for bug-gnu-emacs@gnu.org; Fri, 01 Nov 2019 03:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iQRbG-0004SD-IR for bug-gnu-emacs@gnu.org; Fri, 01 Nov 2019 03:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Nov 2019 07:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37667 X-GNU-PR-Package: emacs Original-Received: via spool by 37667-submit@debbugs.gnu.org id=B37667.157259421017069 (code B ref 37667); Fri, 01 Nov 2019 07:44:02 +0000 Original-Received: (at 37667) by debbugs.gnu.org; 1 Nov 2019 07:43:30 +0000 Original-Received: from localhost ([127.0.0.1]:54974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQRak-0004RF-6s for submit@debbugs.gnu.org; Fri, 01 Nov 2019 03:43:30 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:36086) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQRai-0004Qz-Mk for 37667@debbugs.gnu.org; Fri, 01 Nov 2019 03:43:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:41085) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iQRac-0006SM-01; Fri, 01 Nov 2019 03:43:22 -0400 Original-Received: from [176.228.60.248] (port=1699 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iQRab-0007C4-E2; Fri, 01 Nov 2019 03:43:21 -0400 In-reply-to: <87o8xwskw6.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 31 Oct 2019 22:46:49 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:170580 Archived-At: > From: Juri Linkov > 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.