bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

To reproduce, invoke Emacs from the src directory:

  ./emacs -Q

and then type:

  C-x 6 f xdisp.c RET
  C-x 6 f dispnew.c RET
  C-x 6 f dispextern.h RET
  C-x 6 f window.c RET
  C-x 6 f frame.c RET

The 6th button is displayed partially on the 1st tab-bar line, and the
rest on the 2nd line, which I don't think is pretty.

If you do the same in a -nw session, the 6th tab will not be visible
at all (it looks like display_tab_bar assumes there's always just one
tab-bar line?).


In GNU Emacs 27.0.50 (build 1485, i686-pc-mingw32)
 of 2019-10-08 built on HOME-C4E4A596F7
Repository revision: f96b8fd27c382a941c52c2938544b9b0e3a2fb0e
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
C-x 6 <up> is undefined
C-x <tab-bar> is undefined
<tab-3> is undefined

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int --with-modules
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: C/*l

Minor modes in effect:
  bug-reference-prog-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  tab-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny format-spec rfc822 mml
mml-sec password-cache epa derived epg epg-config gnus-util rmail
rmail-loaddefs text-property-search time-date subr-x seq byte-opt gv
bytecomp byte-compile cconv mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils dired dired-loaddefs vc-git
diff-mode easy-mmode bug-reference cc-mode cc-fonts easymenu cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs
cl-loaddefs cl-lib tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 102411 7725)
 (symbols 48 10315 1)
 (strings 16 26738 2116)
 (string-bytes 1 886304)
 (vectors 16 13502)
 (vector-slots 8 175153 9830)
 (floats 8 33 243)
 (intervals 40 6259 190)
 (buffers 888 17))

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

> To reproduce, invoke Emacs from the src directory:
>
>   ./emacs -Q
>
> and then type:
>
>   C-x 6 f xdisp.c RET
>   C-x 6 f dispnew.c RET
>   C-x 6 f dispextern.h RET
>   C-x 6 f window.c RET
>   C-x 6 f frame.c RET
>
> The 6th button is displayed partially on the 1st tab-bar line, and the
> rest on the 2nd line, which I don't think is pretty.
>
> If you do the same in a -nw session, the 6th tab will not be visible
> at all (it looks like display_tab_bar assumes there's always just one
> tab-bar line?).

What are the possible options?

1. Use something like word-wrap in the tab-bar to wrap
   to the second line non-broken tabs at tab boundaries;

2. Disable wrapping to the second line since it's not supported in -nw;

3. Then truncate tab names to fit all tabs into the first line;

4. Or don't truncate but allow scrolling tabs with mouse wheel;

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Fri, 11 Oct 2019 01:25:32 +0300
> 
> >   C-x 6 f xdisp.c RET
> >   C-x 6 f dispnew.c RET
> >   C-x 6 f dispextern.h RET
> >   C-x 6 f window.c RET
> >   C-x 6 f frame.c RET
> >
> > The 6th button is displayed partially on the 1st tab-bar line, and the
> > rest on the 2nd line, which I don't think is pretty.
> >
> > If you do the same in a -nw session, the 6th tab will not be visible
> > at all (it looks like display_tab_bar assumes there's always just one
> > tab-bar line?).
> 
> What are the possible options?
> 
> 1. Use something like word-wrap in the tab-bar to wrap
>    to the second line non-broken tabs at tab boundaries;

Yes, that's a possibility and shouldn't be hard to implement.

> 2. Disable wrapping to the second line since it's not supported in -nw;

Why isn't it supported on TTY frames, btw?  It seemed to me that the
infrastructure is there, i.e. we can have FRAME_TAB_BAR_LINES(f) > 1,
it's just that the code doesn't consider this possibility.

> 3. Then truncate tab names to fit all tabs into the first line;

This is not scalable.

> 4. Or don't truncate but allow scrolling tabs with mouse wheel;

Yes, this could work as well (but scrolling should be possible not
only with the mouse).  The implementation could simply hscroll the
tab-bar window, including automatic hscrolling when the current tab is
far from the leftmost one.  Maybe this alternative is the easiest
one.  The only difficulty here is with TTY frames.

Thanks.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> 1. Use something like word-wrap in the tab-bar to wrap
>>    to the second line non-broken tabs at tab boundaries;
>
> Yes, that's a possibility and shouldn't be hard to implement.

I'd like to keep the tab-bar multi-line.  No other application has
multi-line tab-bar - no web browsers, no other editors.  This could be
a unique Emacs feature that allows easier tab switching without
truncating tab names like web browsers do.  Even now it looks good,
but could be improved to wrap tabs better.

>> 2. Disable wrapping to the second line since it's not supported in -nw;
>
> Why isn't it supported on TTY frames, btw?  It seemed to me that the
> infrastructure is there, i.e. we can have FRAME_TAB_BAR_LINES(f) > 1,
> it's just that the code doesn't consider this possibility.

Is it possible for TTY frames to use the same code that implements
wrapping in multi-line tab-bar on graphical displays?

>> 3. Then truncate tab names to fit all tabs into the first line;
>
> This is not scalable.

I see that no one likes truncation of tab names.  Maybe this is because
buffer names in Emacs usually are not too long.

>> 4. Or don't truncate but allow scrolling tabs with mouse wheel;
>
> Yes, this could work as well (but scrolling should be possible not
> only with the mouse).  The implementation could simply hscroll the
> tab-bar window, including automatic hscrolling when the current tab is
> far from the leftmost one.  Maybe this alternative is the easiest
> one.  The only difficulty here is with TTY frames.

Maybe after adding a new option that disables multi-line
so tabs are displayed on one line, hscrolling could help
to center around the current tab.

5. There is another alternative: display arrow buttons on both sides
   of the tab-bar, clicking on arrows will hscroll tabs.

6. Or even better: clicking on such arrow buttons will pop up a menu of
   remaining tabs that don't fit into one-line tab-bar.
   This is like implemented recently for Info-history where clicking on
   the tool-bar arrow pops up a menu of previous Info nodes.  The same way
   clicking on the arrows on the tab-bar could pop up a menu of tabs whose
   names don't fit into the one-line tab-bar at both sides of the current tab.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Mon, 14 Oct 2019 01:39:28 +0300
> 
> >> 2. Disable wrapping to the second line since it's not supported in -nw;
> >
> > Why isn't it supported on TTY frames, btw?  It seemed to me that the
> > infrastructure is there, i.e. we can have FRAME_TAB_BAR_LINES(f) > 1,
> > it's just that the code doesn't consider this possibility.
> 
> Is it possible for TTY frames to use the same code that implements
> wrapping in multi-line tab-bar on graphical displays?

I don't think I understand the question.  Which details of wrapping
multi-line tab bars seem to prevent doing the same on TTY frames?

> >> 4. Or don't truncate but allow scrolling tabs with mouse wheel;
> >
> > Yes, this could work as well (but scrolling should be possible not
> > only with the mouse).  The implementation could simply hscroll the
> > tab-bar window, including automatic hscrolling when the current tab is
> > far from the leftmost one.  Maybe this alternative is the easiest
> > one.  The only difficulty here is with TTY frames.
> 
> Maybe after adding a new option that disables multi-line
> so tabs are displayed on one line, hscrolling could help
> to center around the current tab.

I think if we keep using multi-line tab bars, we don't need to
complicate things by hscrolling.  Not yet, anyway.

> 5. There is another alternative: display arrow buttons on both sides
>    of the tab-bar, clicking on arrows will hscroll tabs.

On GUI frames, you get this for free by using the hscrolling machinery
and line truncation.

> 6. Or even better: clicking on such arrow buttons will pop up a menu of
>    remaining tabs that don't fit into one-line tab-bar.
>    This is like implemented recently for Info-history where clicking on
>    the tool-bar arrow pops up a menu of previous Info nodes.  The same way
>    clicking on the arrows on the tab-bar could pop up a menu of tabs whose
>    names don't fit into the one-line tab-bar at both sides of the current tab.

I'd leave such fancy features for future releases.  Remember: we are
waiting for this and other new features to reach some reasonable state
in order to start the Emacs 27 release cycle.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> >> 2. Disable wrapping to the second line since it's not supported in -nw;
>> >
>> > Why isn't it supported on TTY frames, btw?  It seemed to me that the
>> > infrastructure is there, i.e. we can have FRAME_TAB_BAR_LINES(f) > 1,
>> > it's just that the code doesn't consider this possibility.
>>
>> Is it possible for TTY frames to use the same code that implements
>> wrapping in multi-line tab-bar on graphical displays?
>
> I don't think I understand the question.  Which details of wrapping
> multi-line tab bars seem to prevent doing the same on TTY frames?

I meant using the existing function tab_bar_height whose value increases
FRAME_TAB_BAR_LINES, but TTY doesn't use FRAME_TAB_BAR_LINES.

>> 5. There is another alternative: display arrow buttons on both sides
>>    of the tab-bar, clicking on arrows will hscroll tabs.
>
> On GUI frames, you get this for free by using the hscrolling machinery
> and line truncation.

What is needed to enable it?  Does hscrolling depend on the position of point
so point should be moved to the current tab to center other tabs around it?

Also I tried to insert newlines in the tab-bar string, without success.

>> 6. Or even better: clicking on such arrow buttons will pop up a menu of
>>    remaining tabs that don't fit into one-line tab-bar.
>>    This is like implemented recently for Info-history where clicking on
>>    the tool-bar arrow pops up a menu of previous Info nodes.  The same way
>>    clicking on the arrows on the tab-bar could pop up a menu of tabs whose
>>    names don't fit into the one-line tab-bar at both sides of the current tab.
>
> I'd leave such fancy features for future releases.  Remember: we are
> waiting for this and other new features to reach some reasonable state
> in order to start the Emacs 27 release cycle.

This is the simplest and quickest option to implement.  For Info-history
it took just 20 lines of Lisp code.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Tue, 15 Oct 2019 00:47:51 +0300
> 
> >> >> 2. Disable wrapping to the second line since it's not supported in -nw;
> >> >
> >> > Why isn't it supported on TTY frames, btw?  It seemed to me that the
> >> > infrastructure is there, i.e. we can have FRAME_TAB_BAR_LINES(f) > 1,
> >> > it's just that the code doesn't consider this possibility.
> >>
> >> Is it possible for TTY frames to use the same code that implements
> >> wrapping in multi-line tab-bar on graphical displays?
> >
> > I don't think I understand the question.  Which details of wrapping
> > multi-line tab bars seem to prevent doing the same on TTY frames?
> 
> I meant using the existing function tab_bar_height whose value increases
> FRAME_TAB_BAR_LINES, but TTY doesn't use FRAME_TAB_BAR_LINES.

tab_bar_height calls display_tab_bar_line, which is not used on TTY
frames.  We could make display_tab_bar_line work on TTY frames, but
then the question becomes why have a separate display_tab_bar function
for TTY frames instead of making redisplay_tab_bar support TTY frames
as well.

IOW, refactoring the code to have just one set of functions for both
types of frames would make sense, but we should refactor all of it,
not just a single function.

> >> 5. There is another alternative: display arrow buttons on both sides
> >>    of the tab-bar, clicking on arrows will hscroll tabs.
> >
> > On GUI frames, you get this for free by using the hscrolling machinery
> > and line truncation.
> 
> What is needed to enable it?

Add hscrolling support for pseudo-windows, I think.  It could start
with a specialized function to hscroll just the tab-bar, then the code
could just start displaying the tab-bar window starting at a button
that is not necessarily the first one.

> Does hscrolling depend on the position of point so point should be
> moved to the current tab to center other tabs around it?

I was talking about the truncation glyphs and clicking on them, not
about automatic hscrolling when point gets too close to the window
edge.

> Also I tried to insert newlines in the tab-bar string, without success.

Not sure I understand this part.  Why did you need to add newlines,
and what didn't work when you tried?

> >> 6. Or even better: clicking on such arrow buttons will pop up a menu of
> >>    remaining tabs that don't fit into one-line tab-bar.
> >>    This is like implemented recently for Info-history where clicking on
> >>    the tool-bar arrow pops up a menu of previous Info nodes.  The same way
> >>    clicking on the arrows on the tab-bar could pop up a menu of tabs whose
> >>    names don't fit into the one-line tab-bar at both sides of the current tab.
> >
> > I'd leave such fancy features for future releases.  Remember: we are
> > waiting for this and other new features to reach some reasonable state
> > in order to start the Emacs 27 release cycle.
> 
> This is the simplest and quickest option to implement.  For Info-history
> it took just 20 lines of Lisp code.

The code could be small, but it will probably lead us down a rabbit
hole of more discussions, bug reports and feature requests, yet more
discussions, etc.  I'd like to stabilize this feature soon at some
reasonable point and leave the rest to future releases.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

> tab_bar_height calls display_tab_bar_line, which is not used on TTY
> frames.  We could make display_tab_bar_line work on TTY frames, but
> then the question becomes why have a separate display_tab_bar function
> for TTY frames instead of making redisplay_tab_bar support TTY frames
> as well.
>
> IOW, refactoring the code to have just one set of functions for both
> types of frames would make sense, but we should refactor all of it,
> not just a single function.

I have one question: why menu-bar wrapping was not implemented on
TTY frames so far, why the design decision was to always truncate it?

This illustrates the question of how the menu-bar is truncated
whereas text in buffers is wrapped:


[-- Attachment #2: tty-menu-bar-truncated.png --]
[-- Type: image/png, Size: 10712 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2646 bytes --]


Maybe for the same reason why currently the menu-bar is one-line,
the tab-bar should be one-line on TTY frames.

For the same reason the header-line is one-line too, so the tab-line
should be one-line too.  This means that we still need to find
a solution how to scroll tabs on one line.

> Add hscrolling support for pseudo-windows, I think.  It could start
> with a specialized function to hscroll just the tab-bar, then the code
> could just start displaying the tab-bar window starting at a button
> that is not necessarily the first one.

Since it's not clear how to do refactoring for multi-line tab-bar on TTY
and for multi-line tab-line, I'm going to explore the hscrolling option.

>> Does hscrolling depend on the position of point so point should be
>> moved to the current tab to center other tabs around it?
>
> I was talking about the truncation glyphs and clicking on them, not
> about automatic hscrolling when point gets too close to the window
> edge.

I started to implement adding truncation arrow buttons at both sides of
the one-line tab-bar, clicking on them will hscroll the tab-bar.

>> Also I tried to insert newlines in the tab-bar string, without success.
>
> Not sure I understand this part.  Why did you need to add newlines,
> and what didn't work when you tried?

I tried to add newlines between tabs to force moving the wrapped tab
to the beginning of the next line on multi-line tab-bar.

>> >> 6. Or even better: clicking on such arrow buttons will pop up a menu of
>> >>    remaining tabs that don't fit into one-line tab-bar.
>> >>    This is like implemented recently for Info-history where clicking on
>> >>    the tool-bar arrow pops up a menu of previous Info nodes.  The same way
>> >>    clicking on the arrows on the tab-bar could pop up a menu of tabs whose
>> >>    names don't fit into the one-line tab-bar at both sides of the current tab.
>> >
>> > I'd leave such fancy features for future releases.  Remember: we are
>> > waiting for this and other new features to reach some reasonable state
>> > in order to start the Emacs 27 release cycle.
>>
>> This is the simplest and quickest option to implement.  For Info-history
>> it took just 20 lines of Lisp code.
>
> The code could be small, but it will probably lead us down a rabbit
> hole of more discussions, bug reports and feature requests, yet more
> discussions, etc.  I'd like to stabilize this feature soon at some
> reasonable point and leave the rest to future releases.

Firefox provides both options at the same time: two arrow buttons to
hscroll tabs, and one dropdown button to pop up a menu of tabs.
It's easy to implement both.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Tue, 15 Oct 2019 21:07:14 +0300
> 
> I have one question: why menu-bar wrapping was not implemented on
> TTY frames so far, why the design decision was to always truncate it?

Most probably because the number of items on the menu bar is usually
small, unlike the number of tabs that can grow very large.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> Date: Tue, 15 Oct 2019 21:46:02 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 37667@debbugs.gnu.org
> 
> > From: Juri Linkov <juri@linkov.net>
> > Cc: 37667@debbugs.gnu.org
> > Date: Tue, 15 Oct 2019 21:07:14 +0300
> > 
> > I have one question: why menu-bar wrapping was not implemented on
> > TTY frames so far, why the design decision was to always truncate it?
> 
> Most probably because the number of items on the menu bar is usually
> small, unlike the number of tabs that can grow very large.

Also, the menu bar on TTY frames originally was just a decoration: you
couldn't do anything with it except look.  So it made little sense to
invest in wrapping that line.  Drop-down menus on TTY frames are a
relatively recent addition, since Emacs 24.4.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> > I have one question: why menu-bar wrapping was not implemented on
>> > TTY frames so far, why the design decision was to always truncate it?
>> 
>> Most probably because the number of items on the menu bar is usually
>> small, unlike the number of tabs that can grow very large.
>
> Also, the menu bar on TTY frames originally was just a decoration: you
> couldn't do anything with it except look.  So it made little sense to
> invest in wrapping that line.  Drop-down menus on TTY frames are a
> relatively recent addition, since Emacs 24.4.

I've started with implementing hscrolling for window tab-line
because this is needed for both graphical displays and TTY.

But the first question popped up quickly: I don't understand
how to detect the situation where the tab-line is truncated?
And how to find the tab that is visible partially?
Especially when the font is variable-pitch.

What I'm trying to do is to hide leftmost tabs one by one until
the current tab on the rightmost side becomes completely visible.
Please advise.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Wed, 16 Oct 2019 01:39:39 +0300
> 
> I've started with implementing hscrolling for window tab-line
> because this is needed for both graphical displays and TTY.

Thanks.

> But the first question popped up quickly: I don't understand
> how to detect the situation where the tab-line is truncated?

The situation that it's truncated, or the situation that it _needs_ to
be truncated, i.e. the next tab doesn't fit on the line?

If the former, the glyph_row->truncated_on_right_p flag should be set.
You can see it being set in display_string, which is called from
display_mode_line.

If you mean the latter, then look how the truncated_on_right_p flag is
being set in display_line or in other similar display functions, like
display_tab_bar_line.

> And how to find the tab that is visible partially?
> Especially when the font is variable-pitch.

I think you will need to walk the glyphs in the tab-line looking for
the last glyph whose character position has the property you put on
tabs in tab-line (as specified in by tab-line-format).  Or maybe
tab-line-format should put some special property on the last glyph of
a tab, so that you could look for it more easily?

Let me know if the above is not detailed enough to get you off the
ground.

> What I'm trying to do is to hide leftmost tabs one by one until
> the current tab on the rightmost side becomes completely visible.

That will work, but it's inefficient.  Once you know the number N of
pixels are needed to show the tab you want to unhide, just walk the
glyphs of the tabs from the left edge until you find the first tab
whose horizontal position M is greater or equal to N.  then set
it->first_visible_x to that number M and display the tab line.

HTH

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> But the first question popped up quickly: I don't understand
>> how to detect the situation where the tab-line is truncated?
>
> The situation that it's truncated, or the situation that it _needs_ to
> be truncated, i.e. the next tab doesn't fit on the line?
>
> If the former, the glyph_row->truncated_on_right_p flag should be set.
> You can see it being set in display_string, which is called from
> display_mode_line.
>
> If you mean the latter, then look how the truncated_on_right_p flag is
> being set in display_line or in other similar display functions, like
> display_tab_bar_line.
>
>> And how to find the tab that is visible partially?
>> Especially when the font is variable-pitch.
>
> I think you will need to walk the glyphs in the tab-line looking for
> the last glyph whose character position has the property you put on
> tabs in tab-line (as specified in by tab-line-format).  Or maybe
> tab-line-format should put some special property on the last glyph of
> a tab, so that you could look for it more easily?
>
> Let me know if the above is not detailed enough to get you off the
> ground.

Thanks for the explanation.  One thing that I still don't understand is
how to find the exact position in the mode-line string where it's
truncated.  For example, in the string "...abc|xyz", the part
until "abc" is visible, but the rest of the string is truncated,
so "xyz" is not visible.  How to find this position where truncation occurs?

Actually, it seems I found it, it's it.last_visible_x.  Is this correct?

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Thu, 17 Oct 2019 01:39:27 +0300
> 
> Thanks for the explanation.  One thing that I still don't understand is
> how to find the exact position in the mode-line string where it's
> truncated.  For example, in the string "...abc|xyz", the part
> until "abc" is visible, but the rest of the string is truncated,
> so "xyz" is not visible.  How to find this position where truncation occurs?

You should look for that in the glyphs, not in the string you want to
display.

> Actually, it seems I found it, it's it.last_visible_x.  Is this correct?

it.last_visible_x is the first pixel that is _outside_ of the
viewport.  The last pixel that is still visible has X coordinate one
less than that.

Also note that when a screen line (a.k.a. "glyph row") is hscrolled,
its display doesn't starts when it.current_x is zero, it starts when
it.current_x is it.first_visible_x.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> Thanks for the explanation.  One thing that I still don't understand is
>> how to find the exact position in the mode-line string where it's
>> truncated.  For example, in the string "...abc|xyz", the part
>> until "abc" is visible, but the rest of the string is truncated,
>> so "xyz" is not visible.  How to find this position where truncation occurs?
>
> You should look for that in the glyphs, not in the string you want to
> display.
>
>> Actually, it seems I found it, it's it.last_visible_x.  Is this correct?
>
> it.last_visible_x is the first pixel that is _outside_ of the
> viewport.  The last pixel that is still visible has X coordinate one
> less than that.
>
> Also note that when a screen line (a.k.a. "glyph row") is hscrolled,
> its display doesn't starts when it.current_x is zero, it starts when
> it.current_x is it.first_visible_x.

It seems before implementing this, first we need to decide
what UI we could provide.  This decision affects a set of commands
that needs to be implemented for tab-line hscrolling.

One variant is to allow dragging the tab-line by mouse where
dragging to the left will scroll the tab-line to the left.
But actually no web browser implements this behavior, they use
dragging to move a tab to other place.

So maybe better to have two arrow buttons: clicking on the left arrow
will hscroll to the left.

Then we need two commands implemented in C: 'tab-line-scroll-left'
and 'tab-line-scroll-right'.  And later to add some keys like
'C-x >' bound to 'scroll-left'.

These commands could work for the tab-line like hscrolling
in the buffer works when 'auto-hscroll-mode' is 'current-line'.
Also their ARG could be like in 'scroll-left' where the default ARG
is window width minus 2.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Fri, 18 Oct 2019 01:34:15 +0300
> 
> It seems before implementing this, first we need to decide
> what UI we could provide.  This decision affects a set of commands
> that needs to be implemented for tab-line hscrolling.
> 
> One variant is to allow dragging the tab-line by mouse where
> dragging to the left will scroll the tab-line to the left.
> But actually no web browser implements this behavior, they use
> dragging to move a tab to other place.
> 
> So maybe better to have two arrow buttons: clicking on the left arrow
> will hscroll to the left.

Agreed.  As we already have fringe bitmaps to show truncation both on
the left and on the right, arranging for them to be displayed for
tab-lines will allow us to bind clicking on these to scrolling
commands.

> Then we need two commands implemented in C: 'tab-line-scroll-left'
> and 'tab-line-scroll-right'.  And later to add some keys like
> 'C-x >' bound to 'scroll-left'.
> 
> These commands could work for the tab-line like hscrolling
> in the buffer works when 'auto-hscroll-mode' is 'current-line'.

There's an important difference, I think: you want to scroll the
tab-line in tab-button granularity, not one character at a time.  But
the principle and the main idea is the same, yes.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> It seems before implementing this, first we need to decide
>> what UI we could provide.  This decision affects a set of commands
>> that needs to be implemented for tab-line hscrolling.
>>
>> One variant is to allow dragging the tab-line by mouse where
>> dragging to the left will scroll the tab-line to the left.
>> But actually no web browser implements this behavior, they use
>> dragging to move a tab to other place.
>>
>> So maybe better to have two arrow buttons: clicking on the left arrow
>> will hscroll to the left.
>
> Agreed.  As we already have fringe bitmaps to show truncation both on
> the left and on the right, arranging for them to be displayed for
> tab-lines will allow us to bind clicking on these to scrolling
> commands.

Trying to click on truncation arrows in fringe bitmaps of buffers signals:

  <right-fringe> <mouse-1> is undefined

So we need to bind <mouse-1> to a tab-line scrolling command
for [tab-line right-fringe] keymap?

Or maybe the tab-line could be dragged like dragging the
horizontal scroll bar in horizontal-scroll-bar-mode?

Or mouse-wheel could scroll the whole tab-line horizontally
instead of switching tabs like it does now?

>> Then we need two commands implemented in C: 'tab-line-scroll-left'
>> and 'tab-line-scroll-right'.  And later to add some keys like
>> 'C-x >' bound to 'scroll-left'.
>>
>> These commands could work for the tab-line like hscrolling
>> in the buffer works when 'auto-hscroll-mode' is 'current-line'.
>
> There's an important difference, I think: you want to scroll the
> tab-line in tab-button granularity, not one character at a time.  But
> the principle and the main idea is the same, yes.

I thought that granularity should be wider: scrolling by the window width,
like 'C-x >' ('scroll-right') does, where default is window width minus 2.
But maybe tab-button granularity is fine.  The only problem is that
I still studying the code to understand where to begin.  Could you suggest
in what function to implement all this scrolling?

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Mon, 21 Oct 2019 01:28:52 +0300
> 
> > Agreed.  As we already have fringe bitmaps to show truncation both on
> > the left and on the right, arranging for them to be displayed for
> > tab-lines will allow us to bind clicking on these to scrolling
> > commands.
> 
> Trying to click on truncation arrows in fringe bitmaps of buffers signals:
> 
>   <right-fringe> <mouse-1> is undefined
> 
> So we need to bind <mouse-1> to a tab-line scrolling command
> for [tab-line right-fringe] keymap?

Either that, or bind the click on the fringe to a command that looks
at posn-area of the click event, and scrolls the tab-line of the area
is tab-line.

> Or maybe the tab-line could be dragged like dragging the
> horizontal scroll bar in horizontal-scroll-bar-mode?

That would prevent using the drag events for something else, like
reordering the tabs.  It is also not what other applications do,
right?

> Or mouse-wheel could scroll the whole tab-line horizontally
> instead of switching tabs like it does now?

That could be an additional feature, but it cannot be the only one, I
think, because some mice have no wheel.

> >> These commands could work for the tab-line like hscrolling
> >> in the buffer works when 'auto-hscroll-mode' is 'current-line'.
> >
> > There's an important difference, I think: you want to scroll the
> > tab-line in tab-button granularity, not one character at a time.  But
> > the principle and the main idea is the same, yes.
> 
> I thought that granularity should be wider: scrolling by the window width,
> like 'C-x >' ('scroll-right') does, where default is window width minus 2.

I think this would be less convenient.

> But maybe tab-button granularity is fine.  The only problem is that
> I still studying the code to understand where to begin.  Could you suggest
> in what function to implement all this scrolling?

I think you will need a new function.  A tab-line is generated from a
Lisp string, and we don't have code for hscrolling screen lines
produced from strings (as opposed to from buffer text).

The general idea is to identify the first (leftmost) tab you want to
be visible, and then make changes in display_mode_line to start
display from that tab.  I think the first part is the more complex of
these two.  format-mode-line shows an example of how to generate
display derived from Lisp and C strings without displaying anything;
you could use that for finding the X coordinate (in it.current_x) of
the beginning of the Nth tab's button.  Each click on the right fringe
increases N, each click on the left decreases it.  The X coordinate
you compute is the value to use for it.first_visible_x in
display_mode_line.

I hope this makes enough sense to get you going.  If not, please ask
more specific questions.

Thanks.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> But maybe tab-button granularity is fine.  The only problem is that
>> I still studying the code to understand where to begin.  Could you suggest
>> in what function to implement all this scrolling?
>
> I think you will need a new function.  A tab-line is generated from a
> Lisp string, and we don't have code for hscrolling screen lines
> produced from strings (as opposed to from buffer text).
>
> The general idea is to identify the first (leftmost) tab you want to
> be visible, and then make changes in display_mode_line to start
> display from that tab.  I think the first part is the more complex of
> these two.  format-mode-line shows an example of how to generate
> display derived from Lisp and C strings without displaying anything;
> you could use that for finding the X coordinate (in it.current_x) of
> the beginning of the Nth tab's button.  Each click on the right fringe
> increases N, each click on the left decreases it.  The X coordinate
> you compute is the value to use for it.first_visible_x in
> display_mode_line.

This is so overwhelming that I'm still struggling with understanding the
details of the display engine.  If hscrolling was already implemented
for the header-line, we could just copy the existing solution to the
tab-line.

So I looked how packages cope with the requirement of keeping hscrolling
of the header-line in sync with hscrolling of the buffer, and found that
the 'proced' package uses so simple solution that we could just do
the same.  This is what it does:

(defun proced-header-line ()
  "Return header line for Proced buffer."
  (list (propertize " "
                    'display
                    (list 'space :align-to
                          (line-number-display-width 'columns)))
        (if (<= (window-hscroll) (length proced-header-line))
            (replace-regexp-in-string ;; preserve text properties
             "\\(%\\)" "\\1\\1"
             (substring proced-header-line (window-hscroll))))))

i.e. it just cuts scrolled content from the beginning.

Adapting the same idea to the tab-line provides the workable and
reliable solution with just a dozen lines of Lisp code.  You can
evaluate this, and everything works smoothly:

(advice-add 'tab-line-format :around
            (lambda (orig-fun)
              (let ((tabs (funcall orig-fun))
                    (hscroll (window-parameter nil 'hscroll)))
                (if hscroll (nthcdr hscroll tabs) tabs)))
            '((name . tab-line-format-hscroll)))

(defun tab-line-hscroll (&optional arg window)
  (let* ((hscroll (window-parameter window 'hscroll)))
    (set-window-parameter
     window 'hscroll (max 0 (min (+ (or hscroll 0) (or arg 1))
                                 (1- (length (funcall tab-line-tabs-function))))))))

(defun tab-line-hscroll-left (&optional arg mouse-event)
  (interactive (list current-prefix-arg last-nonmenu-event))
  (tab-line-hscroll arg (and (listp mouse-event) (posn-window (event-start mouse-event))))
  (force-mode-line-update))

(defun tab-line-hscroll-right (&optional arg mouse-event)
  (interactive (list current-prefix-arg last-nonmenu-event))
  (tab-line-hscroll (- (or arg 1)) (and (listp mouse-event) (posn-window (event-start mouse-event))))
  (force-mode-line-update))

(global-set-key [tab-line mouse-4] 'tab-line-hscroll-left)
(global-set-key [tab-line mouse-5] 'tab-line-hscroll-right)
(global-set-key [tab-line wheel-up] 'tab-line-hscroll-left)
(global-set-key [tab-line wheel-down] 'tab-line-hscroll-right)

Thus mouse-wheel hscrolls the tab-line exactly like mouse-wheel
hscrolls tabs in Firefox.

Also these two commands can be used via M-x, and can be bound
to some key that could used via a transitive keymap, e.g.
some prefix initiates a key sequence, then consecutive
<right> keys continue hscrolling.

Later advice-add will be moved into the body of tab-line-format.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Tue, 22 Oct 2019 01:20:42 +0300
> 
> This is so overwhelming that I'm still struggling with understanding the
> details of the display engine.  If hscrolling was already implemented
> for the header-line, we could just copy the existing solution to the
> tab-line.

Maybe I should simply sit down and write the code for doing this.

> So I looked how packages cope with the requirement of keeping hscrolling
> of the header-line in sync with hscrolling of the buffer, and found that
> the 'proced' package uses so simple solution that we could just do
> the same.  This is what it does:
> 
> (defun proced-header-line ()
>   "Return header line for Proced buffer."
>   (list (propertize " "
>                     'display
>                     (list 'space :align-to
>                           (line-number-display-width 'columns)))
>         (if (<= (window-hscroll) (length proced-header-line))
>             (replace-regexp-in-string ;; preserve text properties
>              "\\(%\\)" "\\1\\1"
>              (substring proced-header-line (window-hscroll))))))
> 
> i.e. it just cuts scrolled content from the beginning.

But that won't work with variable-pitch fonts and with different
images for the add and close buttons, would it?  Also, doesn't
tab-line-format allow faces (which could change font size) and dynamic
elements via the likes of :eval, like mode-line does?  these would
prevent you from finding where to cut the content, no?

But if this works, by all means go ahead and install something like
that.

Thanks.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

> But that won't work with variable-pitch fonts and with different
> images for the add and close buttons, would it?  Also, doesn't
> tab-line-format allow faces (which could change font size) and dynamic
> elements via the likes of :eval, like mode-line does?  these would
> prevent you from finding where to cut the content, no?
>
> But if this works, by all means go ahead and install something like
> that.

There are two related but separate features: scrolling and auto-scrolling.

Scrolling is implemented now and installed.  It provides UI with buttons,
commands, and mouse-wheeling.

Auto-scrolling could be implemented as well for user convenience: like when
auto-hscroll-mode is enabled, the tab-line could do the same - when due
to the long row of tabs, the current tab gets pushed over the right edge
outside of the screen, then the tab-line could be automatically scrolled
horizontally to make the current tab visible.

This could be implemented by setting the right value to the new window
parameter tab-line-hscroll, and it will bring the current tab back to the view.

The main problem in implementing auto-scrolling is how to detect the
situation when the current tab is not visible.  Maybe by implementing
a function like pos-visible-in-window-p, but named tab-visible-in-tab-line?

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Wed, 23 Oct 2019 00:19:27 +0300
> 
> The main problem in implementing auto-scrolling is how to detect the
> situation when the current tab is not visible.  Maybe by implementing
> a function like pos-visible-in-window-p, but named tab-visible-in-tab-line?

That'd be fine with me.  Let me know if you need help in making that
happen, either by talking or by coding.

Thanks.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> The main problem in implementing auto-scrolling is how to detect the
>> situation when the current tab is not visible.  Maybe by implementing
>> a function like pos-visible-in-window-p, but named tab-visible-in-tab-line?
>
> That'd be fine with me.  Let me know if you need help in making that
> happen, either by talking or by coding.

I'm still trying to understand why truncation flags are not set in the tab-line.
Test case:

0. emacs -Q
1. M-x global-tab-line-mode RET
2. C-x b 01234567890123456789012345678901234567890123456789 RET
   more buffers with long names might be needed
   to cause the tab-line truncation

3. M-x dump-glyph-row RET

shows no truncation:

Row     Start       End Used oE><\CTZFesm     X    Y    W    H    V    A    P
==============================================================================
  0         0         0  111 110000000000     0    0  677   16    0   12    9

i.e. the columns '>' ('row->truncated_on_right_p')
and '<' ('row->truncated_on_right_p') both have values '0'.

Is this a bug?  Or maybe there is another way to detect tab-line truncation
in the glyph matrix?

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Tue, 29 Oct 2019 00:38:19 +0200
> 
> I'm still trying to understand why truncation flags are not set in the tab-line.
> Test case:
> 
> 0. emacs -Q
> 1. M-x global-tab-line-mode RET
> 2. C-x b 01234567890123456789012345678901234567890123456789 RET
>    more buffers with long names might be needed
>    to cause the tab-line truncation
> 
> 3. M-x dump-glyph-row RET
> 
> shows no truncation:
> 
> Row     Start       End Used oE><\CTZFesm     X    Y    W    H    V    A    P
> ==============================================================================
>   0         0         0  111 110000000000     0    0  677   16    0   12    9
> 
> i.e. the columns '>' ('row->truncated_on_right_p')
> and '<' ('row->truncated_on_right_p') both have values '0'.
> 
> Is this a bug?  Or maybe there is another way to detect tab-line truncation
> in the glyph matrix?

These flags are reset because display_mode_line forcibly resets them:

  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.)

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> i.e. the columns '>' ('row->truncated_on_right_p')
>> and '<' ('row->truncated_on_right_p') both have values '0'.
>> 
>> Is this a bug?  Or maybe there is another way to detect tab-line truncation
>> in the glyph matrix?
>
> These flags are reset because display_mode_line forcibly resets them:
>
>   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 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.  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.

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.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> 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.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1061 bytes --]

>> 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.

Please try with this patch to resize the frame right edge until the edge
is between tabs, then it outputs "truncated_on_right_p=0" whereas
when the truncating frame edge is not between tabs then it outputs
"truncated_on_right_p=1"


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: current_tab_visible_p.patch --]
[-- Type: text/x-diff, Size: 2007 bytes --]

diff --git a/src/xdisp.c b/src/xdisp.c
index 987c760c74..b20c7718bd 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -1419,6 +1419,33 @@ window_hscroll_limited (struct window *w, struct frame *f)
   return window_hscroll;
 }
 
+static bool
+current_tab_visible_p (struct window *w, int *tab_num)
+{
+  bool visible_p = false;
+
+  if (window_wants_tab_line (w))
+    {
+      struct it it;
+
+      Lisp_Object window_tab_line_format
+	= window_parameter (w, Qtab_line_format);
+
+      w->tab_line_height
+	= display_mode_line (w, TAB_LINE_FACE_ID,
+			     NILP (window_tab_line_format)
+			     ? BVAR (current_buffer, tab_line_format)
+			     : window_tab_line_format);
+
+      init_iterator (&it, w, -1, -1, NULL, TAB_LINE_FACE_ID);
+
+      fprintf (stderr, "tab_line_p=%d truncated_on_right_p=%d last_visible_x=%d\n",
+               it.glyph_row->tab_line_p, it.glyph_row->truncated_on_right_p, it.last_visible_x);
+    }
+
+  return visible_p;
+}
+
 /* Return true if position CHARPOS is visible in window W.
    CHARPOS < 0 means return info about WINDOW_END position.
    If visible, set *X and *Y to pixel coordinates of top left corner.
@@ -24897,6 +24924,13 @@ display_mode_lines (struct window *w)
 
   if (window_wants_tab_line (w))
     {
+      int tab_num = 0;
+
+      if (current_tab_visible_p (w, &tab_num))
+        {
+          /* Set some Lisp variable */
+        }
+
       Lisp_Object window_tab_line_format
 	= window_parameter (w, Qtab_line_format);
 
