From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations Date: Tue, 25 May 2021 05:06:23 +0200 Message-ID: <651fcd24-679a-3476-cb55-762edfc0c1bc@daniel-mendler.de> References: <87zgwlb4xc.fsf@gmail.com> <617d06ca-27bf-2ae8-26eb-1042123499d3@daniel-mendler.de> <87pmxhb1rs.fsf@gmail.com> <23510125-37b9-e87e-3590-5322f44772ce@daniel-mendler.de> <87a6olazff.fsf@gmail.com> <0a854bd9-27b0-3ed3-ba74-25d2765c083a@daniel-mendler.de> <87fsybiwcc.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12873"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Juri Linkov , Dmitry Gutov , monnier@iro.umontreal.ca, "emacs-devel@gnu.org" To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 25 05:08:36 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 1llNQq-0003E9-O8 for ged-emacs-devel@m.gmane-mx.org; Tue, 25 May 2021 05:08:36 +0200 Original-Received: from localhost ([::1]:39574 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1llNQp-0002F7-NH for ged-emacs-devel@m.gmane-mx.org; Mon, 24 May 2021 23:08:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50834) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llNOo-0007Zn-8F for emacs-devel@gnu.org; Mon, 24 May 2021 23:06:30 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:39593 helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1llNOl-0001x1-BX for emacs-devel@gnu.org; Mon, 24 May 2021 23:06:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=M8UDjdQ2E7aKbwjytCshGQKMz1RwlLLQUPuPLa8TZu0=; b=GOjWVLtx0H5G5XcDIk//RxPGK+ cvMsiB8WFdOsMxC+q6B1To7Os3+iWr3l/CJSeqHCEAY7+AR4ca35x4ftR9HM2ZfSa8oCbUf49eRhX xvLe1SmUxXAxtUKLKFXnCf0TJcHK5KVcaLDFdeln33ClFt+6VRYtM40fsntwSHDUeWQs=; In-Reply-To: <87fsybiwcc.fsf@gmail.com> Content-Language: en-US Received-SPF: pass client-ip=2a01:4f8:121:346::180; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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:269830 Archived-At: On 5/25/21 12:46 AM, João Távora wrote: > Daniel Mendler writes: > >> On 5/23/21 11:54 PM, João Távora wrote: >>> By the way, as a tangent to this, but spurred by your activity and >>> improvements to icomplete.el, I'm also thinking of enhaving icomplete.el >>> to allow a different type of scrolling in icomplete-vertical-mode where >>> the active completion isn't necessarily shown in the screen line of the >>> minibuffer. So that it acts more like a classic dropdown. Kind of >>> company-mode but in the minibuffer. >> >> You may want to take a look at my Vertico package which is on GNU ELPA. >> It is basically a reimplementation of Icomplete with a classic dropdown. >> The inner workings are similar to Icomplete. The main technical >> difference is that Icomplete rotates the candidates, while Vertico keeps >> an index. > > I think rotation makes sense in vanilla icomplete, but not in > icomplete-vertical-mode. So for the latter, I think I will just take > the cue from Vertico and use an index (or equivalent). Since it's in > GNU ELPA, maybe even borrow some code :-) Oh, I disagree here. I think Icomplete should continue to use rotations, since this is what Icomplete is. Why bake in two very different modi inside Icomplete, given that Vertico exists? Honestly, I think it would be better than just import Vertico into Emacs then. Of course it also lives happily on ELPA. Baking two such different modi in Icomplete only complicates things and I don't consider Icomplete a clean implementation actually, since it bakes both `completion-in-region` and `completing-read` into one package (see my criticism on the README of Vertico and Corfu). Vertico and Corfu are deliberately separate to have the ability to optimize the `completion-in-region` and `completing-read` UI separately. Instead of using an index you could still use the rotations and only reorganize the display such that the current candidate is not visualized on the top. I think using rotations is even necessary if you want to continue to use the default completion functions which take the first candidate of the list into account. Of course you can change these inner workings too (I am talking about completion-all-sorted-completions). But I am really not sure what the point is of this in Icomplete. Maybe it makes sense to decouple/deconstruct the minibuffer.el implementation more such that the completion backend functionality is more separate from the display functionality. >>> Another idea is to make icomplete work for >>> `completion-in-region-function`. >> >> Icomplete already should somehow work as a >> `completion-in-region-function`, but I think it is a bit brittle. > > I have a vague recollection that Someone Somewhere (tm) in one of my > extensions over at GitHub tried it out and found it could mostly work > with some tweaks. Will search for it. I also tried it out and it somehow works. But as argued above, I think it is actually better to maintain this in separate packages, at least if you start from a clean slate. This way one can do away with all these icomplete--field-beg accessors too. >> Related to my Vertico package, I also have the Corfu package, which uses >> a similar implementation as Vertico, but uses a child frame to display >> the completion list (Similar to Company-Box, Company-Posframe etc). >> >> https://github.com/minad/vertico >> https://github.com/minad/corfu Of course I will not hold you back from revamping Icomplete completely. It is good to have multiple UIs. But you could seriously consider my packages - I think they are exactly what you may be looking for - a clean slate (vertical) reimplementation of Ivy/Icomplete, relying only on the default completion facilities. I am sure you have some good criticism regarding my code or improvement proposals. Daniel