bug#13333: 24.3.50; (emacs) `Minibuffer History'

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Drew Adams]

There are multiple problems with this node.
 
1. I was trying to find the place in the manual where we mention using
`M-n' to retrieve one or more default values for minibuffer input.  I
tried looking in the index for "default value" and even just "default",
but I found no such entries.
 
This concept of "default input", "default input value" "default
minibuffer input" etc. (choose your own entries) needs to be indexed.
 
Just tucking this behavior away under the topic of minibuffer history is
not sufficient in terms of indexing - it is a convenient hack that `M-n'
doubles as a way to retrieve default values, but looking up information
about the history should not be the only way to stumble upon info about
default input values.  Both concepts regarding minibuffer input: (a)
history (past inputs) and (b) default input values, need to be indexed.
 
2. Searching for "default" in this node, which is presumably the node
where #1 needs to be documented, I find an explanation that isn't very
good.  For one thing, it speaks of "default arguments".  There are no
arguments or parameters here.  These are default values for possible
minibuffer input.  This is user doc.
 
Users should not need to think in terms of `read-from-minibuffer',
`completing-read', or any other such function.  They should not even
need to be aware of these.  They don't care that some function is being
called to read their input, and the default values for their input are
also passed as parts of an argument to such a function.
 
3. We should also not say this, as it is not helpful and can be
confusing:
 
 You can think of this as moving through the "future history" list.
 
There is no logical connection between the set of default values and the
history list - whether "future history" or past.  The only connection is
that we have made the `M-n' key do double duty.  That's a good hack, but
there is zero reason to confuse users by inviting them to think of
retrieving default values as `moving through the "future history" list.'
 
Default values, like completion candidates, are shortcuts to entering
input.  Yes, something you input gets added to a history, but that does
not mean that the concept of a default input value - any more than the
concept of a completion candidate - is the same as that of a past input.
 
Default values are choices as much as completions are.  Neither set is
ordered temporally.  Putting the former on the `M-n' list is a
convenience that is NOT related to the fact that `M-n' can also move
forward along the history list.
 
4. Some keys are written incorrectly.  "`M-p'" is correct.  "<M-n>" is
incorrect (search for it in the node).  Uppercasing "<Up>" and "<Down>"
is also incorrect.  These function keys, like others (<home>, <end>,
etc.) should be lowercase.  That is the way Emacs itself communicates
regarding them, and it is the way Emacs doc should represent them also.
 
(Smarter would be to also get rid of the useless angle brackets, and
just use `...'.  But that's another story.)
 

In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
 of 2012-12-31 on ODIEONE
Bzr revision: 111388 rudalics@gmx.at-20121231113513-subz2dazg6yjukzh
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.7) --no-opt --enable-checking --cflags
 -IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
 

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Drew Adams]

Another thing: Please mention also that you can use a numerical prefix argument
with `M-n', `M-p', etc. to move to a specific history item or default value.

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Juri Linkov]

>  You can think of this as moving through the "future history" list.

"future history" is a misnomer.

> There is no logical connection between the set of default values

"default values" is a misnomer.

There can be only one default value that it used when the user enters
empty input in the minibuffer.  Other values are not "defaults".

In most applications similar functionality is called "suggestions"
where a drop-down list of suggestions is displayed while the user
types a query into a text box.  This feature is documented at
http://en.wikipedia.org/wiki/Search_suggest_drop-down_list

Thus I propose to enhance the documentation by replacing the term
DEFAULTS with (DEFAULT . SUGGESTIONS) where DEFAULT will retain
its original meaning of the value returned for empty input
and SUGGESTIONS is a list of suggestions available via `M-n'.

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Drew Adams]

> >  You can think of this as moving through the "future history" list.
> 
> "future history" is a misnomer.

Yes.

> > There is no logical connection between the set of default values
> 
> "default values" is a misnomer.
> 
> There can be only one default value that it used when the user enters
> empty input in the minibuffer.  Other values are not "defaults".
> 
> In most applications similar functionality is called "suggestions"
> where a drop-down list of suggestions is displayed while the user
> types a query into a text box.  This feature is documented at
> http://en.wikipedia.org/wiki/Search_suggest_drop-down_list
> 
> Thus I propose to enhance the documentation by replacing the term
> DEFAULTS with (DEFAULT . SUGGESTIONS) where DEFAULT will retain
> its original meaning of the value returned for empty input
> and SUGGESTIONS is a list of suggestions available via `M-n'.

