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

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

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.