@@ -24984,7 +25018,10 @@ display_mode_line (struct window *w, enum face_id face_id, Lisp_Object format)
   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;
+
+  /* Currently only tab-line needs truncation detection.  */
+  if (face_id != TAB_LINE_FACE_ID)
+    it.glyph_row->truncated_on_right_p = false;
 
   /* Make a 3D mode-line have a shadow at its right end.  */
   face = FACE_FROM_ID (it.f, face_id);

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Thu, 31 Oct 2019 01:59:38 +0200
> 
> >> 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.
> 
> Please try with this patch to resize the frame right edge until the edge
> is between tabs, then it outputs "truncated_on_right_p=0" whereas
> when the truncating frame edge is not between tabs then it outputs
> "truncated_on_right_p=1"

We've been miscommunicating.  Sorry, it's my fault: I didn't look
closely enough at the code you wrote in tab-line.el, and built me a
mental model that is completely wrong.

> +      w->tab_line_height
> +	= display_mode_line (w, TAB_LINE_FACE_ID,
> +			     NILP (window_tab_line_format)
> +			     ? BVAR (current_buffer, tab_line_format)
> +			     : window_tab_line_format);
> +
> +      init_iterator (&it, w, -1, -1, NULL, TAB_LINE_FACE_ID);
> +
> +      fprintf (stderr, "tab_line_p=%d truncated_on_right_p=%d last_visible_x=%d\n",
> +               it.glyph_row->tab_line_p, it.glyph_row->truncated_on_right_p, it.last_visible_x);

