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