I've heard developers say this before, they want tab bars or good fuzzy search. The puzzling thing is, I feel almost exactly the opposite. I've used many other development environments (over the last 50 years), some for years at a time and others on off for many years: Intellij, Xcode, Adobe products, Textmate, Vim, etc.
These other IDEs and editors certainly have their own strengths and are in some ways better than Emacs for some tasks, but for navigating between tasks, projects, and recently used files Emacs is the best tool I've ever used.
To visit a file, whether for the very first time or to just get back to the previous one you were using, the find-file command is Ctrl-X Ctrl-F. This does exactly what I want about 90% of the time. I type a few letters and because of completion I get to what I want in an instant. This command is one of the first ones that beginners need to learn to open a file for editing. It's trivial to rebind the visit-file command to any key you like (Spacemacs uses Space-F-F). You might be thinking, "Oh yeah, but sometimes I want to open a file read-only", well there's a command for that too its find-file-read-only, bound to Ctrl-X Ctrl-R. Or maybe you're thinking, "What will I do when I want to insert the contents of a file at the cursor?" maybe Emacs won't work for me since I do that a lot. The good news is: there's a command for that. You might be thinking "Thats swell, but sometimes I need to see the file contents in hex!", well there are commands for that too.
On my system there are almost 500 available Emacs functions containing the word file. I was able to find that out with the built-in documentation that gives me access to descriptions of all these functions and key bindings in just a couple of keystrokes (C-h starts the best built in help system I've ever used, period. You can even jump into the code that implements all of these functions.) I recommend sticking with the simple find-file command for a week or two before delving into the many fascinating options available for the Emacs hacker.
If you want to actually see the files that you have already been editing, Ctrl-X Ctrl-B lists the buffers in use. This is a bit like looking through tabs, but Emacs manages hundreds of simultaneous buffers at once and some users like using the buffer list to see all of the current work across many tasks that have been going on over a period of weeks. You can navigate rapidly though the buffer list and pick a buffer to be displayed in your current window pane or other panes or windows. Jumping between buffers, windows, panes within windows is all done with a couple of keystrokes so its fast and easy. If you know the name of the file/buffer already you can use Ctrl-X B, the switch-buffer command to open it directly without browsing the buffer list.
Maybe it's not a current file you want and maybe you don't remember the name but you do know where it is located. The amazing dired interface displays directories and makes it easy to list, rename, or edit (or copy or change permissions, etc.) the files within a directory or it's parent directories or children. Again the interface is right from the keyboard so it is very fast and easy. Dired opens automatically when you do find-file on a directory name. Sensible name completion and shell like navigation make it easy to get places in the file system or remote file systems though the magic of Emacs ability to treat file systems on remote machines like local files if the user has ssh access. Dired is great, there is nothing like it and its various extensions provided by the Emacs built in package system.
These simple to use commands and a couple of commands for splitting windows into panes and jumping between them will get you a long ways and in no time you will discover that you don't miss tabs anymore. I really appreciate the extra screen real estate I have because I don't need tabs or tool-bars in Emacs. I can easily see three or four files at once since the navigation buffers for dired and buffer lists open only when needed.
I know, you're maybe wondering if a form of Emacs Stockholm Syndrome has me under it's spell: windows, panes, buffers, files--it just sounds confusing. Yes, tabs are a simpler idea. Emacs has been around so long that its nomenclature is a bit archaic. What a normal developer would call a window is a "frame" in emacs. I usually like to have a single large frame while I'm using emacs, but you can open up a multiple Emacs Frames, say on different displays, and hop between them with a keystroke or two. Sometimes that's helpful.
Inside a Emacs Frame you can have multiple re-sizable horizontal and/or vertical splits that give you a number of separate panes for editing in. I usually have two or three while I'm working. They work great and are easy to use with a few of the built in commands. The biggest problem is that Emacs documentation calls them "windows". So in Emacs terminology a Frame contains Windows (in modern terminology we would say the Emacs windows can be divided into panes or regions).
A Buffer is just an editing session (usually, although documentation and system information is also held in buffers). The buffer has a cursor and some other features and is usually associated with some underlying file, but the buffer can be written to a different file (kind of like Save-As) and now it becomes associated with the new file name. Multiple buffers can be opened against the same file providing different views of the the file and they can have different cursor positions and different editing modes. Is a buffer also an Emacs Window or Emacs Frame? Buffers exist independently of the user interface to the buffer. When you open a file in a new buffer or switch to an existing buffer for a file, the buffer is presented for editing in one of the Emacs Windows in one of the Frames. The default is the current Frame in use. This makes switching to a buffer like clicking on a tab. But the architecture is more flexible.
The commands I've mentioned work in default Emacs right out the box. More experienced users like some of the fancy searching and auto-completion packages like helm or ivy. There are also speedbars for those that like to mouse-click on a project directory outlines and sophisticated project management tools like projectile with fuzzy searching across the files withing the project. These add on packages are so easy to add that the real problem is having too many features available.
I should mention that there are many fancy fuzzy search tools, but I really don't use them myself, I get by with the basic functions provided by Emacs for grep'ing and searching. And if you still want tab bars there's a package for that, tabbar mode.
Related to project management and along with org-mode one of the most recommended Emacs packages, magit, a really great interface to git that is very well integrated with Emacs.
- Tabs are not present in Emacs, but C-x C-b will list all open buffers
+ Fuzzy file search : you can take a look at the popular Ido-mode
+ eshell is pretty powerful, if you think about it, you have all the emacs search functionality etc. available in a shell inside the editor itself.
I am not trying to popularise emacs, but "inflexible" is not something that you associate with emacs. If anything, it is the bewildering array of choices that is one drawback. Plus, you should really try:
+ org mode : what is the standout feature now a days. You can even do literate programming in the org mode, so can be viewed as an alternative to Jupyter, for example.
The real gripe for me about emacs is that it is single threaded. So a long grep launched off will freeze the entire editor.
> The real gripe for me about emacs is that it is single threaded. So a long grep launched off will freeze the entire editor.
Are you running grep with `shell-command` (M-!)? Using M-x grep, `async-shell-command` (M-&), and invoking grep directly in shell, eshell, term and ansi-term all leave emacs as responsive as normal for me. shell-command is the only one that seems to hang.
I'll also add ivy[1] and helm[2] as alternatives to Ido which are very popular completion systems with integrations that span the package ecosystem.
> - Tabs are not present in Emacs, but C-x C-b will list all open buffers
I want a passive, not an active interface. I want to be able to visually scan the tabs. I want to be able to click them when I'm not in the mood for keyboarding. I want the tabs and the tab bar to not be ugly as sin :) Etc, etc. Heck, if Vim has them built-in (and Vim also has the same concept of buffers as Emacs), surely Emacs could (should?) have them.
> Fuzzy file search : you can take a look at the popular Ido-mode
I know there's modes for that, but open up a folder in VS Code. It's seamless, I don't need to configure it, it just works, they bundle ripgrep for me, etc. The UI/UX are also slick.
> The real gripe for me about emacs is that it is single threaded. So a long grep launched off will freeze the entire editor.
Yeah, Vim is kind of like that, even though it's recently gotten async.
You do not need to see what "tabs" are open at all times. You only need it when you want to switch. It's also incredibly limiting. At this moment I have 127 buffers open in emacs. How would you deal with that?
But your eyes don't. You do not need it to be there at all times. But you'll refuse to try anything else and see that I'm right.
Emacs can do whatever you want but almost every single user switches off the permanent tabs, buttons, scroll bars etc. as soon as they realise they can because it is unnecessary.
>I want a passive, not an active interface. I want to be able to visually scan the tabs. I want to be able to click them when I'm not in the mood for keyboarding
Ibuffer is included in the gnu Emacs distro and does all of this.
It's true that tabs would be nice sometimes, but usually Emacs users have lots of files open all the time. The usual open-edit-close workflow doesn't really apply to Emacs sessions. An Emacs tab bar would resemble that of a browser with 100+ tabs, so the problem is that the people that would be capable of implementing that feature wouldn't use it in the end.
> * super powerful, easy to use, integrated command and fuzzy file search, also with a good UX.
Sounds like you should try ivy and its companions. Ivy offers fuzzy matching for all operations in Emacs (e.g., switching buffers, opening files, looking up documentation) and the counsel packages (e.g., counsel-rg) use that same interface to interact with external tools such as ripgrep or git grep.
Ivy has completely taken over my Emacs experience, and it did not require a lot of configuration, just a few keybindings.
As for a terminal, I don't have a Windows machine to test, but `M-x ansi-term` is pretty much exactly like a regular terminal: you can run any program in it, including htop or even vim.
EXWM/Fulltime Emacs user here... Well... No, ansi-term, sane-term etc are not like regular terminals, they can work for simple things but they are limited, limiting and buggy...
When I start living in Emacs I reduce significantly the dependency of the shell (tramp and dired do most of the business) and start using eshell a bit, but I still use terminator when I need a real terminal...
For all its flaws, the VS Code terminal is quite strong. I've been putting it through its paces recently and if only they'd offer an option for real full screen and proper splits, it could almost get all the way there.
There are very few respects in which Emacs is less functional than other editors (good integration with semantically aware refactoring tools is the primary one, imo), and it has excellent support for the only functionality you explicitly mention (command and fuzzy file search).
I'd want either:
* tabs with a good UX
or
* super powerful, easy to use, integrated command and fuzzy file search, also with a good UX.
I'd also want a terminal at least as good as the VS Code one, on Windows, to use with Cygwin.
With Emacs I'd have to learn a big bunch of terminology no other editor uses for a bit of flexibility while losing quite a bit of functionality.
Sadly for Emacs, I think that most devs are closer to my train of thought than to that of existing Emacs users.