unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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

  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

  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=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 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).