emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Enhancements to "minor-mode-map-alist" functionality.


From: Kim F. Storm
Subject: Re: Enhancements to "minor-mode-map-alist" functionality.
Date: 07 May 2002 23:52:04 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.50

Richard Stallman <address@hidden> writes:

>     > That may be true, but I'd like to see what the issue is more concretely.
>     > If cua and viper tried to use one alist, what would they have to do
>     > to prevent it from being messed up?  What does "messed up" mean in this
>     > context?
> 
>     Changing the sequence or removing an element from the alist.
> 
> I don't understand--could you be less cryptic?
> That does not seem to answer either one of my questions.
> It is not the right kind of answer for either one.

You asked in what way the alist could be "messed up" in "this context".

The "messing up" I'm concerned about is if some other mode
(accidentally) changes the sequence of the elements in the alist, or
(accidentally) removes one or more of the elements.

> 
>     Even with one list, this may be unlikely to happen in practice, but I
>     don't understand why this is a big issue.
> 
> Adding one list is less change from what we have now.
> 

Yes, but IMO, it is the wrong solution to the problem.


> 
> Are you concerned about the order of the list?

Exactly!

> If so, could you explain when and how the order matters?

In cua, I have three keymaps which remaps the same commands
(e.g. kill-ring-save) depending on whether the global mark,
the rectangle, or the region is active -- all of which may be
true at the same time!!!  So for things to work properly,
the elements in the alist must be in the proper order.

Of course, I can arrange the conditions and keymaps so that only one
condition is true at a time -- but that makes things a lot more
complex; just keeping the keymaps in the proper sequence is *much* simpler.

And there are other cases like this in cua.

I would imagine that viper has similar requirements, since it is
based on various operation modes (command, insert, ...).

++kfs






reply via email to

[Prev in Thread] Current Thread [Next in Thread]