Re: comint-carriage-motion, and option nomenclature

[Noah Friedman]

>By contrast, consider variable names like `comint-handle-carriage-motion' or
>`comint-interpet-carriage' motion.  In these, the verb refers not to the
>state change when you set the variable, but rather the action performed when
>it's true.  To me, names like thisseem much more neutral, and better suited
>to cases where either on or off are reasonable defaults.
>
>I wouldn't object to using either of those names or something similar for
>comint-carriage-motion, and changing the sense to positive == enabled.

I'd be in favor of that.

Oh, I also just noticed that comint-carriage-motion also handles backspace
motion, which is a fine idea but it makes the function more general than
its present name implies.  Maybe it should be called something like
comint-cursor-motion instead, so it will be the obvious place to add
additional motion handlers in the future.  In fact, this could be made more
customizable now.  What do you think of something like the following:

    (defvar comint-cursor-motion-table
      `(("\r$" . ,#'(lambda () (delete-char -1)))
        ("\r"  . ,#'(lambda () (delete-region (point) 
                                              (line-beginning-position))))
        ("\b"  . ,#'(lambda () (delete-char -2))))

    (defun comint-cursor-motion (start end)
      (save-excursion
        (goto-char start)
        (when (< (skip-chars-forward "^\b\r" end) (- end start))
          (save-match-data
            (save-restriction
              (widen)
              (let ((inhibit-field-text-motion t)
                    (buffer-read-only nil))
                (mapc #'(lambda (elt)
                          (goto-char start)
                          (while (re-search-forward (car elt))
                            (funcall (cdr elt))))
                      comint-cursor-motion-table)))))))

I'm not strongly advocating rewriting it this way, it was just an idea
that suggested itself, since I've seen other escape sequences from time to
time that might be interesting to handle (e.g. ^[[D instead of ^H).

> (1) Variable names containing verbs like `enable' or `inhibit', which imply
>     a change to the normal case, should only be used when there's an obvious
>     default state.  Such variables should be named so that the normal state
>     corresponds to a `nil' setting, and setting the variable to non-nil
>     overrides this.
>
> (2) All other variables _shouldn't_ use verbs like `enable' or `inhibit'.

A lot of variables today in fact don't use `enable' or `inhibit', and I
don't seem to find that confusing.  It's just the enable/inhibit contrast
that jumps out at me.

You've mostly convinced me; I'm just not sure how obvious what the default
states should be sometimes.  I looked over my own programs and noticed that
I never seem to use "enable" in variable names, but sometimes state
variables have "enabled" in their names, though.  Maybe the ambivalence is
just mine.  :-)