17 ms·

Vim Is Saving Me Hours of Work When Writing Books and Courses

378 points by nickjj 8y ago

INTPenis 8y ago
Let's be honest though; vim saves you hours of work if you're already good at vim. If you're not then it'll just slow you down. It takes practice and daily use to learn. I love vim but let's not sugar coat it.
- giancarlostoro 8y ago
  Indeed. JetBrains IDE's save me hours of work because I'm comfortable working with their IDE's. I am also more comfortable with Emacs than I currently am with VIM, but I use either one depending on circumstances. To be fair op did write how it saves them hours.
  - emsy 8y ago
    Vim plugins are available for most IDEs. I almost never use vim (except for the shell), but I use vim-style editing in all the IDEs I use.
    - polyterative 8y ago
      Is that a viable way to learn vim? As an advanced jetbrains poweruser
      - qqqwww 8y ago
        Absolutely - I first learned "vim" using a visual studio plugin. Since then I used it in 5 other editors, but I barely used vim itself. The main downside is that you don't learn things like window managing, file exploration, etc - mostly because other editors are already good at that, and it's not something plugins focus on.
        polyterative 8y ago
        Is it worth it? I am already pretty fluent using my custom-ish shortcuts for all navigation, will vim speed me up at this point?
      - emsy 8y ago
        I've learned vim in the standard vim editor at the time, so I can only guess but it should probably work. 99% of my work with vim is navigating and editing text. The rest is macros and substitute, all of which is available in IntelliJ. The things you miss out on are (I think) colorschemes and vim specific plugins (which you mostly don't need because you have a fully fledged IDE).
      - alpaca128 8y ago
        Doing it that way will at least prevent you from being disappointed due to missing features. Vim plugins are nice and I definitely prefer them over basic input, but almost all of them don't even cover the basics.
      - neurotrace 8y ago
        That's how I learned it. I got the extension for VS Code and just started playing with it. If I got frustrated, I would slap "i" and go back to my normal way of doing things. The frustrations went down and now I use vim bindings all the time. I'd also recommend getting a Vim plugin for the browser (https://addons.mozilla.org/en-US/firefox/addon/vimium-ff/ https://addons.mozilla.org/en-US/firefox/addon/vimium-ff/). Totally optional but it really helped click in the j and k movements.
- mikece 8y ago
  Ditto the Dvorak keyboard enthusiasts...
  - hopler 8y ago
    Dvorak doesn't save time, it's not faster than qwerty given equal practice
    - chrisfinazzo 8y ago
      But given Vim's quirks, is that layout more amenable to working quickly? Given how people gripe about it in QWERTY setups, that's certainly a possibility.
  - CydeWeys 8y ago
    Even less so. Unless you're doing transcription, typing speed is not even close to being the primary limitation on how quickly you work. Thinking of the words is. The difference between a typist who can hit 100 wpm using QWERTY and 110 wpm using DVORAK will only be exposed when playing TypeRacer. Otherwise there's no functional difference. You have to get down to hunt-and-peck until you see typing ability actually affect productivity (and I have seen those people). If you can touch type using any keyboard layout, though, then typing speed won't be a meaningful limitation for you.
    - bunderbunder 8y ago
      I broke my wrist a few years ago, and had to spend a while typing with one hand on a half-qwerty keyboard setup. I took a huge hit to my typing speed, but the rate at which I was getting work done didn't really change.
      - lfowles 8y ago
        Noticed the same when I switched to an Alphagrip and could only maintain 50-60wpm.
    - simias 8y ago
- segmondy 8y ago
  That's the wrong way to look at it. Anything you're not good at it is going to slow you down. The question is that even tho you might be slow, if you put in the effort, learn it then get good, will the savings and speed up make up for the initial slow down? I'm a vim fan and won't try to convince others. But I personally believe that the answer is yes. One of the secret to being successful with vi is that of mindset. You need to have a positive mindset that it's worth learning, you need to commit to learning it. I learned vi when network speed was very slow and systems didn't have enough memory. It was faster than any other editor. So I had the mindset that I needed to learn it. if I was starting out today, it probably would be hard when you have editors like vscode. I have typed and used computers everyday for 25 years non stop and I have no issue with my fingers and I believe a major part of it is using vim and my fingers not having to travel and move out to find a mouse or hitting Ctrl+ keys.
  - amelius 8y ago
    Another way to look at it is: what fraction of the time are you typing versus thinking? If it's less than 20%, then a faster editor will probably not speed you up by a significant amount.
    - megous 8y ago
      Typing and thinking are almost the same thing to me. I'm either writing code, or bullet lists with things to do, concerns to take into account, things I've learned, etc. Text file is an extension of my memory, and a place to distill, manipulate, and organize my thoughts.
    - TeMPOraL 8y ago
      Vim won't speed up your typing. It'll speed up your editing. Adding/discarding/modifying large blocks of text, or spread-out blocks of text. It'll let you think in terms of moving this block there, replacing these words, duplicating these patterns, etc. The efficiency increase comes, in large part, from allowing you to make steps that are closer to how you think. And even if we're talking about 20% of your time, improving that 2-10x is nothing to shake a stick at. 20% of 10 hours is 2 hours, if Vim makes you edit 2x faster, that's 1h saved, per day. And that's without accounting for other work you could move to your suddenly more efficient plaintext mode, and the work you don't even consider doing because your editing experience is too painful (it sometimes work the other way too; there are things I won't do in Emacs, but I will in IntelliJ, where project-wide, language-aware refactors can be done with two clicks in full confidence that nothing will break).
- emsy 8y ago
  What's your argument here? I don't try to be snarky, but learning a new skill is always slow in the beginning. If anything we should encourage people to learn these skills as early as possible so they can reap the benefits longer. I admit vim's learning curve is pretty steep, and I'm glad I learned it during my bachelor's thesis where I had a lot of time to do so.
  - tiuPapa 8y ago
    Not OP, but I think the argument is that Vim isn't a magic editor that would make you fast out of the box. And if you just want to get work done without concentrating on learning a new skill, maybe you should look at other options?
    - emsy 8y ago
      I can only speak for myself, but I've used vim plugins on almost every IDE I've ever used. Unlike editor shortcuts, which are often exclusive to a certain IDE, vim is transferable and that's how it has one of the best cost/benefit ratios for me.
      - SketchySeaBeast 8y ago
        > Unlike editor shortcuts, which are often exclusive to a certain IDE, vim is transferable and that's how it has one of the best cost/benefit ratios for me. Doesn't that just mean you've selected VIM's syntax for all your IDE's? Most IDE's seem to have plugins for other popular editors.
        NegativeLatency 8y ago
        Seems like it’s the difference between him being supported in many IDEs and say visual studio shortcuts being supported in some thing like Atom. (Support May exist for this, IDK)
        SketchySeaBeast 8y ago
- benawad 8y ago
  short term vim slows you down, long term vim speeds you up
- brootstrap 8y ago
  Valid point. I have to give some updoots for VIM, (or emacs too i guess). The visual editing gives you such an advantage, i'm talking just about coding. Most of my co-workers come from science background and think VI is a joke from that crazy professor in college. I forced myself to really learn VI one summer in 2013. Since then i've been flying around my text editor. I'm not lying, co-workers think you are a god damn wizard. I try not to be a doosh, but I have one co-worker who loves VIM but doesnt really use it (insert mode ftw). Whenever I can i try to subtly drop hints. "Instead of hitting the arrows keys over and then backspacing, you can type cw to change the word" Just little things like that. Once you realize that vim is modular and chainable, you really start to take off!
- sametmax 8y ago
  Even if you are very good at vim, it's still debatable. The thing is, vim forces you to do a lot of stuff that the machine could do for you. E.G: you need to remember states and how to transition between those states. Plus the human mind sucks at context switching. All in all, this adds up, and there is a limit to the cognitive load you can accumulate. You only have one brain and you need to share it between all tasks, including solving the problem at hand and using tools to do so. Half of my income comes from training professionals on site. Experience taugh me that every time somebody uses vim, 4 things will happen: - the person will be one of the best of the team - the person will have some weird bug/config problem/compat issue at some point and will waste time fixing it at least once during the training, swearing it never happens (also the person with vim usually has a very custom setup so this compounds) - at the end of each day, the person will be one of the most exhausted, and will make way more mistakes than the others compare to the morning baseline - at equal technical level, the person with vscode/sublime/jetbrain will be faster on average. Maybe not the first hour. But it will come. So, yes. Vim may be fun. It may suit your workflow and ecosystem, and even your sense of aesthetic. But I don't buy the productivity boost.
  - appleiigs 8y ago
    Do you have examples of the bug/config/compat issues? I get those problems with an IDE, not Vim. IDE is always trying to lint, debug, run stuff... mix that with virtual environments and what a mess. With vim being on every system, i don't really carry much baggage around. I have my vim settings file in cloud storage. And maybe one pluggin (NERDTree) on my main machine.
    - sametmax 8y ago
      No, I never, ever look at the source of the problem nor the solution. I've used vim for 15 years, but I don't have time for this, so I don't customize anything, and if somebody has a problem, the person is responsible for fixing it. I'm not even waiting on people with Vim problems anymore during the lectures. I just go on, they will catch up.
  - nickjj 8y ago
