From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Miles Bader <miles@gnu.org>
Cc: Teemu Likonen <tlikonen@iki.fi>,
Stefan Monnier <monnier@IRO.UMontreal.CA>,
emacs-devel@gnu.org
Subject: Re: substitute-key-definition vs. define-key MAP [remap ...]
Date: Sat, 24 Jul 2010 23:25:52 +0900 [thread overview]
Message-ID: <87tynpvtvz.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <87aaphusuz.fsf@catnip.gol.com>
Miles Bader writes:
> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
> > > And it's _extremely_ handy for some uses... e.g., one of my favorite
> > > tricks is little minor-modes that bind [remap self-insert-command]...
> >
> > It's a handy hack, I'm sure. I think there are better ways to achieve
> > the same end, that's all.
>
> For instance? Solutions as adding hooks/functions for to allow
> mode-specific semantics for standard commands
> (e.g. `fill-paragraph-function') are better for those cases, I think,
> but they have far higher cost (they must be added by the emacs
> developer), and are not really so nice for minor modes -- IOW, it
> doesn't really achieve the same thing.
Use of defun is not restricted to emacs developers (and you will often
need to use it with [remap] anyway).
For handy hacks, I really don't see what's so horrible about
(define-minor-mode caps-lock-mode
"Only useful with a Happy Hacker keyboard."
:lighter "CapsLock")
(defadvice self-insert-command (before caps-lock-mode activate)
"Make self-insert-command respect caps-lock-mode."
(when caps-lock-mode
(set last-command-key (upcase last-command-key))))
and I certainly don't think that concealing a limited advice
capability in the keymap lookup process is any better than advice
itself.
next prev parent reply other threads:[~2010-07-24 14:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-15 8:25 substitute-key-definition vs. define-key MAP [remap ...] Teemu Likonen
2010-07-22 22:36 ` Stefan Monnier
2010-07-23 3:50 ` Stephen J. Turnbull
2010-07-23 9:26 ` Stefan Monnier
2010-07-23 9:32 ` Miles Bader
2010-07-24 7:08 ` Stephen J. Turnbull
2010-07-24 8:19 ` David Kastrup
2010-07-24 9:33 ` Miles Bader
2010-07-24 14:25 ` Stephen J. Turnbull [this message]
2010-07-25 3:21 ` Miles Bader
2010-07-25 10:19 ` Stephen J. Turnbull
2010-07-25 13:43 ` Miles Bader
2010-07-23 10:03 ` David Kastrup
2010-07-24 6:27 ` Stephen J. Turnbull
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tynpvtvz.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=emacs-devel@gnu.org \
--cc=miles@gnu.org \
--cc=monnier@IRO.UMontreal.CA \
--cc=tlikonen@iki.fi \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.