Re: completing-read depricated initial-input

Re: completing-read depricated initial-input

[Anders Munch]

carlmarcos wrote:
> New users do not usually know many keybinding sequences such as `M-n` to show `DEF`.

I'm not sure why an old user would know M-n either.   It's not very discoverable.

regards, Anders

Re: completing-read depricated initial-input

[Jean Louis]

On June 21, 2022 2:56:59 PM UTC, Anders Munch <ajm@flonidan.dk> wrote:
>carlmarcos wrote:
>> New users do not usually know many keybinding sequences such as `M-n`
>to show `DEF`.
>
>I'm not sure why an old user would know M-n either.   It's not very
>discoverable.

It is in manual for mining history, as long time Emacs user I am using this so often, every day, together with M-p, and I even forgot how I learned it.

Reason that I maybe use it more then average users is that my Dynamic Knowledge Repository  handes database backed selections, for example choice of a country, or language.


Jean

Re: completing-read depricated initial-input

[Anders Munch]

Eli Zaretskii wrote:
> It's supposed to guess what you would want to type next.  Thus its name.

What I meant is that I tried various things that used the minibuffer to see what kind of guess they came up with, and then I relayed my experiences.
It wasn't useful to me, but that doesn't mean it's not useful to others.  I didn't mean to imply otherwise.

regards, Anders

Re: completing-read depricated initial-input

[Anders Munch]

I wrote:
> xref-find-definitions is especially weird: It 
> walks through most or maybe all of the symbols in my TAGS file in 
> something like the order they are found in the file. Anyone know 
> what's up with that?

Emanuel Berg wrote:
> On the contrary, it's _vertical_ and known as linear or sequential search.

Don't be condescending.  
Especially since you are technically wrong <wink>: For it to be a _search_ you need to be searching for something.  I was just walking through the entries one by one.

What I saw was in file order, but not including every symbol in the file: Every class name was there, but not every method name.  The missing methods might have shown up further down the sequence, but I did not take the time to M-n through every single entry to see if that would happen, since there's 145,827 entries in the particular TAGS file.

regards, Anders

Re: completing-read depricated initial-input

[Anders Munch]

Jean Louis wrote:
> It is in manual for mining history, as long time Emacs user I am using this so often, every day, together with M-p, and I even forgot how I learned it.

Mining?  Oh, you mean minibuffer history, section 8.5, I suppose that was an autocorrect?  That is some kind of discoverable, I guess, but a weak one.

Trying it out, I can't seem to come up with any minibuffer-using commands where this "future history" contains anything useful, so I guess that explains why I never memorised the feature.  xref-find-definitions is especially weird: It walks through most or maybe all of the symbols in my TAGS file in something like the order they are found in the file.  Anyone know what's up with that?

regards, Anders

Re: completing-read depricated initial-input

[Emanuel Berg]

Anders Munch wrote:

>> It is in manual for mining history, as long time Emacs user
>> I am using this so often, every day, together with M-p, and
>> I even forgot how I learned it.
>
> Mining? Oh, you mean minibuffer history, section 8.5,
> I suppose that was an autocorrect? That is some kind of
> discoverable, I guess, but a weak one.

Jean has real experience from mining so for him it's trivial
to extract.

  (info "(emacs) Minibuffer History")

> Trying it out, I can't seem to come up with any
> minibuffer-using commands where this "future history"
> contains anything useful, so I guess that explains why
> I never memorised the feature. xref-find-definitions is
> especially weird: It walks through most or maybe all of the
> symbols in my TAGS file in something like the order they are
> found in the file. Anyone know what's up with that?

On the contrary, it's _vertical_ and known as linear or
sequential search.

https://en.wikipedia.org/wiki/Linear_search

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Eli Zaretskii]

> From: Anders Munch <ajm@flonidan.dk>
> Date: Wed, 22 Jun 2022 10:02:07 +0000
> 
> Trying it out, I can't seem to come up with any minibuffer-using commands where this "future history" contains anything useful

It's supposed to guess what you would want to type next.  Thus its
name.

completing-read depricated initial-input

[carlmarcos--- via Users list for the GNU Emacs text editor]

Have been reading the docstring of `completing-read`.

(completing-read PROMPT COLLECTION &optional PREDICATE REQUIRE-MATCH
INITIAL-INPUT HIST DEF INHERIT-INPUT-METHOD)

INITIAL-INPUT states that this feature is deprecated - it is best to pass nil
for INITIAL-INPUT and supply the default value DEF instead.  

When do you plan to remove the `INITIAL-INPUT` argument from `completing-read`?

Re: completing-read depricated initial-input

[carlmarcos--- via Users list for the GNU Emacs text editor]

Jun 21, 2022, 07:56 by help-gnu-emacs@gnu.org:

>
> Have been reading the docstring of `completing-read`.
>
> (completing-read PROMPT COLLECTION &optional PREDICATE REQUIRE-MATCH
> INITIAL-INPUT HIST DEF INHERIT-INPUT-METHOD)
>
> INITIAL-INPUT states that this feature is deprecated - it is best to pass nil
> for INITIAL-INPUT and supply the default value DEF instead.  
>
> When do you plan to remove the `INITIAL-INPUT` argument from `completing-read`?
>
I differ with the plan to depricate `INITIAL-INPUT`.  This is because it is useful to immediately
show a value when using `completing-read`.  New users do not usually know many keybinding sequences such as `M-n` to show `DEF`.  Besides the utility of having an initial value that is different from a default.

Particularly when using `t` for `REQUIRE-MATCH`, it is useful to already have an initial value.  An alternative is to allow the first entry in the sequence to show up, but then continue with the second element in the list when the user wants to traverse through the remaining options.

For cases where `REQUIRE-MATCH` is `nil`, it is reasonable not to put anything in the user entry of `complete-read`.
 

Re: completing-read depricated initial-input

[Michael Heerdegen]

carlmarcos--- via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> I differ with the plan to depricate `INITIAL-INPUT`.

I often miss it, too.  I don't recall why it had been deprecated.  But
you still can get the same thing using `minibuffer-setup-hook', e.g.

#+begin_src emacs-lisp
(minibuffer-with-setup-hook (lambda () (insert "b"))
  (completing-read "Input: " (list "a" "b")))
#+end_src

Michael.

Re: completing-read depricated initial-input

[Emanuel Berg]

Michael Heerdegen wrote:

>> I differ with the plan to depricate `INITIAL-INPUT`.
>
> I often miss it, too. I don't recall why it had been
> deprecated.

This isn't explained somewhere?

I mean just a one-liner would probably do most cases ...

"Funked up formal parameter."

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Michael Heerdegen]

Emanuel Berg <incal@dataswamp.org> writes:

> > I often miss it, too. I don't recall why it had been
> > deprecated.
>
> This isn't explained somewhere?

In my Emacs it is - in the docstring of the function.

Michael.

Re: completing-read depricated initial-input

[Jean Louis]

On June 21, 2022 9:51:07 AM UTC, carlmarcos--- via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
>
>Jun 21, 2022, 07:56 by help-gnu-emacs@gnu.org:
>
>>
>> Have been reading the docstring of `completing-read`.
>>
>> (completing-read PROMPT COLLECTION &optional PREDICATE REQUIRE-MATCH
>> INITIAL-INPUT HIST DEF INHERIT-INPUT-METHOD)
>>
>> INITIAL-INPUT states that this feature is deprecated - it is best to
>pass nil
>> for INITIAL-INPUT and supply the default value DEF instead.  
>>
>> When do you plan to remove the `INITIAL-INPUT` argument from
>`completing-read`?
>>
>I differ with the plan to depricate `INITIAL-INPUT`.  This is because
>it is useful to immediately
>show a value when using `completing-read`.  New users do not usually
>know many keybinding sequences such as `M-n` to show `DEF`.  Besides
>the utility of having an initial value that is different from a
>default.

I agree to this notion as being heavy user of this function.


Jean

Re: completing-read depricated initial-input

[Emanuel Berg]

Jean Louis wrote:

> New users do not usually know many keybinding sequences such
> as `M-n` to show `DEF`.

Maybe not but why can only do it as good and fast and powerful
as possible, what some people may or may not know at some
point of their learning curve can't influence that.

>> Besides the utility of having an initial value that is
>> different from a default.
>
> I agree to this notion as being heavy user of this function.

No ... it doesn't work like that, if you can't say what that
is it shouldn't be there. The default is the default, what is
the initial value? Useful? Oh-no.

What's wrong with this and when doesn't it work? I dare you ...

(let ((name "Danger"))
  (read-string (format "name: [%s] " name) nil nil name) )

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Robert Pluim]

>>>>> On Tue, 21 Jun 2022 09:56:59 +0200 (CEST), carlmarcos--- via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> said:

    >> Have been reading the docstring of `completing-read`.

    >> (completing-read PROMPT COLLECTION &optional PREDICATE REQUIRE-MATCH
    >> INITIAL-INPUT HIST DEF INHERIT-INPUT-METHOD)

    >> INITIAL-INPUT states that this feature is deprecated - it is best to pass nil
    >> for INITIAL-INPUT and supply the default value DEF instead.  

    >> When do you plan to remove the `INITIAL-INPUT` argument from `completing-read`?

No such plan exists. At best Emacs could start ignoring that arg, but
we canʼt just change the signature of such a public function.

Robert
-- 

Re: completing-read depricated initial-input

[carlmarcos--- via Users list for the GNU Emacs text editor]

-- 
 Sent with Tutanota, enjoy secure & ad-free emails. 



Jun 21, 2022, 10:26 by rpluim@gmail.com:

>>>>>> On Tue, 21 Jun 2022 09:56:59 +0200 (CEST), carlmarcos--- via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> said:
>>>>>>
>
> >> Have been reading the docstring of `completing-read`.
>
>  >> (completing-read PROMPT COLLECTION &optional PREDICATE REQUIRE-MATCH
>  >> INITIAL-INPUT HIST DEF INHERIT-INPUT-METHOD)
>
>  >> INITIAL-INPUT states that this feature is deprecated - it is best to pass nil
>  >> for INITIAL-INPUT and supply the default value DEF instead.  
>
>  >> When do you plan to remove the `INITIAL-INPUT` argument from `completing-read`?
>
> No such plan exists. At best Emacs could start ignoring that arg, but
> we canʼt just change the signature of such a public function.
>
> Robert
>
Have put some explanation on the value of keeping the functionality of `INITIAL-INPUT`, rather than
stopping it having any effect.  I can see the value of using an initial value for certain situations, rather than  always having the field empty, particularly when one has `REQUIRE-MATCH` being `t`.

Re: completing-read depricated initial-input

[Christopher Dimech]

Jun 21, 2022, 11:19 by michael_heerdegen@web.de:

    carlmarcos--- via Users list for the GNU Emacs text editor
    <help-gnu-emacs@gnu.org> writes:

        I differ with the plan to depricate `INITIAL-INPUT`.


    I often miss it, too. I don't recall why it had been deprecated. But
    you still can get the same thing using `minibuffer-setup-hook', e.g.

    #+begin_src emacs-lisp
    (minibuffer-with-setup-hook (lambda () (insert "b"))
    (completing-read "Input: " (list "a" "b")))
    #+end_src

    Michael.