- pletnes 8y ago
  Programming is much worse. In the beginning, I spent just a few hours a week programming. Today, it’s a sizeable fraction of my work week. Programming is thus a complete waste of time.
- manifestsilence 8y ago
  For the first couple years I used vim, I spent half the time just hitting "i" and using it like a normal editor. And if I was in the mood to learn something, I would hit <esc> and try not to wreck my document. It's not that big a barrier if you start gently rather than going with a purist mentality that the arrow keys are evil and should be pried off the keyboard. :) This approach is especially nice when there are great vim keybindings for things like Visual Studio. The only thing you have to learn to start using vim is to always pay attention to if the cursor is a block or not, and if it is, remember to hit "i" before you mash keys if that's not what you want.
  - Izkata 8y ago
    I don't think I ever did that, but I do have another suggestion that I did for a long while, along the same "start gently" mentality: Use gvim It not only has menus, but the shortcuts on the right side of each menu item aren't special - the they're the same commands you'd just type into vim normally. I picked up a bunch from those, but in particular I remember folding being one I didn't even know existed in vim until using it in one of the menus.
- porpoisely 8y ago
  Agreed. I use vim daily and really the only text processor I use. But the learning curve is pretty steep.
- mettamage 8y ago
  I'm sorry: learning the basics of vim isn't hard, and it never will be, provided you have the right education (I suppose that's true for anything but in this case it's a platitude that I viscerally experience to be true). The right education is: vimtutor (type it in your CLI and within 30 minutes you're done). I deleted my rant but I dare anyone to take my challenge: do vimtutor for 30 minutes and then answer the following question twice (before vimtutor and after it) in a comment. I perceive vim to be difficult: (1) strongly disagree, (2) disagree, (3) agree, (4) strongly agree. Once you know the basics of vim, then it won't slow you donw.
  - johnmarcus 8y ago
    Um...hate to point out, but he didn’t say it was difficult. He said unless your practiced in it, it won’t be particularly more efficient in it. I’m sur vim tutor teaches all the things, but until they are muscle memories in, you will see no time advantage. A 30 minute tutorial will not muscle memory all the things in, that takes time and practice. Also, while not hard (I use vim constantly as a sys admin) I don’t personally think it compares to what I can get done in Atom and it’s never going to be my editor of choice, no matter how familiar.
    - mettamage 8y ago
      Vimtutor doesn't muscle memory everything in. But it does muscle memory in basic things such as deleting, moving around and going to beginning of lines, enf of lines etc. That's what it did on my first run. It indeed wasn't perfect, but there were already a couple of tricks that I've learned that I really liked and that's what you get out of it. I'm not saying you work faster, I'm saying after vimtutor you won't work slower. I suppose you still work slower if you compare it to your favorite text editor, I'm not very strongly proficient in any text editor, which is why I'm not noticing slow downs.
  - kerbalspacepro 8y ago
    >The right education is: vimtutor (type it in your CLI). Well I just discovered a new thing to do over the next 25-30 minutes
- darkpuma 8y ago
  Running through vimtutor a few times one weekend does wonders. And compared to other trades, a few hours of training on a tool is pretty damn quick.
- philwelch 8y ago
  Obviously the best option is to learn vim as early as possible to maximize your return on time invested.
fouc 8y ago
Is VS Code really that bad in CPU/memory usage?
- kgwxd 8y ago
  Yes. Assuming you don't need to run other CPU/memory intensive programs, probably not a real big issue when plugged in, but it's a killer if you're running on battery.
- airstrike 8y ago
  Maybe not compared to other GUI apps, but when you've grown accustomed to the performance of vim in a terminal, it feels very sluggish in comparison
  - simias 8y ago
    I run Emacs outside of the terminal and it's quite fast. There used to be a time where it was considered a resource hog but compared to the monster IDEs we have today it's pretty lightweight. It's not the best editor for dealing with huge files but it does the job (IIRC it used to be a significant limitation back in the 32bit days but not so much on 64bit systems).
    - airstrike 8y ago
      I hear you. To be clear, I'm not saying vim is significantly faster than any other app out there. I'm merely saying VS Code specifically is sluggish in comparison
    - licebmi__at__ 8y ago
      Maybe it was my configuration, but the reason I switched from vim to emacs, was that I was debugging some large log files that made vim choke. I read a comment praising that behavior and I was surprised to see that it was the case, more so as I was in the belief that emacs had a lot of bloat. Which editor would you consider that is better with large files? Not really interested in switching, but really curious.
bo1024 8y ago
Interesting because this post is not about anything people typically focus on -- navigating, hands on the home row, etc -- but mostly about plugins, tools, and performance.
- acidburnNSA 8y ago
  Learning vim with a focus on the basics instead of plugins is a good way to get started. Things like the basic navigation, reflowing, digraphs, macros, splits, etc. are super productive.
- nickjj 8y ago
  I think things like home row typing are very human specific. I don't type properly and I never rest my hands on the home row. My hands fly all over the place and I only use half the fingers on both hands. After 20 years of typing, that's what feels natural to me. It felt natural on day 1 and the same 20 years later. I can type at about 75 WPM using online tests with really high accuracy, so I haven't seen it as a real bottleneck. Call me crazy but I think home row proper typing is the most non-ergonomic and painful layout possible. It's not natural at all to keep your hands completely stationary for hours and while making subtle finger movements. Even if I try that for 5 minutes straight I get all sorts of cramps and weird pains in areas of my hands and arms that I didn't even know existed.
deleted 8y ago
[deleted]
vehemenz 8y ago
Sublime Text handles large files with ease. I routinely hand edit 5MB CSV files (with a color-coding plugin) and have had zero performance issues.
- bacondude3 8y ago
  What plugin? I've been trying to find a good CSV plugin for Sublime.
  - vehemenz 8y ago
    rainbow_csv
- de_Selby 8y ago
  I'm not arguing for or against sublime's performace, but I'd suggest you need to redefine what a large file is!
  - acidburnNSA 8y ago
    For example in the nuclear industry we regularly view and edit 1 GB text file inputs and outputs from chain reactor simulators. Vim, grep, tail -f, and awk, and Python are all essential tools in our belts.
    - kamaal 8y ago
      Wow! That's the coolest thing I've read in a while. I can only imagine how much fun it must be to work as a Nuclear Physicist.
  - vehemenz 8y ago
    The author of the article was having issues with a 1.5MB file. 5MB is substantially larger than that!
- danmg 8y ago
  5MB isn't big.
jkingsbery 8y ago
Just throwing out an alternative: for work, I have a 230k word file of notes I've taken that I edit with emacs org mode. I add to this file 2-3 time per week (so, not every day, but pretty frequently). With org mode, you get the "folding" of different sections for free. Plus, org mode has different tools for converting content, so no need to build one-off bash scripts for many common use cases.
kowdermeister 8y ago
> A big component of my overall problem was dealing with individual file names. umm, I know naming is hard, but xx_chapter_name.md?
- eythian 8y ago
  This is covered in the article. In particular, it makes inserting and rearranging hard.
  - thanatropism 8y ago
    I can't find anymore where I read that Niklas Luhmann's "Zettelkasten" (slip box or note repository) was filed according to the following rules: (1) If there's no related note in the box, give it number $last_number+1 (2) If there's a related note in the box, say, number 103, file it 103/A, 103/B, 103/C, etc. (3) If some subtopic of 103/A comes up, file it 103/A/1, etc. I did that with Markdown and an iPad app for a while. Now I have an actual paper slip box. It's very time-consuming but gives you space to think. Also it's interesting to see notes spatially over an entire living room once in a while. --- I'm lost in a digression. But it seems rather trivial to use a system like that (maybe with dots -- 10.1.1 etc. -- ) and write a script that reads a list of chapters in the order they're going to be used eventually and assembles a book. Heck, from my system I may be able to sort, scan and have someone at Upwork type it.
  - kowdermeister 8y ago
    As someone, who never written a book this makes sense, however is it that common that you move text between chapters that often? I guess it varies from writer to writer. However I would go mad with a single file that size. A 4k monitor with 20 small windows would be me approach :)
kamaal 8y ago
Learn Emacs and then you can save hours of work doing anything. All you do is learn how to write Elisp Macros. And then you automate your knowledge. Think of it like programming a text pad(s)(Like how excel is programming a list(s) of cells). You realize that the text buffer is your programming environment, with cursor movement as your basic control, and text output as your end goal. Then of course other programmatic facilities apply. Only recently wrote a piece of Elisp code at work, that takes a file, does a bit of error analysis and gives me offending lines and other inputs like ids. I take them in a buffer and do all kinds of set operations(intersection etc) from inputs in other buffers(Elisp code for that too). Then take them and have Elisp generate a email message for me(Again Elisp code to do this). I just copy paste and send it to respective stake holders. And I'm a novice who barely started with Emacs. I only imagine what I can do when I get fully proficient with it. It's like automating yourself. I guess we are only lucky our work happens to be mostly in text and we get to use emacs and vim(vim macros are just insane), just like accountants can put spreadsheets to crazy use as their work happens to deal with tables.
- ashton314 8y ago
  I feel like the ease with which one can write keyboard macros in Emacs is an often overlooked feature. Saves me so much work very day.
