From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs Date: Sat, 02 Nov 2019 21:06:05 +0200 Organization: LINKOV.NET Message-ID: <874kzm2j4y.fsf@mail.linkov.net> References: <83o8yrvzgh.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> <83o8xwm484.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="162885"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) Cc: 37667@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Nov 02 20:08:10 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 1iQyks-000gF0-8d for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Nov 2019 20:08:10 +0100 Original-Received: from localhost ([::1]:50046 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iQykr-0006pC-1c for geb-bug-gnu-emacs@m.gmane.org; Sat, 02 Nov 2019 15:08:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58865) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iQykl-0006p4-8z for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2019 15:08:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iQykk-0007Ed-2o for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2019 15:08:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:52526) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iQykj-0007EY-Vl for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2019 15:08:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iQykj-0004Tl-Oo for bug-gnu-emacs@gnu.org; Sat, 02 Nov 2019 15:08:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Nov 2019 19:08:01 +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.157272167917207 (code B ref 37667); Sat, 02 Nov 2019 19:08:01 +0000 Original-Received: (at 37667) by debbugs.gnu.org; 2 Nov 2019 19:07:59 +0000 Original-Received: from localhost ([127.0.0.1]:33114 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQykh-0004TT-D7 for submit@debbugs.gnu.org; Sat, 02 Nov 2019 15:07:59 -0400 Original-Received: from dog.birch.relay.mailchannels.net ([23.83.209.48]:19558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iQyke-0004TJ-4J for 37667@debbugs.gnu.org; Sat, 02 Nov 2019 15:07:57 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E00C25010EB; Sat, 2 Nov 2019 19:07:54 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a64.g.dreamhost.com (100-96-14-250.trex.outbound.svc.cluster.local [100.96.14.250]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 17F135010B8; Sat, 2 Nov 2019 19:07:54 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Original-Received: from pdx1-sub0-mail-a64.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Sat, 02 Nov 2019 19:07:54 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Print-Eight: 52f3eb9036dfe3e1_1572721674336_3289953729 X-MC-Loop-Signature: 1572721674336:1765283495 X-MC-Ingress-Time: 1572721674336 Original-Received: from pdx1-sub0-mail-a64.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a64.g.dreamhost.com (Postfix) with ESMTP id 8DF7A84763; Sat, 2 Nov 2019 12:07:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=PKwMYPliAoeI6FY5oWRItsnK2r8=; b= 1MKuMXlKJth7W9I44NncPqcThNgodW6Ru6YquG7kddmx/3YlSGUOLmpSAladUWwa PGS0LTlsGAAc5rhd0PZL1mRJbg//Vpnu+ygoeusVQnohy7IYX6ZRhm3uALULY4QL 6uExvhj5A4b8ryKDuB6UkgLRVVRKtyS2qUx5b1dF4jM= Original-Received: from mail.jurta.org (m91-129-101-77.cust.tele2.ee [91.129.101.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 4073384760; Sat, 2 Nov 2019 12:07:47 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a64 In-Reply-To: <83o8xwm484.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 01 Nov 2019 09:43:23 +0200") 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:170842 Archived-At: >> 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. Or maybe to disable (visually using a grey shadow) the button that can't do scrolling? > . 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. Do you mean displaying the arrow on the right using fringe? Currently in buffers clicking on the fridge truncation indicator arrow image signals is undefined And on tty, fridges are not available at all. > . 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? Yes, I'd like to implement the last alternative. > The first one sounds the easiest to me. The first one is easy to implement, but it can't do auto-scrolling, i.e. when the current tab becomes invisible, automattically reduce the number of tabs in front of it to make it visible. > 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. Twice processing is not a problem: I see that pos_visible_p does processing twice as well - it calls display_mode_line before calculating whether a position is 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. Modifying display_mode_line is one way. I thought maybe simpler would be to copy some relevant code from display_mode_line to a new function.