I've used vim quite a bit but it still never beat GUI editors for me. The lack of a mouse cursor was always a pain point - for example simple copy/pastes take notably longer. Moving a block of code below another block of code takes 1 second in notepad++ while in vim you have to go V 10d x 13down P or something along those lines, figuring out exactly what numbers to use there probably takes more than 1 second alone. It always feels claustrophobic editing a file in vim, like I'm having tunnel vision, and jumping around files to understand the structure of a program or write a feature that changes many things is more time consuming, and pgup/pgdn and arrow keys just aren't as good as a scroll bar.
Overall I'm glad vim exists so editing config files remotely is easier if I don't have the server mounted locally - it's definitely my favorite shell text editor so far but I'd take notepad++ or visual studio over it any day.
> Moving a block of code below another block of code takes 1 second in notepad++ while in vim you have to go V 10d x 13down P or something along those lines, figuring out exactly what numbers to use there probably takes more than 1 second alone.
dip}p
which would be pure muscle memory to an experienced vim user, and certainly faster than doing it with a mouse.
Vim isn't for everyone, but I mean, it's not really fair to criticize something because you don't know how to use it well yet (though complaining about the learning curve would be reasonable)...
> it's not really fair to criticize something because you don't know how to use it well yet
I don't see any criticizing, just "it doesn't work as well for me," which I think is entirely fair.
In particular, it seems like 'jimmaswell prefers an editor where you think of blocks of code as "I can see this on the screen" than "up to the end of the current curly brace," which seems like a legitimate difference in mental processing styles, not a consequence of lack of learning.
I've been using vim as my only code editor for probably 10 years now, and dip}p is foreign to me. I'd do it by using /{ to search for the beginning, using Ctrl-V /} or /^} or something to search for the end, then using d and searching again for the place I want to insert it with p.
(Also, I think { and } don't work if you're using Python, whereas "I as a human can understand the structure of this code and identify the beginning and end of functions, which I already do because I'm literally writing code in this language" is portable between languages.)
> I don't see any criticizing, just "it doesn't work as well for me," which I think is entirely fair.
I had no problem with his tone. But he's very much making a statement about a technical problem he has with vim, and which isn't well-founded.
> In particular, it seems like 'jimmaswell prefers an editor where you think of blocks of code as "I can see this on the screen" than "up to the end of the current curly brace," which seems like a legitimate difference in mental processing styles, not a consequence of lack of learning.
There is nothing about vim that impedes a visual mental processing style. I constantly look at a place I want to select and then jump there using any number of methods -- the easymotion plugin is ideal for this.
> (Also, I think { and } don't work if you're using Python, whereas "I as a human can understand the structure of this code and identify the beginning and end of functions, which I already do because I'm literally writing code in this language" is portable between languages.)
Again, even vanilla vim performs better here than a mouse. But you should really have custom text objects installed for any language you work in regularly. Here's one for python: https://github.com/bps/vim-textobj-python
Thanks for plugging easymotion. I regularly use a similar feature provided by the VimFx Firefox add-on, but never bothered to look for a way to move similarly inside Vim itself.
I had those issues very early on. Forcing myself to do everything in VIM solved it. It's just muscle memory that people are lacking, once you don't have to think about how to indent/move/select/yank and it is an unconscious action: all these difficulties cease to exist.
> where you think of blocks of code as "I can see this on the screen" than "up to the end of the current curly brace," which seems like a legitimate difference in mental processing styles, not a consequence of lack of learning.
I see this a lot. I tend to think of things visually, be it abstract concepts or code. I remember code by how it looks on screen and how it fits together conceptually, rather than the words. I remember the "shape" of pages of specific papers I read 30 years ago that influenced me, but not the precise words - both literally (I remember what the text looks like and how it was laid out on the page) and conceptually (the takeaway of specific "shapes" of text).
To me this seems like a major difference in thinking that alters the type of languages I prefer. E.g. Haskell to me is noise. I can sit down and decipher it. I read many of the original Haskell papers, and implemented my own lambda calculus implementation etc. to try to get my head around it, and many of the concepts stick with me, but the language is too visually messy for me.
I think this distinction of thinking about symbols vs. visual layout is very pervasive.
I think the same way. That is I am extremely visual and remember visual things very well, though like you its more often the shape of it rather than the specific content, depending.
I grew up using Windows though and while I have had to use vi/vim for work and personally before, I dislike it with a passion (due more to that I didnt grow up using it / havent used it extensively im sure). Ill share the linux folder to windows and use Notepad++ when I can lol.
Pendantry: IIRC `{` and `}` work on paragraphs (or contiguous blocks of lines up to the next blank line) rather than code blocks by default. I'm sure it's possible to change that, but once you're changing things there's no reason not to add support for Python indents or Ruby style `def`/`end` blocks as well.
Like you I also generally just use searches or `%` most of the time.
Not pedantic at all, tbh. This is an important distinction. Curly braces are my primary way of moving in vim and it works great even without curly braces in the code (even in pieces of code without delimiters, actually)
Delete in paragraph. Command+text object is probably the most frequent pattern in vim for me. It would also would work with other text objects like `di(`, `di{`, `di[` to delete between (...)/{...}/[...] bracket pairs for instance. Or other commands like `cip` for change, `yip` for yank(copy) and so on.
Plus custom text object and commands which give exponential combinations. My most used are `ii` or `ai` for in/around indentation, `s` for surrounding and `gc` for toggling commenting in an area.
`{`/`}` go up/down paragraphs. If the code isn't densely packed this works pretty well to jump between logical sections. For c-like languages there are a bunch of weird jumps like [[ and ]] which you were probably thinking of, they are configurable but don't seem very useful.
Do you also use something like bde instead of diw, and ?(ld/)<CR> instead of dib? And if the answer is no, how is dip not in your vocabulary after 10 years?
^ Hey so for the novice to moderately experienced users, this actually works and is composed of three commands:
dip => Operation - delete (cut) inner paragraph
} => Movement - go to end of paragraph (the end of the paragraph following the one you deleted)
p => Operation - paste (the paragraph cut using delete)
Edit: Removed 'not sure why dip copies'; Thanks for the TIL PaulBGD_ !
Since we're talking about pedantry and how it relates to users learning and using vim, let's talk about clipboards. Your clipboard is the '+' register. Cutting or yanking text does not put it into the '+' register, but rather a specified default local register (is it normally 0? Somebody feel free to correct me here). As a consequence, if you delete or yank some text, it doesn't go to the clipboard. If you really want it to go to your clipboard, specify '+' as the default register or call di"+p in place of dip.
This naturally confuses beginners because the concept of registers is completely foreign to other editors. Emacs can provide similar functionality, but by that point Vim is no longer in "weird" mode compared to what you know. We do a lot of simplification when talking about Vim, but small points like this can be immensely confusing for people who just want something to behave the way they're used to.
> The unnamed register is the default and holds the most recently deleted or yanked text; it’s what’s called upon when you just type p without specifying a register.
which would be pure muscle memory to an experienced vim user
As selecting some text with a mouse would be for anyone who's ever edited text with a computer. It's hard to see this kind of argument as more than a statement that learning arcana can be enjoyable. It's true, but then you might as well be learning Rust or writing a tutorial on understanding monad tutorials.
I didn't mean just blocks of code that would be recognized as a paragraph or are fully enclosed in brackets or anything like that. I mean moving some lines around possibly within the same function, which may or may not have multiple newlines between some of them, and have no lexically distinctive property aside from being the lines you want.
1. Even in those situations, I believe a veteran vim user would still beat someone using a mouse.
2. That said, the situation you describe is relatively rare: when coding you typically will be addressing blocks of text defined as functions; sharing an indent level ("ii" selects these); or otherwise selectable by vim in 2-3 keystrokes.
3. Even when that's not the case and the vim selection takes, say, 5 or 6 keystrokes, it has the advantage that your fingers never left the home row, so there is no wasted time "resetting."
4. Just as a tip: doing a "/" search for 2-3 characters after making your visual selection is typically enough to define your block, and will often be faster (and less of a cognitive distraction) than trying to eyeball or count the number of lines and doing a "10j" motion or similar.
I used to share your sentiment but kept going with vim for a year, and now I'm spoiled. Any time for some reason I am forced to use a GUI and a mouse, everything just feels so slow to me now.
Same here. Even if I'm forced to work with non-Vim tools (Visual Studio for example) using their often incomplete Vim-emulations makes lightyears of a difference.
If I had to "criticize" one of Vim's concepts, it would be its way of overriding registers in very unintuitive situations, but I'm certain I'll get used to that, too. When you're aware of it, it's simple to avoid using "_ first.
Edit: OTOH, selecting a piece of text and replacing it with p is quite irritating: The 0 register will still contain its original data, but " will contain the replaced text. I am not aware of how to disable this effect ("_p will paste from the black hole register, which doesn't help in this case).
put a marker at the begining of what you want to cut (mb) b is an arbitrary character but I use b becaues b = begin.
find the end of the block with search, or jkl; or whatever. mark the end of the block (me) e is for end. now type `b, that will bring you back to the start. type v, that puts you in visual mode. type `e, that selects your text from begin to end. x to cut it.
so all in all it's mb<search>me`bv`ex
now if your say you can search your text faster with your mouse than with keystrokes you have a different problem: you don't know how to use the search features in vim efficiently.*
I think it's nearly impossible to be faster with a mouse than a keyboard when it comes to search.
*and yes, to be efficient at it there's a 2 month learning curve that pays dividends over the next 30 years of your programming career -- it's up to you if you think it's worth the investment or not. Use it or lose it, if you don't make an effort you'll stay at your local maximum.
Just another suggestion. sometimes visual mode is overwhelming, or you don't want to be in it while your search for the end of the selection without being sure where it is.
Another thing is if you start with line visual mode (V), and then you end up not wanting line selection the markers help you out -- it's a finer-grained set of commands that's a bit more flexible and a bit less efficient.
It’s still just a few keystrokes.. 10dd 5j p. Take 10 lines, move down 5 lines, paste those 10 lines. With relative line numbers in the gutter there’s no counting involved either. The whole thing is faster than even just reaching for the mouse.
With cursors you just hold shift and use down-arrows to (visually) select the lines you want. Add in Ctrl and you can move word-boundaries, add home-end and you can do beginning/end lines / pages too.
The whole thing is still quicker than vi but with the added benefits of getting much more visual feedback on what is happening and the ability to use the mouse to also quickly select things.
As close as you like. Mouse movements are much more finicky than keyboard ones -- they require a physical precision (seeking, alignment, selection) that keyboard movements don't. And if you never leave the keyboard, you don't have to return to the keyboard to continue your typing. I'm confident even a moderately skilled touch typist familiar with vim would outperform someone switching to the mouse on average for these kinds of tasks.
I would be very interested to a) see this claim tested b) see if it makes a difference in productivity. (Most of what makes me slow at work is trying to understand technical problems, not trying to find parts of text in my editor.)
While not a direct test, there's prior research into the fact that folks who use keyboard shortcuts think they're faster than their mousing counterparts---and are wrong:
> We’ve done a cool $50 million of R & D on the Apple Human Interface. We discovered, among other things, two pertinent facts:
> - Test subjects consistently report that keyboarding is faster than mousing.
> - The stopwatch consistently proves mousing is faster than keyboarding.
(PS and caveat emptor: it's now 30 years since that study was done. Also, I personally firmly enjoy my vim. I just try to stick to liking it because I like it, not because it makes me an uberuser. An uberuser will probably be an uberuser no matter what.)
Ugh, I don't know, a lot of things could skew that result, from font/button sizes (it's hard to miss if you could only fit 5 lines of text on your screen) to insane shortcuts to memorize (I mean c'mon, ⌘-⇧-4 to take a screenshot? There's a line or two about that at the link, but it's presented like inferior and ambiguous combinations are the only one that UI/UX folks can come up with) to ergonomics of the input devices themselves (some cannot stand chiclet keyboards, some can be really productive with trackpoints—sure, this doesn't sound anything like pre-1989 Apple but you get the idea) to even cursor speed/acceleration curve settings. That being said, I'd like to see some details on that R&D.
I still think this might hold true. But for me mouse (and touchpads, trackpoints) trigger repetitive stress syndrome - so acme isn't really an alternative - yet.
But I have some hope for merging the ideas of acme with proper touch screens/digitizers.
> I would be very interested to a) see this claim tested
I would too. But I'd be willing to wager on the results beforehand.
> b) see if it makes a difference in productivity. (Most of what makes me slow at work is trying to understand technical problems, not trying to find parts of text in my editor.)
There's no doubt that things like understanding technical problems, avoiding procrastination, and many non-technical factors are the high-order bits of productivity.
That said, the context of this conversation is text-editor optimization. Also, I think the true benefit of an optimized text editor isn't in raw time savings but in increased flow and just the joy of having a tool that feels like the extension of your mind, rather than something your mind works around.
> Also, I think the true benefit of an optimized text editor isn't in raw time savings but in increased flow and just the joy of having a tool that feels like the extension of your mind, rather than something your mind works around.
My thoughts exactly (although mine might not have been worded that well :) ).
Vim-bindings are like a REPL, but on a different level. If you compare a REPL to a loop of "save, compile, run, enter passwords, wait for a specific event to trigger", you might get a grasp of what a Vim-enthusiast gets out of the editor. They've fixed the thing to fix and moved on while you're still trying to find out where your mouse movement went.
That might sound a bit exaggerated, but for the skeptics, I propose an experiment: Switch your keyboard to a different language (say Turkish, if you're very brave) and try to code for a couple of minutes. I do that regularly (my colleagues don't use the same layout as me), and I'd wager it's about the same level of annoyance as not being able to use Vim-bindings if you're used to them.
I'm not saying that there aren't other effective ways of editing text, I'm merely finding that the defaults aren't very good.
> Also, I think the true benefit of an optimized text editor isn't in raw time savings but in increased flow and just the joy of having a tool that feels like the extension of your mind, rather than something your mind works around.
I couldn't agree more. For me, that's working with a Logitech Anywhere MX mouse in Sublime Text. I imagine how I want the text on screen to be transformed and it just happens without conscious thought.
No. It's just the mouse I've been using for a long time now. It's small, I'm used to how it tracks and accelerates, it fits my hand, and you can disengage the click mechanism on the scroll wheel to spin it freely.
My big complaint is that the buttons eventually start to fail. Single clicks will sometimes register as double clicks and click-drag operations start to drop early.
When I was a DBA, I did all sorts of data normalization stuff, and the Unix pipeline of tools (vim, sed, awk, some perl) was necessary and I was adept at it. Today, I don't do it that often, and it's quicker to just use Excel or whatever for slicing and dicing. It's not worth the overhead to save 10 minutes of manual tasking.
You'd see this when you did green screen to web transformations in enterprise projects. Training would 1/10 the effort, and knowledge based processes would be faster, but the new people would be alot slower than the veteran keyboard operators.
> Most of what makes me slow at work is trying to understand technical problems
That's me too. I spend a lot of time each day reading and that's a lot of scrolling with my mouse and ctrl-clicking on works to jump to definitions or declarations. Text editing speed is definitely not a bottleneck for me.
Have you tried a trackball mouse? That was the magic 'ah-ha' moment for me. I haven't used a normal mouse (at work) in probably 6 years or so. I find in speed it is trackball + kb > kb-only > normal mouse + kb.
I'm not super good with movements myself, so I just use visual mode and the movements I know to select what I want. It doesn't take me longer than reaching for the mouse and moving it around most of the time.
I feel the exact opposite. Reaching for the mouse and aiming the cursor takes forever. I almost never use number prefixes like "10d" for the same reason you dislike them. There are so many other options. } to skip to the bottom of the paragraph, % to skip to the end of the block, H/M/L to target a position on screen, / or * to navigate by searching, Ctrl-D to scroll down half a screen...
Also try VsVim for vim key bindings inside Visual Studio. Or Sublime with vim bindings on instead of notepad++. :)
Then you should start learning how to use Vim, properly ;).
Start from the basics, work your way up. From your post it is painfully obvious that you don't really use Vim to it's fullest potential. Vim requires a completely different way of thinking than regular text editors, and, it requires time to learn.
Only use up down with kj for fine movements. Large movements happen with gg, G, preset marks, and <C-d> and <C-u> which are half screens down and up for me respectively. That covers vertical movement. Most of my horizontal movement is done with either f or vim-seek (which is like f but takes 2 characters!)
Also very useful is setting "number" and using :123 to jump to line 123. This helps the most with compiler errors, but it can also help if you've got a lot of lines on the screen.
I think, because you're used to it, you're under-estimating the cognitive overhead of using the mouse. It also sounds like you've bought into some of the worst kind of vim evangelism, the kind that says effective vim users never hit j repeatedly to move between lines. Granted, it's not the best, but if you're moving only ten lines, V followed by repeated j takes basically no thought to create the selection. If it really bothers you, v followed by / will extend a selection to the match. I find that I mostly use / and ? to move around. In that context, setting hlsearch and incsearch might be helpful.
You might also want to use code folding, especially if moving blocks of code around is something you do a lot of. If you delete a fold in vim, the whole fold goes into the paste buffer.
What's the cognitive overhead? I'm a huge vim weenie and a pretty fast typist, but I'd never argue that the mouse is obsolete when compared to vim.
For example, I've played FPS games where I had to target something the size of < 10 pixels, in less than a second, and the need to move my mouse from one end of the mouse pad to the other. Basically, the mouse and (in most cases) cursor are barely separate from my body when it comes to pointing at things on the screen.
So when I need to put the cursor somewhere, I still find that using the mouse can be much faster than any vim key combination.
While I do agree that the 'context switch' from keyboard to mouse matters, I still find using a mouse/trackpad worth the relative effort often enough that 'pure' keyboard vim is a degradation in experience.
I don't think the mouse is obsolete, just that it's an obstruction when it comes to editing text. Vim, emacs, and my current favorite, kakoune, all give you a rich language for talking to the computer about how you want your text to be arranged. The mouse doesn't speak that language. It requires you to switch from thinking about text as text to thinking about it as a pixel target. That may only feel natural if you play a lot of FPS games.
While I do agree that when it comes to editing Vim/emacs/kaoune might be superior, I spend a nontrivial amount of my coding time in 'discovery' mode. scrolling, clicking around, and mouse stuff in general is very useful in that case, and in my experience definitely faster than keyboard-only.
I could try and make a nuanced argument of when and where a mouse is preferable to a keyboard, but I think even just scrolling is enough of an argument for me. CTRL-D or whatnot just doesn't do justice to scrolling with a mouse.
Anyways, mostly I'm a fan of Vim and using its approach as much as possible. I just get annoyed when Vim-fans try to argue that a mouse is never better, which honestly I feel is a the argument of a fanatic. I've never come across a remotely good argument as to why a mouse is never the answer, and it always feels like a needlessly 'partisan' type thing.
Keyboards are cool. Mice are cool. Can we all just get along?
EDIT: I got a bit carried away and I do agree more with you than this comment might suggest. I just think 'editing' is not the only thing I do when coding, and for some of that other stuff a mouse is a huge advantage, even in a coding context.
Re: scrolling, in vim you have CTRL-E and CTRL-Y and there must be a way to adjust the scroll step (usually 1) to the scroll step of your mouse wheel (usually like 3) is bound. Can a mouse do 30 scrollings per second (my keyboard input rate)?
Where the scroll wheel makes a difference is when you want to fine tune the scrolling speed, which you can't do with a keyboard. I don't think I have a usecase for that (but YMMV), and my impression is it often gets me out of text mode and into FPS mode.
What would be really nice for larger scroll steps (like CTRL-D) is smooth scrolling. I suppose there is no terminal support for this? Also gvim doesn't seem to have it.
Anyway I usually don't scroll by fixed amounts, but do * (identifier search), / (regex search), { and }, and maybe more.
EDIT: just added this to my vimrc. I don't think my mouse scrolling ever was this good
> That may only feel natural if you play a lot of FPS games.
Or almost any kind of PC games. There is learning curve to using a mouse, but it is quite short and once you're over the hump you can use the mouse without thinking about it. The cognitive overhead of the mouse is minimal. There are studies about this: http://www.asktog.com/TOI/toi22KeyboardVMouse2.html
"I've played FPS games where I had to target something the size of < 10 pixels, in less than a second, and the need to move my mouse from one end of the mouse pad to the other."
Do you type with just one hand? Because that's what you'd need to do to replicate that performance while coding.
If you type with both hands, now you have to add in the time it takes you to move one hand from the keyboard to the mouse, make the mouse motion (which could be far across the screen) and then back to the keyboard, repeating that cycle for every single operation which involves the mouse.
Meanwhile, someone who knows vim well and is not reliant on the mouse can type with both hands and only has to move their fingers.
Even if that's true (which is doubtful, as the motion to press a key is much shorter than to move one's arm all the way off a keyboard to the mouse), then you still have the additional time it takes to move the mouse to where it needs to go, and then the time it takes to move your arm back to the keyboard.
There's no way that's going to be as fast. It's also going to be a lot more tiring, if you do that a lot, than merely moving your fingers.
Sure, but you usually have to press a bunch of keys in just the right sequence to do the equivalent with the keyboard.
Some things are quicker to do with the mouse and some things are quicker to do using keyboard shortcuts. I don't understand why people take such absolutist positions on this.
My arm doesn't get tired from moving a few inches to grab the mouse.
"you usually have to press a bunch of keys in just the right sequence to do the equivalent with the keyboard"
Compared to a veteran vim/emacs user, you'd to do a whole ton of mouse movements to get the same effect of a few keystrokes.
"Some things are quicker to do with the mouse and some things are quicker to do using keyboard shortcuts."
The only things I've found to be quicker to do with the mouse are doing things like drawing in Photoshop/GIMP/Inkscape, or interacting with GUI applications which don't have keyboard shortcuts for most of their functions. Text editing and coding, on the other hand, tends to be much faster, sometimes exponentially faster, than the mouse.
This can not be overstated. I haven't seen many GUI type programmers programming in my live, but none of them was faster than "slow". I die of impatience when I watch them edit.
Tog (probably in “Tog on interface”) claims people overestimate the cognitive overhead of the mouse because it is so simple to use, and cites research showing it (including such examples as having to move the mouse over a large screen and back to access a menu item, compared to a keyboard command)
Using the mouse, he claims, is so boring that your mind has time to spend on other things, and that gets perceived as wasting time, while the keyboard continually requires one’s attention, making using the keyboard seem instantaneous
I think that’s why your advice to use repeated j instead of lower keystroke count alternatives is good.
And yes, his research is old (early 1980s) but it wouldn’t surprise me if it held even with die hard vim or meads users. Those keys you press may be close by, but you have to choose between tens of commands every time you issue an editing command.
I've read some of his stuff on this issue, and noticed his experiment design was atrocious, and he has 0 peer-reviewed research. So, I'm taking anything he says with a grain of salt. (I've been doing user research for over 15 years, in a different context, but still I've read tons of HCI/UX work, so I'm not just talking out of my ass here)
By and large, I think vim evangelism is deeply misguided, in that it asks you to learn too many things, it sees golfing your edits down to minimal keystrokes as something other than a total waste of mental energy, it encourages heavy plugin use, and it turns the vimrc into a whole program of its own. The whole point of using an editor like vim is that you don't have to think about it very much. Which is why I encourage using the basic movement and editing keys with reckless abandon. The only thing that justifies learning a new feature is that the simple way is deeply inefficient. Not just less efficient, but so terrible that it's wearing out your fingertips and leaving you annoyed. Global search and replace with regular expressions is a good example. Sooner or later, hitting the letter n and the period key over and over to repeat a replacement is going to get so tiresome that it's worth learning regex, but a novice user can go a long while before doing that and still be quite productive.
It's tuned to my personal typing to be just slow enough that I never have accidental ddoublette kkeypresses, but fast enough that I can just hold down 'j' or 'k' in vim to move 10 or 15 lines (and easily hit the target). Using the mouse cannot even come close here (assuming you don't have your hand on it already). 15 lines would be 620ms here technically, so including the human factors it's still comfortably below a second. Really it makes a huge difference. (I saw this first in a talk by Edward Kmett).
> you're under-estimating the cognitive overhead of using the mouse
What "cognitive overhead?" And how is memorizing a bunch of arcane key combinations for cursor movement and region selection not cognitive overhead?
The (imo, dubious) argument against the mouse has always been that there's a strictly mechanical penalty for moving your hands around - not that there's "cognitive overhead."
Let's break down the cognitive overhead of mouse use. Setting aside the "reaching for the mouse" penalty, there's a lot of work involved in mouse-related tasks like copying a selection:
1. Move your eyes off of the text you're editing so you can find the mouse cursor.
2. Figure out where the mouse cursor is relative to the text you need to edit.
3. Effect that relative movement with your mouse.
4. Highlight the text for copying.
5. ^C or some other key combo to yank the selection.
6. Reorient the mousing hand to the keyboard (find the home row keys again).
Steps 4 and 5 take an equivalent amount of mental effort, but 1-3 and 6 don't exist in vim. That's the cognitive overhead I'm talking about.
> And how is memorizing a bunch of arcane key combinations for cursor movement and region selection not cognitive overhead?
Visual selection is the letter v in vim. There are four keys for basic cursor movement. Then y for yank, d for cut, p for paste. Vim only seems arcane because so many posts about vim are really about demonstrating how smart the author is. I get pretty exercised about this because it's chasing people away who could really benefit from learning vim. Vim is not arcane, vim has a dead simple core with a bunch of entirely optional features on top of it.
> 1. Move your eyes off of the text you're editing so you can find the mouse cursor.
Try this: keep your eyes fixed on a character, then wiggle the mouse or trackpad. I don't think I ever actively look for the pointer before using the mouse, and I doubt anyone else does either.
I'm guessing that if you can track the mouse pointer without taking your eyes off the text you're editing, most of your listed steps become non-factors.
It works independently of transmission method since the mouse clicks are simply translated into "keyboard presses", i.e. encoded to stdin as escape sequences. It's a single stream.
Of course, the terminal emulator must play nice with the windowing environment and translate mouse events correctly.
It works through PuTTY, and moreover it's the default config in Debian 9, which I find sort of annoying because I'm used to using the mouse in PuTTY for copy/paste. But it does work smoothly (including through a screen session and through ssh to other machines).
- Recent vim in terminal (and vim in a GUI container like gvim or MacVim) supports mouse interactions. For example, in macOS's Terminal.app, View -> Allow Mouse Reporting will send mouse events to vim, which will allow you to scroll with your touch pad, select with your mouse, etc.
- I think there is definitely a curve to learning many of the movement commands that vim provides to become fully efficient at moving, say, a block of code. When moving blocks of code, I most frequently use % (which jumps to the matching brace/bracket/paren) or } (which jumps to the next blank line).
I agree that it sometimes feels like there's an analysis step in vim interactions that can feel like it's slowing things down rather than speeding them up. In my experience, much of that calms down after you've been doing it a while. But, that doesn't mean it's worth the investment---I think that depends on the person.
I seem to editor-hop every 2-4 years. I generally end up coming back to vim for long stretches, but I've used plenty of other stuff in the past. I think if you feel productive, that's the tool to use. If you feel curious, or whatever, I think it's worth exploring. Vim is peculiar because its interaction mode is so different that it's hard to feel fully at home with it without going all in for an extended period of time and dedicating yourself to learning some of the stuff that's not necessarily immediately apparent. If you do that, sometimes you find it really clicks with you. Sometimes you don't :)
> Moving a block of code below another block of code takes 1 second in notepad++ while in vim you have to go V 10d x 13down P or something along those lines
There's a bunch of things you could try, btw:
First off,
vim has a GUI version where you can use the mouse (and in some terminal emulators you can too - for example st[0])
Secondly,
did you try using splits (horizontal and vertical is possible, you practically have a sort of WM inside vim)
or maybe you prefer the tabs-approach to things (even though the purpose of tabs is a different one, but you can bend it to your will so it works kinda like in notepad++)
Also, relative line numbers really help me with the vertical navigation - you practically have the number you need to type at the start of the line (and your current line can have the actual line number, if :set nu is active)
For me it's not about wasting time, it's that frequently switching between mouse and keyboard is a repetitive stress injury waiting to happen. The accumulated damage that can occur after doing it everyday for a few years really creeps up on you.
You're not an outlier... The only time when editing takes longer than thinking is when you're processing textual data dump files in their various shapes and forms (logs, database dumps as SQL, etc.). For code thinking definitely takes longer than actually editing :)
I think it depends on the task at hand, whether you are jumping around or focused on a long piece; exploring or debugging ...
Anyway, not everything takes place in the editor.
"The acme user interface for programmers" (http://acme.cat-v.org/) is a good inspiration. It focuses on mouse usage and shows how most systems are as nicely integrated as they could be.
I have hacked together a setup that mimicks acme using a tiling wm, vim (and its amazing remote features), a plumber and a terminal that can send the current selection to the plumber. This way I use vim as I like but I can send it some path:line:col from anywhere with a right click.
Could you explain more about integrating acme ideas into a tiling wm, or possibly share your dotfiles? I've tried doing that with i3, but the window manager has less than optimal mouse support to say the least, and wmii is dead.
Going with your theory, I'd say that pointing devices are more precise which means they require more brain-CPU cycles to operate ... pixel-space is large and you must position it within some delta of the target widget you're trying to use.
Whereas in emacs, say, it's a quick "C-x o" to change to the next/other buffer.
> ...it still never beat GUI editors for me. The lack of a mouse cursor was always a pain point - for example simple copy/pastes take notably longer.
Everybody's milage can vary; in my case it's 100% the opposite. Moving my hands off the keyboard is a demonstrable microinterruption.
FWIW I've been using both text and mouse-based editors since I was 14, roughly 40 years. Some of the time was in deeply mouse-oriented environments (e.g. Xerox PARC in the era when Stu Card was proving that the mouse is indeed a better input approach for a plurality of people -- so I'm not claiming that the mouse is a bad idea in principle). But the keyboard is just so much more direct for me -- I don't have to look at it, and often don't move my eye from the insertion point on the screen even when referring to something elsewhere on the screen.
It also sounds like you don't have relative line numbers enabled, which makes highlighting or jumping some number of lines quickly pretty trivial: https://jeffkreeftmeijer.com/vim-number/
A Vim truism: if what you're doing requires too many keystrokes or otherwise seems cumbersome, there's another way to do it that faster and requires fewer keystrokes.
It's just a matter of whether you're interested in learning and not assuming you have it all figured out.
> while in vim you have to go V 10d x 13down P or something along those lines, figuring out exactly what numbers to use there probably takes more than 1 second alone.
Honestly, I usually just use 9j/9k[1] a bunch to get reasonably close / maybe overshoot a bit, and then adjust with j/k, using visual feedback to guide me. Much quicker than grabbing the mouse, IMO, or computing what line number to go to.
(Admittedly, I should really learn the "go to end of block/paragraph/etc. keys.)
You can also `set relativenumber`, which will change the line numbers on the side to be "relative" (that is, 2 lines down is labelled as "2"); this makes it obvious which number to hit.
[1]: (move down/up 9 lines, 9 being an arbitrary "several")
I really want to say `text objects are faster than using the mouse anyway` but it is probably worth noting that vim has mouse support, even in most terminals. It should be default in neovim. In vim it is disabled by default and the help says
> Normally you would enable the mouse in all four modes with:
> :set mouse=a
so I am not entirely sure why exactly this has to be done manually.
Minimap. What I'm missing in all terminal editors is this neat overview of the file I'm editing.
Everything else can be achieved with clever keyboard shortcuts, tmux, or hacking the .vimrc. It's just a matter of time and persistence.
Similarly with mutt it's attachments. It just cannot handle them as well as a graphical/web mail client. (That and I mostly read my private email on the phone nowadays.)
The individual user's keyboard and mouse proficiency determines their most efficient setup. I'm decent with Vim, but my mouse speed and accuracy is good enough to do many editing tasks with a mouse faster than I could accomplish in Vim.
How do you get moving a block of code to take one second in notepad++? I don't know of a way to get it to take less than a few seconds, but maybe I'm missing something.
Are you intended to keep using vim to edit these remote config files? May it be unnecessary, but if you want to try read this article to figure out how make these things faster using vim.
But IMHO if you are just going for it, there's no reason to learn vim.
You're blowing this out of proportion. Read it again, I didn't discount anyone. All I said was I found one thing more efficient for myself than something else.
Sure, but the question is if the physical and mental context-switch is worth this benefit. I'd say that in editors with a sufficiently expressive keyboard interface like vim, it is not.
One thing I still find myself doing in vim is using the scroll wheel. Browsing and editing is a context switch anyway and I think scroll wheels express scrolling a lot better than keyboards ever can.
Fair enough. I would definitely err on the side of vim when it comes to the benefits of staying within vim's 'mental model', because I do agree the context-switch does matter.
Furthermore, the fact that all my vim-context keypresses can be stored as a 'macro' in itself has provided enough of a productivity increase to make it all worth it. And this is even the case in less-than-perfect vim emulators.
And I do agree that for some things, scrolling and perhaps 'exploring' in general being a big one, a mouse can be worth the context switch.
How do I select Lines 3, 16, 39, 50, 230, 420, 1302, and 2300 at random columns of my needs? With a mouse, I can cntrl/cmd + click the line I am interested in, wherever I am interested, and do any manipulation I want. Can VIM do this easily? I've never tried.
Is there something about those specific line numbers intrinsically? Is there a pattern or specific text on those lines? Is there a relationship to surrounding text, above or below?
The great thing about vim, or a set of similar tools (ed, ex, sed, awk, perl, cut) is that you can address the text in terms of the text itself. Search by text or regex, move within a line or between lines. Replace text or modify elements, preserving some and changing others.
Or, if I know in advance that I've got to deal with the 8 specific lines mentioned but without otherwise addressible context: 3G <edit stuff> 16G <edit stuff> ... 2300G <edit stuff>.
Line numbers were irrelevant, just a set of random numbers. There is no pattern to the text (say it's a set of words that needs to be edited to become the same). I guess this is more related to working with large blocks of text rather than code. Someone mentioned macros, I'm going to give that shot.
What's the characteristc of the text and how do you identify it?
Again, search, paragraph and sentence navigation, and word nav are intrinsic to vim, and fast. If you know what you're looking for, "/<pattern>" and you're there. With incremental search ("set ic" in your ~/.vimrc) thats often a very few keystrokes.
Maybe you're looking for visual block mode?[0]
Or the multi-cursor plugin[1]? I haven't tried the latter, ut I really like visual block mode for certain things.
It's amazing how much new stuff I learn about vim every day... And I'm nowhere near done :)
Wow, shall we argue over whether tabs or spaces are better too? And after we solve that we can figure out how many angels can dance on the head of a pin!
Both gvim and graphical emacs support mouse. But if you use it you're doing it wrong anyway. You're using your boot instead of a hammer because you couldn't figure out which end was the handle.
First would type out a few lines of code incredibly fast with lots of mistakes (and not bothering to backspace over wrongness) - then go back and clear up damage using notepad level editing.
Second would stare fixedly at screen for several seconds, whilst remaining still as a statue, then carefully emit the minimum string of editing commands to achieve the change.
Their actual rate of progress was pretty much identical.
> Second would stare fixedly at screen for several seconds, whilst remaining still as a statue
That eliminates many of the benefits. Was your coworker relatively new to Vim? Or maybe pondering what change to make, not how to actually make it? This is what I've seen from a coworker who was learning Vim and forcing themselves to learn the "proper" way to do things. I don't consider that to be a bad thing, provided that you balance it with actually getting work done.
I always do whatever allows me to edit the line without or with relatively short pause. That might be efficient vim commands, or it might be sloppy if the line isn't formatted in such a way that it fits my muscle memory. If I'm dissatisfied with the edit and think there might be a better way, I research it after the fact so I can later practice and know for next time.
This comes with experience; I've been using Vim for over a decade. Any pause in my editing is because I'm actually figuring out what change to make, not how to make that change.
They were reasonably experienced, but had an appetite for optimization beyond what most people would consider reasonable. In defense however, the task at hand was creating graphics microcode, so that mindset did pay off.
As you rightly point out - there is a reasonable middle ground.
> The second one was investing to become faster in the future.
There's definitely an upper limit to human text manipulation speed, and I would be downright shocked if the difference between "fastest vi user" was even a single order of magnitude better than "experienced mouse user."
Personally I'm extremely happy with the vim plugin in Jetbrains IDEs like IDEA, Rider and so on. It gives me the best of both worlds. I can use vim commands for effective navigation but also have the great static code analysis, smart auto completion, project navigation (find symbol, class, file, ...) etc. of the IDE.
Stripped of the vim baggage (yes, I know vim; yes, I stopped using it as my primary editor in the 1990's), it comes down to:
1. Learn to use the code navigation features of your environment (or get a better environment).
2. Learn to use incremental search and replace in your environment (or get a better environment).
4. Make autocomplete work in your environment (or get a better environment).
3. Make your often used actions one click or one command.
For (1) and (3), Visual Studio and IntelliJ are by far the best options available. (2) seems to be fine in any modern editor. For (4), acme is the best I've seen: you write your commands in a buffer, and click on the ones you want when you want them. If the buffer is a small one at the top of the window, it's the menu bar.
My dream is having an actually working/accurate to the character consumer-grade eye tracker that people can glue onto their screen. Then to move around in vim, look at where you want to go and just press a key.
I think this alone would allow for a jump in effectiveness almost as great as the jump from notepad to vim.
Selecting text with shift and arrows, moving across words with the control key and arrow keys, using home and end keys, using CTRL F and CTRL G, all those are already plenty enough for me.
I honestly don't understand why people use VIM or Emacs. I'm much more productive just with notepad.
Most editors can fold code block, use syntax highlight to make code so much more readable (if you take time to choose the right colors), highlight braces, autocomplete (even sublime text can do a weak autocomplete which is already quite handy).
To be honest, when you learn to type, using the shift, control, home and end keys should be the second thing you learn. Forget about vim and emacs, those were for times when people were coding over SSH. Use Nano if you're in a terminal. Also most of what coders do is read code, not write it.
> Forget about vim and emacs, those were for times when people were coding over SSH.
If you're struggling and have the suspicion that it might not be worth it for you in the end, sure.
For everyone else, don't be afraid to learn how to be more effective by using a more expressive feature set for editing.
I think your advice is potentially harmful. Just because you didn't end up learning this doesn't mean it's useless to other people.
It's quite possible that you're just not learning effectively enough and you're not grasping the tools correctly. There's no shame in that, but to then advise people to not learn it only because you couldn't is completely pointless.
I'm just curious what kind of indispensable feature an editor like emacs or vim has. I don't see the productivity gain.
Ultimately, it might just be pleasurable to learn to use something new and use it. You "feel" like you do things differently, but to me it's just another nerdy gadget thing.
Editor macros are one of the reasons you'll want to use Emacs or Vim instead of notepad. They're just like linguistic macros: You'll never know you need one if you haven't used one. However unlike linguistic macros -where choosing to use one is much more of a design decision than a necessary step- the only viable alternative to editor macros are doing their job by hand.
I guess this is just pre-filled if/else/while/for loops snippets? ST3 does it too I guess.
I don't really think those are very useful, they don't save you that much time. Your editor cannot guess what kind of code you precisely want to type. Or maybe you're using a language that has too much syntax. Or maybe you're typing too much code, and that can be a bad thing too.
As others pointed out, snippets are not macros. And in addition using macros for simple text transformation that was pointed out by @ethagnawl, below are other ideas all of which I use on an almost daily basis:
1. Macros can be shared with different buffers which enables you to a) do complicated transformations in a step by step manner and b) do transformations where the content of one buffer affects the content of another etc.
2. Macros can have state, typically demonstrated by having a counter. Imagine replicating your keys, but somewhere in between, a number is incremented or a word from a list is being chosen etc.
3. Extension of (2) is generative ones e.g. abo abo's `tiny` package.
4. Macros can act in arbitrary buffers. For example, If you're in `dired` or `ranger-mode` or alike, you could edit the file system the same way you were editing the code.
The common denominator of all these is the keyboard. Any GUI version would either be too complex to represent all the possible variations, or there are use cases that are not covered by GUI and those use cases -if they matter to you- would be the reasons you'd be gravitating towards keyboard based editors. For the case of notepad, the uncovered use cases are quite trivial. :)
I can't tell whether or not you're trolling, but I'll bite.
To provide a contrived example of the sort of editor macro capabilities (I believe) somezero was referring to: Imagine you have N lines of hashrocket style Ruby hashes (`{:foo => "bar"}`) and you want to convert all of them to JSON style hashes (`{foo: "bar"}`). In Vim, you can create a macro which records the keystrokes/commands used while massaging first hash (moving :s, removing =>s, etc.) and then replay that macro over any other hashes you want to change.
I just performed a very unscientific test of the example I've provided above and it took < 10 seconds to write/record and apply the macro to 100 hashes - all without touching the mouse or thinking too hard about what I was doing. I'd be interested to know 1) if a similar operation is possible using traditional GUI editors, 2) how long it takes, 3) whether or not the same operation can be performed without touching the mouse and 4) whether or not those "operations" can be shared.
CTRL H, remove all occurrences of ':', then replace '=>' by ':'. In python it's as simple as .replace().replace().
Oh and you don't need to learn that much to do it, or print some large VIM cheatsheet.
> 4) whether or not those "operations" can be shared.
Better even, those can be done in python.
To be honest I prefer using basic tools and building my own when it really is necessary, instead of using complex ones, even if they are more powerful. Sometimes you can waste time coming up with good solutions that you will only use once.
It's telling that Microsoft has opted to integrate Neovim in VS Code to enable its Vim plugin to have perfect Vim compatibility: https://github.com/VSCodeVim/Vim
Integrating Vim makes it a no-brainer for those projects where I have to use VS Code.
Being able to ssh <build farm> && tmux attach to reconnect to your development environment is powerful, especially when your testing environment consists of connecting to a number of different systems at once.
Examle, a persistent tmux session with splits on a big monitor, Vim/Editor in one pane with live-UT results in another and documentation/misc details (scratch?) in another kicked off as I save.
Once kiddo's go to bed I can simply 'tmux attach' from any machine with access and be up and running.
I use IDEs and Vim, but there is clear value to working completely inside the terminal.
The same reason IPv4, Unix, and unencrypted email are still dominating: it's good enough, and it's available everywhere, with no fuss.
Coding over SSH is just so convenient. It doesn't matter whether you're using a Raspberry Pi or a DigitalOcean VM.
When you're coding in vim, you're not losing all of your IDE and just getting vim. You're losing all of your IDE and getting all of the Unix userspace. Unix is a great IDE.
I can't stand editing more than a few lines on a VPS because of the latency and uncertainty. Some letters appear fast, others take a second or more, it's maddening.
I do all of my development on a remote box. All of my work is in a screen session, so I can always reattach to it. Since that box is a lot more stable than my Mac is, it doesn't take much effort to restore my workspace after OS X crashes. I also regularly leave builds and tests running while my laptop's asleep, and, because they're remote, they never cause my laptop to overheat and kick on its fan.
To add to what others have said, VIM has a lot of features of modern editors. They have code folding, autocomplete, and more. Most of it's built in but there's a multitude of plugins for all this.
Because when you're reasonably proficient with Vim, you think of what to do and with a few keystrokes, you've done it without the interruption of reaching for a mouse, selecting a menu command, etc. For many edits, in the time it takes to grab a mouse, orient where the pointer is on the screen and begin the process of selecting a GUI command, etc., you'd already be done using Vim and you're off to the next thing you want to do. Anyone who's been in the flow of coding doesn't want something that interrupts that and Vim is great at keeping you there.
And because Vim uses a language, it's composable in way that VS Code, Notepad, Emacs and all of the rest of editors aren't. Once you understand how to delete a word (`dw` in Normal mode), you also know how to delete sentences, paragraphs, etc. Plugins can add their own text objects to extend the usefulness of the language.
Forget about vim and emacs, those were for times when people were coding over SSH.
Apparently you're not a systems admin, web developer or in devops, where people have to connect to servers via SSH and edit configuration files, scripts, etc. pretty much every day.
The beauty is you can use Vim on your desktop or laptop for local editing tasks (especially gVim) and for remote editing via SSH, FTP, rsync.
Finally, I've used over a dozen different editors over the years on macOS and other platforms; I decided I wanted one editor that had enough headroom that I couldn't outgrow regardless of the task at hand.
Even though I've been using Vim for 4 or 5 years as my primary editor, I've barely scratched the surface of what it enables me to do.
I've used Sublime Text; it's not a bad editor; but compared to using Vim, it’s like being in quicksand.
Sublime Text should be more modern and useful than Vim, an editor with roots going back to the 1970's. As the article describes:
>Vi is fundamentally built on command composability. It favors small, general-purpose commands that can be combined with objects to compose larger commands. By contrast, Emacs and its philosophical descendants (including Sublime Text and Atom) use monolithic, special-purpose commands.
You can't add enough special purpose commands to something like Sublime Text and have it be useable to approach what one can do with Vi/Vim and its composability.
Finally, Vim 8.0 was released just last year (2016), so it's not like it's not being updated with new features.
Last thing from the aforementioned article:
>A new, shiny, modern editor could one-up Vim by fixing some (or hopefully all) of these issues. But before an editor can replace Vim, it needs to learn everything that 1976 has to teach — not just the lesson of Emacs, but also the lesson of vi.
Folks here assume "text editing" is just structured code editing. I use vim for more than just editing code trees in one language. I edit unstructured text (lists, notes, articles), semi-structured markup (latex, markdown), and machine-readable data that is not in the form of a tree (csvs, tsvs, scraper output, training data that comes in arbitrary formats).
The mindset I've come to appreciate for vim is that the goal is to have a zen garden for editing text. Editing text efficiently and seamlessly is the end goal, and what that text is used for is incidental.
I use AutoKey (Linux, surely there are similar apps on OSX and Windows) to do system-wide abbreviations, including correcting "teh" and "hte". Along with abbreviating a few common phrases, this probably saves me hundreds of keystrokes a day.
Anyone who is wary of trying out an editor like Vim should play dwarffortress for a bit. It's amazing how fast you pick up the keyboard commands for common operations.
Which, beyond Emacs with Paredit, whatever is called Paredit-as-ported-to-vim, and some obscure Smalltalk stuff, generally doesn't exist. So yeah. Stay with Vim or switch to Emacs.
For the purposes of Lisps there's Emacs with Paredit (or other editor with Paredit, there are versions for most of them I think), for the purpose of notes there's Emacs with Org-mode.
For the purpose of Java w.r.t. refactoring and navigation there's Intellij, Eclipse etc.
For the purtpose of Python w.r.t. refactoring and navigation there's Pycharm.
And so on.
I use a combination of (1) Emacs & Org-mode for structured editing of notes and prose, and (2) Whatever IDE is most suited for the language I work in.
Isn't MPS for making weird DSLs that require special tooling, and not for editing your generic code? That was the impression I got after installing it and clicking around + reading some of the documentation.
I understand 'nnq asked for editor treating code as trees; beyond Paredit mode for Lisp code, I'm not aware of anything like that being currently in use for regular code anywhere.
Yes, totally. But as a side effect it's also the best and most usable tool that I've ever seen that lets you edit the syntax tree directly.
In that sense it can be seen as the most extensive exploration of this idea, and it could definitely serve as an inspiration to those who want to make a tree editor. Jetbrains poured some serious time and UX design into how to edit a syntax tree.
It has a decent Java mode for example, which you could use to edit Java sources. It takes some getting used to but it really isn't half bad. You can't write code with it that doesn't parse.
Thanks. I'm going to check it out again, time allowing, and try a small project this time, instead of just casual clicking around. I'm very interested in the space around the idea of more structured code editing and different code presentations.
Thanks, but >100ms latency is not something I can tolerate in a code editor. If I need a heavy IDE I can just run it on an overpowered machine and get to my target latency, but web based makes this unusable...
I'm not a big fan of Vim, but unless you can find any smart editor that have had half of the success of vim for half of its life time, I'd say maybe the way it threats text seems to be successful.
Emacs and IDEs are also successful. No IDE in particular was long-time successful, but the general concept of "heavy program dedicated to structured editing of code" is successful. I still use Vim for config files though :P
It depends how you define "long time". Visual Studio was launched 20 years ago. Eclipse 15 years ago. Both of them seem to have at least as many years left in them.
Emacs is older than vim, almost exactly as old as vi (both emacs & vi started in 1976, IIRC), is quite smart and is capable of treating code as trees rather than strings.
One problem with key commands is that there's a lot of keyboard layouts. The same key can generate different letters depending on the keyboard. So when building an editor, do you listen to keys or whatever comes out after the key press(es) !?
It's true that you should think about what you're doing so you can avoid mistakes (and, as a side effect, type less), but you still end up typing quite a bit as a programmer, and you probably want to minimize the impedance mismatch while you're translating your thoughts into code.
I've seen this play out in real life with two programmers who were roughly equal in terms of thinking in abstract terms. One of them was much better at typing (and using tools in general), so their code quality was better overall. The other would get frustrated in the translation/typing stage and produce lots of sloppy and incorrect code.
I've heard that argument before but as a plus point for Vim. I just want to fix that typo in the next paragraph (}), not have to pick up a mouse and carefully place the cursor, or move down fifteen lines by hand or something.
It's Vim... it could be (1992) and probably still be useful to many vim users. Vim is regularly updated with new stuff but most of the stuff people use day to day to be more productive is decades old.
I use vim every day and find these old articles are often helpful.
Heck, sometimes I find articles from the 1970s/80s about vi to be still helpful in vim.
Plain text is an extremely simple, open and universal format, a local optimum in the design space. It has been with us in various forms for over 100 years ever since the first telegram systems. Ascii has existed since the early 60's and still exists today as a subset of UTF8. It will no doubt outlive almost any other binary encoding currently in existence.
Surely you could make that argument about text other than source code? Why write scripts for television shows instead of using computers to make diagrams of the plot? Why put words in instruction manuals instead of cartoon pictures showing how to use the item? (Granted, that works for Ikea.) Why use textbooks for instruction when you could videotape the lectures instead? For any application where there's an alternative, even a popular one, text endures.
Your comment is entirely consistent with that position :) I appreciate the irony of asking if you've written anything about your new communication paradigm, but, well, have you?
Computing as we know it is not even a century old and we already had several radically shift in it.
Compared to house building, medicine or transportation... We had millenniums of experience with them and yet we don't revolutionize them every decade.
Things take time.
Let's try find balance in what we got already. Once we have a hold on that, we'll have plenty of opportunity for the rest. Innovation is not an endangered concept in the human specie.
One wonders why you aren't asking the same questions of spoken word. The answer is probably that what we do right now is actually very efficient, well-tested, broadly applicable, and easy to learn.
I am extremely critical of spoken words as well. I'm convinced that natural languages should and will be replaced by something better in the near future. I'm actually working on it.
Better in what way, exactly? More expensive? Doesn't use built-in biological facilities? Requires software updates and network synchronization? Children can't use it?
- You'll never have to say the same thing twice (since the system you communicate through remembers)
- You'll rarely have to say something explicitly (because most of the things can be anticipated for you)
- You'll never say ambiguous things (because everything is semantically clear and verified)
- You won't be able to contradict yourself or express paradoxes (because the meaning is verified and tested for coherence)
- You'll never have to adapt your output to an other persons input (because the translation and contextual reformulation is made for you, think responsive speech)
This comment appears every single time there's a discussion on the unwieldiness of code as text, probably ever since online discussions were a thing. Shouldn't someone have come up with something radically better by now (instead of just complaining about it)?
I was in primary school when this was published. I had never touched a computer by then and the closest I got to one was maybe 3 or 4 feet. The whole school had one computer in the library, and the librarian's son played games on it. That same child died in the Ukraine a couple years ago and I spent the majority of my waking hours now with a computer.. Life is strange!!
Overall I'm glad vim exists so editing config files remotely is easier if I don't have the server mounted locally - it's definitely my favorite shell text editor so far but I'd take notepad++ or visual studio over it any day.