- oblio 8y ago
  Yeah, but you're basically just programming. Does Emacs really matter to what you listed? You could do all of that with Python and any programming editor.
  - kamaal 8y ago
    You have basically do programming to do anything anywhere. There is no magic. >>You could do all of that with Python and any programming editor. Perl is better at these text manipulation things than Python. Lisp will be around for a lot of time than these languages. Though I expect Perl to be around too. But then vim is literally a kind of VisualPerl. Emacs feels like VisualLisp. Before learing Elisp I was writing tons of Perl scripts to tasks like these. Perl is just insanely good at all things text. But Perl doesn't have Lisp like Macros. And eventually you realize you can weaponize Macros to all kinds of things you can't do in Perl. In short Elisp is better at a few things than Perl.
ashton314 8y ago
I just tried out editing a 1300321 word file with Emacs. Running in text-mode, I notice no lag. CPU usage tops out at about 3% on my machine (i5 MacBook Pro) when editing. Markdown-mode pushes it up a few points, but not a lot. Long live command line editors!
- deleted 8y ago
  [deleted]
- apocalypstyx 8y ago
  How long were the lines? From my experience (as a pretty heavy emacs users, so not knocking it) when I have a 5K+ word paragraph, quite alot of operations become laggy when within that paragraph/line (regardless of whether visual-line-mode is on or off). Fontlock makes it, yet, worse.
azthecx 8y ago
Well you seem to already have solved your problem, but if you haven't it might be worthwhile to consider using Latex, the ToC and everything else is already handled or its very likely that a plugin already exists. You can also have separate files and just include them on a main file. Converting Latex to Markdown is also pretty seamless so it's (relatively) easy to convert to use in your website.
- mishurov 8y ago
  I use latexmk for watching and recompiling a pdf after saving a .tex file and I don't use any plug-ins, only vim's standard syntax hi-lighting.
rejschaap 8y ago
There are many reasons for doing the things the author did, but I highly doubt saving time is a valid reason. The amount of time spent on setting this up and learning these tools and optimizing the workflows and writing scripts will most likely be much more than any time saved (real or imagined). It is a similar pitfall that developers step into when they optimize their code before profiling where the bottlenecks are at. But of course you should still do all of this, because it is a lot of fun and Vim rocks.
- noonespecial 8y ago
  Some yaks just look really good bald.
  - chosenbreed37 8y ago
    > Some yaks just look really good bald. Sure...but how long will they stay bald? :)
    - castis 8y ago
      Once you have the proper shaving environment set up it should be pretty easy to keep them as smooth as desired.
    - sophacles 8y ago
      There's a legend of another yak. It's called "dotfiles management". It has the wildest mane of hair and actively resists shaving. If however you manage to get this yak shaved, they say it will confer the power to keep the other yaks bald effortlessly, at the low cost of occasionally removing the stubble from your dotfiles yak. There's also many legends of people going mad trying to shave this particular yak so...
    - james_s_tayler 8y ago
      Yaks present infinite opportunities to shave them. This is the benefit of Yaks. You never run out of stuff to do. Plus you have all that delicious yak fur.
doktrin 8y ago
I've used vim for years, have vimium / vimperator installed in all my browsers, use vim navigation bindings in i3, etc. I still broadly prefer using ST3 with vintage mode over classical vim. It doesn't have the performance limitations of electron editors, doesn't force keyboard-only interaction and has a package ecosystem that is easier to maintain and navigate. Best of both worlds to me, just IMHO.
deleted 8y ago
[deleted]
mishurov 8y ago
based and redpilled
mark_l_watson 8y ago
As much as I have been using VSCode as a coding and writing ‘Swiss army knife’ lately, tmux and good editors like Vim and Emacs are great because context switching is easy. I have a similar workflow as the author of this blog, often writing a book manuscript in markdown while working on code examples for the book that I am working on.
acidburnNSA 8y ago
I just wrote a little e-book in vim using reStructuredText and Sphinx for all the bookkeeping. It took a bit to get started, but ended up being a really nice combo. Vim for all the editing and navigation, of course, and RST+Sphinx for all the hyperlinking, footnotes, TOC, glossary, index, headings, images, etc. Then I just rendered it to HTML, PDF, ePub, and pure text (for grammar checking). I think RST is less popular than Markdown, but it's really incredibly powerful. You can in-line LaTeX formulas, a Tikz image, a graphviz dot, and all sorts of things. Formatting and theming is a bit of a pain, but I think with just a little more work, it'd be easy to recommend this path for anyone making technical books, courses, etc. Lightweight markup languages and vim feel like steampunk at first, but they're actually more productive than mainstream modern tools.
- randlet 8y ago
  RST+Sphinx is really fantastic other than the impossible to remember syntax.
  - acidburnNSA 8y ago
    Bonus of writing a book in it: about 50 pages in you finally get the hang of it. "Which side of this does the underscore go on!?"
- asicsp 8y ago
  do you have a more detailed write up for this publishing process? or some references that you followed to get this set up? I'm looking for alternate ways than just github-style-markdown+pandoc for creating ebooks for more features and polished look I'm also looking into alternates like https://github.com/rstudio/bookdown https://github.com/rstudio/bookdown, https://github.com/hplgit/doconce https://github.com/hplgit/doconce and https://www.methods.co.nz/asciidoc/index.html https://www.methods.co.nz/asciidoc/index.html
  - acidburnNSA 8y ago
    Not yet, but writing one for today's versions of all the tools is something I plan to do within a week. I can ping you if/when I get it up. I started with older links like this: https://pedrokroger.net/using-sphinx-write-technical-books/ https://pedrokroger.net/using-sphinx-write-technical-books/ This is inspiring but less useful: https://www.tompurl.com/2012-11-22-writing-a-book-with-vim.html https://www.tompurl.com/2012-11-22-writing-a-book-with-vim.h... This was useful for theming: https://github.com/FriendsOfEpub/eBookTricks https://github.com/FriendsOfEpub/eBookTricks
umvi 8y ago
My e-book pipeline consists of: Markdown + VSCode (for editing) Pandoc to generate DOCX from Markdown Calibre CLI to generate MOBI from DOCX (and to fill in the e-book metadata) This seems to be the cleanest way I've discovered for generating nice Kindle books that have full table of contents, etc.
trextrex 8y ago
It seems like the author's file numbering problem could have been easily solved with a slightly different numbering scheme -- reserve a couple of digits for additional content. So start with 0010, 0020, 0030 ... and if you wanted to add something between 0010 and 0020, it becomes 0015 and so on. Then you would have to renumber the files only at the very end of the process.
- randlet 8y ago
  Getting bad flashbacks to the days of explicit line numbers in Basic.
- nickjj 8y ago
  The problem there is the lesson numbers need to be displayed in the course platform's UI. I can't have my course's lesson numbers be increments of 10. It's too confusing for end users, and they also can't be different than what I have on file because then it would be a nightmare to maintain (as the person who created the course). Using gapped numbers is a great way to solve certain ordering problems though. That's a common thing to do with database position columns for ordered content.
  - trextrex 8y ago
    I meant to say that you would use that scheme while you were working on your lessons, and at the end of it all, do a single pass of renumbering all the lessons with an appropriate number scheme.
jpm_sd 8y ago
OK, I'm sold. I finally have to learn vi[m].
dlkf 8y ago
I think the most interesting thing about the article isn't the solution. It's the problem: how do you organize a long piece of writing (O(100k) words) into logical units whose length isn't dictated in advance, and which don't force some kind of manual global refactor (e.g. renumbering chapters) every time a change is made. The author's solution (one big file created with Vim) is reasonable and seems to work well for him. However, it seems to trade modularity/reusability. I'd be interested to hear about a microcontent solution (and the attendant tooling) that doesn't make this tradeoff. Or if I'm wrong about the tradeoff, I'd like to hear why.
- nickjj 8y ago
  I think it depends on what you're working on. When it comes to creating a course, there really is no way to reuse those files in a way that makes sense. A course on Docker and Flask have nothing in common for example. Also, a course's writing isn't the only aspect. There's video too. Each video is its own individual unit of output. Once a course is delivered on video, you really can't go back and start adding in new lessons to the middle because your previously recorded videos depend on things being in the old order. When you record lesson 103 and it expects code to exist in folder 103/ in a git repo, you can't just add a new lesson after 57 because now 103 becomes 104 and it throws everything off. So in my case, once I complete the course, its TOC is set in stone. Those numbers won't change, but I want the flexibility to change them as I actively make the course which is when they change a lot.
  - dlkf 8y ago
    That's fair. My specific interest lies in Help Center content / software documentation, in which some degree of reusability is critical.
  - luxpir 8y ago
    57a
- Certhas 8y ago
  The approach really makes little sense to me to be honest. Latex or any competent Text processing tool should take care of most of these needs. As far as I know the tech the OP uses is used almost nowhere where people work with large bodies of text, meaning the editing and typesetting industry.
