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: vertical fido-mode Date: Fri, 21 Aug 2020 02:15:36 +0300 Organization: LINKOV.NET Message-ID: <87pn7llbnb.fsf@mail.linkov.net> References: <1704199899.1577092.1591806438580.ref@mail.yahoo.com> <1704199899.1577092.1591806438580@mail.yahoo.com> <13ec44ed-4b54-8d43-590f-709bd813fd01@yandex.ru> <795146083.1708851.1591826041689@mail.yahoo.com> <87y2ouldrr.fsf@mail.linkov.net> <20200819121755.24hgq4gyba2wkt76@Ergus> <87pn7mdqbe.fsf@mail.linkov.net> <20200820103746.6n5op7dtz563k7qm@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="1704"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: "emacs-devel@gnu.org" To: Ergus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Aug 21 01:28:20 2020 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 1k8tym-0000Lc-Bb for ged-emacs-devel@m.gmane-mx.org; Fri, 21 Aug 2020 01:28:20 +0200 Original-Received: from localhost ([::1]:50896 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k8tyl-0004Yc-EM for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Aug 2020 19:28:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39056) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k8tyC-0003tk-9U for emacs-devel@gnu.org; Thu, 20 Aug 2020 19:27:44 -0400 Original-Received: from relay3-d.mail.gandi.net ([217.70.183.195]:60381) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k8ty9-0003S0-QL for emacs-devel@gnu.org; Thu, 20 Aug 2020 19:27:44 -0400 X-Originating-IP: 91.129.102.47 Original-Received: from mail.gandi.net (m91-129-102-47.cust.tele2.ee [91.129.102.47]) (Authenticated sender: juri@linkov.net) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 9434160004; Thu, 20 Aug 2020 23:27:37 +0000 (UTC) In-Reply-To: <20200820103746.6n5op7dtz563k7qm@Ergus> (Ergus's message of "Thu, 20 Aug 2020 12:37:46 +0200") Received-SPF: pass client-ip=217.70.183.195; envelope-from=juri@linkov.net; helo=relay3-d.mail.gandi.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/20 19:27:38 X-ACL-Warn: Detected OS = Linux 3.11 and newer 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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:254064 Archived-At: > While in the minibuffer the horizontal arrows are used to > move-forward/backward and the vertical to search in history. > > Do you have any alternative? An alternative would be to use the same keys as used in web browsers to navigate completions from the url input field where M-up and M-down are used to display a list of completions and to navigate in completions, without switching to the completions buffer. > OTOH this is the simplest I could implement making minimal changes with > the hope of making some of this enabled by default in the "near" future > without too many old users complains. > > Otherwise we will implement just-another new mode that will be off by > default and probably nobody will use as there is ido/fido/icomplete/ivy > and so on. > > So far there are some details in the actual user experience with > *Completes* I didn't change intentionally. > > 1) Completions are only shown on demand (TAB) > > 2) When completions are shown TAB tries to scroll the completions buffer > if not all of them are visible (actual behavior) There are other keys that currently scroll the completions buffer as well: M-PgUp, M-PgDown, M-C-v, S-M-C-v. > 3) The completions are updated on demand (TAB) only (unlike zsh that they are > updated automatically on input) I think whether to show/update completions only on demand or to show/update them automatically on input should be customizable with a new option. > 4) Arrows and navigation keys keep their current meaning either in > minibuffer and *Completions* buffer. > > So far this doesn't changes the current experience at all, so old users > won't complain and we could enable this by default. I agree that any changes in the default behavior should be unobtrusive. > The only addition was the jump to completions with a TAB when all > completions are shown. The existing key that already jumps to completions is PgUp (M-v). > And exit completions with C-g like in zsh. The existing key to exit completions is ESC (delete-completion-window). > Do you think it worth doing a stronger change? I think that adding more logic to the existing key TAB is too strong change: for example, when the user doesn't notice that the completions buffer already displays all completions, types TAB again, and it switches to the completions buffer contrary to user wishes. OTOH, the feature of using TAB to switch to the completions buffer doesn't work when the list of completions is too big and not all completions are displayed.