Eli and Stefan, those working with `completing-read` can see the value of
having the functionality of INITIAL-INPUT in completing-read.  Could you
contemplate not deprecating the functionality INITIAL-INPUT.  Because the
argument does have usefulness, which will be possible to do if deprecated.

RE: [External] : Re: completing-read depricated initial-input

[Drew Adams]

>> I differ with the plan to depricate `INITIAL-INPUT`.
> 
> I often miss it, too. I don't recall why it had been deprecated.
> But you still can get the same thing using `minibuffer-setup-hook',
> e.g.
> 
>     (minibuffer-with-setup-hook (lambda () (insert "b"))
>     (completing-read "Input: " (list "a" "b")))
> 
> Eli and Stefan, those working with `completing-read` can
> see the value of having the functionality of INITIAL-INPUT
> in completing-read.  Could you contemplate not deprecating
> the functionality INITIAL-INPUT.  Because the argument does
> have usefulness, which will be possible to do if deprecated.

1. Deprecated doesn't mean it will be removed.
   Removal generally means desupport.  Deprecation
   generally means that it might be desupported at
   some time.  Deprecation is a heads-up that you
   might want to start moving your code away from
   depending on its existence.

2. I argued long ago that it shouldn't be deprecated.
   Unsuccessfully.

3. The "argument" for deprecating it amounted to only
   a statement that stylistically some preferred that
   only the DEF (default value) argument be used.

   Even if one agrees with such a stylistic guideline
   it should just be a guideline.  There never was a
   good reason to deprecate it.  And really the doc
   should describe circumstances where it might make
   sense not to use it and circumstances where it
   might be useful.
___

4. FWIW, this is the INITIAL-INPUT part of the doc
   string of `completing-read' used in Icicles.

If INITIAL-INPUT is non-nil, insert it in the minibuffer initially,
with point positioned at the end.  If it is (STRING . POSITION), the
initial input is STRING, but point is placed at zero-indexed position
POSITION in STRING.  (This is different from `read-from-minibuffer'
and related functions, which use one-indexing for POSITION.)

INITIAL-INPUT is considered deprecated by vanilla Emacs, but not by
Icicles.  If INITIAL-INPUT is nil and DEF is non-nil, the user can use
`next-history-element' to yank DEF into the minibuffer.

HIST, if non-nil, specifies a history list and optionally the initial
position in the list.  It can be a symbol, which is the history list
variable to use, or it can be a cons cell (HISTVAR . HISTPOS).  If a
cons cell, HISTVAR is the history list variable to use, and HISTPOS is
the initial position (the position in the list used by the minibuffer
history commands).  For consistency, you should also specify that
element of the history as the value of INITIAL-INPUT.  Positions are
counted starting from 1 at the beginning of the list.  The variable
`history-length' controls the maximum length of a history list.

DEF, if non-nil, is the default value or (Emacs 23+ only) the list of
default values.  Option `icicle-default-value' controls the treatment
of the default value (or the first default value, if DEF is a list):
whether it is shown in the prompt, substituted for an empty
INITIAL-INPUT, and so on.  If `icicle-default-value' is t then option
`icicle-default-in-prompt-format-function' is used to format DEF for
its addition to PROMPT.

Re: completing-read depricated initial-input

[Arash Esbati]

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

> 3. The "argument" for deprecating it amounted to only
>    a statement that stylistically some preferred that
>    only the DEF (default value) argument be used.

I thought the argument was "INITIAL-INPUT in too intrusive in the
minibuffer, most notably, when it's not what the user wants, and then
the hassle with C-a C-k and such begins".  And if I compare:

(let ((default "FOO"))
  (completing-read (format "Prompt (default %s): " default)
                   '("FOO" "BAR" "BAZ")
                   nil nil nil nil default))

where I hit ENTER or TAB makes more sense to me than this:

(let ((default "FOO"))
  (completing-read "Prompt: "
                   '("FOO" "BAR" "BAZ")
                   nil nil default))

where I hit ENTER or have to delete the entry before I can proceed with
TAB.

As a personal note, the INITIAL-INPUT was something in AUCTeX which
bugged for me for a long time, especially in queries for length
arguments.  I can't say how often I've deleted "1.0\linewidth" in my
life.

Best, Arash

Re: completing-read depricated initial-input

[Emanuel Berg]

Arash Esbati wrote:

> (let ((default "FOO"))
>   (completing-read (format "Prompt (default %s): " default)
>                    '("FOO" "BAR" "BAZ")
>                    nil nil nil nil default))

Not pretty!

Not saying it should be changed for that reason but for future
(other) Elisp maybe `cl--parsing-keywords', an alist or just
something ... else ... comes to mind!

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: completing-read depricated initial-input

[Drew Adams]

> > 3. The "argument" for deprecating it amounted to only
> >    a statement that stylistically some preferred that
> >    only the DEF (default value) argument be used.
       ^^^^
>
> I thought the argument was "INITIAL-INPUT in too
> intrusive in the minibuffer, most notably, when
> it's not what the user wants, and then the hassle
> with C-a C-k and such begins".

That's an argument about UI interaction style.  And
the "only" is the real key to what's misguided.

Different users can prefer different interactions.
Different coders can prefer different interactions
for different calls to `completing-read'.

There is no one-size-fits-all.  `completing-read'
is extremely general, allowing for many different
interactions for many different kinds of use cases.

Even if Godot proclaimed that ONE style of use is
"better" for most interactions, that's not, in
itself, a reason to not provide also for what
INITIAL-INPUT offers.
___

BTW, independently of this discussion (and even
independently of completion), there should be a
single key to empty the minibuffer.  (Icicles
has provided `M-k' for that forever.)  

> And if I compare:
> 
> (let ((default "FOO"))
>   (completing-read (format "Prompt (default %s): " default)
>                    '("FOO" "BAR" "BAZ")
>                    nil nil nil nil default))
>
> where I hit ENTER or TAB makes more sense to me than this:
> 
> (let ((default "FOO"))
>   (completing-read "Prompt: "
>                    '("FOO" "BAR" "BAZ")
>                    nil nil default))
> 
> where I hit ENTER or have to delete the entry
> before I can proceed with TAB.

That may make more sense to you.  It may always
make more sense to you.  It may make more sense
to you in that example.

Those preferences might be arguments in favor
of providing ways for a user to configure such
preferences.

None of them is an argument why INITIAL-INPUT
should be deprecated.

> As a personal note, the INITIAL-INPUT was something in AUCTeX which
> bugged for me for a long time, especially in queries for length
> arguments.  I can't say how often I've deleted "1.0\linewidth" in my
> life.

That you don't want INITIAL-INPUT is one thing.
That some library might not make a good decision
about its use is another thing.

Whether INITIAL-INPUT should be deprecated is
a third thing - something completely different.

Re: completing-read depricated initial-input

[Arash Esbati]

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

>> > 3. The "argument" for deprecating it amounted to only
>> >    a statement that stylistically some preferred that
>> >    only the DEF (default value) argument be used.
>       ^^^^
>>
>> I thought the argument was "INITIAL-INPUT in too
>> intrusive in the minibuffer, most notably, when
>> it's not what the user wants, and then the hassle
>> with C-a C-k and such begins".
>
> That's an argument about UI interaction style.  And
> the "only" is the real key to what's misguided.

I agree that there are cases where INITIAL-INPUT still has its place,
but as I said, I remember the reason for phasing it out was different
than stylistic preferences.

> `completing-read' is extremely general, allowing for many different
> interactions for many different kinds of use cases.

True, unfortunately.

> BTW, independently of this discussion (and even
> independently of completion), there should be a
> single key to empty the minibuffer.  (Icicles
> has provided `M-k' for that forever.)  

I presume you've suggested this addition to Emacs?

>> As a personal note, the INITIAL-INPUT was something in AUCTeX which
>> bugged for me for a long time, especially in queries for length
>> arguments.  I can't say how often I've deleted "1.0\linewidth" in my
>> life.
>
> That you don't want INITIAL-INPUT is one thing.
> That some library might not make a good decision
> about its use is another thing.
>
> Whether INITIAL-INPUT should be deprecated is
> a third thing - something completely different.

Not sure about this one.  I mean, Emacs has a lot of external (i.e., not
maintained in core) libraries and it would be a major advantage if they
all feel the same when you use them.  Hence, I understand the general
direction of "deprecating a feature" to streamline the look&feel, but
you're still free to use the old feature if you think it has a added
value from a user perspective.  In my example above, it wasn't a good
decision, so I changed it.

Best, Arash

RE: [External] : Re: completing-read depricated initial-input

[Drew Adams]

> >> > 3. The "argument" for deprecating it amounted to only
> >> >    a statement that stylistically some preferred that
> >> >    only the DEF (default value) argument be used.
> >       ^^^^
> >>
> >> I thought the argument was "INITIAL-INPUT in too
> >> intrusive in the minibuffer, most notably, when
> >> it's not what the user wants, and then the hassle
> >> with C-a C-k and such begins".
> >
> > That's an argument about UI interaction style.  And
> > the "only" is the real key to what's misguided.
> 
> I agree that there are cases where INITIAL-INPUT still has its place,
> but as I said, I remember the reason for phasing it out was different
> than stylistic preferences.

What you say you remember states a choice of
one style over another. And it's not a choice
by an individual user or the coder of an
individual `completing-read' invocation.

So would be making such a choice just as the
default style (behavior).  Deprecating
something is not the same thing as choosing
another thing as just the default behavior.

> > `completing-read' is extremely general, allowing for many different
> > interactions for many different kinds of use cases.
> 
> True, unfortunately.

Why "unfortunately"?  There are lots of
functions that do more specific kinds of read
with completion.  `completing-read' is a very
general function, on purpose.  And it's been
getting more and more general.

And there's `read-from-minibuffer', which is
even more general.

`read-file-name' is a specific kind of
completion, but one which is also still quite
general, allowing multiple behaviors.

> > BTW, independently of this discussion (and even
> > independently of completion), there should be a
> > single key to empty the minibuffer.  (Icicles
> > has provided `M-k' for that forever.)
> 
> I presume you've suggested this addition to Emacs?

I did.  I think I've pretty much suggested
everything I've ever implemented.  I'd rather
have Emacs implement, test, and maintain it
than do so myself, if possible. ;-)