Calling init_iterator _after_ performing display has no useful effect
on anything.  And since the 'struct it' you pass to it is unrelated to
what display_mode_line used, the value you print has no relation to
what happens inside display_mode_line, nor with the actual flags of
the glyph row produced by display_mode_line for displaying the
tab-line.  I verified in the debugger that when the tab-line is longer
than the window width, the truncated_on_right_p flag of the tab-line's
glyph row is always set, no matter how I resize the frame.

(Given what I write below, this is not really important; I just wanted
to point out your mistakes for the future.)

> @@ -24984,7 +25018,10 @@ display_mode_line (struct window *w, enum face_id face_id, Lisp_Object format)
>    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;
> +
> +  /* Currently only tab-line needs truncation detection.  */
> +  if (face_id != TAB_LINE_FACE_ID)
> +    it.glyph_row->truncated_on_right_p = false;

Here's the thing: I thought that you wanted the truncation indications
to be displayed on the fringes, like we do with text-area lines.  This
is why I started talking about truncated_on_right_p flag: this flag is
used by fringe.c to decide where to display the truncation bitmaps.

But tab-line.el handles the hscrolling and truncation of tab-lines
entirely in Lisp, and displays the hscrolling arrows by itself.  So
you don't need the truncated_on_right_p flag at all, and might as well
revert the above change -- it has no effect for tab-line display the
way that you implemented it.