ausjke 8y ago
while I use vim a lot at the console, I still use GUI for real coding, I use geany which is super light, but geany is not strong in markdown editing(sadly). I really hope vim has a light-weight GUI version, better than the existing gvim and geany, that integrates nerdtree and bundles a few "must-have" plugins out of box.
- opportune 8y ago
  I recommend using an IDE with a good vim plugin. I predominately code this way and I feel like I get all the benefits of both vim and the gui. I can use the intuitive UI of the IDE to navigate through the project (using IntelliJ, find usage and shift-shift search are clutch) and handle builds/test/refactoring partly visually, and then I can edit individual files very efficiently with vim. also it's really nice being able to click around in vim if you think it will be faster than navigating to the desired point using the keyboard, really reduces the cognitive overhead
paultopia 8y ago
Hmm. I use vim sometimes to edit text, and I find it markedly less ergonomic than using vim for editing code, for one key reason: text is typically organized in paragraphs, rather than lines, and all the vim movements make much more sense for lines. Like, if I'm editing a block of text in a long paragraph that looks like a single line to vim, I don't have a mouse anymore, and up-down movements just leave the paragraph, so I usually find myself with awkward commands like `50w` to try and guess the number of words to move to the point where I'm trying to edit. Sadness. Then again, this might just be because I don't have enough vim skillz yet. There's probably some command to make vim pretend a visual line is a real line...
- opportune 8y ago
  if you know the characters of the word you want to jump to you can type /<prefix> <ENTER> and hit n to cycle through the substring search results
- replax 8y ago
  I agree that it can be a bit annoying for working with visual lines. You can move up and down visual lines by using ‚gj‘ and ‚gk‘ instead of ‚j‘ and ‚k‘.
  - paultopia 8y ago
    Ooh, I'll try that. Thanks!
    - jsat 8y ago
      :nmap j gj :nmap k gk
- iimblack 8y ago
  Two things that help me a lot when working in paragraphs: - gj instead of j and gk instead of k to move up and down by visual line instead of line number. - Just go where I want by using / and then typing the word I want to navigate to. No need to guess how many words in it is.
burritofanatic 8y ago
Editing is where the dangerous stuff happens. I was editing a traditional document on a processor called Scrivener, and my worst fear is an errant change unknown to me after saving the file. Going strictly on something like vim might be too hardcore, but if I started out with something like Scrivener, then port to .txt and commit my edits, and bring it back out to Scrivener for compiling, it may make sense. I haven't looked into too many of my options, but if anyone else doing a decent amount of writing can share their tips, please do!
- titanomachy 8y ago
  Sounds like you should version control your files...
ryanmcbride 8y ago
Vim is great, but I'm very glad that I learned it early in my life as an engineer. The learning curve slowed me down at a time where it was understandable if I was slow at doing something. I feel like I would have had a much harder time if I had tried to learn it after I was already completely comfortable with another editor. That doesn't stop me from recommending it to everyone.
daveFNbuck 8y ago
When writing a large document, I prefer to use a file format that has a way to import the contents of other files. When writing a long document in LaTeX, I would have separate files for different sections, plus a main file that had the overall layout and imported each section in the right place. This approach allows you to easily insert/remove/rearrange sections and doesn't require having a giant file open in your editor. It also makes viewing the compiled version easier, as you don't have to compile the entire document to see what the part you're working on looks like.
- NegativeLatency 8y ago
  One of my favorite things about vim is being able to open very large files. (Larger than my available RAM)
- nickjj 8y ago
  But then we're back to the same problem in the article where you have 150+ numbered / referenced files.
  - daveFNbuck 8y ago
    They're not numbered. Referencing doesn't have the problems the article complains about. Also, you can go between these extremes and have a handful of medium-sized files.
    - nickjj 8y ago
      The numbers are very important because the reference has to happen outside of the editing tool / structure. I need to be able to identify that lesson 'xyz' is lesson 50 so I can say to check out the code in folder 50 inside of a git repo.
      - daveFNbuck 8y ago
        When you compile the document, the numbering is automatically added just like it would be if you had a single large document. The importing gives you the same final result as having a single file, but gives you the flexibility to put individual lessons in separate files for easier editing and reuse in other course plans. This also makes it easier to do things like print out individual lessons if you need a hard copy but don't want the entire document.
