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

classic Classic list List threaded Threaded
57 messages Options
123
Reply | Threaded
Open this post in threaded view
|

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



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
> 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;



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Juri Linkov <[hidden email]>
> Cc: [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

martin rudalics
In reply to this post by Juri Linkov-2
 > 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



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
>> 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.



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by Eli Zaretskii
>> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Juri Linkov-2
> From: Juri Linkov <[hidden email]>
> Cc: Eli Zaretskii <[hidden email]>,  [hidden email]
> 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).



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Juri Linkov-2
> From: Juri Linkov <[hidden email]>
> Cc: [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by Eli Zaretskii
>> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Juri Linkov <[hidden email]>
> Cc: [hidden email],  [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by Eli Zaretskii
>> >> 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.



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by Eli Zaretskii
>> >> 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):



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

browser_tabs.png (28K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Juri Linkov <[hidden email]>
> Cc: [hidden email],  [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
In reply to this post by Juri Linkov-2
> From: Juri Linkov <[hidden email]>
> Cc: [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by Eli Zaretskii
>> > 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.



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
In reply to this post by Eli Zaretskii
> 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:



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.

tty-menu-bar-truncated.png (14K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Juri Linkov <[hidden email]>
> Cc: [hidden email]
> 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.



Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]>
> Cc: [hidden email]
>
> > From: Juri Linkov <[hidden email]>
> > Cc: [hidden email]
> > 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.



Reply | Threaded
Open this post in threaded view
|

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

Juri Linkov-2
>> > 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.



Reply | Threaded
Open this post in threaded view
|

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

Eli Zaretskii
> From: Juri Linkov <[hidden email]>
> Cc: [hidden email]
> 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



123