I now understand that you thought you needed this flag for finding the
current tab, and only for that.  I'm not yet sure that is true, see my
other message.  If it turns out I'm wrong, we can then return to this
issue and discuss whether and how you need to cause this flag to be
set.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> 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.

Before starting to search the current tab, the code needs to known
whether truncation really occurred.

>> 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?

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).

It seems searching for the current tab is not possible in the glyph matrix,
because when the current tab is after the truncation point, then its
glyphs are not produced.

Then the code for searching the current tab should be similar to
display_string but without producing glyphs.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Thu, 31 Oct 2019 02:03:51 +0200
> 
> >> 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.
> 
> Before starting to search the current tab, the code needs to known
> whether truncation really occurred.

Can you explain why?  Don't you keep the ordinal number of the current
tab somewhere?  If not, can you keep it?  Given the number, finding
the tab should be trivial, no?  (At least for some values of "find".)

> 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?  So if you also keep the number of the current tab, the above
decisions become trivial, no?  Or what am I missing?

> It seems searching for the current tab is not possible in the glyph matrix,
> because when the current tab is after the truncation point, then its
> glyphs are not produced.

If we arrive at the conclusion that using the tab numbers, as I
suggest above, is unworkable, then it would make sense to search it by
walking the glyphs.  I don't think it will be hard, let alone
impossible, but let's first see why not do this in Lisp.

