comint-carriage-motion, and option nomenclature

[Noah Friedman <friedman@splode.com>]

I have two remarks about the current implementation of
comint-carriage-motion.

The first is that currently, when I run a shell that has onlcr set on the
tty, I can't see any output in the buffer at all.  I think this is because
comint-carriage-motion needs to (goto-char start) before calling
skip-chars-forward to look for \r$.

Secondly, and more generally, I find the inconsistent usage of variables to
enable options "in the negative" vs. enabling "in the positive" to be
disturbing.  

Some user options are named positively, e.g. `enable-local-eval',
`enable-flow-control', `enable-multibyte-characters'.

On the other hand, some user options are named like
`inhibit-eol-conversion', `inhibit-startup-message', etc.

In a few cases (especially for temporarily disabling features that are
normally enabled by other flags, e.g. `inhibit-read-only' overrides the
effects of `buffer-read-only') this is reasonable; those are not user
options.

But I really think user options ought to be consistent: all options should
be of the form "enable-some-behavior".  It doesn't matter what the default
actually is; but options should not be named according to what the "normal"
code path is.  Rather they should indicate whether an activity that is
controlled by that particular option is currently enabled or not.

It's probably too late to change the variables I mentioned, but I'm making
an appeal that the variable `comint-inhibit-carriage-motion' be renamed to
`comint-enable-carriage-motion' and the default changed to t.  And that all
new user options in the future use "enable-", not "inhibit-".