From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: vertico Date: Sat, 10 Apr 2021 09:17:53 +0200 Message-ID: <87sg3y7g7x.fsf@gnu.org> References: <87im4vglwv.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18044"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.5.11; emacs 28.0.50 Cc: emacs-devel@gnu.org To: Daniel Mendler Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 10 09:27:17 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 1lV81U-0004Ya-CQ for ged-emacs-devel@m.gmane-mx.org; Sat, 10 Apr 2021 09:27:16 +0200 Original-Received: from localhost ([::1]:58162 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lV81T-0007a9-Aj for ged-emacs-devel@m.gmane-mx.org; Sat, 10 Apr 2021 03:27:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55390) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lV80m-00072d-7V for emacs-devel@gnu.org; Sat, 10 Apr 2021 03:26:32 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40858) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lV80l-00048g-SP; Sat, 10 Apr 2021 03:26:31 -0400 Original-Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:58305) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1lV80j-000218-Vr; Sat, 10 Apr 2021 03:26:31 -0400 Original-Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailauth.nyi.internal (Postfix) with ESMTP id 4DD8C27C0054; Sat, 10 Apr 2021 03:26:29 -0400 (EDT) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sat, 10 Apr 2021 03:26:29 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudekvddgudduhecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfhgfhffvufffjgfkgggtsehttd ertddtredtnecuhfhrohhmpefvrghsshhilhhoucfjohhrnhcuoehtshguhhesghhnuhdr ohhrgheqnecuggftrfgrthhtvghrnhepvdfhudevuedvtdevieeffeehvdffueegheejtd ffhfeiveelvdfgheeujefgheffnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfk phepkeejrdduieefrdefuddrudehgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrh grmhepmhgrihhlfhhrohhmpehthhhorhhnodhmvghsmhhtphgruhhthhhpvghrshhonhgr lhhithihqdekieejfeekjeekgedqieefhedvleekqdhtshguhheppehgnhhurdhorhhgse hfrghsthhmrghilhdrfhhm X-ME-Proxy: Original-Received: from thinkpad-t440p (p57a31f9a.dip0.t-ipconnect.de [87.163.31.154]) by mail.messagingengine.com (Postfix) with ESMTPA id 58FF01080054; Sat, 10 Apr 2021 03:26:28 -0400 (EDT) In-reply-to: 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:267778 Archived-At: Hi Daniel, >> Now I have two questions: >> 1. Shouldn't there be a command like `th/vertico-complete' which >> completes the common part of the candidates? > > Vertico follows the design where you put less importance on the > prefix/TAB completion but instead excepts the user to enter more text > for narrowing, which works well with the orderless completion style. > > But note that Vertico is fully compatible with default completion, so > as you observed you can just use `minibuffer-complete`. If you bind > `minibuffer-complete` to the `vertico-map` it will work. See > https://github.com/minad/vertico#keymap. > > Is that good enough or do you have something else in mind? It's just almost good enough. It completes correctly but the candidates are not refreshed. For example, with find-file, it might complete uniquely to a directory but still display the siblings of that directory rather than its contents. That's why I've sneaked in a call to `vertico--exhibit' in my `th/vertico--complete' command. >> 2. One annoying effect with the above command and vertico is that the >> typical completion messages such as "Next char not unique" bump point >> to the right, i.e., with stock minibuffer completion you have >> my-input| [Next char not unique] >> whereas with vertico you have >> my-input [Next char not unique]| >> where | indicates point. Why is that? > > Yes, I've also observed issues with minibuffer messages appearing at > the wrong place. Vertico uses overlays to display the candidate count > and the candidate list, similar to Icomplete. Icomplete however > removes the overlay in the pre-command-hook and puts the overlay back > in the post-command-hook. I am not doing that. I just move the overlay > to the end but it seems this solution is not good enough. Since I have > not yet understood fully what the problem is I haven't done anything > yet to fix the issue. > > Besides, my recommendation would be to deactivate those messages. I > think they are pretty annoying. I suspect even more so in combination > with aggressive-completion. Yes, `completion-auto-help' makes absolutely no sense with vertico (and can be disabled with aggressive-completion using `aggressive-completion-auto-completion-help'). Probably the same is true for `completion-show-inline-help'. Bye, Tassilo