completing-read depricated initial-input

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: [External] : Re: completing-read depricated initial-input

[Drew Adams]

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

No, I don't think it is.  Not in `emacs -Q',
Emacs 28 and prior.  But maybe we differ on
what an explanation of why means.

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

[Michael Heerdegen]

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

> No, I don't think it is.  Not in `emacs -Q',
> Emacs 28 and prior.

I mean the sentence "This feature is deprecated--it is best to pass nil
for INITIAL-INPUT and supply the default value DEF instead." - a
sentence present for more than 20 years.

> But maybe we differ on what an explanation of why means.

Likely.

Michael.

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

[Drew Adams]

> > No, I don't think it is.  Not in `emacs -Q',
> > Emacs 28 and prior.
> 
> I mean the sentence "This feature is deprecated--it
> is best to pass nil for INITIAL-INPUT and supply the
> default value DEF instead." - a sentence present for
> more than 20 years.

That just says it's deprecated.  And says "it
is best...".  It doesn't say _why_ it is best.
It doesn't say why it was deprecated.  It
doesn't say how DEF suffices as a replacement.

Supplying DEF is _not_ an adequate substitute
for INITIAL-INPUT.  Each is useful.

(BTW, when comparing two things, the better
word to use is "better", not "best".)

> > But maybe we differ on what an explanation of why means.
> 
> Likely.

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: [External] : Re: completing-read depricated initial-input

[Emanuel Berg]

Drew Adams wrote:

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

Uhm, what's an Emacs library and how does one feel different
from another when used please?

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

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

[Drew Adams]

> Drew Adams wrote:

(In this context he wrote only
"That's a different question.")

> >> 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.
> 
> Uhm, what's an Emacs library and how does one feel different
> from another when used please?

At least the feeling part is a question for Arash,
to whom I replied.
___

An Elisp "library" is a "package" with or without
any additional package-handling paraphernalia.

It can be a single Elisp file or a set of related
ones, e.g., files that are required or otherwise
expected to be used together.

When package.el and package repositories were
added to Emacs, the notion of Elisp package was
born.  A package is a library plus some metadata
needed or optional for the package-handling
apparatus.

E.g., `dired+.el' is a single-file library.
Files `bookmark+*.el' compose library Bookmark+.
Neither library is in a package repository (both
were in MELPA at one time).

standard libraries again (was: Re: [External] : Re: completing-read depricated initial-input)

[Emanuel Berg]

Drew Adams wrote:

> An Elisp "library" is a "package" with or without any
> additional package-handling paraphernalia.

I think we should have standard libraries like for example
C with the aspiration for uniformness and general usefulness
for a broad range of purposes ... the rest would be libraries
or simply programs (and no such assumptions could then be
made), and last if it's bundled in the Elisp package way, then
it's a package of course.

Almost every program I ever wrote, one half or one third is
Elisp that doesn't really have anything to do with the
specific program, they are just basic building blocks.

Probably they have been implemented many, many times already
and - but I can't know where and after I've done it, they or
future people can't know it's here either.

Again, see this example for a lot of that ...

  https://dataswamp.org/~incal/emacs-init/perm.el

Here's an example what it would be like, but better and a lot
more ...

  https://dataswamp.org/~incal/emacs-init/math.el

After math, the sky is the limit. plato-close-reading.el and
feminist-gender-studies.el LOL :)

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

RE: standard libraries again (was: Re: [External] : Re: completing-read depricated initial-input)

[Drew Adams]

> > An Elisp "library" is a "package" with or without any
> > additional package-handling paraphernalia.
> 
> I think we should have standard libraries like for example
> C with the aspiration for uniformness and general usefulness
> for a broad range of purposes ... the rest would be libraries
> or simply programs (and no such assumptions could then be
> made), and last if it's bundled in the Elisp package way, then
> it's a package of course.

"Library" in Emacs/Elisp has long meant what I said.

Lisp files (e.g. `dired.el') or sets of files (e.g.
Gnus) included with Emacs (perhaps autoloaded) are
referred to as libraries.

You don't need to download them separately.  And
being part of Emacs, they're "standard", if you like.

And they're typically not packages.  The only ones
that are also packages are (I think) those that are
also available from a package repository.  I think
this is the case for Org, for example.

Re: standard libraries again (was: Re: [External] : Re: completing-read depricated initial-input)

[Emanuel Berg]

Drew Adams wrote:

>> I think we should have standard libraries like for example
>> C with the aspiration for uniformness and general
>> usefulness for a broad range of purposes ... the rest would
>> be libraries or simply programs (and no such assumptions
>> could then be made), and last if it's bundled in the Elisp
>> package way, then it's a package of course.
>
> "Library" in Emacs/Elisp has long meant what I said.
>
> Lisp files (e.g. `dired.el') or sets of files (e.g.
> Gnus) included with Emacs (perhaps autoloaded) are
> referred to as libraries.
>
> You don't need to download them separately.  And
> being part of Emacs, they're "standard", if you like.
>
> And they're typically not packages.  The only ones
> that are also packages are (I think) those that are
> also available from a package repository.  I think
> this is the case for Org, for example.

Now you're getting stuck on the names, I used what I think is
the best name to communicate the problem, poorly so it would
seem. No, change names one should be careful with.

