You don't need tabs in Emacs; use buffer instead. Helm has a really good interface to navigate open buffers. I usually have 30-50 buffers open in my emacs. Now how does vim handle that many buffers?

For what is worth, I have currently 755 buffers open on my emacs session. That's probably on the low side as I restarted my session recently (i.e. in the last 7 days). I usually have 8 buffers showing (vertical + horizontal split across two windows) at any one time. I don't even known how a tabbed interface would look like in this setup.

I use ido-switch-buffer instead of helm for quick switching. Should I switch to helm?

I have an elisp function that opens every file in the projects I'm currently working on. I run it when I start a new session.

  1790 buffers        20295782                  1774 files, 1 process

I prefer lazy-loading both packages and files, but still having recently-worked-on files available for quick opening, since I sometimes do restart Emacs :)

With the below form in my .emacs.d/init.el, I can restart Emacs and the first time I do C-x b I get to pick from files I had opened in the previous session:

    (use-package ido
      :init
      (setq ido-use-virtual-buffers t) ; treat closed files as open buffers for C-x b
      :config
      (ido-mode 1)
      (ido-everywhere 1)
      (use-package recentf
        :init
        (setq recentf-auto-cleanup 7200 ; clean list on idle rather than startup
              recentf-max-saved-items 2000)
        :config
        (recentf-mode 1)))

That is, ido-use-virtual-buffers will put closed buffers at the end of the buffer list, while recentf makes that list of previously closed buffers persistent across sessions.

