Re: comint-carriage-motion, and option nomenclature

[Miles Bader]

Noah Friedman <address@hidden> writes:
> 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$.

I couldn't actually manage to reproduce the problem experimentally,
but I think you're right about the solution, so I changed it.

> 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-".  

First, `comint-enable-carriage-motion' is not really intended to be a
user option, but something for derived modes to set.

Second, I think you're wrong about `enable-' vs. `inhibit-'.  There's a
tension between naming options to always refer to a "positive" action,
and naming options such that they refer to a change from the "normal"
situation.

I don't think there's any mechanical way to decide which is right, and
that we simply have to depend on programmer's judgement.  In the case
of the comint-carriage-motion, `comint-inhibit-carriage-motion' feels
right, whereas `comint-enable-carriage-motion' sounds wrong -- it
sounds like it refers to an exceptional case.

Obviously you disagree, but I guess that's the point: it's a matter of
taste and judgement, not something amenable to a simple rule.

-Miles
-- 
Occam's razor split hairs so well, I bought the whole argument!