Problems with whole buffer Custom functions.

Problems with whole buffer Custom functions.

[Luc Teirlinck]

Recently more emphasized (via the mode docstring) Custom buffer
key bindings (C-x C-s and C-c C-c) have problems.

`custom-mode-map' is _not_ enabled in the entire Custom buffer.  For
instance, it is not enabled in editable fields.

I can not do the following example in `emacs -q' because it involves
saving into .emacs, but I am pretty sure the problems are not caused
by my customizations.

Do `M-x customize-option RET double-click-time'.  Edit the value in
the editable field and, with point still in the editable field, do
`C-x C-s', which according to the mode doc is going to save your new
value in your .emacs.  Note that instead you get asked in which file
you want to save the Custom buffer.  With point still in the editable
field, doing C-c C-c shows that it is not defined.

I do not immediately know whether editable fields are the only problem.

Sincerely,

Luc.

Re: Problems with whole buffer Custom functions.

[Juri Linkov]

> Recently more emphasized (via the mode docstring) Custom buffer
> key bindings (C-x C-s and C-c C-c) have problems.
>
> `custom-mode-map' is _not_ enabled in the entire Custom buffer.  For
> instance, it is not enabled in editable fields.

More keys are not enabled in editable fields, for instance, `n' and `p':

    Move to next button or editable field.     n
    Move to previous button or editable field. p

They can be used only until point reaches the first editable field.
After that keys get inserted literally to the field.

> I can not do the following example in `emacs -q' because it involves
> saving into .emacs, but I am pretty sure the problems are not caused
> by my customizations.
>
> Do `M-x customize-option RET double-click-time'.  Edit the value in
> the editable field and, with point still in the editable field, do
> `C-x C-s', which according to the mode doc is going to save your new
> value in your .emacs.  Note that instead you get asked in which file
> you want to save the Custom buffer.  With point still in the editable
> field, doing C-c C-c shows that it is not defined.

Perhaps cus-edit should bind `C-c C-c' and `C-x C-s' in a new keymap
inheriting from widget-field-keymap.

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

Re: Problems with whole buffer Custom functions.

[Luc Teirlinck]

   More keys are not enabled in editable fields, for instance, `n' and `p':

       Move to next button or editable field.     n
       Move to previous button or editable field. p

   They can be used only until point reaches the first editable field.
   After that keys get inserted literally to the field.

Of course, ordinary self-inserting characters _should_ self-insert in
editable fields.  But note that TAB still moves to next button or
editable field (I guess that list should now also include "link").
S-TAB also has its regular meaning, but the recently added M-TAB does
not, because it has another (completion related) meaning in editable
fields.

Sincerely,

Luc.

Re: Problems with whole buffer Custom functions.

[Juri Linkov]

> Of course, ordinary self-inserting characters _should_ self-insert in
> editable fields.  But note that TAB still moves to next button or
> editable field (I guess that list should now also include "link").
> S-TAB also has its regular meaning, but the recently added M-TAB does
> not, because it has another (completion related) meaning in editable
> fields.

I think this is mostly a documentation problem.  `C-h m' on a customization
buffer suggests using `n' and `p' instead of better `TAB' and `S-TAB':

  Move to next button or editable field.     n
  Move to previous button or editable field. p
  Complete content of editable text field.   M-TAB

Adding `\\<widget-keymap>\' before first two lines above in the docstring
of `custom-mode' to force displaying keybindings from `widget-keymap', the
output of `C-h m' is still not good:

  Move to next button or editable field.     TAB
  Move to previous button or editable field. M-TAB
  Complete content of editable text field.   M-TAB

Note duplicate `M-TAB' for different contexts.

Also while `C-x C-s' and `C-c C-c' are not available in editable fields,
the docstring should warn about this fact.

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

Re: Problems with whole buffer Custom functions.

[Kevin Rodgers]

Juri Linkov wrote:
>>Of course, ordinary self-inserting characters _should_ self-insert in
>>editable fields.  But note that TAB still moves to next button or
>>editable field (I guess that list should now also include "link").
>>S-TAB also has its regular meaning, but the recently added M-TAB does
>>not, because it has another (completion related) meaning in editable
>>fields.
> 
> 
> I think this is mostly a documentation problem.  `C-h m' on a customization
> buffer suggests using `n' and `p' instead of better `TAB' and `S-TAB':
> 
>   Move to next button or editable field.     n
>   Move to previous button or editable field. p
>   Complete content of editable text field.   M-TAB

Would M-n and M-p be better?

> Adding `\\<widget-keymap>\' before first two lines above in the docstring
> of `custom-mode' to force displaying keybindings from `widget-keymap', the
> output of `C-h m' is still not good:
> 
>   Move to next button or editable field.     TAB
>   Move to previous button or editable field. M-TAB
>   Complete content of editable text field.   M-TAB
> 
> Note duplicate `M-TAB' for different contexts.

