[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Drew Adams
Subject: RE: [External] : Re: completing-read depricated initial-input
Date: Tue, 21 Jun 2022 22:07:41 +0000

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]