From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Stephen Berman <stephen.berman@gmx.net>
Cc: 10289@debbugs.gnu.org
Subject: bug#10289: 24.0.92; Sneaky clobbering of user key binding
Date: Tue, 13 Dec 2011 14:38:24 -0500 [thread overview]
Message-ID: <jwvd3bse0en.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <87iplkmrce.fsf@escher.fritz.box>
> 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
next prev parent reply other threads:[~2011-12-13 19:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-13 15:19 bug#10289: 24.0.92; Sneaky clobbering of user key binding Stephen Berman
2011-12-13 19:38 ` Stefan Monnier [this message]
2018-01-20 12:10 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvd3bse0en.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=10289@debbugs.gnu.org \
--cc=stephen.berman@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).