From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: keypad-*-setup Date: Tue, 18 Sep 2007 08:11:24 -0700 Message-ID: References: <87ps0gtb2p.fsf@kfs-lx.testafd.dk> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1190128369 26202 80.91.229.12 (18 Sep 2007 15:12:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 18 Sep 2007 15:12:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: "Kim F. Storm" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 18 17:12:38 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IXekF-00066i-OC for ged-emacs-devel@m.gmane.org; Tue, 18 Sep 2007 17:12:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IXekD-0002fX-St for ged-emacs-devel@m.gmane.org; Tue, 18 Sep 2007 11:12:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IXekA-0002eM-4j for emacs-devel@gnu.org; Tue, 18 Sep 2007 11:12:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IXek9-0002db-Gy for emacs-devel@gnu.org; Tue, 18 Sep 2007 11:12:05 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IXek9-0002dY-BV for emacs-devel@gnu.org; Tue, 18 Sep 2007 11:12:05 -0400 Original-Received: from rgminet01.oracle.com ([148.87.113.118]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IXek8-0008Ja-5D for emacs-devel@gnu.org; Tue, 18 Sep 2007 11:12:05 -0400 Original-Received: from agmgw1.us.oracle.com (agmgw1.us.oracle.com [152.68.180.212]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l8IFBo6g026416; Tue, 18 Sep 2007 09:11:50 -0600 Original-Received: from acsmt351.oracle.com (acsmt351.oracle.com [141.146.40.151]) by agmgw1.us.oracle.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id l8IFBml3009463; Tue, 18 Sep 2007 09:11:49 -0600 Original-Received: from dhcp-amer-csvpn-gw1-141-144-65-85.vpn.oracle.com by acsmt351.oracle.com with ESMTP id 3222969611190128283; Tue, 18 Sep 2007 08:11:23 -0700 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <87ps0gtb2p.fsf@kfs-lx.testafd.dk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Importance: Normal X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE X-Detected-Kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:79203 Archived-At: > >> > 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 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.