Separate area at the top for a serious tab bar

Separate area at the top for a serious tab bar

[R. Diez]

Hi all:


A tab bar is a very important usability element. Virtually every other editor has it. For many people, including myself, visual, positional clues makes life much easier.

I just do not want to live without one.  Therefore, I am a long-time user of tabbar.el . I have installed several little enhancements and hacked together some dodgy Lisp code over the years. It is a problematic solution that still frustrates me on a regular basis.

I am no Lisp expert, but I am sure that many smarter people would quickly write a better tab bar package if given a good chance. My bet is that something is holding them back.

The reason may be the lack of a separate area for a tab bar. If I remember correctly, the current tabbar.el steals an area designed for displaying a ruler. This stealing causes problems, because the handling of that area is not flexible enough and yields trouble here and there. It is not a good basis to build upon.

I have just read the following in the Emacs 26.1 change log:

"Emacs now supports optional display of line numbers in the buffer. This is similar to what 'linum-mode' provides, but much faster and doesn't usurp the display margin for the line numbers."

I guess that there was a similar problem there: the old code had to usurp the margin for another purpose.

This is my plea to the Emacs gurus: Implement a suitable area at the top of windows/frames/whatever to pave the way for a serious tab bar implementation.

Best regards,
  rdiez

Re: Separate area at the top for a serious tab bar

[martin rudalics]

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

 > This is my plea to the Emacs gurus: Implement a suitable area at the top of
 > windows/frames/whatever to pave the way for a serious tab bar implementation.

A side window at the top of a frame (see section 28.19 Side Windows of
the Elisp manual) is such an area.  A couple of years ago I wrote a
package called frame-tabs.el which uses it.  I attached a copy of it
so you can see what's needed to convert your code.

martin

