make `occur' use word at point as default

make `occur' use word at point as default

[Emilio Lopes]

The command `occur' currently uses the last item in the regexp history
as the default value.  I think it would be more useful to offer the
word at point (if any) as default, since the previous history item can
be easily fetched with "M-p".

2005-08-28  Emilio C. Lopes  <eclig@gmx.net>

	* replace.el (occur-read-primary-args): use word at point as
	default.

diff -rN -c old-emacs-darcs.eclig/lisp/replace.el new-emacs-darcs.eclig/lisp/replace.el
*** old-emacs-darcs.eclig/lisp/replace.el	Sun Aug 28 14:30:13 2005
--- new-emacs-darcs.eclig/lisp/replace.el	Sun Aug 28 13:37:51 2005
***************
*** 903,909 ****
        (nreverse result))))
  
  (defun occur-read-primary-args ()
!   (list (let* ((default (car regexp-history))
  	       (input
  		(read-from-minibuffer
  		 (if default
--- 903,909 ----
        (nreverse result))))
  
  (defun occur-read-primary-args ()
!   (list (let* ((default (or (current-word t) (car regexp-history)))
  	       (input
  		(read-from-minibuffer
  		 (if default

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

[Richard M. Stallman]

    The command `occur' currently uses the last item in the regexp history
    as the default value.

Please do not change that.
Peopel are accustomed to just typing RET to search
for the same thing again.

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

[Emilio Lopes]

Richard M Stallman writes:

>     The command `occur' currently uses the last item in the regexp
>     history as the default value.

> Please do not change that.  Peopel are accustomed to just typing RET
> to search for the same thing again.

That's a good point.

But the problem remains: too often I have to first mark a word or symbol,
copy the region, start a command (`grep', `occur', `query-replace',
whatever), paste it, press <enter>.  That's three keystrokes too many.

How do other people accomplish this?

I think something like isearch's "C-w" and friends extended to other
commands which read from the minibuffer would be useful.

Opinions?

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

[Drew Adams]

    >     The command `occur' currently uses the last item in the regexp
    >     history as the default value.
    > Please do not change that.  Peopel are accustomed to just typing RET
    > to search for the same thing again.

    That's a good point.
    But the problem remains: too often I have to first mark a word
    or symbol, copy the region, start a command..., paste it, press
    <enter>.  That's three keystrokes too many. How do other people
    accomplish this?
    I think something like isearch's "C-w" and friends extended to other
    commands which read from the minibuffer would be useful.
    Opinions?

FWIW (since you asked), here is my (singleton, heretical) opinion (again):

1. I prefer to access previous values ("search for the same thing again")
via the history list - only. That's not what the default value is for, IMO.
I agree with Emilio that the default value in the `occur' case should
reflect the current word/symbol, not the last-used value. It's not hard to
hit `M-p' to "search again".

2. I prefer to have the default value placed in the minibuffer
automatically, as input - that is, as INIT-VALUE. Yes, that means that I
must empty the minibuffer (one keystroke), if the default value is not
something I want to use. More often than not, however, I do use it, perhaps
modifying it first.