And btw, why do you need to "find the current tab"? for what feature?

Thanks.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> Before starting to search the current tab, the code needs to known
>> whether truncation really occurred.
>
> Can you explain why?  Don't you keep the ordinal number of the current
> tab somewhere?  If not, can you keep it?  Given the number, finding
> the tab should be trivial, no?  (At least for some values of "find".)

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.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> 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.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> 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

  <right-fringe> <mouse-1> 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.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Sat, 02 Nov 2019 21:06:05 +0200
> 
> >  . 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?

Yes, possible.

> >  . 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?

No, I meant displaying them like you do now, just move the right arrow
to the right of the last visible tab.

> > 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.

Is that such a serious problem?  Browsers don't auto-scroll.

> > 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.

I think you end up copying almost all of it.  But if I'm wrong, sure,
that's possible.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> >  . 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?
>
> No, I meant displaying them like you do now, just move the right arrow
> to the right of the last visible tab.

This requires a function to find the last visible tab.
Maybe it would be possible to reuse the same new function
that will detect if the current tab is visible.

>> > 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.
>
> Is that such a serious problem?  Browsers don't auto-scroll.

Chromium doesn't auto-scroll because it reduces every tab width
to fit all tabs to the tab bar, so there is no scrolling.
But Firefox auto-scrolls the tab bar to the current tab.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> The main problem in implementing auto-scrolling is how to detect the
>> situation when the current tab is not visible.  Maybe by implementing
>> a function like pos-visible-in-window-p, but named tab-visible-in-tab-line?
>
> That'd be fine with me.  Let me know if you need help in making that
> happen, either by talking or by coding.

