Just one example of that - recently I needed to create some UUIDs to use in my code. Previously, I would have googled a UUID generator or used uuid on the command line and then pasted the output into my editor. With Emacs, I was able to easily insert the UUID directly into my code using `C-u M-! uuidgen` (that keyboard shortcut inserts the output of the given command at the current cursor location).
There are emacs packages for tree views[0] and tabs[1], but as you note the built-in buffer management is more powerful. Stuff like Helm or Ivy is even better!
There's also an emacs uuidgen package, which can generate a uuid & insert it with M-x uuidgen; you could of course bind it to a key sequence if you use it frequently.
Even with Atom finding files is way faster than clicking through the tree viewer.
There's even a dozen of generator presets integrated, you can just easily invoke them from your keyboard, without pressing all modifier keys at once.
And PyCharm even has all the keyboard navigation as well, you can even get emacs or vi keybindings, if you wish, I only use the mouse when the app's already running and I'm going through the log.
So for example although the (very old) version of Emacs (/usr/bin/emacs) that comes with OS X was built in such a way that it can communicate with the user only via the terminal, the following command line will install a GUI-capable Emacs:
brew tap railwaycat/emacsmacport && brew update && brew install emacs-mac
(The simpler command line `brew update && brew install emacs` would install a GUI-capable Emacs, too, but delivers the pure-FSF version of Emacs, which for mac for many years now has been buggier than the FSF version plus Mitsuharu's patches, which is what the first command line delivers. In the past there have been times when `brew install emacs` would install an Emacs that is just not usable because of bugs while `brew install emacs-mac` would install and Emacs that works fine.)
Whether or not the code Jane Street added to Emacs can be used with a pointing device I do not know.
When you need to open a shell in a certain directory, do you use cd or do you navigate using a GUI? I much prefer the tab-completion I get with the former, especially in hierarchies with high branching factor.
Just like using CLIs does not preclude using a mouse, using GUIs does not preclude using keyboard shortcuts ;)
Quick Explorer example (sometimes I mix and match, maybe I want to show something to a colleague):
explorer . # does what you'd expect; alternatively Win-e
Alt-d # focus path in Explorer
Start typing, Explorer autocompletes stuff
Enter
Tab around, if need be, to change panels
And this is with what is, basically, the dumbest common GUI file manager out there :)
Really depends on the workflow. If I know where I'm navigating then I prefer cd, if I don't then a gui is better than a cd/ls loop. Fortunately programs like ranger cover the latter quite well too.
This is how I do all my file navigation.
This is through cygwin, real linux is another story. I don't know what the difference is between how windows and linux mount remote drives, but the performance difference is stark, ls on a mounted network drive in linux is essentially instant but there is a noticeable lag doing the same from a windows machine.
You can turn on mouse support for terminal apps like Vim and Emacs and still click things like the file viewer, scroll text with two fingers and resize windows with a mouse.
You just have to configure it.
This to my mind is the real difference between classic editors like Vim and Emacs and GUI IDEs.
With the terminal editors you can be at least sure that you'll get a comprehensive keyboard interface system, I haven't always found that with GUI IDEs especially when it comes to third party plugins.
Another reasons why I prefer GUI are auto complete, tooltips and context menus. Also for some documents like xml, also when working with other people’s code, I find it useful to collapse/expand blocks of text.
All these features pretty much require a GUI-based editor.
For auto-complete, vanilla emacs has dynamic abbreviations; there are several packages for fancier auto-completion; company-mode, for example, works just fine in the terminal, as well of course as in the GUI (X11, macOS or Windows).
Likewise with tooltips, which in the terminal generally are generally displayed in a special region of the terminal instead.
Likewise with context menus, which can be shown just fine in a VT100 terminal.
Likewise with expanding & collapsing text ('folding'). Org-mode, to take just one example, is built on folding — and is easily one of modern emacs's killer features.
Seriously, give emacs a shot. Both Prelude & spacemacs are excellent configs for it.
Are there any advantages over Visual Studio + Visual Assist, for C++ or C# languages?
Because I see many disadvantages.
About text editor features, your workarounds have flaws compared to good GUI. For tooltips, that special region of the terminal is physically separate from the cursor. For folding, a separate, visually distinct indicators of what’s folded/unfolded help navigating the code faster.
Another text editor feature hard to do in text mode is spell checking for strings and comments. Color is already used for syntax highlighting, so wavy red underlines come handy.
But visual studio is more than an editor, it includes a build system, debuggers and profilers, package manager, and many more related features. Everything comes already integrated and just works out of the box.
A fully-extensible, flexible environment which anyone (even a secretary!) can easily extend.
> About text editor features, your workarounds have flaws compared to good GUI.
They're not workarounds; they are the features. emacs has a GUI. I repeat: emacs has a GUI. Tooltips in a GUI display as you'd expect. Folding in a GUI displays as you'd expect.
> Another text editor feature hard to do in text mode is spell checking for strings and comments. Color is already used for syntax highlighting, so wavy red underlines come handy.
Terminals support underlines!
> But visual studio is more than an editor, it includes a build system, debuggers and profilers, package manager, and many more related features.
Have you ever used emacs? It's more than an editor; it connects to build systems like make, maven, gradle, ant, what-have-you. It has its own elisp debugger, connects to gdb, SLIME provides an integrated Common Lisp debugger &c. It has a profiler. It has a package manager. It has a best-of-breed git interface, Magit. It has a best-of-breed personal organiser, Org-mode. It has multiple email clients (rmail, vm, gnus & notmuch come to mind, but there are probably more). It has multiple web browsers (emacs-w3m, eww, w3 & a new experimental WebKit-based browser). It has multiple image viewers. It has multiple terminals & its own shell.
Emacs is far, far 'more than an editor.' It's probably the single editor which is the furthest from being just an editor. Don't trust me: give it a shot! It really is a wonderful experience.
And yes, it has a GUI. Images, scrollbars, menubar, toolbar: the works. Runs on X11, macOS & Windows. And it also runs perfectly well in a VT100 terminal. You can use the same emacs locally and remotely, over SSH. It's pretty awesome.
Even if that’s true, we’re talking about development environments here, so secretaries are irrelevant. I’ve been programming C++ and C# for decades, for me, visual studio is quite flexible and extensible.
> Terminals support underlines
I specifically told about wavy red underlines for spell checking, and terminals don’t support that. Simple underlines are too intrusive i.e. they often mask '_', and don’t stand out visually from normal text.
> It's more than an editor; it connects to build systems like make, maven, gradle, ant, what-have-you.
I know it’s possible to integrate everything in Linux ecosystem. I just don’t want to waste my time connecting, integrating, and then supporting the setup that just works out of the box on Windows, with freeware visual studio.
No wavy red lines, but there's still two different types of coloring (letters vs cell background): https://i1.wp.com/www.tjansson.dk/wp-content/vim-spell-error...
So you can have underline, bold, italic, squiggles, I think even strikethrough. Also you can have tooltip "windows" but since they're harder to create and manage few applications use them. Those that do are generally based on ncurses, a library for TUI (think Norton Commander or Turbo Pascal)
Vim even has a spell checker built in.
What the terminal does not have is usually consistent support because terminal emulators are really shady, there's no actual standard (most just do what xterm does). For the TUI thing, there's also no real conventions plus I'm pretty sure both Vim and Emacs don't use ncurses and roll their own (see: lack of consistency).
You also need to cobble things together out of packages with varying degrees of quality and documentation, from long forgotten wikis and 90's pages belongings to ex post-docs.
Tooltips work in the terminal, they're just text after all. See Vim + YouCompleteMe (which, as the name indicates, also provides auto-complete): https://camo.githubusercontent.com/1f3f922431d5363224b20e994...
> I find it useful to collapse/expand blocks of text
For that you don't even need plugins, folding has been a standard feature for many years
e.g. I'm using ZSH specifically for it's command line autocomplete stuff. Emacs has helm for context narrowing and really good support for context menus. Vim will let you collapse/expand blocks of text including in XML using a mouse in a terminal window.
For spelling errors Vim will give you an straight red underline in the terminal and squiggly underline in its "GUI" versions. I assume that Emacs is the same.
I'm not suggesting you leave VS by the way. I'm just saying that your GUI only examples aren't GUI only.
But then most command-line editors are actually GUIs in the terminal with excellent keyboard support.
They show documentation (pulled from comments) for functions, classes and arguments.
> and context menus
For context-sensitive commands I use once per week or less often, so I don’t bother memorizing keyboard shortcuts for them.
> most command-line editors are actually GUIs in the terminal
Most developers don’t use command line editors. Here’s recent data from this year: https://insights.stackoverflow.com/survey/2018#development-e... As you see, 4 most popular editors are VS Code, Visual Studio, Notepad++ and Sublime Text, all of them are GUI applications. Only 26% developers use Vim, 4% Emacs.
and yet:
> Most developers don’t use command line editors. Here’s recent data from this year: https://insights.stackoverflow.com/survey/2018#development-e.... As you see, 4 most popular editors are VS Code, Visual Studio, Notepad++ and Sublime Text, all of them are GUI applications. Only 26% developers use Vim, 4% Emacs.