custom-mode should not be interactive

custom-mode should not be interactive

[Magnus Henoch]

I noticed that custom-mode is an interactive function now.  I think it
shouldn't be, for two reasons:

1. It doesn't do anything useful when called interactively.
2. It hinders tab completion, making M-x customize-variable etc more
   difficult to type.

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?

Magnus

Re: custom-mode should not be interactive

[Richard Stallman]

    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.

Re: custom-mode should not be interactive

[Stefan Monnier]

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


        Stefan

Re: custom-mode should not be interactive

[Juri Linkov]

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

Re: custom-mode should not be interactive

[Stefan Monnier]

> 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':

Looks good, except I see no need for a `custom-mode'
backward-compatibility alias.


        Stefan

Re: custom-mode should not be interactive

[Juri Linkov]

>> 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':
>
> Looks good, except I see no need for a `custom-mode'
> backward-compatibility alias.

There are two places in Emacs where `custom-mode' is used:
lisp/info-look.el and lisp/emulation/viper.el.  We could rename
`custom-mode' to `Custom-mode' in these places and don't care about
some external package using it.

Also lisp/progmodes/ada-prj.el uses `custom-mode-map' but it seems
renaming `custom-mode-map' to `Custom-mode-map' is not necessary,
because `Custom-mode' calls `use-local-map' to set `custom-mode-map'
explicitly (so it doesn't use its default `Custom-mode-map').

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: custom-mode should not be interactive

[Stefan Monnier]

>>> 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':
>> 
>> Looks good, except I see no need for a `custom-mode'
>> backward-compatibility alias.

> There are two places in Emacs where `custom-mode' is used:
> lisp/info-look.el and lisp/emulation/viper.el.  We could rename
> `custom-mode' to `Custom-mode' in these places and don't care about
> some external package using it.

I guess the compatibility alias is OK, then.


        Stefan