I agree with your suggestion.  But please propose it to everyone at emacs-devel.

And please leave this bug open, unless you also correct the problems it
addresses.

(Yes, if your suggestion is implemented that will change some of the text of
this node.  But let's please get all of the problems mentioned taken care of,
whether or not the suggestion gets done.)

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Lars Ingebrigtsen]

Juri Linkov <juri@jurta.org> writes:

>>  You can think of this as moving through the "future history" list.
>
> "future history" is a misnomer.
>
>> There is no logical connection between the set of default values
>
> "default values" is a misnomer.
>
> There can be only one default value that it used when the user enters
> empty input in the minibuffer.  Other values are not "defaults".
>
> In most applications similar functionality is called "suggestions"
> where a drop-down list of suggestions is displayed while the user
> types a query into a text box.  This feature is documented at
> http://en.wikipedia.org/wiki/Search_suggest_drop-down_list
>
> Thus I propose to enhance the documentation by replacing the term
> DEFAULTS with (DEFAULT . SUGGESTIONS) where DEFAULT will retain
> its original meaning of the value returned for empty input
> and SUGGESTIONS is a list of suggestions available via `M-n'.

I think this sounds like a good idea.  "Future history" is cute and all,
but it's not really helpful as a term -- especially when "suggestions"
is as clear as it is.

Anybody with any comments here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#13333: [External] : Re: bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Drew Adams]

> I think this sounds like a good idea.  "Future history" is cute and all,
> but it's not really helpful as a term -- especially when "suggestions"
> is as clear as it is.
> 
> Anybody with any comments here?

You're asking for "more info" now?

I already commented on that suggestion, eight years
ago.  Does that count?

  I agree with your suggestion.  But please propose
  it to everyone at emacs-devel.

  And please leave this bug open, unless you also
  correct the problems it addresses.

  (Yes, if your suggestion is implemented that will
  change some of the text of this node.  But let's
  please get all of the problems mentioned taken
  care of, whether or not the suggestion gets done.)

And the bug report itself (from me), does that count?
It details "multiple problems with this node."

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Gregory Heytings]

>>> You can think of this as moving through the "future history" list.
>>
>> "future history" is a misnomer.
>>
>>> There is no logical connection between the set of default values
>>
>> "default values" is a misnomer.
>>
>> There can be only one default value that it used when the user enters 
>> empty input in the minibuffer.  Other values are not "defaults".
>>
>> In most applications similar functionality is called "suggestions" 
>> where a drop-down list of suggestions is displayed while the user types 
>> a query into a text box.  This feature is documented at 
>> http://en.wikipedia.org/wiki/Search_suggest_drop-down_list
>>
>> Thus I propose to enhance the documentation by replacing the term 
>> DEFAULTS with (DEFAULT . SUGGESTIONS) where DEFAULT will retain its 
>> original meaning of the value returned for empty input and SUGGESTIONS 
>> is a list of suggestions available via `M-n'.
>
> I think this sounds like a good idea.  "Future history" is cute and all, 
> but it's not really helpful as a term -- especially when "suggestions" 
> is as clear as it is.
>
> Anybody with any comments here?
>

FWIW, I do not think this is a good idea.

Emacs is the only application I know which has a unified way to interact 
with history of past actions and suggestions for future actions.  The name 
"future history" is not only cute, it is also an excellent one, from a 
mnemonical viewpoint, to remember that the M-n is the key binding that 
should be used to access those suggestions.  What I would suggest instead 
is to add an explanation between parentheses that "future history" is what 
is called in some other applications "suggestions" (and possibly update 
the glossary accordingly).

