From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: Other details about completion. Date: Thu, 07 Apr 2022 19:50:28 +0300 Organization: LINKOV.NET Message-ID: <867d80c00z.fsf@mail.linkov.net> References: <4E8D9AEF-4D7A-4B11-822F-8D0911964A05@aol.com> <86bkxfibdo.fsf@mail.linkov.net> <20220405232013.5y5jnr4ykzqgxqla@Ergus> <86a6cyiqlt.fsf@mail.linkov.net> <20220406132108.evlofp5l3krsl5h7@Ergus> <86sfqqduon.fsf@mail.linkov.net> <20220406181339.iubahj6fviq3fyqv@Ergus> <86o81eawnv.fsf@mail.linkov.net> <91135A5B-17B9-4B1A-AFB9-40D2656313DE@aol.com> <86ee29pawb.fsf@mail.linkov.net> <20220407090845.rvjzos3pp6f77qrz@Ergus> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36299"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (x86_64-pc-linux-gnu) Cc: Philip Kaludercic , emacs-devel@gnu.org To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 07 18:58:05 2022 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 1ncVSN-0009Jt-Gw for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Apr 2022 18:58:03 +0200 Original-Received: from localhost ([::1]:40494 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ncVSM-0003Z3-9J for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Apr 2022 12:58:02 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42554) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncVQt-0001by-Rj for emacs-devel@gnu.org; Thu, 07 Apr 2022 12:56:31 -0400 Original-Received: from relay5-d.mail.gandi.net ([217.70.183.197]:42813) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncVQr-0001zJ-MG for emacs-devel@gnu.org; Thu, 07 Apr 2022 12:56:31 -0400 Original-Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id 5A39A1C0005; Thu, 7 Apr 2022 16:56:26 +0000 (UTC) In-Reply-To: <20220407090845.rvjzos3pp6f77qrz@Ergus> (Ergus's message of "Thu, 7 Apr 2022 11:08:45 +0200") Received-SPF: pass client-ip=217.70.183.197; envelope-from=juri@linkov.net; helo=relay5-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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:287891 Archived-At: >> So C-g in the minibuffer could be two-step as well: >> first C-g closes the completions window and clears the suffix, >> second C-g exits the minibuffer. > > The most I go into this the most convinced I get that > completion-auto-select and selecting the Completions windows is the > simplest and cleaner way to go. Earlier you said that it should work like zsh. But does zsh really select the Completions window? I see that typing a letter while a completion candidate is highlighted in zsh, inserts both the highlighted completion candidate and the letter. This looks like it never leaves the command line that corresponds to the minibuffer in Emacs. So why do you think that switching to the Completions window is required to select a completion candidate? >>> Then it should probably be line-move but forward-line goes to column zero. >> >> Neither of them wraps to the beginning like next-completion does. > > The wrap behavior is only set for tab and backtab commands (yes, it is > hardcoded there... don't blame me) not even for all next-completion > uses. I prefer not to touch that code anymore or add more stuff > there... At some point we will decide to fix/replace the mouse-face > approach there and all this will be a nightmare to support the legacy > behavior. >This means we need a new command next-completion-vertical. > > I already tried that in the first version of zcomplete I did long time > ago. And you said (and I agreed) that it was too complicated. But in zsh and wrap to the top/bottom of the same column. Also in zsh TAB moves vertically when columns are sorted vertically. Shouldn't TAB in Emacs move vertically too when 'completions-format' is 'vertical'?