In emacs frames are distinct windows on the display manager. Then you have buffers which usually are a file you are editing but also contain things like directories of files, list of buffers and messages from emacs. It's really easy to switch between buffers using a couple of key commands. Another command brings up the list of buffers which you can search with the same search command you use in a file. You can sort or filter the list. With all this you really don't need tabs cluttering up the screen.

> I just wanted a visual list of frames or whatever they're called, preferably at the top of the screen, preferably visible despite whatever mode I was in and preferably easily manageable through keyboard commands.

The list-buffers command provides exactly that: a list of buffers, easily manageable through keyboard commands. You can have a window containing that list at the top of every frame. I don't think that you'd end up actually wanting that, since in emacs it's common to have dozens or hundreds of buffers open, but you can if you like.

If you'd prefer a look like you're used to, there's https://www.emacswiki.org/emacs/TabBarMode

Again, I don't think you'd actually want to do that, but you can.

> To which I'm just giving 1 data point of Emacs not being able to do what Sublime does out of the box.

It is perfectly able to, being a Turing-complete text editor. But trying to do that doesn't make sense.

> And "code it yourself" is not a valid reply since a flexible and robust tab management solution in the Emacs environment is not a trivial project.

Neither was a text editor, neither was a Usenet client, neither was a web browser, neither was a git interface, neither was org-mode — and yet all those and more have been done.

Somewhy many conversations about emacs go like this:

A: emacs is awesome, you should use it.

B: I can't use it since it misses this one feature i like.

A: it is a stupid feature, but there are plugins doing half of what you like, and you can create another plugin.

B: it is too much work, i don't have time to do that.

A: people have created plugins that required even more work...

Emacs is a great editor, and for people who get used to its ui limitations, it is often the best editor, but for new users the ancient ui is a huge roadblock, and most users never will get past it.

Not implementing modern ui and not being interested in what new users like is a perfectly valid choice for emacs developers, but then saying emacs is great and not liking it is the users fault is illogical.

> for new users the ancient ui is a huge roadblock, and most users never will get past it.

Reading & writing is a huge roadblock, but most people do get past it — and the UI of emacs is far easier than learning to read & write.

> then saying emacs is great and not liking it is the users fault is illogical.

No, emacs is great and users should be humble enough to try to learn it, rather than arrogant enough to think they can do better. It's like a kid who says, 'I don't want to read; my parents can read to me.' That's no way to go through life — and neither is using an inferior computer interface.

The difference is the reward one gets after passing the roadblock. Without reading people can't do anything, without emacs most developers manage to work happily.

I do agree that emacs is great, but many aspects of its behavior are dictated by limitations of old machines and can be improved.

> Without reading people can't do anything, without emacs most developers manage to work happily.

Illiterate children are quite happy, too — they have no idea of the worlds which open up before them when they can read. They literally don't know what they are missing.

So too for people not using a powerful editor.

> Without reading people can't do anything

People could do lots of things before written language was developed, so I'm pretty sure that's far from the truth.

I hoped the meaning would be clear from context, but i see i should have been more careful in writing the comment.

Things that a human (who is living now) misses by not learning to read, far outnumber things a programmer misses by not learning emacs. There are very few jobs someone illiterate can perform. But non emacs user can do almost anything that emacs user does, almost as good.

So my argument that benefits from learning reading and learning emacs are not comparable, is not far from the truth.

Check out sr-speedbar. It is not exactly what you want because it represents the current directory of whatever file the current buffer is visiting, but in terms of a UI-ism it is very very close to what you want. You could probably modify it to bind to Ido-buffers instead of the current directory and essentially have exactly the functionality you want.

In the regular speedbar you can hit `b` to see a list of buffers. I imagine it works with sr-speedbar too.

Very cool! I did not know that. And 'f' toggles back to the files view.