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: Mon, 17 Sep 2007 15:30:09 -0700 Message-ID: References: <87wsupq77a.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 1190068380 15113 80.91.229.12 (17 Sep 2007 22:33:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 17 Sep 2007 22:33:00 +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 00:32:57 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 1IXP9E-0003Dq-Lc for ged-emacs-devel@m.gmane.org; Tue, 18 Sep 2007 00:32:57 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IXP9D-0001F3-Be for ged-emacs-devel@m.gmane.org; Mon, 17 Sep 2007 18:32:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IXP7O-0008Pl-0G for emacs-devel@gnu.org; Mon, 17 Sep 2007 18:31:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IXP7M-0008OD-T4 for emacs-devel@gnu.org; Mon, 17 Sep 2007 18:31:01 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IXP7M-0008Nm-4q for emacs-devel@gnu.org; Mon, 17 Sep 2007 18:31:00 -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 1IXP7L-0001m3-ME for emacs-devel@gnu.org; Mon, 17 Sep 2007 18:30:59 -0400 Original-Received: from rgmgw2.us.oracle.com (rgmgw2.us.oracle.com [138.1.186.111]) by rgminet01.oracle.com (Switch-3.2.4/Switch-3.1.6) with ESMTP id l8HMUcIr028585; Mon, 17 Sep 2007 16:30:39 -0600 Original-Received: from acsmt350.oracle.com (acsmt350.oracle.com [141.146.40.150]) by rgmgw2.us.oracle.com (Switch-3.2.4/Switch-3.2.4) with ESMTP id l8HMUZE5002898; Mon, 17 Sep 2007 16:30:38 -0600 Original-Received: from dhcp-4op11-4op12-west-130-35-178-158.us.oracle.com by acsmt350.oracle.com with ESMTP id 3219539151190068206; Mon, 17 Sep 2007 15:30:06 -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: <87wsupq77a.fsf@kfs-lx.testafd.dk> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 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:79144 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)? > > 2. Do we really need a separate `numeric' choice? Why not > > always specify an explicit decimal-point? That is, why not get > > rid of the value `numeric' ... and just use the version that > > specifies a decimal-point character - it uses `.' as the default value, > > which is the same as choosing the option value `numeric'. > > IIRC, the intention was to _somehow_ find the proper decimal point > character from the language/regional environment settings. > I probably didn't finish it because I don't know how to do that. 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? > > 3. Shouldn't `integerp' be `char-valid-p' in the test for the > > value? :match (lambda (widget value) (integerp value)). In function > > `keypad-setup', `char-valid-p' is used to test the character. > > That sounds right - but I don't remember. Perhaps whoever is finalizing this patch for CVS etc. can try that. I think it should be correct. > In general I think your descriptions are very good, but OTOH I also > think that some of the text is too verbose and elaborates too much on > some of the trivial issues. Feel free to propose specific reductions (as you did below). > > Other keys that might be physically nearby, such as the keypad PF keys > > (e.g. `') and the keys labeled `/', `*', `-', `+', and `Enter', > > are not considered part of the keypad, as the term is understood here. > ^numeric > > > This means that only some of the keys with names starting with `kp-' > > are considered "keypad" keys in this section. For example, the nearby > > key labeled `/' is often named `', but it is not a numeric > > keypad key. Be aware that in some other contexts any key whose Emacs > > name starts with `kp-' might be considered a "keypad" key. See, for > > instance, (elisp) "Function Keys". > > This is true, but formally it doesn't add any information that the > previous section didn't say implicitly - so it could be removed. Again, feel free to remove anything. 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 `.'. 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. > > 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 is > > usually near the keypad keys. It acts similarly to the Caps Lock key, > > but instead of toggling between uppercase and lowercase for the main > > keyboard it toggles the keypad keys between two possible modes: > > numeric and non-numeric. Like the Caps Lock key, and unlike the Shift > > key, NumLock is modal: hitting it once enters a mode that stays active > > until you hit it again to change the mode. NumLock is not a modifier > > key: you do not hold it down while hitting other keys. > > I think most users will know that NumLock is modal - and that you > don't have to hold it down - so this section could be more terse. > > E.g. something like this should be sufficient IMO: > > 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. Thx - Drew