Auto-scrolling is implemented now and pushed to master.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Sun, 17 Nov 2019 23:44:00 +0200
> 
> >> The main problem in implementing auto-scrolling is how to detect the
> >> situation when the current tab is not visible.  Maybe by implementing
> >> a function like pos-visible-in-window-p, but named tab-visible-in-tab-line?
> >
> > That'd be fine with me.  Let me know if you need help in making that
> > happen, either by talking or by coding.
> 
> Auto-scrolling is implemented now and pushed to master.

Is it turned off by default?  If so, how does one turn it on?

Thanks.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> Auto-scrolling is implemented now and pushed to master.
>
> Is it turned off by default?  If so, how does one turn it on?

Now I added a new option for auto-scroll that is enabled by default.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Mon, 18 Nov 2019 23:57:30 +0200
> 
> >> Auto-scrolling is implemented now and pushed to master.
> >
> > Is it turned off by default?  If so, how does one turn it on?
> 
> Now I added a new option for auto-scroll that is enabled by default.

Thanks.  It works somewhat strangely, though.  First, it doesn't
scroll even if the current tab is only partially visible.  And second,
if I switch to a buffer whose tab is hscrolled out of view, that tab
is moved to the right end of the tab line, whereas I expected the tab
line to hscroll back such that the tab would become visible without
changing its relative order.

Is that intended?  Basically, I expected that line to behave like we
hscroll text lines.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> Now I added a new option for auto-scroll that is enabled by default.
>
> Thanks.  It works somewhat strangely, though.  First, it doesn't
> scroll even if the current tab is only partially visible.  And second,
> if I switch to a buffer whose tab is hscrolled out of view, that tab
> is moved to the right end of the tab line, whereas I expected the tab
> line to hscroll back such that the tab would become visible without
> changing its relative order.
>
> Is that intended?  Basically, I expected that line to behave like we
> hscroll text lines.

Do you customize tab-line-tabs-function to tab-line-tabs-buffer-groups?
After switching to another buffer it changes the order of tabs
because it uses the same order by recency as buffer-list.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Wed, 20 Nov 2019 00:25:24 +0200
> 
> >> Now I added a new option for auto-scroll that is enabled by default.
> >
> > Thanks.  It works somewhat strangely, though.  First, it doesn't
> > scroll even if the current tab is only partially visible.  And second,
> > if I switch to a buffer whose tab is hscrolled out of view, that tab
> > is moved to the right end of the tab line, whereas I expected the tab
> > line to hscroll back such that the tab would become visible without
> > changing its relative order.
> >
> > Is that intended?  Basically, I expected that line to behave like we
> > hscroll text lines.
> 
> Do you customize tab-line-tabs-function to tab-line-tabs-buffer-groups?

