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: Wed, 30 Oct 2019 17:59:57 +0200 Message-ID: <835zk6p6ki.fsf@gnu.org> References: <83o8yrvzgh.fsf@gnu.org> <83o8yjke0u.fsf@gnu.org> <87lftnqbmg.fsf@mail.linkov.net> <83h84agytj.fsf@gnu.org> <87tv89opbh.fsf@mail.linkov.net> <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> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="3743"; 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 Wed Oct 30 17:04:49 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 1iPqSm-0000oY-Fi for geb-bug-gnu-emacs@m.gmane.org; Wed, 30 Oct 2019 17:04:48 +0100 Original-Received: from localhost ([::1]:42196 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPqSj-00077W-UX for geb-bug-gnu-emacs@m.gmane.org; Wed, 30 Oct 2019 12:04:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50476) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPqPC-0003nT-KM for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2019 12:01:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iPqPB-0003cb-Dd for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2019 12:01:06 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42477) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iPqPB-0003bl-9Y for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2019 12:01:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iPqP8-0001NP-JK for bug-gnu-emacs@gnu.org; Wed, 30 Oct 2019 12:01: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: Wed, 30 Oct 2019 16:01: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.15724512081860 (code B ref 37667); Wed, 30 Oct 2019 16:01:02 +0000 Original-Received: (at 37667) by debbugs.gnu.org; 30 Oct 2019 16:00:08 +0000 Original-Received: from localhost ([127.0.0.1]:51298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iPqOF-0000TU-L4 for submit@debbugs.gnu.org; Wed, 30 Oct 2019 12:00:08 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:41168) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iPqOE-0000Nz-00 for 37667@debbugs.gnu.org; Wed, 30 Oct 2019 12:00:06 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:35660) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1iPqO7-0007vs-Vy; Wed, 30 Oct 2019 12:00:00 -0400 Original-Received: from [176.228.60.248] (port=3133 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1iPqO6-0003Im-PW; Wed, 30 Oct 2019 11:59:59 -0400 In-reply-to: <871ruvax4p.fsf@mail.linkov.net> (message from Juri Linkov on Wed, 30 Oct 2019 02:35:18 +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:170424 Archived-At: > From: Juri Linkov > Cc: 37667@debbugs.gnu.org > Date: Wed, 30 Oct 2019 02:35:18 +0200 > > > it.glyph_row->full_width_p = true; > > it.glyph_row->continued_p = false; > > it.glyph_row->truncated_on_left_p = false; > > it.glyph_row->truncated_on_right_p = false; > > > > I think you will find that before the last two lines are executed, the > > truncated_on_right_p flag is set for the tab-line in your example. > > > > I think we need to make a change there to not reset the last 2 flags > > when we are displaying the tab-line. (The full_width_p flag should > > still be set, because we don't want margin areas on the tab-line.) > > I tried to not reset these flags only for the tab-line, and indeed > when the tab-line is truncated, then truncated_on_right_p is true > most of the time, but not always. It's false when the tab-line > is truncated between tabs. > > AFAIU by looking at 'display_string', it looks like this has something > to do with whitespace between tabs as this comment explains: > > /* Add truncation mark, but don't do it if the line is > truncated at a padding space. */ I don't think this is the reason, because AFAICT tab-line-format doesn't include constructs that would pad its elements with spaces. Can you cook up a simple recipe where the truncation bitmaps don't appear, and also show the patch you used not to reset those flags? I'd like to look into what happens in the code in that case. > I don't want to modify display_string to take the tab-line > into account because more logic for searching the current tab > needs to be implemented anyway. Searching the current tab and displaying truncation indicators are two separate tasks that don't necessarily need the same (or even similar) code. The former could be found much easier, I think. > So maybe better to copy code from display_string to a new function > tab_visible_in_tab_line, and beside detection of truncation also add > more code to detect a situation when the current tab is not visible > due to truncation. I don't think these two jobs are similar enough, but maybe I don't understand well enough what you have in mind. Can you elaborate how you intended to search for the current tab? > One thing that I don't understand where a function similar to > display_string will produce glyphs? It should not touch the > real tab-line. It should only check if the produced glyphs > push the current tab out of view. If you don't want the display code to produce glyphs, you should arrange for it->glyph_row to be a NULL pointer. See the call to init_iterator inside format-mode-line to understand how this is done. That function has the same problem as what you describe above.