Especially since Emacs prides itself on being a jack of all trades, unlike the "limited" Sublime or Notepad++, for example.
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.
You are quite free to do that: go forth and freely implement your own tabs if the existing tab packages don't do what you want! Heck, you might even get the emacs dev team to include your package in the default elisp packages.
You don't have tasking authority for the emacs devs; it's puzzling that you seem to believe you ought to.
You're probably right, I shouldn't have been ranting.
On the other hand, I'm a bit tired of the holier-than-thou attitude of many Emacs (and many Vim users) on internet forums.
In my case I voted with my feet already :)
Well, think back to when you were a kid in school. Did the high-schoolers consider themselves better-educated than the first-graders? Almost certainly. Were they right? Indubitably.
vi & emacs are, simply, superior to the alternatives (albeit imperfect in themselves). It's a recasting of the Blub Paradox: someone using a moderately-powerful editor can see how it's better than Notepad or nano, but cannot see how emacs or vi is better than his own editor. From his perspective, users of better editors are self-congratulatory and delusional — the problem is that his perspective is wrong: there is an objective ranking of editors, and his is worse than theirs.
> In my case I voted with my feet already :)
In the long run, that's like being truant. Sure, it saves one some miserable hours in school, but those miserable hours buy one an education.
Life's too short to use Atom, Eclipse, SublimeText or TextMate.
And if you create artificial barriers to entry, don't expect many people to stick around to enjoy the supposed benefits at the end of the rainbow.