RE: [PATCH] Make `C-x {' and `C-x }' repeatable

[Drew Adams <drew.adams@oracle.com>]

> (1) Discoverability.  Auto-acceleration 

It's undefined, so far.  Hard to defend or criticize something still pie-in-the-sky.

But my crystal ball and experience whisper to me that "automatic" too often misses
the mark and does not really DWIM.

On the other hand, _direct manipulation_ is all about user control, with
immediate feedback.

>     would likely happen to me frequently, so I'd learn it.
>     (Maybe not learn to use it, but learn to avoid it, at least.)

Avoiding an "automatic" do-it-all solution is one way to try to deal with it.
But it does not solve the problem.

>     "C-u C-u C-x } } C-3 }" is not something I would likely try
>     on my own, nor would I find it easy to remember if I read
>     about it in passing.

No need to remember anything.  The default behavior (no prefix arg) provides
a fine-tuning value (e.g. an increment) of 1.

And trying C-u at the outset, which is pretty simple and discoverable, quickly
shows you what it does: provides a larger increment for subsequent stepping.

Just stop and start again with the prefix key, if you like, to use a different
increment for subsequent steps.  Also obvious.

And if you _happen_ to use a prefix arg also before one of the final-key
occurrences... WYSIWYG - immediately.  This is just a shortcut so you don't have
to start again with the prefix key.

Readers of the doc string or curious experimenters will quickly discover the shortcut.
And others are not handicapped without the shortcut: they can just hit the prefix
key again, giving it a different prefix arg to change the increment size.

IOW, if you don't happen to stumble upon all the available behaviors, it's likely
you'll continue using the default increment, which means fine-tuning all the time.
Or you'll figure out only the initial prefix arg, so will quit after N uses and
start again without a prefix arg to fine-tune.

> (2) Consistency.  I can't think of any other case where an infix key
>     controls the behavior of a command.

There is no "infix" key anywhere here.  There are just keys, bound to various
commands.  And each key accepts a prefix arg and does something with it.

The only thing different from usual here is that the default value of the prefix
arg is the last used prefix arg, instead of 1.

And that is already what we do for C-x C-(+|-), except that we don't let you
change the prefix arg along the way.  The arg you use initially continues to be
used for each subsequent step.  We do NOT revert you to the default increment
size for steps after the first.  You continue to increment/decrement using the
same increment size for all steps.

That's the approach I recommend.  With the added feature that you can, if you like,
change the increment on the fly, without having to start over with the prefix key.

> (3) Usability.  Some people, like you, can estimate pretty well
>     whether you need C-2 or C-3.  Others can't, and would need to
>     calculate, possibly costing more time than they save.  Auto-
>     acceleration has no such cost of computation.

No, you miss the point.  This is direct manipulation.  Typically each such
resizing, moving, etc. command/key has its opposite: `right' cancels `left'
etc.  Overshoot?  Just come back.  Come back less or more, as needed.
There is nothing to "estimate".  Just do it and see immediately the effect,
adjusting on the fly as needed.

This is typical of any command that is repeatable and provides incremental adjustment.
A different but similar approach is used in DoReMi, which lets you incrementally
change all kinds of things.  There, instead of a prefix arg, there is a default
increment size, and using the `Meta' key with the usual incrementing keys (e.g. `up',
`down', `left', `right') boosts the default increment by a factor.

So if you want to move your frame quickly across the screen then you hold down
`M-' while you hold down `right'.  If you want to slow down you release `M-'.
If you go too far then you use `left' to come back.  Simple, even obvious.

The point is that it is trivial to "discover" how to incrementally adjust something,
including taking advantage, when you want to, of any scaling/boosting/accelerating.
This is no more difficult to "learn" or discover than sliding a scroll-bar thumb
with your mouse pointer.

> (4) Economy.  The advantage of user control is smaller than you
>     suggest, I believe.  Anything bigger than C-1 will cause you to
>     miss the target half the time or more.

Simply not true.  Where do you get that "half the time or more"?  And what does
"miss the target" even mean here, precisely?

We're talking about incremental adjustment.  If I want to move an Emacs frame
downward so that its bottom edge precisely aligns with the top of another frame
(just as an example), that edge coincidence is presumably your "target".  It is
obvious and simple to do this incrementally.  If you want to move the whole distance
using a tiny increment (e.g. 1 pixel at a time), you can do that.  But if you want
to move most of the distance using a larger increment then you can do that too.

And if you overshoot (and you likely will, when in a final "docking" maneuver)
then you just move back (and forth, if necessary, until you get it right).

This is so simple as to make any description of it overkill.  But hopefully it
is clear now?  

>     Sometimes people will need
>     to correct for overshooting, which means either starting over with
>     the inverse command or using a negative count.  And even if they
>     undershoot they need to switch to C-1.

You make over/undershooting sound like some kind of error.  It is in fact the
_normal_ way we interact with our environments (and even with ourselves).
You cannot sit down or stand up or take a step without making over/undershoot
adjustments.

And no, I do not understand your statement about starting over.

> I don't want it badly enough to write the code, but I suspect more
> users will find it useful than the UI you propose.  Both are valid
> proposals and worth experimenting with.

Yes to the idea that experimenting is helpful.

If you want to experiment with incremental adjustment (if not the same prefix-arg
design), here are a few places to start:

* frame-cmds.el: commands such as `move-frame-(down|up|right|left)',
  `(enlarge|shrink)-frame(-horizontally)'
  http://www.emacswiki.org/emacs-en/download/frame-cmds.el

* doremi-frm.el, doremi-cmd.el: any of the commands (increment face/frame colors,
  frame/font sizes, etc.)
  http://www.emacswiki.org/emacs-en/download/doremi-frm.el
  http://www.emacswiki.org/emacs-en/download/doremi-cmd.el
  http://www.emacswiki.org/cgi-bin/wiki/DoReMi

Even in vanilla Emacs, just consider adjusting text size using C-x C-(-|+), with
and without a prefix arg.  A prefix arg here is "modal" in the sense that the
initial prefix arg you give is passed on to each subsequent +/-, instead of reverting
to an increment of 1.  You cannot, however, change the increment along the way (which
is the additional feature I proposed in the current context).

Or even just using `M-f' and `C-f' to move across text to your "target", coming back
with `(M|C)-b' if you overshoot, etc.  Here, like the DoReMi booster-key case, there
are separate keys for different size increments.  A prefix arg here controls not
the increment size but the number of jumps.

Really not a big deal at all.  All of these different ways of incrementally adjusting
something provide easy ways to fine-tune, including adjusting for over/undershoot.