• 0 Posts
  • 4 Comments
Joined 1Y ago
cake
Cake day: Jul 01, 2023

help-circle
rss

It’s useful when vim is being run from a different program or script.

For example, if I run p4 change to create a new Perforce changelist it will open up my editor (which I have set to vim) so that I can enter the CL description and other fields. If I realize I don’t actually actually want to create the CL yet I can use :cq to quit with an error so that p4 knows to abort.

I also have a script I use for diffing a list of file pairs. It runs vimdiff on the first pair of files then if I exit with :qa it will move on to the next pair of files. But if I exit with :cq it will just abort and skip all of the remaining file pairs.


I agree that it’s the most obvious choice, but it also doesn’t work when there are hidden buffers open. :qa! and :cq should always work so they are arguably more correct


It makes more sense when you realize it’s based on code.golf submissions. No one is going to create a class like that for a code golf problem. They’re probably not going to create any classes (other than one just to hold the main function).

I’m pretty sure I can do the Fibonnaci one with less code than your simple class. Because these problems are simple enough they don’t benefit from any OOP stuff so you avoid most of the syntactic overhead.

I am surprised it’s not higher in the list since the overhead of setting up a main method is still quite significant compared to most languages. But other than that, these problems can be solved without running into any egregious examples of overhead.