have cake will eat, eat cake will have - krazy key koncept kontroversy

have cake will eat, eat cake will have - krazy key koncept kontroversy

[Drew Adams]

(At Swim-Two-Birds...)

This will probably be another controversial suggestion...  Or ignored.
Or both.  ;-)


1. Key sequences that are single keys or chords can be repeated by
simply holding the key or chord pressed.  This is very handy for
certain commands; for other commands it is not so important (not
needed).

The set of easy-to-use single keys and chords is limited, so we should
try to save such key sequences for commands that we might want to
easily repeat.  IOW, we don't want to waste such keys.

(Yes, you can always use `C-x z z z z z...' after any key sequence, to
repeat a command.  But that's not quite as handy as simply holding a
key pressed to repeat it.)


2. Putting commands on a prefix key makes them *not* easily
repeatable.  So we should do that only for commands whose easy
repetition is not so important.


3. Grouping related commands on a prefix key is one way to conserve
non-prefix key bindings (that is, conserve keys that are easily
repeatable).  (Such grouping can also help with remembering, doc,
etc.)

For example, we put all of the bookmark commands on prefix `C-x r'.
We could have bound each of them to a non-prefix key instead, but that
would have wasted the (easily repeatable) non-prefix keys.  These
particular commands do not need to be repeated often, so grouping them
on a prefix is a good choice.


4. Emacs has some non-prefix keys that are not bound to commands that
require easy repetition.  I haven't thought about a list of such
commands, but there are some.  You can easily think of a few (`C-a',
for instance).

Judging only by the criterion in #1, this is a waste of precious
easily-repeatable keys.  (But that's not the only criterion.)


5. The reasons for #4 might be different for different keys.  They
include:

5a. Often-used commands deserve an easy-to-press key or chord.
Regardless of whether they are often repeated or even repeatable.

5b. Maybe just legacy - the key was assigned soon after the Emacs Big
Bang, and old habits die hard.  When Emacs was young, there were more
easy keys to go 'round.


6. Emacs has other non-prefix keys, such as `C-b', that are bound to
commands that do require the possibility of easy repetition.  Like the
easily repeatable non-prefix keys that do not require repetition (#4),
these keys are, well, non-prefix.  They cannot also be used as a
prefix, to introduce a group of related keys.  ("Huh? Duh!", I hear
you say.)


7. A prefix key defines key sequences that cannot easily be repeated
(i.e., simply by holding pressed), and the prefix key itself does
nothing.  That is, it has no action other than serving as a way
station to the suffix keys it prefixes.

This means that each prefix key (single key or chord) that itself is
easy to type wastes an easily repeatable key, depriving it of being
used on its own for an action.  For example, since `C-x' is a prefix
key, `C-x' cannot be used to perform some action - so we cannot then
just hold `C-x' pressed to repeat that action.

(Note that using the prefix key itself as one of its suffixes is not
the same as repeatedly repeating it.  E.g. `C-x C-x' can be defined as
some action, but `C-x' itelf cannot perform a repeatable action, and
`C-x C-x C-x' is not a repetition of anything.


8. #6 and #7 together simply say that you cannot have your cake and
eat it too.  If a key serves as a prefix, then it cannot also perform
an action.  If a key performs an action, then it cannot also be a
prefix key.  After all, a prefix key is bound to a keymap, not to a
command.  Duh, again.



OK, here comes the crazy, controversial part...


9. What about somehow working around this limitation?  That is, find a
way to let a key such as `C-x' serve both (a) as a prefix key (a way
station to suffix keys) and (b) as its own binding, to invoke a
repeatable action.


10. If we did that, then we could potentially revisit some of the
wasters mentioned in #4, #6, and #7.  We could define the same easily
repeatable key (`C-a' or whatever) as a prefix key.  Being able to do
that doesn't mean that we would have to do it, but the discussion
could be opened wrt particular keys, case by case.


11. WDOT?  Is this a good idea in general or not?  If so, do you have
a good idea for an implementation of #9?


12. Here is one possible implementation in Lisp.  I don't claim it's
the best one, but it seems to work OK.

(defun repeat-command (command)
  "Repeat COMMAND.  (more explanation needed)"
 (interactive)
 (let ((repeat-previous-repeated-command  command)
       (last-repeatable-command           'repeat))
   (repeat nil)))

Here is how you could then define `C-x', which is already a prefix
key, as also a repeatable key for an action command, in this case,
`backward-char':

(defun backward-char-repeat ()
  "Like `backward-char'.  (more explanation needed)"
  (interactive)
  (repeat-command 'backward-char))

(define-key ctl-x-map "\C-x" 'backward-char-repeat)


Now just holding down `C-x' invokes `backward-char' repeatedly - once
you've gotten past the first `C-x' (the prefix).

But `C-x C-f' still calls `find-file', `C-x b' still calls
`switch-to-buffer', etc.  IOW, `C-x' is, in effect, both a prefix key
and an action key ("in effect", meaning it _seems_ to act that way).

The idea is to just define the prefix key as its own suffix (just as
we do for `exchange-point-and-mark'), but by binding that key sequence
to a repeat action.

(Obviously, this example is just an illustration.  I'm not proposing
to do away with `C-x C-x' for `exchange-point-and-mark' or to change
the binding of `backward-char'.)


13. Yes, you must repeat the key at least once for it to do anything.
That is, `C-x' does nothing until you hit it again.  But each `C-x'
after the first one invokes the action.

Because of this startup hiccup (stutter?), we would not want to do
this for any command (such as `C-b', in fact) that we would often use
_without_ repeating.  This would be good for actions, such as frame
movement, text scaling, or window resizing, that are typically used
with repetition and not as one-offs.


14. In the implementation, we could perhaps play with using a prefix
arg too.  But without changing the definitions at all, notice that you
can already use a prefix arg to increase the scale of each action (or
do whatever the command does with a prefix arg, each time it is
invoked in a set of repetitions).

For example, with the above definitions, `C-u C-x C-x C-x C-x'
performs three (4 - 1 = 3) `backward-char' operations, giving each one
the prefix arg (numeric value 4).  For `backward-char', the effect is
that the scale of movement is multiplied by 4.  Each repetition is
scaled: 3 * 4 = 12.


15. Obviously, the interest of this would be to be able to do both of
these at the same time (have our cake and eat it too):

15a. HAVE CAKE: Treat an existing non-prefix key as a prefix key
                (e.g. `C-a').

15b. EAT CAKE:  Add an action binding to an existing prefix key
                (e.g. `M-s').


16. Downsides?  Less transparency, not so obvious.

`C-h k C-x C-x' for the above example shows its doc string, but we
would need to introduce the concept of such a key for users, to make
it clear once and for all what's involved.

And there is no doc for just `C-h k C-x'.  That is, this kind of
repeatable key/action is nevertheless on a prefix key - nothing
happens until you hit it a second time.

IOW, the "trick" would need to be explained, to set expectations.

Not the implementation, but the idea that `C-x C-x' (or whatever) is a
key sequence whose last part (only) is repeatable.  You need not
repeat the pair `C-x C-x'; you can just repeat `C-x' (at least once).

Some doc or naming convention should probably be adopted to identify
and refer to such commands and their key bindings.

Another (minor, IMO) downside is the inability to use, say, `C-x C-f'
immediately after repeating `C-x C-x...'.  You must do something else
first, to break the chain of repetition.


17. If we were to decide to adopt this approach semi-systematically,
the question would arise as to how to proceed.  Emacs itself could no
doubt take advantage of the possibility of additional
easily-repeatable bindings.  But users would also appreciate that
possibility for their own bindings.

I personally would not like to see Emacs take advantage of things to
the point of not giving some of the new freedom to users for their own
bindings.


18. An alternative approach might be to do nothing except explain this
possibility to users, as a trick they might want to use to rationalize
their key bindings.  IOW, document it, but don't use it to change any
bindings in Emacs-out-of-the box.  (Or do nothing at all - I'll just
mention it on the wiki.)


19. If we decided for #17 (not #18), a good place to start would be to
identify the cases of #15a that might be good candidates for
redefinition.  IOW, would it make sense to bind `C-b' to a command
such as `backward-char-repeat'?

Let's suppose the answer for `C-b' is "yes" (even though it's not).
That means defining `C-b' as a prefix key, but it doesn't necessarily
mean defining any other suffix than `C-b' right away.  Emacs could
hold off, leaving the rest of that prefix key open for use by users,
at least for now.

On the other hand, some might argue that it would be silly to do that,
given that the current use of a single `C-b' would be lost (you would
need to use `C-b C-b' to get any action at all).  They might say that
we should wait until we actually use `C-b' as a prefix for some group
of operations - that way, at least the loss of a single active `C-b'
would be compensated by some gain.

Obviously, `C-b' is, again, just an illustration.  I'm not proposing
that we lose the single-key `C-b' action just to be able to squeeze
suffixes onto `C-b'.  Real candidates for this would need to be picked
case by case.


20. Anyway, you get the idea:
20a. The main question of the utility of such a manip.
20b. The question of what implementation would be good.
20c. The question of how to proceed (which keys/commands to look at).

Re: have cake will eat, eat cake will have - krazy key koncept kontroversy

[Andrey Paramonov]

Drew Adams <drew.adams <at> oracle.com> writes:
> OK, here comes the crazy, controversial part...
[the crazy, controversial part skipped]

Hello!

I see the problem you are trying to solve.

Your solution pros:
1) It has a sketch of elegant implementation,
2) It does solve the problem.

Your solution cons:
1) In many cases, user will have to hit prefix twice instead of once (C-a C-a
instead of C-a).

I suggest to go the other way around: 
IF there is no keymap entry that matches the key sequence
*and* the previous key has successfully executed a command
*and* the key equals to the previous key 
THEN repeat the command (and keep processing the key sequence).

For example:

C-x o   will take me to other window
C-x o o o o ...   will cycle me through windows
C-x C-f   will work as used to
C-x C-x   will exchange point and mark
C-x C-x C-x   will exchange point and mark twice
C-x C-x C-x C-x   will exchange point and mark three times

This approach does not impose extra key penalty for non-repetitive command
execution. 

In Emacs 23, C-x C-= / C-x C-- (text-scale-adjust) work this way. I find it very
useful and intuitive.

Andrey Paramonov

RE: have cake will eat, eatcake will have - krazy key koncept kontroversy

[Drew Adams]

> I see the problem you are trying to solve.

Yes and no. I think you see the point about using a suffix key to repeat an
action.

I don't think you see the point about using a prefix key (as its own suffix) to
perform a (repeatable) action.

[*]

> 1) In many cases, user will have to hit prefix twice instead 
> of once (C-a C-a instead of C-a).

Not just in many cases. In *all* cases where this technique is used.

This is in the nature of a prefix key. If a key (e.g. C-a) performs an action on
its first press, then it cannot be a prefix key.

Otherwise, how could you distinguish C-a as action from C-a as prefix? How would
you know whether C-a might be followed by `j' or `C-r' (assuming keys `C-a j'
and `C-a C-r' were defined)?

> I suggest to go the other way around: 
> IF there is no keymap entry that matches the key sequence
> *and* the previous key has successfully executed a command
> *and* the key equals to the previous key 
> THEN repeat the command (and keep processing the key sequence).
> 
> For example:
> C-x o   will take me to other window
> C-x o o o o ...   will cycle me through windows
> C-x C-f   will work as used to
> C-x C-x   will exchange point and mark
> C-x C-x C-x   will exchange point and mark twice
> C-x C-x C-x C-x   will exchange point and mark three times
> 
> This approach does not impose extra key penalty for 
> non-repetitive command execution.
> 
> In Emacs 23, C-x C-= / C-x C-- (text-scale-adjust) work this 
> way. I find it very useful and intuitive.

What you are talking about has nothing to do with prefix keys.

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)

The fact that you can do that in this way is only part of what I was pointing
out.

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

Obviously, if the same key is used as both prefix and suffix, then no action can
be performed the first time the key is pressed. Because it is a prefix key, C-x
does nothing until you press it again (or press some another key).

So we would only bind a repeatable action to a prefix key followed by itself
when that action is not very useful as a one-off. I gave as examples commands
that incrementally change some parameter - e.g. the height of a window, frame,
font,...  It's not very important that such a command do something on the very
first key press, since you are going to press it multiple times.

The point is that we can:

a. Use an existing prefix key as its own suffix, and thus let it perform some
repeatable action (starting with the first repetition).

b. Convert an existing non-prefix key to a prefix key, when its one-off action
isn't really needed (that is, we are mainly interested in its repeated action).

Together, these allow reuse of the same key to (a) perform a repeated action by
holding it pressed and (b) serve as a way station to other keys/commands, by
being a prefix.

Wrt (a): Think of all the prefix keys you use. We could reuse an existing prefix
key such as `M-s h' to perform a repeatable action such as, I don't know,
highlight-the-next-word: M-s h h h h...

Would it be worth it to do that? Dunno. It all depends on the particular keys
and commands. But the possibility is there.

Wrt (b): Think of all the non-prefix keys you use. Some of them perform useful
repeatable actions. Others do not - they are just one-offs. C-M-a is usefully
repeatable; C-M-x is not. (Binding C-M-x to a command that we do not repeat is,
_in itself_, a waste. But there are other reasons for that binding.)

We could make a key such as C-M-a or C-M-x into a prefix key, if we wanted. (I'm
not suggesting we do that.) Advantage: another prefix key.

If we did that, we could still have C-M-a go to the beginning of the previous
defun, in a repeatable way, just as now. The only loss would be that to get the
one-off behavior of going just to the current defun, you would need to hit C-M-a
twice.

Would it be worth it to do that for C-M-a? Probably not. It all depends on the
particular command (do we really need the one-off behavior?), the particular key
binding (is it easy to repeat?), and how hard up we are for a new prefix key.
But the possibility is there.


[* To simplify the wording, I say use the prefix key as its own suffix, but I
really mean use some tail of the prefix key as its own suffix, where the tail
could be the whole prefix key. `C-x C-x' uses the whole prefix key `C-x' as a
suffix. `M-s h h' uses only the tail `h' of the prefix key `M-s h' as a suffix.]

Re: have cake will eat, eat cake will have - krazy key koncept kontroversy

[Juri Linkov]

> 9. What about somehow working around this limitation?  That is, find a
> way to let a key such as `C-x' serve both (a) as a prefix key (a way
> station to suffix keys) and (b) as its own binding, to invoke a
> repeatable action.
> [...]
> 11. WDOT?  Is this a good idea in general or not?  If so, do you have
> a good idea for an implementation of #9?

Cua-mode uses a short delay (`cua-prefix-override-inhibit-delay') to decide
between interpreting a key as a prefix key or using its own binding.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: have cake will eat, eat cake will have - krazy key koncept kontroversy

[Miles Bader]

Juri Linkov <juri@jurta.org> writes:
>> 11. WDOT?  Is this a good idea in general or not?  If so, do you have
>> a good idea for an implementation of #9?
>
> Cua-mode uses a short delay (`cua-prefix-override-inhibit-delay') to decide
> between interpreting a key as a prefix key or using its own binding.

Note that this sort of test is notoriously flaky, and should only be
used if there's no other choice.  It's far, far, better, to simply avoid
the ambiguity in the first place.

-miles

-- 
History, n. An account mostly false, of events mostly unimportant, which are
brought about by rulers mostly knaves, and soldiers mostly fools.

Re: have cake will eat, eatcake will have - krazy key koncept kontroversy

[Андрей Парамонов]

2009/8/28 Drew Adams <drew.adams@oracle.com>:
> 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...

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

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

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

Andrey

Re: have cake will eat, eatcake will have - krazy key koncept kontroversy

[Andreas Schwab]

Андрей Парамонов <cmr.pent@gmail.com> writes:

> Is it possible to make *all* key sequences repeatable?

That would definitely be a desaster.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: have cake will eat, eatcake will have - krazy key koncept kontroversy

[Андрей Парамонов]

2009/8/28 Andreas Schwab <schwab@linux-m68k.org>:
> That would definitely be a desaster.
>

Please explain why.

Andrey

Re: have cake will eat, eatcake will have - krazy key koncept kontroversy

[Andreas Schwab]

Андрей Парамонов <cmr.pent@gmail.com> writes:

> 2009/8/28 Andreas Schwab <schwab@linux-m68k.org>:
>> That would definitely be a desaster.
>>
>
> Please explain why.

It would kill fast typing if any letter can randomly trigger repetition.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RE: have cake will eat, eat cake will have - krazy key koncept kontroversy

[Drew Adams]

> Juri Linkov <juri@jurta.org> writes:
> >> 11. WDOT?  Is this a good idea in general or not?  If so, 
> >>     do you have a good idea for an implementation of #9?
> >
> > Cua-mode uses a short delay
> > (`cua-prefix-override-inhibit-delay') to decide
> > between interpreting a key as a prefix key or using its
> > own binding.
> 
> Note that this sort of test is notoriously flaky, and should only be
> used if there's no other choice.  It's far, far, better, to 
> simply avoid the ambiguity in the first place.

In addition to Miles's point (orthogonal to it):

It's good to consider multiple possible implementations. For the subject at
hand, however, I don't think such a delay would be helpful.

IIUC, in CUA mode a delay distinguishes `C-x <delay> C-f', as cut followed by
forward-char, from `C-x C-f' as find-file.

But the discussion is about repeating the prefix key. If `C-x' for CUA were some
repeatable action (e.g. shrink the window) instead of cut, then to repeatedly
act you would need to do `C-x <delay> C-x C-x C-x' (or maybe even `C-x <delay>
C-x <delay> C-x...'; dunno).

If you're going to do that, you might as well use the approach I suggested, and
simply hit `C-x' twice: `C-x C-x' is about as easy as `C-x <delay>', especially
when repetition is involved: `C-x C-x C-x' (hold pressed) vs `C-x <delay> C-x'
(or perhaps `C-x <delay> C-x <delay>').

Anyway, I'm glad you mentioned this alternative approach. The more the merrier.

RE: have cake will eat, eatcake will have - krazy key koncept kontroversy

[Drew Adams]

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