RE: make `occur' use word at point as default

[Drew Adams]

    > Could none of those history-list bindings be sacrificed for accessing
    > "default" values (such as those Juri & Stefan have mentioned,
    > and/or the values in `minibuffer-completion-table')?

    There are two different issues here: accessing the completion values,
    and accessing the default values supplied explicitly via the `default'
    argument of the minibuffer reading functions.  So please make this
    distinction when discussing them.  These are two different sets of
    values (though, one is a subset of another).

    1. a list of all possible completions.
    2. a list of default values.

Yes, there is a difference. That's partly what I meant to indicate by using
quotes around "default" and separating this from the list of completions
with "and/or" - but the difference is clearer as you express it - thanks.

You distinguish the two in terms of their meaning: default value vs a value
that completes an input (i.e. works via completion). These can be different,
a priori.

You also distinguish them operationally: one is accessed via the
default-value argument to completing-read, the other via the obarray
argument (minibuffer-completion-table).

These two distinctions are not the same, so let's distinguish them, too ;-).

The second distinction more or less assumes what we are debating (_how_
users are to access default values). You assume that default values are to
be treated as the default-value arg to completing-read. And, besides begging
the question, your second distinction is a bit premature: until now, the
default-value arg to completing-read has in fact been a single value, not a
list of values.

So, I'll concentrate on the first distinction: default values vs
completions.

Given the fact that "default value" does not necessarily imply "completion",
and vice versa, we can nevertheless _choose_ to consider accessing the two
in the same way - that is, to equate them _operationally_ (i.e., in terms of
use). They are all, in principle, reasonable input values to expect the user
to choose. IOW, having gone through the exercise of distinguishing their
meanings logically, we can still choose to treat "default value"  and
"completion" the same way (giving them the same meaning, some might argue!).

Let's assume that the minibuffer-completion-table passed to completing-read
etc. is intelligently tailored to be a set of values the user would likely
choose. That's not always the case today (the unfocussed obarray is often
passed), but there is nothing standing in the way of programmers passing a
well-chosen minibuffer-completion-table that is truly helpful in some
particular context. Not to mention also passing a useful
minibuffer-completion-predicate.

In some cases, this sequence of completions could perhaps be sorted in some
special way, in terms of likelihood of use, for instance. That might provide
additional help to the user.

In front of these completion values we might place some
even-more-intelligently-crafted choices - the kinds of choices that you and
Stefan suggested, perhaps. That is, there is nothing preventing us from
tacking on super-smart choices to the front of a list of less brilliant
choices. This is just another way of ordering the list.

This gives us a sequence of possible choices, perhaps ordered in some smart
way. I suggest that there is no reason not to make each of these choices
available also as a _completion_ - that is, to let users complete input to
obtain it. This is the main reason for bringing together the two lists you
distinguished above.

Then, the list of completions and the list of possible default values would
be the same: each default value would be a completion target, and each
completion would be a possible default value.

If we did that, then the original question would remain, _how to access_ the
values in this list? Completion would be one way now, thanks to unifying the
two lists.

Cycling via one or two keys could be another way. I suggested reusing one of
the 4 redundant pairs currently dedicated to the history lists - the up/down
arrows, for instance. You mentioned that some external libraries cycle
completions using left/right, C-s/C-r etc. Whatever - in any case, I don't
see a _scarcity_ of such pairs, as Richard suggested.

An alternative, which you suggest, is to use M-n for this cycling (though
you propose it only for the default-value list, which you separate from the
completions list):

    The most natural key to access a list of default values is M-n.
    It could work like M-p for a list of history values, but in the
    opposite direction.

To me, that's less desirable/natural, as it confuses the history list (which
can already be navigated in both directions) with the default-value list. I
personally would prefer to keep the two critters separate, operationally.
However, you're right that M-n accesses the "future" here (possible inputs),
while M-p (and M-n, up to the last input!) accesses past inputs, so that is
also a perfectly _workable_ scheme.

If we chose that scheme, I would hope that it would be chosen based on its
own special merits (whatever they might be), rather than on either:

 - the false perception that there is a scarcity of key-pairs to bind, or

 - an assumption that "default-value" implies the default-value arg to
completing-read and "completion" implies the obarray arg, and
never-the-twain-shall-meet (that is, assuming one side of the point under
discussion: how to access default values)

So, what are those special merits for M-n? Saying that M-n is more "natural"
(and my saying that it is less "natural") doesn't get us very far.

Another reason for dedicating a separate key pair to cycling default values
(as completions), besides the desire to avoid confusion with navigation of
the list of previous choices, would be to foresee the dedication of
different _kinds_ of completion to different key pairs.

In my library, for instance, I use the down/up arrows for cycling among the
values that match the current input using normal, prefix completion. I use
next/prior for cycling among the values that match the input using regexp
completion (sort of an "apropos" completion). There are 3 separate pairs of
keys that cycle possible inputs:

 - M-n/M-p:    previous inputs (history list)
 - down/up:    prefix completions (also C-n/C-p)
 - next/prior: apropos completions

I can imagine that Emacs might itself employ different kinds of completion
some day (still other kinds are imaginable), and we might then want
different key pairs for these.

    There are many packages that
    provide key bindings for accessing next/previous completion items.
    AFAIK, most popular key pairs are [left]/[right], C-s/C-r, TAB/M-TAB.
    You seem to be advocating for unified key bindings for these packages.

I did not advocate or even mention such unification at all, in fact. I
mentioned my library that uses up/down, C-n/C-p, and next/prior. I've seen
other libraries that also use up/down and C-n/C-p. I don't know any
libraries with the bindings you refer to, and I'm not aware of any standard
Emacs libraries that cycle completions. I don't doubt their existence; I'm
just ignorant of them.

Wrt your implied question of whether or not I advocate such unification:

There might conceivably be good reasons for a particular package to use
special bindings, so unification might not be appropriate across the board.
However, if this is not the case - if other things are equal, and if the
packages you refer to are part of Emacs, then yes, why not unify their
bindings? Put me down now as a unification advocate, in that sense.

But, to me, it is most important to let all default values be both:

 - cyclable (accessible, in sequence, by some key binding)
 - targets of completion

What key(s) we bind for cycling those values is a secondary choice.