Would that go away if M-n and M-p were in front of (i.e. added later
than) TAB and M-TAB in widget-keymap?

-- 
Kevin Rodgers

Re: Problems with whole buffer Custom functions.

[Richard M. Stallman]

      Move to next button or editable field.     TAB
      Move to previous button or editable field. M-TAB
      Complete content of editable text field.   M-TAB

    Note duplicate `M-TAB' for different contexts.

It's not a bug in the help mechanism, because it is looking these up
in two different keymaps.

Anyway, I will define a command advertised-widget-backward
to control what this displays.

Re: Problems with whole buffer Custom functions.

[Juri Linkov]

> Of course, ordinary self-inserting characters _should_ self-insert in
> editable fields.  But note that TAB still moves to next button or
> editable field (I guess that list should now also include "link").

In the patch below I've added "link" to the docstring of `custom-mode'
to custom.texi, and fixed examples in custom.texi since links
in customization buffer don't have square brackets anymore.

Index: lisp/cus-edit.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/cus-edit.el,v
retrieving revision 1.279
diff -c -r1.279 cus-edit.el
*** lisp/cus-edit.el	19 Jan 2006 23:26:04 -0000	1.279
--- lisp/cus-edit.el	22 Jan 2006 00:33:54 -0000
***************
*** 4425,4436 ****
  
  The following commands are available:
  
! Move to next button or editable field.     \\[widget-forward]
! Move to previous button or editable field. \\[widget-backward]
! \\<widget-field-keymap>\
  Complete content of editable text field.   \\[widget-complete]
  \\<custom-mode-map>\
! Invoke button under the mouse pointer.     \\[Custom-move-and-invoke]
  Invoke button under point.		   \\[widget-button-press]
  Set all options from current text.         \\[Custom-set]
  Make values in current text permanent.     \\[Custom-save]
--- 4430,4442 ----
  
  The following commands are available:
  
! \\<widget-keymap>\
! Move to next button, link or editable field.     \\[widget-forward]
! Move to previous button, link or editable field. \\[widget-backward]
! \\<custom-field-keymap>\
  Complete content of editable text field.   \\[widget-complete]
  \\<custom-mode-map>\
! Invoke button under the mouse pointer.     \\[widget-move-and-invoke]
  Invoke button under point.		   \\[widget-button-press]
  Set all options from current text.         \\[Custom-set]
  Make values in current text permanent.     \\[Custom-save]

Index: man/custom.texi
===================================================================
RCS file: /sources/emacs/emacs/man/custom.texi,v
retrieving revision 1.104
diff -c -r1.104 custom.texi
*** man/custom.texi	19 Jan 2006 17:34:34 -0000	1.104
--- man/custom.texi	22 Jan 2006 00:34:47 -0000
***************
*** 202,208 ****
  
    The appearance of the example buffers in this section is typically
  different under a window system, since faces are then used to indicate
! buttons and editable fields.
  
  @menu
  * Groups: Customization Groups.   How settings are classified in a structure.
--- 202,208 ----
  
    The appearance of the example buffers in this section is typically
  different under a window system, since faces are then used to indicate
! buttons, links and editable fields.
  
  @menu
  * Groups: Customization Groups.   How settings are classified in a structure.
***************
*** 232,243 ****
  /- Emacs group: ---------------------------------------------------\
        [State]: visible group members are all at standard values.
     Customization of the One True Editor.
!    See also [Manual].
  
! Editing group: [Go to Group]
  Basic text editing facilities.
  
! External group: [Go to Group]
  Interfacing to external utilities.
  
  @var{more second-level groups}
--- 232,243 ----
  /- Emacs group: ---------------------------------------------------\
        [State]: visible group members are all at standard values.
     Customization of the One True Editor.
!    See also Manual.
  
! Editing group: Go to Group
  Basic text editing facilities.
  
! External group: Go to Group
  Interfacing to external utilities.
  
  @var{more second-level groups}
***************
*** 256,271 ****
  
  @cindex editable fields (customization buffer)
  @cindex buttons (customization buffer)
    Most of the text in the customization buffer is read-only, but it
  typically includes some @dfn{editable fields} that you can edit.
! There are also @dfn{buttons}, which do something when you @dfn{invoke}
! them.  To invoke a button, either click on it with @kbd{Mouse-1}, or
! move point to it and type @key{RET}.
! 
!   For example, the phrase @samp{[Go to Group]} that appears in a
! second-level group is a button.  Invoking it creates a new
! customization buffer, which shows that group and its contents.  This
! is a kind of hypertext link to another group.
  
    The @code{Emacs} group includes a few settings, but mainly it
  contains other groups, which contain more groups, which contain the