> >> As a personal note, the INITIAL-INPUT was something in AUCTeX which
> >> bugged for me for a long time, especially in queries for length
> >> arguments.  I can't say how often I've deleted "1.0\linewidth" in my
> >> life.
> >
> > That you don't want INITIAL-INPUT is one thing.
> > That some library might not make a good decision
> > about its use is another thing.
> >
> > Whether INITIAL-INPUT should be deprecated is
> > a third thing - something completely different.
> 
> Not sure about this one.  I mean, Emacs has a lot of
> external (i.e., not maintained in core) libraries and
> it would be a major advantage if they all feel the
> same when you use them.

That's a different question.

> Hence, I understand the general direction of
> "deprecating a feature" to streamline the look&feel,

If it's about the look&feel, and not about the need
to maintain something, then it's enough to set the
default behavior.  That's not deprecating another
behavior.

> but you're still free to use the old feature if you
> think it has a added value from a user perspective.

Sure.  With the risk that what's deprecated might be
desupported at some point.

(At which point you can always choose to copy the old
code and continue to use it.  With the bother of
dealing with incompatibilities, inconsistencies, and
having to keep some bits synchronized...) 

Re: completing-read depricated initial-input

[Arash Esbati]

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

>> > `completing-read' is extremely general, allowing for many different
>> > interactions for many different kinds of use cases.
>> 
>> True, unfortunately.
>
> Why "unfortunately"?

Because extremely general tools give one many ways to do things.  It is
just hard if you find out afterwards that things went in the wrong
direction and you try to clean up.  No other reason.

> And there's `read-from-minibuffer', which is
> even more general.

Therefore we have `read-string'.

> I'd rather have Emacs implement, test, and maintain it than do so
> myself, if possible. ;-)

Good strategy ;-)

>> but you're still free to use the old feature if you
>> think it has a added value from a user perspective.
>
> Sure.  With the risk that what's deprecated might be
> desupported at some point.
>
> (At which point you can always choose to copy the old
> code and continue to use it.  With the bother of
> dealing with incompatibilities, inconsistencies, and
> having to keep some bits synchronized...)

I don't think this will happen for `completing-read'.  Looking at other
places than the docstring of `completing-read', you find:

 • Emacs Lisp Ref:

   21.5 Initial Input[1]

   Several of the functions for minibuffer input have an argument called
   initial. This is a mostly-deprecated feature for specifying that the
   minibuffer should start out with certain text, instead of empty as
   usual. [...]

   We discourage use of a non-nil value for initial, because initial
   input is an intrusive interface. History lists and default values
   provide a much more convenient method to offer useful default inputs
   to the user.

   There is just one situation where you should specify a string for an
   initial argument. This is when you specify a cons cell for the
   history argument. See Minibuffer History.

   21.6.2 Completion and the Minibuffer[2]

   Function: completing-read [...]
   The argument initial is mostly deprecated; we recommend using a
   non-nil value only in conjunction with specifying a cons cell for
   history. See Initial Input. For default input, use default instead.

  • `read-string' docstring:

    Read a string from the minibuffer, prompting with string PROMPT.
    If non-nil, second arg INITIAL-INPUT is a string to insert before reading.
      This argument has been superseded by DEFAULT-VALUE and should
      normally be nil in new code.  It behaves as INITIAL-CONTENTS in
      ‘read-from-minibuffer’ (which see).

Note the terms "mostly-deprecated", "discourage", "recommend",
"superseded".  So maybe the docstring of `completing-read' should be
adjusted to the statements above in order to avoid confusion?

Best, Arash

Footnotes:
[1]  https://www.gnu.org/software/emacs/manual/html_node/elisp/Initial-Input.html
[2]  https://www.gnu.org/software/emacs/manual/html_node/elisp/Minibuffer-Completion.html

Re: completing-read depricated initial-input

[carlmarcos--- via Users list for the GNU Emacs text editor]

Jun 23, 2022, 07:59 by arash@gnu.org:

> Drew Adams <drew.adams@oracle.com> writes:
>
>>> > `completing-read' is extremely general, allowing for many different
>>> > interactions for many different kinds of use cases.
>>>
>>> True, unfortunately.
>>>
>>
>> Why "unfortunately"?
>>
>
> Because extremely general tools give one many ways to do things.  It is
> just hard if you find out afterwards that things went in the wrong
> direction and you try to clean up.  No other reason.
>
>> And there's `read-from-minibuffer', which is
>> even more general.
>>
>
> Therefore we have `read-string'.
>
>> I'd rather have Emacs implement, test, and maintain it than do so
>> myself, if possible. ;-)
>>
>
> Good strategy ;-)
>
>>> but you're still free to use the old feature if you
>>> think it has a added value from a user perspective.
>>>
>>
>> Sure.  With the risk that what's deprecated might be
>> desupported at some point.
>>
>> (At which point you can always choose to copy the old
>> code and continue to use it.  With the bother of
>> dealing with incompatibilities, inconsistencies, and
>> having to keep some bits synchronized...)
>>
>
> I don't think this will happen for `completing-read'.  Looking at other
> places than the docstring of `completing-read', you find:
>
>  • Emacs Lisp Ref:
>
>  21.5 Initial Input[1]
>
>  Several of the functions for minibuffer input have an argument called
>  initial. This is a mostly-deprecated feature for specifying that the
>  minibuffer should start out with certain text, instead of empty as
>  usual. [...]
>
>  We discourage use of a non-nil value for initial, because initial
>  input is an intrusive interface. History lists and default values
>  provide a much more convenient method to offer useful default inputs
>  to the user.
>
>   21.6.2 Completion and the Minibuffer[2]
>
>  Function: completing-read [...]
>  The argument initial is mostly deprecated; we recommend using a
>  non-nil value only in conjunction with specifying a cons cell for
>  history. See Initial Input. For default input, use default instead.
>
This is where I disagree.  The documentation discouraging and recommending
not to use it, reads as a statement that lacks any persuasive discussion.

It is not valuable to discourage something simply because it is usually found that
 it is empty.  A designer might know better what he is trying to achieve.  At times it
is better to display some indicative words to the user, than nothing at all (an empty field).

INITIAL-INPUT allows one to display a personally preferable feature whilst keeping
the usual default intact. One must not confuse "initial" with "default".  An initial value
could be assigned to some preferential usage that differs from some well known canonical
 setting.

    



>  • `read-string' docstring:
>
>  Read a string from the minibuffer, prompting with string PROMPT.
>  If non-nil, second arg INITIAL-INPUT is a string to insert before reading.
>  This argument has been superseded by DEFAULT-VALUE and should
>  normally be nil in new code.  It behaves as INITIAL-CONTENTS in
>  ‘read-from-minibuffer’ (which see).
>
> Note the terms "mostly-deprecated", "discourage", "recommend",
> "superseded".  So maybe the docstring of `completing-read' should be
> adjusted to the statements above in order to avoid confusion?
>
I do not see that the deprecation was superceded through some improved
 coding mechanism.


> Best, Arash
>
> Footnotes:
> [1]  https://www.gnu.org/software/emacs/manual/html_node/elisp/Initial-Input.html
> [2]  https://www.gnu.org/software/emacs/manual/html_node/elisp/Minibuffer-Completion.html
>

Re: completing-read depricated initial-input

[Emanuel Berg]

carlmarcos--- via Users list for the GNU Emacs text editor wrote:

> One must not confuse "initial" with "default".

I have heard the word "initial" before but what's the
use case? Is it the completion stuff already mentioned?

If so then that argument can safely be moved, preferable to
the dust heap of programming history.

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Michael Heerdegen]

Arash Esbati <arash@gnu.org> writes:

> Note the terms "mostly-deprecated", "discourage", "recommend",
> "superseded".  So maybe the docstring of `completing-read' should be
> adjusted to the statements above in order to avoid confusion?

The purpose of `completing-read' is a bit different from `read-string'
and `read-from-minibuffer'.  Providing INITIAL-INPUT is useful for the
latter, but much less for `completing-read' in my opinion.  If at all
(anybody who has a believable real-life example?).

Michael.

Re: completing-read depricated initial-input

[Arash Esbati]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> The purpose of `completing-read' is a bit different from `read-string'
> and `read-from-minibuffer'.  Providing INITIAL-INPUT is useful for the
> latter, but much less for `completing-read' in my opinion.  If at all
> (anybody who has a believable real-life example?).

If you have a common prefix which should be shown in the candidates
list, in (La)TeX for instance:

