From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Re: Other details about completion. Date: Thu, 7 Apr 2022 19:22:01 +0200 Message-ID: <20220407172201.qwggexthtersxi7x@Ergus> References: <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> <867d80c00z.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6105"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Philip Kaludercic , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 07 19:22:59 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 1ncVqV-0001R5-7N for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Apr 2022 19:22:59 +0200 Original-Received: from localhost ([::1]:58804 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ncVqT-0000Nx-Pr for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Apr 2022 13:22:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47628) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ncVpl-0007PI-Gs for emacs-devel@gnu.org; Thu, 07 Apr 2022 13:22:13 -0400 Original-Received: from sonic304-9.consmr.mail.bf2.yahoo.com ([74.6.128.32]:42233) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ncVpj-0006EK-35 for emacs-devel@gnu.org; Thu, 07 Apr 2022 13:22:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1649352129; bh=BZIu+WT2SiDtjE6CsBUBWkVI2IceeWJyM6OW8DxnUhg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=r3Ni7axABXnE6jZ58GwoTf+HQRNHeEeyvtnwyqQKDW8+CiS3cAGq2u1L7d1hHQeGGzmOl48Ggx3GivdjSsGdW2Ol04euJ4sYj3jF8m+gL6u01HO51bSQmYYFR1+W6rUeZMi69RSuDE4iUpjFplyGXH1EizEO9NwEIvlSMXqNoPUa8COXkn19OZZU9/gSkDvtTDYmy84pz8NEVYYD4kLpAr7mX7KuNu9ulUu/03MNtVMyYKV4SaHt2yPGk6RmpBQRqCwi73Xe6rgRjvnOT3Ao9gVLRzeLyfZwLTzTlnNSrpr48fw2Wd0Vs4ZGuB2u7IxC3L8jy/evBbupLQSEx2W37Q== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1649352129; bh=x7hG8SU8tCKBqErz2jfIkA5nGvtIqgwPt+0r010GcOW=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=YuL13mm2MPHx63vtMVlyTyOOuxGr36aIuSQPeGHukkHDs6ji2jX5kYoAIMJO8aQ1zZnMJn2mTkHzEKcMqKnNbOqN2myr6Bvq9Xtt3ffahyDKd1ZFlqye+cy7VNcL1K6nlPaXKVySKLeKoGO4t+GHGS/pue8kBKeg/hlm3c92b46E1Yb1NVwhUrJ+CiwpLLWuAjoXSwKgIvqJvbJO4fo+1BdVS7CIF/s4jpDoTZieDE3ZIyWGnNd9m1KIRTX+dbIDyDPd6RlAAqnNCu10xbQDwC60YQULd8cbj124+7Yn2ApA22mM9uQC3PAPIOoSivOXZN6K2syM3+iK0g0SQjAz3w== X-YMail-OSG: lY9rxKAVM1nFc8gTW7RT7juF0L4zHX0f0zYzCV.DYiSuZEKP2wOcz7fsEZP_Ybp cTkGV1Gtb1kJMVcHD_XkYqZiH_mz4fnxUm0UfjaUfwdhFv1_G37ST0hSfbKmpr7YVt.MgYanWK1i 4road.9OehiNNB4eW_5I.PyiUXxQkq1ULGikqyjDwwgfE8qL6MkyYJSSiLS5tlLdVQVhSy_Sf2Id 4YJq4MjhWv8TEMbvie3aB7Vm8DZVAYZ42NTOD4e5It8GPkqGA6PoNLqUfyhwZBJQrEBSpBgEZOv4 NSnHpOwf5moVbpjNqxu.tJZP0GZN0.wo0uMhr9107pnc41QVcKUbNhNopTo7LCjvVIl5G0tGgko1 4UJPGWZ.wOSkasITmizQJBnZITSob6VHfyjmiL.sK0Hsraw5lMyoekhJtSljAD7nTtGUKwcIV.VY TejptC3mqPIBRln2TbQjY0VavR615rl1CixdQ_m526U7hGtY4Klafl9MCWjQDa5sx.r.zm0S.IRi QR37RjSPYUMECoWch3PDQMwi7y_vz7AEPioAovQmdmBmt5Sz2hHGHSpviCqdPkbUq8.Zek6HeS5x mfsggbhckDVvcthUuyVKl7y5aK6rMqR77p3.XTxjWLCW17IEKLY.fZG87wFS5rRdKftINt8sJl9Y Ytf9MIOh3dDX1YGqhUT_1LnMqNYjQ_2uDgp7KaAQHNUH5vQS.9F.8yJUq7kYnd1rE1leqfCwZ33a YbdyRDIN.fyNTfnXPj8CBbtGYliRIJyd8T.i.JyJJzBQmni4sUkWL0pVn6Mn8nMLWc0Gg8Xv2cqa 9s0eUmz0_mWJJykJjNhJ603ZEyVOqws.DTFZJZxKfX X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Thu, 7 Apr 2022 17:22:09 +0000 Original-Received: by kubenode516.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID db0568ed0540f03d35b5d59b7772dd30; Thu, 07 Apr 2022 17:22:06 +0000 (UTC) Content-Disposition: inline In-Reply-To: <867d80c00z.fsf@mail.linkov.net> X-Mailer: WebService/1.1.20001 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Received-SPF: pass client-ip=74.6.128.32; envelope-from=spacibba@aol.com; helo=sonic304-9.consmr.mail.bf2.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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:287895 Archived-At: On Thu, Apr 07, 2022 at 07:50:28PM +0300, Juri Linkov wrote: >>> 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? > Basically because we don't need that exact behavior in all the details as our use case is a bit different different (and simpler). we use single commands most if the time. I mean, most of the completion we need are for single commands/candidates/files because we can't do things like: "M-x find-file /my/file/path" in a single line. (there are some exceptions line shell-commands or so... but those are the exception, not the rule) But also because emulating that from completions is straight forward considering that Completions is read-only and any edit attempt (insert a letter) will emit an error we can handle moving to the minibuffer and executing there whatever we need. zsh adds an extra space before the letter so even if it does not leave the command line completely there is a switch to a state where arrows navigate, a letter inserts a space and C-g restores to the initial... So there is a mode and context change. >>>> 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. > Yes, I already implemented that and you didn't liked because it was a bit long ;p... Now this is getting longer and longer.... >Also in zsh TAB moves vertically when columns are sorted vertically. >Shouldn't TAB in Emacs move vertically too when 'completions-format' >is 'vertical'? > Actually yes... But implementation will be long and ugly... I don't think it worth it... The ideal case may be to have some modes completions-vertical, completions-horizontal and completions-one-column that will handle all the pack together (bindings, order, formats)... but may break some of the external packages. Otherwise we will end with a code full of if-else and hard to maintain or extend...