[-- Attachment #2: frame-tabs.el --]
[-- Type: application/emacs-lisp, Size: 12889 bytes --]

Re: Separate area at the top for a serious tab bar

[Van L]

> A side window at the top of a frame (see section 28.19 Side Windows of
> the Elisp manual) is such an area.

Mouse button 1 and 3 switches among open buffers when clicking on buffer name in modeline.

Mouse button 2 scroll up/down could show a context menu there, for open buffers to choose from.

Having tabs wastes space.

RE: Separate area at the top for a serious tab bar

[Drew Adams]

Another way to log an enhancement request is to use
`M-x report-emacs-bug'.  That enters the request into
the bug tracker.

help-gnu-emacs is a good place to discuss such a
possible enhancement, but you might also want to
record it in the bug tracker.

Re: Separate area at the top for a serious tab bar

[Teemu Likonen]

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

R. Diez [2018-06-20 07:06:59Z] wrote:

> A tab bar is a very important usability element. Virtually every other
> editor has it. For many people, including myself, visual, positional
> clues makes life much easier.
>
> I just do not want to live without one.

That is a valid point and it would be good if Emacs had nice tab bar
feature.

In my opinion tab bar wastes space but I'm interested in trying such
feature. Normally I switch buffers with "C-x b" (bound to
ido-switch-buffer) and sometimes I use <C-down-mouse-1> for graphical
buffer menu or "C-x C-b" (bound to buffer-menu-other-window) for the
normal textual buffer menu.

-- 
/// Teemu Likonen   - .-..   <https://keybase.io/tlikonen> //
// PGP: 4E10 55DC 84E9 DFF6 13D7 8557 719D 69D3 2453 9450 ///

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Separate area at the top for a serious tab bar

[Van L]

> record it in the bug tracker.

There is a want-ad at

  http://lists.gnu.org/r/help-debbugs/2018-06/msg00004.html

Re: Separate area at the top for a serious tab bar

[Grant Rettke]

On Wed, Jun 20, 2018 at 2:06 AM, R. Diez <rdiezmail-emacs@yahoo.de> wrote:

> I just do not want to live without one.  Therefore, I am a long-time user of tabbar.el . I have installed several little enhancements and hacked together some dodgy Lisp code over the years. It is a problematic

I hear you. That is a powerful statement. I respect that, and share my
thoughts with you in that context:

Have you mastered buffers? Have you mastered ibuffer and grouping the
buffers listed by git folder?

When I learned Emacs I strongly disliked the buffer mode. It wasn't
just weird, I really disliked it. So I used tabbar mode.
I loved it. I set it up to logically group files and that worked
great. Then something happened. I just kept using the rest of
Emacs and started to warm up to buffers. Eventually I felt that they
perfectly fit and I didn't want tabbar mode anymore.

I guess my that I wanted to share that perspective from a tabbar user
to another. Thanks.

Re: Separate area at the top for a serious tab bar

[Jay Kamat]

Hi,

R. Diez writes:

> I just do not want to live without one. Therefore, I am a long-time user of
> tabbar.el . I have installed several little enhancements and hacked together
> some dodgy Lisp code over the years. It is a problematic solution that still
> frustrates me on a regular basis.

As someone who has come from other editors (originally eclipse, intellij, and
atom), and has thought the exact same thing (that a tabbar is a necessity for
an editor), I know how you feel. I would highly reccomend giving the buffer
based workflow a try, however. Once I tried seriously dropping tabs, I can't
imagine going back to a tabbed workflow.

> I am no Lisp expert, but I am sure that many smarter people would quickly
> write a better tab bar package if given a good chance. My bet is that
> something is holding them back.

tabbar.el has many issues with it implementation wise. I think that if someone
did a full audit of it and cleaned out the bugs and fixed the performance
issues, it would handle a lot nicer, even without any changes on the Emacs
side. I think that most of the bugs in the issue tracker are fixable purely in
elisp:

https://github.com/dholm/tabbar/issues

> The reason may be the lack of a separate area for a tab bar. If I remember
> correctly, the current tabbar.el steals an area designed for displaying a
> ruler. This stealing causes problems, because the handling of that area is
> not flexible enough and yields trouble here and there. It is not a good
> basis to build upon.

See `tabbar-local-mode', which I found works well even when the header line is
used. See it's docstring for more information on that. When I used tabbar, I
just turned off the header for all the modes I used and used tabbar-local-mode
when that option wasn't available.


I actually wrote a blog post about my feelings on this topic earlier, maybe
you would find some interesting ideas in it:

http://jgkamat.gitlab.io/blog/emacs-tabs.html

My tabbar configuration is here; if you decide to continue using tabbar, you
may find some useful things in it:

https://gitlab.com/jgkamat/dotfiles/blob/13da6a341688e5fb1e74d6521dc9a3a941dd0cde/emacs/.emacs.d/lisp/tabbar-tweaks.el

-Jay

Re: Separate area at the top for a serious tab bar

[R. Diez]

> [...]
> I would highly reccomend giving the buffer
> based workflow a try, however. Once I tried seriously
> dropping tabs, I can't imagine going back to a tabbed workflow.
> [...]

You are not the first with that kind of suggestion.

I still have not seen what makes that "buffer based workflow" better. Sometimes I do use ibuffer to clean buffers up, or to find some buffer I 'lost', but tabs give you a kind of positional orientation that is hard to beat.

I do not switch buffers with the mouse. I use Ctrl+Up and Ctrl+Down to navigate the tab bar. With Ctrl+Shift+Up and Ctrl+Shift+Down I can reorder the tabs with the keyboard. I do this all the time, so that the buffers I am working on at the moment are near each other.

By the way, those are exactly the keys that Firefox uses for its tabbar.


For example, when working on C/C++ code, I place the .h and .cpp files next to each other, the .h file to the left, and the .cpp file to the right. I know I can open the other one with 'other', but that is not reliable, for example, if the .h file is not next to the .cpp file, but in some other include/ directory. If I am moving code, I place the old source file to the left, and the new one next to it, to the right, so switching is immediate. I can open a script and have next to it a shell to test it out. And many such pairs happily coexist in the same, long tabbar.



Best regards,
  rdiez

Re: Separate area at the top for a serious tab bar

[Marcin Borkowski]

On 2018-06-25, at 08:24, R. Diez <rdiezmail-emacs@yahoo.de> wrote:

>> [...]
>> I would highly reccomend giving the buffer
>> based workflow a try, however. Once I tried seriously
>> dropping tabs, I can't imagine going back to a tabbed workflow.
>> [...]
>
> You are not the first with that kind of suggestion.

And not the last. ;-)

