From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daimrod Newsgroups: gmane.emacs.help Subject: Re: view-mode keymap Date: Thu, 03 Jan 2013 13:21:07 +0100 Organization: les newsgroups par Orange Message-ID: <87sj6ifoek.fsf@casa.home> References: <87sj6mi7p5.fsf@casa.home> <87sj6j8y1q.fsf@casa.home> <87y5gafrnt.fsf@casa.home> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1357216212 27855 80.91.229.3 (3 Jan 2013 12:30:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 3 Jan 2013 12:30:12 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Jan 03 13:30:29 2013 Return-path: Envelope-to: geh-help-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 1TqjwJ-0004je-Pb for geh-help-gnu-emacs@m.gmane.org; Thu, 03 Jan 2013 13:30:27 +0100 Original-Received: from localhost ([::1]:34601 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tqjw4-0007U6-Lr for geh-help-gnu-emacs@m.gmane.org; Thu, 03 Jan 2013 07:30:12 -0500 X-Received: by 10.180.100.74 with SMTP id ew10mr11332163wib.7.1357216102427; Thu, 03 Jan 2013 04:28:22 -0800 (PST) Original-Path: usenet.stanford.edu!m3no4875052wim.1!news-out.google.com!i11ni349479wiw.0!nntp.google.com!proxad.net!feeder1-2.proxad.net!193.252.117.184.MISMATCH!feeder.news.orange.fr!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:2HRFV23ICrasiKXZxACtB269ejI= Original-Lines: 97 Original-NNTP-Posting-Date: 03 Jan 2013 13:28:22 CET Original-NNTP-Posting-Host: 109.211.53.138 Original-X-Trace: 1357216102 reader.news.orange.fr 1220 109.211.53.138:14147 Original-X-Complaints-To: abuse@orange.fr Original-Xref: usenet.stanford.edu gnu.emacs.help:196094 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 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 Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:88403 Archived-At: Daimrod writes: > Jambunathan K writes: > >> Daimrod writes: >> >>> Jambunathan K writes: >>> >>>> I think, `make-composed-keymap' can help here. >>>> >>>> >>>>> I like `view-mode' but it conflicts with others minor mode map (paredit >>>>> in my case). >>>>> >>>>> I would like to know if there is a better way to make a keymap that >>>>> takes precedence over the others than manipulating >>>>> `minor-mode-map-alist'. >>>>> >>>>> Here is my current implementation: >>>>> >>>>> (add-hook 'view-mode-hook >>>>> (lambda () >>>>> ;; Makes sure `view-mode-map' is the first minor mode map >>>>> ;; available in `minor-mode-map-alist', because in case of >>>>> ;; conflicting bindings, the first one is used. >>>>> (unless (eq 'view-mode (caar minor-mode-map-alist)) >>>>> (setf minor-mode-map-alist >>>>> (cons (cons 'view-mode view-mode-map) >>>>> (cl-remove 'view-mode minor-mode-map-alist >>>>> :key #'car)))))) >>> >>> I've looked at it but I don't see how it can help. I don't want to >>> create a new keymap, I want `view-mode-map' to take priority over other >>> keymaps. >> >> I was hoping that something like this >> >> (use-local-map >> (make-composed-keymap view-mode-map >> (current-local-map))) >> >> will put `view-mode-map' on top of the keymap stack and thus overwrite >> paredit's bindings. >> >> I see that DEL (backspace) key is shared between view-mode and paredit. >> My little experimentation that the above snippet failst to produce the >> effect expected by me. >> >> Do you think I am reading the doc of the APIs (used above) incorrectly? > > No, the problem is not the way you're building the keymap, but how > keymaps are searched. > > From (info "(elisp) Searching Keymaps") >> (or (cond >> (overriding-terminal-local-map >> (FIND-IN overriding-terminal-local-map)) >> (overriding-local-map >> (FIND-IN overriding-local-map)) >> ((or (FIND-IN (get-char-property (point) 'keymap)) >> (FIND-IN TEMP-MAP) >> (FIND-IN-ANY emulation-mode-map-alists) >> (FIND-IN-ANY minor-mode-overriding-map-alist) >> (FIND-IN-ANY minor-mode-map-alist) >> (if (get-text-property (point) 'local-map) >> (FIND-IN (get-char-property (point) 'local-map)) >> (FIND-IN (current-local-map)))))) >> (FIND-IN (current-global-map))) > > It searches through `minor-mode-map-alist' _before_ looking at > `current-local-map'. > > I could use `overriding-local-map' instead of `current-local-map' if it > was a buffer local variable. But it's not, and I'm afraid that making it > buffer local might break things in a weird way. However I've just noticed that I can use `minor-mode-overriding-map-alist' instead of `minor-mode-map-alist'. So now my code is: (add-hook 'view-mode-hook (lambda () ;; In `view-mode', `view-mode-map' overrides other minor ;; mode maps. (pushnew (cons 'view-mode view-mode-map) minor-mode-overriding-map-alist :key #'car))) A bit more cleaner :) >>> I've looked at the documentation and it seems that changing the order in >>> `minor-mode-map-alist' is the only way to manage priorities between >>> keymap, because they shouldn't conflict in there first place. -- Daimrod/Greg