No, this is in "emacs -Q".

> After switching to another buffer it changes the order of tabs
> because it uses the same order by recency as buffer-list.

So this is a feature?  It's quite unexpected, I'd say, because
browsers don't behave like that.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> After switching to another buffer it changes the order of tabs
>> because it uses the same order by recency as buffer-list.
>
> So this is a feature?  It's quite unexpected, I'd say, because
> browsers don't behave like that.

I don't know why 'switch-to-buffer' changes the order of
window-prev-buffers used in the tab-line.  We have to ask Martin
is it possible to keep the original order in window-prev-buffers list.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[martin rudalics]

 > I don't know why 'switch-to-buffer' changes the order of
 > window-prev-buffers used in the tab-line.  We have to ask Martin
 > is it possible to keep the original order in window-prev-buffers list.

No.  The aim of 'window-prev-buffers' (and 'window-next-buffers') is
to make navigation between the buffers shown in that window reliable.
So 'window-prev-buffers' is kept in a "most recently shown in that
window first" order.

Browser tabs are usually ordered by their creation time which has no
relationship to what has been actually shown.  You can create a new
browser tab and then remove it without ever visiting the corresponding
link.  OTOH a buffer listed in 'window-prev-buffers' has been shown in
that window at least once.  After C-x 2 the new window has just one
element in that list, the buffer it shows.

The (here defunct) tab mix plus had a number of ways to affect the
(dynamic re-)sorting of tabs including the positioning of a new tab
wrt the currently active one.  Maybe we should try to simulate some of
their more popular ones here.

martin

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> Cc: 37667@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 21 Nov 2019 09:23:41 +0100
> 
>  > I don't know why 'switch-to-buffer' changes the order of
>  > window-prev-buffers used in the tab-line.  We have to ask Martin
>  > is it possible to keep the original order in window-prev-buffers list.
> 
> No.  The aim of 'window-prev-buffers' (and 'window-next-buffers') is
> to make navigation between the buffers shown in that window reliable.
> So 'window-prev-buffers' is kept in a "most recently shown in that
> window first" order.
> 
> Browser tabs are usually ordered by their creation time which has no
> relationship to what has been actually shown.  You can create a new
> browser tab and then remove it without ever visiting the corresponding
> link.  OTOH a buffer listed in 'window-prev-buffers' has been shown in
> that window at least once.  After C-x 2 the new window has just one
> element in that list, the buffer it shows.

I agree.  Perhaps we should allow customization of the buffer order on
the tab line, but I think the default order should not change when one
switches buffers.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

> Browser tabs are usually ordered by their creation time which has no
> relationship to what has been actually shown.  You can create a new
> browser tab and then remove it without ever visiting the corresponding
> link.

This is exactly how this is already implemented on the tab-bar.

> OTOH a buffer listed in 'window-prev-buffers' has been shown in
> that window at least once.  After C-x 2 the new window has just one
> element in that list, the buffer it shows.

The tab-line is used just for buffer selection, so either it can use
the order of buffer-list, or the order of window-prev-buffers, or
alphabetical order.  I see no other way to sort buffers.

You mentioned 'creation time' above.  Does a buffer have a buffer-local
variable for its creation time?  Then we could sort by buffer's
creation time.  But currently I see only the variable buffer-display-time,
not buffer-creation-time.

> The (here defunct) tab mix plus had a number of ways to affect the
> (dynamic re-)sorting of tabs including the positioning of a new tab
> wrt the currently active one.  Maybe we should try to simulate some of
> their more popular ones here.

Many features of the tab mix plus are already supported on the tab-bar.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[martin rudalics]

 > The tab-line is used just for buffer selection, so either it can use
 > the order of buffer-list, or the order of window-prev-buffers, or
 > alphabetical order.  I see no other way to sort buffers.

'window-prev-buffers' lists a buffer iff it has been displayed before
in the argument window.  'buffer-list' does something similar for its
argument frame but in principle does not care about whether a buffer
has been displayed already.  So you have to decide what the tab-line
should do.  Just an example: Should 'bury-buffer' affect a tab-line
and if so how?

 > You mentioned 'creation time' above.  Does a buffer have a buffer-local
 > variable for its creation time?  Then we could sort by buffer's
 > creation time.  But currently I see only the variable buffer-display-time,
 > not buffer-creation-time.

Indeed.  If you do care about yet undisplayed buffers, then such a
function might be needed.

martin

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[martin rudalics]

 > 1. Use something like word-wrap in the tab-bar to wrap
 >     to the second line non-broken tabs at tab boundaries;

That's what I did in frame-tabs.el.  There I tried to use U-200B as
separator but word-wrap couldn't handle it.

 > 2. Disable wrapping to the second line since it's not supported in -nw;

-nw should support it.

 > 3. Then truncate tab names to fit all tabs into the first line;

Rather not.

 > 4. Or don't truncate but allow scrolling tabs with mouse wheel;

IIRC XEmacs had that with the mode line.  Not really useful IMHO.

martin

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> 1. Use something like word-wrap in the tab-bar to wrap
>>     to the second line non-broken tabs at tab boundaries;
>
> That's what I did in frame-tabs.el.  There I tried to use U-200B as
> separator but word-wrap couldn't handle it.

word-wrap wraps at word boundary that sometimes might be inside the tab name
when tab name contains spaces (tested frame-tabs.el on customization buffers
whose names contain a lot of spaces).

>> 2. Disable wrapping to the second line since it's not supported in -nw;
>
> -nw should support it.

Sorry, I don't understand the meaning of "should".
Does this mean -nw already supports it but its support is not used?

>> 3. Then truncate tab names to fit all tabs into the first line;
>
> Rather not.

But all web browsers truncate tab names.

>> 4. Or don't truncate but allow scrolling tabs with mouse wheel;
>
> IIRC XEmacs had that with the mode line.  Not really useful IMHO.

BTW, is there a reason why the mode line doesn't use a variable-pitch font?

I tried a variable-pitch font for tab bars, and it looks good
and makes tab widths smaller, so more tabs fits into the tab-bar.

But maybe non-monospace fonts might complicate calculation of various
text lengths when trying to fit tabs into the tab-bar.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  37667@debbugs.gnu.org
> Date: Mon, 14 Oct 2019 01:31:00 +0300
> 
> BTW, is there a reason why the mode line doesn't use a variable-pitch font?

By default?  It would cause unpleasant horizontal movement of text,
e.g. when the line number changes.  Also, many variable-pitch fonts
have a very thin glyph for SPC, so different fields could appear as a
single field, another visual problem.

Of course, nothing prevents people from customizing the face to use
whatever font they like.

> I tried a variable-pitch font for tab bars, and it looks good
> and makes tab widths smaller, so more tabs fits into the tab-bar.

Could be a good idea.  Toolkit menu bars definitely use variable-pitch
fonts on most systems.

> But maybe non-monospace fonts might complicate calculation of various
> text lengths when trying to fit tabs into the tab-bar.

Emacs never assumes a face uses fixed-pitch font when it calculates
the various metrics.  So this cannot be a problem (barring bugs).

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> BTW, is there a reason why the mode line doesn't use a variable-pitch font?
>
> By default?  It would cause unpleasant horizontal movement of text,
> e.g. when the line number changes.  Also, many variable-pitch fonts
> have a very thin glyph for SPC, so different fields could appear as a
> single field, another visual problem.
>
> Of course, nothing prevents people from customizing the face to use
> whatever font they like.

I tried to customize the mode-line face to a variable-pitch font,
and indeed glyphs not only for SPC, but for 1-character indicators '-'
and '*' that toggle e.g. writable/modification states or switch coding,
are so thin that it's hard to click them with the mouse.

