emacs-devel
[Top][All Lists]
Advanced

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

Re: Proposal: Remap interactive commands via keymaps


From: Kim F. Storm
Subject: Re: Proposal: Remap interactive commands via keymaps
Date: 08 Jan 2002 00:59:38 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Jason Rumney <address@hidden> writes:

> address@hidden (Kim F. Storm) writes:
> 
> > As an real-life example, I have written cua.el which depends on both
> > examining this-command in the pre-command-hook and remapping commands
> > through a keymap (in a brute force manner), and it works fine as long
> > as the user doesn't use M-x to run any of the overloaded commands.  If
> > he does, things only go slightly wrong for some commands, utterly
> > wrong for other commands, whereas practically none of them works
> > correctly.
> 
> I fondly remember a time when cua-mode used to happily co-exist with
> Emacs, so I could use C-@, C-w, C-y etc as I was used to, and others
> that used my PC could use Shift-arrow keys, C-x, C-v etc as they were
> used to. Now I have to tell others to use the menus if they are not
> used to Emacs keybindings, as I am not prepared to lose the normal
> Emacs functions that cua.el aggressively tries to suppress.

Well, the current state of cua.el is my honest attempt to make the
best out of the current features provided by emacs.  It is primarily
because I want be able to implement cua in a cleaner way I've proposed
this feature - as well as a previous proposal for the
emulation-mode-map-alist (which was also rejected by RMS).

Anyway, I don't follow you here.  C-@, C-w, etc works fine with
cua.el, and I don't see what commands cua.el aggressively
(i.e. intentionally) tries to suppress.  I would very much like you to
describe exactly what behaviour of cua.el that has changed to the
worse (preferably in a private mail).


> 
> > No, according to you and Jason, I (and any novice user like me) have
> > to explicitly know that although I enabled whizzy-mode, I need to
> > enter M-x whizzy-lisp-complete-symbol to get the behaviour I want.
> 
> And according to you, if I explicitly want the behaviour of
> lisp-complete-symbol, I am out of luck.  IMO, *that* is not user
> friendly. whizzy-mode should modify keybindings, not replace standard
> functions with its own in an intrusive way.
> 
But why did you enable whizzy-mode if you don't like its behaviour ?
You still haven't explained why you would want to do that?

As things are now, I think you have to agree that there are two
fundamentally different views on this issue.  IMO, my view is just as
valid as yours - except that your view is "backed by management" :-)

As a compromise - can we offer both behaviours?  At the user level, a
simple `remap-extended-commands' variable would be enough.  The
default would be as you and Richard prefer (i.e. off).

AFAICS, the code changes needed to implement this are quite trivial,
and I could have implemented it in 1/5th of the time I've spent arguing
about the issue.

Please, can I do this - and get on to *using* the feature?


> > Why do you think than an average user would expect yank and yank to
> > behave differently whether he runs it via C-y or M-x yank ?  I simply
> > cannot understand how you can say this is the correct behaviour!
> 
> I think the way that delete-selection-mode implements this is
> flawed. It should rebind C-y to run some other command, so it is made
> explicit that it is not the standard yank behaviour.

With command remapping, it should remap yank to delsel-yank in the
delsel-mode-map.

>                                                     The part of the
> change you are proposing which RMS and myself agree with would make
> such an implementation easier. The rest of the change you are
> proposing just reinforces the confusion.

Well, confusion is relative - what you call natural, I find confusing,
and what I feel is obvious, you say is confusing.

-- 
Kim F. Storm <address@hidden> http://www.cua.dk




reply via email to

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