> I still have not seen what makes that "buffer based workflow" better. Sometimes I do use ibuffer to clean buffers up, or to find some buffer I 'lost', but tabs give you a kind of positional orientation that is hard to beat.

1. Scalability.  I have around 250 buffers open now, and I'm only at
about 4 days emacs-uptime and on vacation. ;-)

2. Regex-based switching to tabs (I use Ivy).

Though I understand the "positional orientation" idea.

> I do not switch buffers with the mouse. I use Ctrl+Up and Ctrl+Down to navigate the tab bar. With Ctrl+Shift+Up and Ctrl+Shift+Down I can reorder the tabs with the keyboard. I do this all the time, so that the buffers I am working on at the moment are near each other.
>
> By the way, those are exactly the keys that Firefox uses for its tabbar.

I plan to ditch the Firefox tabs, too, and use EXWM, so that I can make
the tabbar->buffer kind of switch in web browsing, too.  (BTW, those
keys don't work in my FF.)

> For example, when working on C/C++ code, I place the .h and .cpp files next to each other, the .h file to the left, and the .cpp file to the right. I know I can open the other one with 'other', but that is not reliable, for example, if the .h file is not next to the .cpp file, but in some other include/ directory. If I am moving code, I place the old source file to the left, and the new one next to it, to the right, so switching is immediate. I can open a script and have next to it a shell to test it out. And many such pairs happily coexist in the same, long tabbar.

That is indeed neat, but isn't it fragile?  It depends on you, the user,
ordering the tabs.  This looks like something a computer could do.  I'd
probably write a small Elisp command to do that kind of buffer switch
for me.  With something like projectile it should probably be at most
a few lines of code, even if the "other" file is in some other
directory.

Also, I use windows/frames for similar things.

/me thinking

Thanks for a blog post idea.  While I don't code in C-whatever, this
might be useful more generally.  JS web apps could benefit from that,
and LaTeX to some extent, too.

Best,

--
Marcin Borkowski
http://mbork.pl

Re: Separate area at the top for a serious tab bar

[R. Diez]

> [...]

> Though I understand the "positional orientation" idea.

This is a personal preference. Many people thrive in chaos. Other must have a tidy desktop. There is nothing wrong per se with each way.

A tabbar does not preclude other buffer switching methods. I often have many buffers open. But I tend to keep the "local context" (the tabs that are visible right now) sorted (.h left from .cpp and so on).

There is a tabbar in Firefox. There is one in most desktop environments (Windows, Xfce, KDE...). There will always be people and scenarios where a tabbar is the right approach, even in Emacs.

I would not underestimate this kind of usability matter. It may well be one of the biggest factors driving people away from Emacs. It could even be a necessary evil until most people learn to do away with the tabbar. Humans are just like that.


> [...]

> (BTW, those keys don't work in my FF.)

They are standard in Firefox:

https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly#w_windows-tabs

You are probably using a Linux desktop environment that is eating those key combinations. I had to tell mine to stop taking some key combinations for virtual desktop switching, which I personally do not use.



> That is indeed neat, but isn't it fragile?  It depends on you,
> the user, ordering the tabs.  This looks like something a computer could do.
> [...]

On the contrary. I am the user, and I rule. 8-) Automatic ordering here would not work. Sometimes, during testing, I keep seemingly-unrelated tabs next to each other. For example, a shell buffer next to the script I am testing right now, or the HTML page next to the C++ code that is generating it.


I do most of my buffer switching without even looking at the tabbar, with just 1 or 2 quick keystrokes, because I intuitively know where the buffer I want is (2 steps left, or 1 step right). For a small group of related files, this positional hint works better (at least for me) than rotating over the last-visited buffers.


Best regards,
  rdiez

Re: Separate area at the top for a serious tab bar

[Eli Zaretskii]

> Date: Mon, 25 Jun 2018 10:20:18 +0000 (UTC)
> From: "R. Diez" <rdiezmail-emacs@yahoo.de>
> Cc: "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>,
> 	Jay Kamat <jaygkamat@gmail.com>
> 
> > Though I understand the "positional orientation" idea.
> 
> This is a personal preference. Many people thrive in chaos. Other must have a tidy desktop. There is nothing wrong per se with each way.
> 
> A tabbar does not preclude other buffer switching methods. I often have many buffers open. But I tend to keep the "local context" (the tabs that are visible right now) sorted (.h left from .cpp and so on).
> 
> There is a tabbar in Firefox. There is one in most desktop environments (Windows, Xfce, KDE...). There will always be people and scenarios where a tabbar is the right approach, even in Emacs.
> 
> I would not underestimate this kind of usability matter. It may well be one of the biggest factors driving people away from Emacs. It could even be a necessary evil until most people learn to do away with the tabbar. Humans are just like that.

FWIW, I consider tabbar to be in the same class as line numbers: while
not really an Emacs'y thing, at least not for us veteran curmudgeons,
they are very popular in some quarters, and if we want to make those
people happy, we should have them.

I also think this kind of feature needs support in the display engine;
anything else will always look like a hacky band-aid.  Volunteers are
welcome to work on that.

Re: Separate area at the top for a serious tab bar

[Jean-Christophe Helary]

> On Jun 25, 2018, at 23:49, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Date: Mon, 25 Jun 2018 10:20:18 +0000 (UTC)
>> From: "R. Diez" <rdiezmail-emacs@yahoo.de>

>> A tabbar does not preclude other buffer switching methods. I often have many buffers open. But I tend to keep the "local context" (the tabs that are visible right now) sorted (.h left from .cpp and so on).
> 
> I also think this kind of feature needs support in the display engine;
> anything else will always look like a hacky band-aid.  Volunteers are
> welcome to work on that.

I'm pretty sure Aquamacs has developed such a thing. Wouldn't it be possible to borrow from their code base ?


Jean-Christophe Helary
-----------------------------------------------
http://mac4translators.blogspot.com @brandelune

Re: Separate area at the top for a serious tab bar

[Eli Zaretskii]

> From: Jean-Christophe Helary <brandelune@gmail.com>
> Date: Mon, 25 Jun 2018 23:56:39 +0900
> Cc: help-gnu-emacs@gnu.org
> 
> I'm pretty sure Aquamacs has developed such a thing. Wouldn't it be possible to borrow from their code base
> ?

Depends on how portable it is and whether we can get the copyright
assignment from the original author (assuming the code is
non-trivial).

Like I said: volunteers welcome ;-)