koonsolo 8y ago
Am I missing something obvious here? I'm a heavy VIM user myself, but for documents, I use a word processor. Why mess with filenames and sequence numbers, when any basic word processor handles this for you?
- ahmedalsudani 8y ago
  A couple of reasons: 1. Version control 2. Simple text files that are easy to maintain and convert into different formats There are other reasons I can think of but those are the biggest two. Personally, I hate using word processors and would love to never have to use one again. Their GUIs and learning this and that shortcut key (which usually don't transfer to other apps) used to be tolerable but I can't stand them now.
  - koonsolo 8y ago
    1. Most word processors have revision control and multi-author options. They even allow comments etc. 2. You have all kinds of open formats such as MS Word, RTF, OpenOffice, that can basically export to anything you want. The only reason I do see is that you can use the tools that you already know, such as code version control and your code editor. But other than that, it seems strange to try to do this thing in plain text files. Because then you have all these problems that shouldn't be problems in the first place.
bor0 8y ago
I've written my first book entirely in Vim. Using Leanpub's support for Markdown+LaTeX was a very pleasant experience.
deleted 8y ago
[deleted]
12dellydell 8y ago
My take-away isn't 'switch to Vim' rather just how rewarding it is to master a smaller set of powerful tools.
konart 8y ago
Today was the 3rd time I've tried to come into VIM. I've stopped as soon as YouCompleteMe came into play. Instead of just git clone you have to do this and that just to have a damn autocomplete... And after time wasted - vim segfaulted on me. Sorry, but I really can't see how this can be better than, say, IDEA. Installed it once, git pushed my settings - and never had any problems with it. Shortcuts are almost 100% universal these days.
- jacoblambda 8y ago
  While it is fair that some of the plugins are problematic, in general the plugin space is fairly easy to traverse. Most plugins take at most 2 steps to install (add to .vimrc, run update command) when using a plugin manager. Those that have external dependencies that take extra work are often packaged for distros. I know YouCompleteMe has an emerge package that bypasses all the setup hassle.
  - konart 8y ago
    I was using pathogen and it's true that some plugins are just git clone away. But's it doesn't matter when you have to spent all evening to figure out something that simple and in the end it sill doesn't work. >often packaged for distros... I don't really care at this point. Vim is dead for me. And tbh most things that people describe here in the comments seem more like a form of autosuggestion. Losing context? What? All modern editors have command menu with everything you need. Fuzzy search, any command that the editor or and IDE can offer, including those provided by plugins installed. And you don't have to worry about pluging updates - it's automatic. All you have to do is to read a changelog if you are interested.
  - konart 8y ago
    As a final attempt I've just installed SpaceVim. A distro. Full of features and whatnot. lang#go layer enabled - check. I go to the first .go file I can remember of and... autocomplete works. But only for the packages provided by the go iteself. Not the 3rd party. Kind of... what the point really? As a final word: I'm trully happy for people who have found their happiness in Vim. Nothing can be better that having a tool that satisfies your needs to the fullest. But I still can see it as a capable DE. Navigation is great and I use it in Firefox everyday via Tridactyl. All those hacky '3ytcvnsdg' whatever commands are super nice when you are working with some kind of csv dump of an oracle database via ssh (I had this moment!). Editing some configs on my Raspbery Pi? Sure. Writting books and such? Maybe, never had such experience. But software development? Seems like a nightmare to me.
TeddyDD 8y ago
I used to think Vim and company are only worth it when you work with structured text (like programming languages) most of the time. I'm not so sure nowadays. I had to work on big prose document in Libre Office. I hated every second of it. It might be because I used to modal editing. It felt like typing with one finger when you are used to touch typing... I got question. It here anyone who learned Vim editing model and decided it's worse than „traditional” Cua, mouse oriented editors[1]? I can't remember seeing any blog posts like „I used Vim for X years but I switched to Cua editor”. [1]: well, I switched to Kakoune from Spacemacs but that's another modal editor (not Vi clone tho) so it doesn't count ;)
- d33 8y ago
  What exactly were you missing? Could it be that you're just not used to the shortcuts that let you navigate with the cursor, remove previous word etc.?
  - TeddyDD 8y ago
    That was an issue, yes. I know basic shortcuts ({ctrl, shift} + arrows, ctrl+backspace) but I assume someone used to Cua editor would know more tricks. I missed actions like: - select to given character - select to begging/end of the line/whole line - select sentence/paragraph/text with the same indentation I know some of those actions are available with multiple mouse clicks (3 clicks to select paragraph If I recall correctly) but that means you have to use mouse. Beside this ctrl+f search is not as good as / in Vim. It has no regex support for example (you can open dialog that has option to enable regex but that's more than one shortcut away). Actions in Cua editor cannot be composed and reused, that's also an issue for me.
sergioro 8y ago
If I were to write an article on how increase productive with Vim I wouldn't focus on its plugins (after all many other editors/IDEs have great plugins). The power of Vim relies in its multi-modal editing. It requires time to get used to it but... once you're comfortable switching between modes it quickly pays off in productivity. I think the text editor is the most important tool of a developer and Vim outperforms any non-modal editor. My thoughts on Vim are summarized in this quote by Abraham Lincoln: "Give me six hours to chop down a tree and I will spend the first four sharpening the ax."
anthony_doan 8y ago
I use Tmux + Vim. It's pretty nice. The investment time is big but it's a one time investment with minimum upkeep. I don't use any plugin other than language plugin.

378 points by nickjj 8y ago

Let's be honest though; vim saves you hours of work if you're already good at vim. If you're not then it'll just slow you down. It takes practice and daily use to learn. I love vim but let's not sugar coat it.

giancarlostoro 8y ago
Indeed. JetBrains IDE's save me hours of work because I'm comfortable working with their IDE's. I am also more comfortable with Emacs than I currently am with VIM, but I use either one depending on circumstances. To be fair op did write how it saves them hours.
- emsy 8y ago
  Vim plugins are available for most IDEs. I almost never use vim (except for the shell), but I use vim-style editing in all the IDEs I use.
  - polyterative 8y ago
    Is that a viable way to learn vim? As an advanced jetbrains poweruser
    - qqqwww 8y ago
      Absolutely - I first learned "vim" using a visual studio plugin. Since then I used it in 5 other editors, but I barely used vim itself. The main downside is that you don't learn things like window managing, file exploration, etc - mostly because other editors are already good at that, and it's not something plugins focus on.
      - polyterative 8y ago
        Is it worth it? I am already pretty fluent using my custom-ish shortcuts for all navigation, will vim speed me up at this point?
    - emsy 8y ago
      I've learned vim in the standard vim editor at the time, so I can only guess but it should probably work. 99% of my work with vim is navigating and editing text. The rest is macros and substitute, all of which is available in IntelliJ. The things you miss out on are (I think) colorschemes and vim specific plugins (which you mostly don't need because you have a fully fledged IDE).
    - alpaca128 8y ago
      Doing it that way will at least prevent you from being disappointed due to missing features. Vim plugins are nice and I definitely prefer them over basic input, but almost all of them don't even cover the basics.
    - neurotrace 8y ago
      That's how I learned it. I got the extension for VS Code and just started playing with it. If I got frustrated, I would slap "i" and go back to my normal way of doing things. The frustrations went down and now I use vim bindings all the time. I'd also recommend getting a Vim plugin for the browser (https://addons.mozilla.org/en-US/firefox/addon/vimium-ff/ https://addons.mozilla.org/en-US/firefox/addon/vimium-ff/). Totally optional but it really helped click in the j and k movements.
mikece 8y ago
Ditto the Dvorak keyboard enthusiasts...
- hopler 8y ago
  Dvorak doesn't save time, it's not faster than qwerty given equal practice
  - chrisfinazzo 8y ago
    But given Vim's quirks, is that layout more amenable to working quickly? Given how people gripe about it in QWERTY setups, that's certainly a possibility.
- CydeWeys 8y ago
  Even less so. Unless you're doing transcription, typing speed is not even close to being the primary limitation on how quickly you work. Thinking of the words is. The difference between a typist who can hit 100 wpm using QWERTY and 110 wpm using DVORAK will only be exposed when playing TypeRacer. Otherwise there's no functional difference. You have to get down to hunt-and-peck until you see typing ability actually affect productivity (and I have seen those people). If you can touch type using any keyboard layout, though, then typing speed won't be a meaningful limitation for you.
  - bunderbunder 8y ago
    I broke my wrist a few years ago, and had to spend a while typing with one hand on a half-qwerty keyboard setup. I took a huge hit to my typing speed, but the rate at which I was getting work done didn't really change.
    - lfowles 8y ago
      Noticed the same when I switched to an Alphagrip and could only maintain 50-60wpm.
  - simias 8y ago
segmondy 8y ago
That's the wrong way to look at it. Anything you're not good at it is going to slow you down. The question is that even tho you might be slow, if you put in the effort, learn it then get good, will the savings and speed up make up for the initial slow down? I'm a vim fan and won't try to convince others. But I personally believe that the answer is yes. One of the secret to being successful with vi is that of mindset. You need to have a positive mindset that it's worth learning, you need to commit to learning it. I learned vi when network speed was very slow and systems didn't have enough memory. It was faster than any other editor. So I had the mindset that I needed to learn it. if I was starting out today, it probably would be hard when you have editors like vscode. I have typed and used computers everyday for 25 years non stop and I have no issue with my fingers and I believe a major part of it is using vim and my fingers not having to travel and move out to find a mouse or hitting Ctrl+ keys.
- amelius 8y ago
  Another way to look at it is: what fraction of the time are you typing versus thinking? If it's less than 20%, then a faster editor will probably not speed you up by a significant amount.
  - megous 8y ago
    Typing and thinking are almost the same thing to me. I'm either writing code, or bullet lists with things to do, concerns to take into account, things I've learned, etc. Text file is an extension of my memory, and a place to distill, manipulate, and organize my thoughts.
  - TeMPOraL 8y ago
    Vim won't speed up your typing. It'll speed up your editing. Adding/discarding/modifying large blocks of text, or spread-out blocks of text. It'll let you think in terms of moving this block there, replacing these words, duplicating these patterns, etc. The efficiency increase comes, in large part, from allowing you to make steps that are closer to how you think. And even if we're talking about 20% of your time, improving that 2-10x is nothing to shake a stick at. 20% of 10 hours is 2 hours, if Vim makes you edit 2x faster, that's 1h saved, per day. And that's without accounting for other work you could move to your suddenly more efficient plaintext mode, and the work you don't even consider doing because your editing experience is too painful (it sometimes work the other way too; there are things I won't do in Emacs, but I will in IntelliJ, where project-wide, language-aware refactors can be done with two clicks in full confidence that nothing will break).
emsy 8y ago
What's your argument here? I don't try to be snarky, but learning a new skill is always slow in the beginning. If anything we should encourage people to learn these skills as early as possible so they can reap the benefits longer. I admit vim's learning curve is pretty steep, and I'm glad I learned it during my bachelor's thesis where I had a lot of time to do so.
- tiuPapa 8y ago
  Not OP, but I think the argument is that Vim isn't a magic editor that would make you fast out of the box. And if you just want to get work done without concentrating on learning a new skill, maybe you should look at other options?
  - emsy 8y ago
    I can only speak for myself, but I've used vim plugins on almost every IDE I've ever used. Unlike editor shortcuts, which are often exclusive to a certain IDE, vim is transferable and that's how it has one of the best cost/benefit ratios for me.
    - SketchySeaBeast 8y ago
      > Unlike editor shortcuts, which are often exclusive to a certain IDE, vim is transferable and that's how it has one of the best cost/benefit ratios for me. Doesn't that just mean you've selected VIM's syntax for all your IDE's? Most IDE's seem to have plugins for other popular editors.
      - NegativeLatency 8y ago
        Seems like it’s the difference between him being supported in many IDEs and say visual studio shortcuts being supported in some thing like Atom. (Support May exist for this, IDK)
        SketchySeaBeast 8y ago
benawad 8y ago
short term vim slows you down, long term vim speeds you up
brootstrap 8y ago
Valid point. I have to give some updoots for VIM, (or emacs too i guess). The visual editing gives you such an advantage, i'm talking just about coding. Most of my co-workers come from science background and think VI is a joke from that crazy professor in college. I forced myself to really learn VI one summer in 2013. Since then i've been flying around my text editor. I'm not lying, co-workers think you are a god damn wizard. I try not to be a doosh, but I have one co-worker who loves VIM but doesnt really use it (insert mode ftw). Whenever I can i try to subtly drop hints. "Instead of hitting the arrows keys over and then backspacing, you can type cw to change the word" Just little things like that. Once you realize that vim is modular and chainable, you really start to take off!
sametmax 8y ago
Even if you are very good at vim, it's still debatable. The thing is, vim forces you to do a lot of stuff that the machine could do for you. E.G: you need to remember states and how to transition between those states. Plus the human mind sucks at context switching. All in all, this adds up, and there is a limit to the cognitive load you can accumulate. You only have one brain and you need to share it between all tasks, including solving the problem at hand and using tools to do so. Half of my income comes from training professionals on site. Experience taugh me that every time somebody uses vim, 4 things will happen: - the person will be one of the best of the team - the person will have some weird bug/config problem/compat issue at some point and will waste time fixing it at least once during the training, swearing it never happens (also the person with vim usually has a very custom setup so this compounds) - at the end of each day, the person will be one of the most exhausted, and will make way more mistakes than the others compare to the morning baseline - at equal technical level, the person with vscode/sublime/jetbrain will be faster on average. Maybe not the first hour. But it will come. So, yes. Vim may be fun. It may suit your workflow and ecosystem, and even your sense of aesthetic. But I don't buy the productivity boost.
- appleiigs 8y ago
  Do you have examples of the bug/config/compat issues? I get those problems with an IDE, not Vim. IDE is always trying to lint, debug, run stuff... mix that with virtual environments and what a mess. With vim being on every system, i don't really carry much baggage around. I have my vim settings file in cloud storage. And maybe one pluggin (NERDTree) on my main machine.
  - sametmax 8y ago
    No, I never, ever look at the source of the problem nor the solution. I've used vim for 15 years, but I don't have time for this, so I don't customize anything, and if somebody has a problem, the person is responsible for fixing it. I'm not even waiting on people with Vim problems anymore during the lectures. I just go on, they will catch up.
- nickjj 8y ago
pletnes 8y ago
Programming is much worse. In the beginning, I spent just a few hours a week programming. Today, it’s a sizeable fraction of my work week. Programming is thus a complete waste of time.
manifestsilence 8y ago
For the first couple years I used vim, I spent half the time just hitting "i" and using it like a normal editor. And if I was in the mood to learn something, I would hit <esc> and try not to wreck my document. It's not that big a barrier if you start gently rather than going with a purist mentality that the arrow keys are evil and should be pried off the keyboard. :) This approach is especially nice when there are great vim keybindings for things like Visual Studio. The only thing you have to learn to start using vim is to always pay attention to if the cursor is a block or not, and if it is, remember to hit "i" before you mash keys if that's not what you want.
- Izkata 8y ago
  I don't think I ever did that, but I do have another suggestion that I did for a long while, along the same "start gently" mentality: Use gvim It not only has menus, but the shortcuts on the right side of each menu item aren't special - the they're the same commands you'd just type into vim normally. I picked up a bunch from those, but in particular I remember folding being one I didn't even know existed in vim until using it in one of the menus.
porpoisely 8y ago
Agreed. I use vim daily and really the only text processor I use. But the learning curve is pretty steep.
mettamage 8y ago
I'm sorry: learning the basics of vim isn't hard, and it never will be, provided you have the right education (I suppose that's true for anything but in this case it's a platitude that I viscerally experience to be true). The right education is: vimtutor (type it in your CLI and within 30 minutes you're done). I deleted my rant but I dare anyone to take my challenge: do vimtutor for 30 minutes and then answer the following question twice (before vimtutor and after it) in a comment. I perceive vim to be difficult: (1) strongly disagree, (2) disagree, (3) agree, (4) strongly agree. Once you know the basics of vim, then it won't slow you donw.
- johnmarcus 8y ago
  Um...hate to point out, but he didn’t say it was difficult. He said unless your practiced in it, it won’t be particularly more efficient in it. I’m sur vim tutor teaches all the things, but until they are muscle memories in, you will see no time advantage. A 30 minute tutorial will not muscle memory all the things in, that takes time and practice. Also, while not hard (I use vim constantly as a sys admin) I don’t personally think it compares to what I can get done in Atom and it’s never going to be my editor of choice, no matter how familiar.
  - mettamage 8y ago
    Vimtutor doesn't muscle memory everything in. But it does muscle memory in basic things such as deleting, moving around and going to beginning of lines, enf of lines etc. That's what it did on my first run. It indeed wasn't perfect, but there were already a couple of tricks that I've learned that I really liked and that's what you get out of it. I'm not saying you work faster, I'm saying after vimtutor you won't work slower. I suppose you still work slower if you compare it to your favorite text editor, I'm not very strongly proficient in any text editor, which is why I'm not noticing slow downs.
- kerbalspacepro 8y ago
  >The right education is: vimtutor (type it in your CLI). Well I just discovered a new thing to do over the next 25-30 minutes
darkpuma 8y ago
Running through vimtutor a few times one weekend does wonders. And compared to other trades, a few hours of training on a tool is pretty damn quick.
philwelch 8y ago
Obviously the best option is to learn vim as early as possible to maximize your return on time invested.

fouc 8y ago

Is VS Code really that bad in CPU/memory usage?

kgwxd 8y ago
Yes. Assuming you don't need to run other CPU/memory intensive programs, probably not a real big issue when plugged in, but it's a killer if you're running on battery.
airstrike 8y ago
Maybe not compared to other GUI apps, but when you've grown accustomed to the performance of vim in a terminal, it feels very sluggish in comparison
- simias 8y ago
  I run Emacs outside of the terminal and it's quite fast. There used to be a time where it was considered a resource hog but compared to the monster IDEs we have today it's pretty lightweight. It's not the best editor for dealing with huge files but it does the job (IIRC it used to be a significant limitation back in the 32bit days but not so much on 64bit systems).
  - airstrike 8y ago
    I hear you. To be clear, I'm not saying vim is significantly faster than any other app out there. I'm merely saying VS Code specifically is sluggish in comparison
  - licebmi__at__ 8y ago
    Maybe it was my configuration, but the reason I switched from vim to emacs, was that I was debugging some large log files that made vim choke. I read a comment praising that behavior and I was surprised to see that it was the case, more so as I was in the belief that emacs had a lot of bloat. Which editor would you consider that is better with large files? Not really interested in switching, but really curious.

bo1024 8y ago

Interesting because this post is not about anything people typically focus on -- navigating, hands on the home row, etc -- but mostly about plugins, tools, and performance.

acidburnNSA 8y ago
Learning vim with a focus on the basics instead of plugins is a good way to get started. Things like the basic navigation, reflowing, digraphs, macros, splits, etc. are super productive.
nickjj 8y ago
I think things like home row typing are very human specific. I don't type properly and I never rest my hands on the home row. My hands fly all over the place and I only use half the fingers on both hands. After 20 years of typing, that's what feels natural to me. It felt natural on day 1 and the same 20 years later. I can type at about 75 WPM using online tests with really high accuracy, so I haven't seen it as a real bottleneck. Call me crazy but I think home row proper typing is the most non-ergonomic and painful layout possible. It's not natural at all to keep your hands completely stationary for hours and while making subtle finger movements. Even if I try that for 5 minutes straight I get all sorts of cramps and weird pains in areas of my hands and arms that I didn't even know existed.

deleted 8y ago

[deleted]

vehemenz 8y ago

Sublime Text handles large files with ease. I routinely hand edit 5MB CSV files (with a color-coding plugin) and have had zero performance issues.

bacondude3 8y ago
What plugin? I've been trying to find a good CSV plugin for Sublime.
- vehemenz 8y ago
  rainbow_csv
de_Selby 8y ago
I'm not arguing for or against sublime's performace, but I'd suggest you need to redefine what a large file is!
- acidburnNSA 8y ago
  For example in the nuclear industry we regularly view and edit 1 GB text file inputs and outputs from chain reactor simulators. Vim, grep, tail -f, and awk, and Python are all essential tools in our belts.
  - kamaal 8y ago
    Wow! That's the coolest thing I've read in a while. I can only imagine how much fun it must be to work as a Nuclear Physicist.
- vehemenz 8y ago
  The author of the article was having issues with a 1.5MB file. 5MB is substantially larger than that!
danmg 8y ago
5MB isn't big.

jkingsbery 8y ago

Just throwing out an alternative: for work, I have a 230k word file of notes I've taken that I edit with emacs org mode. I add to this file 2-3 time per week (so, not every day, but pretty frequently). With org mode, you get the "folding" of different sections for free. Plus, org mode has different tools for converting content, so no need to build one-off bash scripts for many common use cases.

kowdermeister 8y ago

> A big component of my overall problem was dealing with individual file names. umm, I know naming is hard, but xx_chapter_name.md?

eythian 8y ago
This is covered in the article. In particular, it makes inserting and rearranging hard.
- thanatropism 8y ago
  I can't find anymore where I read that Niklas Luhmann's "Zettelkasten" (slip box or note repository) was filed according to the following rules: (1) If there's no related note in the box, give it number $last_number+1 (2) If there's a related note in the box, say, number 103, file it 103/A, 103/B, 103/C, etc. (3) If some subtopic of 103/A comes up, file it 103/A/1, etc. I did that with Markdown and an iPad app for a while. Now I have an actual paper slip box. It's very time-consuming but gives you space to think. Also it's interesting to see notes spatially over an entire living room once in a while. --- I'm lost in a digression. But it seems rather trivial to use a system like that (maybe with dots -- 10.1.1 etc. -- ) and write a script that reads a list of chapters in the order they're going to be used eventually and assembles a book. Heck, from my system I may be able to sort, scan and have someone at Upwork type it.
- kowdermeister 8y ago
  As someone, who never written a book this makes sense, however is it that common that you move text between chapters that often? I guess it varies from writer to writer. However I would go mad with a single file that size. A 4k monitor with 20 small windows would be me approach :)

kamaal 8y ago

Learn Emacs and then you can save hours of work doing anything. All you do is learn how to write Elisp Macros. And then you automate your knowledge. Think of it like programming a text pad(s)(Like how excel is programming a list(s) of cells). You realize that the text buffer is your programming environment, with cursor movement as your basic control, and text output as your end goal. Then of course other programmatic facilities apply. Only recently wrote a piece of Elisp code at work, that takes a file, does a bit of error analysis and gives me offending lines and other inputs like ids. I take them in a buffer and do all kinds of set operations(intersection etc) from inputs in other buffers(Elisp code for that too). Then take them and have Elisp generate a email message for me(Again Elisp code to do this). I just copy paste and send it to respective stake holders. And I'm a novice who barely started with Emacs. I only imagine what I can do when I get fully proficient with it. It's like automating yourself. I guess we are only lucky our work happens to be mostly in text and we get to use emacs and vim(vim macros are just insane), just like accountants can put spreadsheets to crazy use as their work happens to deal with tables.

ashton314 8y ago
I feel like the ease with which one can write keyboard macros in Emacs is an often overlooked feature. Saves me so much work very day.
oblio 8y ago
Yeah, but you're basically just programming. Does Emacs really matter to what you listed? You could do all of that with Python and any programming editor.
- kamaal 8y ago
  You have basically do programming to do anything anywhere. There is no magic. >>You could do all of that with Python and any programming editor. Perl is better at these text manipulation things than Python. Lisp will be around for a lot of time than these languages. Though I expect Perl to be around too. But then vim is literally a kind of VisualPerl. Emacs feels like VisualLisp. Before learing Elisp I was writing tons of Perl scripts to tasks like these. Perl is just insanely good at all things text. But Perl doesn't have Lisp like Macros. And eventually you realize you can weaponize Macros to all kinds of things you can't do in Perl. In short Elisp is better at a few things than Perl.

ashton314 8y ago

I just tried out editing a 1300321 word file with Emacs. Running in text-mode, I notice no lag. CPU usage tops out at about 3% on my machine (i5 MacBook Pro) when editing. Markdown-mode pushes it up a few points, but not a lot. Long live command line editors!

deleted 8y ago
[deleted]
apocalypstyx 8y ago
How long were the lines? From my experience (as a pretty heavy emacs users, so not knocking it) when I have a 5K+ word paragraph, quite alot of operations become laggy when within that paragraph/line (regardless of whether visual-line-mode is on or off). Fontlock makes it, yet, worse.

azthecx 8y ago

Well you seem to already have solved your problem, but if you haven't it might be worthwhile to consider using Latex, the ToC and everything else is already handled or its very likely that a plugin already exists. You can also have separate files and just include them on a main file. Converting Latex to Markdown is also pretty seamless so it's (relatively) easy to convert to use in your website.

mishurov 8y ago
I use latexmk for watching and recompiling a pdf after saving a .tex file and I don't use any plug-ins, only vim's standard syntax hi-lighting.

rejschaap 8y ago

There are many reasons for doing the things the author did, but I highly doubt saving time is a valid reason. The amount of time spent on setting this up and learning these tools and optimizing the workflows and writing scripts will most likely be much more than any time saved (real or imagined). It is a similar pitfall that developers step into when they optimize their code before profiling where the bottlenecks are at. But of course you should still do all of this, because it is a lot of fun and Vim rocks.

noonespecial 8y ago
Some yaks just look really good bald.
- chosenbreed37 8y ago
  > Some yaks just look really good bald. Sure...but how long will they stay bald? :)
  - castis 8y ago
    Once you have the proper shaving environment set up it should be pretty easy to keep them as smooth as desired.
  - sophacles 8y ago
    There's a legend of another yak. It's called "dotfiles management". It has the wildest mane of hair and actively resists shaving. If however you manage to get this yak shaved, they say it will confer the power to keep the other yaks bald effortlessly, at the low cost of occasionally removing the stubble from your dotfiles yak. There's also many legends of people going mad trying to shave this particular yak so...
  - james_s_tayler 8y ago
    Yaks present infinite opportunities to shave them. This is the benefit of Yaks. You never run out of stuff to do. Plus you have all that delicious yak fur.

