From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Stepping Back: A Wealth Of Completion systems Re: [ELPA] New package: vertico Date: Thu, 08 Apr 2021 20:03:31 +0200 Message-ID: <877dlcwt58.fsf@posteo.net> References: <9c9af088-580f-9fb1-4d79-237a74ce605c@inventati.org> <874kgkxxs0.fsf@posteo.net> <78741fe6-2612-d7c9-2bc4-0b68ea7fa51a@yandex.ru> <76a4d0e2-117b-165d-d56e-5bc2f504b50c@yandex.ru> <87blapln0r.fsf@posteo.net> <37bd2e96-ce04-eb6d-24da-fdd7ea427e61@yandex.ru> <87im4wx2ct.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13941"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Cc: "emacs-devel@gnu.org" , Dmitry Gutov To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 08 20:04:31 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lUZ15-0003XH-H2 for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 20:04:31 +0200 Original-Received: from localhost ([::1]:56166 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lUZ14-0006WE-Gg for ged-emacs-devel@m.gmane-mx.org; Thu, 08 Apr 2021 14:04:30 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44672) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUZ0G-00066d-6e for emacs-devel@gnu.org; Thu, 08 Apr 2021 14:03:43 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:37935) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lUZ0C-00036O-W9 for emacs-devel@gnu.org; Thu, 08 Apr 2021 14:03:39 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 002902400E5 for ; Thu, 8 Apr 2021 20:03:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1617905014; bh=3sFUhh3p2SIc1ZKOZc3ConEiR6R1ruCuLnfXxQTRCNk=; h=From:To:Cc:Subject:Date:From; b=e2196GcE1RWsuEMj6XSxfbLi+d3CBhxlpKmV7CXB+PHvrT4686KgBDMvGv/5NgskV fNsOdRO75cp8+wFBqy/Aew55fUNwfzj/MwsPPp8MN92SpZHNFrCUbfM+S10Mq+t62j n9mGx973IeSL4wnsenBMM0P+0S4l2s9IuCrNZj7hxpx6/9opx/XX5W4NEbDGyxJuhS qibFxTDPWP9vvJWpL3HiEfOQl/KH2m2Mh5h0EobvMEHXHcMS0gQHfXf0jqSuP7nDii 3AudfJaxekyAGZdrGDDT+IKZy7kpwTOSHJr7N1YwaVuiOfxin9FPigd/tC3ExQkUpd wKEciyKBmVOVQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4FGTdw1kHHz6tm5; Thu, 8 Apr 2021 20:03:32 +0200 (CEST) In-Reply-To: (Drew Adams's message of "Thu, 8 Apr 2021 17:21:43 +0000") Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:267646 Archived-At: Drew Adams writes: >> > What's the purpose of having that distinction? >> >> My hypothisis is that selection is held back >> by completing-read, > Why do you think so? Held back in what way(s)? > Details, please. Can completing-read offer a hierarchical overview, allow inspection into selected items, ensure that calls return values eq to the input, lazily compute textual representations when they are needed? Starting from a clean slate and intentionally designing an alternative function around selection would seem to have the advantage that we already know that people want, instead of having to fight what we already have. >> and that a framework that is explicitly made for >> selection and not retrofitted into the existing >> framework could stand to improve the user experience. > > Again, why do you think so? > > This is as vague as a suggestion to rewrite Emacs > so it uses Rust (or Python or Scheme or whatever) > instead of Lisp, with no attempt to say what the > need for that is or the advantages would be. > > I'm not arguing that `completing-read' has no > room for improvement. In fact, I'm the first to > say (and to have said, and shown) that there's > plenty of room. > > (I've actually improved it in many ways, in my > own code and practice. Lots of details and > experience with my own "proposed" changes to it.) > > But a vague argument at the level of "selecting" > versus "completing" doesn't cut it, in my book. > > Push the existing envelope first, to see where > the real limits of `completing-read' are, before > asking for an overhaul. I am not proposing an overhaul, but to make the job easier for completing-read. Instead of continuing to extend it by adding additional special arguments and finding loopholes in the current implementations of selection frameworks, I argue that a cleaner and more consistent solution can be found in trying to understand when selection is wanted, and how a solution that can be provided that directly solves the problem. I don't want to sound like a "Rewrite X in Y" kind of guy, because I don't want to replace completing-read. I like it, and I like it simple. Maybe it doesn't make sense to have both, but some experimentation is necessary before that can be concluded. -- Philip K.