The basic stuff has to be done over and over and locally for
everyone trying to solve some other problem on a whole other
level is th problem I describe, not whatever we or anyone else
calls stuff.

This is absolutely not a problem in Python and much less
a problem in C ... why? No reason what I can see in terms
of technology at least, right?

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

RE: standard libraries again (was: Re: [External] : Re: completing-read depricated initial-input)

[Drew Adams]

> > "Library" in Emacs/Elisp has long meant what I said...
> 
> Now you're getting stuck on the names

You asked "what's an Emacs library"?  I thought
you wanted to know what "library" means to Emacs.

Re: standard libraries again (was: Re: [External] : Re: completing-read depricated initial-input)

[Emanuel Berg]

Drew Adams wrote:

>> Now you're getting stuck on the names
>
> You asked "what's an Emacs library"? I thought you wanted to
> know what "library" means to Emacs.

So the truth to the matter is we have a bunch of files all
over the place, with no way of knowing what's in them and
what's where, and this lack of solid libraries compared to
what the most successful languages have is a big part of the
answer to the question why devel time in Elisp is often poor
or moderate?

I tried CL once with SLIME/SBCL/SDL2/OpenGL [1] but the
interactiveness of Elisp wasn't there ... hm, maybe that was
a game loop thing? Is it so, that CL has proper libraries only
Emacs Lisp doesn't?

Here library is a service to the programmer but also ...
well, obviously a utility for the programs to work.

Are libraries part of CL and part of its "industrial strength"
Lisp quality?

[1] https://dataswamp.org/~incal/common-lisp/general-base

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

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: [External] : Re: completing-read depricated initial-input

[Drew Adams]

