From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: A solution to display completion candidates after point in a minibuffer Date: Sat, 03 Oct 2020 06:59:16 +0000 Message-ID: References: Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23820"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Oct 03 09:01:02 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 1kObXS-00065l-Em for ged-emacs-devel@m.gmane-mx.org; Sat, 03 Oct 2020 09:01:02 +0200 Original-Received: from localhost ([::1]:49550 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kObXR-0006Tr-Fe for ged-emacs-devel@m.gmane-mx.org; Sat, 03 Oct 2020 03:01:01 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41544) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kObVy-0005wg-8l for emacs-devel@gnu.org; Sat, 03 Oct 2020 02:59:30 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:49385) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kObVv-0008Dp-47 for emacs-devel@gnu.org; Sat, 03 Oct 2020 02:59:29 -0400 Original-Received: from sdf.org (IDENT:ghe@otaku.sdf.org [205.166.94.8]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 0936xJrX013127 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 3 Oct 2020 06:59:19 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 0936xQVw010534; Sat, 3 Oct 2020 06:59:26 GMT In-Reply-To: Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/03 02:59:23 X-ACL-Warn: Detected OS = ??? 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:256986 Archived-At: >>> [ FWIW, I just tried it in my local Emacs where I replaced the ad-hoc >>> `resize_mini_window` scrolling with the use of >>> `scroll-conservatively`, and I get the behavior that you seem to >>> prefer. ] >> >> Yes, that's not surprising, what your code does is essentially (or very >> close to) what I suggested to do in bug#43519 and bug#43572, > > Not really, because with my code, the window start is not explicitly set > to BOB unless the buffer's content is small enough to be completely > visible (the first version of my patch did, but not the current one). > That's correct indeed, but setting window start explicitly in resize_mini_window() is only a hint for redisplay, that can ignore this setting in particular when when point would become invisible. So in effect it's (very close to) what I suggested to do. >> Thank you, now I see what you mean. IMO (and I would be extremely >> surprised if I were the only one with that opinion) seeing the current >> directory disappearing is disturbing (and from a newcomer point of >> view: very disturbing), so the prompt an user input should always be >> displayed (unless the miniwindow is too small of course). > > I agree it's suboptimal when entering the minibuffer. OTOH it's a > perfectly acceptable behavior while editing the minibuffer's content and > can even be preferable in some cases to what you propose. > I don't think so, IMO the minibuffer prompt should be visible at all times. A rough equivalent of what you propose in a GUI would be, for example, for the Windows File Explorer or the macOS Finder to suddenly become fullscreen when the directory entered contains more files than it can display with its current size. But I will not argue further. Anyway, what you think could be a preferable behavior (showing the first line(s) when entering the minibuffer, and hiding it/them when the user has already entered some data) is easy to do with the minibuffer-local variable solution I propose. It suffices to (setq start-display-at-beginning-of-minibuffer nil) at some point. It could become a user preference, something like icomplete-always-display-prompt with a default value t. >>> IIRC the reason it won't scroll the second time around is because >>> point should be visible (and redisplay would only scroll in order to >>> move point within view). >> >> I don't know, but I'm not sure about that. If you (set-window-start >> nil 1) unconditionally in window-scroll-functions, this setting will be >> obeyed by redisplay, even if point is not visible anymore. > > Oh, indeed, in that case it would move point instead. > No, that's not what I meant. In that case redisplay does not scroll and does not move point. Point simply becomes invisible. It becomes visible again after the next redisplay, a second or two later.