Re: Separate area at the top for a serious tab bar

[Bob Proulx]

Eli Zaretskii wrote:
> R. Diez wrote:
> > A tabbar does not preclude other buffer switching methods. I often
> > have many buffers open. But I tend to keep the "local context" (the
> > tabs that are visible right now) sorted (.h left from .cpp and so
> > on).
> >
> > I would not underestimate this kind of usability matter. It may
> > well be one of the biggest factors driving people away from
> > Emacs. It could even be a necessary evil until most people learn
> > to do away with the tabbar. Humans are just like that.
> 
> FWIW, I consider tabbar to be in the same class as line numbers: while
> not really an Emacs'y thing, at least not for us veteran curmudgeons,
> they are very popular in some quarters, and if we want to make those
> people happy, we should have them.

I like your thinking here.

I feel compelled to note that no one has mentioned the "speedbar"
interface here.  There is an entire another camp of speedbar followers
too.  Yet another way to manage and switch files and buffers.

I have myself been a very longtime user of electric-buffer-mode bound
to the list-buffers key C-x C-b.  I guess I should review ibuffer
given the recommendations for it here.  So far it looks like a
somewhat fancier electric-buffer-mode.  I am working with lower
resolution displays these days (not by choice, but by small portable
laptops now being short on vertical pixels, life is a compromise) and
therefore anything that robs me of vertical space is bad.  If it uses
vertical space then it needs to be very useful or it must be removed
in order to give the pixels to the text that is being displayed.

Bob

Re: Separate area at the top for a serious tab bar

[Eric Abrahamsen]

Bob Proulx <bob@proulx.com> writes:

