The case for vertically stacked tabs

That's a bit of a strange post, but I hope it may spark some positive discussion: Emacs recently get tab support. First AFAIK from Centaur Emacs and then upstream. Tabs are common UI elements since years, however IMVHO in most cases are a very bad idea as they are normally: modern monitor are 16:9 and most people use them straight, not 90° rotated, so plenty of horizontal space, very little vertical one and tabs eat some of it while still being unable to scale well... On contrary "experiments" like Tab Center Redux (it's successor Tab Center Reborn) Firefox extension show that vertical tabs can scale well, they might be "hard to choose" at first, but actually work pretty well. They remain easy to read even when they are many, they might be scrollable if needed, integrated with `switch-buffer` search&narrow packages, they might co-exist with a sidebar (like those popular in IDEs), even on one and another side of the screen and potentially spark new UI ideas to extend them further. What do you think about that?

I haven't seen a package for this, but it seems like it should be possible to build a tool that displays open buffers as [treemacs](https://github.com/Alexander-Miller/treemacs#treemacs-as-a-framework) nodes.

This isn't to knock the efforts, but what's the use case for tabs in emacs? Don't buffers do everything they can do, just better? I actually spent quite a lot of effort to convert all my of web browser's tabs into buffers upon opening so they show up in my buffer switcher (using exwm as window manager).

Modern screens have lots of width, but to me that means 2 (laptop) or 3 (monitor) windows side-by-side and then I am making full use of the width and don't have excess to burn. I can't speak for centaur tabs, but the built in tab-bar is more for tabs-as-workspaces, not tab-per-buffer (though it can do that). As such, personally I usually have 3-6 of them, rarely 8 or more, occupying one line, while side tabs would mean enough width to display at least a reasonable amount of the tab's name (for me, that's usually the project it's displaying). It's also possible to display more info in the right of that bar, making more use of that one line. So I would not be interested in side-tabs. I'm also uninterested in tab-per-buffer as I can't see any benefit. It seems to me to be something that only makes sense for mouse-centric interactions. If I am not looking at a buffer, I will summon it quickly with keyboard fuzzy search, not by visually scanning for it and then selecting it in some clunky way.

1) I use tab-bar-mode a lot. Its tabs are sort of more like workspaces -- each is a setup if windows and buffers. I find this is useful for dividing up parts of a workflow, and keeping open things which take up a lot of window slace (gnus, ebib) 2) can you post/link that tabs-as-buffers config for EXWM? Sounds really useful!!

You can use them for the same purpose as vim, if you have several views or layouts you want to use and just switch buffer inside each window. It can be pretty handy if you're jumping around tons of buffers to look for something in a large code base, and have another tab with the more permanent windows where you're doing most of the work. A tab per buffer which is more the norm in other editors is not really needed though, when you have the buffers. Using a tab to organize a collection of windows in a certain layout though is pretty nice. Those two together are hard to beat.

You probably want to take a look at [https://github.com/jojojames/ibuffer-sidebar](https://github.com/jojojames/ibuffer-sidebar) Honestly though once you get the minibuffer style buffer switching, you can't go back. It's much faster and more convenient - instead of scanning a list of names, you do filtering and let the name come to you.

> It's also possible to display more info in the right of that bar, making more use of that one line. You could also split window horizontally and adjust window below (or above) vertical tab-bar to display something else.

Assuming what you want to display is very narrow. On my tab-bar line I have the full pathname of the file plus line/column numbers, since I don't use window-manager title bars. But that's just ameliorating the problem in the first place. Side tabs would take up more useful space, and do a worse job at displaying their contents.

There are two kinds of tabs available, which you can use individually or in combination. `tab-bar-mode` provides "window configurations as tabs". You wouldn't have many of these at all, typically. `tab-line-mode` provides "buffers as tabs" which is the type you're thinking of.

> Assuming what you want to display is very narrow. Yes, but the same reasoning goes for horizontal line too. It assumes that whatever you are displaying fits in one line, and depending on how many tabs there are it can also be narrow. > I don't use window-manager title bars Neither do I. Nor menubar, toolbar or scrollbars. I am always into maximizing my work area. You can [see how my Emacs looks like](https://postimg.cc/N5NtScsZ), I don't use tabs at all. I prefer to maximize vertical space because of similar reasoning as Op, vertical space is at premium. That is 50% of my screen width. The other 50% is either Firefox, or Emacs is in full-screen. It's a 4k display, 3840x2160. > Side tabs would take up more useful space, and do a worse job at displaying their contents. It probably depends on the content displayed. You could display just icons for tabs without text. But the point is that there is much more space horizontally, which we don't use so well with modern displays, than what there is vertically.

The people who like them are welcome to carry on but yeah tabs are very un-Emacs which, IMO, needs to be keyboard-driven to get the most out of it.

Ooh, that actually sounds pretty nice. I'll check that out, thanks!

Thanks for replay, honestly I do not see a case for "tabs as workspace", especially because there are normally few: switching from one to another it's not hyper-frequent (at least for me) so the trade-off to hit a key and select one search&narrow style is almost no brain and no issue. For buffers *sometimes* I do have a certain use-case, for instance I drop elfeed to Miniflux with it's webui because having many feeds and no real attentive reading of any single entry in my feeds I benefit from FF side tabs to quickly skim the new items, middle-click to open potentially interested one, then again middle-click to close them aside passing one after another easily. It prove to be faster than keyboard for me. It work with *less* attention witch sometimes is bad, but sometimes is good. I've tried with multiple FF windows and Emacs switch buffer, while hyper-fast (a single key bound to `kill-this-buffer`) still do not gives me the same effect of having a handful of stacked tabs aside. For the rest I do not see a use-case for tabs at all. Essentially my point is: - sometimes having UI to *reduce* our attention while "processing" mass of low-important contents is useful, tabs fall in that category but... - ... horizontally stacked in a row are absolutely inefficient since they do not scale more than few, so they might work just when due to the low number of elements are not needed. For curiosity: why you like "perspectives" (workspace) "via tabs" ? Did you switch between them frequently enough?

Most textual content is narrow, it need to be for readability, that's why we have "77/80 columns max" rules, we have narrow/portrait paper etc. Wide contents are mostly media content (movies, images etc), so for GIMP yes I agree, side tabs waste precious space, horizontally stacked tabs like GIMP's one are better, but that's not generally valid IMO.

IMO it's rare, but might be useful for web browsing in EXWM, for activities that demand "an overview" of something with an overall low attention. Personally I do not use tabs in Emacs, nor horizontally nor vertically, but I use the for instance in GIMP, horizontally as they are by default, since in GIMP I need wide views and no need much tabs, and side tabs (Tab Center Reborn) in Firefox because I often have many tabs and like the "persistent overview" while most web-pages are narrow for readability so having large empty bands aside is useless. I tried (I'm on EXWM too) all middle-clicked links open in a dedicated window so use Emacs to switch between them, rarely is of help, for instance to put two webpages side by side without specific FF extension to tile them, but in most case does not work enough for me...

