In the long tradition of "Considered harmful" articles, let me address one of my pet peeves when it comes to zsh. Enter the `CORRECT_ALL' option:

 CORRECT_ALL (-O)
     Try to correct the spelling of all arguments in a line.

Sounds innocent enough, doesn't it? After all, automatic stuff is awesome. It takes manual work from the user. You can't argue with that. And it can do good:

 % foo="Hello World"
 % echo $fooo
 zsh: correct '$fooo' to '$foo'? (YNEA) y
 Hello World

Woot! Nice.

So, why am I complaining so much about this? Well, a word that doesn't look special will always be subject to filename-based correction. Okay, that's a bit of a lie, too. If you look at zsh's source code, you will notice that zsh will not try word correction if the word is "in" or if the word starts in a dash (most commands in the unix realm take their options like that) or if the word starts with a percent sign (because in zsh - and other shells for that matter - you address backgrounded or suspended jobs with words that look like that).

Still doing filename-based correction on everything that doesn't look like something special borders on insanity. Many commands handle subcommands, like cvs or other version control systems. And how about this:

% touch ccommit
% cvs commit
zsh: correct 'commit' to 'ccommit'? (YNEA)

What the hell!? No! Or what about programs that take their options differently, say with a plus instead of a minus - and if only to have "+bar" mean the opposite of "-bar":

% touch bar
% echo +bar
zsh: correct '+bar' to 'bar'? (YNEA)

You can dream up an infinite amount of examples like that. On of the more prominent ones being the use of "sudo vim ..." on operating systems like Ubuntu, which in their default install disable the use of a `root' user to avoid it being misused by unsuspecting newcomers. Now if you use said command and are a self-respecting vim user, you'll have some sort of configuration for the editor within the ~/.vim subdirectory. And zsh will ask if it should correct "vim" to ".vim". Isn't that great.

One final example you can't leave out in arguments concerning `CORRECT_ALL' is its use in connection with potentially destructive commands such as `mv':

% ls
foo  mumble
% mv foo mumbl
zsh: correct 'mumbl' to 'mumble'? (YNEA)

In a moment of abstraction you might override files you wish you didn't have. But thank the mighty Zeus computer user never are in a hurry and always read enquiries made by their user interface quite carefully. ;)

It's not that you cannot reign correction in at all. You can. How? Well, you have the option to turn correction off selectively for commands with which it doesn't have a chance:

% alias echo="nocorrect echo"
% echo +bar
+bar

I am sure anybody who really uses `CORRECT_ALL' already does something like that, because it is pretty much the only option you got, since sadly, you cannot setup more special-case ignores (like the default "-*" and "%*") via the `$CORRECT_IGNORE' parameter. It doesn't apply for filename-based as done by `CORRECT_ALL'. That's a pity. Maybe it's time for an additional `$CORRECT_FILES_IGNORE' parameter. "Send patches!", I guess.

FWIW, I am not against automatic correction. It is just that this way is blatantly wrong so much of the time, that its use should never ever be advocated to new users. Things could be better, too. Zsh has this wonderful completion system that has a pretty good idea of what the context for a cursor-position in a given command buffer is. Is the current word an option? a command? a file? It could tell us. If the correction mechanism could then dispatch to specific handlers, everything could be made to make the right choice at quite an impressive rate. The problem is that the correction mechanism is very much hardcoded within zsh's C core. I've tried for a day or two years ago, but shut down the experiment because it was too much work for too little gain.

Too little gain? Why yes. You're using zsh. You shouldn't ever have a misspelled file name on your command line anyway. If you do, you didn't use zsh's completion system. Which you should. All. The. Time. It has completers like `_correct' and `_approximate', that can help you get the spelling of sub-commands, options, file names and whatever else right. This sort of power makes `CORRECT_ALL' largely obsolete in my humble opinion, so much that this particular option became the one feature I wish zsh did not have.

I hope I made my position as well as my concerns clear. I do not deem automatic action in general, or correction specifically, to be evil. Far from it. I love it. I am also a user of the `CORRECT' option - because it has a decent chance to be right most of the time. `CORRECT_ALL', at least if set without any other sort of configuration, does not.

Now that I think of it, maybe this article should have rather been called "Anything that advocates or sets `CORRECT_ALL' by default considered harmful", but that would have sounded way too long and clumsy. :-)