doktrin 8y ago

I've used vim for years, have vimium / vimperator installed in all my browsers, use vim navigation bindings in i3, etc. I still broadly prefer using ST3 with vintage mode over classical vim. It doesn't have the performance limitations of electron editors, doesn't force keyboard-only interaction and has a package ecosystem that is easier to maintain and navigate. Best of both worlds to me, just IMHO.

deleted 8y ago

[deleted]

mishurov 8y ago

based and redpilled

mark_l_watson 8y ago

As much as I have been using VSCode as a coding and writing ‘Swiss army knife’ lately, tmux and good editors like Vim and Emacs are great because context switching is easy. I have a similar workflow as the author of this blog, often writing a book manuscript in markdown while working on code examples for the book that I am working on.

acidburnNSA 8y ago

I just wrote a little e-book in vim using reStructuredText and Sphinx for all the bookkeeping. It took a bit to get started, but ended up being a really nice combo. Vim for all the editing and navigation, of course, and RST+Sphinx for all the hyperlinking, footnotes, TOC, glossary, index, headings, images, etc. Then I just rendered it to HTML, PDF, ePub, and pure text (for grammar checking). I think RST is less popular than Markdown, but it's really incredibly powerful. You can in-line LaTeX formulas, a Tikz image, a graphviz dot, and all sorts of things. Formatting and theming is a bit of a pain, but I think with just a little more work, it'd be easy to recommend this path for anyone making technical books, courses, etc. Lightweight markup languages and vim feel like steampunk at first, but they're actually more productive than mainstream modern tools.

