Modal text editors are definitely not my thing, but anyway this looks like a huge improvement on vim.
Still a shame that it is entirely console-based. It's 2016 people! We've had GUIs for literally decades.
Still a shame that it is entirely console-based. It's 2016 people! We've had GUIs for literally decades.
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.
Maybe Kakoune does the same, I haven't checked. I also second the first child's note that being console based is a feature.
fta:
>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.
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?
> We've had GUIs for literally decades.
Not being destructive of user input, for starters.
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.
No applications running in the terminal will be able to tell the difference between these two different key presses.
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.
I also absolutely agree that this is the correct way for an editor to be implemented.
Jokes aside, do you understand the architecture of a system better from a diagram than from a 2 page description?
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.
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.
Granted, it won't support using variable-width fonts as-is; but that's never been a problem for me.
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