By real autocompletion dropdowns, I mean dropdowns which are different from editing buffer. That means whatever is the colour of the code/background underneath, they won't blend in in confusing ways. VIM does coloured completion drop-downs, but they're still just buffer-like text. Unless you mess with your theme manually, there's a chance it will blend in and confuse you one day, because there's no real frame around it.

As for markers, I know they're supported by Vim. That's why I'm saying better. For example Vim can't do single-pixel column marker (or specifically, create a line between columns). I can do hacks to highlight one column only (100th for example), but then highlight/copy on the terminal is broken, because in reality I just have spaces displayed after my code. Similar thing with region folds - they don't need to take the whole text row and the description of the fold can go off-buffer on a side.

Basically you can do everything with text. You can even print out "this is a placeholder for an image of a sad green frog looking at a computer screen". But actually displaying that picture is better ;)

> By real autocompletion dropdowns, I mean dropdowns which are different from editing buffer.

Fair point, it's my biggest gripe with Vim's autocomplete--which I love. That being said when it works, it's more efficient than any other autocomplete I've seen in a text editor, since it's practically the shell's autocomplete.

> Basically you can do everything with text. You can even print out "this is a placeholder for an image of a sad green frog looking at a computer screen". But actually displaying that picture is better ;)

Once again, valid reasoning, but that's not the point. No one (at least I hope not) is seriously advocating TUI's for graphic design, we're talking about editing text, and that's where Vim excels.

A GUI editor can do everything a terminal based emulator can; there are lots of things a GUI editor can do that a text editor can't. Some examples were given in another reply. Others include inline previews of things like latex equations or images, documentation tooltips, unobtrusive autocomplete popups, proportional fonts, proper mouse interaction, working well with window managers, and basically complete freedom to design the interface in a way which is optimal for whatever task rather than shoe-horning it into a grid of text.

What is the advantage of terminal based editors? As far as I can see, ubiquity, which is made less compelling when you need a host of plugins to do the things you mention.

Terminal editor enthusiasts seem to be under the effects of something like the Blub paradox, where any feature of a GUI editor described to them is dismissed with "why would I ever need that?" while anything in terminal emulator can do is considered essential.

> A GUI editor can do everything a terminal based emulator can; there are lots of things a GUI editor can do that a text editor can't.

Really? I'd like to see sublime handle text manipulations with the same efficiency and precision that Vim provides.

> What is the advantage of terminal based editors? As far as I can see, ubiquity, which is made less compelling when you need a host of plugins to do the things you mention.

What about integration with the shell? It's not merely a matter of ubiquity: I don't really need a document tree when I have the entire terminal at my disposal a :sh or :wq away.

> Terminal editor enthusiasts seem to be under the effects of something like the Blub paradox, where any feature of a GUI editor described to them is dismissed with "why would I ever need that?" while anything in terminal emulator can do is considered essential.

This would be an apt description if the majority of "terminal editor enthusiasts" were as inexperienced with GUI editors as their GUI counterparts, but in fact the opposite is true. Most Vim/Emacs users tend to have hundreds of hours experience working with GUI editors, but are for some reason convinced that they (the editors) were inferior. Finally, let me give you an irrelevant (but fun) fact: PG, the original proposer of the Blub paradox, uses vi.

"Really? I'd like to see sublime handle text manipulations with the same efficiency and precision that Vim provides."

I think you've misunderstood the claim here. The claim was not that all existing GUI editors do all the things that all existing terminal editors do. The claim is that a GUI (not a GUI editor, just a GUI) can do everything a console can do, and then do more things besides.

The claim is obviously true, because a GUI can embed a terminal interface in itself, and then augment it. I use emacs that way. It's emacs, but it also can do buttons, menus, proportional fonts, etc. (... not that I use any of those things, but it can), and all sorts of things it can't do in terminal mode even though it's literally the same executable. The point is that the GUI environment is intrinsically more flexible because the GUI has a superset of capabilities, not that a traditionally-GUI-centric design with heavy mouse and menu usage is superior.

Your first two points are simply features, and there is no reason they can't be implemented for GUI editors. In fact they are available for many of them.

The anecdotal suggestion that people who prefer a GUI simply don't know what they are talking about is just pure snobbery. I know both and I still prefer a GUI. You're right that the appeal to the authority of PG on this subject is irrelevant.

>Really? I'd like to see sublime handle text manipulations with the same efficiency and precision that Vim provides.

Can you give an example of an efficient/precise text manipulation that vim can do that sublime can't?