From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: custom-mode should not be interactive Date: Wed, 27 Feb 2008 23:27:34 +0200 Organization: JURTA Message-ID: <87skzersxl.fsf@jurta.org> References: <87d4qnw5ub.fsf@freemail.hu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1204147879 19458 80.91.229.12 (27 Feb 2008 21:31:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Feb 2008 21:31:19 +0000 (UTC) Cc: Magnus Henoch , rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 27 22:31:44 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JUTsC-0004hy-Oa for ged-emacs-devel@m.gmane.org; Wed, 27 Feb 2008 22:31:33 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JUTrg-0003uf-If for ged-emacs-devel@m.gmane.org; Wed, 27 Feb 2008 16:31:00 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JUTrb-0003rT-Ae for emacs-devel@gnu.org; Wed, 27 Feb 2008 16:30:55 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JUTra-0003qj-Do for emacs-devel@gnu.org; Wed, 27 Feb 2008 16:30:55 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JUTra-0003qc-9n for emacs-devel@gnu.org; Wed, 27 Feb 2008 16:30:54 -0500 Original-Received: from relay02.kiev.sovam.com ([62.64.120.197]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JUTrW-0005k3-B6; Wed, 27 Feb 2008 16:30:50 -0500 Original-Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1JUTrR-000PVl-VR; Wed, 27 Feb 2008 23:30:46 +0200 In-Reply-To: (Stefan Monnier's message of "Sun, 24 Feb 2008 15:34:28 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-unknown-linux-gnu) X-Scanner-Signature: 817cf4c869a1f0263988801a8cb77744 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Not Detected X-SpamTest-Info: Profiles 2333 [Feb 27 2008] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: none X-SpamTest-Rate: 11 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release X-detected-kernel: by monty-python.gnu.org: FreeBSD 6.x (1) 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: news.gmane.org gmane.emacs.devel:90653 Archived-At: >> I'm not sure how to fix it though, as custom-mode is defined through >> define-derived-mode, which always makes the mode function interactive. >> One way is to define a new keyword argument for define-derived-mode. >> What do you think? > >> I think it would be better not to use `define-derived-mode'. >> In fact, `custom-mode' is not derived from another mode. > > Of course, I disagree. > As the Elisp manual states: > > Even if the new mode is not an obvious derivative of any other mode, > it is convenient to use `define-derived-mode' with a `nil' parent > argument, since it automatically enforces the most important coding > conventions for you. > > As for the OP's question, the manual also states (23.2.2 Major Mode > Conventions): > > * Define a command whose name ends in `-mode', with no arguments, > that switches to the new mode in the current buffer. This command > > so, it *should* be a "command", i.e. an interactive function. > The fact that it doesn't seem to do anything useful is not a problem. > As for the point number 2, we could address it by renaming the command to > customize-mode, although I'd just recommend partial-completion-mode > instead which helps just as well. This is a real usability problem, so I'd like to find a way to fix it. I see that we can't use `customize-mode' because it is already defined as a command to customize options related to the current major mode. This is fine since commands that start with the prefix `customize-' are really entry points to the Customization UI. Fortunately, there is also another namespace with the prefix `Custom-' for commands that operate on the customization buffers, e.g.: Custom-goto-parent Custom-help Custom-reset-current Custom-reset-saved Custom-reset-standard Custom-save Custom-set It seems it would be a prefect fit for the customization mode name `Custom-mode'. This will follow already existing convention to start names of such commands related to Custom mode with the capital C. So the following patch renames `custom-mode' to `Custom-mode' and provides the non-interactive alias `custom-mode': Index: lisp/cus-edit.el =================================================================== RCS file: /sources/emacs/emacs/lisp/cus-edit.el,v retrieving revision 1.341 diff -c -r1.341 cus-edit.el *** lisp/cus-edit.el 16 Jan 2008 16:22:29 -0000 1.341 --- lisp/cus-edit.el 27 Feb 2008 21:27:14 -0000 *************** *** 1578,1584 **** 'custom-button-pressed-unraised)))) (defun custom-buffer-create-internal (options &optional description) ! (custom-mode) (let ((init-file (or custom-file user-init-file))) ;; Insert verbose help at the top of the custom buffer. (when custom-buffer-verbose-help --- 1578,1584 ---- 'custom-button-pressed-unraised)))) (defun custom-buffer-create-internal (options &optional description) ! (Custom-mode) (let ((init-file (or custom-file user-init-file))) ;; Insert verbose help at the top of the custom buffer. (when custom-buffer-verbose-help *************** *** 1684,1690 **** (setq group 'emacs)) (let ((name "*Customize Browser*")) (pop-to-buffer (custom-get-fresh-buffer name))) ! (custom-mode) (widget-insert (format "\ %s buttons; type RET or click mouse-1 on a button to invoke its action. --- 1684,1690 ---- (setq group 'emacs)) (let ((name "*Customize Browser*")) (pop-to-buffer (custom-get-fresh-buffer name))) ! (Custom-mode) (widget-insert (format "\ %s buttons; type RET or click mouse-1 on a button to invoke its action. *************** *** 4634,4640 **** (if (eq (widget-get (widget-get widget :parent) :custom-state) 'modified) (message "To install your edits, invoke [State] and choose the Set operation"))) ! (define-derived-mode custom-mode nil "Custom" "Major mode for editing customization buffers. The following commands are available: --- 4634,4640 ---- (if (eq (widget-get (widget-get widget :parent) :custom-state) 'modified) (message "To install your edits, invoke [State] and choose the Set operation"))) ! (define-derived-mode Custom-mode nil "Custom" "Major mode for editing customization buffers. The following commands are available: *************** *** 4695,4701 **** --- 4695,4709 ---- (set (make-local-variable 'widget-link-suffix) "")) (add-hook 'widget-edit-functions 'custom-state-buffer-message nil t)) + (put 'Custom-mode 'mode-class 'special) + + ;; backward-compatibility + (defun custom-mode () + "Non-interactive variant of `Custom-mode'." + (Custom-mode)) + (make-obsolete 'custom-mode 'Custom-mode "23.0") (put 'custom-mode 'mode-class 'special) + (define-obsolete-variable-alias 'custom-mode-hook 'Custom-mode-hook "23.0") (dolist (regexp '("^No user option defaults have been changed since Emacs " -- Juri Linkov http://www.jurta.org/emacs/