all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Christopher Dimech <dimech@gmx.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: Michael Heerdegen <michael_heerdegen@web.de>,
	"eliz@gnu.org" <eliz@gnu.org>,
	"heimeborgia@protonmail.com" <heimeborgia@protonmail.com>,
	"65348@debbugs.gnu.org" <65348@debbugs.gnu.org>
Subject: bug#65348: RE: [External] : bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively
Date: Mon, 21 Aug 2023 08:29:52 +0200	[thread overview]
Message-ID: <trinity-ba45dc11-cbb7-4bdd-89dd-9eac5480bc5e-1692599392908@3c-app-mailcom-bs13> (raw)
In-Reply-To: <SJ0PR10MB54889D437AFAD6CB4373154BF31EA@SJ0PR10MB5488.namprd10.prod.outlook.com>



> Sent: Monday, August 21, 2023 at 5:23 PM
> From: "Drew Adams" <drew.adams@oracle.com>
> To: "Christopher Dimech" <dimech@gmx.com>
> Cc: "Michael Heerdegen" <michael_heerdegen@web.de>, "eliz@gnu.org" <eliz@gnu.org>, "heimeborgia@protonmail.com" <heimeborgia@protonmail.com>, "65348@debbugs.gnu.org" <65348@debbugs.gnu.org>
> Subject: bug#65348: RE: [External] : bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively
>
> > > > I suggest that the capability of prefilling the minibuffer be
> > > > reintroduced for the new scheme as well.  Because from what
> > > > I see, the deprecated parts include a feature that will be
> > > > automatically discarded under the new scheme.
> > >
> > > I missed that memo completely!  What's the new scheme?
> >
> > The new scheme of using history which automatically discarded
> > the capability of prefilling the minibuffer before cycling can
> > start.
>
> I don't understand.  There's a proposal to NOT
> SUPPORT INITIAL at all anymore?  I definitely
> oppose that.  What is hoped to be _gained_, by
> taking away this feature?

It all depends whether INITIAL-INPUT would be deprecated.



> > > What is expected to be automatically discarded?  Where
> > > is the presentation/discussion of such a change?  Is
> > > it this bug thread?  (Why would it be in a bug thread?)
> >
> > As INITIAL is obsolete, the capability of prefilling the
> > minibuffer entry would be missing.
>
> That's ridiculous.  Why would anyone want to remove
> that feature?  Have we gone from (1) some deciding
> that INITIAL isn't as good as DEFAULT (even though
> they have different behaviors and thus different
> uses) to (2) some deciding that INITIAL shouldn't
> be supported at all?
>
> Was there some problem discovered with allowing
> users to use INITIAL if/when they really want to?
> I don't think so.

This really has to be cleared out.

> > > I hope we're not changing the longstanding arg list of
> > > `completing-read' (except perhaps to add more args,
> > > which might be debatable but excusable).
> >
> > It is a problem.  We have been very happy adding more args for
> > new features, without taking serious consideration the resulting
> > confusion between old schemes and new schemes, resulting in numerous
> > recommendations.  The less recommendations on how to use a function
> > the better things will be to work with.
>
> Sorry to say it, but that's just nonsense.  If
> Someone (TM) finds it too complicated to deal
> with complex recommendations then don't recommend
> anything about INITIAL or whatever.

I agree

> That's not a
> reason to remove it - just because some people
> might not ever use it.  If your guidance seems to
> be ending up to complicated then maybe it's a bit
> misguided.  Maybe start over and don't advise so
> much.  WHAT the CODE does is what matters, and
> that's clear - clearer than any supposedly derived
> description of what you should use when.

The changes to completing-read needs clarification.

> `completing-read' _is_ complex, and it _does_ have
> many different use patterns.  Should we remove
> some of the different values we allow for argument
> COMPLETIONS, because that would make describing
> the function easier or simpler to understand?
>
> That way lies madness.  If Someone wants a
> simplified, dumbed-down `completing-read' then
> they can create another function that does what
> they want.  But leave the original alone. There's
> no need to go deprecating and removing features
> that others put to what they consider to be good
> use.

I agree.

> I don't know who's requesting such changes,
> misguidedly thinking they're improving things,
> so I write "Someone".  I mean "they", whoever
> they might be.
>
> > When deep changes happen, I prefer to keep the old as is,
> > and make a new function for significant changes that affect
> > the old functionality.
>
> Make a new function that _doesn't_ affect the
> old functionality.  That's the point.  If
> Someone wants a new/different behavior then
> they can code it up and give it a name - a
> new name.  It shouldn't affect good old
> `completing-read' at all.

Absolutely right.

> > It does not happen regularly that new features are accessed in ways that
> > maintain clarity and avoids unnecessary complexity.
>
> And?  Not sure I follow your point there.

