bug#10289: 24.0.92; Sneaky clobbering of user key binding

bug#10289: 24.0.92; Sneaky clobbering of user key binding

[Stephen Berman]

I was reading gnu-emacs-help with Gnus, and one of the articles included
a MIME part of type "text/x-org", which results in org-mode being
called, which loads a slew of org libraries.  Some time later I went to
the Calendar and typed `k', which is unbound in the default Calendar and
Diary mode maps, but which I have bound to a command I defined.
However, this time my command wasn't called, but instead
org-agenda-action.  This is due to the defcustom
org-calendar-agenda-action-key in org.el, which is set to `k' by default
and was enabled when I read the article with the text/x-org MIME part.

I think it's a bug to clobber a user setting in this sneaky way: I don't
use Org, so I didn't know about this binding or the defcustom that sets
it.  But even if I did know, it seems rather nasty to be forced to set a
variable to avoid clobbering a setting I had no reason to expect to be
problematic.

I think the best solution to this problem from the user's POV would be
to prevent the processing of a MIME part from effecting other buffers,
perhaps by unloading the libraries after the processing (unless they
were already loaded before the article was opened); or would that
throttle Emacs too much?  If so, a less desirable solution could be for
defcustoms like org-calendar-agenda-action-key to check whether the key
is bound and in that case require (as nonintrusively as possible) user
intervention.


In GNU Emacs 24.0.92.2 (i686-suse-linux-gnu, GTK+ Version 2.24.7)
 of 2011-12-05 on escher
Windowing system distributor `The X.Org Foundation', version 11.0.11004000
configured using `configure  '--without-toolkit-scroll-bars' 'CFLAGS=-g''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

bug#10289: 24.0.92; Sneaky clobbering of user key binding

[Stefan Monnier]

> I think it's a bug to clobber a user setting in this sneaky way: I don't

Agreed.

> I think the best solution to this problem from the user's POV would be

There indeed various ways to solve this problem.  One convention which
Emacs mandates (but doesn't enforce, obviously) is that loading a file
should not have any other (visible) side effect than providing new
behavior (e.g. defining new commands and variables) without affecting
existing behavior.

Obviously it's a fuzzy convention, but from this point of view, the
problem is that loading Org (well, one of its files) changed the
calendar keymap.

> perhaps by unloading the libraries after the processing (unless they

That's pretty much impossible to do reliably given the way Elisp works
right now (it's not sufficiently declarative for that).

> throttle Emacs too much?  If so, a less desirable solution could be for
> defcustoms like org-calendar-agenda-action-key to check whether the key
> is bound and in that case require (as nonintrusively as possible) user
> intervention.

I think a good solution should be along these lines: only add the `k'
binding if the `k' key is currently "unbound" (or more generally does
nothing more than signal an error, since `k' is probably bound to
something like `undefined').  Of course, this care should only
be used if org-calendar-agenda-action-key was not set explicitly by
the user.


        Stefan

bug#10289: 24.0.92; Sneaky clobbering of user key binding

[Nicolas Goaziou]

Hello,

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> I think a good solution should be along these lines: only add the `k'
> binding if the `k' key is currently "unbound" (or more generally does
> nothing more than signal an error, since `k' is probably bound to
> something like `undefined').  Of course, this care should only
> be used if org-calendar-agenda-action-key was not set explicitly by
> the user.

This will be the default behaviour in Org 9.2.

Thank you!

Regards,

-- 
Nicolas Goaziou                                                0x80A93738