> Eli Zaretskii wrote:
>> R. Diez wrote:
>> > A tabbar does not preclude other buffer switching methods. I often
>> > have many buffers open. But I tend to keep the "local context" (the
>> > tabs that are visible right now) sorted (.h left from .cpp and so
>> > on).
>> >
>> > I would not underestimate this kind of usability matter. It may
>> > well be one of the biggest factors driving people away from
>> > Emacs. It could even be a necessary evil until most people learn
>> > to do away with the tabbar. Humans are just like that.
>> 
>> FWIW, I consider tabbar to be in the same class as line numbers: while
>> not really an Emacs'y thing, at least not for us veteran curmudgeons,
>> they are very popular in some quarters, and if we want to make those
>> people happy, we should have them.
>
> I like your thinking here.
>
> I feel compelled to note that no one has mentioned the "speedbar"
> interface here.  There is an entire another camp of speedbar followers
> too.  Yet another way to manage and switch files and buffers.

It seems like speedbar is nearly capable of doing what the OP wants. I
think the only part of his request that isn't really doable out of the
box is the ability to manually arrange a small group of buffers in close
proximity to each other, for ease of switching. It seems like this is
something speedbar could do without massive amounts of coding.

Personally I really like projectile, and
`helm-projectile-switch-to-buffer', for this sort of thing. If I know
I'm going to be working with three or four files in particular, I close
all other buffers in the project, and that command becomes very useful
for quick switching.

Eric

Re: Separate area at the top for a serious tab bar

[R. Diez]

Hallo Martin:


> A side window at the top of a frame (see section 28.19
> Side Windows of the Elisp manual) is such an area.
> [...]


Despite my limited Lisp skills, I am still thinking about tab bars. 8-)

In the Emacs manual I found the following:

"Side windows are special windows positioned at any of the four sides of a frame’s root window"

You seem to know more than I do, so maybe you can help me save some time investigating around.

In NetBeans, you can split the editor vertically and have one tab bar over each half. Emacs' tabbar.el uses the "ruler" area, which is (or was?) a special area on top of each buffer. This way, each Emacs buffer (or "window") has a tab bar at its top. If I split the frame vertically with split-window-below, I get to see 2 tab bars.


From the documentation, I guess I cannot have a "side window" automatically placed on top of each buffer (or "window"), because side windows only apply to entire frames. Is that right?

I have seen that you can nest windows, which are then called "internal windows". Would a tab bar based on that be hard to manage? I guess that the tab bar would then be another Window as far as Emacs is concerned, so windmove-up would then take me to the tabbar over its buffer window, which I do not really want. Buffer windows might also get confused if they suddenly move down in the window hierarchy in order to make room for a tool bar on top. Any tips on how I could approach a new tab bar implementation?


Thanks in advance,
  rdiez

Re: Separate area at the top for a serious tab bar

[martin rudalics]

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

 > In NetBeans, you can split the editor vertically and have one tab
 > bar over each half. Emacs' tabbar.el uses the "ruler" area, which is
 > (or was?) a special area on top of each buffer.

Let's say on top of each window showing the buffer.

 > This way, each Emacs
 > buffer (or "window") has a tab bar at its top. If I split the frame
 > vertically with split-window-below, I get to see 2 tab bars.

Right.

 >>From the documentation, I guess I cannot have a "side window"
 > automatically placed on top of each buffer (or "window"), because
 > side windows only apply to entire frames. Is that right?

Right.

 > I have seen that you can nest windows, which are then called
 > "internal windows".

Emacs windows are "nested" by default.  That is, splitting a window
makes a new internal window unless such a window exists already and
can be reused.

 > Would a tab bar based on that be hard to manage?
 > I guess that the tab bar would then be another Window as far as
 > Emacs is concerned, so windmove-up would then take me to the tabbar
 > over its buffer window, which I do not really want.

In this (and in any related case) set the 'no-other-window' parameter
of the window that you do not want to select.  'window-in-direction'
which should be called by 'windmove-up' respects that.

 > Buffer windows
 > might also get confused if they suddenly move down in the window
 > hierarchy in order to make room for a tool bar on top. Any tips on
 > how I could approach a new tab bar implementation?

Do I understand correctly that you want a tabbar for each window?  In
that case I would suggest making an atomic window (section 28.20
Atomic Windows of the Elisp manual).  For how to accomplish that I
attach my old win-tabs.el.  (I plan to post a newer version of this
together with one for frame-tabs.el on GNU ELPA - for the moment
please live with some of its behavioral glitches.)

martin

[-- Attachment #2: win-tabs.el --]
[-- Type: application/emacs-lisp, Size: 11684 bytes --]