Interesting, if he's architected it for that purpose, it doesn't have to solely be console based.
Neovim separated the client and server parts, and there are a host of clients (QT, HTML/Atom, etc) including the canonical one, from the docs:
When compiled with the |+clientserver| option, Vim can act as a command
server. It accepts messages from a client and executes them. At the same
time, Vim can function as a client and send commands to a Vim server.
>The first thing to realize is that non-modal text editors are extremely biased towards insertion. They make insertion easy (by making the default behaviour of most keys to insert a character into the buffer) at the expense of making most other operations suboptimal, by requiring hard to reach keys or modifiers (or, even worse, moving your hand all the way to your mouse).
i disagree whole heartedly that reaching a modifier key is some great expense. I can do many things very quickly in sublime and have never felt that there was any time loss hitting a modifier key. compared to the expense of:
1) occasionally entering several commands by accident when in the wrong mode and having to correct it
2) lack of ease of use both for initial learning and for other coders who might have to type something on your comp when pairing and they dont use your exact modal editor
3) lack of transitionable skills to other editors, difficult discoverability, and many other side effects of modal systems
i respect the choice of others to use modal editors but it is absolutely not some cut and dry thing as the author presents it.
i can do things in sublime at probably 90% of the speed of someone in vim and perform many or all of the same operations including some you cant do in vim etc thanks to plugins.
aside from all that, reading, writing, and navigating code are not my bottlenecks for productivity anyway.
> 1) occasionally entering several commands by accident when in the wrong mode and having to correct it
Maybe for beginners, but this almost never happens after a while, and hitting undo takes 0 time.
> 2) lack of ease of use both for initial learning and for other coders who might have to type something on your comp when pairing and they dont use your exact modal editor
You have a point for learners, but I'm not going to pick my tools based on what other people need, I'm going to pick them based what I need.
> 3) lack of transitionable skills to other editors, difficult discoverability, and many other side effects of modal systems
Don't see this at all. Vim-like editors have a pretty standard set of objects/verbs, many programs use vim style keys (less for example). How are you going to transition say, IDEA, or RubyMine, or Emacs specific key shortcuts or plugins?
Update: 2 more
> I disagree that reaching for modifiers is some great expense
It is when you are using "commands" at the rate an experienced vim user is. Excluding single char/line navigation spam, I use about 20-70 a minute if I have a good conception of the change I want to make.
> i can do things in sublime at probably 90% of the speed of someone in vim and perform many or all of the same operations including some you cant do in vim etc thanks to plugins.
A) I doubt that. I've seen people rip through stuff in ways that cannot be done without modal editing. For more concrete examples, look at some vimgolf problems and see how sublime solutions compare. keystrokes are a good measurement IMO because it's independent of user typing speed. Not that the average vim user edits like that, but just as an example of what's possible.
B) Saying "with plugins" is a pretty arbitrary measurement, unless you're trying to claim there are plugins in sublime which you can't implement in vim. Do you have a specific example?
Yes, lots of them. The one on my work desktop is different from the one on my home desktop, and they don't talk. Then there's the router, the NAS, the VPS, and so on that don't have screens, let alone GUIs.
What would a GUI bring to this that isn't possible in the console? You can use a mouse to issue commands to console programs, after all: if you want to use your mouse to scroll through or select regions of text, you can.
I find that console apps are far less intuitive when it comes to visual thinkers. I also am not too keen on modal editing, it doesn't match how I do most things in life. I don't have to switch out my teeth when eating vs drinking. It just doesn't seem natural to me. I've always found I'm more productive with a GUI. Command line is great for simple tasks and executing commands, but editing files has always seemed less than ideal. You have to remember so many key combinations and commands and track what mode you are in and what modes are available. I would rather spend that brain power on solving problems.
> I don't have to switch out my teeth when eating vs drinking.
But you do switch how your mouth is working when switching between eating and drinking. In one, you masticate and move food around your mouth before swallowing once (maybe twice), whereas the other involves directing fluids back to your throat which acts in a near-continuous swallowing action.
> You have to remember so many key combinations and commands
They become muscle memory after an admittedly non-trivial amount of use. Yes, it is an investment in your future usage of that tool.
And to be fair, you had to memorize C-x, C-c, and C-v at one point too.
He doesn't control his mouth when switching between eating and breathing, I'm pretty sure that it's part of the autonomic system. You kind of made his point since there's no way Vim actions actually become fully reflex actions, especially the powerful stuff that separates Vim from a good IDE, since the vast majority of those really complex actions will be done at best dozens of times per day (and I'm being generous here).
> there's no way Vim actions actually become fully reflex actions
You might be surprised. Maybe not quite the level of a true "reflex", but it can get close. I find I not infrequently get weird compile/test/spellcheck errors when I'm not using vim and go back to find a string of vi keystrokes in the middle of my document that I typed without consciously realizing.
If I'm not mistaken, the reason vim doesn't allow a lot of key bindings (like control+shift+key, control+symbol) is because of the terminal, so in theory a GUI should allow to bind them.
You know what? I was ready for bullshit and you actually gave a compelling answer :P Yeah, that's a bummer, but there aren't that many instances of that drawback (it's bitten me a couple times maybe in many years?) and on the other hand text mode gives a lot of convenience like being able to use it from SSH and other niceties.
Anyways, I don't think such behavior is inherent to "the console", only Linux's particular implementation (i.e. it's tty's fault) which admittedly is pretty outdated and relies a bit too much on control characters.
IMHO the original question still stands:
> What would a GUI bring to this that isn't possible in the console?
In my experience text mode brings a lot that GUIs don't, and not the other way around.
Plus it's easier to make a GUI wrapper for a console program than a console wrapper for a GUI program.
Visual editors assign various non-editing tasks to command sequences as well. Pycharm moves the cursor around parenthesis with C-m for example, Cmd-M minimizes windows, and Cmd-I does formatting.
While Kakoune is mainly terminal oriented, it has an experimental json interface that while pretty basic can be used to implement a GUI to it.
I took a stab at it, and while it still needs half of the features to be on par with the terminal UI, it gives an idea of how difficult it would be (it isn't): https://github.com/doppioandante/kakoune-qml
Still a shame that it is entirely console-based. It's 2016 people! We've had GUIs for literally decades.