> > (let ((list '("iffalse" "iftrue" "else" "fi")))
> >   (completing-read "Macro: "
> >                    (mapcar (lambda (x) (concat "\\" x)) list)
> >                    nil nil "\\"))
> 
> A convincing example, in my opinion.

Yes, it's a typical use case for non-nil INIT
arg: inserting a prefix.

And it's also essentially the case for non-nil
`insert-default-directory' for `read-file-name'.

(Try setting `insert-default-directory' to nil,
and see if you like it.  Now imagine if Emacs
hard-coded the behavior as nil and decided to
tell users that inserting `default-directory'
is deprecated...)

This case can arise if you use `try-completion'
to obtain such a common prefix, and then you use
`completing-read' to get the completion the user
wants.

Another example:
(completing-read "Color: " (defined-colors)
                 nil nil (buffer-substring-no-properties
	                     (widget-field-start widget)
	                     (point)))
___

Another typical use case is when the HIST arg is a
cons, so you can insert a particular history element
and position the cursor after it.

This case is what the doc string of `completing-read'
(misguidedly) says is the _only_ use case:

  (This is the only case in which you should use
  INITIAL-INPUT instead of DEF.)

(Our docs shouldn't use "should", BTW. ;-))

And it's not even necessarily a case of "instead
of DEF".  Using INIT here doesn't exclude also
using a DEF value.

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

[Michael Heerdegen]

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

> Another example:
> (completing-read "Color: " (defined-colors)
>                  nil nil (buffer-substring-no-properties
> 	                     (widget-field-start widget)
> 	                     (point)))

And the Gnu Emacs sources themselves contain dozens (around 40) examples
of nontrivial uses of that argument (not all may be justified, but at
least some are).

So it seems there are indeed valid use cases.

Michael.

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

[Christopher Dimech]

> Sent: Friday, June 24, 2022 at 4:41 AM
> From: "Michael Heerdegen" <michael_heerdegen@web.de>
> To: help-gnu-emacs@gnu.org
> Subject: Re: [External] : Re: completing-read depricated initial-input
>
> Drew Adams <drew.adams@oracle.com> writes:
>
> > Another example:
> > (completing-read "Color: " (defined-colors)
> >                  nil nil (buffer-substring-no-properties
> > 	                     (widget-field-start widget)
> > 	                     (point)))
>
> And the Gnu Emacs sources themselves contain dozens (around 40) examples
> of nontrivial uses of that argument (not all may be justified, but at
> least some are).
>
> So it seems there are indeed valid use cases.
>
> Michael.

The discouragement on the use of initial-value should be removed as well
as any deprecation statements.

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

[Emanuel Berg]

Michael Heerdegen wrote:

> So it seems there are indeed valid use cases.

One so far, the common prefix? That can and because of that
should be automated?

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

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

[Christopher Dimech]

> Sent: Friday, June 24, 2022 at 4:30 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Michael Heerdegen" <michael_heerdegen@web.de>, "Arash Esbati" <arash@gnu.org>
> 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>
> Subject: RE: [External] : Re: completing-read depricated initial-input
>
> > > (let ((list '("iffalse" "iftrue" "else" "fi")))
> > >   (completing-read "Macro: "
> > >                    (mapcar (lambda (x) (concat "\\" x)) list)
> > >                    nil nil "\\"))
> >
> > A convincing example, in my opinion.
>
> Yes, it's a typical use case for non-nil INIT
> arg: inserting a prefix.
>
> And it's also essentially the case for non-nil
> `insert-default-directory' for `read-file-name'.
>
> (Try setting `insert-default-directory' to nil,
> and see if you like it.  Now imagine if Emacs
> hard-coded the behavior as nil and decided to
> tell users that inserting `default-directory'
> is deprecated...)
>
> This case can arise if you use `try-completion'
> to obtain such a common prefix, and then you use
> `completing-read' to get the completion the user
> wants.
>
> Another example:
> (completing-read "Color: " (defined-colors)
>                  nil nil (buffer-substring-no-properties
> 	                     (widget-field-start widget)
> 	                     (point)))
> ___
>
> Another typical use case is when the HIST arg is a
> cons, so you can insert a particular history element
> and position the cursor after it.
>
> This case is what the doc string of `completing-read'
> (misguidedly) says is the _only_ use case:
>
>   (This is the only case in which you should use
>   INITIAL-INPUT instead of DEF.)
>
> (Our docs shouldn't use "should", BTW. ;-))
>
> And it's not even necessarily a case of "instead
> of DEF".  Using INIT here doesn't exclude also
> using a DEF value.

Correct, there are use cases for init and def to be different,
and for who do not want init, nil is specified.

But I do agree with the recommendation of not using initial-value,
is not based on the existence of any coherent problem to elisp
package success.  Looking at in, the discouragement is deeply
rooted around the use cases seen in many packages.  And ignore
the truly great ones that might use initial-value it future.

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

[Emanuel Berg]

Drew Adams wrote:

>>> (let ((list '("iffalse" "iftrue" "else" "fi")))
>>>   (completing-read "Macro: "
>>>                    (mapcar (lambda (x) (concat "\\" x)) list)
>>>                    nil nil "\\"))
>> 
>> A convincing example, in my opinion.
>
> Yes, it's a typical use case for non-nil INIT
> arg: inserting a prefix.

Automate. Generic, perfect execution forever on with no human
factor error-proneness involved or relied upon be it at the
programmer or user level ...

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

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: [External] : Re: completing-read depricated initial-input

[Drew Adams]

> I already asked, what concept is the initial value?
...
> "Why is the computer putting stuff there?  It's
> the area where the human user should put stuff."
...
> There is only one use case (completion with a
> common prefix)

Please read (again?) what others have written.

First, it's initial _input_, not initial value.  It's
about prefilling the minibuffer with particular text,
which you can use any way you like (e.g. edit it).

A common prefix is only one such use case.  (For one
thing, prefix completion isn't all there is nowadays.)

As the arg to `completing-read', `read-from-minibuffer',
`read-string', `read-buffer', `read-minibuffer', etc.,
it's unrelated to any default value.  (More precisely,
it's not _necessarily_ related.)

There's no reason it shouldn't be possible to provide
you an initial-input that's useful for editing, even
one that might not be directly related to any default
value.
___

As for inserting the _default value_ (not the INIT arg)
in the minibuffer automatically: a user might want that.
You might not; others might.  This should be a user
choice, not imposed one way or the other.

As I said:

  If you often want to use or edit the default value,
  then consider setting `icicle-default-value' to
  non-`nil' and non-`t' [to insert it in the minibuffer].

  If you rarely do so, then consider using `nil' or `t'
  [to not insert it].

As one user, I'm in the former camp: I often want
to use or edit the default value, and as a result I
prefer that it be inserted automatically.

That is, I prefer to hit a key to delete it, in the
(fewer) cases where I don't want it, than to have to
hit `M-n' to insert it, in the (more numerous) cases
where I do want it (including to edit it, rather
than just accept it as is).

Remember that minibuffer reading is not always, or
even usually, a must-match situation.  Even for
completion, there's lax completion (REQUIRE-MATCH
nil).

With well-designed code a `completing-read' call
with lax completion can nevertheless provide a
helpful default value - e.g., one that I might want
to edit slightly.

Of course, a `completing-read' call that gives you
a poor default value lessens the utility of using
it, and so lessens the usefulness of inserting it.

Again, this want-or-don't-want-DEF-inserted is akin
to whether to use `delete-selection-mode'.  I do
use that mode.  Users are different.

And it's important, IMO, to have a single key to
empty the minibuffer, regardless of where point is.
In `icy-mode' that's `M-k', by default.  Vanilla
Emacs still has no such key.  (Why not?)

Neither (1) having to use `M-n' to insert the
default, nor (2) having to use `M-k' to erase its
automatic insertion, is super bothersome.  Each
can make sense and be preferred by some users.
That's all.
___

Summary:

1. There are uses for an initial-input arg.
2. Automatic insertion of the default value can
   be useful and preferred by some users.  Let
   users choose.
3. Emacs shouldn't deprecate, let alone get rid
   of, an initial-input arg for `completing-read'.
   In fact, it should consider adding one for
   some functions that don't have it - some of
   the `read-*' functions, for example.

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

[Christopher Dimech]

> Sent: Saturday, June 25, 2022 at 2:30 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Emanuel Berg" <incal@dataswamp.org>, "help-gnu-emacs@gnu.org" <help-gnu-emacs@gnu.org>
> Subject: RE: [External] : Re: completing-read depricated initial-input
>
> > I already asked, what concept is the initial value?
> ...
> > "Why is the computer putting stuff there?  It's
> > the area where the human user should put stuff."
> ...
> > There is only one use case (completion with a
> > common prefix)
>
> Please read (again?) what others have written.
>
> First, it's initial _input_, not initial value.  It's
> about prefilling the minibuffer with particular text,
> which you can use any way you like (e.g. edit it).
>
> A common prefix is only one such use case.  (For one
> thing, prefix completion isn't all there is nowadays.)
>
> As the arg to `completing-read', `read-from-minibuffer',
> `read-string', `read-buffer', `read-minibuffer', etc.,
> it's unrelated to any default value.  (More precisely,
> it's not _necessarily_ related.)
>
> There's no reason it shouldn't be possible to provide
> you an initial-input that's useful for editing, even
> one that might not be directly related to any default
> value.
> ___
>
> As for inserting the _default value_ (not the INIT arg)
> in the minibuffer automatically: a user might want that.
> You might not; others might.  This should be a user
> choice, not imposed one way or the other.
>
> As I said:
>
>   If you often want to use or edit the default value,
>   then consider setting `icicle-default-value' to
>   non-`nil' and non-`t' [to insert it in the minibuffer].
>
>   If you rarely do so, then consider using `nil' or `t'
>   [to not insert it].
>
> As one user, I'm in the former camp: I often want
> to use or edit the default value, and as a result I
> prefer that it be inserted automatically.
>
> That is, I prefer to hit a key to delete it, in the
> (fewer) cases where I don't want it, than to have to
> hit `M-n' to insert it, in the (more numerous) cases
> where I do want it (including to edit it, rather
> than just accept it as is).
>
> Remember that minibuffer reading is not always, or
> even usually, a must-match situation.  Even for
> completion, there's lax completion (REQUIRE-MATCH
> nil).
>
> With well-designed code a `completing-read' call
> with lax completion can nevertheless provide a
> helpful default value - e.g., one that I might want
> to edit slightly.
>
> Of course, a `completing-read' call that gives you
> a poor default value lessens the utility of using
> it, and so lessens the usefulness of inserting it.
>
> Again, this want-or-don't-want-DEF-inserted is akin
> to whether to use `delete-selection-mode'.  I do
> use that mode.  Users are different.
>
> And it's important, IMO, to have a single key to
> empty the minibuffer, regardless of where point is.
> In `icy-mode' that's `M-k', by default.  Vanilla
> Emacs still has no such key.  (Why not?)
>
> Neither (1) having to use `M-n' to insert the
> default, nor (2) having to use `M-k' to erase its
> automatic insertion, is super bothersome.  Each
> can make sense and be preferred by some users.
> That's all.
> ___
>
> Summary:
>
> 1. There are uses for an initial-input arg.
> 2. Automatic insertion of the default value can
>    be useful and preferred by some users.  Let
>    users choose.
> 3. Emacs shouldn't deprecate, let alone get rid
>    of, an initial-input arg for `completing-read'.
>    In fact, it should consider adding one for
>    some functions that don't have it - some of
>    the `read-*' functions, for example.

I fully support the summary as well.

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

[Emanuel Berg]

Drew Adams wrote:

> 1. There are uses for an initial-input arg.

I've only seen one use case for inserting the initial value
and it's the completion one, I don't like that to begin with
and with this use case I like it even less since basically the
computer then tells the user "Okay, this is as far as I can
take you, now you start complete your way thru the rest of the
jungle without me".

> 2. Automatic insertion of the default value can be useful
>    and preferred by some users. Let users choose.

Make that an option if so the users can put to t if they want
it rather than have the programer give the default value twice
to the same function.

> 3. Emacs shouldn't deprecate, let alone get rid of, an
>    initial-input arg for `completing-read'.

Prognosis: annihilation.

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

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

[Drew Adams]

> > 1. There are uses for an initial-input arg.
> 
> I've only seen one use case for inserting the initial value
> and it's the completion one,

You keep repeating that, and it's wrong.
See my response to another of your mails
today that repeats the same thing.

> I don't like that to begin with

You don't have to like it.  You don't have
to use it in your code.  It's an optional
parameter.

A different question is whether you have to
use some code that uses it.  Ideally users
would have a _general_ way of expressing an
individual preference such as yours.  That's
different from _removing_ the possibility of
providing such behavior.

> and with this use case I like it even less
> since basically the computer then tells the
> user "Okay, this is as far as I can take
> you, now you start complete your way thru
> the rest of the jungle without me".

Nonsense.  Boogeyman?

Show da codez if you really have something to
say there.

> > 2. Automatic insertion of the default value
> >    can be useful and preferred by some users.
> >    Let users choose.
> 
> Make that an option

Did you read what I wrote?  I detailed just
such an option.

> rather than have the programer give the default
> value twice to the same function.

Did anyone suggest giving the default value twice
to the same function?  I wonder if you read the
message you're replying to.

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

[Emanuel Berg]

Drew Adams wrote:

>>> Automatic insertion of the default value can be useful and
>>> preferred by some users. Let users choose.
>> 
>> Make that an option
>
> [...] I detailed just such an option.

But then you'd need initial-input even less?

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

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

[Drew Adams]

> >>> Automatic insertion of the default value
> >>> can be useful and preferred by some users.
> >>> Let users choose.
> >> Make that an option
> > I detailed just such an option.
> 
> But then you'd need initial-input even less?

I've already explained that a default value is
something different from an initial-input value -
they have different behavior and thus different
uses - and why that remains true even if someone
chooses to automatically insert the default value.

And I posted some of the doc, which makes clear
that the option values that insert the default
value do so only when the INIT-VALUE is a no-op:

  When [the option] is non-nil and non-t,
  and the initial-input argument is nil or "", 
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
  the default value can be inserted into the
  minibuffer as the initial input.

E.g., if you set the option to `insert-end' then
the default value is inserted (with point after
it) *ONLY IF* there's no INIT-VALUE to insert.

This inserts the default value, `jjj':

(completing-read "q: " '(aaa bbb ccc ddd)
                 nil nil "" nil "jjj")
                          ^       ^
                        init    default

But if there's an INIT-VALUE then it's inserted.
This inserts `iii':

(completing-read "q: " '(aaa bbb ccc ddd)
                 nil nil "iii" nil "jjj")
                           ^         ^
                         init      default
___

[I also suggested it might be useful to give
users some general control over the INIT-VALUE.
Icicles hasn't done that - it just adds user
control of the default value.  For INIT-VALUE
Icicles just respects the vanilla behavior.
You know - the arg that Emacs itself claims is
deprecated?  Icicles respects that one, as is.]
___

https://www.emacswiki.org/emacs/Icicles_-_Customization_and_General_Tips#icicle-default-value

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

[Emanuel Berg]

Drew Adams wrote:

>>>>> Automatic insertion of the default value
>>>>> can be useful and preferred by some users.
>>>>> Let users choose.
>>>>
>>>> Make that an option
>>>
>>> I detailed just such an option.
>> 
>> But then you'd need initial-input even less?
>
> I've already explained that a default value is something
> different from an initial-input value - they have different
> behavior and thus different uses - and why that remains true
> even if someone chooses to automatically insert the
> default value.
>
> And I posted some of the doc, which makes clear
> that the option values that insert the default
> value do so only when the INIT-VALUE is a no-op:
>
>   When [the option] is non-nil and non-t,
>   and the initial-input argument is nil or "", 
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
>   the default value can be inserted into the
>   minibuffer as the initial input.
>
> E.g., if you set the option to `insert-end' then
> the default value is inserted (with point after
> it) *ONLY IF* there's no INIT-VALUE to insert.
>
> This inserts the default value, `jjj':
>
> (completing-read "q: " '(aaa bbb ccc ddd)
>                  nil nil "" nil "jjj")
>                           ^       ^
>                         init    default

Yeah but you see yourself how that looks? You a collector of
nils and empty strings now?

The suggestion where you can have a function to do whatever is
the best ...

Meanwhile the standard interface will be simplified and
unclear concepts with unclear purposes will be pruned as well
as the necessity to have all those nils, empty strings
etc everywhere just to do a basic thing.

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

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

[Drew Adams]

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

No comment on all of that.  At least not until
it becomes something real to worry about. ;-)

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

Possible insertion of the default value, and its
possible addition to the prompt, should be handled
more generally than just for completion.

Ideally the choice should belong mainly to users,
and it should apply to pretty much all minibuffer
reading functions that allow for a default value.
_____

FWIW, Icicle mode handles this with user option
`icicle-default-value'.

When the value's non-`nil' and arg INITIAL-INPUT
of minibuffer-reading functions is `nil' or "",
the DEFAULT-VALUE argument can be inserted into
the minibuffer as initial input.

For `completing-read', `read-file-name'[*], and
`read-string', if the option value is `t' then the
default value is added to the prompt as a hint.

Adding the default value to the prompt corresponds
to a more or less conventional behavior of vanilla
Emacs.  But Emacs doesn't do that systematically.
Instead, it hard-codes default values into prompts
here and there.  It's up to the particular command
to decide about this - ad hoc.

By design, individual Icicles commands never add
the default value to a prompt themselves.  Instead,
option `icicle-default-value' controls the behavior.

Non-`nil' and non-`t' inserts the default value
into the minibuffer as the initial value.

`nil' neither inserts the default value nor adds
it to the prompt.

(If the value is `t' or `nil', you can always use
`M-n' to insert the default value manually.) 

If you often want to use or edit the default value,
then consider setting `icicle-default-value' to
non-`nil' and non-`t'.  If you rarely do so, then
consider using `nil' or `t'.

A non-`nil', non-`t' value also controls whether
or not the inserted default value is preselected
(as the active region), and where to leave the
cursor: at its beginning or end.

Preselecting the value can be useful in Delete
Selection mode, because it makes it easy to
replace that value by typing characters, or delete
it by hitting `DEL' or `C-d'.  (However, all of
the initial input is deleted with `C-d' or `DEL',
which is inconvenient if you just want to edit it
slightly.)

Summary of values:

 Don't insert default into minibuffer:

   nil  - Don't add to prompt.
   t    - Add to prompt if `completing-read',
          `read-file-name', or `read-string'.

 Do insert default into minibuffer:

   `insert-start'    - Leave cursor at start.
   `insert-end'      - Leave cursor at end.
   `preselect-start' - Preselect and put cursor
                       at beginning.
   `preselect-end'   - Preselect and put cursor
                       at end.

`t' is the default.  (I use `insert-end'.)
_____

When Icicles automatically puts the default value
into the prompt, as a hint, it also replaces it
there if put there already by some command, so
the hint format will be systematically the same.

Option `icicle-default-in-prompt-format-function'
defines the format to use.  By default it's this:
 (lambda (default) (format " (%s)" default))

Function `icicle-handle-default-for-prompt' does
the work:
__

 (icicle-handle-default-for-prompt PROMPT DEFAULT INCLUDE)

 Return PROMPT, possibly changed to format or remove the DEFAULT value.
 Argument INCLUDE:
  * nil means do not include DEFAULT in prompt.  Remove it if there.
  * non-nil means include DEFAULT, formatted according to
    `icicle-default-in-prompt-format-function'.

 In the existing PROMPT before modification, recognizes inclusion of
 a default value according to these possible patterns:

  `minibuffer-default-in-prompt-regexps'
  "(default ___):"
  "(default is ___):"
  " [___] "
__

Icicles just reuses vanilla Emacs variable
`minibuffer-default-in-prompt-regexps', which is
defined for `minibuffer-electric-default-mode'.

  A list of regexps matching the parts of minibuffer
  prompts showing defaults.
  When 'minibuffer-electric-default-mode' is active,
  these regexps are used to identify the portions of
  prompts to elide.

(`minibuffer-electric-default-mode'e tries to show
a default value in a prompt only when hitting RET
yields that value.  If you edit the minibuffer text
so it's no longer the default value, the default's
removed from the prompt.)
____________________


[*]: However, for `read-file-name', if option
`insert-default-directory' is non-`nil' then, to
avoid duplication:

* If the default value is the same as the value of
  `default-directory' then it's not added to the
  prompt.

* If the default value is added to the prompt then
  it's first made relative to `default-directory'.

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

[Christopher Dimech]

> Sent: Friday, June 24, 2022 at 12:10 PM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Stefan Monnier" <monnier@iro.umontreal.ca>, "Michael Heerdegen" <michael_heerdegen@web.de>
> Cc: "Arash Esbati" <arash@gnu.org>, "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: [External] : 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).
>
> No comment on all of that.  At least not until
> it becomes something real to worry about. ;-)
>
> > 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).
>
> Possible insertion of the default value, and its
> possible addition to the prompt, should be handled
> more generally than just for completion.
>
> Ideally the choice should belong mainly to users,
> and it should apply to pretty much all minibuffer
> reading functions that allow for a default value.

