Seven habits of effective text editing (2000)
moolenaar.net
moolenaar.net
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.
dip}p
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)...
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 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
This is so popular, it made it to emacs too: https://github.com/hlissner/evil-snipe
I love the 2 char lookahead/lookbehind. It is so fast and useful.
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 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.
Like you I also generally just use searches or `%` most of the time.
> dip
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.
p means paste which you probably now anyway.
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)
Some other cool diX (delete inner X) commands here: http://vimdoc.sourceforge.net/htmldoc/motion.html#diw
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.
Source: https://pbrisbin.com/posts/vim_registers/
Besides + there is also * for accessing alternate clipboard: http://vim.wikia.com/wiki/Accessing_the_system_clipboard
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.
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.
That doesn't seem to work. Am I missing something?
Also, relative line numbering changed my life.
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).
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.
why not just?
v<search>xAnother useful visual mode is Visual Block (<ctrl>+v), for deleting/yanking, replacing block across multiple lines.
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.
http://www.asktog.com/TOI/toi06KeyboardVMouse1.html
> 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.)
But I have some hope for merging the ideas of acme with proper touch screens/digitizers.
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.
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.
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.
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.
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.
Also try VsVim for vim key bindings inside Visual Studio. Or Sublime with vim bindings on instead of notepad++. :)
>pgup/pgdn and arrow key
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!)
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.
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 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.
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
" Triple scrolling "speed"
nnoremap <C-e> 3<C-e>
nnoremap <C-y> 3<C-y>Agreed.
I'm a vim fanboy - and I use the mouse.
Well spoken, that goes for me too. Something about internet discussions amplifies disagreement!
My google-fu is failing me; what is kaoune?
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
The cursor's where I left it, damnit. Don't move it and force me to put it back.
There are times when directly pointing to screen elements is useful. Working with text I almost always find it gets in the way
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.
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.
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.
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.
Depends on what you're doing. Again with the absolutism!
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.
# keyboard autorepeat delay / rate
xset r rate 170 30
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.
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.
set mouse=a
At that point you can quickly select text, hit "d" to cut it, click where you want it and hit p
[0] http://vimdoc.sourceforge.net/htmldoc/options.html#%27mouse%...
Of course, the terminal emulator must play nice with the windowing environment and translate mouse events correctly.
- 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 :)
...if by "recent" you mean a decade old version.
Your problem with Vim is that you don't grok vi:
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)
Maybe I’m an outlier here but the whole thinking, planning, and experimenting takes way longer than my hands can move.
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.
The setup requires:
- a terminal that is aware of its shell current working directory (OSC7) (I use st or tmux and zsh)
- a terminal that would call a plumbing command with the current selection on a mouse right click (I use st or tmux)
- a plumbing command that would call the appropriate action given the selection string passed in (I use a script and plan9 plumber)
- an editor that supports being called from the plumbing script (I use acme or vim remote with vim-fetch plugin)
- an eventual tiling wm or tmux for window management
My dotfiles aren't public but I guess I could try and package them if you're interested. PM me at the email on the suckless page.
Whereas in emacs, say, it's a quick "C-x o" to change to the next/other buffer.
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.
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.
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")
> Normally you would enable the mouse in all four modes with:
> :set mouse=a
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.)
However, I never use the mouse in visual mode to highlight blocks of text; for that I'm much faster using Vim’s keyboard commands.
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.
It is a long path indeed, but wort it.
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.
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.
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>.
That's not elegant, but it's doable and fast.
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.
What I'd do is record a macro for the edit on one line into q, and then apply it to all relevant lines with a regex, e.g. g/regex/norm @q
It's amazing how much new stuff I learn about vim every day... And I'm nowhere near done :)
[0]https://stackoverflow.com/questions/21806168/vim-use-ctrl-q-... [1]https://github.com/terryma/vim-multiple-cursors
- go to line 3
- start recording a temporary macro ("qq" in my habits)
- do the editing
- stop the macro ("q")
- go to the line 16 with 16gg and reply the macro with @q - 39gg@q
- 50gg@q
- ...
Well, if used for the right purpose.
To take it a step further, its 4-space indents. I've seen code where people pull off 2-spaces, but it gets crowded failrly quickly.
You should ask a tabs advocate what they think the primary feature of tabs is :)
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.
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.
As you rightly point out - there is a reasonable middle ground.
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."
7 Habits For Effective Text Editing 2.0: https://www.youtube.com/watch?v=eX9m3g5J-XA
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.
I think this alone would allow for a jump in effectiveness almost as great as the jump from notepad to vim.
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.
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.
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.
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.
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. :)
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.
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.
No, you seem to be simply talking out of ignorance.
Integrating Vim makes it a no-brainer for those projects where I have to use VS Code.
I do substantially all of my coding over SSH, and so do most of my friends.
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.
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 don't know what this feature is not widespread enough.
If you think lowest-common denominator stuff like Notepad equals productivity because it's easy and "discoverable", then I got nothing for you.
There's a reason why the subtitle of Drew Neil's book is "Edit Text at the Speed of Thought": https://www.amazon.com/Practical-Vim-Thought-Pragmatic-Progr...
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.
More at "Why Vim Can't Replace Emacs/Sublime Text, etc.": https://medium.com/@mkozlows/why-atom-cant-replace-vim-43385...
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.
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.
1. "wow, the author seems to know a lot about vim!" 2. glance up at the name in the url ... ooooooh.
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.
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.
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.
https://blog.isomorf.io/an-experiment-in-structured-code-edi...
https://blog.isomorf.io/the-economics-of-semantic-coding-7e8...
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...
http://web.archive.org/web/20171023122758/http://moolenaar.n...
thinking >>> editing.
If serious non-trivial editing effort is required, write a script to do it.
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.
Does anyone here seriously take more than sub-second time to get the cursor on any given character using a trackpad?
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.
If anything, popular software only keeps regressing over time, letting you be less and less effective.
I'm actively working on a new communication paradigm that I hope will make natural languages obsolete.
What I have in mind is basically anticipatory computing.
https://news.ycombinator.com/item?id=14941564
https://news.ycombinator.com/item?id=10567261
https://news.ycombinator.com/item?id=10774715
https://news.ycombinator.com/item?id=12296347
The posts are chronological, so you can kind of see the idea developing in Mr. Rochefort's mind.
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.
- 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)
1) Observe other people edit text, then judge for yourself what is effective and what isn't, then decide for yourself what to learn and what not to.