Re: cc-mode adds newlines

[Kevin Rodgers]

Stefan Monnier wrote:
>>I think we should add a variable require-final-newline-modes which
>>would be a list of mode names.  run-mode-hook could see if the current
>>mode is in require-final-newline-modes, and if so, set
>>require-final-newline to require-final-newline-mode-value.  The
>>default for require-final-newline-mode-value would be :ask, but if a
>>user sets it to t, then all the appriate modes would set
>>require-final-newline to t.
>
>
> I think that would be silly.  Tons of variable might want to be set
> differently in different modes.  Do we really want to add all the
> corresponding foo-modes side-variables?
> I think we'd be better off with a more generic solution.

I agree, but I would like to see it implemented outside of customize.
Custom would of course provide an interface to it, but wouldn't be the
only way to specify a mode-specific value.

For example, what if you just stored those values in each variable's
property list?  E.g.

(put 'require-final-newline 'c-mode t)

would be equivalent to

(add-hook 'c-mode-hook
          (lambda ()
            (set (make-local-variable 'require-final-newline) t))

> I.e. we should aim for a way to specify per-mode settings in custom.
> That would be a lot more useful and wouldn't require adding any
> new variable.
>
> Here is one way it could work:
>
> - instead of `:type foo' use `:type (per-mode foo)' where (per-mode foo)
>   stands for something like (repeat (cons mode foo)) where the list 
of modes
>   can be obtained doing
>
>     (let ((modes nil) mode)
>       (mapatoms (lambda (s)
>                   (if (and (string-match "-mode-hook\\'" (symbol-name s))
>                            (fboundp (intern (concat (setq mode 
(substring (symbol-name s) 0 (match-beginning 0))) "-mode"))))
>                       (push mode modes))))
>       modes)

Minor improvement (eliminate concat):

                  (when (and (string-match "\\(-mode\\)-hook\\'" 
(symbol-name s))
                             (fboundp (intern (setq mode (substring 
(symbol-name s) 0 (match-end 1))))))
                    (push mode modes))))

Why is it better to look for -mode-hook variables and derive the -mode
function, than to just look for -mode functions?

> - set custom-get and custom-set functions could look like:
>
> (defun custom-set-per-mode (var vals)
>   (put var 'custom-per-mode vals)
>   (dolist (setting vals)
>     (let ((mode (car setting))
>           (value (cdr setting)))
>       (if (eq t mode)
>           (set-default var value)
>         (let ((fun (intern (concat "custom-set-" mode "-" 
(symbol-name var)))))
>           (unless (fboundp fun)
>             (fset fun
>                   `(lambda ()
>                      (let ((val (assoc ',mode (get ',var 
'custom-per-mode))))
>                        (if val (set (make-local-variable ',var) (cdr 
val)))))))
>           (add-hook (intern (concat mode "-mode-hook")) fun))))))
>
> (defun custom-get-per-mode (var)
>   (let* ((val (get var 'custom-per-mode))
>          (defval (assq t val)))
>     (unless (eq (cdr defval) (default-value var))
>       ;; It was changed somehow...
>       (setcdr defval (default-value var)))
>     val))

Ah, we're talking about almost exactly the same thing.  You've collected
all the mode-specific values into an association list keyed by the mode
symbol, and put that on the variable's custom-per-mode property; whereas
I put each value on a separate property.

But the main difference is that I imagined the mode-specific value being
set by normal-mode instead of the mode's hook (which would be preserved
as a user option, not a system variable).

> Ideally we should even provide such per-mode settings for *all* custom
> variables, without having to change the `defcustom'.

--
Kevin Rodgers