Quite right.  The ability to show an entry rather than always
keeping it blank should be kept.

> _____
>
> FWIW, Icicle mode handles this with user option
> `icicle-default-value'.
>
> When the value's non-`nil' and arg INITIAL-INPUT
> of minibuffer-reading functions is `nil' or "",
> the DEFAULT-VALUE argument can be inserted into
> the minibuffer as initial input.
>
> For `completing-read', `read-file-name'[*], and
> `read-string', if the option value is `t' then the
> default value is added to the prompt as a hint.
>
> Adding the default value to the prompt corresponds
> to a more or less conventional behavior of vanilla
> Emacs.  But Emacs doesn't do that systematically.
> Instead, it hard-codes default values into prompts
> here and there.  It's up to the particular command
> to decide about this - ad hoc.
>
> By design, individual Icicles commands never add
> the default value to a prompt themselves.  Instead,
> option `icicle-default-value' controls the behavior.
>
> Non-`nil' and non-`t' inserts the default value
> into the minibuffer as the initial value.
>
> `nil' neither inserts the default value nor adds
> it to the prompt.
>
> (If the value is `t' or `nil', you can always use
> `M-n' to insert the default value manually.)
>
> If you often want to use or edit the default value,
> then consider setting `icicle-default-value' to
> non-`nil' and non-`t'.  If you rarely do so, then
> consider using `nil' or `t'.
>
> A non-`nil', non-`t' value also controls whether
> or not the inserted default value is preselected
> (as the active region), and where to leave the
> cursor: at its beginning or end.
>
> Preselecting the value can be useful in Delete
> Selection mode, because it makes it easy to
> replace that value by typing characters, or delete
> it by hitting `DEL' or `C-d'.  (However, all of
> the initial input is deleted with `C-d' or `DEL',
> which is inconvenient if you just want to edit it
> slightly.)
>
> Summary of values:
>
>  Don't insert default into minibuffer:
>
>    nil  - Don't add to prompt.
>    t    - Add to prompt if `completing-read',
>           `read-file-name', or `read-string'.
>
>  Do insert default into minibuffer:
>
>    `insert-start'    - Leave cursor at start.
>    `insert-end'      - Leave cursor at end.
>    `preselect-start' - Preselect and put cursor
>                        at beginning.
>    `preselect-end'   - Preselect and put cursor
>                        at end.
>
> `t' is the default.  (I use `insert-end'.)
> _____
>
> When Icicles automatically puts the default value
> into the prompt, as a hint, it also replaces it
> there if put there already by some command, so
> the hint format will be systematically the same.
>
> Option `icicle-default-in-prompt-format-function'
> defines the format to use.  By default it's this:
>  (lambda (default) (format " (%s)" default))
>
> Function `icicle-handle-default-for-prompt' does
> the work:
> __
>
>  (icicle-handle-default-for-prompt PROMPT DEFAULT INCLUDE)
>
>  Return PROMPT, possibly changed to format or remove the DEFAULT value.
>  Argument INCLUDE:
>   * nil means do not include DEFAULT in prompt.  Remove it if there.
>   * non-nil means include DEFAULT, formatted according to
>     `icicle-default-in-prompt-format-function'.
>
>  In the existing PROMPT before modification, recognizes inclusion of
>  a default value according to these possible patterns:
>
>   `minibuffer-default-in-prompt-regexps'
>   "(default ___):"
>   "(default is ___):"
>   " [___] "
> __
>
> Icicles just reuses vanilla Emacs variable
> `minibuffer-default-in-prompt-regexps', which is
> defined for `minibuffer-electric-default-mode'.
>
>   A list of regexps matching the parts of minibuffer
>   prompts showing defaults.
>   When 'minibuffer-electric-default-mode' is active,
>   these regexps are used to identify the portions of
>   prompts to elide.
>
> (`minibuffer-electric-default-mode'e tries to show
> a default value in a prompt only when hitting RET
> yields that value.  If you edit the minibuffer text
> so it's no longer the default value, the default's
> removed from the prompt.)
> ____________________
>
>
> [*]: However, for `read-file-name', if option
> `insert-default-directory' is non-`nil' then, to
> avoid duplication:
>
> * If the default value is the same as the value of
>   `default-directory' then it's not added to the
>   prompt.
>
> * If the default value is added to the prompt then
>   it's first made relative to `default-directory'.
>
>

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

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

[Drew Adams]

> You have to delete the initial input if it's not what
> you want or if you want to see the other possibilities.

That's akin to the arguments pro/con
`delete-selection-mode'.  One person says
she wants to be able to immediately type to
replace/delete, without first having to use
`C-w'.  Another person says she prefers to
always explicitly use `C-w' first, and not
have Emacs automatically delete selected
text by default.

Au choix - vive la difference.  You get to
choose.

> So basically all occurrences

"Basically"? or "all"?  Do you mean not all
but most/generally?  Or do you mean all, so
not just basically?

I guess you mean almost all, aka _not_ all.

> where INITIAL-INPUT is used as a kind of default
> value are better handled with the DEF argument.

Sounds a bit circular.  That just says that DEF
is a better default-value behavior.  Initial
input isn't the same as a default value.  The
behavior/effect is different.

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

The behavior of INITIAL-INPUT differs from that
of DEF.  That's enough to point to different uses.

Unless, that is, you can convince all that the
DEF behavior is always preferable - for all users,
all calls to `completing-read', and all contexts.

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

[Tassilo Horn]

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

>> You have to delete the initial input if it's not what
>> you want or if you want to see the other possibilities.
>
> That's akin to the arguments pro/con `delete-selection-mode'.

No, not really.  It is easy for every user to enable or disable
delete-selection-mode.  That's not true for initial-input.  If the
programmer used it, you get it, and there's no easy way to disable it.

>> So basically all occurrences
>
> "Basically"? or "all"?  Do you mean not all
> but most/generally?  Or do you mean all, so
> not just basically?
>
> I guess you mean almost all, aka _not_ all.

Yes, I've meant that I cannot think of a situation where initial-input
used as a default value is suitable and even in non-default-value
scenarios I was able to come up with only two sensible use-cases.  And
honestly, only the completing-read-multiple case is really convincing to
me.

>> where INITIAL-INPUT is used as a kind of default
>> value are better handled with the DEF argument.
>
> Sounds a bit circular.  That just says that DEF
> is a better default-value behavior.  Initial
> input isn't the same as a default value.  The
> behavior/effect is different.

Yes.  What I've meant to say is that in the past, initial-input was
frequently used as a means to insert a default value, maybe because it
was available earlier.  I don't know exactly, I'm an emacs newby using
it only since 2001.

And since it comes first in the completing-read argument list and
INITIAL-INPUT is more in the face than DEF, chances are that people read
it first, it looks suitable, and so it is used for the default value
case.

>> 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.)
>
> The behavior of INITIAL-INPUT differs from that
> of DEF.  That's enough to point to different uses.
>
> Unless, that is, you can convince all that the
> DEF behavior is always preferable - for all users,
> all calls to `completing-read', and all contexts.

I can only say that except for the crm case I cannot come up with a good
example where it's useful.  But if you know some, I'm eager to read
them.

And in any case: there's no need to have flamewars about some argument
being called deprecated.  It's one of the central functions in emacs,
the argument is in the middle of the argument list.  There's no doubt it
will still be there in 20 years. ;-)

Bye,
Tassilo

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

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

Jun 23, 2022, 19:56 by tsdh@gnu.org:

> Drew Adams <drew.adams@oracle.com> writes:
>
>>> You have to delete the initial input if it's not what
>>> you want or if you want to see the other possibilities.
>>>
>>
>> That's akin to the arguments pro/con `delete-selection-mode'.
>>
>
> No, not really.  It is easy for every user to enable or disable
> delete-selection-mode.  That's not true for initial-input.  If the
> programmer used it, you get it, and there's no easy way to disable it.
>
>>> So basically all occurrences
>>>
>>
>> "Basically"? or "all"?  Do you mean not all
>> but most/generally?  Or do you mean all, so
>> not just basically?
>>
>> I guess you mean almost all, aka _not_ all.
>>
>
> Yes, I've meant that I cannot think of a situation where initial-input
> used as a default value is suitable and even in non-default-value
> scenarios I was able to come up with only two sensible use-cases.  And
> honestly, only the completing-read-multiple case is really convincing to
> me.
>
>>> where INITIAL-INPUT is used as a kind of default
>>> value are better handled with the DEF argument.
>>>
>>
>> Sounds a bit circular.  That just says that DEF
>> is a better default-value behavior.  Initial
>> input isn't the same as a default value.  The
>> behavior/effect is different.
>>
>
> Yes.  What I've meant to say is that in the past, initial-input was
> frequently used as a means to insert a default value, maybe because it
> was available earlier.  I don't know exactly, I'm an emacs newby using
> it only since 2001.
>

