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 use ido-switch-buffer instead of helm for quick switching. Should I switch to helm?
1790 buffers 20295782 1774 files, 1 processWith 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)))
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))))
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'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.
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
Yet another option is not to use emacs if it does not fit your requirements and preferences.
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 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.
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)
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.
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.