Serious focus on clarity is needed, rather than simply go on with
changes.

> > > Let's please keep this function backward-compatible.
> > > If you want something different, please add it as a
> > > separate function.
> >
> > That's the whole point, and we should follow that route
> > as an important strategy for maintainers.
>
> I think maybe you're agreeing with me, or I with
> you?

I am agreeing.

> Regardless of who's pushing it, if Someone wants
> to get rid of INITIAL then I object.  I objected
> when the doc was changed to say it's ill-advised
> etc.

I concur with your objection.

> I don't have a problem with calling out the
> special case that's mentioned wrt placement of
> point.  I do object to the doc saying that that's
> the ONLY case where anyone should ever use INITIAL.
>
> Let's please stop with the "shoulds" altogether,
> unless they're backed up with clear reasons.
> Otherwise that's just "I don't like" whatever -
> beards or piano or watermelon or...
>
> And there never was any need/reason for such a
> restriction/admonishment against INITIAL.  It's
> just overeager-beaver control syndrome, IMO.
> There was never anything to warn users away from
> or protect them from.  Using INITIAL won't get
> anyone in trouble.  Whether it's the best tool
> for the job depends on what the job is and what
> your taste is.

Using INITIAL does not cause problems.  Contrarily it provides
a clear way to prefill the minibuffer.

Avoiding things like so

(minibuffer-with-setup-hook (lambda () (insert "BBB"))
  (completing-read "Input: " (list "AAA" "BBB" "CCC")))


> Whether Someone thinks that stylistically it's
> always bad to use INITIAL is, IMO, irrelevant.
> Someone is just plain wrong.  The devil, when it
> comes to what's useful in any given case, is in
> the details of the context of calling
> `completing-read', and in the users of that code.
>
> Someone should be a little less presumptuous, and
> just let it be.  Circulez - il n'y a rien a voir!
>





  reply	other threads:[~2023-08-21  6:29 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-17  0:47 bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-17  5:49 ` Eli Zaretskii
2023-08-17  6:05   ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-17  7:20     ` Eli Zaretskii
2023-08-17 10:27       ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-17 10:45         ` Eli Zaretskii
2023-08-18  0:35           ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18  1:47             ` Drew Adams
2023-08-18  3:49             ` Eli Zaretskii
2023-08-18  5:13               ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18  5:36                 ` Eli Zaretskii
2023-08-18  5:56                   ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18  6:32                     ` Eli Zaretskii
2023-08-18  8:40                       ` uzibalqa via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 12:14                         ` Eli Zaretskii
2023-08-18 12:27                           ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 12:30                             ` Eli Zaretskii
2023-08-18 12:55                               ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 13:27                                 ` Eli Zaretskii
2023-08-18 13:36                                   ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 15:23                                     ` Drew Adams
2023-08-18 15:16                 ` Drew Adams
2023-08-18 15:43                   ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 17:33                     ` Drew Adams
2023-08-18 19:12                       ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 21:03                         ` Drew Adams
2023-08-19  1:55                           ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-19  2:34                         ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-19  4:14                           ` Drew Adams
2023-08-19  4:22                             ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-19  4:46                               ` Drew Adams
2023-08-19  5:05                                 ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-19  6:34                                   ` Eli Zaretskii
2023-08-19 16:20                                     ` Drew Adams
2023-08-19 19:19                                       ` Eli Zaretskii
2023-08-19 20:56                                         ` Drew Adams
2023-08-20 16:39                                           ` Juri Linkov
2023-08-21  0:23                                             ` Drew Adams
2023-08-21  4:34                                               ` Christopher Dimech
2023-08-20  5:42                                         ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-20  6:12                                           ` Michael Heerdegen
2023-08-20  6:23                                             ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-20  6:34                                             ` Christopher Dimech
2023-08-21  0:25                                               ` Drew Adams
2023-08-21  4:26                                                 ` bug#65348: RE: [External] : " Christopher Dimech
2023-08-21  5:23                                                   ` Drew Adams
2023-08-21  6:29                                                     ` Christopher Dimech [this message]
2023-08-21  7:21                                                     ` bug#65348: " Christopher Dimech
2023-08-21 11:40                                                       ` Eli Zaretskii
2023-08-21 12:07                                                         ` Christopher Dimech
2023-08-21 12:25                                                           ` Eli Zaretskii
2023-08-21 13:27                                                             ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-21 16:08                                                         ` Drew Adams
2023-08-18 19:45                       ` Heime via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-18 21:07                         ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=trinity-ba45dc11-cbb7-4bdd-89dd-9eac5480bc5e-1692599392908@3c-app-mailcom-bs13 \
    --to=dimech@gmx.com \
    --cc=65348@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=heimeborgia@protonmail.com \
    --cc=michael_heerdegen@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.