Also, after opening vc-tracked files, I want subsequent find-file calls to match on all non-ignored subdirectories of that repo, not just the directory of the current file, so I use ffir to add tracked subdirectories to ido's work directories:

    (use-package find-file-in-repository
      :ensure t
      :config
      (setq ffir-avoid-HOME-repository nil)
      (defun ffir-repo-subdirectories ()
        "Use ffir to put projects into ido-work-directories.
    This makes useful files show up even if you haven't been to that
    sub-folder yet."
        ;; TODO: compare emacs25 project-find-file
        (interactive)
        (let* ((repo-directory (expand-file-name
                                (ffir-locate-dominating-file
                                 default-directory
                                 (lambda (directory)
                                   (ffir-directory-contains-which-file
                                    ffir-repository-types directory)))))
               (file-list (funcall (ffir-directory-contains-which-file
                                    ffir-repository-types repo-directory)
                                   repo-directory))
               dir-list)
          (mapc (lambda (p)
                  (add-to-list 'dir-list (file-name-directory (cdr p))))
                file-list)
          dir-list))
      (defadvice ido-merge-work-directories (before advice-merge-repo-subdirs first nil activate)
        (mapc (lambda (d) (add-to-list 'ido-work-directory-list d))
              (ffir-repo-subdirectories))))
    

(ffir is a fairly small dependency for a vc-general "list-non-ignored-files", though perhaps there's something built-in in Emacs' vc.el I should be using instead)

There are multiple helm-like plugins for vim, which can be used to change buffers. Tabs, on the other hand, are used so that you can, for example, have a tab with a vertical split and buffers A and B, and another tab with just one big buffer, and so on.

Well then you could try perspective-el for emacs

> I tried Emacs/Spacemacs and for example, there's no decent tabbed interface. I mean a real tabbed interface, at least as good as Vim's.

It's been ages since I was a vi user, and I never used tabs. I took a look at http://vim.wikia.com/wiki/Using_tab_pages, and it sounds like tabs are just what emacs would call windows, which have been there for decades at this point. I'm guessing that's not it, so … what is?

Does https://github.com/krisajenkins/evil-tabs not solve your problem?

Also, what is wrong with 'write it yourself'? You are presumably an intelligent human being; the whole point of free software is that you are free to do whatever you like with it. If there's a feature you want, implement it (or hire someone to do so)!

> I tried Emacs/Spacemacs and for example, there's no decent tabbed interface. I mean a real tabbed interface, at least as good as Vim's. The answers I got on this topic ranged from: "you're not going to need it" (how do you know what I need?) to "use this random package which kind of provides a limited subset of the tabbed interface UX" to "write it yourself" (...).

I'd like to offer a different explanation, which I think it much more truthful and reflects the Emacs way(tm).

In Emacs everything (and I mean everything) is represented by the same type of primitives: Buffers made out of text. Every interaction with such a text-buffer is represented as lisp-code implementing an Emacs mode.

This is the core of Emacs. Everything in Emacs must build on this. No exceptions. And that's incredibly powerful.

Because of these "limitations" it means everything (and I mean everything) in Emacs can be processed using the same primitives, the same functions and the same keys.

There's no magic buttons, or drop-down lists, or special UI elements exempt from this.

I can search/grep for text in any buffer. I can recursively grep for results in my grep-result buffer. I can navigate these search results, the same way I would navigate a code-document. I can enable spell-check in any mode I like (like Git commit-mode). Etc etc.

It also means that any customization I've done to any part of Emacs, I can apply to any third party extension as well. It means I can customize and interact with a extension which extends another extension. There's almost no limits to what you can do with these simple but powerful primitives.

And all that in a simple and uniform way. Everything at your finger-tips. Both as a Emacs-package developer and an Emacs-user.

Once you get used to it, it's really a captivating thing and everything else starts feeling wrong.

If you want to make a tabbed interface... How are you going to represent that using those primitives? How will that work?

How will you make sure you tab-line/row stays in place and is exempt from other rules which governs the current buffer and the Emacs mode it runs (not to mention the user-customized rules for this mode)?

I'm not saying it can't be done. I'm just saying it wouldn't be very Emacsy, and it's probably not a trivial thing to implement either. Especially when you consider that all your code also needs to work in a terminal. Emacs should be able to work 100% in a SSH session too, you know. At least for me, that's one of it's many selling points :)

So non-trivial and not very Emascy. That doesn't sound like anything which is going to get lots of developer-time. Neither core nor third-party.

Emacs has frames (aka "windows" for non-Emacs lingo) so there is no theoretical reason it couldn't have tabs. I understand the complaint about tabs. In Vim I have the opposite complaint: no frames.

Tabs can work in a terminal; Vim has them.

If I were an Emacs developer I wouldn't bother with tabs because we already have frames, but there's nothing non-Emacsy about tabs.

It could work well if tabs contained frames instead of buffers, i.e. as a sort of workspace management. I guess this could be done right now by using a tabbed window manager.

I actually think it could work well if you could choose one or the other. aquamacs outlines the paradigm that I would generally use (frames usually equal buffers, but a tab can contain two buffers in necessary, like you often do in org-mode). I'm glad emacs doesn't ship with a tab paradigm by default, but it's easy enough to add one if you need.

Vim has (more or less) the same buffer paradigm. And it still has a proper tabbed interface.

It can be done, it's just that there's no interest in the community or from the developers.

I can understand that, on the other hand such things make sure that a large number of people won't ever enter the Emacs community, for good or bad.

If you don't believe me about the popularity of the tabbed interface, I present:

- the addition of tabs to Vim

- the #1 feature request for Visual Studio Code, now implemented, tabs

I typically open Emacs when I boot my laptop, and close it when I shut down (which happens only every few weeks); this is typical of a lot of Emacs users. In those few weeks, I open hundreds of buffers and I rarely close them: my buffer list contains all the TeX files from the paper I'm working on, the code files of a couple different projects, many one-off files, IRC buffers, twitter buffers, etc. Yet, switching to the buffer I want is easy, fast, and painless. Using ivy (helm or ido-flx are good too), I can quickly switch to any buffer by typing part of its name. This paradigm would be totally impossible (or at the very least, most impractical) if I had one tab-per-buffer.

I think if Vim or Visual Studio Code had a similar quick way of switching between buffers, people would be less reliant on tabs. As for Emacs, it seems like a waste of time and effort to implement a feature that most Emacs users would not use.

Tabs are an inefficient representation of Emacs buffers, as they are not mere views into files, and sometimes not even intended for the user to see. That said, there are packages out there if you really want them. Or you implement it. There are the facilities. But the default Emacs is an API for other packages, and plugging in tabs would have implications on most of the elisp out there.

Yet another option is not to use emacs if it does not fit your requirements and preferences.

So you mean GUI tabs I guess? How would one even begin to display hundreds of tabs on a screen? I hate that Firefox doesn't make it as easy to switch tabs as emacs makes it easy to switch buffers.

IIRC vim's tabs are just views into buffers - you don't need to have a tab per buffer at all. So you can switch between tabs, or between buffers in a tab etc.

What's wrong with speedbar-mode?

IIRC it used to be impossible to display it in a split, it required a separate frame (that is, windowmanager-level window).

There were some dirty hacks to fix that, but led to more problems with window & buffer switch ordering (and layouts for things like ediff)

May all be fixed now, this was years ago when I last played with it, but haven't really found the need for it, instead of ibuffer-mode, ido-everywhere, and smex. (Probably helm too if I can ever be bothered to set it up properly)

You might as well be a lisp programmer who doesn't think recursively.

The analogy would hold if Emacs would be used only for Lisp. But I see it recommended from time to time as the development environment for various non-Lisp programming languages.

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.

My point was in emacs you don't think in tabs.

And my point was that I should be free to think in whatever I want. If the other bastion of go-your-own-way, Vim, has tabs, I'm pretty sure the Emacs could have them as well.

Especially since Emacs prides itself on being a jack of all trades, unlike the "limited" Sublime or Notepad++, for example.

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?

I've tried Emacs and I've tried several tab packages. None of them seemed to work properly, and I wasn't expecting much.

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.

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.

> And my point was that I should be free to think in whatever I want.

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 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 :)

> 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.

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.