From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Phil Sainty Newsgroups: gmane.emacs.bugs Subject: bug#16312: 24.3.50; Docstring fix for `set-transient-map' (and tangents...) Date: Wed, 01 Jan 2014 16:09:46 +1300 Message-ID: <52C386FA.6040709@orcon.net.nz> References: <55769.202.78.240.7.1388455781.squirrel@mail.orcon.net.nz> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1388545882 29553 80.91.229.3 (1 Jan 2014 03:11:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 1 Jan 2014 03:11:22 +0000 (UTC) To: 16312@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jan 01 04:11:27 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1VyCDN-00017u-87 for geb-bug-gnu-emacs@m.gmane.org; Wed, 01 Jan 2014 04:11:25 +0100 Original-Received: from localhost ([::1]:36249 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VyCDM-0006se-Q4 for geb-bug-gnu-emacs@m.gmane.org; Tue, 31 Dec 2013 22:11:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53621) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VyCDA-0006sV-Oq for bug-gnu-emacs@gnu.org; Tue, 31 Dec 2013 22:11:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VyCD0-0003h0-SH for bug-gnu-emacs@gnu.org; Tue, 31 Dec 2013 22:11:12 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41353) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VyCD0-0003gr-Ob for bug-gnu-emacs@gnu.org; Tue, 31 Dec 2013 22:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VyCD0-0002b3-Ex for bug-gnu-emacs@gnu.org; Tue, 31 Dec 2013 22:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Phil Sainty Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Jan 2014 03:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 16312 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.13885458339936 (code B ref -1); Wed, 01 Jan 2014 03:11:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 1 Jan 2014 03:10:33 +0000 Original-Received: from localhost ([127.0.0.1]:55372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VyCCW-0002aB-0y for submit@debbugs.gnu.org; Tue, 31 Dec 2013 22:10:32 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:51645) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VyCCS-0002a2-In for submit@debbugs.gnu.org; Tue, 31 Dec 2013 22:10:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VyCCD-0003X4-Gm for submit@debbugs.gnu.org; Tue, 31 Dec 2013 22:10:28 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:55050) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VyCCD-0003Wu-Dg for submit@debbugs.gnu.org; Tue, 31 Dec 2013 22:10:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53291) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VyCC3-0006gb-Tf for bug-gnu-emacs@gnu.org; Tue, 31 Dec 2013 22:10:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VyCBv-0003EG-P1 for bug-gnu-emacs@gnu.org; Tue, 31 Dec 2013 22:10:03 -0500 Original-Received: from nctlincom01.orcon.net.nz ([60.234.4.69]:47424) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VyCBv-0003D0-7p for bug-gnu-emacs@gnu.org; Tue, 31 Dec 2013 22:09:55 -0500 Original-Received: from mx4.orcon.net.nz (mx4.orcon.net.nz [219.88.242.54]) by nctlincom01.orcon.net.nz (8.14.3/8.14.3/Debian-9.4) with ESMTP id s013NEI8020503 for ; Wed, 1 Jan 2014 16:23:14 +1300 Original-Received: from Debian-exim by mx4.orcon.net.nz with local (Exim 4.69) (envelope-from ) id 1VyCBp-0002Ue-Rf for bug-gnu-emacs@gnu.org; Wed, 01 Jan 2014 16:09:49 +1300 Original-Received: from [121.99.80.47] (helo=[10.1.1.3]) by mx4.orcon.net.nz with esmtpa (Exim 4.69) (envelope-from ) id 1VyCBp-0002UU-Me for bug-gnu-emacs@gnu.org; Wed, 01 Jan 2014 16:09:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <55769.202.78.240.7.1388455781.squirrel@mail.orcon.net.nz> X-Forwarded-Message-Id: <55769.202.78.240.7.1388455781.squirrel@mail.orcon.net.nz> X-DSPAM-Check: by mx4.orcon.net.nz on Wed, 01 Jan 2014 16:09:49 +1300 X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Jan 1 16:09:49 2014 X-DSPAM-Confidence: 0.5403 X-DSPAM-Probability: 0.0000 X-Bayes-Prob: 0.3577 (Score 0, tokens from: @@RPTN, default) X-CanIt-Geo: ip=121.99.80.47; country=NZ; region=E7; city=Auckland; latitude=-36.8667; longitude=174.7667; http://maps.google.com/maps?q=-36.8667,174.7667&z=6 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 06L8rneFz - 58e0e5744ab7 - 20140101 X-Scanned-By: CanIt (www . roaringpenguin . com) on 172.16.100.174 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:82793 Archived-At: The docstring for `set-transient-map' states: > Note that MAP will take precedence over the \"overriding\" maps > `overriding-terminal-local-map' and `overriding-local-map' (and > over the `keymap' text property). Unlike those maps, if no match > for a key is found in MAP, Emacs continues the normal key lookup > sequence. The NEWS file suggests that this info is now incorrect for the former of those two: > * Incompatible Lisp Changes in Emacs 24.4 > > ** `overriding-terminal-local-map' no longer replaces the local keymaps. > It used to disable the minor mode, major mode, and text-property keymaps, > whereas now it simply has higher precedence. So perhaps that docstring paragraph should now simply read: "Note that MAP will take precedence over the \"overriding\" maps `overriding-terminal-local-map' and `overriding-local-map' (and over the `keymap' text property). If no match for a key is found in MAP, Emacs continues the normal key lookup sequence." I also see the phrase "the keymap char property" in the docstring for `overriding-local-map'. Should that read "the keymap text property"? Or is this because there's a keymap Overlay property as well, and the `get-char-property' function checks them both? (This seems likely, but might imply that the reference to "the `keymap' text property" in set-transient-map is insufficient, iff that also needs to cover overlay properties?) I'm afraid I'm not very familiar with text properties and overlays, so I'm not sure which is the preferred term here. I would imagine that this issue (with two types of 'keymap' properties) might crop up in a number of places, so perhaps there's already an agreed way of describing it for documentation purposes? I suspect this would be less confusing were it not for the info node "(elisp) Character Properties" which is unconnected to `get-char-property' (instead we have `get-char-code-property' to obtain these "Character Properties". It seems to me that this is mostly an unfortunate naming clash with a standard Unicode term, but as such the info nodes could probably benefit from some up-front clarifications to make the distinction between the two types of "char property" and associated function naming schemes clear from the outset? Perhaps the "Character Properties" node should even be renamed to "Character Code Properties" to better align with the function names? This concept in Emacs sounds as if it's a super-set of the Unicode Character Property Model, so it possibly doesn't *need* to have that exact name?