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: Fri, 02 Oct 2020 23:11:22 +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="37164"; 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 01:12:19 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 1kOUDq-0009XK-AV for ged-emacs-devel@m.gmane-mx.org; Sat, 03 Oct 2020 01:12:18 +0200 Original-Received: from localhost ([::1]:41260 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kOUDp-000134-CD for ged-emacs-devel@m.gmane-mx.org; Fri, 02 Oct 2020 19:12:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46482) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kOUD6-0000az-AM for emacs-devel@gnu.org; Fri, 02 Oct 2020 19:11:32 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:57614) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kOUD3-0006hS-P5 for emacs-devel@gnu.org; Fri, 02 Oct 2020 19:11:32 -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 092NBPMW003513 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Fri, 2 Oct 2020 23:11:25 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 092NBP6Q013230; Fri, 2 Oct 2020 23:11:25 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/02 15:39:34 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:256979 Archived-At: Hi Stefan, > > In your example recipe, the first line is hidden. I agree that it's > probably a bad idea *when you enter the minibuffer*. But this same > display is probably a better choice after the user read the prompt and > knows what's the current directory, at which point the list of remaining > completions is likely going to the main focus. > 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). > > After `set-window-start`, the redisplay will be inevitably re-started, > which in turn might decide to scroll and thus > `run_window_scroll_functions`, etc... > > 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. Which, by the way, explains the need of a recursive call to set-window-start-at-begin.