bug#29599: 26.0; `dframe.el' binds keys unconditionally when loaded

[Drew Adams]

> > 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.
> 
> Yeah (it's probably the loading-on-completion thing again).

I don't think I know (or didn't know or at least don't
recall) anything about such a thing.  Is it something new?

> > 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?
> 
> The root problem is that there is no easy way to share the bindings.

Dunno what you mean by that ("share the bindings").
But maybe if I knew what "loading-on-completion" is
then I would understand "share the bindings" (?).

> I think those keys should be bound to a function which calls runs a hook,
> like focus-in and focus-out events are.

Maybe so, but then the question would be whether and why
dframe.el (or anything else) would initialize the hook
to have one or more functions on it.

In my case, I'm pretty sure I don't want anything other
than my replacement for iconification to be on the hook.
So I would probably empty the hook before using `add-hook'
for my function.  Maybe that's only out of ignorance of
what the deframe functions are for or do.

> Actually, it sort of looks like
> dframe is trying to install such a hook; the functions it puts don't do
> anything except call `dframe-make-frame-{visible,iconify,delete}-
> function'.

But (without looking at them), those sound like specific
replacements for the standard iconify etc.  If so, it's
great to provide such functions, but they shouldn't be
bound to special events by default (i.e., upon loading).

> Anyway, at a minimum, we can't have keybindings being modified by just a
> load.

Yes, thank you.

> Here's a patch which moves the keybinding to dframe-frame-mode
> activation instead.

I can't speak to the value of the patch (I know nothing
about this), but thanks for working on this.