That would be a mistake on their part.  Please refrain using the 20 year 
card to thumb down others simply to push towards some direction.  


> And since it comes first in the completing-read argument list and
> INITIAL-INPUT is more in the face than DEF, chances are that people read
> it first, it looks suitable, and so it is used for the default value
> case.
>
>>> 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.)
>>>
>>
>> The behavior of INITIAL-INPUT differs from that
>> of DEF.  That's enough to point to different uses.
>>
>> Unless, that is, you can convince all that the
>> DEF behavior is always preferable - for all users,
>> all calls to `completing-read', and all contexts.
>>
>
> I can only say that except for the crm case I cannot come up with a good
> example where it's useful.  But if you know some, I'm eager to read
> them.
>
> And in any case: there's no need to have flamewars about some argument
> being called deprecated.  It's one of the central functions in emacs,
> the argument is in the middle of the argument list.  There's no doubt it
> will still be there in 20 years. ;-)
>
If emacs discourages things, people will take it seriously.  A deprecated statement has consequences to many people in the way they code.  It is assumed that the  functionality is not to be relied upon too much.

It becomes a flame war when people start insisting on discouraging things that do not constitute a problem.  There is nothing inherently wrong with it.  

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

[Jean Louis]

* carlmarcos--- via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> [2022-06-24 14:25]:
> If emacs discourages things, people will take it seriously.  A
> deprecated statement has consequences to many people in the way they
> code.  It is assumed that the  functionality is not to be relied
> upon too much.

You refer to this:

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.  (*Note* that this is different from
  ‘read-from-minibuffer’ and related functions, which use one-indexing
  for POSITION.)  This feature is deprecated--it is best to pass nil
  for INITIAL-INPUT and supply the default value DEF instead.  The
  user can yank the default value into the minibuffer easily using
  M-n.

Maybe author of that description could consider various use
cases. That assumes that somebody is usig INITIAL-INPUT as replacement
for DEF. 

It also assumes what is best for programmer, with "it is best to pass
nil" -- but that is best for who? Maybe somebody who does not use it
or has confusion with it.

INITIAL-INPUT and DEF are different things, each has its own use in
various situations.

Instead of deprecating 2 different functions because some people
assume they are same, description shall be written so that there is no
confusion what is DEF and what is INITIAL-INPUT.

-- 
Jean

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

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

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

[Emanuel Berg]

Jean Louis wrote:

> Maybe author of that description could consider various use
> cases. That assumes that somebody is usig INITIAL-INPUT as
> replacement for DEF.
>
> It also assumes what is best for programmer, with "it is
> best to pass nil" -- but that is best for who?
> Maybe somebody who does not use it or has confusion with it.

Yes, make that whole function deprecated perhaps and write
a new one, one with fewer formal parameters and one that
doesn't need any "side notes" in its docstring ...

> Instead of deprecating 2 different functions because some
> people assume they are same, description shall be written so
> that there is no confusion what is DEF and what is
> INITIAL-INPUT.

You start, what is INITIAL-INPUT? We have only heard of one
use case (completion) and it isn't good enough.

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

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

[Drew Adams]

> what is INITIAL-INPUT? We have only heard of one
> use case (completion) and it isn't good enough.

The use case you're (apparently) thinking of has
nothing per se to do with completion.

Witness the fact that an INITIAL-INPUT arg
(UN-deprecated) is allowed for some read functions
- from specific such as `read-string' to general
such as `read-from-minibuffer' - that don't use
completion at all.

It's not only about completion.  And it's not only
about inserting a _prefix_ of text you might want
to enter.

Putting _anything_ in the minibuffer automatically,
whether it comes from an INITIAL-INPUT arg, or a
DEFAULT arg, or a global variable, or ... aims to
provide you text for editing (not just completing).
That's all.  Can that be handy?  Depends on context
and user preference.

Whether that provides for one use case or a hundred
depends on the context and on how you look at it.

It's a particular _behavior_.  How or whether one
makes use of it is quite another thing - just as
for every behavior.

What's important are:

 1. Having the behavior as a possible one - a
    tool in the toolkit.
 2. Giving users some control over it.

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

[Christopher Dimech]

> Sent: Wednesday, June 22, 2022 at 8:41 AM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Arash Esbati" <arash@gnu.org>
> 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: [External] : Re: completing-read depricated initial-input
>
> > > 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.

The evaluation makes INITIAL-INPUT worthwhile to keep.

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