From: storm@cua.dk (Kim F. Storm)
Cc: emacs-devel@gnu.org
Subject: Re: Enhancements to "minor-mode-map-alist" functionality.
Date: 21 Apr 2002 13:08:36 +0200 [thread overview]
Message-ID: <5xwuv11f7v.fsf@kfs2.cua.dk> (raw)
In-Reply-To: <200204201727.g3KHRvu01477@aztec.santafe.edu>
Richard Stallman <rms@gnu.org> writes:
> The actual interpretation of C-x is done via three of cua's 7 keymaps.
>
> Using separate keymaps for C-x seems reasonable.
>
> I wonder, though, why simply putting all three in minor-mode-map-alist
> won't do the job. As I recall, if any active keymap defines a binding
> with a non-prefix definition, that should override all prefix
> definitions regardless of the precedence order of the maps. Is that
> not true now? If not, maybe we could make it true again.
I wasn't aware of this functionality. I'll see if it is true now.
> So there is
> no need to worry about the relative order of your maps and all other
> maps.
>
There are other cases where the ordering of those maps matters, but I
might be able to further limit the dependence on the ordering (by
making sure only one condition is true at a time), but I would still
prefer if I could just rely on having my own (separate)
cua-minor-mode-map-alist (on the emulation-mode-map-alists list), and
be sure that noone would mess with it. And since I've already implemented
it, I know the change to add emulation-mode-map-alists is trivial!
> If you need to condition some of these maps on some symbol's being
> false, then we could make the minimal extension so far proposed, which
> is to allow minor-mode-map-alist (or another new alist) to have
> conditions which are more complex than just a symbol. But you do see
> if you can easily get away without that.
If we don't allow some form of simple logical expression [e.g. the
functions I listed in a previous mail], I really don't see any
alternative to the present code cua (and viper) which refreshes a list
of state variables and fixes any ordering problems in
minor-mode-map-alist after each command.
>
> To facilitate this, three more keymaps are used which selectively does
> command remapping of `kill-ring-save' to handle either region, rectangle,
> or the global mark.
>
> It would be cleaner to define a single new command for that purpose.
I don't agree. There are many other commands which are specific for
the region, rectangle, and global mark cases, and handling those in
separate functions is a lot clearer (to me).
Actually, the new cua package consists of three files now:
cua-base.el (for the basic functionality and region handling)
cua-rect.el (for rectangle commands)
cua-gmrk.el (for the global mark functionality)
>
> The final keymap is used to allow users to take advantage of cua's
> uniform command set for rectangles (and the global mark), but still
> continue to use C-w, M-w and C-y instead of C-x, C-c, and C-v (which
> are the normal cua bindings).
>
> Which characters does this map redefine?
>
C-z -> undo, C-v -> yank
--
Kim F. Storm <storm@cua.dk> http://www.cua.dk
next prev parent reply other threads:[~2002-04-21 11:08 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-11 22:56 Enhancements to "minor-mode-map-alist" functionality Kim F. Storm
2002-04-11 22:43 ` Stefan Monnier
2002-04-12 9:31 ` Kim F. Storm
2002-04-12 13:20 ` Kim F. Storm
2002-04-12 18:46 ` Stefan Monnier
[not found] ` <5xofgoobzr.fsf@kfs2.cua.dk>
[not found] ` <200204122021.g3CKLh217680@rum.cs.yale.edu>
2002-04-14 22:32 ` Kim F. Storm
2002-04-16 20:18 ` Richard Stallman
2002-04-16 22:34 ` Kim F. Storm
2002-04-18 18:46 ` Richard Stallman
2002-04-18 23:07 ` Kim F. Storm
2002-04-19 13:43 ` Stefan Monnier
2002-04-19 15:36 ` Kim F. Storm
2002-04-19 14:46 ` Stefan Monnier
2002-04-21 17:46 ` Kim F. Storm
2002-04-22 9:28 ` Stefan Monnier
2002-04-22 15:15 ` Kim F. Storm
2002-04-19 18:42 ` Richard Stallman
2002-04-19 22:05 ` Kim F. Storm
2002-04-20 17:27 ` Richard Stallman
2002-04-21 11:08 ` Kim F. Storm [this message]
2002-04-22 7:47 ` Richard Stallman
2002-04-22 13:53 ` Kim F. Storm
2002-04-22 22:36 ` Richard Stallman
2002-04-23 10:58 ` Kim F. Storm
2002-04-22 22:36 ` Richard Stallman
2002-04-23 11:02 ` Kim F. Storm
2002-04-24 17:55 ` Richard Stallman
2002-04-26 13:44 ` Kim F. Storm
2002-04-27 22:41 ` Richard Stallman
2002-04-29 9:17 ` Kai Großjohann
2002-04-30 5:18 ` Richard Stallman
2002-04-30 21:25 ` Kim F. Storm
2002-05-01 7:14 ` Richard Stallman
2002-05-01 17:37 ` Kim F. Storm
2002-04-14 23:11 ` Kim F. Storm
2002-04-12 18:20 ` Stefan Monnier
2002-04-12 21:05 ` Kim F. Storm
2002-04-12 20:30 ` Stefan Monnier
2002-04-12 22:08 ` Kim F. Storm
2002-04-13 19:05 ` Richard Stallman
2002-04-13 19:05 ` Richard Stallman
2002-04-13 23:30 ` Kim F. Storm
2002-04-15 12:34 ` Stefan Monnier
2002-04-17 16:03 ` Richard Stallman
2002-04-15 21:54 ` Richard Stallman
2002-04-15 23:55 ` Kim F. Storm
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=5xwuv11f7v.fsf@kfs2.cua.dk \
--to=storm@cua.dk \
--cc=emacs-devel@gnu.org \
/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.