3. I also cycle among the other `completing-read' "default" values, using
the arrow keys, treating them the same way as the default value (possibly
editing, re-completing, etc.). I use a library that lets me cycle, match,
and complete such values either by prefix (normal completion) or by regexp.

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

[David Kastrup]

"Drew Adams" <drew.adams@oracle.com> writes:

> FWIW (since you asked), here is my (singleton, heretical) opinion (again):
>
> 1. I prefer to access previous values ("search for the same thing again")
> via the history list - only. That's not what the default value is for, IMO.
> I agree with Emilio that the default value in the `occur' case should
> reflect the current word/symbol, not the last-used value. It's not hard to
> hit `M-p' to "search again".

I find that occur should probably heed an active transient region
(quoting its contents), but I don't think it a good idea to use stuff
from the buffer in other cases.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[Mathias Dahl]

Emilio Lopes <eclig@gmx.net> writes:

> I think something like isearch's "C-w" and friends extended to other
> commands which read from the minibuffer would be useful.

I would like that.

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

[Kai Großjohann]

Emilio Lopes <eclig@gmx.net> writes:

> But the problem remains: too often I have to first mark a word or symbol,
> copy the region, start a command (`grep', `occur', `query-replace',
> whatever), paste it, press <enter>.  That's three keystrokes too many.

How about making the thing at point be accessible via M-n?

Kai

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

[Richard M. Stallman]

    > But the problem remains: too often I have to first mark a word or symbol,
    > copy the region, start a command (`grep', `occur', `query-replace',
    > whatever), paste it, press <enter>.  That's three keystrokes too many.

    How about making the thing at point be accessible via M-n?

By convention, M-n is supposed to insert _the default_.
I do not want to make exceptions to that.

We could conceivably make a second M-n insert another possible input
that one might want.  In effect, this would mean putting another
element at the "front" of the history list.  That could be a new
convention that could be generalized to other things.

Now is not the time to implement this, but I'm interested in hearing
if there are any objections to the idea.

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

[Drew Adams]

        > But the problem remains: too often I have to first mark a
        > word or symbol, copy the region, start a command (`grep',
        > `occur', `query-replace', whatever), paste it, press <enter>.
        > That's three keystrokes too many.

        How about making the thing at point be accessible via M-n?

    By convention, M-n is supposed to insert _the default_.
    I do not want to make exceptions to that.

    We could conceivably make a second M-n insert another possible input
    that one might want.  In effect, this would mean putting another
    element at the "front" of the history list.  That could be a new
    convention that could be generalized to other things.

    Now is not the time to implement this, but I'm interested in hearing
    if there are any objections to the idea.

My opinion: Keep the history list (and ways of accessing it) separate from
the default value (and ways of accessing it).

M-n and M-p are for the history list. M-n already pulls the default value
into the minibuffer and adds it (possibly edited) to the history list. This
is enough connection between the two.

In this case, you seem to want the default value to be the _previous_
history value (so that empty input "searches the same thing again"). This
means that M-n, M-p, and empty input will all do more or less the same
thing: use the last (i.e. previous) history value. That's a lot of
convenience for accessing that one value, but it leaves no easy way to use
the word/symbol at point - which several people have mentioned is an obvious
thing to want to do with `occur'.

For `occur', I would use the word/symbol at point as the default value, and
let people use `M-p RET' to get the last history value. Consistent, and not
terribly inconvenient, IMO (one extra keystroke: M-p).

Wrt your general proposal - Given that you don't want the default value to
be automatically inserted into the minibuffer (my preference), you should
stick with M-n to insert it. I think extending this to a second M-n, for a
possible second "default value" would be confusing, with little reward.

However, you might consider giving access to a list of "default values"
(more than just 1 or 2) via _different_ keys from M-n and M-p - the arrow
keys, for instance. A reasonable (default) set of default-value candidates
would be those in `minibuffer-completion-table' (perhaps as filtered by
`minibuffer-completion-predicate').

This is what several existing libraries do, including my icicles library.
You might look to such libraries for ideas on possibilities (food for
thought). The icicles code is here:
http://www.emacswiki.org/cgi-bin/emacs/icicles.el.

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

[Juri Linkov]

> We could conceivably make a second M-n insert another possible input
> that one might want.  In effect, this would mean putting another
> element at the "front" of the history list.  That could be a new
> convention that could be generalized to other things.

This is already implemented by a small 9-line patch I proposed in
http://lists.gnu.org/archive/html/emacs-devel/2004-05/msg01755.html
It allows M-n in the minibuffer to insert input from the list of
default values.  Each consecutive M-n inserts a new default value
from the list.

For `grep' and `occur' there are at least five useful default values:

1. word at point - (current-word t)
2. tag at point - (funcall (or find-tag-default-function
                           (get major-mode 'find-tag-default-function)
                           'find-tag-default))
3. active region - (and transient-mark-mode mark-active
                        (buffer-substring-no-properties
                         (region-beginning) (region-end)))
4. last isearch regexp - (car regexp-search-ring)
5. last kill from the kill ring - (current-kill 0)

With this patch, it is possible to make a list of all these default
values accessible in the minibuffer via M-n.

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

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

[Stefan Monnier]

> 1. word at point - (current-word t)
> 2. tag at point - (funcall (or find-tag-default-function
>                            (get major-mode 'find-tag-default-function)
>                            'find-tag-default))

These are pretty much the same.  More specifically the tag should include
the current-word as a substring, so I'd drop the number 1 and just keep
number 2.

> 3. active region - (and transient-mark-mode mark-active
>                         (buffer-substring-no-properties
>                          (region-beginning) (region-end)))

You could have done M-w before the current operation.  Much simpler/quicker
than doing M-n M-n M-n searching for it.

> 4. last isearch regexp - (car regexp-search-ring)

This one makes sense.  Maybe we could simply use the same ring for occur as
for regexp-search so that it is available as M-p.

> 5. last kill from the kill ring - (current-kill 0)

C-y brings it more quickl;y and reliably than M-n M-n M-n M-n.

I.e. there are really only 2 different useful values and we could make one
of the two available via M-p.


        Stefan

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

[Richard M. Stallman]

    M-n and M-p are for the history list. M-n already pulls the default value
    into the minibuffer and adds it (possibly edited) to the history list. This
    is enough connection between the two.

    In this case, you seem to want the default value to be the _previous_
    history value (so that empty input "searches the same thing again").

Yes, that's what the default is now.

    This
    means that M-n, M-p, and empty input will all do more or less the same
    thing: use the last (i.e. previous) history value.

Each of them follows a convention.  In this case, all three conventions
converge.

    However, you might consider giving access to a list of "default values"
    (more than just 1 or 2) via _different_ keys from M-n and M-p - the arrow
    keys, for instance.

Finding other keys would be difficult.

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

[Drew Adams]

        However, you might consider giving access to a list of
        "default values" (more than just 1 or 2) via _different_
        keys from M-n and M-p - the arrow keys, for instance.

    Finding other keys would be difficult.

Why? There is currently a good deal of redundancy in the bindings for
`next-history-element' and `previous-history-element'. These minibuffer
history-list commands are bound to *FOUR PAIRS* of keys: (1) arrows [up] /
[down], (2) C-n / C-p, (3) M-n / M-p, and (4) [next] / [prior]. (Well,
actually, [prior] is then rebound to `switch-to-completions'.)

[Not to mention M-r, and M-s, which also provide access to previous
minibuffer input (and ESC ESC C-x, which provides access to previously
executed commands).]

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')?

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

[Juri Linkov]

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

2. a list of default values.  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.

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

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

[Juri Linkov]

>> 1. word at point - (current-word t)
>> 2. tag at point - (funcall (or find-tag-default-function
>>                            (get major-mode 'find-tag-default-function)
>>                            'find-tag-default))
>
> These are pretty much the same.  More specifically the tag should include
> the current-word as a substring, so I'd drop the number 1 and just keep
> number 2.

I agree.

>> 3. active region - (and transient-mark-mode mark-active
>>                         (buffer-substring-no-properties
>>                          (region-beginning) (region-end)))
>
> You could have done M-w before the current operation.  Much simpler/quicker
> than doing M-n M-n M-n searching for it.

>> 5. last kill from the kill ring - (current-kill 0)
>
> C-y brings it more quickl;y and reliably than M-n M-n M-n M-n.

Doing M-w/C-y is simpler only for strings that don't contain special
regexp characters.  But in regexps they need to be quoted.  `M-n M-n ...'
could provide a default value with quoted special regexp characters.

>> 4. last isearch regexp - (car regexp-search-ring)
>
> This one makes sense.  Maybe we could simply use the same ring for occur as
> for regexp-search so that it is available as M-p.

There is also another command that reads a regexp and that could share
the same regexp ring - `query-replace'.  It has a special variable
`query-replace-from-history-variable' that defines the history list to use.
So `occur' and `isearch' could have similar variables to allow
occur/multi-occur/keep-lines/flush-lines/how-many and isearch-regexp
to use the same ring with either:

(setq regexp-history-variable 'regexp-history)
(setq regexp-search-ring-variable 'regexp-history)

or:

(setq regexp-history-variable 'regexp-search-ring)
(setq regexp-search-ring-variable 'regexp-search-ring)

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

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.

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

[Richard M. Stallman]

    Why? There is currently a good deal of redundancy in the bindings for
    `next-history-element' and `previous-history-element'. These minibuffer
    history-list commands are bound to *FOUR PAIRS* of keys: (1) arrows [up] /
    [down], (2) C-n / C-p, (3) M-n / M-p, and (4) [next] / [prior]. (Well,
    actually, [prior] is then rebound to `switch-to-completions'.)

C-n and C-p do not run these commands; they do the usual cursor motion.
NEXT could conceivably be used to access another default.
But I think it would be more convenient to add it to the list for
C-p to access.

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

[Drew Adams]

        There is currently a good deal of redundancy in the
        bindings for `next-history-element' and
        `previous-history-element'. These minibuffer history-list
        commands are bound to *FOUR PAIRS* of keys: (1) arrows [up] /
        [down], (2) C-n / C-p, (3) M-n / M-p, and (4) [next] /
        [prior]. (Well, actually, [prior] is then rebound to
        `switch-to-completions'.)

    C-n and C-p do not run these commands; they do the usual cursor motion.

You're right. My bad.

    NEXT could conceivably be used to access another default.
    But I think it would be more convenient to add it to the list for
    C-p to access.

I don't understand the last sentence. Do you mean add the [next] key to some
list? What list? Do you mean C-p or M-p? Sorry, I don't follow you here.

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

[Drew Adams]

        C-n and C-p ... do the usual cursor motion
        [in the minibuffer]

I replied:

    You're right. My bad.

I should have added that I doubt that such up and down cursor motions are
very useful in the minibuffer.

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

[Benjamin Riefenstahl]

Hi Drew,

"Drew Adams" writes:
> I should have added that I doubt that such up and down cursor
> motions are very useful in the minibuffer.

I regularly edit multi-line text in the minibuffer when I use
replace-string and eval-expression. 

benny

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

[Richard M. Stallman]

	NEXT could conceivably be used to access another default.
	But I think it would be more convenient to add it to the list for
	C-p to access.

    I don't understand the last sentence. Do you mean add the [next] key to some
    list? What list? Do you mean C-p or M-p? Sorry, I don't follow you here.

I meant M-p.  Sorry.

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

[Drew Adams]

    	NEXT could conceivably be used to access another default.

It's a good idea to reserve [next] for a complementary use with [prior] -
that's a natural pair, and such pairs are relatively scarce. What's more,
their names are perfect for forward-backward operations that do what they
say.

FWIW, I use [insert], instead of [prior], in the minibuffer for
`switch-to-completions'. And I use [insert] in *Completions* to switch back
to the minibuffer. Semi-lame mnemonic: "insert" cursor....

    	But I think it would be more convenient to [use M-n to]
      add [additional default values] to the list for [M-p] to access.

It should be the user's acceptance (via RET) of an input candidate that puts
an input onto the history list (for use by M-p) - it shouldn't be the mere
act of Emacs making an input candidate available or the user's looking at a
candidate via M-n. (I think that's already the case - just wanted to
emphasize it.)

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

[Richard M. Stallman]

	    But I think it would be more convenient to [use M-n to]
	  add [additional default values] to the list for [M-p] to access.

We seem to be miscommunicating; your additions turn this into
something very different from what I was talking about.

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

[Drew Adams]

    	    But I think it would be more convenient to [use M-n to]
    	    add [additional default values] to the list for [M-p] to access.

    We seem to be miscommunicating; your additions turn this into
    something very different from what I was talking about.

Sorry; I tried. Could you please rephrase what you meant? We're getting lost
in the translations.

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

[Juri Linkov]

> It should be the user's acceptance (via RET) of an input candidate that puts
> an input onto the history list (for use by M-p) - it shouldn't be the mere
> act of Emacs making an input candidate available or the user's looking at a
> candidate via M-n. (I think that's already the case - just wanted to
> emphasize it.)

Yes, and I want to add that if the user types RET with empty input,
then it should put onto the history list not the whole list of default
values, but only the first element of such list, i.e. the same element
that minibuffer-reading functions return.

BTW, currently there is an inconsistency in the `read-from-minibuffer'
function.  Typing RET with empty input after evaluation of:

(read-from-minibuffer "prompt: " nil nil nil nil "default")

adds the string "default" to the history list, even though this function
returns an empty string.  I don't know whether this should be fixed or
maybe it causes no problems.

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

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

[Juri Linkov]

> 	    But I think it would be more convenient to [use M-n to]
> 	  add [additional default values] to the list for [M-p] to access.
>
> We seem to be miscommunicating; your additions turn this into
> something very different from what I was talking about.

Drew's response to your message seems right, but his reconstruction
of your message is not.  Could you confirm that you really meant this:

  But I think it would be more convenient to [use M-n to]
  access [additional default values] from the list [of default values].

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

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

[Richard M. Stallman]

      But I think it would be more convenient to [use M-n to]
      access [additional default values] from the list [of default values].

Yes, that's what I had in mind.