Thanks :-) actually I do not use tabs at all in Emacs/EXWM but I see use-cases for side tabs since I use them in Firefox and for such usage works very well for me, while buffer switching between windows does not work comfortable enough, that's the reason for a "case about side tabs" :-) Ideally I think having them, optional of course, both "aside" and "top or bottom" might be useful case-by-case :-)

I don't really get how code width gives more free screen width. I too like column limits in code and am currently working with an 88 column standard, have had 78 and 80. It means on my 27" 4k I can sometimes spare a little width when I have 3 windows, and I will launch treemacs if I'm exploring a new repository, but generally turn it off because I can't spare that space. If I need a browser or other reference, I can fit that in plus two-window Emacs. In that case I have zero available width.

> I do not see a case for "tabs as workspace", especially because there are normally few: switching from one to another it's not hyper-frequent (at least for me) so the trade-off to hit a key and select one search&narrow style is almost no brain and no issue. I switch very frequently, sometimes multiple times a minute, e.g. between testing and editing contexts, or between two closely inter-related repositories I'm working on, between a remote server tab and a code reference tab. The tab bar to me is solely a visual display of which workspaces exist and which one I'm in - both of which I often lose track of. I also use the right of the space to display the full pathname of the current file etc. I almost never use the mouse within Emacs, as I find it irritating and clunky to do so compared to the other options. I also think the buffer list is just a cache, and displaying and interacting with it is something of an anti-pattern. It's an implementation detail that I should never care about. Currently I have ~100 buffers, so I certainly don't want tabs for all of them (but presumably you could narrow it down with perspectives or something). I include `recentf` in my buffer switching and often use project-based file finding, so I typically switch to a file without any regard for whether it's already in a buffer .

Thanks :-)

Is it frequent? I mean do you frequently have many "vertical subdivision" that eat up your horizontal space? I'm curious because I still fail to find a "good monitor setup", I've tried 2×27" 90° rotated, works well in *some* cases, but not in most others, a small 23" 90° rotated and a 31" main, works well in most cases, for the others I just turn off the small one, but still not that happy. I've eyed the new LG 16:18 but I see no one on sale... Sometimes I still miss "wide" space, but rarely happen, while missing vertical space on 16:9 screens happen normally for me.

Literally almost all the time that I have windows side-by-side to code-width plus some buffer - except when something has really long lines, like a logfile or some error output, when I might remove spits temporarily. I have a hacky defun that splits and repopulates with the most recently used file-buffers from the current project and I use that any time I want to 'reset' my project view. I've often wondered about trying to make that generically useful to share. I don't feel vertically cramped much now I'm on 27" / 4k. My 3 windows have 81 lines visible, which is fully adequate for me, or 2 with 58 lines on my 13" laptop where I rarely code for long. Frankly, between WM workspaces and Emacs tabs I am usually very comfortable on a single monitor plus the laptop for comms (Slack etc.). The time I've had much use for 2 full monitors is when I need to do web dev, when I like a side portrait monitor for the browser and console/etc. while maintaining my full 3-pane code view. I suppose it would be the same for any graphical project where I might want to keep the execution of it and the code environment separate.

Thanks :-)