randlet 8y ago
RST+Sphinx is really fantastic other than the impossible to remember syntax.
- acidburnNSA 8y ago
  Bonus of writing a book in it: about 50 pages in you finally get the hang of it. "Which side of this does the underscore go on!?"
asicsp 8y ago
do you have a more detailed write up for this publishing process? or some references that you followed to get this set up? I'm looking for alternate ways than just github-style-markdown+pandoc for creating ebooks for more features and polished look I'm also looking into alternates like https://github.com/rstudio/bookdown https://github.com/rstudio/bookdown, https://github.com/hplgit/doconce https://github.com/hplgit/doconce and https://www.methods.co.nz/asciidoc/index.html https://www.methods.co.nz/asciidoc/index.html
- acidburnNSA 8y ago
  Not yet, but writing one for today's versions of all the tools is something I plan to do within a week. I can ping you if/when I get it up. I started with older links like this: https://pedrokroger.net/using-sphinx-write-technical-books/ https://pedrokroger.net/using-sphinx-write-technical-books/ This is inspiring but less useful: https://www.tompurl.com/2012-11-22-writing-a-book-with-vim.html https://www.tompurl.com/2012-11-22-writing-a-book-with-vim.h... This was useful for theming: https://github.com/FriendsOfEpub/eBookTricks https://github.com/FriendsOfEpub/eBookTricks

umvi 8y ago

My e-book pipeline consists of: Markdown + VSCode (for editing) Pandoc to generate DOCX from Markdown Calibre CLI to generate MOBI from DOCX (and to fill in the e-book metadata) This seems to be the cleanest way I've discovered for generating nice Kindle books that have full table of contents, etc.

trextrex 8y ago

It seems like the author's file numbering problem could have been easily solved with a slightly different numbering scheme -- reserve a couple of digits for additional content. So start with 0010, 0020, 0030 ... and if you wanted to add something between 0010 and 0020, it becomes 0015 and so on. Then you would have to renumber the files only at the very end of the process.

randlet 8y ago
Getting bad flashbacks to the days of explicit line numbers in Basic.
nickjj 8y ago
The problem there is the lesson numbers need to be displayed in the course platform's UI. I can't have my course's lesson numbers be increments of 10. It's too confusing for end users, and they also can't be different than what I have on file because then it would be a nightmare to maintain (as the person who created the course). Using gapped numbers is a great way to solve certain ordering problems though. That's a common thing to do with database position columns for ordered content.
- trextrex 8y ago
  I meant to say that you would use that scheme while you were working on your lessons, and at the end of it all, do a single pass of renumbering all the lessons with an appropriate number scheme.

jpm_sd 8y ago

OK, I'm sold. I finally have to learn vi[m].

dlkf 8y ago

I think the most interesting thing about the article isn't the solution. It's the problem: how do you organize a long piece of writing (O(100k) words) into logical units whose length isn't dictated in advance, and which don't force some kind of manual global refactor (e.g. renumbering chapters) every time a change is made. The author's solution (one big file created with Vim) is reasonable and seems to work well for him. However, it seems to trade modularity/reusability. I'd be interested to hear about a microcontent solution (and the attendant tooling) that doesn't make this tradeoff. Or if I'm wrong about the tradeoff, I'd like to hear why.

nickjj 8y ago
I think it depends on what you're working on. When it comes to creating a course, there really is no way to reuse those files in a way that makes sense. A course on Docker and Flask have nothing in common for example. Also, a course's writing isn't the only aspect. There's video too. Each video is its own individual unit of output. Once a course is delivered on video, you really can't go back and start adding in new lessons to the middle because your previously recorded videos depend on things being in the old order. When you record lesson 103 and it expects code to exist in folder 103/ in a git repo, you can't just add a new lesson after 57 because now 103 becomes 104 and it throws everything off. So in my case, once I complete the course, its TOC is set in stone. Those numbers won't change, but I want the flexibility to change them as I actively make the course which is when they change a lot.
- dlkf 8y ago
  That's fair. My specific interest lies in Help Center content / software documentation, in which some degree of reusability is critical.
- luxpir 8y ago
  57a
Certhas 8y ago
The approach really makes little sense to me to be honest. Latex or any competent Text processing tool should take care of most of these needs. As far as I know the tech the OP uses is used almost nowhere where people work with large bodies of text, meaning the editing and typesetting industry.

ausjke 8y ago

while I use vim a lot at the console, I still use GUI for real coding, I use geany which is super light, but geany is not strong in markdown editing(sadly). I really hope vim has a light-weight GUI version, better than the existing gvim and geany, that integrates nerdtree and bundles a few "must-have" plugins out of box.

