From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Support "\n" in icomplete-separator Date: Wed, 11 Nov 2020 18:26:51 +0300 Message-ID: References: <837dqv5huk.fsf@gnu.org> <83mtzp2qj0.fsf@gnu.org> <83r1p11369.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17987"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: Eli Zaretskii , monnier@iro.umontreal.ca, spacibba@aol.com, Andrii Kolomoiets , emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 11 16:29:14 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 1kcs3c-0004Vg-VA for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 16:29:12 +0100 Original-Received: from localhost ([::1]:39552 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcs3b-00037Q-Vm for ged-emacs-devel@m.gmane-mx.org; Wed, 11 Nov 2020 10:29:12 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51250) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcs1f-0001cd-5D for emacs-devel@gnu.org; Wed, 11 Nov 2020 10:27:11 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:45849) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcs1d-0006bo-2B; Wed, 11 Nov 2020 10:27:10 -0500 Original-Received: from localhost ([::ffff:197.157.34.177]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0009.000000005FAC02CA.00004661; Wed, 11 Nov 2020 15:27:06 +0000 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/11 08:57:59 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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:259011 Archived-At: * martin rudalics [2020-11-11 13:03]: > >> Applications have to accept that users want their minibuffer windows to > >> show just one line. Or at most two lines. Or three ... > > > > Also users: "Show us completions vertically" and > > (setq -separator "\n") > > Users shouldn't want the cake and eat it too. Any application should > take care of such users. If an application has a truly expandable > minibuffer window or a normal window at its hands, it can try to show > completions vertically. With the default minibuffer window, it should > always behave as if only one line were available. Personally, it is bad idea to expand minibuffer. I could agree maybe to 2 lines, not even to three. I prefer having possibility to expand completion into full screen and to expand into split-window so that mode line remains where it is. When I was asking here before some months how to write a function to replace `read-from-minibuffer' into `read-from-buffer' I have got some tips and I think Eli and others helped that Emacs does not break the excursion. Then I made it possible for strings larger than length X to expand editing into full window. When there is string to be entered larger than what minibuffer should accommodate in relation to legibility and disturbance of user interface (mode line going up with longer strings), then the full window opens and I can receive the string from window or full buffer. There are various components of user interface, mini buffer is "informational component" and users expect to get information on familiar place. Common user interface shall remain as such. Only exceptionally and by user's CHOICE should minibuffer open up. Not by default. Personally I like how helm does it, it opens split window usually and mode line remains where it is, while I can use mini buffer to narrow the collection and find the matches. I have not given any command to helm to have my mode line jump up and down. The built-in completing-read does not automatically let the mode line jump up. I can complete with by using few words and TAB. If there is no completion TAB will expand the mini buffer. In this case I have explicitly decided to see the collection. Deciding for user to expand mini buffer is bad idea. To understand my feelings you would need to manage database by using completion frameworks, with 100+ tables where some of them have hundreds of thousands of records. If we already get split-screen, at least mode line shall remain where it is. What about the case of using minibuffer within minibuffer? I hope that has been taken in account with icomplete. Hide Enable Recursive Minibuffers: Toggle on (non-nil) State : SET for current session only. Non-nil means to allow minibuffer commands while in the minibuffer. More TAB is meant for line completion. For narrowing match completion there are words and choice, up and down or forward and back. Maybe some lists of how to design user interfaces could help: https://www.usability.gov/what-and-why/user-interface-design.html What applies: Quotes: " Keep the interface simple. The best interfaces are almost invisible to the user. They avoid unnecessary elements and are clear in the language they use on labels and in messaging. Create consistency and use common UI elements. By using common elements in your UI, users feel more comfortable and are able to get things done more quickly. It is also important to create patterns in language, layout and design throughout the site to help facilitate efficiency. Once a user learns how to do something, they should be able to transfer that skill to other parts of the site." "Think about the defaults. By carefully thinking about and anticipating the goals people bring to your site, you can create defaults that reduce the burden on the user. This becomes particularly important when it comes to form design where you might have an opportunity to have some fields pre-chosen or filled out."