[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29599: 26.0; `dframe.el' binds keys unconditionally when loaded
From: |
Drew Adams |
Subject: |
bug#29599: 26.0; `dframe.el' binds keys unconditionally when loaded |
Date: |
Wed, 6 Dec 2017 22:10:52 -0800 (PST) |
Well, not completely unconditionally. But I see this:
(if (boundp 'special-event-map)
(progn
(define-key special-event-map [make-frame-visible]
'dframe-handle-make-frame-visible)
(define-key special-event-map [iconify-frame]
'dframe-handle-iconify-frame)
(define-key special-event-map [delete-frame]
'dframe-handle-delete-frame))
)
That condition that the map exists isn't, I think, sufficient to give it
license to bind keys in the map.
I must have done something after my init file was loaded that required
`dframe.elc' to be loaded, and that load overwrote bindings I made in my
init file.
I don't know what I did that caused dframe to be loaded, but that
shouldn't matter. I don't think it should overwrite key bindings
just by being loaded.
In my init file I do this (after loading library `thumb-frm.el', which
defines `thumfr-thumbify-frame-upon-event'):
(when (and (eq system-type 'windows-nt)
(fboundp 'thumfr-thumbify-frame-upon-event))
(define-key special-event-map [iconify-frame]
'thumfr-thumbify-frame-upon-event))
But dframe.el overwrites that binding when it gets loaded.
Shouldn't dframe.el bind its own commands to `special-event-map' keys
only if those keys are not already bound?
I don't know what it's doing or why, but this doesn't seem very polite
of it. Why should it think that just by being loaded it should
(re-)bind keys?
In GNU Emacs 26.0.90 (build 3, x86_64-w64-mingw32)
of 2017-10-13
Repository revision: 906224eba147bdfc0514090064e8e8f53160f1d4
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --without-dbus --host=x86_64-w64-mingw32
--without-compress-install 'CFLAGS=-O2 -static -g3''
- bug#29599: 26.0; `dframe.el' binds keys unconditionally when loaded,
Drew Adams <=