From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christopher Dimech Newsgroups: gmane.emacs.bugs Subject: bug#65348: RE: RE: [External] : bug#65348: INITIAL-INPUT in completing-read repeats same entry twice consecutively Date: Mon, 21 Aug 2023 09:21:40 +0200 Message-ID: References: <7D2p2XmGzWwhYjrI_PaUsn8r_NaQf-B0eAf7AmeRIhBEl84z79j_jKky-Lqlt6nc52SQ7T5yrL9OdqUzou1Mh3zQzgJx-SV6kIvc9Km8bDg=@protonmail.com> <83a5un35h6.fsf@gnu.org> <83o7j2yh47.fsf@gnu.org> <571_jSaUteaY0xDvqYdtM-FS0QLvAyOLY94AUDK81h4Fdn0jF869iyYXLHgsEmj1cEMNt6QHJnfCKY-__59S3R8z4SG03sXu9rO6mQa8nwg=@protonmail.com> <87sf8es0m0.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29410"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Michael Heerdegen , "heimeborgia@protonmail.com" , "65348@debbugs.gnu.org" <65348@debbugs.gnu.org>, Drew Adams To: "eliz@gnu.org" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Aug 21 09:22:45 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qXzFM-0007P4-RB for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Aug 2023 09:22:44 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXzEf-0008Qa-Jg; Mon, 21 Aug 2023 03:22:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXzEe-0008QS-Jw for bug-gnu-emacs@gnu.org; Mon, 21 Aug 2023 03:22:00 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qXzEe-00029d-9V for bug-gnu-emacs@gnu.org; Mon, 21 Aug 2023 03:22:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qXzEg-0001FZ-58 for bug-gnu-emacs@gnu.org; Mon, 21 Aug 2023 03:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Christopher Dimech Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Aug 2023 07:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65348 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 65348-submit@debbugs.gnu.org id=B65348.16926025194796 (code B ref 65348); Mon, 21 Aug 2023 07:22:02 +0000 Original-Received: (at 65348) by debbugs.gnu.org; 21 Aug 2023 07:21:59 +0000 Original-Received: from localhost ([127.0.0.1]:55340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXzEd-0001FH-75 for submit@debbugs.gnu.org; Mon, 21 Aug 2023 03:21:59 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:54907) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qXzEY-0001Ew-At for 65348@debbugs.gnu.org; Mon, 21 Aug 2023 03:21:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.com; s=s31663417; t=1692602500; x=1693207300; i=dimech@gmx.com; bh=Hmn4Pf1imcrLaoVAqeyMqyZxH+VnK5M02fKehMys0LE=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=svKS0ENxdLwHvlbxHzp3+trwjjyhu7ochTV/slEGah+M2eYcvLCpkhcUZwn3gcw4Z29zJMR Qw6qW+2D0pO47h3hJst7g3fxlhir2x50X+w5vpekRvFiXRc9o+EeMQc30ykXzMpXu2w1XK/5D jDg283pci5dtN8FSQMURl0b1uq1T8JOk1Y1Dd0/hW17vuOqTyIvlsmGn3YLabxUh+dJZMbfeJ Ql5ktPXqlRqVB0+CuY5mroyiSq3q7ILo7NDnpRNoj4YhGilj0IKqkV1v5kCbo+vNwAz77KML7 9EFucXpq5MAHmAZvqEzPSwy78p2jr/wftuq5x8QYP1ZIuYHLVVQA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [141.8.81.247] ([141.8.81.247]) by web-mail.gmx.net (3c-app-mailcom-bs13.server.lan [172.19.170.181]) (via HTTP); Mon, 21 Aug 2023 09:21:40 +0200 Importance: normal Sensitivity: Normal In-Reply-To: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K1:QgMnC5X5t6ZaZzeA75tIIUjG7/7We6ijoizsDgxRPSE+kDftVNSt/iBJ0MT0HRWnNh+B1 +hg8nUzVFvZAR0Z6YAeMZJRsHuJ//i6LHJBLC27lYQRzXhTXeJwc8qR8Oye12E+BWEX93eHsqlUZ fCOhTqBYYscFI/jmbBllslI4LIskTGTgqvAF9/6qzSRsaPk2JkvmqaYeFohwoaw9u9nI/YFuYFPt /8WxfXWUTa7En+ICfhyGXxyze6qGZ+NwmQvJVqbIxgYdmfQ8F6zK1gBZGGWrhz5S/VMJzWxlXp3V 1w= UI-OutboundReport: notjunk:1;M01:P0:u7Bq4/PLnPI=;/lKWghA3qSnJRTqZvGCQ6RiA6XQ 5cFtMjyavv65P9F0DYk5kwN2z1XTZdHGEnn/bZ6YFK2zUU1PgVN8J8ZP+cCob+G9SDX6PK+5k pxYQJ6t0qjYjWWdM/Dw4St+M535cIROr0eXugGgHaPsIOZAfThxLDONzloK0YSpm+4WbYqy2f kUrFEicZk2Yt/UbkbCDhxU4jG02p6Gztk3e76ZDp7SJ/z0XNLdnOTCHJC/z97qzG4aSh8iRLe zqYWjZr3HKqIoBKtkPrW2bRVjgF1T5xFMQwQKk+xUfoDxE45defYAU85Oj7YID9wrrlvZNbhS KrDjedG9GZOq/esYCqsPGbLOSSAYegpU4NRMKDq0Zeo773TGUPaAfZjdAzcgDW+qO6iHU3yHv FCmRE16FlpYUlVCfnx9cLusaKpXyPNLr0K/uc2QjtVQ8MkBe1KP6ZuAVS4KeX9L2sAvQPl2qA eQTA2XR0MkXva5kB2pw1cCY/Ar2zix38MPpN4GdLzKC4YB9QIc82F6qBqL7+fhpQVU4xr0ifG 3LXegSN3KZJ7af60uTPMn4PNf9npJ5wNCPRHEeicq6evvnmdKflk/EXD9AkjgggG8byHn6peW V/n+EZPDsAYy07s2uYS8MOu+WhOq4i5M+6dnn1XMCdu77XSaaVvHcDgmqOCLz+3wvD1yUsYJH eg/EyFoPVOXw3ucJ6jyOGNjPGfg1rc1wARoIPZZLsJ8ewJfOznd16MdbQzYiWH7oOzWnHW0qM RyGovBwWiAIQlLXDs5wBX/4ynpOxSMuzZmMY4UqGOrAkRAupj0zRGNYemWGIWiNv9Vkf5v4Q X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:268062 Archived-At: Eli, there needs to be some clarification. Initially this was about INITIAL-INPUT, its possible deprecation in the doctring, and the COLLECTION-HISTORY debacle. What is the situation exactly ? Is the use of nil for INITIAL-INPUT consistent with the future plan about INITIAL-INPUT ? Having the ability to prefill the minibuffer with a collection entry is perfectly reasonable expectation for people to use. As for the COLLECTION-HISTORY thing, it is something that can be considere= d in a different titled discussion, if need be. > Sent: Monday, August 21, 2023 at 5:23 PM > From: "Drew Adams" > To: "Christopher Dimech" > Cc: "Michael Heerdegen" , "65348@debbugs.gnu.o= rg" <65348@debbugs.gnu.org>, "eliz@gnu.org" , "heimeborgia@p= rotonmail.com" > Subject: RE: RE: [External] : bug#65348: INITIAL-INPUT in completing-re= ad 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? > > > > 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. > > > > 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. 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. > > `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 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. > > > It does not happen regularly that new features are accessed in ways th= at > > maintain clarity and avoids unnecessary complexity. > > And? Not sure I follow your point there. > > > > 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? > > 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 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. > > 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! >