RE: [External] : Re: Proposal: new default bindings for winner and windmove

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

Apropos using something like Icicles for
cycling and choosing (and there are other
frameworks besides Icicles - even vanilla
Emacs offers enough to get the job done):

Q: Why is completion superior to cycling for
accessing different choices?

1. You can cycle (duh).
2. You can filter, reducing the choice space
   (including the cycling space) on the fly.
3. You can access choices directly (what we
   used to call "random access").
4. You can see/show additional, related info
   about individual candidates (or groups of
   candidates).
5. You can sort candidates in different ways,
   which means changing the eyeball-searching
   order and the cycling order.
6. A single, command-specific key to initiate,
   but can stick to the same (e.g. standard)
   keys for cycling/choosing.  IOW, only the
   initial key need be different (acts like a
   prefix key).

#6 means:

Instead of N key sequences for cycling among
(1) buffers, (2) windows, ... (N) whatevers,
you just need a single key (simple or complex
- doesn't really matter) for each such command.

No need to dedicate N key sequences to such
things, arguing over whether this or that
really deserves a default binding etc.

Regardless of what windmove, winner, winslow,
winthrop, windchill, wince, windbreaker,
windhover, windjammer, windsurfer, windmill,
or ... actually does, consider giving it a
_completion_ UI instead.  Not knowing the
particulars, I'm guessing you'd win bigtime
- see #1-6, above.
___

"Cycling Completions", here:

https://www.emacswiki.org/emacs/Icicles_-_Cycling_Completions

says this about thinking that cycling is only
about #1:

 Do not become a cycling drone!  Input some text
 to narrow the set of candidates, before cycling
 among them to choose one.  This is a good habit
 to adopt, generally, in Icicles.  Most of the
 power of Icicles comes in your ability to filter
 a set of candidates...

 Cycling and filtering work hand in hand.  If the
 set of candidates is small to begin with, then
 just cycling might be quick enough – that's the
 case if you move among a small set of buffers,
 for instance.  But with Icicles you can profitably
 use cycling on even a very large set of candidates
 – by filtering the set first.

(#1-6 are not only about Icicles, per se.  It's
about leveraging _completion_.)
___

Q: When is completion _not_ a better way to cycle?

A: When it's about incrementing/decrementing
something, not choosing among named things.

For that, one general library is Do Re Mi:

https://www.emacswiki.org/emacs/DoReMi

(I assume there are other general libraries for
this kind of thing.)

From that page:

 In case you’re interested, here’s how the idea
 of Do Re Mi came to me.  I had ‘C-M-’ up, down, 
 left, and right arrow keys assigned to commands 
 ‘shrink-frame’, ‘enlarge-frame’,
 ‘shrink-frame-horizontally’, and
 ‘enlarge-frame-horizontally’ from library
 frame-cmds.el.

 But then I saw a use for another command that
 could also be usefully bound to an arrow key to
 take advantage of press-and-hold for incremental
 change of some kind.

 And another.

 My key combinations with the arrow keys being
 limited, it occurred to me that I needed a key
 sequence (command) that would put me in a mode
 where the arrow keys would be temporarily bound
 to some (repeatable) action.

[ Maybe a bit like transient.el, or repeat-mode,
  or this function that I use a lot to repeatify
  a given command:

  (defun repeat-command (command)
    "Repeat COMMAND."
    (require 'repeat)
    (let ((repeat-previous-repeated-command  command)
          (repeat-message-function           #'ignore)
          (last-repeatable-command           'repeat))
      (repeat nil))))
]