Hmm, your tone indicates were this is likely to go.. but...
Emacs can have tabs and it can have goto next etc. What do you want? for them to override out of the box the default method of buffer and frame mgmt in emacs?
Emacs can have tabs and it can have goto next etc. What do you want? for them to override out of the box the default method of buffer and frame mgmt in emacs?
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. For an exact example of what I wanted, just open GVim. You will notice that tabs are added on top of the existing Vim concepts, such as buffers, and you can easily use Vim/Gvim without actually using tabs. You can even disable the tabbar.
I couldn't get that without major hassle.
I don't really want anything from Emacs, I'm just pointing out that:
- Emacs is frequently aggressively promoted as some sort of holy grail of text editing
- people say that they are using an editor such as Sublime which does what they want
- Emacs folks then point out that Emacs can do whatever Sublime can and more
To which I'm just giving 1 data point of Emacs not being able to do what Sublime does out of the box. 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.
Anyway, different philosophies, both successful.
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.
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.
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.
I do agree that emacs is great, but many aspects of its behavior are dictated by limitations of old machines and can be improved.
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.
People could do lots of things before written language was developed, so I'm pretty sure that's far from the truth.
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.