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: `this-command-keys-vector', prefix keys, and Customize Date: Fri, 7 Feb 2014 14:31:40 -0800 (PST) Message-ID: <1e92962b-bb8c-42f7-92ab-ec18b183edcd@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1391812317 12607 80.91.229.3 (7 Feb 2014 22:31:57 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 7 Feb 2014 22:31:57 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 07 23:32:04 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WBtxs-0004di-G4 for ged-emacs-devel@m.gmane.org; Fri, 07 Feb 2014 23:32:04 +0100 Original-Received: from localhost ([::1]:44088 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBtxs-0003P2-40 for ged-emacs-devel@m.gmane.org; Fri, 07 Feb 2014 17:32:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42062) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBtxi-0003O2-2O for emacs-devel@gnu.org; Fri, 07 Feb 2014 17:32:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WBtxZ-0000Vu-1T for emacs-devel@gnu.org; Fri, 07 Feb 2014 17:31:54 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:29423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WBtxY-0000Uo-QZ for emacs-devel@gnu.org; Fri, 07 Feb 2014 17:31:44 -0500 Original-Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s17MVg9q031346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 7 Feb 2014 22:31:43 GMT Original-Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s17MVfdg021786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 7 Feb 2014 22:31:42 GMT Original-Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s17MVfaj020463 for ; Fri, 7 Feb 2014 22:31:41 GMT X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8 (707110) [OL 12.0.6680.5000 (x86)] X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169475 Archived-At: Consider this: (global-set-key [menu-bar edit foo] '("Foo" . foo-cmd)) Then, choosing `Edit > Foo' from the menu bar results in this value for `(this-command-keys-vector)': [(menu-bar) edit foo] I don't find the parenthesized form `(menu-bar)' documented anywhere. Is it really correct? In a sense it obviously is, since Emacs apparently works that way. And someone will no doubt reply that it is internal, so it can be anything Emacs Dev wants it to be. Maybe. But we document the form of keys and keymaps, and users should be able to know what the form is (or all possible forms are) in such a case, and count on that. Either that or provide functions (an API) that abstract from the actual form and let you construct and manipulate its components etc. Now consider this, as a way of letting users define a key sequence to be used as a prefix key and tested against existing prefix keys: (defcustom pref-key [] "doc..." :type '(key-sequence :tag "Prefix Key" :value [])) Now how can a user customize that, to match the actual prefix key returned as the first part of [(menu-bar) edit foo]? S?he can enter in the Customize edit field. But that gives [menu-bar edit], not [(menu-bar) edit]. How can code test a value such as [menu-bar edit] against the prefix part of what `this-command-keys-vector' returns, which is [(menu-bar) edit]? Is there a bug in `this-command-keys-vector', so that it should in fact return [menu-bar edit foo] here, not [(menu-bar) edit foo]? Or is there a problem with Customize, so that it should return [(menu-bar) edit] for the input ? Or is there some function `same-key' that handles all such forms of keys, testing for equivalence, so that instead of (equal ACTUAL-PREFIX OPTION-PREFIX), i.e., in this case (equal [(menu-bar) edit] [menu-bar edit]) ^^^^^actual^^^^^^ ^^^^option^^^^^ I could test (same-key ACTUAL-PREFIX OPTION-PREFIX)? If not, and I need to roll my own such test function, what are the possible forms of a prefix key as a vector? Is it enough to wrap any non-list elements of ACTUAL-PREFIX and OPTION-PREFIX with #'list, so, in effect, the comparison here becomes: (equal [(menu-bar) (edit)] [(menu-bar) (edit)])? Or to unwrap any list elements, so it becomes: (equal [menu-bar edit] [menu-bar edit])? What's the right way, or a good way, to go about this? I want to test an actual prefix key, obtained as part of `this-command-keys-vector', against a prefix key chosen by the user as an option value. Thanks for any help. Perhaps this is all clearly documented somewhere, the coding is trivial, and I just haven't come across it yet. That's my hope anyway.