The idea of replacing DEFAULT with (DEFAULT . SUGGESTIONS) is also not 
really optimal IMO.  The problem is that DEFAULT would not only be the 
value that is used when the user hits RET with an empty input, it is also 
the first value inserted when hitting M-n, that is, it is also the first 
SUGGESTION.  What I would suggest instead is to replace DEFAULTS with 
FUTURE-HISTORY, with an explanation that the first element of 
FUTURE-HISTORY is used when the user hist RET with an empty input.

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> The idea of replacing DEFAULT with (DEFAULT . SUGGESTIONS) is also not
> really optimal IMO.

I think the suggestion was replacing DEFAULTS with (DEFAULT . SUGGESTIONS),
though...

> The problem is that DEFAULT would not only be the
> value that is used when the user hits RET with an empty input, it is
> also the first value inserted when hitting M-n, that is, it is also
> the first SUGGESTION.

I guess you could look at it that way...  but I'd say that the first
`M-n' gives you the default, and then you get the suggestions.

> What I would suggest instead is to replace DEFAULTS with
> FUTURE-HISTORY, with an explanation that the first element of
> FUTURE-HISTORY is used when the user hist RET with an empty input.

Hm...  I dunno...  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Gregory Heytings]

>> The idea of replacing DEFAULT with (DEFAULT . SUGGESTIONS) is also not 
>> really optimal IMO.
>
> I think the suggestion was replacing DEFAULTS with (DEFAULT . 
> SUGGESTIONS), though...
>

Yes, sorry, that was a typo, I meant "replacing DEFAULTS with (DEFAULT . 
SUGGESTIONS).

>> The problem is that DEFAULT would not only be the value that is used 
>> when the user hits RET with an empty input, it is also the first value 
>> inserted when hitting M-n, that is, it is also the first SUGGESTION.
>
> I guess you could look at it that way...  but I'd say that the first 
> `M-n' gives you the default, and then you get the suggestions.
>

Isn't the default already part of the suggestions?  Unless I'm missing 
something, it's a suggested default.  The current distinction between 
(past) "history" and "future history", where the first item of the future 
history is the default, and in which you can freely navigate back and 
forth with M-p and M-n is, much clearer IMO than a distinction between 
three kinds of items, (past) "history", default and suggestions.  In fact, 
I don't understand what problem this would solve.

I remember when I learned the concept of "future history" and its key 
binding, it was a "wow!" effect.  Because of that it's possibly the only 
key binding I immediately remembered and never forgot.  But perhaps that's 
just me.

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> I remember when I learned the concept of "future history" and its key
> binding, it was a "wow!" effect.  Because of that it's possibly the
> only key binding I immediately remembered and never forgot.  But
> perhaps that's just me.

I think the conclusion here is that there's no great enthusiasm for
changing the terminology here (and we've been using the term "future
history" slightly more actively in the last year), so I'm closing this
bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Howard Melman]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Gregory Heytings <gregory@heytings.org> writes:
>
>> I remember when I learned the concept of "future history" and its key
>> binding, it was a "wow!" effect.  Because of that it's possibly the
>> only key binding I immediately remembered and never forgot.  But
>> perhaps that's just me.
>
> I think the conclusion here is that there's no great enthusiasm for
> changing the terminology here (and we've been using the term "future
> history" slightly more actively in the last year), so I'm closing this
> bug report.

I think the emacs manual could be improved here.

"future history" should be in the index (currently only
"future history for file names" is) pointing to the
Minibuffer History node where it is defined.

Also perhaps "minibuffer suggestions", "minibuffer input
suggestions" or some equivalents could be indexed to point
to the same place to aid in people learning about this still
little-known "wow!" feature.

-- 

Howard

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Lars Ingebrigtsen]

Howard Melman <hmelman@gmail.com> writes:

> I think the emacs manual could be improved here.
>
> "future history" should be in the index (currently only
> "future history for file names" is) pointing to the
> Minibuffer History node where it is defined.
>
> Also perhaps "minibuffer suggestions", "minibuffer input
> suggestions" or some equivalents could be indexed to point
> to the same place to aid in people learning about this still
> little-known "wow!" feature.

