all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* custom-mode should not be interactive
@ 2008-02-24  0:33 Magnus Henoch
  2008-02-24 15:23 ` Richard Stallman
  0 siblings, 1 reply; 7+ messages in thread
From: Magnus Henoch @ 2008-02-24  0:33 UTC (permalink / raw)
  To: emacs-devel

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





^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: custom-mode should not be interactive
  2008-02-24  0:33 custom-mode should not be interactive Magnus Henoch
@ 2008-02-24 15:23 ` Richard Stallman
  2008-02-24 20:34   ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: Richard Stallman @ 2008-02-24 15:23 UTC (permalink / raw)
  To: Magnus Henoch; +Cc: emacs-devel

    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.




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: custom-mode should not be interactive
  2008-02-24 15:23 ` Richard Stallman
@ 2008-02-24 20:34   ` Stefan Monnier
  2008-02-27 21:27     ` Juri Linkov
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2008-02-24 20:34 UTC (permalink / raw)
  To: rms; +Cc: Magnus Henoch, emacs-devel

>     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







^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: custom-mode should not be interactive
  2008-02-24 20:34   ` Stefan Monnier
@ 2008-02-27 21:27     ` Juri Linkov
  2008-02-27 22:31       ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: Juri Linkov @ 2008-02-27 21:27 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Magnus Henoch, rms, emacs-devel

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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: custom-mode should not be interactive
  2008-02-27 21:27     ` Juri Linkov
@ 2008-02-27 22:31       ` Stefan Monnier
  2008-02-27 22:50         ` Juri Linkov
  0 siblings, 1 reply; 7+ messages in thread
From: Stefan Monnier @ 2008-02-27 22:31 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Magnus Henoch, rms, emacs-devel

> 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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: custom-mode should not be interactive
  2008-02-27 22:31       ` Stefan Monnier
@ 2008-02-27 22:50         ` Juri Linkov
  2008-02-28  1:50           ` Stefan Monnier
  0 siblings, 1 reply; 7+ messages in thread
From: Juri Linkov @ 2008-02-27 22:50 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Magnus Henoch, rms, emacs-devel

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




^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: custom-mode should not be interactive
  2008-02-27 22:50         ` Juri Linkov
@ 2008-02-28  1:50           ` Stefan Monnier
  0 siblings, 0 replies; 7+ messages in thread
From: Stefan Monnier @ 2008-02-28  1:50 UTC (permalink / raw)
  To: Juri Linkov; +Cc: Magnus Henoch, rms, emacs-devel

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




^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2008-02-28  1:50 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-24  0:33 custom-mode should not be interactive Magnus Henoch
2008-02-24 15:23 ` Richard Stallman
2008-02-24 20:34   ` Stefan Monnier
2008-02-27 21:27     ` Juri Linkov
2008-02-27 22:31       ` Stefan Monnier
2008-02-27 22:50         ` Juri Linkov
2008-02-28  1:50           ` Stefan Monnier

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.