[viraptor]

> I don't understand why people need a GUI to edit text.

They don't need it, but GUI can provide nice things consoles can't. For example real autocompletion drop-downs. Or see-through file outline/minimap like the one in sublime text. (https://2.bp.blogspot.com/-Co2awzuaA_s/TqQCZ1wwFLI/AAAAAAAAO...) Or better markers for things like region folds, column positions, matching braces, highlights, etc.

[thegenius2000]

I don't think you've mentioned a single thing that can't be done by Emacs/Vim, with minimal customization. Personally I use Vim, which has great auto-completion (it's minimalist and extremely effective), extremely customize-able code-folding, highlighting and advanced navigation features out of the box. With a few plugins (like the NERD family, Syntastic etc.) it has all the features you mentioned, along with having insanely good performance and integration with the shell. And that's not to mention the advanced editing capabilities it has for managing text, which far exceed those available in editors like Sublime.

[nerdponx]

I've never experienced this "insanely good performance" from Vim or NeoVim. It's fine for editing code when lines are short, but as soon as the lines get long or the file itself it's long, or if I'm using all of those plug-ins necessary to replicate basic functionality in Sublime, it slows down substantially.

That said, I can't let go of modal editing, composeability, and word motions. Here's to hoping sublime implements them and I can relegate Vim/NeoVim to quick fixes in the terminal and Git commit messages.

[cyphar]

> For example real autocompletion drop-downs.

There's no reason a TUI can't give you "real autocompletion". Vim does pretty well in most cases.

> Or see-through file outline/minimap like the one in sublime text.

I personally don't see the benefit of that, but you're right that you can't see a zoomed-out version of your code in a TUI.

> Or better markers for things like region folds, column positions, matching braces, highlights,

All of those things are supported by Vim and can be done in a TUI. As for "syntax highlighters" that decide to italicise code, I don't really consider that a feature.

[viraptor]

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

[thegenius2000]

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

[unfamiliar]

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.

[thegenius2000]

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

[jerf]

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

[unfamiliar]

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.

[unfamiliar]

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