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: on helm substantial differences Date: Wed, 18 Nov 2020 00:14:03 +0300 Message-ID: References: <87wnymda5g.fsf@mail.linkov.net> <87ima5he8j.fsf@mail.linkov.net> <87mtzfzt9a.fsf@mail.linkov.net> 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="7959"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Cc: spacibba@aol.com, andreyk.mad@gmail.com, emacs-devel@gnu.org, rudalics@gmx.at, Stefan Monnier , Gregory Heytings , Eli Zaretskii , Drew Adams To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Nov 17 22:16:28 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 1kf8Kx-0001xd-Ps for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Nov 2020 22:16:27 +0100 Original-Received: from localhost ([::1]:33852 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kf8Kw-0004Ff-QG for ged-emacs-devel@m.gmane-mx.org; Tue, 17 Nov 2020 16:16:26 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60512) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kf8Jp-0003Gp-0a for emacs-devel@gnu.org; Tue, 17 Nov 2020 16:15:17 -0500 Original-Received: from static.rcdrun.com ([95.85.24.50]:58439) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kf8Jn-0000oQ-5l; Tue, 17 Nov 2020 16:15:16 -0500 Original-Received: from localhost ([::ffff:41.202.241.56]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0010.000000005FB43D60.00005626; Tue, 17 Nov 2020 21:15:11 +0000 Content-Disposition: inline In-Reply-To: <87mtzfzt9a.fsf@mail.linkov.net> 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/17 15:48:56 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:259316 Archived-At: * Juri Linkov [2020-11-17 22:33]: > > Before knowing what's the best approach, I think we should clearly > > decide what would be the "ideal" new API. E.g. should it return "any > > string" and then it'd be up to the infrastructure code to store > > side-info about what is the corresponding candidate's actual text? > > After trying different variants, it turned out that the most convenient > is to use annotation-function that can contain a placeholder for the > completion candidate. Currently "%s" is used as a placeholder, > for example, "prefix %s suffix" but it can be any string. > Or maybe better to allow returning a list of two separate strings > for prefix and suffix from annotation-function? If I may comment on (not related to above paragraph) the attached .png picture is that minibuffer enlarged very much over the screen. What would happen if the screen would be split in two windows before completion, would then the very narrow scratch buffer on top be divided with another mode line? In that case both divided windows would be very narrow and not readable. Sometimes at least the focused window should be readable during completion as completion is very general for programmers who may need reference in the window they are working in. Large minibuffer window practically splits window in 2 parts, one very narrow, minibuffer very high. In this case your *scratch* buffer, would it have more text, would not be usable at all as it little would be visible. My suggestion is that minibuffer rather makes proper split window by default or that it does not enlarge over the screen more then the calculated half of the full window, as that way user would have visible buffer. My suggestion for Emacs that already has 2 split windows is that minibuffer completion does not resize the focused window as that is where user works and expects (probably) to maybe insert something into that buffer or use it as reference during completion. Rather minibuffer should use the unfocused other window (from two or more split windows) to show its completions then enlarging itself over the screen and effectively disturbing the visual static interface.