(let ((list '("iffalse" "iftrue" "else" "fi")))
  (completing-read "Macro: "
                   (mapcar (lambda (x) (concat "\\" x)) list)
                   nil nil "\\"))

Something like this looks odd:

(let ((list '("iffalse" "iftrue" "else" "fi")))
  (completing-read "Macro: \\" list))

Best, Arash

Re: completing-read depricated initial-input

[Michael Heerdegen]

Arash Esbati <arash@gnu.org> writes:

> (let ((list '("iffalse" "iftrue" "else" "fi")))
>   (completing-read "Macro: "
>                    (mapcar (lambda (x) (concat "\\" x)) list)
>                    nil nil "\\"))

A convincing example, in my opinion.

Michael.

Re: completing-read depricated initial-input

[Emanuel Berg]

Michael Heerdegen wrote:

> A convincing example, in my opinion.

But it's done manually when there isn't a reason to ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Emanuel Berg]

Arash Esbati wrote:

> If you have a common prefix which should be shown in the
> candidates list, in (La)TeX for instance:
>
> (let ((list '("iffalse" "iftrue" "else" "fi")))
>   (completing-read "Macro: "
>                    (mapcar (lambda (x) (concat "\\" x)) list)
>                    nil nil "\\"))
>
> Something like this looks odd:
>
> (let ((list '("iffalse" "iftrue" "else" "fi")))
>   (completing-read "Macro: \\" list))

Neither looks good but the second is much less complicated and
error-prone and also more clear since there isn't the two nil
arguments.

If it is just about identifying a common and thus mandatory
prefix `completing-read' could just as well do it, the
alternatives could then all retain their intended and
complete form.

It's Thursday today, not (format "Thurs%s" shared-day-suffix)

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Jean Louis]

I like my function `rcd-ask' as it saves me generation of history variables automatically. 

(defun rcd-symbol-if-not-exist (variable &optional value description)
  "Return symbol for VARIABLE string. 

It will generate new VARIABLE if it does not exist.

VALUE and DESCRIPTION are optional."
  (let* ((variable (replace-regexp-in-string "[^[:alnum:]]" "-" (downcase variable)))
	 (rcd-symbol (intern variable))
	 (description (or description (format "Generated variable `%s'" variable))))
    (if (boundp rcd-symbol)
	rcd-symbol
      (eval (list 'defvar rcd-symbol value description)))))

(defun rcd-ask-history-variable (prompt)
  "Generate history variable based on PROMPT."
  (let* ((description (format "History for `%s' prompt." prompt)))
    (rcd-symbol-if-not-exist (concat "rcd-" prompt "-history") nil description)))

(defun rcd-ask (&optional prompt initial-contents keymap read default-value)
  "Modified function `read-from-minibuffer'.

This is shorter, simpler function that generates the prompt
automatically, generates history variable automatically and
inherits the input method. The input will be returned trimmed."
  (let* ((prompt (or prompt "Input data: "))
	 (history (rcd-ask-history-variable prompt))
	 (input (read-from-minibuffer prompt initial-contents keymap read history default-value t))
	 (input (string-trim input)))
    input))

;; (rcd-ask "First name: ") ⇒ "Emmanuel"
;; In the next step "Emmanuel" is automatically history, and one can get him by M-n M-p
;; (rcd-ask "First name: ")
;; (rcd-ask) ⇒ "Here is some string"

And I also like this function that asks few TIMES for something:

(defun rcd-ask-times (times &optional prompt initial-contents keymap read default-value)
  "Return list of queries by multiples TIMES"
  (let ((list ())
	(count 0))
    (while (< count times)
      (push (rcd-ask (concat (format "[#%s] " (1+ count)) prompt) initial-contents keymap read default-value) list)
    (setq count (1+ count)))
    (reverse list)))

;; (rcd-ask-times 3 "Query: ") ⇒ ("Emmanuel" "Berg" "Sweden")


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: completing-read depricated initial-input

[Emanuel Berg]

Jean Louis wrote:

> ;; (rcd-ask-times 3 "Query: ") ⇒ ("Emmanuel" "Berg" "Sweden")

Haha :)

Emanuel is history for sure. But does that mean Jean
is psycho?

From what novel series?

  - I'm psycho.

  - I'm history.

https://www.quora.com/Isaac-Asimov-gave-the-world-an-introduction-to-psycho-history-What-is-your-take-on-the-subject

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2022-06-24 05:37]:
> Jean Louis wrote:
> 
> > ;; (rcd-ask-times 3 "Query: ") ⇒ ("Emmanuel" "Berg" "Sweden")
> 
> Haha :)
> 
> Emanuel is history for sure. But does that mean Jean
> is psycho?
> 
> From what novel series?
> 
>   - I'm psycho.
> 
>   - I'm history.

I knew you will get the joke.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: completing-read depricated initial-input

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2022-06-23 14:22]:
> Arash Esbati <arash@gnu.org> writes:
> 
> > Note the terms "mostly-deprecated", "discourage", "recommend",
> > "superseded".  So maybe the docstring of `completing-read' should be
> > adjusted to the statements above in order to avoid confusion?
> 
> The purpose of `completing-read' is a bit different from `read-string'
> and `read-from-minibuffer'.  Providing INITIAL-INPUT is useful for the
> latter, but much less for `completing-read' in my opinion.  If at all
> (anybody who has a believable real-life example?).

I am used to automatically generate history variables based on
prompt. And I use often read-from-minibuffer wrapped in my function,
this below is using automatically inserted initial contents based on
history variable. I find that useful.

(defun rcd-ask (&optional prompt initial-contents keymap read default-value auto-initial-contents)
  "Modified function `read-from-minibuffer'.

This is shorter, simpler function that generates the prompt
automatically, generates history variable automatically and
inherits the input method. The input will be returned trimmed."
  (let* ((prompt (or prompt "Input data: "))
	 (history (rcd-ask-history-variable prompt))
	 (initial-contents (or initial-contents (when auto-initial-contents (car (symbol-value history)))))
	 (input (read-from-minibuffer prompt initial-contents keymap read history default-value t))
	 (input (string-trim input)))
    input))

;; (rcd-ask "First name: " "Emmanuel") ⇒ "Emmanuel"
;; (rcd-ask "First name: ") ⇒ "Berg"
;; rcd-first-name---history ⇒ ("Berg" "Emmanuel" "Jean" "Louis")

Then we get automatic initial contents based on the prompt:

(rcd-ask "First name: " nil nil nil nil t)

as then minibuffer says "First name: Berg" and waits for input.

Having initial contents based on last value of the history is useful on my side.

But then again I have another wrapper that uses `completing-read'
which I also want to adapt to use auto-initial-input based on last
value of history variable. For example I am often entering country
names, and often people from same country, having last history
variable as auto-initial-input is useful

(defun rcd-completing-read-sql-hash (prompt sql pg &optional history initial-input not-require-match)
  "Complete selection by using SQL.

First column shall be unique id, followed by text
representation.  Example SQL query:

SELECT people_id, people_firstname || ' ' || people_lastname FROM people

PG is database handle.  HISTORY is supported with INITIAL-INPUT
Argument PROMPT will be displayed to user."
  (let* ((hash (rcd-sql-hash-with-key sql pg))
	 (completion-ignore-case t)
	 (require-match (if not-require-match nil t))
	 (history (or history (rcd-ask-history-variable prompt)))
	 (choice (completing-read prompt hash nil require-match initial-input history))
	 (choice (string-trim choice))
	 (id (gethash choice hash)))
    (if id id
      (if not-require-match 
	  choice))))

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: completing-read depricated initial-input

[Jean Louis]

* Michael Heerdegen <michael_heerdegen@web.de> [2022-06-23 14:22]:
> Arash Esbati <arash@gnu.org> writes:
> 
> > Note the terms "mostly-deprecated", "discourage", "recommend",
> > "superseded".  So maybe the docstring of `completing-read' should be
> > adjusted to the statements above in order to avoid confusion?
> 
> The purpose of `completing-read' is a bit different from `read-string'
> and `read-from-minibuffer'.  Providing INITIAL-INPUT is useful for the
> latter, but much less for `completing-read' in my opinion.  If at all
> (anybody who has a believable real-life example?).

Thanks, it gave me idea so I have improved my function to
automatically insert auto-initial-input based on last value of
automatically generated history variable.

It spares my time in some entries, and I do many of them per day..

(defun rcd-completing-read-sql-hash (prompt sql pg &optional history initial-input not-require-match auto-initial-input)
  "Complete selection by using SQL.

First column shall be unique id, followed by text
representation.  Example SQL query:

SELECT people_id, people_firstname || ' ' || people_lastname FROM people

PG is database handle.  HISTORY is supported with INITIAL-INPUT
Argument PROMPT will be displayed to user."
  (let* ((hash (rcd-sql-hash-with-key sql pg))
	 (completion-ignore-case t)
	 (require-match (if not-require-match nil t))
	 (history (or history (rcd-ask-history-variable prompt)))
	 (initial-input (or initial-input (when auto-initial-input (car (symbol-value history)))))
	 (choice (completing-read prompt hash nil require-match initial-input history))
	 (choice (string-trim choice))
	 (id (gethash choice hash)))
    (if id id
      (if not-require-match 
	  choice))))

Example:

That would show user's name and email address and ID number, and I
would get ID number as result.

(rcd-completing-read-sql-hash "People: " "SELECT people_id, people_firstname || ' ' || people_lastname FROM people LIMIT 10" cf-db nil nil nil t) ⇒ 32367


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: completing-read depricated initial-input

[Stefan Monnier]

I haven't really followed that thread, but IMO the `initial-input` arg
should be changed into `setup-function` (so we don't have to use the
hideous `minibuffer-with-setup-function` hack) and using a string there
should be deprecated (the rare places where inserting an initial string
makes sense can use a setup-function instead).

Also the prompt handling should be changed so that it automatically
inserts the default into the prompt.  Doing that in a reliable and
backward compatible way is not completely straightforward, tho, so maybe
a simpler solution is to introduce a whole new function instead.

Then a user-customization could also be used to choose between the
current default (where the default is added to the prompt) or the other
option of always inserting the default as initial value (pre-selected
so it can be deleted with a quick DEL).


        Stefan

Re: completing-read depricated initial-input

[Christopher Dimech]

> Sent: Friday, June 24, 2022 at 9:05 AM
> From: "Stefan Monnier" <monnier@iro.umontreal.ca>
> To: "Michael Heerdegen" <michael_heerdegen@web.de>
> Cc: "Arash Esbati" <arash@gnu.org>, "Drew Adams" <drew.adams@oracle.com>, "Christopher Dimech" <dimech@gmx.com>, "eliz@gnu.org" <eliz@gnu.org>, "Help Gnu Emacs" <help-gnu-emacs@gnu.org>, "carlmarcos@tutanota.com" <carlmarcos@tutanota.com>
> Subject: Re: completing-read depricated initial-input
>
> I haven't really followed that thread, but IMO the `initial-input` arg
> should be changed into `setup-function` (so we don't have to use the
> hideous `minibuffer-with-setup-function` hack) and using a string there
> should be deprecated (the rare places where inserting an initial string
> makes sense can use a setup-function instead).
>
> Also the prompt handling should be changed so that it automatically
> inserts the default into the prompt.  Doing that in a reliable and
> backward compatible way is not completely straightforward, tho, so maybe
> a simpler solution is to introduce a whole new function instead.
>
> Then a user-customization could also be used to choose between the
> current default (where the default is added to the prompt) or the other
> option of always inserting the default as initial value (pre-selected
> so it can be deleted with a quick DEL).
>

Inserting default would make sense.  We should not continue with the
initial-value name then.  Stating that DEF will be displayed  as first
instance.  Making things smoother and clearer to understand.

Re: completing-read depricated initial-input

[Stefan Monnier]

> Inserting default would make sense.

That depends on the UI we want to provide.

So it shouldn't be part of the API but instead part of the user customizations.


        Stefan

Re: completing-read depricated initial-input

[Christopher Dimech]

> Sent: Friday, June 24, 2022 at 10:19 AM
> From: "Stefan Monnier" <monnier@iro.umontreal.ca>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Michael Heerdegen" <michael_heerdegen@web.de>, "Arash Esbati" <arash@gnu.org>, "Drew Adams" <drew.adams@oracle.com>, "eliz@gnu.org" <eliz@gnu.org>, "Help Gnu Emacs" <help-gnu-emacs@gnu.org>, "carlmarcos@tutanota.com" <carlmarcos@tutanota.com>
> Subject: Re: completing-read depricated initial-input
>
> > Inserting default would make sense.
>
> That depends on the UI we want to provide.
>
> So it shouldn't be part of the API but instead part of the user customizations.
>
> Stefan

I'll agree with that.  Just do not have initial-input and def working interchangeably.
It only leads to bad or tricky habits.

Re: completing-read depricated initial-input

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2022-06-24 01:11]:
> Inserting default would make sense.  We should not continue with the
> initial-value name then.  Stating that DEF will be displayed  as first
> instance.  Making things smoother and clearer to understand.

I do not find it so. I do not say how function works, but I wish
 to say what I expect as user. 

How I understand the "default" is that it should be the value
that function gives as result in case when user does not write
anything else, hits enter.

However, it does not work this way with `read-from-minibuffer',
so I will file bug report.

(read-from-minibuffer "Your name: " nil nil nil nil "Jean") ⇒ ""

However, in this function it does work the expected way:

(completing-read "Your name: " '("Jean" "Emmanuel" "Adebayo") nil nil nil nil "Jean") ⇒ "Jean"

(completing-read "Your name: " '("Jean" "Emmanuel" "Adebayo") nil nil nil nil "Adebayo") ⇒ "Adebayo"

So I have filed bug report today, as that is not consistent behavior.

Initial input is something else, that is something I wish to
see there in front of me, ready to be chosen by pressing enter.

Those are totally different events. 

1) I maybe do not want to show any initial input, but if I press
   enter, I need my default

2) I maybe want to show the initial input, but if I delete it and
   press enter with empty string, I still need my default, which may
   be different from initial input.

For me it would be rather damaging to remove initial input as I do
work with it often, there are people employed working with it, it
would affect the business.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: completing-read depricated initial-input

[Christopher Dimech]

> Sent: Friday, June 24, 2022 at 7:08 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Stefan Monnier" <monnier@iro.umontreal.ca>, "Michael Heerdegen" <michael_heerdegen@web.de>, "Arash Esbati" <arash@gnu.org>, "Drew Adams" <drew.adams@oracle.com>, "eliz@gnu.org" <eliz@gnu.org>, "Help Gnu Emacs" <help-gnu-emacs@gnu.org>, "carlmarcos@tutanota.com" <carlmarcos@tutanota.com>
> Subject: Re: completing-read depricated initial-input
>
> * Christopher Dimech <dimech@gmx.com> [2022-06-24 01:11]:
> > Inserting default would make sense.  We should not continue with the
> > initial-value name then.  Stating that DEF will be displayed  as first
> > instance.  Making things smoother and clearer to understand.
> 
> I do not find it so. I do not say how function works, but I wish
>  to say what I expect as user. 
> 
> How I understand the "default" is that it should be the value
> that function gives as result in case when user does not write
> anything else, hits enter.

That how it should be understood
 
> However, it does not work this way with `read-from-minibuffer',
> so I will file bug report.
> 
> (read-from-minibuffer "Your name: " nil nil nil nil "Jean") ⇒ ""
> 
> However, in this function it does work the expected way:
> 
> (completing-read "Your name: " '("Jean" "Emmanuel" "Adebayo") nil nil nil nil "Jean") ⇒ "Jean"
> 
> (completing-read "Your name: " '("Jean" "Emmanuel" "Adebayo") nil nil nil nil "Adebayo") ⇒ "Adebayo"
> 
> So I have filed bug report today, as that is not consistent behavior.
> 
> Initial input is something else, that is something I wish to
> see there in front of me, ready to be chosen by pressing enter.
> 
> Those are totally different events. 
> 
> 1) I maybe do not want to show any initial input, but if I press
>    enter, I need my default
> 
> 2) I maybe want to show the initial input, but if I delete it and
>    press enter with empty string, I still need my default, which may
>    be different from initial input.
> 
> For me it would be rather damaging to remove initial input as I do
> work with it often, there are people employed working with it, it
> would affect the business.
> 
> -- 
> Jean

I agree Jean, but it looks like the reasoning is taking a long discussion
to be appreciated.  initial-value is not related to a default or anything
but on what gets displayed as soon an you enter minibuffer read.

Re: completing-read depricated initial-input

[Jean Louis]

* Christopher Dimech <dimech@gmx.com> [2022-06-24 11:19]:
> I agree Jean, but it looks like the reasoning is taking a long
> discussion to be appreciated.  initial-value is not related to a
> default or anything but on what gets displayed as soon an you enter
> minibuffer read.

That is true, and I am well aware of it, just I do not understand why
you do not understand that I am well aware of it... 👀


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: completing-read depricated initial-input

[Christopher Dimech]

> Sent: Friday, June 24, 2022 at 11:00 PM
> From: "Jean Louis" <bugs@gnu.support>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: help-gnu-emacs@gnu.org
> Subject: Re: completing-read depricated initial-input
>
> * Christopher Dimech <dimech@gmx.com> [2022-06-24 11:19]:
> > I agree Jean, but it looks like the reasoning is taking a long
> > discussion to be appreciated.  initial-value is not related to a
> > default or anything but on what gets displayed as soon an you enter
> > minibuffer read.
> 
> That is true, and I am well aware of it, just I do not understand why
> you do not understand that I am well aware of it... 👀
> 
> Jean
 
The comment was for people reading the list whilst interacting with you
regarding your clear thinking.

Re: completing-read depricated initial-input

[Emanuel Berg]

Jean Louis wrote:

> (read-from-minibuffer "Your name: " nil nil nil nil "Jean")

Holy cow, there's no need to hard code that! What if you were
to change your name (nom de guerre if you wish) for romantic
and/or conspiratorial reasons? Use `user-full-name'
instead ...

(BTW 4 nil in a row. How many do you need to strike
the jackpot?)

>> Inserting default would make sense. We should not continue
>> with the initial-value name then. Stating that DEF will be
>> displayed as first instance. Making things smoother and
>> clearer to understand.
>
> I do not find it so. I do not say how function works, but
> I wish to say what I expect as user.

We have been thinking of it in very practical terms so far.

I already asked, what concept is the initial value? I'm not
aware of any such concept in this context. One can think of
several UIs (including GUIs) where the initial value has been
inserted to communicate the default value, and enable -
transparently, even - for the user to submit this value.
In that sense, it isn't that bad: the default value is shown
loud and clear, it can be edited and when its submitted this
happens with the same method so no extras in terms of
technology at that end.

However ...

We don't want that for the default value so all that doesn't
matter anymore (or to us).

If we look at it from even further away the initial value
makes even less sense. "Why is the computer putting stuff
there? It's the area where the human user should put stuff."

So in general it doesn't make sense, specifically it _could_
make sense but it doesn't since we have another, better method
for that.

There is only one use case (completion with a common prefix)
however that can either be automated _or_ solved with the
default method _and_ relying on completion to navigate huge
search spaces of similar members, that's a poor situation to
begin with, maybe it gets mildly better with completion but
that's obviously nothing to base general policy on.

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2022-06-24 11:26]:
> Jean Louis wrote:
> 
> > (read-from-minibuffer "Your name: " nil nil nil nil "Jean")
> 
> Holy cow, there's no need to hard code that! What if you were
> to change your name (nom de guerre if you wish) for romantic
> and/or conspiratorial reasons? Use `user-full-name'
> instead ...

Which name? That is not name, that is:

1. jean, blue jean, denim -- ((usually plural) close-fitting trousers of heavy denim for manual work or casual wear)

Jokes aside... 👁️

> >> Inserting default would make sense. We should not continue
> >> with the initial-value name then. Stating that DEF will be
> >> displayed as first instance. Making things smoother and
> >> clearer to understand.
> >
> > I do not find it so. I do not say how function works, but
> > I wish to say what I expect as user.
> 
> We have been thinking of it in very practical terms so far.
> 
> I already asked, what concept is the initial value? I'm not
> aware of any such concept in this context. One can think of
> several UIs (including GUIs) where the initial value has been
> inserted to communicate the default value, and enable -
> transparently, even - for the user to submit this value.
> In that sense, it isn't that bad: the default value is shown
> loud and clear, it can be edited and when its submitted this
> happens with the same method so no extras in terms of
> technology at that end.

It is my sincere hope you will understand the difference between those
two.

1) Default is what will be chosen if use press enter, regardless if
   user sees that default or not. That is my expectation, but
   read-from-minibuffer in development version does not behave this
   way. 

   Personally I have heavy uses of defaults, such as "Default address"
   while some addresses are rather different "Work address" or
   "Temporary address". I need default address, thus it is usable for
   me. 

2) Initial value is usable as it is visible and makes it easier to
   make the choice, but it is not necessarily default.

   My personal example is that some people have one address in
   Germany, other in Austria, but one of those addresses is default
   (this word now has no relation to Emacs). If letter has been sent
   last 2 times to Austria, system can recognize it and offer such as
   initial input. But if Austria is not choosen, or if nothing in
   particular has been seen in the prompt and user hits RET, then
   default German address would be choosen.

   Another example is that I am entering phone numbers every
   day. Communication line is "Phone" but type is "Default", which
   means nothing in particular. However, I start entering many mobile
   numbers, than I appreciate that system looks in past and offers me
   "Mobile" as initial input, just to press enter, while my Default
   would be choosen if I delete it and press enter on empty
   minibuffer.

   ┌───────────────────────┬────────┐
   │ Addreses in last year │ Count  │
   ├───────────────────────┼────────┤
   │ Addresses             │ 197299 │
   └───────────────────────┴────────┘

   The above personal example I go through many times per day.

   In my example I do not use initial-value to communicate default,
   but to communicate the choice which could be more probable based on
   last information. That choice may be dynamically chosen, it is not
   hard code.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: completing-read depricated initial-input

[Emanuel Berg]

Jean Louis wrote:

> Initial value is usable as it is visible and makes it easier
> to make the choice, but it is not necessarily default.
>
> My personal example is that some people have one address in
> Germany, other in Austria, but one of those addresses is
> default (this word now has no relation to Emacs). If letter
> has been sent last 2 times to Austria, system can recognize
> it and offer such as initial input.

That's something similar to a cache memory which is based on
the principle of spacial and temporal proximity, I still don't
see why whatever suggestion it comes up with isn't then the
default value simply?

It is shown and if you want to edit it first, it is inserted
with M-n.

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Jean Louis]

* Emanuel Berg <incal@dataswamp.org> [2022-06-25 21:56]:
> Jean Louis wrote:
> 
> > Initial value is usable as it is visible and makes it easier
> > to make the choice, but it is not necessarily default.
> >
> > My personal example is that some people have one address in
> > Germany, other in Austria, but one of those addresses is
> > default (this word now has no relation to Emacs). If letter
> > has been sent last 2 times to Austria, system can recognize
> > it and offer such as initial input.
> 
> That's something similar to a cache memory which is based on
> the principle of spacial and temporal proximity, I still don't
> see why whatever suggestion it comes up with isn't then the
> default value simply?
> 
> It is shown and if you want to edit it first, it is inserted
> with M-n.

True. For few entries that is fine. M-n once or multiple times or M-p
followed by RET. Imagine 20 entries per day, that is just fine.

When you have many entries it is easier to press RET. Imagine 500
entries per day. It's faster.


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/

Re: completing-read depricated initial-input

[Emanuel Berg]

Jean Louis wrote:

>> That's something similar to a cache memory which is based
>> on the principle of spacial and temporal proximity, I still
>> don't see why whatever suggestion it comes up with isn't
>> then the default value simply?
>> 
>> It is shown and if you want to edit it first, it is
>> inserted with M-n.
>
> True. For few entries that is fine. M-n once or multiple
> times or M-p followed by RET. Imagine 20 entries per day,
> that is just fine.
>
> When you have many entries it is easier to press RET.
> Imagine 500 entries per day. It's faster.

If you want it all the time you should rather have a variable
for that instead of sending it twice to the function.
That'd be even faster. And make more sense.

And if you do it 500 times a day you should write a program and
automate it completely instead of relying on little clever
shortcuts here and there ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Emanuel Berg]

Stefan Monnier wrote:

> I haven't really followed that thread, but IMO the
> `initial-input` arg should be changed into `setup-function`
> (so we don't have to use the hideous
> `minibuffer-with-setup-function` hack) and using a string
> there should be deprecated (the rare places where inserting
> an initial string makes sense can use a setup-function
> instead).

I thought about that to, good idea but if so move the
'setup-fun' formal parameter to the right of 'def' so there
don't have to be nil in between all the time in Elisp code,
because to have/want a default value will be much more common.

> Also the prompt handling should be changed so that it
> automatically inserts the default into the prompt.

100%, and not just that, everything and anything that can be
automated one should never leave to a human, programmer or
not ...

> Doing that in a reliable and backward compatible way is not
> completely straightforward, tho, so maybe a simpler solution
> is to introduce a whole new function instead.

Right.

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : Re: completing-read depricated initial-input

[Drew Adams]

> >> > `completing-read' is extremely general,
> >> > allowing for many different interactions
> >> > for many different kinds of use cases.
> >>
> >> True, unfortunately.
> > Why "unfortunately"?
> 
> Because extremely general tools give one many
> ways to do things.

And?  Emacs and Elisp are all about giving us
many ways to do things.  They even give you lots
of rope to hang yourself with.

> It is just hard if you find out afterwards that
> things went in the wrong direction and you try
> to clean up.  No other reason.

Too general/abstract.  Can you elaborate with
some specifics?

> > And there's `read-from-minibuffer', which is
> > even more general.
> 
> Therefore we have `read-string'.

We have both specific and general functions that
read input - both with and without completion.

`completing-read' is a general completion
workhorse function.  Among other things, you can
use it to define your own specific completion
functions.

When a specific read function is appropriate, use
it.  That's not a reason for not also having more
general functions.

No one's obliged to use the very general function
`completing-read'.  And no one's obliged to use
it with a non-nil INITIAL-INPUT arg.

Re: completing-read depricated initial-input

[Arash Esbati]

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

>> Because extremely general tools give one many
>> ways to do things.
>
> And?  Emacs and Elisp are all about giving us
> many ways to do things.  They even give you lots
> of rope to hang yourself with.
>
>> It is just hard if you find out afterwards that
>> things went in the wrong direction and you try
>> to clean up.  No other reason.
>
> Too general/abstract.  Can you elaborate with
> some specifics?

I don't have any specific example in my mind, I was also thinking about
what you said above about the rope and hang yourself.

> No one's obliged to use the very general function
> `completing-read'.  And no one's obliged to use
> it with a non-nil INITIAL-INPUT arg.

Agreed.

But in terms of coming to some sort of conclusion: This thread started
with the question:

  When do you plan to remove the `INITIAL-INPUT` argument from
  `completing-read`?

I think the answer is: This will not happen, so don't worry.

If so, is the docstring of `completing-read' inaccurate or misleading?
If so, should there be a bug report and/or a change suggestion?

WDYT?

Best, Arash

Re: completing-read depricated initial-input

[Christopher Dimech]

> Sent: Friday, June 24, 2022 at 8:58 AM
> From: "Arash Esbati" <arash@gnu.org>
> To: "Drew Adams" <drew.adams@oracle.com>
> Cc: "Christopher Dimech" <dimech@gmx.com>, "eliz@gnu.org" <eliz@gnu.org>, "monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>, "Help Gnu Emacs" <help-gnu-emacs@gnu.org>, "carlmarcos@tutanota.com" <carlmarcos@tutanota.com>, "michael_heerdegen@web.de" <michael_heerdegen@web.de>
> Subject: Re: completing-read depricated initial-input
>
> Drew Adams <drew.adams@oracle.com> writes:
>
> >> Because extremely general tools give one many
> >> ways to do things.
> >
> > And?  Emacs and Elisp are all about giving us
> > many ways to do things.  They even give you lots
> > of rope to hang yourself with.
> >
> >> It is just hard if you find out afterwards that
> >> things went in the wrong direction and you try
> >> to clean up.  No other reason.
> >
> > Too general/abstract.  Can you elaborate with
> > some specifics?
>
> I don't have any specific example in my mind, I was also thinking about
> what you said above about the rope and hang yourself.
>
> > No one's obliged to use the very general function
> > `completing-read'.  And no one's obliged to use
> > it with a non-nil INITIAL-INPUT arg.
>
> Agreed.
>
> But in terms of coming to some sort of conclusion: This thread started
> with the question:
>
>   When do you plan to remove the `INITIAL-INPUT` argument from
>   `completing-read`?
>
> I think the answer is: This will not happen, so don't worry.

The bigger problem is really about whether the functionality associated with
INITIAL-INPUT will end?

> If so, is the docstring of `completing-read' inaccurate or misleading?
> If so, should there be a bug report and/or a change suggestion?
>
> WDYT?
>
> Best, Arash
>

Re: completing-read depricated initial-input

[Emanuel Berg]

Arash Esbati wrote:

> in terms of coming to some sort of conclusion: This thread
> started with the question:

Arash, do you know what animal is the least predictable?

Answer: https://www.youtube.com/watch?v=L5sQYUFGAc0

>   When do you plan to remove the `INITIAL-INPUT` argument from
>   `completing-read`?
>
> I think the answer is: This will not happen, so don't worry.

It will be obliterated.

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Po Lu]

Arash Esbati <arash@gnu.org> writes:

> I agree that there are cases where INITIAL-INPUT still has its place,
> but as I said, I remember the reason for phasing it out was different
> than stylistic preferences.

What other reason can there be?  I can't think of any non-stylistic
reason to discourage using that argument.

If you think it is counterproductive to insert some initial value into
the minibuffer itself, then by all means recommend against using it.

But don't obsolete the means of doing so.  You do not have a place in
dictating how users write their Lisp programs.

Re: completing-read depricated initial-input

[Emanuel Berg]

Po Lu wrote:

>> I agree that there are cases where INITIAL-INPUT still has
>> its place, but as I said, I remember the reason for phasing
>> it out was different than stylistic preferences.
>
> What other reason can there be? I can't think of any
> non-stylistic reason to discourage using that argument.

Maybe stop thinking about it and instead let your subconscious
figure it out for you?

Anyway this is what I think is the best interface:

(let ((name "Danger"))
  (read-string (format "name: [%s] " name) nil nil name) )

You then see:

name: [Danger] _

So if you hit RET you get the default (the suggestion), i.e.
"Danger", if you print you print and if you want to edit
"Danger" hit M-n and it's inserted only pint isn't moved.

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Christopher Dimech]

> Sent: Wednesday, June 22, 2022 at 3:09 PM
> From: "Po Lu" <luangruo@yahoo.com>
> To: "Arash Esbati" <arash@gnu.org>
> Cc: "Drew Adams" <drew.adams@oracle.com>, "Christopher Dimech" <dimech@gmx.com>, "eliz@gnu.org" <eliz@gnu.org>, "monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>, "Help Gnu Emacs" <help-gnu-emacs@gnu.org>, "carlmarcos@tutanota.com" <carlmarcos@tutanota.com>, "michael_heerdegen@web.de" <michael_heerdegen@web.de>
> Subject: Re: completing-read depricated initial-input
>
> Arash Esbati <arash@gnu.org> writes:
>
> > I agree that there are cases where INITIAL-INPUT still has its place,
> > but as I said, I remember the reason for phasing it out was different
> > than stylistic preferences.
>
> What other reason can there be?  I can't think of any non-stylistic
> reason to discourage using that argument.
>
> If you think it is counterproductive to insert some initial value into
> the minibuffer itself, then by all means recommend against using it.
>
> But don't obsolete the means of doing so.


Because `completing-read` is a very general function, on purpose, and
has historically been getting more and more general, the presence of
INITIAL-INPUT does have purpose.  Would want to keep `completing-read`
as a general canonical function for user input.  And I do use it, especially
when `REQUIRE-MATCH` in `t`.

Obsoleting the means of using it will introduce functional difficulties rather
than solving or simplifying anything.

There is enough agreement about the generality of `completing-read` to keep
the functionality of INITIAL-INPUT.

Re: completing-read depricated initial-input

[Arash Esbati]

Po Lu <luangruo@yahoo.com> writes:

> Arash Esbati <arash@gnu.org> writes:
>
>> I agree that there are cases where INITIAL-INPUT still has its place,
>> but as I said, I remember the reason for phasing it out was different
>> than stylistic preferences.
>
> What other reason can there be?  I can't think of any non-stylistic
> reason to discourage using that argument.

Improved user experience?  But that means we have to find out what our
definitions of "stylistic preferences / reason" are in the first place,
but we don't have to go there.

> If you think it is counterproductive to insert some initial value into
> the minibuffer itself, then by all means recommend against using it.

This is already done by Emacs itself.  Please see my other answer to
Drew where I quoted some text.

> But don't obsolete the means of doing so.

I'm not the decision maker here, and I don't have the impression that
the means are getting obsoleted.

> You do not have a place in dictating how users write their Lisp
> programs.

What do you mean with that "You"?  I'm not involved in Emacs development
and I'm not dictating anything; and I see no reason for you to get
harsh.

Best, Arash

Re: completing-read depricated initial-input

[Emanuel Berg]

Arash Esbati wrote:

>>> I agree that there are cases where INITIAL-INPUT still has
>>> its place, but as I said, I remember the reason for
>>> phasing it out was different than stylistic preferences.
>>
>> What other reason can there be? [...]
>
> Improved user experience?

Why/how so?

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Tassilo Horn]

Emanuel Berg <incal@dataswamp.org> writes:

>>>> I agree that there are cases where INITIAL-INPUT still has its
>>>> place, but as I said, I remember the reason for phasing it out was
>>>> different than stylistic preferences.
>>>
>>> What other reason can there be? [...]
>>
>> Improved user experience?
>
> Why/how so?

You have to delete the initial input if it's not what you want or if you
want to see the other possibilities.  So basically all occurrences where
INITIAL-INPUT is used as a kind of default value are better handled with
the DEF argument.

The only places where I can see it's useful is when all possible
completions have a common prefix and that is given as initial-input (but
then you only save one TAB) or with completing-read-multiple when it's
highly likely that the user wants to use the defaults given as
initial-input and just insert some more.  (completing-read-multiple
doesn't explicitly state that INITIAL-INPUT is deprecated.)

Bye,
Tassilo

Re: completing-read depricated initial-input

[Emanuel Berg]

Tassilo Horn wrote:

>>>>> I agree that there are cases where INITIAL-INPUT still
>>>>> has its place, but as I said, I remember the reason for
>>>>> phasing it out was different than stylistic preferences.
>>>>
>>>> What other reason can there be? [...]
>>>
>>> Improved user experience?
>>
>> Why/how so?
>
> You have to delete the initial input if it's not what you
> want or if you want to see the other possibilities.
> So basically all occurrences where INITIAL-INPUT is used as
> a kind of default value are better handled with the
> DEF argument.

I know but ... why are you telling me this?

IMO this is the best way of doing it:

(let ((name "Danger"))
  (read-string (format "name: [%s] " name) nil nil name) )

> The only places where I can see it's useful is when all
> possible completions have a common prefix [...]

It is useful there but only in terms on relying on completion
over a huge set of pretty much similar symbol names which is
a situation that shouldn't be encouraged to begin with, and
neither should completion BTW. And, alltho, as Merlin the
Great Wizard was fond of saying, there is no right or wrong,
just what is and what isn't, it still holds that two wrongs
don't make one right.

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Tassilo Horn]

Emanuel Berg <incal@dataswamp.org> writes:

>>>> Improved user experience?
>>>
>>> Why/how so?
>>
>> You have to delete the initial input if it's not what you
>> want or if you want to see the other possibilities.
>> So basically all occurrences where INITIAL-INPUT is used as
>> a kind of default value are better handled with the
>> DEF argument.
>
> I know but ... why are you telling me this?

Because you've asked why/how not using INITIAL-INPUT with
completing-read has an improved user experience.

> IMO this is the best way of doing it:
>
> (let ((name "Danger"))
>   (read-string (format "name: [%s] " name) nil nil name) )

But it has nothing to do with completing-read.

>> The only places where I can see it's useful is when all
>> possible completions have a common prefix [...]
>
> It is useful there but only in terms on relying on completion over a
> huge set of pretty much similar symbol names which is a situation that
> shouldn't be encouraged to begin with, and neither should completion
> BTW.

Huh?  Completion is a must especially when there are many and similar
completions.  Would you consider M-x/C-h {f,v,etc} without completion
being a good user interface?

> And, alltho, as Merlin the Great Wizard was fond of saying, there is
> no right or wrong, just what is and what isn't, it still holds that
> two wrongs don't make one right.

Sure.  But the thing is that people writing packages usually don't
provide an option if INITIAL-INPUT should be used or not.  Therefore,
whatever choice they make is forced upon their users (well, unless the
user knows of :filter-args advices).  For that reason it makes sense to
document a guideline on how to do things as Arash cited in
<86mte3lsj2.fsf_-_@gnu.org>.

Bye,
Tassilo

Re: completing-read depricated initial-input

[carlmarcos--- via Users list for the GNU Emacs text editor]

Jun 23, 2022, 11:26 by tsdh@gnu.org:

> Emanuel Berg <incal@dataswamp.org> writes:
>
>>>>> Improved user experience?
>>>>>
>>>>
>>>> Why/how so?
>>>>
>>>
>>> You have to delete the initial input if it's not what you
>>> want or if you want to see the other possibilities.
>>> So basically all occurrences where INITIAL-INPUT is used as
>>> a kind of default value are better handled with the
>>> DEF argument.
>>>
>>
>> I know but ... why are you telling me this?
>>
>
> Because you've asked why/how not using INITIAL-INPUT with
> completing-read has an improved user experience.
>
>> IMO this is the best way of doing it:
>>
>> (let ((name "Danger"))
>>  (read-string (format "name: [%s] " name) nil nil name) )
>>
>
> But it has nothing to do with completing-read.
>
>>> The only places where I can see it's useful is when all
>>> possible completions have a common prefix [...]
>>>
>>
>> It is useful there but only in terms on relying on completion over a
>> huge set of pretty much similar symbol names which is a situation that
>> shouldn't be encouraged to begin with, and neither should completion
>> BTW.
>>
>
> Huh?  Completion is a must especially when there are many and similar
> completions.  Would you consider M-x/C-h {f,v,etc} without completion
> being a good user interface?
>
>> And, alltho, as Merlin the Great Wizard was fond of saying, there is
>> no right or wrong, just what is and what isn't, it still holds that
>> two wrongs don't make one right.
>>
>
> Sure.  But the thing is that people writing packages usually don't
> provide an option if INITIAL-INPUT should be used or not.  Therefore,
> whatever choice they make is forced upon their users (well, unless the
> user knows of :filter-args advices).  For that reason it makes sense to
> document a guideline on how to do things as Arash cited in
> <86mte3lsj2.fsf_-_@gnu.org>.
>
So now emacs is getting into the habit of trashing code by looking at written
packages by figuring out what is not usually done by the majority?  It is a bad
strategy, to say the least.  Even worse, it looks as if the documentation in putting
in people's head that INITIAL-INPUT should not be used in any function where
it is defined as an argument.



> Bye,
> Tassilo
>

Re: completing-read depricated initial-input

[Emanuel Berg]

carlmarcos--- via Users list for the GNU Emacs text editor wrote:

> So now emacs is getting into the habit of trashing code by
> looking at written packages by figuring out what is not
> usually done by the majority? It is a bad strategy, to say
> the least. Even worse, it looks as if the documentation in
> putting in people's head that INITIAL-INPUT should not be
> used in any function where it is defined as an argument.

It's called techno-totalitarianism and even as we speak
computers all over the world are busy pushing it still further
and further, and eventually it'll be like an art of
perfection, almost.

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Christopher Dimech]

> Sent: Friday, June 24, 2022 at 9:38 AM
> From: "Emanuel Berg" <incal@dataswamp.org>
> To: help-gnu-emacs@gnu.org
> Subject: Re: completing-read depricated initial-input
>
> carlmarcos--- via Users list for the GNU Emacs text editor wrote:
>
> > So now emacs is getting into the habit of trashing code by
> > looking at written packages by figuring out what is not
> > usually done by the majority? It is a bad strategy, to say
> > the least. Even worse, it looks as if the documentation in
> > putting in people's head that INITIAL-INPUT should not be
> > used in any function where it is defined as an argument.
>
> It's called techno-totalitarianism and even as we speak
> computers all over the world are busy pushing it still further
> and further, and eventually it'll be like an art of
> perfection, almost.
>
> --
> underground experts united
> https://dataswamp.org/~incal

Right.  Ending up with a robot like Sofia that you can't screw.
But she'll screw you.

Re: completing-read depricated initial-input

[Emanuel Berg]

Tassilo Horn wrote:

>> It is useful there but only in terms on relying on
>> completion over a huge set of pretty much similar symbol
>> names which is a situation that shouldn't be encouraged to
>> begin with, and neither should completion BTW.
>
> Huh? Completion is a must especially when there are many and
> similar completions. Would you consider M-x/C-h {f,v,etc}
> without completion being a good user interface?

It's a good interface when the thing to be examined is
at point.

> Sure. But the thing is that people writing packages usually
> don't provide an option if INITIAL-INPUT should be used or
> not. Therefore, whatever choice they make is forced upon
> their users (well, unless the user knows of :filter-args
> advices). For that reason it makes sense to document
> a guideline on how to do things

Actually I already called it not to do that ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Arash Esbati]

Emanuel Berg <incal@dataswamp.org> writes:

> Tassilo Horn wrote:
>
>> You have to delete the initial input if it's not what you
>> want or if you want to see the other possibilities.
>> So basically all occurrences where INITIAL-INPUT is used as
>> a kind of default value are better handled with the
>> DEF argument.
>
> I know but ... why are you telling me this?

Because you asked?  I parsed your question exactly the same way Tassilo
did.

> IMO this is the best way of doing it:
>
> (let ((name "Danger"))
>   (read-string (format "name: [%s] " name) nil nil name) )

I think the current standard in Emacs is like this:

(let ((name "Danger"))
  (read-string (format "Name (default %s): " name)
               nil nil name))

Best, Arash

Re: completing-read depricated initial-input

[Lars Ingebrigtsen]

Arash Esbati <arash@gnu.org> writes:

> I think the current standard in Emacs is like this:
>
> (let ((name "Danger"))
>   (read-string (format "Name (default %s): " name)
>                nil nil name))

Or rather:

(let ((name "Danger"))
  (read-string (format-prompt "Name" name) nil nil name))

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

Re: completing-read depricated initial-input

[Tassilo Horn]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> (let ((name "Danger"))
>   (read-string (format-prompt "Name" name) nil nil name))

Nice!

  Probably introduced at or before Emacs version 28.1.

Hm, ok, that will take a while before AUCTeX can start using it.

Bye,
Tassilo

Re: completing-read depricated initial-input

[Arash Esbati]

Tassilo Horn <tsdh@gnu.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> (let ((name "Danger"))
>>   (read-string (format-prompt "Name" name) nil nil name))
>
> Nice!

Indeed, and the best part of it is `minibuffer-default-prompt-format'
which you can customize.

>   Probably introduced at or before Emacs version 28.1.
>
> Hm, ok, that will take a while before AUCTeX can start using it.

I'd say it's up to the AUCTeX maintainers to bump the minimum required
Emacs version at a faster pace ;-)

Best, Arash

Re: completing-read depricated initial-input

[Robert Pluim]

>>>>> On Thu, 23 Jun 2022 16:46:53 +0200, Arash Esbati <arash@gnu.org> said:

    Arash> Tassilo Horn <tsdh@gnu.org> writes:
    >> Lars Ingebrigtsen <larsi@gnus.org> writes:
    >> 
    >>> (let ((name "Danger"))
    >>> (read-string (format-prompt "Name" name) nil nil name))
    >> 
    >> Nice!

    Arash> Indeed, and the best part of it is `minibuffer-default-prompt-format'
    Arash> which you can customize.

    >> Probably introduced at or before Emacs version 28.1.
    >> 
    >> Hm, ok, that will take a while before AUCTeX can start using it.

    Arash> I'd say it's up to the AUCTeX maintainers to bump the minimum required
    Arash> Emacs version at a faster pace ;-)

Either that, or they can depend on the 'compat' package, and then just
use emacs-28 features with wild abandon.

Robert
-- 

Re: completing-read depricated initial-input

[Arash Esbati]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Thu, 23 Jun 2022 16:46:53 +0200, Arash Esbati <arash@gnu.org> said:
>
>     Arash> I'd say it's up to the AUCTeX maintainers to bump the minimum required
>     Arash> Emacs version at a faster pace ;-)
>
> Either that, or they can depend on the 'compat' package, and then just
> use emacs-28 features with wild abandon.

Thanks for reminding me of compat.  I think compat-28.el has currently a
bug since the return value of `format-prompt' is not the same as in
Emacs>=28:

(format-prompt "Foo" "")
=> "Foo: "

This is what compat-28.el does:

(defun compat-format-prompt (prompt default &rest format-args)
  "Format PROMPT with DEFAULT.
If FORMAT-ARGS is nil, PROMPT is used as a plain string.  If
FORMAT-ARGS is non-nil, PROMPT is used as a format control
string, and FORMAT-ARGS are the arguments to be substituted into
it.  See `format' for details.

If DEFAULT is a list, the first element is used as the default.
If not, the element is used as is.

If DEFAULT is nil or an empty string, no \"default value\" string
is included in the return value."
  (concat
   (if (null format-args)
       prompt
     (apply #'format prompt format-args))
   (and default
        (or (not (stringp default))
            (not (null default)))
        ;;  (length> default 0) ; This is in Emacs stock version
        (format " (default %s)"
                (if (consp default)
                    (car default)
                  default)))
   ": "))

(compat-format-prompt "Foo" "")
=> "Foo (default ): "

compat doesn't check if DEFAULT is an empty string.  I'm CC'ing Philip,
maybe he can comment.

Best, Arash

Re: completing-read depricated initial-input

[Philip Kaludercic]

Arash Esbati <arash@gnu.org> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>>>>>>> On Thu, 23 Jun 2022 16:46:53 +0200, Arash Esbati <arash@gnu.org> said:
>>
>>     Arash> I'd say it's up to the AUCTeX maintainers to bump the minimum required
>>     Arash> Emacs version at a faster pace ;-)
>>
>> Either that, or they can depend on the 'compat' package, and then just
>> use emacs-28 features with wild abandon.
>
> Thanks for reminding me of compat.  I think compat-28.el has currently a
> bug since the return value of `format-prompt' is not the same as in
> Emacs>=28:
>
> (format-prompt "Foo" "")
> => "Foo: "
>
> This is what compat-28.el does:
>
> (defun compat-format-prompt (prompt default &rest format-args)
>   "Format PROMPT with DEFAULT.
> If FORMAT-ARGS is nil, PROMPT is used as a plain string.  If
> FORMAT-ARGS is non-nil, PROMPT is used as a format control
> string, and FORMAT-ARGS are the arguments to be substituted into
> it.  See `format' for details.
>
> If DEFAULT is a list, the first element is used as the default.
> If not, the element is used as is.
>
> If DEFAULT is nil or an empty string, no \"default value\" string
> is included in the return value."
>   (concat
>    (if (null format-args)
>        prompt
>      (apply #'format prompt format-args))
>    (and default
>         (or (not (stringp default))
>             (not (null default)))
>         ;;  (length> default 0) ; This is in Emacs stock version
>         (format " (default %s)"
>                 (if (consp default)
>                     (car default)
>                   default)))
>    ": "))
>
> (compat-format-prompt "Foo" "")
> => "Foo (default ): "
>
> compat doesn't check if DEFAULT is an empty string.  I'm CC'ing Philip,
> maybe he can comment.

You are right, this is a bug.  When "reimplementing" format-prompt with
backwards compatibility in mind, I replaced the (length> default 0) with
(not (null default)).  This would work on lists, but not on arrays.  I
have replaced it and updated the tests.

> Best, Arash

Re: completing-read depricated initial-input

[Emanuel Berg]

Arash Esbati wrote:

> Indeed, and the best part of it is
> `minibuffer-default-prompt-format' which you can customize.

Oh, excellent!

Instant

  (setq minibuffer-default-prompt-format " [%s]")

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Emanuel Berg]

Tassilo Horn wrote:

>> (let ((name "Danger"))
>>   (read-string (format-prompt "Name" name) nil nil name))
>
> Nice!

Actually no, try to replace existing code with that ... It's
the two occurrences of name (above) that makes it clumsy
and ugly.

Also this is not needed functionally, it's logical that it
isn't but as an example see for example `read-number' which
already does this for you. Eval this:

  (read-number "pills/day: "  4)

S0 why not `read-string' as well?

However - one can do one's own function for that ...

(defun read-string-1 (ps &optional def hist)
  (setq ps (format-prompt ps def))
  (read-string ps nil hist def))
  
(read-string-1 "name" "Danger")

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Emanuel Berg]

Lars Ingebrigtsen wrote:

> Or rather:
>
> (let ((name "Danger"))
>   (read-string (format-prompt "Name" name) nil nil name))

+1

The code still doesn't look good tho with the double nil and
then 'name' again :$

So then maybe the middle name should be Overkill?

-- 
underground experts united
https://dataswamp.org/~incal

Re: completing-read depricated initial-input

[Emanuel Berg]

Arash Esbati wrote:

>> I know but ... why are you telling me this?
>
> Because you asked? I parsed your question exactly the same
> way Tassilo did.

That's the problem with you people.

-- 
underground experts united
https://dataswamp.org/~incal