From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kevin Rodgers Newsgroups: gmane.emacs.devel Subject: Re: cc-mode adds newlines Date: Mon, 22 Nov 2004 12:16:07 -0700 Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1101151002 13514 80.91.229.6 (22 Nov 2004 19:16:42 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 22 Nov 2004 19:16:42 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 22 20:16:31 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CWJfq-0002zM-00 for ; Mon, 22 Nov 2004 20:16:31 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CWJou-000850-51 for ged-emacs-devel@m.gmane.org; Mon, 22 Nov 2004 14:25:52 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CWJom-00084p-Kh for emacs-devel@gnu.org; Mon, 22 Nov 2004 14:25:44 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CWJol-00084P-PG for emacs-devel@gnu.org; Mon, 22 Nov 2004 14:25:44 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CWJol-00084M-LK for emacs-devel@gnu.org; Mon, 22 Nov 2004 14:25:43 -0500 Original-Received: from [80.91.229.2] (helo=main.gmane.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CWJfb-0008Dk-G4 for emacs-devel@gnu.org; Mon, 22 Nov 2004 14:16:15 -0500 Original-Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1CWJfY-0008Lt-00 for ; Mon, 22 Nov 2004 20:16:12 +0100 Original-Received: from 170.207.1.200 ([170.207.1.200]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2004 20:16:12 +0100 Original-Received: from ihs_4664 by 170.207.1.200 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 22 Nov 2004 20:16:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-To: emacs-devel@gnu.org Original-Lines: 102 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 170.207.1.200 User-Agent: Mozilla Thunderbird 0.9 (X11/20041105) X-Accept-Language: en-us, en In-Reply-To: X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:30263 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30263 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