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

[Drew Adams <drew.adams@oracle.com>]

> tags 29599 + patch
> quit
> 
> Drew Adams <drew.adams@oracle.com> writes:
> 
> >> 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?
> 
> Yes, see Bug#28607.

That's quite a bug report - no report at all (?).

Perhaps it was because all of the actual report was
in another bug report that was closed, and that now
redirects to this (vacuous) report?

The only thing in #28607 is a link to an emacs-devel
thread.  No description of the problem (?).

Anyway, it's not clear to me how that bug relates to this one.

This one is about explicitly binding keys when the
source code loads.  I don't get the impression that
that one is about this at all.  (What am I missing?)

> > 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).
> 
> As far as I can tell, there is no code in Emacs which sets those
> functions to anything.  So presumably the idea is to allow the user to
> run some code when a "dframe" is made visible/iconified/deleted.

No doubt.  But (I think we agree?) that possibility
should be offered to users, to choose, and not imposed
just by loading the file.

> >> 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.
> 
> Okay, it should take care of this bug, and it should be perfectly safe,
> since the functions do nothing before dframe-frame-mode is activated
> anyway.  I'll push to emacs-26 in a few days if there are no objections.

Thanks.