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.
> It is a similar pitfall that developers step into when they optimize their code before profiling where the bottlenecks are at.
Author here. For reference I've made 5 courses over the last 4 years and have written over a million words. I also have 200+ blog posts and have hundreds of thousands of lines of code written across a bunch of projects.
In other words, I hope I know what my bottlenecks are with my environment. It's not specifically editing text, but it is managing a shit load of words across many hundreds of files and also switching between projects.
With no real prior Vim knowledge (I looked at it once many years ago) it took a solid weekend, and when I say solid, I mean I spent 10 hours both days researching Vim features, watching tutorials, following along with tutorials and slowly introducing a couple of plugins I knew I wanted (based on exact problems I had).
That got me to the point where I had the environment mostly working with a decent enough config file. Then I spent days floundering around like an idiot while I hardcore failed to even do simple things like "move to the 2nd to last word in a sentence and then wrap the last 2 words to a new line". Doing that without arrow keys and no mouse almost killed me initially.
After about a week of immersing myself I got to the point where I didn't feel like I was completely destroyed by a foreign environment. During this week I wrote about 10,000 words and worked on a couple of freelance programming gigs.
In my opinion, it was worth the 20 hours of set up + 20ish hours of not being as productive to set me up for the next 5+ years.
Plus as you mentioned, a side effect is it happens to be a fun too. That's a win win!
You may enjoy Vimwiki, which will offer you some of the benefits you already have with markdown, but also offer structure in the form of hypertext links, when needed.
> In other words, I hope I know what my bottlenecks are with my environment. It's not specifically editing text, but it is managing a shit load of words across many hundreds of files and also switching between projects.
I think another way to look at it is that humans are terrible at perceiving reality over time. Our understanding of what problems are most pressing are often only accurate to criteria that we aren't aware of judging. Ie, psychological biases built around your world view can have material impact on what you perceive as the most pressing problems - especially when trying to boil down thousands of hours of data points.
That's not to dismiss your findings - it's simply to say I distrust human perception, benchmarks are needed. Hah :)
Nick I started doing the same thing a year ago and I was very nervous about getting too abstract with all the tooling and code and writing. It's challenging—and I definitely take breaks to really feel the difference—but it is so, so worth it.
I do it more with emacs and self-made CLIs, but I think the person choosing the path is the right way. It melds it perfectly to your tasks and mind.
Not the poster above but emacs' evil mode has really good vim emulation but the yak shaving rabbit hole goes much deeper. Emacs isn't stellar when it comes to large files and long lines although that's mainly for code and not plain text.
> It is a similar pitfall that developers step into when they optimize their code before profiling where the bottlenecks are at.
I heard this many times and believed it, but after some time I think this is bad advice.
Here's mine:
There are two kinds of performance optimizations: free optimizations and optimizations with a cost.
The free ones are things that don't really take any extra complexity to implement, just a little thought. Using a hashed data structure instead of an array when you'll be accessing items randomly by id. Breaking early from a loop.
If you never think about these things unless you're explicitly on a profiling task, your code base will be full of "easy wins" that you have to go back and find and fix. Which will be time consuming and error prone if you do it after all your code is written.
The other group of performance fixes is ones with a complexity cost: adding a cache layer, rewriting an algorithm in a slightly more confusing way, etc.
My advice is: always pause when you are designing a new feature and think about whether there are "free" performance wins. You can implement them now with no cost, and you should. It often helps with your data design anyway, getting code that more closely matches the actual processing domain.
It doesn't have to take more than a minute. Anything bigger than that, yes: punt it til after you have profiled.
I like optimizations that also free up cognitive load. So that even if you can't "justify" the time savings from spending a couple days optimizing something, it might pay bigger dividends in not having to think about item again.
I guess it's just semantics, but if you can think of two ways you could do something and both are about the same in terms of time-to-implement, readability, complexity, etc., but one is probably faster... then I wouldn't call it an optimization. That's just writing good code in the first place.
It is, but people still use the "premature optimization" adage as an excuse to avoid thinking about performance at all.
As GP is saying, at any given complexity and readability level, you can write the code in a more and less performant way. Writing more efficient code takes just a) willingness to consider performance, and b) willingness to actually learn your toolset as you use it.
You're not wrong, but I don't think anyone is saying you shouldn't use appropriate data structures.
To me the advice means don't belabor the choice of data structure of its not obvious to you.
If you're writing a quad nested for loop to solve a problem, don't get distracted trying to refractor all the work leading up to that wart... Just get it down first.
Get a passing test first then optimize later if the code is a bottleneck.
> Get a passing test first then optimize later if the code is a bottleneck.
In that case, totally get that test passing and then maybe add few more tests around that solution - so that when I come to the project half a year later, and see the application consing like crazy because you used lists instead of arrays, and this now powers half of the business logic, I can tear this up and fix the data structure with confidence I won't break things badly.
As one who codes in Vim, there is a huge time savings from living in a tool that closely maps your mind. Every cognitive load you can extract from the process of getting your vision down onto paper builds a compound interest in keeping your flow and momentum going while you work. If you're searching for menu options, or browsing a file directory, or doing the hundreds of other things it takes to otherwise navigate a computer file system, you can easily lose track of what you're trying to write in the first place. Call it saving time, or call it building productive power, but either way, it adds up fast.
Not to mention the aesthetic pleasure of making your tools a joy to use.
Nicely said. Master craftsmen spend much time and money acquiring high quality tools to use while they work. Most make many custom tools themselves. Having great working tools that become extensions of your body (and the body can be looked at as just a very tightly integrated tool for your mind) is key to long, highly productive sessions of creativity. Computer programmers also search for the same type of tools.
Imagine changing jobs. At your new job, you'll be able to go faster because you have a well optimized workflow.
It doesn't matter to your new bosses that you previously spent an ungodly amount of time optimizing your workflow and learning advanced tools, the only thing they're seeing is a productive employee.
He's frontloading his time and attention, using time that isn't going to produce productive writing, and investing it so that his productive time doesn't deal with any of this crap.
Exactly right. When you're saving time is absolutely critical, particularly for something like writing. Even tiny automations that save what appear to be small amounts of time can lead to large increases in productivity by not distracting you.
You can definitely go too far with something like this. But although he might not get his time back on this project, he'll probably be writing more books and course materials, and he'll be moving faster on them because of the setup work he did for his current project.
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...
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.
I think this ignores that certain types of optimizations can have benefits that are small but almost constant. A more fluid environment for your task can result in less jarring stops that take you out of the task at hand, and keep you in a highly focused state. Maximizing the time in this state, where you might actually be some multiple more productive, is a vast improvement over just saving a little time.
> But of course you should still do all of this, because it is a lot of fun and Vim rocks.
Heh, probably. You should also compile your own kernel once (maybe even go for a LFS setup), configure FVWM with bells and whistles and probably a few other things I'm forgetting now :)
You’ll be surprised how much those small automations and time savings pile up. And also if it keeps you in the flow it can make a quantitive difference truly qualitive. I always like to fallback on the “is it worth my time xkcd” https://xkcd.com/1205/
Yes, not only do they pile up, but there's another interesting win which isn't measurable in time.
It's being happy. It's knowing you're using tools that let you get things done in a way that works best for you.
Something like this has infinite value because it's the difference between waking up and dreading doing something because of the upcoming million paper cuts VS waking up really excited to do your task. That's the difference between writing nothing one day vs writing 5,000 top quality words.
This. I really feel optimization across this dimension perhaps the most. I just enjoy things much more. Maybe if you really want to quantify it you could think of the happiness factor as a multiplier.
So you have a task that takes X time. What's say optimizing it is a net loss time-wise because it doesn't in aggregate save you more than you spent to perform the optimization. Say after optimization it only costs 0.8X time but it took 0.2X time to do the optimization so all benefit cancels out. But the difference being now happiness is 1.5 multiplier so you feel 50% better and the same aggregate amount of time is spent but it's much more enjoyable and therefore more valuable to you.
Maybe I'm not explaining it well, but I totally feel this way about plenty of stuff.
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.
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.
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?
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.
> 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.
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)
I can't reply directly to SketchySeaBeast but you're right, there are probably alternatives. Emacs shortcuts are widely used on terminal emulators iirc. Vim is just one option for a portable, efficient way to edit text.
> And if you just want to get work done without concentrating on learning a new skill
Maybe this is a mindset issue, but I'm having a hard time imagining how one would want to just get the work done, without trying to pick up a skill in the process.
Despite the current UX trends of dumbing down software, it's rare you'll use a tool just once in your lifetime.
Ah I see your point. What I was trying to say is that learning Vim is a separate commitment. If you are not prepared to make that commitment, Vim will slow you down instead of speeding you up.
That's true. And if you really believe you won't be needing vim - or won't be solving the class of problems vim is good for - very often, it may not be worth it to explicitly sit down and learn it. The calculus is correct, but the actual values that go into the equation matter a lot.
My wife has used SublimeText and Notepad++ for total of maybe 10 hours in her entire life. I'm not suggesting her to learn Vim (or Emacs), because the kinds of tasks she does with computers don't benefit that much from a proper text editor. However, most developers spent inordinate amount of time editing plain text files, and a lot of tasks they do in other tools - like task management, time tracking, documentation writing, drawing diagrams, commenting on StackOverflow - could receive stupidly huge efficiency improvements by being done in plain text too. Vim and Emacs are the two tools that are dedicated for precisely this class of problems. In my opinion, the couple dozen hours one has to invest over the course of a month to get some basic proficiency in them is worth the across-the-board payoff in work speed and comfort.
--
One trick I've learned is being explicit and deliberate about learning. To things like learning a new piece of software, recursive Pareto rule applies - 20% of time gives you 80% of value. 4% of time gives you 64% of value. So, say you're willing to entertain the thought of learning a little bit of Vim. Allocate a single pomodoro to it right now, and fire up vimtutor. 25 minutes, full focus. You'll notice it only takes a few minutes to break through your own habits and learn the basics of a new interface. You'll be impressed by how much you've learned in just 25 minutes[0]. Next step: commit to 5 hours over a week. 10 pomodoros. Find some introductory tutorials, and work through them this way.
Personally, I did above trick a couple of times to learn new Emacs features. Getting comfortable with multiple cursors, or with paredit, are things that turned out to take 1 or 2 pomodoros, and have been improving my editing speed and comfort for the past couple years.
--
WRT. mindset, a proper one can smooth out the learning curve quite well. The most basic trick that I see even developers not recognizing is this: every time you click on a button in your program, figure out if there's a keyboard shortcut for it. If there is, try to use it instead. Soon, you'll find yourself working much faster and comfortable than before.
--
[0] - though you'll lose half of it in a day. Committing new skills to long-term memory takes more time and exposure; muscle memory takes even more. Good news is, this happens pretty much by itself, as you apply the new skills to the tasks you're doing.
There is bad trend going on in the Industry for a while now. It's basically that people want things designed to be good for newbies and no body else. This makes tools easy to pick up, but it makes it very hard to solve complicated tasks with it.
Most people don't want to put in anything more than 40 hour work week these days. Which also means no time to learn and upgrade your skill set. That is for doing their everyday tasks.
Now selling vim or emacs to this set of people would never work for one reason. They just can't get themselves to spend that time.
That's also a big reason why people hate Nerds. These people spend to get better at things in a way we don't want to.
And truthfully, the productivity wins for me weren't so much tied into being able to input text at a faster rate with Vim.
It was being able to leverage Vim itself to help me rethink and reshape how I organize large amounts of structured text, which saves a lot of time and headaches when dealing with files. Plus there's other wins too with limelight and video editing (an added bonus).
I'm still not 100% as fast as I was with VSCode for inputting and editing text but after 2 weeks of using Vim, it's not a complete train wreck anymore. It was brutal for days, but it's slowly getting better.
Ah OK. Haven't had that myself, even using USB audio interfaces in a similar fashion, so I wouldn't put that down to Linux. I use monitor speakers and have good hearing and definitely not getting those issues with a simple pulseaudio setup. I flick between youtube, cmus, recording on my old Zoom H2, audio from a VM etc. so have run the gamut of opportunities for it to pop and click.
Sounds like you had to spend a lot of time troubleshooting and in the end thought it wasn't worth the fight. I hear you, but I would see if I could borrow another audio interface from a store or contact of yours before giving up on OS-freedom for good. The Scarlett is an entry-level device anyway, known to have dubious build quality. I'd also take it up with the manufacturer before looking for more fixes.
Yeah it seems isolated to some type of combo of hardware I have.
After I finish this next course I will try again with a different distro, and then see if my other USB mic that worked on the Chromebook (running native Linux) also works on my main machine.
It is an editor that is hard to learn and master. There are other options you could have some / most of the mentioned benefits with much lower investment. Not everyone has the energy / willpower / time to learn vim.
Vim isn't that hard to learn. I think the idea that someone doesn't have the willpower to learn vim is unlikely to the point of being ludicrous. It took me about two weeks of using vim with a printout until I could use it without thinking or having to reference it.
Vim is not hard to learn, a few hours give you the basic.
Vim is hard to master. 3 years ago I started to use Spacemacs with evil (so vim) and I keep learning new vim tricks.
Isn't that the whole beauty of it? You're learning what you've already learned on top without having to re-learn everything again. That's primarily why I've stuck with it. That and the fact that it's easily programmable even though VimL leaves you wanting more.
Have you ever tried to set up a colorscheme for vim? Add plugins, set keybindings? Imagine a non-engineer trying to do any of these things. Even as an engineer it's taken me years of iteration to get vim to a place where I'm as fast as I am, and I still get frustrated setting up a new computer (and I've gone through the trouble of hosting my dotfiles on GitHub!)
It can be tricky, but doesn't depend on the user being an engineer. It mainly requires the right mindset.
Some people find even an iPhone too complicated, others don't mind reading the manual for a minute. For some users Vim just makes sense, while certain people will struggle with saving files in Notepad because they think a specific button is at the wrong place and refuse to learn it any other way than they imagined.
> I still get frustrated setting up a new computer
Why is that? Setting up Vim is the easiest task for me, it's literally just a matter of copying some files.
> It can be tricky, but doesn't depend on the user being an engineer. It mainly requires the right mindset.
A mindset that is suspiciously similar to an engineer's. :P For example, you need the user to memorize the fact that all the configs are in a ".vimrc" file in their home directory. Oh and since it's a dotfile they might not see it immediately. And then if they want to add custom shortcuts they need to learn exactly how the syntax works, the different "modes", the types of remaps, etc. It's a horrible experience for a non-engineer.
> Why is that? Setting up Vim is the easiest task for me, it's literally just a matter of copying some files.
I have a lot of plugins (e.g. syntax highlighting, linting, and autocomplete for different languages), and each of those can have their own dependencies that they require you to install before they'll work.
I tend to use the example of a car in these topics, but I have a better one: a coffee maker. There are numerous non-obvious things one has to learn about coffee makers - like how to apply a water filter, and what kind to buy. Like the symbols that mean "not enough water", "not enough coffee", "dredge drawer full", and what to do when they show up. Somehow, I never see anyone complaining about this - because there's a social expectation that people can and should figure this out. The coffee machine comes with a small booklet explaining all of this in pictures and a dozen languages.
Yet somehow, with software people think that the UI should just have a button labeled "get my job done", pressing which will get their job done. It's a really broken mindset, because it's impossible (or rather, it's an AI-complete problem) to have software like that.
The coffee maker does indeed come with a booklet that explains what various messages mean, and what actions need to be taken to address these issues. Those steps are maybe two sentences long and generally self evident even without the booklet.
People complain about that, because they think things should be handled and explained within the machine itself. I don't complain about coffee machines, but I agree with the principle. If I have to go searching through manuals to figure out what actions I need to take to get something working, that piece of software has failed at user interface design.
Sometimes it's ok to fail at UI. I don't expect everything handed to me on a silver platter when I'm writing a bootloader for an 8051, but I do expect my tools to be reasonably user friendly. Vim isn't user friendly, and that understandably drives people away. Hell, even emacs can be a pain to work with.
A HUGE problem with developers learning VIM is that they think they have to go from 0 - 100 immediately when you can adopt VIM gradually and still see noticeable efficiency increases.
> A HUGE problem with developers learning VIM is that they think they have to go from 0 - 100 immediately when you can adopt VIM gradually and still see noticeable efficiency increases.
That iterative process is exactly what I'm talking about. It's taken years to develop my vimrc, because starting with a "prebuilt vimrc" means that you don't really understand what is pure vim, what's custom, and what issues you might run into because of those custom settings conflicting with new plugins.
The first time, each of those things probably took me like ten seconds. Cloned into folders specified in readmes. Keybindings are even simpler.
Obviously there can be snags on the road and things get more difficult the more complicated things you want to do, but learning the basic keybindings and being able to efficiently edit files with vim just isn't that hard.
Non-engineer: "What is .vimrc?" And no, for example solarized takes quite a bit of googling to learn exactly which files to copy from GitHub (red flag: non-engineer has to go to GitHub and download a raw file), and then fiddle with the color settings depending on which terminal you're using.
It's funny you mention printouts. They've been critical for my learning process too. I have a standing desk and as of right now I have 6x sticky notes worth of shortcuts hanging down below my monitor.
I say that vim is easy to learn if you approach it from the idea that it’s a vocabulary to edit text and not a bunch of arcane invocations. Instead of learning di” as a invocation to delete text inside the current or next pair of double quotes on the line you learn it as a verb and target... d deletes i sets the scope inside something and “ is the target. Then the next time you want to delete inside something all you need to do is change the target up to say single quote or paragraph. or you substitute the inner with a mark or a line number or a regex.
Yeah once I got to thinking about it being almost like a piano, where you're playing notes or melodies to do something it suddenly all started to click.
But still, I have a lot jotted down. Mainly the hotkeys, but also things just to remind myself that a feature exists (like * to highlight the current word).
I don't have the willpower to learn vim. Everytime I even look at it I think... no. And reach for nano instead and just be inefficient and happy. We're out there.
Hmmm. I'm not sure I agree with this. That's like saying that people use a screw driver to screw in a nail because it's a much lower investment and not everyone has the energy to use a drill.
The premise of the article is that the VIM is better enough than alternatives that it's worth the learning curve. Just like a drill is better enough than a screwdriver to learn ho to use it. If you want to contest that, that's a different discussion.
If your argument is, "some people don't have the energy to use the best tool for the job"... idk how to respond to that.
Doesn't the screw driver/drill analogy work here too? Drills cost a lot more money than screw drivers or hammers, require that you be working with screws rather than nails, and don't work unless you have electricity. Hence, they're not a worthwhile investment for everyone.
If you go far enough, you can cause the analogy to break down, but that's true of any analogy. This breaks down because the ROI for a drill is too short to compare with Vim.
The headline to this story is "Vim is saving me hours of work..." which is a lot like "Find out how to lose 10lbs in one week" or "You too can earn thousands of dollars a week with this easy trick".
And trends go around in IT just like any other field. So before someone jumps into vim to save themselves hours of work they should know that it requires practice use to use well.
How would you rewrite the headline based on the article's contents? Keep in mind it has to be 60 or less characters too.
I wouldn't say I am learning Vim due to it being a trend. I'm learning and using it based on problems I discovered using other editors to write books and courses.
Even without being a dedicated Vim user, I think using it for git commits can be beneficial.
You can use it to visually warn you that your git commit is going past a certain amount of characters. Basically it can help you create better git commit messages.
But if you hate it and are on a Unix-like environment you can export EDITOR="nano" in your profile and now git should use nano instead. I think there's a git specific setting you can set too if you don't want to do it system wide.
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.
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.
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.
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.
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).
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.
I generally agree as somebody still fairly new to development. I'm about 6 years into focusing in computer science, and early into the process I heard about vim and emacs. I knew that it wouldn't be necessary to use either while going through undergrad, but I decided to learn enough vim to be functional just because I wanted to understand.
Vim still isn't my exclusive dev editor, but it has almost become my exclusive terminal editor. Learning older technologies may not always be top priority, but it can do a large amount to enrich your personal perspective- particularly if you discover the niche where its usefulness is best utilized (and like you mentioned, if the amount of time to get up to speed will save you proportionate future time).
When I started using Unix (36 years ago) I could open a file in ed, make a small change in the file, and save it back to disk, faster than it took vi to startup.
Eight Megs? On the machine I was using 36 years ago, each process had a limit of 64 KB for code + 64 KB for data. It was 8086 based and that was called the small-memory model. Later versions of the OS added support for the medium-memory model which could support 192 KB of code + 64 KB of data.
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.
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.
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/). Totally optional but it really helped click in the j and k movements.
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.
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).
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.
OP here. What I'm noticing is that Vim kind of helps you not have to switch contexts.
For example, let's say you want to put the cursor next to a specific word in a sentence.
If you use the mouse, now you need to stop writing, goto the mouse, find your mouse pointer, look at the mouse pointer, then move the mouse to the word you want to be at, click the mouse and start typing again.
I'm an avid gamer. I'm super used to this. I can move my mouse at pixel precision and do it very quickly, but even if it's fast, it's still a context switch.
With Vim, it almost feels like Vim itself is another input device that's almost a mind control device. I can just direct my eyes to the word I want to move to, hit 3 keys and then have my cursor jump directly to it (by using vim-sneak and pressing any 2 characters of the word).
Even if doing this is only equal speed to the mouse, it's still a win in my book because it feels less of a context switch. Plus if you want to talk about mistakes, looking at the word you want to jump to instead of your mouse cursor forces you to look at the word, so you have 1 more chance of avoiding a spelling mistake -- although to be fair, most editors including Vim can visually show you these errors.
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.
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.
I have trouble making work together "one of the best of the team" and "one of the most exhausted". It seems weird to me that the "best" persons use a tool that so obviously drag them down (don't they realize they are more exhausted, slower and make more mistakes at the end of the day?)
I believe that there may be some post hoc, ergo propter hoc at play here.
For instance did you include the age of the persons in your observations? It wouldn't be surprising that the persons choosing vim are a bit older on average, and then one could think that they have a bit less stamina and are exhaust faster?
Or maybe they are actually doing more, like spending part of their energy helping others? That's also a pattern you can see often in group training sessions.
Also, you mentioned that you won't help them with the "weird issues" they usually have with vim. Do you apply the same treatment to non-vim users?
The dreaded "show me your sources" question. Of course this can lead to non-specialists trading flawed studies based on skimming the abstract which adds marginal value.
That being said one person's anecdote supporting a highly subjective opinion deserves to be torn to shreds without ample evidence or at least better context.
> vim forces you to do a lot of stuff that the machine could do for you.
I don't think that makes any sense at all. If anything Vim does a lot for me because it's programmable. When doing heavy editing, the whole point is the automation does the heavy lifting.
Switching modes doesn't have any cognitive load effects that I can notice. The cursor changes the shape for example, so you instantly know what to do. It's pretty much second nature.
What you're describing is a novice or clumsy Vim user. I don't know what "compatibility problems" should have a text editor, but I haven't had any in many years.
> So, yes. Vim may be fun. [...] But I don't buy the productivity boost.
Kind of condescending, really. Thinking that Vim is a toy and all users are using it for the heck of it, when they could be more productive otherwise.
Unless you're keeping a written log of who is using what editor and comparing it to some kind of objective metric, this is almost definitely a case of confirmation bias. There's no way that literally every person using vim is having these kinds of problems.
Even if the correlation is real, there's just no way that difference between using vim and using something else is so great that it's causing people to exhaust themselves, so best case scenario there's some hidden variable causing it.
vi is a set of controls -- NOT a specific editor. Emacs, vi, vim, neovim, <misc_vi_clone>, sublime, intelliJ, kate, VS Code, etc all have vi controls.
Give me VS Code with the Vim plugin and I'll code circles around someone using the standard controls simply because it takes so little effort to do most complex things and if a mouse actually makes things faster, I can use that too.
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.
The built-in tutorial in Emacs can be opened by pressing CTRL+h, and then t ("C-h t" in Emacs notation), or by pressing Alt+x writing help-with-tutorial <ret> ("M-x help-with-tutorial" in Emacs notation).
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.
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.
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.
I switched to Dvorak originally because I wanted to learn how to touchtype and using Dvorak meant that I couldn't cheat by looking at the keyboard. We're now almost 15 years later and I don't regret my choice, I don't know if typing in Dvorak is really faster than QWERTY but it definitely feels very comfortable. That's a very significant functional difference, most of the typing in Dvorak occurs around the home row. When you type for hours every day it's well worth the switch IMO. Get a good ergonomic keyboard while you're at it.
That being said if I anybody reading this is tempted to switch away from QWERTY towards a more ergonomic layout I'd suggest looking into Colemak, it's supposed to be at least as ergonomic as Dvorak while being closer to the standard QWERTY layout.
I also endorse the switch to Dvorak -- I find it more comfortable (less finger movement feels calmer). I can also switch between keyboard layouts within a few conscious keystrokes, after that the 'muscle memory' takes over.
I suspect Colemak is better, but it's a much smaller gain going from Dvorak to Colemak than from Qwerty to Dvorak, so I'll stick to what I have. Otherwise I suspect Colemak is better than Dvorak when switching from QWERTY.
>I suspect Colemak is better, but it's a much smaller gain going from Dvorak to Colemak than from Qwerty to Dvorak, so I'll stick to what I have.
Yeah I'm in the same boat, that's why I was mainly aiming my comment at people using QWERTY and looking to switch to a better layout. Even the Colemak people acknowledge that:
> The Colemak keyboard layout fixes all the issues mentioned above, and wins in virtually every criterion, but the difference will be less noticeable than the difference between QWERTY and Dvorak. The switch won't be as easy for veteran Dvorak users. If you're generally happy with Dvorak, you should probably stick with it.
As someone that can type QWERTY and Colemak pretty equally well, I’m not convinced in my experience that alternative keyboard layouts are significantly more comfortable than QWERTY (speed aside). Comfort greatly is noticeable if you’re transcripting at high speeds frequently (typing tests) but is otherwise questionable.
Layout switchers have some bias here because they don’t type as well in QWERTY anymore or they didn’t touch type QWERTY.
> Comfort greatly is noticeable if you’re transcripting at high speeds frequently (typing tests) but is otherwise questionable.
When I'm writing something that doesn't require a lot of cognitive overhead (typically chatting online, when I may have a lot to say but it's not particularly intellectually demanding and doesn't require a lot of precision or proofreading) I can reach pretty high WPMs.
I'm not convinced that typing speed is always brain-bound outside of typing tests. If I'm telling you about my day at work I'm pretty sure I can just "stream-of-consciousness" directly through the keyboard with very little overhead, especially if I do it in my native French.
I agree with you (though perhaps speed increases become less important after a certain threshold).
I was trying to talk about comfort difference between keyboard layouts anyhow, not the speed difference.
Given the same proficiency level of QWERTY and Dvorak/Colemak, comfort difference would be more noticeable for high intensity / little breaks / long duration activity like typing tests.
Are alternative keyboard layouts significantly more comfortable for practical tasks? I’m skeptical. (Most enthusiasts already agree they aren’t really faster).
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.
As a Dvorak and Vim (Spacemacs, really) user, I don't get this argument.
It's not about speed. Sure, some people say it's about speed, on either side of the debate, but I'm not a faster typist, nor a faster editor, nor would it matter in my profession (coding.)
It's about ease of use.
Once you're used to them, these tools save you (cognitive) overhead. Dvorak doesn't tire out my wrists (subjective, but I switched away from Qwerty&Emacs after developing RSI when writing larger technical documentation. Never had the same problem with Vim&Dvorak, even when writing frantically day and night on my thesis.) And Vim allows me to navigate text easily. It's not about speed. It's about intuitively navigating to something quickly, without having to think about it, and to stop and completely upend my current focus because I have to hunt & peck for something with my mouse.
> Never had the same problem with Vim&Dvorak, even when writing frantically day and night on my thesis
Most of the graduate students I've knew spent a lot of time working alone, and had at some point to type a lot of things already clear in their head meaning ease and speed of typing was a very important factor, keyboard sharing not so much.
And then I've observed the same things as you, it's really annoying working at the desktop of my colleagues using non standards keyboards.
So, really, it's all dependent on context, and as usual there's a right tool for a given job. Kudos to both of you for coming to correct conclusions in your given environments :-)
I originally started learning dvorak because I was getting cramps in my hands from typing. Learning dvorak solved that. I run dvorak at home and qwerty at work, and I think switching between them helps out my hands and fingers even more. The only downside is when I first start to type something I sometimes type gibberish until I realize I'm on a different layout. For example, I originally type "G " instead of "I " when I started typing this. As far as I can tell I'm equally fast in either layout. If a friend comes over and needs to use the computer I can click on an icon in the taskbar and they are good to go.
I decided to stay with qwerty at work because I want a colleague to be able to work on my system, and switching keyboard layouts multiple times per day only causes me to type gibberish more often. And as you say, there is value in standardization.
If you switch machines so often you can't keep up with moving your customizations between them, by all means, learn just the defaults (but do learn them - e.g. whatever the "standard" editor IDE, learn the keyboard shortcuts). As for pair programming, switching keyboard layouts and opening a project in a different editor/IDE takes only a small fraction of the time your colleague will spend in front of your machine.
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.
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.
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!
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.
Seconded. It's fair to say that almost any imaginable task involving mainly text - including many UIs - could be done better in Emacs.
For instance, for my freelancing I track both tasks and time spent in Org Mode. I wrote myself a little bit of Elisp that, when invoked with the name of a customer, turns my Org Mode agenda into a table with line items for an invoice. I've been copying that into my invoice LaTeX template for a while, but recently I've been working on finishing the Elisp code: the end goal is to have a three-step process:
1) Press a key to generate a table with invoice line items and another with all other data that goes into the invoice.
2) Review the table, adjusting as necessary (e.g. rounding off stray minutes).
3) Press a key for Emacs to take these tables, fill a LaTeX template according to their contents, generate an invoice and file it in appropriate location.
At this point I have 1) and 2) fully working, and 3) missing only the "fill template" and "refile result" steps, which are rather trivial to add.
I'll release this publicly when I'm done. The current solution is somewhat specific to invoicing for services according to my country's regulations, but it shouldn't be too hard to make it universal (I'd love some help here, especially in form of examples of invoices for other countries).
Did I spend more time on it that I would if I used a web tool for invoices? Yes. Do I expect to ultimately get ahead on this solution? Maybe. Is it worth it? The interface (read: an org-mode document invoking some elisp) is already more fluid than any web tool I've ever seen, and I don't need to be on-line - so a huge YES!
That is a very nice example of playing to Emacs' strengths to solve a specific problem.
As a non-Emacs user I do something similar with a bit of Bash scripting. It doesn't go as far as generating a ready to send invoice, but it will sum up the hours worked and provide a $ amount as output so I know how much to invoice someone.
It parses a log.md file I keep for each client.
The file looks like this, and the first number after the # is the hours worked.
---
# 4 2019/01/28
- Made something cool
- Helped XYZ do ABC
# 1 2019/02/11
- Foobar
- Yada yada yada
# 8.5 2019/02/12
- Lots of good stuff!
---
From here it's just a couple of piped Unix commands to generate the output I'm interested in.
You got me to thinking though. I wonder if I can generate a 100% ready to go PDF invoice. That would save a lot of tedious and error prone steps where I manually create each invoice based off a template in Google docs.
Thanks for providing an example! I wonder how many custom solutions there are :).
> I wonder if I can generate a 100% ready to go PDF invoice. That would save a lot of tedious and error prone steps where I manually create each invoice based off a template in Google docs.
This is my goal too. In parallel comment, I pasted an example table with line items. I wrote the code making that table some 9 months ago, and I've been retyping values into a LaTeX invoice ever since. I finally decided this is too annoying and error-prone to continue, and for the past couple weeks I've been slowly building up an end-to-end system, but with an explicit review step (I don't trust my own code that much).
As for time tracking format, the standard org-mode clocking feature appends a block under your TODO tasks that looks like this:
This block (called a "drawer") is automatically folded, so it doesn't clutter your org file as you work with it, but it's there in the plaintext. As I work, I mark a given TODO item as "active", either directly or via org-mode agenda, and when I'm done, I "clock out"; Emacs populates the :LOGBOOK: entries automatically.
Interesting use of orgmode as a database. How does it work? Does that use a built in agenda functionality or are you calling lower level org functions to query your agenda files and enumerating the results to generate the table as text in another buffer?
I use proper org-mode functions to query the built-in agenda and then group entries by org-mode tags. My code expects a configuration that maps tags to their line item names (as on invoice), hourly rates and applicable tax. I use this to output a dynamic[0] table like this:
The #+TBLFM: line at the bottom is org-mode spreadsheet functionality; it ensures I can modify the table text in-place, and just press C-c C-c to recalculate all values in it. I generate a similar table with data for invoices; some taken from my configuration, some computed (e.g. invoice number is generated by looking at filenames of previous invoices; sale date and service period are estimated from current date and the time range you specified when generating line items table, etc.).
The code for generating above table is hand-crafted. While org-mode provides you a generator for agenda tables based on TODO item name - see [1], I had to write similar feature that aggregated time by org-mode tags. I used [2] as a reference, but essentially wrote my own implementation. Surprisingly, it turned out to be almost trivial.
Then, it's simply a matter of turning those two org-mode tables into an elisp list of keys and values. This I accomplish using a simple elisp that uses built-in Emacs calls:
(defun trc-invoicing--named-table-to-lisp (name)
"Convert a named org mode table in the current buffer into a list.
The function finds a table named `NAME', passes it through `ORG-TABLE-TO-LISP',
and return the result. Refer to the documentation of `ORG-TABLE-TO-LISP'
for info about result's shape."
(save-excursion
(goto-char (point-min))
(search-forward (format "#+NAME: %s" name))
(forward-line)
(org-table-to-lisp)))
Then it's a matter of populating a LaTeX template with extracted values, invoking pdflatex, and copying the resulting PDF in an appropriate place. That last part I yet have to finish.
It's the biggest piece of elisp I wrote since Nyan Mode, but all in all, I find it surprisingly easy to code for Emacs. Availability of source code, extensive in-editor documentation and built-in source-level debugger make this process pretty pleasant.
--
[0] - Org Mode has a concept of "dynamic blocks". You type in #+BEGIN: blockname some params, and then using C-c C-c on it causes Org Mode to invoke an elisp function named org-dblock-write:blockname. The called function is then responsible for outputting contents of the dynamic block.
To be clear, the TBLFM there has a separate purpose. My implementation of [2] generates a table with appropriate shape and data items; TBLFM computes sums and products. This allows for manually modifying the table (e.g. adding a line item, rounding off hours, changing them to include tine you don't track in org mode) and having the sums and products recalculated.
(Also, for anyone scared by that TBLFM line noise, Emacs has a way to edit it in more readable form.)
I have seen comments like this so many times, yet I can't think of much things in which emacs can help. I have 10s of keyboard shortcut in vim, but all of the steps are just combination of keys or passing selection to unix command. I can do all of the things in most programmable editor. The thing you described(error analysis) can be done in any language and I would have done in vim and wrote a shell script. It doesn't require any extensibility from editor side. I know how extensible emacs is, but there are very very few examples that requires this.
Secondly the argument that lisp is better for text processing is not even relevant. You can install lisp compiler and use it with most editor if we are just passing the input into it.
I feel exactly the same.
Emacs is powerful, but basically everything it can do is also possible with Vim + Bash, and as both can be combined productively I saw no reason to use Emacs. In the end it doesn't matter if e.g. a document is compiled within Emacs or with a Vim shortcut that calls Pandoc in the background.
>>The thing you described(error analysis) can be done in any language and I would have done in vim and wrote a shell script.
Exactly. The difference between Emacs and Vim cultures is, in vim you use shell and programs(like sed, awk, perl etc) as a kind of assorted set of tools to build what you want. Emacs gives you all that in one nice integrated package. If I'm not wrong this was also originally a difference between Unix and Lisp cultures. In Lisp you had the operating system boot to a Lisp REPL. In unix you have it boot to a shell. Then one good thing about lisp is the list syntax helps you exchange code and data in a proper structure. Whereas in shell you have to understand the structure of what you are passing around(Text). Which is why after a while you just have to write a Perl script to get things done.
Error analysis is just one thing. Once you start building your utils, in Elisp, you just continue to use them together as a part of a larger workflow. In Unix you can do the same, but it will take you a lot of Perl and shell scripts.
>>I have 10s of keyboard shortcut in vim, but all of the steps are just combination of keys or passing selection to unix command.
Same in Emacs. When using vim you still have to commit a few things to Muscle memory, you have to learn movements, you have to learn modes. And then learn to use them with registers and macros. You do the same in Emacs.
>>I can do all of the things in most programmable editor.
Vim is a very nice editor. And I still use it a lot. But Emacs is a editor and beyond. I like to describe Emacs as an Editor and a very good programming system, which offers you way to program anything that comes in the domain of programmatically controlling a text buffer.
>>I know how extensible emacs is, but there are very very few examples that requires this.
I though the same way, but the use cases keep increasing once you start using it. It's really like saying spreadsheets are useless because you can iterate lists over a for loop and do what you like. Its only when you start using features like Pivot table, What-if, Vtables etc do you begin to see how powerful it can get. Some times it also requires changing the way you think about a tool to get it right. Once you start using it you begin to see all kinds of curious cases where it can be put to use.
I've even seen(in YouTube) cool uses of Elisp Macros and Clojure macros stitched together to make Emacs generate Clojure code. Then plugins like aggressive-indent-mode and paredit just make writing code a bit like uttering your thought at the speed it occurs. You can also use Elisp to make debugging easy, or generate templates of code or do various other things. These are just very basic things, the possibilities are endless.
>>Secondly the argument that lisp is better for text processing is not even relevant. You can install lisp compiler and use it with most editor if we are just passing the input into it.
So basically you are suggesting I re-invent emacs itself? Because that's what installing a Lisp compiler and building text manipulation APIs means. Why should I do it, when the community has spend more than 5 decades doing it for me.
> I've even seen(in YouTube) cool uses of Elisp Macros and Clojure macros stitched together to make Emacs generate Clojure code.
Try the reverse sometimes :). I recently needed to view some data our product generates while working over an SSH connection, so I hacked together a bit of Elisp and Common Lisp code, so that I can invoke a function in Common Lisp REPL that renders its input as an ASCII histogram in a new Emacs buffer, perfect for working in terminal mode :).
Most editors, even most of those with a programmable bent are not very malleable. I looked into improving indentation support for common lisp in other editors, and for editors not named "vim" or "emacs" the support was incredibly poor.
For most, indentation was 100% builtin, so the only way to change the indentation was to either modify the editor itself (i.e. not a plugin), or install a plugin that hooked into the return key. Usually this was only doable from C.
In addition, most of the elisp standard library is specifically for manipulating buffers of text; perl is the only language I've used that's could be argued to be better.
The same way the Web Browser seems to be the best runtime for multimedia documents and graphical UIs, Emacs is arguably the best runtime for code operating on text, and for text-based user interfaces (not just 1D CLI, but also 2D). So yes, you could do it in any programming language, but Emacs gives you a powerful environment tailored for text-based work, and geared for full interoperability. Where on the Web you can barely get two pieces of software to talk to each other (and that's only until Chrome security team removes the trick you've used), in Emacs the features you create compose almost seamlessly with other features, both built-in and written by other users.
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.
> Lisp will be around for a lot of time than these languages.
Are you sure about that? Lisp is old, and it has survived many old languages. But many of those were from the Computer Science/IT early teens age... Now CS/IT is quite mature.
Mainstream languages, especially Open Source ones, will probably outlive us both.
> But many of those were from the Computer Science/IT early teens age...
Nah, that's when the maturing process happened; what we have today is mostly middle-age crisis, running in circles with occasional small step forward.
Lisp will survive because it's essentially the fundamental core of programming. When you're writing Lisp, you're essentially writing an AST. The elegance, flexibility and powerfulness of this is exactly why every new runtime that shows up gets a Lisp made for it.
I often get stuck somewhere between a one-off keyboard macro and finding a pre-written full-blown mode but resist learning the techniques and functions needed to do this powerful in between workflow automation. Care to share a snippet?
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.
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.
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.
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.
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.
Org is absolutely amazing, though unfortunately as a markup language defined by its reference implementation (Org Mode in Emacs), it won't gain much popularity. If you're working alone, and especially if you're already using Emacs, it's the best tool out there. If you have to collaborate with non-Emacsers on a document, RST and Markdown are unfortunately the better choices.
You don't need Emacs in order to work on org-mode documents, in the end it's just a text file.
I write all my org documents in Vim and then convert them via Pandoc or with a keybinding making Emacs convert it in batch mode. It's barely different than working with Markdown, it just offers much more.
You don't need Emacs to work with org-mode, but without Emacs, org-mode is just marginally better but much less popular Markdown. Org-mode really shines through its Emacs implementation - the absolutely magical interface for working with tables, the TODO/agenda capabilities, spreadsheet capabilities, the executable source blocks and literal programming - which turn it into a better version of Jupyter notebooks, etc.
thanks a lot, will go through and get back to you if I have clarifications :)
some suggestions if I may:
* could you add your website to your HN profile? https://news.ycombinator.com/user?id=acidburnNSA - makes it easier to know about it, that was where I looked up first before commenting in this thread
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.
I would most likely go with Semver prefixed dir & md-files.
Then concatenate with python + transform with Pandoc. It was not bad when we (3persons) were doing requirements documentation in a way that our changes are backed by git remote.
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.
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.
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."
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I think one difference you and I have is, I've pretty much ditched the idea of autocomplete being a useful thing so I don't depend on it with any editor. This is coming at it from a Python, Ruby, Elixir point of view.
This is mainly because of 2 things:
1. 99% of the apps I develop are Dockerized and there's no editor that flawlessly handles that
2. I've tried PyCharm, RubyMine, etc. and the autocomplete never really saves me that much time. In my mind "pretty good autocomplete" is worse than no autocomplete. Pretty good autocomplete usually slows you down overall because it's good, but not good enough. I still always find myself referencing documentation which means autocomplete didn't really do anything except maybe save typing a few characters.
I've been coding in Python and Ruby most of the time and now it's Ruby with Go. And while I agree that autocomplete is less usefull with Ruby due to it's nature - it saves a ton of time while developing in Go. And sometimes you simply don't have any documentation to reference. So it's 'go to definition' and autocomplete all the way through.
1. What's the problem with it being Dockerized? I have my current project Dockerized too. JI just have :volumes in my docker-compose for development. If source code access is what we are talkig about.
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...
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‘.
I work with plenty of text in Org-mode using emacs and evil (vim mode for emacs) and I find it just fine. Most of the time, I just use / to search where I want to edit; but maybe you can use something like this: https://github.com/easymotion/vim-easymotion
Also you can research on soft and hard line breaks, so you can move easily within the paragraph VimPencil could help you with that.
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.
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.
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.
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.
Yes, it really is. I use VSCode as my daily driver because I can find an extension for anything. It's good for an electron app, but it's still an electron app. I just tried opening a 20mb log file with similar results on CPU usage. The memory usage for that one file was background noise compared to the 1.9GB VSCode was already using with 2 workspaces and 10 normal source files open.
I think the issue might be the number or type of plugins involved.
I work mostly with ASM, C, C#, and a bit of VB. Even with 3 separate folders open, intelligence running, a couple larger files (of order 100mb) open, ~20 tabs with source and CSV, and a few plugins to help readability, VSC is taking up "only" 700MB.
Not exactly sleek compared to old-school editors, but not quite as bloated as your example.
It's well worth noting that plugins like the C/C++ extension run separate instances for each relevant tab on every workspace. When you have many tabs and many plugins, it starts to eat up a significant amount of space.
As an Atom user I wanted to try this because historically Atom has been worse than VS Code at large files.
I don't have a 500k word text file laying around, but I tried an 80k line SQL script. FWIW, it's 8.5mb and the Atom wordcount plugin claims it's about 1.5 million "words".
Atom opened this file in 3-4 seconds and memory usage only increased about 30mb.
Navigation grinds to a halt with the wordcount plugin enabled. Once I disable its "always on" feature (normally it doesn't pay attention to .sql), navigation and editing seem snappy.
Just a data point. VS Code should be able to get much better...
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.
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).
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.
I genuinely don't know, I just noticed that Emacs could be rather sluggish for some operations while dealing with massive files. For all I know all other editors might fare worse.
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
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.
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.
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 ;)
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.?
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.
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!
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.
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.
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.
"Big" doesn't strictly refer to informaion technology contexts. User / usage context also matters.
For text, a byte is (roughly) a letter, 8 bytes about a word, 32 - 64 bytes a typical sentence, 140 bytes a tweet, 500 bytes the text that will fit on an index card, and 2.4 kB about a page of text (40 lines of 60 characters, about 250 words).
Ten pages is a mid-length essay (25 kB, 2500 words), 100 pages a monograph or short novel (250 kB, 25,000 words), and 1,000 pages a sizeable book (2.5 MB, 250,000 words). As we extend from there, we're talking about shelves, aisles, floors, and libraries worth of content.
My initial "5 MB is about a book" coment comes from experience with formatted textual (rather than graphical/raster) PDFs of books.
The sum total of published human writing is modest by present data standards. The 24 million books of the U.S. Library of Congress, as extual PDFs, would occupy less than 120 TB of storage, about $6,000 at current prices.
Reading that -- by humans, not machines -- might keep you up a few nights.
When writing large literary works, the problems are far less with tthe computing than the authoring: developing and expressing ideas clearly, consistently, and effectively. The constraints on writing tools are imposed by wetware and cranial hardware, not silicon and software.
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.
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 :)
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.
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
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.