--- 256,273 ----
  
  @cindex editable fields (customization buffer)
  @cindex buttons (customization buffer)
+ @cindex links (customization buffer)
    Most of the text in the customization buffer is read-only, but it
  typically includes some @dfn{editable fields} that you can edit.
! There are also @dfn{buttons} and @dfn{links}, which do something when
! you @dfn{invoke} them.  To invoke a button or a link, either click on
! it with @kbd{Mouse-1}, or move point to it and type @key{RET}.
! 
!   For example, the phrase @samp{[State]} that appears in
! a second-level group is a button.  It operates on the same
! customization buffer.  But the phrase @samp{Go to Group} is a kind
! of hypertext link to another group.  Invoking it creates a new
! customization buffer, which shows that group and its contents.
  
    The @code{Emacs} group includes a few settings, but mainly it
  contains other groups, which contain more groups, which contain the
***************
*** 288,295 ****
  @samp{[+]}.  When the group contents are visible, this button changes to
  @samp{[-]}; invoking that hides the group contents.
  
!   Each setting in this buffer has a button which says @samp{[Group]},
! @samp{[Option]} or @samp{[Face]}.  Invoking this button creates an
  ordinary customization buffer showing just that group and its
  contents, just that user option, or just that face.  This is the way
  to change settings that you find with @kbd{M-x customize-browse}.
--- 290,297 ----
  @samp{[+]}.  When the group contents are visible, this button changes to
  @samp{[-]}; invoking that hides the group contents.
  
!   Each setting in this buffer has a link which says @samp{Group},
! @samp{Option} or @samp{Face}.  Invoking this link creates an
  ordinary customization buffer showing just that group and its
  contents, just that user option, or just that face.  This is the way
  to change settings that you find with @kbd{M-x customize-browse}.

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

Re: Problems with whole buffer Custom functions.

[Luc Teirlinck]

Juri Linkov wrote:

   In the patch below I've added "link" to the docstring of `custom-mode'
   to custom.texi, and fixed examples in custom.texi since links
   in customization buffer don't have square brackets anymore.

In latest CVS, they apparently still do (in emacs -nw -q).

Sincerely,

Luc.

Re: Problems with whole buffer Custom functions.

[Juri Linkov]

>    In the patch below I've added "link" to the docstring of `custom-mode'
>    to custom.texi, and fixed examples in custom.texi since links
>    in customization buffer don't have square brackets anymore.
>
> In latest CVS, they apparently still do (in emacs -nw -q).

Actually, I meant that links in customization buffer don't have square
brackets with my latest patch I posted on another thread.  Below I've
extracted that part into a separate patch.  I think it is inappropriate
to enclose links into square brackets.  Square brackets are a textual
representation of buttons to indicate a rectangular area around them
that looks like buttons.  OTOH, links are underlined blue and don't need
additional markup like square brackets. So I propose not to display links
in square brackets even on a tty and to update the manual:

Index: lisp/cus-edit.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/cus-edit.el,v
retrieving revision 1.280
diff -c -r1.280 cus-edit.el
*** lisp/cus-edit.el	23 Jan 2006 01:21:24 -0000	1.280
--- lisp/cus-edit.el	23 Jan 2006 01:41:57 -0000
***************
*** 4450,4458 ****
    ;; may not be optimal.
    (when custom-raised-buttons
      (set (make-local-variable 'widget-push-button-prefix) "")
!     (set (make-local-variable 'widget-push-button-suffix) "")
!     (set (make-local-variable 'widget-link-prefix) "")
!     (set (make-local-variable 'widget-link-suffix) ""))
    (add-hook 'widget-edit-functions 'custom-state-buffer-message nil t)
    (run-mode-hooks 'custom-mode-hook))
  
--- 4451,4459 ----
    ;; may not be optimal.
    (when custom-raised-buttons
      (set (make-local-variable 'widget-push-button-prefix) "")
!     (set (make-local-variable 'widget-push-button-suffix) ""))
!   (set (make-local-variable 'widget-link-prefix) "")
!   (set (make-local-variable 'widget-link-suffix) "")
    (add-hook 'widget-edit-functions 'custom-state-buffer-message nil t)
    (run-mode-hooks 'custom-mode-hook))

Index: man/custom.texi
===================================================================
RCS file: /sources/emacs/emacs/man/custom.texi,v
retrieving revision 1.105
diff -c -r1.105 custom.texi
*** man/custom.texi	23 Jan 2006 01:30:13 -0000	1.105
--- man/custom.texi	23 Jan 2006 01:41:59 -0000
***************
*** 232,243 ****
  /- Emacs group: ---------------------------------------------------\
        [State]: visible group members are all at standard values.
     Customization of the One True Editor.
!    See also [Manual].
  
! Editing group: [Go to Group]
  Basic text editing facilities.
  
! External group: [Go to Group]
  Interfacing to external utilities.
  
  @var{more second-level groups}
--- 232,243 ----
  /- Emacs group: ---------------------------------------------------\
        [State]: visible group members are all at standard values.
     Customization of the One True Editor.
!    See also Manual.
  
! Editing group: Go to Group
  Basic text editing facilities.
  
! External group: Go to Group
  Interfacing to external utilities.
  
  @var{more second-level groups}
***************
*** 265,271 ****
  
    For example, the phrase @samp{[State]} that appears in
  a second-level group is a button.  It operates on the same
! customization buffer.  The phrase @samp{[Go to Group]} is a kind
  of hypertext link to another group.  Invoking it creates a new
  customization buffer, which shows that group and its contents.
  
--- 265,271 ----
  
    For example, the phrase @samp{[State]} that appears in
  a second-level group is a button.  It operates on the same
! customization buffer.  But the phrase @samp{Go to Group} is a kind
  of hypertext link to another group.  Invoking it creates a new
  customization buffer, which shows that group and its contents.
  
***************
*** 290,297 ****
  @samp{[+]}.  When the group contents are visible, this button changes to
  @samp{[-]}; invoking that hides the group contents.
  
!   Each setting in this buffer has a link which says @samp{[Group]},
! @samp{[Option]} or @samp{[Face]}.  Invoking this link creates an
  ordinary customization buffer showing just that group and its
  contents, just that user option, or just that face.  This is the way
  to change settings that you find with @kbd{M-x customize-browse}.
--- 290,297 ----
  @samp{[+]}.  When the group contents are visible, this button changes to
  @samp{[-]}; invoking that hides the group contents.
  
!   Each setting in this buffer has a link which says @samp{Group},
! @samp{Option} or @samp{Face}.  Invoking this link creates an
  ordinary customization buffer showing just that group and its
  contents, just that user option, or just that face.  This is the way
  to change settings that you find with @kbd{M-x customize-browse}.

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

Re: Problems with whole buffer Custom functions.

[Richard M. Stallman]

      OTOH, links are underlined blue and don't need
    additional markup like square brackets.

Not on a tty they aren't.  There is no underlining.

					    So I propose not to display links
    in square brackets even on a tty and to update the manual:

No, please don't install that.

Re: Problems with whole buffer Custom functions.

[Juri Linkov]

>       OTOH, links are underlined blue and don't need
>     additional markup like square brackets.
>
> Not on a tty they aren't.  There is no underlining.
>
> 					    So I propose not to display links
>     in square brackets even on a tty and to update the manual:
>
> No, please don't install that.

I don't insist on removing square brackets.  I only wanted to make the
appearance of buttons and links consistent at least on same display types.

Currently there is the following inconsistency on the link appearance:

on graphics terminals:
links in Customize   - underlined blue
links in Info        - underlined blue
links in Help        - underlined

on xterms:
links in Customize   - underlined blue with square brackets
links in Info        - underlined blue
links in Help        - underlined

on ttys:
links in Customize   - blue with square brackets
links in Info        - blue
links in Help        - no highlighting at all

I propose to change them according to the following scheme (I'm still not
quite sure about adding blue to links in the Help buffer):

On graphics terminals:
links in Customize   - underlined blue
links in Info        - underlined blue
links in Help        - underlined (blue?)

On xterms:
links in Customize   - underlined blue
links in Info        - underlined blue
links in Help        - underlined (blue?)

On ttys:
links in Customize   - blue
links in Info        - blue
links in Help        - blue

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

Re: Problems with whole buffer Custom functions.

[Lennart Borgman]

Juri Linkov wrote:
> I propose to change them according to the following scheme (I'm still not
> quite sure about adding blue to links in the Help buffer):
>   
Please use underlined blue in the Help buffer too.

Re: Problems with whole buffer Custom functions.

[Juri Linkov]

>> I propose to change them according to the following scheme (I'm still not
>> quite sure about adding blue to links in the Help buffer):
>>
> Please use underlined blue in the Help buffer too.

Underlined blue links don't look nicely in link-dense buffers like
the Help buffer generated by `list-faces-display'.

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

Re: Problems with whole buffer Custom functions.

[Richard M. Stallman]

    On ttys:
    links in Customize   - blue
    links in Info        - blue
    links in Help        - blue

I am not convinced that just blue is clear enough.
I am not convinced we should get rid of the square brackets.
So I won't agree to it.

You don't seem to appreciate the fact that you are proposing a lot of
different changes at once.  If I dislike even one of them, I will say
no to the whole package.


    on graphics terminals:
    links in Customize   - underlined blue
    links in Info        - underlined blue
    links in Help        - underlined

    on xterms:
    links in Customize   - underlined blue with square brackets
    links in Info        - underlined blue
    links in Help        - underlined

I would not object to making these consistent--making them
all underlined blue, for instance.

But don't do it until we hear what others have to say!

Re: Problems with whole buffer Custom functions.

[Luc Teirlinck]

Juri Linkov wrote:

   In the patch below I've added "link" to the docstring of `custom-mode'
   to custom.texi, and fixed examples in custom.texi since links
   in customization buffer don't have square brackets anymore.

In my previous reply, I forgot to point out that custom.texi
explicitly claims to describe Custom on a text only terminal:

     The appearance of the example buffers in this section is typically
  different under a window system, since faces are then used to indicate
  buttons and editable fields.

Sincerely,

Luc.

Re: Problems with whole buffer Custom functions.

[Juri Linkov]

>      The appearance of the example buffers in this section is typically
>   different under a window system, since faces are then used to indicate
>   buttons and editable fields.

BTW, since now links in customization buffers are blue, they can be
confused with group and variable names which are blue as well.
The only difference is that links are underlined, but names are bold.

There is one comment in cus-edit.el before `defface custom-variable-tag':

  ;; When this was underlined blue, users confused it with a
  ;; Mosaic-style hyperlink...

I don't know what appearance custom-variable-tag had before,
but it still can be confused with links.

Perhaps group and variable names should have a different color than blue?

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

Re: Problems with whole buffer Custom functions.

[Juri Linkov]

> S-TAB also has its regular meaning, but the recently added M-TAB does
> not, because it has another (completion related) meaning in editable
> fields.

S-TAB is the preferable key binding, but currently it's impossible to
specify a preferable key binding in the docstring.  ASCII character
sequences are always preferred over non-ascii.

At least, S-TAB could be mentioned in the manual:

Index: man/widget.texi
===================================================================
RCS file: /sources/emacs/emacs/man/widget.texi,v
retrieving revision 1.33
diff -c -r1.33 widget.texi
*** man/widget.texi	21 Jan 2006 13:01:28 -0000	1.33
--- man/widget.texi	22 Jan 2006 00:48:57 -0000
***************
*** 316,321 ****
--- 316,322 ----
  Move point @var{count} buttons or editing fields forward.
  @end deffn
  @item @kbd{M-@key{TAB}}
+ @itemx @kbd{S-@key{TAB}}
  @deffn Command widget-backward &optional count
  Move point @var{count} buttons or editing fields backward.
  @end deffn

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

Re: Problems with whole buffer Custom functions.

[Richard M. Stallman]

    At least, S-TAB could be mentioned in the manual:

Please install that little patch.

Re: Problems with whole buffer Custom functions.

[Richard M. Stallman]

    More keys are not enabled in editable fields, for instance, `n' and `p':

I like the idea of using M-n and M-p for them.  Those keys
could be bound in the keymap used for editable fields, and then they
would work everywhere in the buffer.

    Perhaps cus-edit should bind `C-c C-c' and `C-x C-s' in a new keymap
    inheriting from widget-field-keymap.

I think that is a good idea.

Can one of you do these things?

Re: Problems with whole buffer Custom functions.

[Juri Linkov]

>     More keys are not enabled in editable fields, for instance, `n' and `p':
>
> I like the idea of using M-n and M-p for them.  Those keys
> could be bound in the keymap used for editable fields, and then they
> would work everywhere in the buffer.

I'd reserve M-n and M-p in editable fields for history navigation.
Since editable fields are very like the minibuffer where M-n and M-p
are used to navigate in the minibuffer history, it makes sense to
implement something similar for editable fields (after the release).

>     Perhaps cus-edit should bind `C-c C-c' and `C-x C-s' in a new keymap
>     inheriting from widget-field-keymap.
>
> I think that is a good idea.
>
> Can one of you do these things?

Below is a patch that implement this.

Index: lisp/cus-edit.el
===================================================================
RCS file: /sources/emacs/emacs/lisp/cus-edit.el,v
retrieving revision 1.279
diff -c -r1.279 cus-edit.el
*** lisp/cus-edit.el	19 Jan 2006 23:26:04 -0000	1.279
--- lisp/cus-edit.el	22 Jan 2006 00:43:55 -0000
***************
*** 4400,4405 ****
--- 4396,4410 ----
      ["Erase Customization" Custom-reset-standard t]
      ["Info" (info "(emacs)Easy Customization") t]))
  
+ (defvar custom-field-keymap
+   (let ((map (copy-keymap widget-field-keymap)))
+     (define-key map "\C-c\C-c" 'Custom-set)
+     (define-key map "\C-x\C-s" 'Custom-save)
+     map)
+     "Keymap used inside editable fields in customization buffers.")
+ 
+ (widget-put (get 'editable-field 'widget-type) :keymap custom-field-keymap)
+ 
  (defun Custom-goto-parent ()
    "Go to the parent group listed at the top of this buffer.
  If several parents are listed, go to the first of them."

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

Re: Problems with whole buffer Custom functions.

[Richard M. Stallman]

    I'd reserve M-n and M-p in editable fields for history navigation.

I don't think this is necessary, because there is already an undo
mechanism (the "backup value").

Instead I think it should preserve the ordinary undo list when you set
the variable.  Currently, setting the variable discards the undo list,
which is more or less a bug.

However, I now see that TAB does work for moving from an editable
field to the next button.  So we don't need M-n to do that.
We can stick with TAB as the one recommended way to do that.

    S-TAB is the preferable key binding, but currently it's impossible to
    specify a preferable key binding in the docstring.

The way to do that is to use two different command names.  Look at
`advertised-undo', for instance.  We could use that same technique to
make sure that S-TAB is what appears in a doc string.

However, arranging to present only S-TAB would have a drawback,
that it would not give any way to do this on a tty.

I find that M-TAB is bound to complete-symbol in custom buffers.  That
is not useful, so we could change it to widget-backwards.  However,
M-TAB in an editable field is bound to widget-complete, and we
certainly do not want to change that.

This means that no variant of TAB is suitable to be the universal way
to move to the previous widget, from all buffer positions, on all
terminals.  That is too bad.

Maybe we should define M-n and M-p for this, just to have a consistent
set of commands that move in both directions.

Or maybe we should settle for having S-TAB available only on graphics
terminals.

RE: Problems with whole buffer Custom functions.

[Drew Adams]

I probably shouldn't jump in here, since I haven't been following this
closely. Ignore, if my comments make little sense or are redundant.

      Juri> I'd reserve M-n and M-p in editable fields for history
navigation.
            Since editable fields are very like the minibuffer where M-n and
M-p
            are used to navigate in the minibuffer history, it makes sense
to
            implement something similar for editable fields (after the
release).

 RMS> I don't think this is necessary, because there is already an undo
      mechanism (the "backup value").

RMS: Does that provide a single backup value or an undo history of all edits
of the value (field)?

Juri: I assume you mean that there would be a separate M-n/M-p history for
each value (editable field). What would be the extent (limit) of the
proposed history list(s)? Would the limit be the current Emacs session? the
current access to Customize for that field? Or would the histories be
persistent (e.g. via savehist.el)? What would constitute an entry in such a
history list: would it be each individual edit (a la undo) or each value
that the user sets or saves (via Set for Current Session or Save...)?

    Instead I think it should preserve the ordinary undo list when you set
    the variable.  Currently, setting the variable discards the undo list,
    which is more or less a bug.

Either way would be OK for undo.

I like Juri's suggestion (IIUC) of history lists with entries that would be
the values that were set or saved (one list per option/field). Most such
lists would be empty most of the time, of course.

Given such history lists, undo would let you rewind your edits (either until
the last set or save operation or, as RMS suggests, further), while, say,
M-p would rewind the history of value settings (for that option).

Especially when complex Lisp values are concerned, one is particularly
interested in previously set values, not just in the mini changes of edits.
And undoing edit operations on previous values (from the history list) might
not be a real requirement. It's most important to be able to:

1. undo edits back to the last set or save operation, and

2. retrieve previously set or saved values.

Of course, extending undo further back wouldn't be a bad thing, but it has a
cost.

Also, are we speaking of a single, global undo for the whole buffer or an
individual undo per editable field? The latter would be preferable.

        S-TAB is the preferable key binding [for navigating backward], but
        currently it's impossible to specify a preferable key binding in the
        docstring.

    The way to do that is to use two different command names.  Look at
    `advertised-undo', for instance.  We could use that same technique to
    make sure that S-TAB is what appears in a doc string.

This question of how to control which binding appears in a doc string when
there are several has been brought up previously (probably more than once).
It's a separate problem, and one that it would be good to address in some
general fashion after the release. See, for instance, the emacs-devel thread
"Qs on key-description, substitute-command-keys" from 2005-10-15 to 16.
Stefan made a couple of alternative suggestions in that thread:

1. Have a `preferred-binding' property on a command symbol. It would contain
a preferred binding or a list of preferred bindings to be used by
`substitute-in-command-keys'.

2. Require the use of a menu item for the main binding, and then obey a
Boolean `:preferred-binding' property placed on the menu item.

    Maybe we should define M-n and M-p for this, just to have a consistent
    set of commands that move in both directions. Or maybe we should settle
    for having S-TAB available only on graphics terminals.

How about reserving M-n/M-p within an editable field for a value history
(for that field) = Juri's suggestion?

M-n/M-p outside an editable field could be used for something else, but
navigation among fields is something you often do from within a field, so
M-n/M-p probably shouldn't replace TAB/S-TAB for such navigation. (A poor
workaround would be to navigate to just before the field etc.)

For navigation, in addition to TAB/S-TAB (when available), what about
reusing the global bindings of `forward-sentence'/`backward-sentence' (M-e,
M-a) for navigation? Or those of `forward-paragraph'/`backward-paragraph'
(C-up, C-down, M-{, M-})? Those aren't particularly useful in Customize
anyway, are they? They might represent a good sacrifice, to obtain bindings
that work on ttys too (not C-up, C-down, perhaps, but I assume the others
work everywhere).

Re: Problems with whole buffer Custom functions.

[Juri Linkov]

> I assume you mean that there would be a separate M-n/M-p history for
> each value (editable field).

I meant a history mechanism like is used in modern GUI applications,
e.g. in Firefox typing M-down in an editable field opens a list of
values previously entered into the same field.  There is also Emacs-like
completion that filters out values based on the contents of the field.

> What would be the extent (limit) of the proposed history list(s)? Would
> the limit be the current Emacs session? the current access to Customize
> for that field? Or would the histories be persistent (e.g. via
> savehist.el)?

Adding a new history variable with a list (or alist with one sublist per
option/field or per widget class) of previously entered values would
automatically allow saving it with savehist.el or desktop.el.

> What would constitute an entry in such a history list: would it be each
> individual edit (a la undo) or each value that the user sets or saves
> (via Set for Current Session or Save...)?

I think preserving each value that the user sets or saves is more useful
than preserving mini changes undoable with the ordinary undo.  This would
work exactly like history lists work in the minibuffer: in the minibuffer
history list gets updated after exiting with RET, in editable fields this
could be done after activating the field.

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

RE: Problems with whole buffer Custom functions.

[Drew Adams]

    > I assume you mean that there would be a separate M-n/M-p history for
    > each value (editable field).

    I meant a history mechanism like is used in modern GUI applications,
    e.g. in Firefox typing M-down in an editable field opens a list of
    values previously entered into the same field.  There is also Emacs-like
    completion that filters out values based on the contents of the field.

Yes.  Good.

    > What would be the extent (limit) of the proposed history
    > list(s)? Would the limit be the current Emacs session? the current
    > access to Customize for that field? Or would the histories be
    > persistent (e.g. via savehist.el)?

    Adding a new history variable with a list (or alist with one sublist per
    option/field or per widget class) of previously entered values would
    automatically allow saving it with savehist.el or desktop.el.

Sounds good to me.  (I almost mentioned an alist implementation myself.)

If we did that, we might also (eventually) provide an easy way to empty
(clear) one or all of these history lists - like you can do in a Web
browser.  Not that histories of edited values pose a great threat to
privacy, but you might want to clear them out at some point so you could
more easily notice subsequent changes - that is, reset the history.

    > What would constitute an entry in such a history list: would
    > it be each individual edit (a la undo) or each value that the user
    > sets or saves (via Set for Current Session or Save...)?

    I think preserving each value that the user sets or saves is more useful
    than preserving mini changes undoable with the ordinary undo.

So do I. That's why I brought it up. However, it might still be useful to
(also) be able to incrementally undo the edits for each field (separately)
since the field's last set or save operation. That could help with editing
complex Lisp expressions, for instance.

    This would work exactly like history lists work in the minibuffer: in
the
    minibuffer, history list gets updated after exiting with RET, in
editable
    fields this could be done after activating the field.

Sounds good to me.

Re: Problems with whole buffer Custom functions.

[Juri Linkov]

> If we did that, we might also (eventually) provide an easy way to empty
> (clear) one or all of these history lists - like you can do in a Web
> browser.

Do you mean S-DEL on a value in the history list?  I already proposed
a patch to do this:

http://lists.gnu.org/archive/html/emacs-devel/2004-06/msg00937.html

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

Re: Problems with whole buffer Custom functions.

[Richard M. Stallman]

     RMS> I don't think this is necessary, because there is already an undo
	  mechanism (the "backup value").

    RMS: Does that provide a single backup value or an undo history of all edits
    of the value (field)?

It is just one value.  I think that is enough for now, but we could
extend it into a sequence.

I do not want to use editing commands to access past values.
It is better to use the State menu, since that won't get in the way.

In any case, now is not the time to add such a feature.

Re: Problems with whole buffer Custom functions.

[Juri Linkov]

>     S-TAB is the preferable key binding, but currently it's impossible to
>     specify a preferable key binding in the docstring.
>
> The way to do that is to use two different command names.  Look at
> `advertised-undo', for instance.  We could use that same technique to
> make sure that S-TAB is what appears in a doc string.
>
> However, arranging to present only S-TAB would have a drawback,
> that it would not give any way to do this on a tty.

Perhaps a better solution than adding `advertised-widget-backward'
is not to bind M-TAB on on graphics terminals at all.

> Or maybe we should settle for having S-TAB available only on graphics
> terminals.

TAB and S-TAB are standard keys to move to next/previous links in modern
GUI applications.

I think this is not a big problem that S-TAB is not available on a tty.
There was no M-TAB keybinding in Emacs for moving to the previous link for
several years until it was installed a month ago, and nobody complained
about this.

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

Re: Problems with whole buffer Custom functions.

[Richard M. Stallman]

    Perhaps a better solution than adding `advertised-widget-backward'
    is not to bind M-TAB on on graphics terminals at all.

That would not be feasible.

Re: Problems with whole buffer Custom functions.

[martin rudalics]

 > Instead I think it should preserve the ordinary undo list when you set
 > the variable.  Currently, setting the variable discards the undo list,
 > which is more or less a bug.

Undo in customization buffers is peculiar in other ways as well:

1. With emacs -Q do M-x customize-group RET paren-showing-faces RET,
show both faces, and set the background of `show-paren-match' to
"turquoise1" and the background of `show-paren-mismatch' to "purple1".
Doing C-_ twice will now get you "No further undo information" - you
can't undo the change to `show-paren-match'.

Now change the face of `show-paren-match' to "turquoise" and that of
`show-paren-mismatch' to "purple" and do C-_ twice again.  This time
both modifications are undone.  Hence whether a modification can be
undone may depend on whether this or another modification is the first
editing change for a specific option.


2. With emacs -Q do M-x customize-group RET paren-showing-faces RET,
show the `show-paren-match' face, set the background of
`show-paren-match' to "paleturquoise", and do C-_.  At this moment point
is somewhere left of the foreground color checkbox.

The reason for this is that editing also changes some magic text from
"STANDARD." to "EDITED, shown value does not take effect until you set
or save it.".  This modification is, however, not recorded in
`buffer-undo-list' and the buffer position recorded before editing
started becomes invalid with respect to the actual buffer contents.


3. With emacs -Q do M-x customize-group RET paren-showing-faces RET,
show the `show-paren-mismatch' face, set the background of
`show-paren-mismatch' to "mediumpurple4", do C-_, then C-f (to make the
next undo a redo), and C-_.  At this moment the line of the background
color reads as

              [X] Background: mediumpurple4mple)

It's a mildly amusing exercise to erase your customization buffer with
an appropriate sequence of undos and redos.  One culprit here is the
mechanism adjusting field sizes in `widget-after-change'.  On the other
hand, wid-edit uses `before-change-functions' to detect whether the user
attempts to "change text outside editable field".  The corresponding
check in `widget-before-change', however, is performed if and only if
`inhibit-read-only' is nil.  And `primitive-undo' sets this to t.  Hence
the undo / redo mechanism obtains control over non-editable parts of the
customization buffer.

Re: Problems with whole buffer Custom functions.

[Richard M. Stallman]

    Now change the face of `show-paren-match' to "turquoise" and that of
    `show-paren-mismatch' to "purple" and do C-_ twice again.  This time
    both modifications are undone.  Hence whether a modification can be
    undone may depend on whether this or another modification is the first
    editing change for a specific option.

Maybe the undo command needs to specialize to
the changes for the specific item.  Something like undo-in-region.

    The reason for this is that editing also changes some magic text from
    "STANDARD." to "EDITED, shown value does not take effect until you set
    or save it.".  This modification is, however, not recorded in
    `buffer-undo-list' and the buffer position recorded before editing
    started becomes invalid with respect to the actual buffer contents.

I guess the code that does these changes
ought to update the positions in the undo list also.

Re: Problems with whole buffer Custom functions.

[Richard M. Stallman]

    >     Perhaps cus-edit should bind `C-c C-c' and `C-x C-s' in a new keymap
    >     inheriting from widget-field-keymap.
    >
    > I think that is a good idea.
    >
    > Can one of you do these things?

    Below is a patch that implement this.

Please install your patch.

Re: Problems with whole buffer Custom functions.

[LENNART BORGMAN]

From: Juri Linkov <juri@jurta.org>

> >> I propose to change them according to the following scheme (I'm 
> still not
> >> quite sure about adding blue to links in the Help buffer):
> >>
> > Please use underlined blue in the Help buffer too.
> 
> Underlined blue links don't look nicely in link-dense buffers like
> the Help buffer generated by `list-faces-display'.

I might agree with that, but I think useability is much more important. We are not trying to attract customers with a web page here.