RE: keypad-*-setup

[Drew Adams]

> >> > 1. A nil ("No change (keep existing bindings)") value for the
> >> > setup options seems to be a no-op.... Am I reading this wrong?
> >>
> >> I don't really remember why I included that choice.
> >> Most likely it was a way to specify "use default bindings or whatever
> >> the user has changed them to".
> >
> > Do you agree that it is a no-op, and can be removed (or am I missing
> > something)?
>
> What if user has once customized one of the keypad setups, and later
> wants to revert to the "default setting" ... then there need to be a
> setting which corresponds to that setting.
>
> So I don't think it is a no-op.  But this may be one of the things I
> don't understand about Customize :-)

I don't think that's what this does at all. But, as you said, "this may be
one of the things I [Drew] don't understand about Customize :-)" ;-)

IOW, you might be right and I am reading the code wrong. I also tried it,
however, and it did not seem to restore any default value. AFAICT, it does
nothing.

Perhaps someone who understands Customize better can speak to this? I think
we agree, at least, that _if_ it turns out that this is a no-op then we can
remove this value of the options. Or, better yet, if I'm right that it does
nothing, perhaps someone can correct it so that it in fact restores the
default value.

> > OK. Then I suggest that we remove the `numeric' choice. Even if
> > someone did implement what you suggest someday, that could be
> > done by providing the "right" default value for the explicit
> > decimal-point character (which the
> > user could choose to override or not). Do you agree?
>
> What about users who already has set keypad binding to numeric ?

Keypad is new with Emacs 22.1. I don't think many users will be impacted.
And it's not like we would be taking away any functionality - they would
simply change the value from `numeric' to `.' to get the same effect.

This is not a biggee, so please do as you like here.

I personally think it's better to move in the direction of a simpler UI (no
redundant options that are hard to understand) and simpler code - at the
possible cost of a few users updating their custom value for this. But this
is not very important either way.

> > Perhaps whoever is finalizing this patch for CVS etc. can try
> > that. I think it should be correct.
>
> I think everybody expected you to finalize the patch :-)

I already spoke to that. I don't mind sending a patch for keypad.el, once
people agree on what is needed. And I can prepare a changelog entry. But I
don't want to mess with the texinfo - someone else can adapt the plain text
I sent.

> But if you make another revision of the patch, I'll take a look at
> finalizing it.

I'm OK with whatever changes you want. Go for it. My main objection was the
unclear text (including Lisp commentary and doc strings), and I think we're
clearing that up now.

> > The difficulty I saw was that the previous manual section,
> > Function Keys, speaks of keys such as <kp-divide> as "keypad"
> > keys, but keypad.el is not concerned with those. There are
> > two different uses of the word "keypad" in
> > the manual, one refers to all keys with prefix `kp-'; the other
> > refers only to the 11 numeric keys 0-9 and `.'.
>
> Those extra keys are not affected by the state of the numlock key.

But users don't know that unless we say it. The notion of "keypad" is not a
clear one, referring both to all `kp-' keys and to a physical pad somewhere
on a keyboard (and whose set of keys can vary). And especially since our doc
refers to both of these, we need to distinguish which we mean in the
different contexts.

> That's also why I prefer to say "numeric keypad" rather than keypad.
> Perhaps the package should have been called numlock.el, numpad.el or
> some such.  But I guess that's too late now.

I agree. It's OK to repeat "numeric keypad" each time, instead of trying to
shorten it to "keypad" as I did here, but I think we still need to address
the possible source of confusion.

When people read doc, they don't necessarily pick it apart carefully like
lawyers or logicians. I agree that the text for this point could be
shortened, but I think we should say at least something to clear up or
prevent possible confusion about `kp-' vs the (numeric keypad) subset of the
`kp-' keys that this library affects.

> > There needs, I think, to be some explanation of the terminology to avoid
> > confusion - the reader of the previous manual section will otherwise
> > misunderstand what is said in this section. Feel free to
> > propose something shorter to make this point.
>
> I think you made a good attempt at explaining it - saying that it
> applies only to 0..9 and decimal/del key.  To remove the possible
> confusion one could just say:
>
> "The other keypad keys (such as kp-divide) are not affected by the
> keypad customizations described here".

That's probably good enough. But here too, when you say "other keypad keys"
in a context where we have been speaking (so far) only about "numeric
keypad" keys, a reader might not realize that in this case "keypad" keys
refers to all keys that have `kp-' as a prefix.

Anyway, yes, that is good enough.

> >> The Shift key and the NumLock key modify the behavior of keys on the
> >> numeric keypad.  The Shift key acts as usual.  The NumLock key toggles
> >> the keypad keys between two possible modes: numeric and non-numeric.
> >
> > Sounds good to me.
>
> Ok.

Thx.