From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "David Vanderschel" Newsgroups: gmane.emacs.help Subject: Re: elisp mouse programming problems Date: Thu, 21 Aug 2003 01:46:41 GMT Organization: Road Runner - Texas Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <5wV0b.2124$pW3.242047@twister.austin.rr.com> References: <873cfwvcqp.fsf@emacswiki.org> NNTP-Posting-Host: deer.gmane.org X-Trace: sea.gmane.org 1061431610 1171 80.91.224.253 (21 Aug 2003 02:06:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 21 Aug 2003 02:06:50 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Aug 21 04:06:49 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19peqe-0005ZH-00 for ; Thu, 21 Aug 2003 04:06:48 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19penv-0008Gn-I1 for geh-help-gnu-emacs@m.gmane.org; Wed, 20 Aug 2003 22:03:59 -0400 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!headwall.stanford.edu!newshub.sdsu.edu!elnk-nf2-pas!elnk-pas-nf1!newsfeed.earthlink.net!cyclone.socal.rr.com!news-west.rr.com!news.rr.com!cyclone.austin.rr.com!twister.austin.rr.com.POSTED!53ab2750!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 75 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Original-NNTP-Posting-Host: 66.69.227.127 Original-X-Complaints-To: abuse@rr.com Original-X-Trace: twister.austin.rr.com 1061430401 66.69.227.127 (Wed, 20 Aug 2003 20:46:41 CDT) Original-NNTP-Posting-Date: Wed, 20 Aug 2003 20:46:41 CDT Original-Xref: shelby.stanford.edu gnu.emacs.help:116033 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:11943 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:11943 "Alex Schroeder" wrote in message news:873cfwvcqp.fsf@emacswiki.org... > "David Vanderschel" writes: > > I am having a problem with overriding the global > > map ... > One mouse click will generate not only the mouse > click event, but also a button-down event. And if > somebody binds a command to the button-down event, > then the command bound to the click event is never > called. That is new information for me, but I do not think that this would not explain why I cannot override drag-mouse-2. My whole problem is that only certain bindings fail, and I can't see the difference. In one failure case, we are talking about C-down-mouse-1. So I have tried to experiment more with that. When I look in my new mode-map, I see the pair: (C-down-mouse-1 . dv-test1) When I do C-h c for C-down-mouse-1, I still get: C-down-mouse-1 at that spot runs the command msb My own major mode mode-map was definitely in effect (for other things I bound specially) in the buffer in which I tried that. > > Also, in testing such things, I am confused by the > > fact that I cannot seem to redefine the bindings of a > > mode-map by simply setting it to nil and rerunning the > > (modified) code which builds the mode-map. ... > A keymap is a list that starts with the symbol `keymap'. >Only the cdr of that list is used by Emacs when >looking up keys. When you just change the value of a >mode-map, the old cdr will still be used. (Maybe you >need to draw box diagrams to see this.) When I said "setting it to nil" I was talking about the pointer to the list (Hube-mode-map, in my case). Thus regenerating that list should also generate a new cdr. If emacs still has a pointer to the old cdr, I need to know how to get emacs to give it up. What makes it adopt the cdr in the first place? I think I have now figured this one out. Changing the mode-map itself is not sufficient. You must again invoke (use-local-map whatever-mode-map). (I had erroneously believed that what emacs remembered was my variable which held the pointer to the mode-map and that it would use the new map when I changed it. But there is no quote on the argument, so it cannot know. I now recall running into another manifestation of this. emacs will readily show you the current mode-map, but it is difficult to discover the 'name' of that map - ie., the variable used to create it.) > The correct solution depends on where the bindings > are: Global map? Local map? Overlays? Text > properties? The case I am concerned with occurs when the bindings are in the major mode mode-map which I am working on now. Thanks, David V.