Re: cc-mode adds newlines

From:

Kevin Rodgers

Subject:

Re: cc-mode adds newlines

Date:

Mon, 22 Nov 2004 12:16:07 -0700

User-agent:

Mozilla Thunderbird 0.9 (X11/20041105)

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

> (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