There is no such problem in tabs where clicking area is wide.

>> I tried a variable-pitch font for tab bars, and it looks good
>> and makes tab widths smaller, so more tabs fits into the tab-bar.
>
> Could be a good idea.  Toolkit menu bars definitely use variable-pitch
> fonts on most systems.

So I changed tab bars to use variable-pitch fonts.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rudalics@gmx.at,  37667@debbugs.gnu.org
> Date: Mon, 14 Oct 2019 23:07:50 +0300
> 
> >> I tried a variable-pitch font for tab bars, and it looks good
> >> and makes tab widths smaller, so more tabs fits into the tab-bar.
> >
> > Could be a good idea.  Toolkit menu bars definitely use variable-pitch
> > fonts on most systems.
> 
> So I changed tab bars to use variable-pitch fonts.

Please make the :height attribute smaller, like 0.9.  The current
value of 1.1 produces too large tab names.

Btw, as long as we are optimizing the tab-bar appearance: I think the
choice of the colors of the current and non-current tabs should be
reversed: the lighter color is more appropriate for "inactive" than
the darker one.  Alternatively, use some non-gray color for the
current tab (I personally think these gray colors are too dull).

Thanks.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]

>> >> I tried a variable-pitch font for tab bars, and it looks good
>> >> and makes tab widths smaller, so more tabs fits into the tab-bar.
>> >
>> > Could be a good idea.  Toolkit menu bars definitely use variable-pitch
>> > fonts on most systems.
>> 
>> So I changed tab bars to use variable-pitch fonts.
>
> Please make the :height attribute smaller, like 0.9.  The current
> value of 1.1 produces too large tab names.

So I changed :height to 0.9 (tab-line tabs should have
smaller height because they are more local).

> Btw, as long as we are optimizing the tab-bar appearance: I think the
> choice of the colors of the current and non-current tabs should be
> reversed: the lighter color is more appropriate for "inactive" than
> the darker one.  Alternatively, use some non-gray color for the
> current tab (I personally think these gray colors are too dull).

The current color scheme is the same as used in Web browsers where the
current tab has the lighter color, so users are accustomed to such
palette.  Here is comparison of colors (at the bottom is Chromium):


[-- Attachment #2: browser_tabs.png --]
[-- Type: image/png, Size: 21129 bytes --]

[-- Attachment #3: Type: text/plain, Size: 124 bytes --]


The only difference is that browser tabs have rounded corners.
I could finish implementing rounded corners for Emacs soon.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: rudalics@gmx.at,  37667@debbugs.gnu.org
> Date: Tue, 15 Oct 2019 00:50:56 +0300
> 
> > Please make the :height attribute smaller, like 0.9.  The current
> > value of 1.1 produces too large tab names.
> 
> So I changed :height to 0.9 (tab-line tabs should have
> smaller height because they are more local).

Thanks.

> > Btw, as long as we are optimizing the tab-bar appearance: I think the
> > choice of the colors of the current and non-current tabs should be
> > reversed: the lighter color is more appropriate for "inactive" than
> > the darker one.  Alternatively, use some non-gray color for the
> > current tab (I personally think these gray colors are too dull).
> 
> The current color scheme is the same as used in Web browsers where the
> current tab has the lighter color, so users are accustomed to such
> palette.  Here is comparison of colors (at the bottom is Chromium):

Chromium has additional visual queues for the current tab (as do other
browsers), while we don't.  So the color is much less important for
the browsers than it is for us, because in Emacs the color is
currently the _only_ indication of the current tab.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> > Btw, as long as we are optimizing the tab-bar appearance: I think the
>> > choice of the colors of the current and non-current tabs should be
>> > reversed: the lighter color is more appropriate for "inactive" than
>> > the darker one.  Alternatively, use some non-gray color for the
>> > current tab (I personally think these gray colors are too dull).
>>
>> The current color scheme is the same as used in Web browsers where the
>> current tab has the lighter color, so users are accustomed to such
>> palette.  Here is comparison of colors (at the bottom is Chromium):
>
> Chromium has additional visual queues for the current tab (as do other
> browsers), while we don't.

Soon I'll finish implementing the same visual cues for Emacs tabs.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[martin rudalics]

 > word-wrap wraps at word boundary that sometimes might be inside the tab name
 > when tab name contains spaces (tested frame-tabs.el on customization buffers
 > whose names contain a lot of spaces).

Right.  It probably should use U-00A0 instead.

 >>> 2. Disable wrapping to the second line since it's not supported in -nw;
 >>
 >> -nw should support it.
 >
 > Sorry, I don't understand the meaning of "should".
 > Does this mean -nw already supports it but its support is not used?

No.  I meant it should be implemented on -nw, eventually.

 >>> 3. Then truncate tab names to fit all tabs into the first line;
 >>
 >> Rather not.
 >
 > But all web browsers truncate tab names.

Firefox here does some strange shading before truncating.  I'm not
fond of it but my version here doesn't support tab mix plus any more.

 > I tried a variable-pitch font for tab bars, and it looks good
 > and makes tab widths smaller, so more tabs fits into the tab-bar.

Variable sized tabs can be a pain.  When you want to kill a row of
tabs by clicking on the "x" you have to move the mouse in between.

martin

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>>>> 3. Then truncate tab names to fit all tabs into the first line;
>>>
>>> Rather not.
>>
>> But all web browsers truncate tab names.
>
> Firefox here does some strange shading before truncating.  I'm not
> fond of it but my version here doesn't support tab mix plus any more.

Maybe PaleMoon still supports TabMixPlus.

>> I tried a variable-pitch font for tab bars, and it looks good
>> and makes tab widths smaller, so more tabs fits into the tab-bar.
>
> Variable sized tabs can be a pain.  When you want to kill a row of
> tabs by clicking on the "x" you have to move the mouse in between.

Indeed fixed-width tabs in browsers help with this, but at the cost
of tab truncation.  Since no one wants tab truncation in Emacs, we need
to support hscrolling.

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[martin rudalics]

 >> Firefox here does some strange shading before truncating.  I'm not
 >> fond of it but my version here doesn't support tab mix plus any more.
 >
 > Maybe PaleMoon still supports TabMixPlus.

The last time I used PaleMoon it had other issues (although there was
a fork of it that even worked with Windows XP).  With its new display
engine, Firefox has broken most of my old viewing habits.  By now I
got too tired of adapting.

 > Indeed fixed-width tabs in browsers help with this, but at the cost
 > of tab truncation.  Since no one wants tab truncation in Emacs, we need
 > to support hscrolling.

That's why I prefer multiline tabs.  Hscrolling always has the
potential problem that one considers things scrolled off as things
that are not present.

martin

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Lars Ingebrigtsen]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> To reproduce, invoke Emacs from the src directory:
>
>   ./emacs -Q
>
> and then type:
>
>   C-x 6 f xdisp.c RET
>   C-x 6 f dispnew.c RET
>   C-x 6 f dispextern.h RET
>   C-x 6 f window.c RET
>   C-x 6 f frame.c RET
>
> The 6th button is displayed partially on the 1st tab-bar line, and the
> rest on the 2nd line, which I don't think is pretty.

This is a very long thread, and I've just skimmed parts of it.  Much has
changed in the tab dept. since this bug report, but it seems like the
tabs basically have the same problem as described here.  (Although I had
to open 11 buffers this way to make it do this.)


[-- Attachment #2: Type: image/png, Size: 27957 bytes --]

[-- Attachment #3: Type: text/plain, Size: 304 bytes --]


Was the conclusion that this is how tabs should be displayed, or is this
a new regression?

I think it'd make more sense to put "category.c" on a new line, and not
break in the middle of the string?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 37667@debbugs.gnu.org
> Date: Sun, 20 Sep 2020 13:24:29 +0200
> 
> I think it'd make more sense to put "category.c" on a new line, and not
> break in the middle of the string?

Yes, I think so.