[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: have cake will eat, eatcake will have - krazy key koncept kontrovers
From: |
Drew Adams |
Subject: |
RE: have cake will eat, eatcake will have - krazy key koncept kontroversy |
Date: |
Fri, 28 Aug 2009 08:34:28 -0700 |
> > Using the technique I mentioned, you can get the behavior
> > you listed (C-x o, C-x o o o..., C-x C-x, etc) immediately:
> >
> > (defun other-window-repeat ()
> > (interactive)
> > (repeat-command 'other-window))
> >
> > (define-key ctl-x-map "o" 'other-window-repeat)
>
> Is it possible to make *all* key sequences repeatable? Creating the
> above code for every single key sequence is tiresome...
I don't think we would want to.
One of the points I tried to make was that all of these considerations depend on
the particular keys, commands, context, etc.
Currently, we do waste some repeatable keys on non-repeatable commands (e.g.
C-M-x for something you won't want to repeat). Sometimes (e.g. C-M-x) this can
still be a good idea. It's not because we _could_ do this to all keys that we
would want to.
Simlarly, it's not because we _could_ make all prefix keys also perform
repeatable actions that we would want to.
The point is (a) to think about conserving such easy-to-repeat-by-pressing keys
and chords, and (b) that one way to conserve them can be to give repeatable
actions to prefix keys (in addition to their role as prefix) - and to give a
prefix role to keys that are currently used only for actions.
> > The real point was to be able to use this technique also
> > for a prefix key: to be able to have a prefix key perform
> > some action when repeated. Why?
> >
> > a. To have additional easily repeatable keys (giving
> > existing prefix keys double duty).
> >
> > b. To have additional prefix keys (giving existing
> > non-prefix keys double duty).
>
> My proposal solves a) and b) too:
>
> a) C-x C-x becomes easily repeatable (1 + n instead of 2n keys for n
> repeatitions);
>
> b) You may make C-a prefix key, and bind C-a C-a to repeatable command
> (again, 1 + n keys for n repeatitions, like in your method).
If, by your proposal, you mean what you sent before, then no. As I explained, if
you expect a prefix key to act in some way (e.g. as `forward-char') the first
time it is pressed, then it cannot also be a prefix key.
Well, it could be done, but with some jimmying. We could use a delay, as Juri
pointed out CUA-mode does. Or we could try to undo the action (from the first
C-a) if the following key is a legitimate suffix for that prefix, and then do
what the suffix says.
We could perhaps come up with other such workarounds. But the problem to be
worked around (or not, as in my suggestion) is that when a prefix key is pressed
once, you cannot know what is to follow - in general you must wait and see,
before doing anything.
> Is it correct that the difference between our proposals is
> the following?
>
> 1) Your method requires user to bind the prefix key (e.g. C-x, M-s h).
Users can do it themselves, of course. But my suggestion was for Emacs to do it,
for some set of keys that Emacs developers would agree on.
We would bind the prefix key as its own suffix, yes.
But not the whole prefix key - just its smallest nonempty tail. (If the only
nonempty tail is the whole key, then yes, the whole key.) In the case of prefix
key `M-s h', it is the tail `h' that we would bind to a repeatable action, not
the whole prefix key `M-s h'. We would bind `h' as a suffix in the prefix-key's
map, that is, the map for `M-s h'.
To make `C-x' after `C-x' and `h' after `M-s' repeatable, we would bind `C-x'
and `h' to `<something>-repeat' commands. In the former case, the binding would
be in the ctl-x-map; in the latter case, it would be in the `M-s h' map.
`M-s h h' is then defined as a repeatable action, so `M-s h h h h...' works, the
first action occurring with the second `h'.
> 2) My method requires user to bind the whole key sequence for the
> first repeatition (e.g. C-x C-x, M-s h h).
Sorry, I don't follow you. Please show some code or an algorithm. Or walk
through the binding steps you have in mind.
- have cake will eat, eat cake will have - krazy key koncept kontroversy, Drew Adams, 2009/08/26
- Re: have cake will eat, eat cake will have - krazy key koncept kontroversy, Andrey Paramonov, 2009/08/27
- RE: have cake will eat, eatcake will have - krazy key koncept kontroversy, Drew Adams, 2009/08/27
- Re: have cake will eat, eatcake will have - krazy key koncept kontroversy, Андрей Парамонов, 2009/08/28
- Re: have cake will eat, eatcake will have - krazy key koncept kontroversy, Andreas Schwab, 2009/08/28
- Re: have cake will eat, eatcake will have - krazy key koncept kontroversy, Андрей Парамонов, 2009/08/29
- Re: have cake will eat, eatcake will have - krazy key koncept kontroversy, Andreas Schwab, 2009/08/28
- RE: have cake will eat, eatcake will have - krazy key koncept kontroversy,
Drew Adams <=
Re: have cake will eat, eat cake will have - krazy key koncept kontroversy, Juri Linkov, 2009/08/27