opportune 8y ago
I recommend using an IDE with a good vim plugin. I predominately code this way and I feel like I get all the benefits of both vim and the gui. I can use the intuitive UI of the IDE to navigate through the project (using IntelliJ, find usage and shift-shift search are clutch) and handle builds/test/refactoring partly visually, and then I can edit individual files very efficiently with vim. also it's really nice being able to click around in vim if you think it will be faster than navigating to the desired point using the keyboard, really reduces the cognitive overhead

paultopia 8y ago

Hmm. I use vim sometimes to edit text, and I find it markedly less ergonomic than using vim for editing code, for one key reason: text is typically organized in paragraphs, rather than lines, and all the vim movements make much more sense for lines. Like, if I'm editing a block of text in a long paragraph that looks like a single line to vim, I don't have a mouse anymore, and up-down movements just leave the paragraph, so I usually find myself with awkward commands like `50w` to try and guess the number of words to move to the point where I'm trying to edit. Sadness. Then again, this might just be because I don't have enough vim skillz yet. There's probably some command to make vim pretend a visual line is a real line...

opportune 8y ago
if you know the characters of the word you want to jump to you can type /<prefix> <ENTER> and hit n to cycle through the substring search results
replax 8y ago
I agree that it can be a bit annoying for working with visual lines. You can move up and down visual lines by using ‚gj‘ and ‚gk‘ instead of ‚j‘ and ‚k‘.
- paultopia 8y ago
  Ooh, I'll try that. Thanks!
  - jsat 8y ago
    :nmap j gj :nmap k gk
iimblack 8y ago
Two things that help me a lot when working in paragraphs: - gj instead of j and gk instead of k to move up and down by visual line instead of line number. - Just go where I want by using / and then typing the word I want to navigate to. No need to guess how many words in it is.

burritofanatic 8y ago

Editing is where the dangerous stuff happens. I was editing a traditional document on a processor called Scrivener, and my worst fear is an errant change unknown to me after saving the file. Going strictly on something like vim might be too hardcore, but if I started out with something like Scrivener, then port to .txt and commit my edits, and bring it back out to Scrivener for compiling, it may make sense. I haven't looked into too many of my options, but if anyone else doing a decent amount of writing can share their tips, please do!

titanomachy 8y ago
Sounds like you should version control your files...

ryanmcbride 8y ago

Vim is great, but I'm very glad that I learned it early in my life as an engineer. The learning curve slowed me down at a time where it was understandable if I was slow at doing something. I feel like I would have had a much harder time if I had tried to learn it after I was already completely comfortable with another editor. That doesn't stop me from recommending it to everyone.

daveFNbuck 8y ago

When writing a large document, I prefer to use a file format that has a way to import the contents of other files. When writing a long document in LaTeX, I would have separate files for different sections, plus a main file that had the overall layout and imported each section in the right place. This approach allows you to easily insert/remove/rearrange sections and doesn't require having a giant file open in your editor. It also makes viewing the compiled version easier, as you don't have to compile the entire document to see what the part you're working on looks like.

NegativeLatency 8y ago
One of my favorite things about vim is being able to open very large files. (Larger than my available RAM)
nickjj 8y ago
But then we're back to the same problem in the article where you have 150+ numbered / referenced files.
- daveFNbuck 8y ago
  They're not numbered. Referencing doesn't have the problems the article complains about. Also, you can go between these extremes and have a handful of medium-sized files.
  - nickjj 8y ago
    The numbers are very important because the reference has to happen outside of the editing tool / structure. I need to be able to identify that lesson 'xyz' is lesson 50 so I can say to check out the code in folder 50 inside of a git repo.
    - daveFNbuck 8y ago
      When you compile the document, the numbering is automatically added just like it would be if you had a single large document. The importing gives you the same final result as having a single file, but gives you the flexibility to put individual lessons in separate files for easier editing and reuse in other course plans. This also makes it easier to do things like print out individual lessons if you need a hard copy but don't want the entire document.

koonsolo 8y ago

Am I missing something obvious here? I'm a heavy VIM user myself, but for documents, I use a word processor. Why mess with filenames and sequence numbers, when any basic word processor handles this for you?

ahmedalsudani 8y ago
A couple of reasons: 1. Version control 2. Simple text files that are easy to maintain and convert into different formats There are other reasons I can think of but those are the biggest two. Personally, I hate using word processors and would love to never have to use one again. Their GUIs and learning this and that shortcut key (which usually don't transfer to other apps) used to be tolerable but I can't stand them now.
- koonsolo 8y ago
  1. Most word processors have revision control and multi-author options. They even allow comments etc. 2. You have all kinds of open formats such as MS Word, RTF, OpenOffice, that can basically export to anything you want. The only reason I do see is that you can use the tools that you already know, such as code version control and your code editor. But other than that, it seems strange to try to do this thing in plain text files. Because then you have all these problems that shouldn't be problems in the first place.

bor0 8y ago

I've written my first book entirely in Vim. Using Leanpub's support for Markdown+LaTeX was a very pleasant experience.

deleted 8y ago

[deleted]

12dellydell 8y ago

My take-away isn't 'switch to Vim' rather just how rewarding it is to master a smaller set of powerful tools.

konart 8y ago

Today was the 3rd time I've tried to come into VIM. I've stopped as soon as YouCompleteMe came into play. Instead of just git clone you have to do this and that just to have a damn autocomplete... And after time wasted - vim segfaulted on me. Sorry, but I really can't see how this can be better than, say, IDEA. Installed it once, git pushed my settings - and never had any problems with it. Shortcuts are almost 100% universal these days.

jacoblambda 8y ago
While it is fair that some of the plugins are problematic, in general the plugin space is fairly easy to traverse. Most plugins take at most 2 steps to install (add to .vimrc, run update command) when using a plugin manager. Those that have external dependencies that take extra work are often packaged for distros. I know YouCompleteMe has an emerge package that bypasses all the setup hassle.
- konart 8y ago
  I was using pathogen and it's true that some plugins are just git clone away. But's it doesn't matter when you have to spent all evening to figure out something that simple and in the end it sill doesn't work. >often packaged for distros... I don't really care at this point. Vim is dead for me. And tbh most things that people describe here in the comments seem more like a form of autosuggestion. Losing context? What? All modern editors have command menu with everything you need. Fuzzy search, any command that the editor or and IDE can offer, including those provided by plugins installed. And you don't have to worry about pluging updates - it's automatic. All you have to do is to read a changelog if you are interested.
- konart 8y ago
  As a final attempt I've just installed SpaceVim. A distro. Full of features and whatnot. lang#go layer enabled - check. I go to the first .go file I can remember of and... autocomplete works. But only for the packages provided by the go iteself. Not the 3rd party. Kind of... what the point really? As a final word: I'm trully happy for people who have found their happiness in Vim. Nothing can be better that having a tool that satisfies your needs to the fullest. But I still can see it as a capable DE. Navigation is great and I use it in Firefox everyday via Tridactyl. All those hacky '3ytcvnsdg' whatever commands are super nice when you are working with some kind of csv dump of an oracle database via ssh (I had this moment!). Editing some configs on my Raspbery Pi? Sure. Writting books and such? Maybe, never had such experience. But software development? Seems like a nightmare to me.

TeddyDD 8y ago

I used to think Vim and company are only worth it when you work with structured text (like programming languages) most of the time. I'm not so sure nowadays. I had to work on big prose document in Libre Office. I hated every second of it. It might be because I used to modal editing. It felt like typing with one finger when you are used to touch typing... I got question. It here anyone who learned Vim editing model and decided it's worse than „traditional” Cua, mouse oriented editors[1]? I can't remember seeing any blog posts like „I used Vim for X years but I switched to Cua editor”. [1]: well, I switched to Kakoune from Spacemacs but that's another modal editor (not Vi clone tho) so it doesn't count ;)

d33 8y ago
What exactly were you missing? Could it be that you're just not used to the shortcuts that let you navigate with the cursor, remove previous word etc.?
- TeddyDD 8y ago
  That was an issue, yes. I know basic shortcuts ({ctrl, shift} + arrows, ctrl+backspace) but I assume someone used to Cua editor would know more tricks. I missed actions like: - select to given character - select to begging/end of the line/whole line - select sentence/paragraph/text with the same indentation I know some of those actions are available with multiple mouse clicks (3 clicks to select paragraph If I recall correctly) but that means you have to use mouse. Beside this ctrl+f search is not as good as / in Vim. It has no regex support for example (you can open dialog that has option to enable regex but that's more than one shortcut away). Actions in Cua editor cannot be composed and reused, that's also an issue for me.

sergioro 8y ago

If I were to write an article on how increase productive with Vim I wouldn't focus on its plugins (after all many other editors/IDEs have great plugins). The power of Vim relies in its multi-modal editing. It requires time to get used to it but... once you're comfortable switching between modes it quickly pays off in productivity. I think the text editor is the most important tool of a developer and Vim outperforms any non-modal editor. My thoughts on Vim are summarized in this quote by Abraham Lincoln: "Give me six hours to chop down a tree and I will spend the first four sharpening the ax."

anthony_doan 8y ago

I use Tmux + Vim. It's pretty nice. The investment time is big but it's a one time investment with minimum upkeep. I don't use any plugin other than language plugin.