Sure, makes sense.  Could you come up with a patch for this?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Howard Melman]

On May 6, 2022, at 6:21 AM, Lars Ingebrigtsen <larsi@gnus.org> wrote:
> 
> Howard Melman <hmelman@gmail.com> writes:
> 
>> I think the emacs manual could be improved here.
>> 
>> "future history" should be in the index (currently only
>> "future history for file names" is) pointing to the
>> Minibuffer History node where it is defined.
>> 
>> Also perhaps "minibuffer suggestions", "minibuffer input
>> suggestions" or some equivalents could be indexed to point
>> to the same place to aid in people learning about this still
>> little-known "wow!" feature.
> 
> Sure, makes sense.  Could you come up with a patch for this?

I'm sorry no, I don't build my own emacs, don't have the source, 
and haven't signed copyright over.  It should just be a couple
of @cindex calls in mini.texi

@cindex future history
@cindex minibuffer suggestions

Howard

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Eli Zaretskii]

> Cc: 13333@debbugs.gnu.org
> From: Howard Melman <hmelman@gmail.com>
> Date: Fri, 6 May 2022 09:40:59 -0400
> 
> > Sure, makes sense.  Could you come up with a patch for this?
> 
> I'm sorry no, I don't build my own emacs, don't have the source, 
> and haven't signed copyright over.  It should just be a couple
> of @cindex calls in mini.texi
> 
> @cindex future history
> @cindex minibuffer suggestions

That's not how good index entries are (or should be) added.  One needs
to think of subjects potential readers will have in mind when they are
looking for the indexed text.  With this in mind, I wonder who would
think about "minibuffer suggestions" in conjunction with this
material?  I wouldn't, because "minibuffer suggestions" tells nothing
to me about what it alludes to.  "Suggestions" is not a good word to
describe this feature.

As for "future history", if we want it, it should _replace_ the
existing index entry, because they both lead to almost the same text,
and it is not useful to have several index entries that begin with the
same text and lead to the same page of the manual.

bug#13333: 24.3.50; (emacs) `Minibuffer History'

[Howard Melman]

> On May 6, 2022, at 9:57 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> Cc: 13333@debbugs.gnu.org
>> From: Howard Melman <hmelman@gmail.com>
>> Date: Fri, 6 May 2022 09:40:59 -0400
>> 
>>> Sure, makes sense.  Could you come up with a patch for this?
>> 
>> I'm sorry no, I don't build my own emacs, don't have the source, 
>> and haven't signed copyright over.  It should just be a couple
>> of @cindex calls in mini.texi
>> 
>> @cindex future history
>> @cindex minibuffer suggestions
> 
> That's not how good index entries are (or should be) added.  One needs
> to think of subjects potential readers will have in mind when they are
> looking for the indexed text.  With this in mind, I wonder who would
> think about "minibuffer suggestions" in conjunction with this
> material?  I wouldn't, because "minibuffer suggestions" tells nothing
> to me about what it alludes to.  "Suggestions" is not a good word to
> describe this feature.
> 
> As for "future history", if we want it, it should _replace_ the
> existing index entry, because they both lead to almost the same text,
> and it is not useful to have several index entries that begin with the
> same text and lead to the same page of the manual.

I disagree. I was responding to the previous comments in this bug
that:

> In most applications similar functionality is called "suggestions"


> "Future history" is cute and all, but it's not really helpful as a term -- 

> especially when "suggestions" is as clear as it is.


The original bug offered: "default input", "default input value" "default
minibuffer input" which I think are also good.

So while you might not think of "minibuffer suggestions" it seems others
would.  I would.

I'd mostly be fine with having these replace the existing index entries for:

@cindex future history for file names
@cindex minibuffer defaults for file names

but I would prefer they didn't.  Just because  they "begin with the same
text" doesn't mean they're useless.  They end with different text and when
one searches for "file name" in the index getting directed to either of 
these is quite useful.

TBH I think the text itself could be expanded a bit.  I'd like to see:

"Emacs tries fetching from a list of default arguments: values that you are 
likely to enter, typically text found near point."

Howard